WEBVTT

1
00:00:00.160 --> 00:00:02.879
<v Speaker 1>Welcome to the deep dive. You know, we often think

2
00:00:02.879 --> 00:00:05.960
<v Speaker 1>about our digital identities, but maybe not the hidden foundations,

3
00:00:06.000 --> 00:00:08.279
<v Speaker 1>the systems that really know who we are online, what

4
00:00:08.400 --> 00:00:12.119
<v Speaker 1>we can access. It can get complex, but it's incredibly vital,

5
00:00:12.199 --> 00:00:15.279
<v Speaker 1>it really is. Today we're taking a deep dive into

6
00:00:15.359 --> 00:00:20.559
<v Speaker 1>Sanderbrickauer's Active Directory Administration Cookbook. Our mission to pull out

7
00:00:20.600 --> 00:00:24.480
<v Speaker 1>the absolute must know nuggets about Active directory. You know,

8
00:00:24.600 --> 00:00:27.519
<v Speaker 1>from its core on prem structures right through to how

9
00:00:27.519 --> 00:00:31.199
<v Speaker 1>it fits into this modern hybrid cloud world. Think of

10
00:00:31.239 --> 00:00:34.200
<v Speaker 1>it as your shortcut to really understanding the backbone of

11
00:00:34.359 --> 00:00:36.119
<v Speaker 1>enterprise identity exactly.

12
00:00:36.200 --> 00:00:39.479
<v Speaker 2>And it's not just about the peck jargon, is it. It's

13
00:00:39.079 --> 00:00:42.320
<v Speaker 2>really about understanding the why behind the big design choices,

14
00:00:42.840 --> 00:00:46.079
<v Speaker 2>the security decisions, and identity management, trying to make sense

15
00:00:46.159 --> 00:00:48.960
<v Speaker 2>of what can feel like a pretty overwhelming landscape. Sometimes.

16
00:00:49.079 --> 00:00:52.000
<v Speaker 1>Okay, let's get into it then, Active Directory. Some might

17
00:00:52.000 --> 00:00:54.880
<v Speaker 1>think it sounds a bit well old school, but its

18
00:00:54.880 --> 00:00:57.960
<v Speaker 1>core ideas are still incredibly relevant even if you're mainly

19
00:00:58.000 --> 00:01:00.200
<v Speaker 1>in the cloud. Now, let's start right at the beginning.

20
00:01:00.240 --> 00:01:03.719
<v Speaker 1>Domains and forests, these fundamental building blocks. When does adding

21
00:01:03.719 --> 00:01:05.680
<v Speaker 1>a whole new domain actually make sense?

22
00:01:06.000 --> 00:01:09.359
<v Speaker 2>That's a great starting point. The rationale for a new

23
00:01:09.400 --> 00:01:14.400
<v Speaker 2>domain usually comes down to needing very specific boundaries. So

24
00:01:14.640 --> 00:01:18.439
<v Speaker 2>maybe you need a totally separate DNS domain name, like

25
00:01:18.480 --> 00:01:21.120
<v Speaker 2>for a new business venture or something. Okay, that also

26
00:01:21.200 --> 00:01:26.239
<v Speaker 2>lets you limit how eighty integrated DNS zones replicate, keep

27
00:01:26.239 --> 00:01:32.040
<v Speaker 2>that DNS info just within that domain, and perhaps most importantly,

28
00:01:32.359 --> 00:01:35.439
<v Speaker 2>it gives you a boundary for different password policies, different

29
00:01:35.439 --> 00:01:39.519
<v Speaker 2>account logout rules, or maybe shielding sensitive accounts that you

30
00:01:39.519 --> 00:01:41.000
<v Speaker 2>don't want visible everywhere else.

31
00:01:41.159 --> 00:01:44.120
<v Speaker 1>Right, So fine grain control within that boundary. But Microsoft

32
00:01:44.120 --> 00:01:46.879
<v Speaker 1>often advises keeping things simple, don't they? What are the

33
00:01:46.959 --> 00:01:49.799
<v Speaker 1>kind of downsides or the hidden costs of adding that

34
00:01:49.879 --> 00:01:50.400
<v Speaker 1>new domain?

35
00:01:50.799 --> 00:01:53.599
<v Speaker 2>They definitely advise simplicity, and for good reason. Look, adding

36
00:01:53.599 --> 00:01:56.439
<v Speaker 2>a new domain isn't trivial. You're immediately talking about needing

37
00:01:56.439 --> 00:01:59.959
<v Speaker 2>at least two extra domain control right, redundancy exactly, more

38
00:02:00.040 --> 00:02:02.719
<v Speaker 2>active directory trust to manage between the domains, and just

39
00:02:02.840 --> 00:02:06.560
<v Speaker 2>generally a bigger administrative workload. It's complexity.

40
00:02:06.760 --> 00:02:09.800
<v Speaker 1>Okay, so that's the domain boundary. If that creates one level,

41
00:02:10.080 --> 00:02:13.000
<v Speaker 1>what about a forest that sounds like an even bigger step.

42
00:02:13.000 --> 00:02:13.879
<v Speaker 1>Where does that fit in?

43
00:02:13.960 --> 00:02:16.800
<v Speaker 2>It's a much bigger step. Yes, a new active directory

44
00:02:16.840 --> 00:02:23.680
<v Speaker 2>forest is essentially a completely new independent AD environment. By default,

45
00:02:23.960 --> 00:02:28.039
<v Speaker 2>there's no relationship, no trust with any existing forests.

46
00:02:28.039 --> 00:02:29.639
<v Speaker 1>You might have total separation.

47
00:02:29.719 --> 00:02:33.400
<v Speaker 2>Total separation. It creates the strongest possible boundary. Think about

48
00:02:33.400 --> 00:02:37.120
<v Speaker 2>things like the schema and configuration petitions in AD. If

49
00:02:37.159 --> 00:02:40.319
<v Speaker 2>you have an application that needs specific schema changes, maybe

50
00:02:40.439 --> 00:02:42.240
<v Speaker 2>something that could conflict with your main AD.

51
00:02:42.240 --> 00:02:44.800
<v Speaker 1>Like a legacy app or something really cutting.

52
00:02:44.639 --> 00:02:48.000
<v Speaker 2>Edge precisely, or maybe you need absolute separation for the

53
00:02:48.000 --> 00:02:51.560
<v Speaker 2>global catalog. You don't want certain object details replicating across

54
00:02:51.599 --> 00:02:54.639
<v Speaker 2>that boundary. The forest is really your ultimate security and

55
00:02:54.719 --> 00:02:58.159
<v Speaker 2>administrative boundary. It's also the go to structure if you're

56
00:02:58.159 --> 00:03:02.039
<v Speaker 2>planning for say acquisition or to vestiture down the line,

57
00:03:02.240 --> 00:03:04.199
<v Speaker 2>you know you'll need to cleanly separate things later.

58
00:03:04.400 --> 00:03:07.199
<v Speaker 1>That makes sense for M and A heavy businesses, but

59
00:03:07.400 --> 00:03:11.479
<v Speaker 1>doubling the admin effort difficulty sharing resources like address lists

60
00:03:11.520 --> 00:03:14.840
<v Speaker 1>or apps, that sounds like a serious commitment.

61
00:03:14.919 --> 00:03:17.360
<v Speaker 2>Oh it is. You really have to weigh the need

62
00:03:17.800 --> 00:03:23.120
<v Speaker 2>for that absolute separation against the ongoing operational cost and complexity.

63
00:03:23.159 --> 00:03:26.680
<v Speaker 2>It's a major architectural decision with long term consequences.

64
00:03:26.879 --> 00:03:30.039
<v Speaker 1>It really highlights those critical choices admins make early on,

65
00:03:30.120 --> 00:03:33.360
<v Speaker 1>doesn't it decisions that just ripple through the whole life cycle?

66
00:03:33.520 --> 00:03:37.319
<v Speaker 1>No wonder. Sanderberkauer calls himself an active directory of ficionado.

67
00:03:37.759 --> 00:03:38.560
<v Speaker 1>These are big.

68
00:03:38.360 --> 00:03:40.560
<v Speaker 2>Calls, absolutely foundational stuff.

69
00:03:40.639 --> 00:03:43.039
<v Speaker 1>So once you have that structure, that blueprint, you need

70
00:03:43.080 --> 00:03:45.479
<v Speaker 1>the actual servers running at the domain controllers. These are

71
00:03:45.479 --> 00:03:50.800
<v Speaker 1>like the identity castles right offering LDAP, corberos, the core services.

72
00:03:51.520 --> 00:03:54.680
<v Speaker 1>What's key to managing these today, especially since they're not

73
00:03:54.719 --> 00:03:56.680
<v Speaker 1>always physical boxes anymore.

74
00:03:56.319 --> 00:04:00.719
<v Speaker 2>That's right, Managing dcs involves, you know, the basics, promoting

75
00:04:00.759 --> 00:04:03.000
<v Speaker 2>a server to become a DC and solling the ad

76
00:04:03.039 --> 00:04:05.560
<v Speaker 2>domain services role and then demoting it when it's no

77
00:04:05.639 --> 00:04:08.960
<v Speaker 2>longer needed. And yeah, these days they're very often virtual machines, which.

78
00:04:08.759 --> 00:04:11.360
<v Speaker 1>Brings its own considerations. I imagine it does.

79
00:04:11.199 --> 00:04:14.719
<v Speaker 2>Things like snapshotting clumbing, which we can touch on. But

80
00:04:14.840 --> 00:04:17.680
<v Speaker 2>one really interesting type of DC is the read only

81
00:04:17.720 --> 00:04:19.079
<v Speaker 2>domain controller.

82
00:04:19.040 --> 00:04:22.560
<v Speaker 1>The RDC AH Yes, rodcs. I know. They're often used

83
00:04:22.560 --> 00:04:25.600
<v Speaker 1>in places like branch offices or perimeter networks. What makes

84
00:04:25.639 --> 00:04:27.160
<v Speaker 1>them special from a security angle?

85
00:04:27.600 --> 00:04:31.800
<v Speaker 2>Their main purpose is security in less secure locations. They

86
00:04:31.839 --> 00:04:34.360
<v Speaker 2>hold a read only copy of the eighty database and

87
00:04:34.399 --> 00:04:39.360
<v Speaker 2>the NSYS vol share. Crucially, they use what's called scoped reputation,

88
00:04:39.759 --> 00:04:42.839
<v Speaker 2>meaning you can figure exactly which user and computer accounts

89
00:04:43.000 --> 00:04:45.920
<v Speaker 2>and importantly, which passwords are allowed to be cased on

90
00:04:45.959 --> 00:04:49.120
<v Speaker 2>that RODC, so only the necessary accounts for that location

91
00:04:49.160 --> 00:04:52.439
<v Speaker 2>are stored there. If it gets compromised, the blast radius

92
00:04:52.480 --> 00:04:52.920
<v Speaker 2>is much.

93
00:04:52.759 --> 00:04:56.399
<v Speaker 1>Smaller because sensitive admin accounts, for instance, wouldn't be cashed there.

94
00:04:56.439 --> 00:05:00.040
<v Speaker 2>Hopefully ideally know you can figure password replication policies to

95
00:05:00.040 --> 00:05:03.319
<v Speaker 2>prevent that. Plus they have a unique security feature related

96
00:05:03.319 --> 00:05:07.480
<v Speaker 2>to Corberos. Each RODC gets its own special care BTG account.

97
00:05:07.639 --> 00:05:10.000
<v Speaker 2>It looks like CARABGGT followed by some numbers.

98
00:05:10.079 --> 00:05:14.040
<v Speaker 1>Right, the standard Carbero's Ticket Granting Service account is just krebtwgt.

99
00:05:14.560 --> 00:05:19.360
<v Speaker 2>Exactly, this unique RODC account is used to encrypt Carbero's

100
00:05:19.399 --> 00:05:24.120
<v Speaker 2>tickets issued by that RODC, So if someone physically steals

101
00:05:24.160 --> 00:05:25.800
<v Speaker 2>an RODC, they can't use.

102
00:05:25.720 --> 00:05:29.839
<v Speaker 1>Its krabtgkey to decrypt tickets and impersonate users across the

103
00:05:29.839 --> 00:05:30.439
<v Speaker 1>whole domain.

104
00:05:30.519 --> 00:05:33.600
<v Speaker 2>Precisely, they can only compromise the tickets issued by that

105
00:05:33.639 --> 00:05:37.399
<v Speaker 2>specific RODC, and only for the account's casturre it. It

106
00:05:37.519 --> 00:05:41.360
<v Speaker 2>significantly contains the damage compared to compromising a writeable DC.

107
00:05:41.839 --> 00:05:44.839
<v Speaker 1>That's a clever bit of security design for those edge scenarios. Okay,

108
00:05:44.959 --> 00:05:47.839
<v Speaker 1>RDCs helps secure distributed spots, but what about just getting

109
00:05:47.920 --> 00:05:51.519
<v Speaker 1>new dcs up and running quickly? You mentioned virtualization brings changes.

110
00:05:51.560 --> 00:05:52.319
<v Speaker 1>Is there anything there?

111
00:05:52.399 --> 00:05:56.439
<v Speaker 2>Yes? Absolutely, Speed and consistency are key, especially in virtual environments.

112
00:05:56.800 --> 00:05:59.319
<v Speaker 2>And this is where domain controller cloning comes in. It's

113
00:05:59.319 --> 00:06:02.560
<v Speaker 2>a feature that lets you well clone existing virtual.

114
00:06:02.279 --> 00:06:05.720
<v Speaker 1>Dcs, clone a domain controller. That sounds risky. Didn't That

115
00:06:05.800 --> 00:06:07.120
<v Speaker 1>used to cause major problems?

116
00:06:07.199 --> 00:06:09.839
<v Speaker 2>It absolutely used to be a huge no. No. Cloning

117
00:06:09.839 --> 00:06:15.240
<v Speaker 2>could lead to duplicate security identifiers, sids, USN, rollback issues,

118
00:06:15.839 --> 00:06:18.639
<v Speaker 2>all sorts of nightmares. But starting with Windowserver twenty twelve,

119
00:06:18.720 --> 00:06:20.199
<v Speaker 2>they introduced safe cloning.

120
00:06:20.480 --> 00:06:21.839
<v Speaker 1>Okay, how does that work safely?

121
00:06:22.040 --> 00:06:26.600
<v Speaker 2>The magic ingredient is a hypervisor feature called VM generation ID.

122
00:06:26.839 --> 00:06:30.279
<v Speaker 2>Most modern hypervisors support this now hyper v.

123
00:06:30.480 --> 00:06:33.240
<v Speaker 1>VMware And what does VM generation ID do.

124
00:06:33.519 --> 00:06:35.959
<v Speaker 2>It's basically a one hundred and twenty eight bit random

125
00:06:36.040 --> 00:06:38.879
<v Speaker 2>number that's stored in the virtual machin's memory, but also

126
00:06:38.920 --> 00:06:41.480
<v Speaker 2>gets written into the active directory database by the DC.

127
00:06:42.399 --> 00:06:44.839
<v Speaker 2>If you restore a snapshot of a DC, or if

128
00:06:44.879 --> 00:06:47.879
<v Speaker 2>you clone a vhdx file, the hypervisor generates a new

129
00:06:47.959 --> 00:06:49.000
<v Speaker 2>VM generation ID.

130
00:06:49.319 --> 00:06:52.639
<v Speaker 1>AH, so the DC boots up, sees the ID in

131
00:06:52.720 --> 00:06:55.319
<v Speaker 1>memory doesn't match the one in its database exactly.

132
00:06:55.600 --> 00:06:58.319
<v Speaker 2>It knows something major happened to roll back or a clone.

133
00:06:58.639 --> 00:07:02.279
<v Speaker 2>It then takes safety precautions like invalidating its local rid

134
00:07:02.360 --> 00:07:05.079
<v Speaker 2>pool to prevent duplicate sids, and if it's a clone,

135
00:07:05.120 --> 00:07:07.720
<v Speaker 2>it goes through a process to make itself unique. It

136
00:07:07.800 --> 00:07:11.120
<v Speaker 2>essentially allows safe rapid deployment of new dcs from a

137
00:07:11.160 --> 00:07:13.959
<v Speaker 2>template image, as long as the source DC is properly

138
00:07:14.000 --> 00:07:17.319
<v Speaker 2>prepared and doesn't hold certain sensitive FSMO rolls like the

139
00:07:17.319 --> 00:07:18.199
<v Speaker 2>PDC emulator.

140
00:07:18.319 --> 00:07:21.560
<v Speaker 1>That VM generation ID is a fantastic example of AD

141
00:07:21.680 --> 00:07:24.800
<v Speaker 1>adapting to virtualization, really neat tech. So okay, let's loop

142
00:07:24.839 --> 00:07:26.959
<v Speaker 1>back to the RODC for a second. If one does

143
00:07:27.000 --> 00:07:29.680
<v Speaker 1>get compromised, say stolen from a branch office, how fast

144
00:07:29.680 --> 00:07:30.560
<v Speaker 1>can you lock it down?

145
00:07:30.720 --> 00:07:33.600
<v Speaker 2>The recovery is designed to be quick because it has

146
00:07:33.639 --> 00:07:37.439
<v Speaker 2>that unique care. BTG account admins can immediately reset the

147
00:07:37.480 --> 00:07:40.600
<v Speaker 2>password for that specific account an ad they can also

148
00:07:40.639 --> 00:07:43.079
<v Speaker 2>trigger a password reset for all the user accounts whose

149
00:07:43.079 --> 00:07:45.800
<v Speaker 2>credentials might have been cached on that RODC.

150
00:07:45.480 --> 00:07:48.560
<v Speaker 1>So you invalidate its ability to issue tickets and reset

151
00:07:48.600 --> 00:07:50.199
<v Speaker 1>potentially exposed passwords.

152
00:07:50.279 --> 00:07:53.399
<v Speaker 2>Right, it renders the stolen device pretty much useless from

153
00:07:53.399 --> 00:07:57.439
<v Speaker 2>an AD perspective, very quickly, much faster and less impactful

154
00:07:57.480 --> 00:07:59.160
<v Speaker 2>than losing a full writeable DC.

155
00:07:59.439 --> 00:08:03.600
<v Speaker 1>Okay, makes sense. Let's shift gears a bit. Users, groups,

156
00:08:03.800 --> 00:08:07.879
<v Speaker 1>computer objects. This is the daily grind for many AD admins,

157
00:08:07.879 --> 00:08:10.279
<v Speaker 1>the bread and butter. What are some key things, maybe

158
00:08:10.279 --> 00:08:13.560
<v Speaker 1>beyond the absolute basics, that help manage these effectively and

159
00:08:13.680 --> 00:08:14.839
<v Speaker 1>securely well?

160
00:08:14.920 --> 00:08:18.240
<v Speaker 2>PowerShell is obviously key for anything beyond simple one off

161
00:08:18.279 --> 00:08:21.879
<v Speaker 2>tasks in the GI for automation bulk changes, it's essential.

162
00:08:22.240 --> 00:08:25.319
<v Speaker 2>But AD itself has gained some interesting features. One I

163
00:08:25.399 --> 00:08:28.160
<v Speaker 2>find particularly useful is expiring group memberships.

164
00:08:28.240 --> 00:08:30.319
<v Speaker 1>Expiring group memberships? How does that work?

165
00:08:30.680 --> 00:08:33.600
<v Speaker 2>It came in with Windows Server twenty sixteen. It uses

166
00:08:33.639 --> 00:08:37.320
<v Speaker 2>something called expiring links for attributes like group membership. You

167
00:08:37.320 --> 00:08:39.919
<v Speaker 2>can basically add a user to a group, but set

168
00:08:39.919 --> 00:08:43.279
<v Speaker 2>a time to live and expiry date on that membership.

169
00:08:43.360 --> 00:08:46.480
<v Speaker 1>Oh nice, So temporary access grants become much easier to

170
00:08:46.559 --> 00:08:47.399
<v Speaker 1>manage exactly.

171
00:08:47.480 --> 00:08:51.720
<v Speaker 2>Think about contractors temporary project access instead of relying on

172
00:08:51.799 --> 00:08:55.000
<v Speaker 2>manual cleanup later, which often gets missed. The membership just

173
00:08:55.039 --> 00:08:57.879
<v Speaker 2>automatically disappears when the time is up. It's great for

174
00:08:57.960 --> 00:09:01.120
<v Speaker 2>enforcing least privilege and just another access.

175
00:09:01.039 --> 00:09:05.120
<v Speaker 1>That sounds incredibly useful for security hygiene. What about computer objects?

176
00:09:05.120 --> 00:09:07.360
<v Speaker 1>Anything specific there admins should be aware of.

177
00:09:07.559 --> 00:09:10.320
<v Speaker 2>There's a default setting that often catches people out, or

178
00:09:10.360 --> 00:09:13.840
<v Speaker 2>maybe they just don't realize the implication. By default, any

179
00:09:13.919 --> 00:09:16.480
<v Speaker 2>authenticated user in your domain can join up to ten

180
00:09:16.559 --> 00:09:18.559
<v Speaker 2>machines to active directory.

181
00:09:18.159 --> 00:09:20.480
<v Speaker 1>Ten machines, any user.

182
00:09:20.279 --> 00:09:23.279
<v Speaker 2>Any user. It's controlled by an attribute called MSDS machine

183
00:09:23.279 --> 00:09:26.519
<v Speaker 2>account quota on the domain object itself. The default value

184
00:09:26.559 --> 00:09:26.879
<v Speaker 2>is ten.

185
00:09:27.440 --> 00:09:29.759
<v Speaker 1>That seems potentially problematic.

186
00:09:29.879 --> 00:09:33.360
<v Speaker 2>It can be from a security standpoint. The strong recommendation

187
00:09:33.480 --> 00:09:35.440
<v Speaker 2>is to change that quota to zero.

188
00:09:35.440 --> 00:09:38.600
<v Speaker 1>So only privileged accounts can join computers.

189
00:09:38.559 --> 00:09:42.600
<v Speaker 2>Right domain admins, account operators, or specific accounts you delegate

190
00:09:42.639 --> 00:09:46.879
<v Speaker 2>the permission to. It stops unauthorized devices potentially being added

191
00:09:46.919 --> 00:09:50.320
<v Speaker 2>to your trusted domain environment. It's a simple change with

192
00:09:50.399 --> 00:09:52.039
<v Speaker 2>a significant security benefit.

193
00:09:52.120 --> 00:09:56.080
<v Speaker 1>Good tip. Okay, and sticking with device security local administrator

194
00:09:56.120 --> 00:09:59.960
<v Speaker 1>passwords on potentially thousands of machines. That's always been a nightmare,

195
00:10:00.159 --> 00:10:00.600
<v Speaker 1>hasn't it?

196
00:10:00.679 --> 00:10:05.480
<v Speaker 2>Oh? A massive headache trying to maintain unique, strong, regularly

197
00:10:05.559 --> 00:10:09.279
<v Speaker 2>changed local admin passwords across a fleet of workstations and

198
00:10:09.320 --> 00:10:13.559
<v Speaker 2>servers manually. It's basically impossible and a huge security risk.

199
00:10:13.679 --> 00:10:16.919
<v Speaker 2>If an attacker gets one local admin password and it's

200
00:10:16.960 --> 00:10:18.120
<v Speaker 2>reused everywhere.

201
00:10:17.799 --> 00:10:20.200
<v Speaker 1>They can move laterally across the network very easily, past

202
00:10:20.240 --> 00:10:21.440
<v Speaker 1>the hash attacks and so on.

203
00:10:21.600 --> 00:10:25.919
<v Speaker 2>Exactly. That's where LAPS comes in the Local Administrator Password Solution.

204
00:10:26.399 --> 00:10:29.840
<v Speaker 2>It's a free Microsoft tool now even built into Windows.

205
00:10:29.519 --> 00:10:31.360
<v Speaker 1>And LAPS solves this how.

206
00:10:31.360 --> 00:10:34.440
<v Speaker 2>It automatically manages the password for the built in local

207
00:10:34.440 --> 00:10:38.399
<v Speaker 2>administrator account on domain joint machines. It generates a unique,

208
00:10:38.480 --> 00:10:42.320
<v Speaker 2>complex password for each machine, stores it securely within specific

209
00:10:42.360 --> 00:10:45.320
<v Speaker 2>attributes on the computer object in active directory.

210
00:10:45.639 --> 00:10:47.080
<v Speaker 1>Which attributes are those.

211
00:10:47.639 --> 00:10:52.159
<v Speaker 2>Ms and mcs at MBWD for password itself and ms

212
00:10:52.399 --> 00:10:55.240
<v Speaker 2>mcs at ampi ud expiration time for when it should

213
00:10:55.240 --> 00:10:56.480
<v Speaker 2>be automatically rotated again.

214
00:10:56.639 --> 00:10:59.720
<v Speaker 1>And how is access to those password attributes protect it?

215
00:11:00.000 --> 00:11:01.320
<v Speaker 1>I want just anyone reading them?

216
00:11:01.440 --> 00:11:05.559
<v Speaker 2>No, absolutely not. Access is tightly controlled, typically using something

217
00:11:05.600 --> 00:11:09.080
<v Speaker 2>called a filtered attribute set in AD or just standard

218
00:11:09.080 --> 00:11:13.600
<v Speaker 2>AD permissions. Usually only domain admins or maybe dedicated helpdesk

219
00:11:13.720 --> 00:11:17.840
<v Speaker 2>peers you explicitly authorize can read those passwords. So an

220
00:11:17.840 --> 00:11:21.320
<v Speaker 2>authorized admin needs the local admin password for a specific machine.

221
00:11:21.480 --> 00:11:24.480
<v Speaker 2>The query ad get the current unique password, use it,

222
00:11:24.759 --> 00:11:26.840
<v Speaker 2>and LAPS will rotate it again later.

223
00:11:26.960 --> 00:11:30.399
<v Speaker 1>That completely breaks the reused password problem and makes lateral

224
00:11:30.440 --> 00:11:31.519
<v Speaker 1>movement much harder.

225
00:11:31.559 --> 00:11:34.720
<v Speaker 2>It's a fundamental security improvement for endpoints. Honestly, if you're

226
00:11:34.759 --> 00:11:36.600
<v Speaker 2>running AD, you should be using LAPS.

227
00:11:36.960 --> 00:11:42.440
<v Speaker 1>Okay, LAPS expiring memberships, controlling machine account quotas great practical tips.

228
00:11:43.000 --> 00:11:46.039
<v Speaker 1>But active directory isn't just living safely inside the corporate

229
00:11:46.039 --> 00:11:49.720
<v Speaker 1>network anymore. Is it the cloud, the Internet, It's everywhere.

230
00:11:50.279 --> 00:11:53.360
<v Speaker 1>How does AD fit into this hybrid world?

231
00:11:53.519 --> 00:11:56.080
<v Speaker 2>That's the big evolution, isn't it. We've moved firmly into

232
00:11:56.120 --> 00:11:59.120
<v Speaker 2>the hybrid identity era. Your on premises active director is

233
00:11:59.200 --> 00:12:02.120
<v Speaker 2>very often connected as you're Active directory now called Microsoft

234
00:12:02.279 --> 00:12:05.480
<v Speaker 2>entra Id. But the concept's the same. Identity becomes a

235
00:12:05.519 --> 00:12:06.840
<v Speaker 2>new security perimeter and.

236
00:12:06.759 --> 00:12:09.600
<v Speaker 1>The protocols change too. Right on prem we had Carbero's

237
00:12:09.679 --> 00:12:11.960
<v Speaker 1>and TLM. What about the cloud exactly?

238
00:12:11.960 --> 00:12:14.279
<v Speaker 2>Cloud and web applications speak a different language. They use

239
00:12:14.279 --> 00:12:18.279
<v Speaker 2>open standards like ws Federation, SML two point zero open

240
00:12:18.279 --> 00:12:21.759
<v Speaker 2>a D connect, so bridging that gap connecting your established

241
00:12:21.759 --> 00:12:24.000
<v Speaker 2>on prem identity with these cloud services. That's the core

242
00:12:24.080 --> 00:12:25.200
<v Speaker 2>challenge of hybrid identity.

243
00:12:25.360 --> 00:12:27.399
<v Speaker 1>So how do you actually connect them? What are the

244
00:12:27.399 --> 00:12:30.600
<v Speaker 1>main ways to handle authentication when you link on PREMAD

245
00:12:30.799 --> 00:12:31.759
<v Speaker 1>with azure AD.

246
00:12:32.399 --> 00:12:36.200
<v Speaker 2>They're essentially three main methods provided by Microsoft Azure AD connect.

247
00:12:36.679 --> 00:12:40.200
<v Speaker 2>The default and usually recommended method is password hash sync

248
00:12:40.399 --> 00:12:41.240
<v Speaker 2>or PHS.

249
00:12:41.480 --> 00:12:45.639
<v Speaker 1>Okay, synking password hashes to the cloud. How secure is that? Really?

250
00:12:46.200 --> 00:12:49.840
<v Speaker 2>That's the crucial point to understand. BHS does not sync

251
00:12:49.919 --> 00:12:54.519
<v Speaker 2>your actual NTLM password hash one stored in AD. Instead,

252
00:12:54.919 --> 00:12:57.879
<v Speaker 2>it takes that hash, hashes it again using SAHA two

253
00:12:57.879 --> 00:13:01.559
<v Speaker 2>fifty six, and sinks that result hash of the hash

254
00:13:01.759 --> 00:13:02.559
<v Speaker 2>to azure.

255
00:13:02.279 --> 00:13:05.039
<v Speaker 1>Ad ah, so the hash stored in the cloud can't

256
00:13:05.080 --> 00:13:07.600
<v Speaker 1>be used directly for pass the hash attacks against your

257
00:13:07.600 --> 00:13:08.399
<v Speaker 1>on prem AD.

258
00:13:08.360 --> 00:13:11.120
<v Speaker 2>Correct It protects your on prem credentials. Azure AD handles

259
00:13:11.159 --> 00:13:14.200
<v Speaker 2>the cloud authentication using the synchronized half to a hash.

260
00:13:14.639 --> 00:13:19.039
<v Speaker 2>It's surprisingly secure and also enables features like leaked credential

261
00:13:19.120 --> 00:13:22.080
<v Speaker 2>detection in azure AD. It's the simplest, most resilient option

262
00:13:22.159 --> 00:13:23.240
<v Speaker 2>for most organizations.

263
00:13:23.399 --> 00:13:26.120
<v Speaker 1>Okay, PHS is the default. What are the other options?

264
00:13:26.159 --> 00:13:30.320
<v Speaker 2>The second is pass through authentication or PTA. With PTA,

265
00:13:30.559 --> 00:13:33.879
<v Speaker 2>you install lightweight agents on servers inside your network. When

266
00:13:33.879 --> 00:13:36.480
<v Speaker 2>a user tries to authenticate to azure AD, azure ad

267
00:13:36.559 --> 00:13:39.600
<v Speaker 2>sends the credential validation request back down to these agents.

268
00:13:39.320 --> 00:13:41.960
<v Speaker 1>And the agents validate the password directly against your on

269
00:13:42.080 --> 00:13:43.840
<v Speaker 1>prem active directory.

270
00:13:43.679 --> 00:13:46.879
<v Speaker 2>Exactly the password validation happens on your network. It gives

271
00:13:46.919 --> 00:13:49.919
<v Speaker 2>you that direct on prem audit trail and control, maybe

272
00:13:49.960 --> 00:13:52.720
<v Speaker 2>if you have specific security policies that must be enforced

273
00:13:52.720 --> 00:13:55.559
<v Speaker 2>by AD itself during the log in. It provides single

274
00:13:55.559 --> 00:13:58.360
<v Speaker 2>sign on two, but it does rely on connectivity to

275
00:13:58.360 --> 00:13:59.279
<v Speaker 2>those agents.

276
00:13:59.000 --> 00:14:01.240
<v Speaker 1>Right adds a dependence and the third option.

277
00:14:01.440 --> 00:14:04.919
<v Speaker 2>The third is the more traditional approach, Active directory Federation

278
00:14:05.000 --> 00:14:09.799
<v Speaker 2>Services or ADFS. This involves running your own federation servers

279
00:14:09.799 --> 00:14:14.159
<v Speaker 2>on premises, usually with Web application proxy servers in a DMZ.

280
00:14:13.919 --> 00:14:15.519
<v Speaker 1>Or infrastructure to manage.

281
00:14:15.360 --> 00:14:20.240
<v Speaker 2>Definitely more infrastructure. ADFS handles the authentication requests issue SAML

282
00:14:20.320 --> 00:14:23.720
<v Speaker 2>tokens and gives you the most control over the authentication process,

283
00:14:24.039 --> 00:14:27.919
<v Speaker 2>custom claims, rules, branding, potentially integrating with third party MJ

284
00:14:28.080 --> 00:14:32.360
<v Speaker 2>providers on prem It's powerful, but complex compared to PHS

285
00:14:32.480 --> 00:14:33.360
<v Speaker 2>or PTA.

286
00:14:33.240 --> 00:14:37.120
<v Speaker 1>So PHS for simplicity and resilience PTA for on prem

287
00:14:37.200 --> 00:14:41.159
<v Speaker 1>validation with less infra than adfs and ADFS for maximum

288
00:14:41.159 --> 00:14:45.519
<v Speaker 1>control and complex scenarios. Clear Now, once users are authenticating

289
00:14:45.559 --> 00:14:48.559
<v Speaker 1>to cloud apps via azure AD, how do you control

290
00:14:48.600 --> 00:14:51.679
<v Speaker 1>what they can access and under what conditions? Just using

291
00:14:51.720 --> 00:14:54.200
<v Speaker 1>groups feels a bit basic for the cloud.

292
00:14:54.600 --> 00:14:58.120
<v Speaker 2>It is basic and often insufficient. This is where conditional

293
00:14:58.159 --> 00:15:03.559
<v Speaker 2>access in azure AD, specifically azure AD Premium, becomes absolutely essential.

294
00:15:03.799 --> 00:15:05.919
<v Speaker 2>It's a complete game changer for cloud security.

295
00:15:06.000 --> 00:15:07.360
<v Speaker 1>What makes it a game changer.

296
00:15:07.120 --> 00:15:11.200
<v Speaker 2>It lets you define granular attribute based access policies. You

297
00:15:11.240 --> 00:15:15.120
<v Speaker 2>move beyond just is this user in this group? Instead

298
00:15:15.360 --> 00:15:18.879
<v Speaker 2>you make access decisions based on real time signals and conditions.

299
00:15:19.080 --> 00:15:21.440
<v Speaker 2>What kind of signals things like the user's sign in risk?

300
00:15:21.559 --> 00:15:24.120
<v Speaker 2>Is azure AD detecting anything suspicious about this log in?

301
00:15:24.600 --> 00:15:26.960
<v Speaker 2>The state of the device they're using, is compliant with

302
00:15:26.960 --> 00:15:30.399
<v Speaker 2>your policies? Is at hybrid azure AD join their physical

303
00:15:30.399 --> 00:15:33.519
<v Speaker 2>location based on IP address, even the specific application they're

304
00:15:33.519 --> 00:15:35.519
<v Speaker 2>trying to access or the client app they're using.

305
00:15:35.600 --> 00:15:38.279
<v Speaker 1>Okay, so you gather all that context, than what controls

306
00:15:38.320 --> 00:15:38.559
<v Speaker 1>can you.

307
00:15:38.559 --> 00:15:42.399
<v Speaker 2>Apply based on those conditions? You can enforce specific controls.

308
00:15:42.799 --> 00:15:46.480
<v Speaker 2>You can simply allow access or block it entirely. More commonly,

309
00:15:46.519 --> 00:15:50.720
<v Speaker 2>you'd require multi factor authentication MFA, or maybe force them

310
00:15:50.720 --> 00:15:53.480
<v Speaker 2>to accept terms of use or require the device to

311
00:15:53.480 --> 00:15:56.759
<v Speaker 2>be marked as compliant by in tune. You can even

312
00:15:56.799 --> 00:16:00.320
<v Speaker 2>get really granular, like limiting sessions and share points, change

313
00:16:00.360 --> 00:16:03.080
<v Speaker 2>online to be browser only, no downloads allowed.

314
00:16:03.200 --> 00:16:05.159
<v Speaker 1>Wow, that's incredibly fine grain control.

315
00:16:05.240 --> 00:16:08.639
<v Speaker 2>It is the key insight, or maybe the default state

316
00:16:08.720 --> 00:16:11.399
<v Speaker 2>you need to fight against is that without conditional access,

317
00:16:11.799 --> 00:16:15.279
<v Speaker 2>pretty much everyone can access everything from anywhere at any

318
00:16:15.320 --> 00:16:18.639
<v Speaker 2>time once they authenticate. Conditional access is how you implement

319
00:16:18.759 --> 00:16:23.320
<v Speaker 2>zero trust principles, verify explicitly, use least privileged access, assume breach.

320
00:16:23.720 --> 00:16:26.360
<v Speaker 1>And you mentioned what f tool That sounds useful for

321
00:16:26.399 --> 00:16:27.519
<v Speaker 1>not locking yourself out.

322
00:16:27.559 --> 00:16:30.159
<v Speaker 2>Oh, it's a lifesaver. Before you enable a new policy,

323
00:16:30.240 --> 00:16:32.200
<v Speaker 2>you can use the what if tool to select a user,

324
00:16:32.279 --> 00:16:35.639
<v Speaker 2>select an application, maybe assimulate certain conditions like location or

325
00:16:35.679 --> 00:16:39.039
<v Speaker 2>device state, and see exactly which conditional access policies would

326
00:16:39.039 --> 00:16:41.519
<v Speaker 2>apply and what the outcome would be. It helps you

327
00:16:41.600 --> 00:16:44.440
<v Speaker 2>test and validate before impacting real users.

328
00:16:44.799 --> 00:16:49.240
<v Speaker 1>Essential for complex policy sets. Okay, conditional access secures the

329
00:16:49.240 --> 00:16:52.799
<v Speaker 1>front door. What about monitoring the health of this whole

330
00:16:52.879 --> 00:16:54.279
<v Speaker 1>hybrid identity setup.

331
00:16:54.519 --> 00:16:56.879
<v Speaker 2>That's where as your ad connect Health comes in. It's

332
00:16:56.879 --> 00:16:59.600
<v Speaker 2>a monitoring service with agents you install in your critical

333
00:16:59.639 --> 00:17:04.319
<v Speaker 2>identity infrastructure, your on prem domain controllers, your ADFS servers

334
00:17:04.319 --> 00:17:06.960
<v Speaker 2>if you have them, and the Azure ad connects sinc

335
00:17:07.000 --> 00:17:07.759
<v Speaker 2>server itself, and.

336
00:17:07.799 --> 00:17:09.680
<v Speaker 1>It gives you visibility into their.

337
00:17:09.559 --> 00:17:14.640
<v Speaker 2>Health, performance, replication status, synchronization errors. It provides alerts and

338
00:17:14.680 --> 00:17:18.960
<v Speaker 2>insights into potential problems. Basically, it helps you proactively maintain

339
00:17:19.359 --> 00:17:23.039
<v Speaker 2>the availability and performance of that crucial bridge between your

340
00:17:23.039 --> 00:17:24.920
<v Speaker 2>on premises world and the cloud.

341
00:17:25.240 --> 00:17:29.319
<v Speaker 1>So keeping the identity infrastructure healthy good. One more area

342
00:17:29.480 --> 00:17:33.359
<v Speaker 1>especially critical for security privileged accounts, those admin accounts with

343
00:17:33.400 --> 00:17:36.799
<v Speaker 1>powerful permissions. How do we manage those better in the cloud.

344
00:17:36.960 --> 00:17:39.480
<v Speaker 2>This is another area where azure ad offers a massive

345
00:17:39.480 --> 00:17:44.200
<v Speaker 2>improvement over traditional approaches using Privileged Identity Management or PIME.

346
00:17:44.640 --> 00:17:47.119
<v Speaker 2>It requires Azure ad Premium P two licensing.

347
00:17:47.200 --> 00:17:49.839
<v Speaker 1>Okay, PIME, what's the core problem it solves?

348
00:17:50.119 --> 00:17:55.160
<v Speaker 2>The problem is persistent standing administrative privileges. Accounts that are

349
00:17:55.240 --> 00:17:58.920
<v Speaker 2>always domain admins are always global admins in Azure AD.

350
00:17:59.799 --> 00:18:04.119
<v Speaker 2>These are prying targets for attackers. If one gets compromised,

351
00:18:04.160 --> 00:18:05.000
<v Speaker 2>the damage can be.

352
00:18:04.960 --> 00:18:09.240
<v Speaker 1>Catastrophic, so PI aims to reduce that standing access precisely.

353
00:18:09.680 --> 00:18:13.720
<v Speaker 2>PI provides just in time got access to privileged roles.

354
00:18:14.519 --> 00:18:17.039
<v Speaker 2>Instead of being a permanent admin, a user is made

355
00:18:17.039 --> 00:18:19.839
<v Speaker 2>eligible for an admin role when they actually need to

356
00:18:19.839 --> 00:18:24.119
<v Speaker 2>perform administrative tasks. They go through an activation process in BIME.

357
00:18:23.960 --> 00:18:25.279
<v Speaker 1>Like requesting access.

358
00:18:25.400 --> 00:18:27.920
<v Speaker 2>Yes, they request to activate their role. Maybe they need

359
00:18:28.000 --> 00:18:31.640
<v Speaker 2>to provide justification, perhaps go through an approval workflow, maybe

360
00:18:31.680 --> 00:18:34.759
<v Speaker 2>even satisfy an MFA check. Again. If approved, they get

361
00:18:34.799 --> 00:18:37.720
<v Speaker 2>the admin privileges, but only for a limited time, say

362
00:18:37.880 --> 00:18:39.559
<v Speaker 2>four hours, eight hours, whatever.

363
00:18:39.319 --> 00:18:42.319
<v Speaker 1>You can figure. And after that time expires, their privileges.

364
00:18:41.920 --> 00:18:44.160
<v Speaker 2>Are automatically revoked. They go back to being just a

365
00:18:44.200 --> 00:18:46.920
<v Speaker 2>standard user until they need to activate the role again.

366
00:18:47.000 --> 00:18:50.359
<v Speaker 1>So it enforces least privilege by default and drastically shrinks

367
00:18:50.400 --> 00:18:53.200
<v Speaker 1>the window of opportunity for attackers. If an admin account

368
00:18:53.240 --> 00:18:54.519
<v Speaker 1>is compromised.

369
00:18:54.240 --> 00:18:57.839
<v Speaker 2>Exactly, it reduces the overall risk, significantly, provides a clear

370
00:18:58.000 --> 00:19:01.279
<v Speaker 2>audit trail of who activated what role, and really changes

371
00:19:01.319 --> 00:19:04.480
<v Speaker 2>the mindset around administrative access. It moves from always on

372
00:19:04.640 --> 00:19:05.559
<v Speaker 2>to on demand.

373
00:19:05.759 --> 00:19:10.319
<v Speaker 1>Wow, Okay, what a journey we've gone from the absolute foundations,

374
00:19:10.359 --> 00:19:13.960
<v Speaker 1>those critical choices about domains and forests, through managing the

375
00:19:14.039 --> 00:19:19.200
<v Speaker 1>dcs themselves, rodcs cloning, then optimizing the everyday user in

376
00:19:19.240 --> 00:19:23.359
<v Speaker 1>computer management with things like expiring memberships and laps, and

377
00:19:23.480 --> 00:19:28.000
<v Speaker 1>finally landing squarely in the hybrid cloud with PHS PTA adfs.

378
00:19:28.119 --> 00:19:31.799
<v Speaker 1>The power of conditional access and securing privileged access with

379
00:19:31.880 --> 00:19:35.039
<v Speaker 1>PM active directory has definitely not been standing still, not

380
00:19:35.119 --> 00:19:35.400
<v Speaker 1>at all.

381
00:19:35.440 --> 00:19:38.400
<v Speaker 2>It's constantly evolving in understanding that whole picture, the on

382
00:19:38.440 --> 00:19:41.759
<v Speaker 2>prem structure, how to manage the core components efficiently and securely,

383
00:19:41.759 --> 00:19:44.319
<v Speaker 2>and then how to embrace these modern cloud security concepts

384
00:19:44.519 --> 00:19:47.839
<v Speaker 2>like conditional access and PM. That's really crucial, that ability

385
00:19:47.880 --> 00:19:50.680
<v Speaker 2>to bridge on prem in cloud identity. It's not just

386
00:19:50.680 --> 00:19:52.599
<v Speaker 2>a nice to have anymore, is it. It's pretty much

387
00:19:52.640 --> 00:19:54.759
<v Speaker 2>the key skill for identity admins today.

388
00:19:54.960 --> 00:19:59.039
<v Speaker 1>Absolutely. So to wrap up, here's maybe a provocative thought

389
00:19:59.039 --> 00:20:01.960
<v Speaker 1>for you to consider f this step dive. Even as

390
00:20:02.000 --> 00:20:05.680
<v Speaker 1>we see more cloud native identity solutions emerge, think about

391
00:20:05.680 --> 00:20:10.039
<v Speaker 1>how those fundamental concepts AD pioneered decades ago, things like

392
00:20:10.200 --> 00:20:14.799
<v Speaker 1>trust relationships, hierarchical structures, the need for secure access based

393
00:20:14.799 --> 00:20:17.799
<v Speaker 1>on identity. How those ideas continue to shape and inform

394
00:20:17.839 --> 00:20:20.680
<v Speaker 1>how we design identity security in entirely new cloud and

395
00:20:20.799 --> 00:20:23.960
<v Speaker 1>hybrid environments. It seems the more things change, the more

396
00:20:24.000 --> 00:20:26.519
<v Speaker 1>those core principles stick around, even if the tools in

397
00:20:26.559 --> 00:20:27.720
<v Speaker 1>tech look completely different.

398
00:20:27.799 --> 00:20:29.599
<v Speaker 2>That's a great point. The fundamentals endure.

399
00:20:29.920 --> 00:20:31.720
<v Speaker 1>Thank you so much for joining us on this steep

400
00:20:31.799 --> 00:20:34.519
<v Speaker 1>dive today. We really hope this gave you some valuable insights.

401
00:20:34.799 --> 00:20:38.640
<v Speaker 1>Keep learning, keep exploring that ever evolving world of identity management.