Speaker 1: Welcome to the deep dive. You know, we often think
Speaker 1: about our digital identities, but maybe not the hidden foundations,
Speaker 1: the systems that really know who we are online, what
Speaker 1: we can access. It can get complex, but it's incredibly vital,
Speaker 1: it really is. Today we're taking a deep dive into
Speaker 1: Sanderbrickauer's Active Directory Administration Cookbook. Our mission to pull out
Speaker 1: the absolute must know nuggets about Active directory. You know,
Speaker 1: from its core on prem structures right through to how
Speaker 1: it fits into this modern hybrid cloud world. Think of
Speaker 1: it as your shortcut to really understanding the backbone of
Speaker 1: enterprise identity exactly.
Speaker 2: And it's not just about the peck jargon, is it. It's
Speaker 2: really about understanding the why behind the big design choices,
Speaker 2: the security decisions, and identity management, trying to make sense
Speaker 2: of what can feel like a pretty overwhelming landscape. Sometimes.
Speaker 1: Okay, let's get into it then, Active Directory. Some might
Speaker 1: think it sounds a bit well old school, but its
Speaker 1: core ideas are still incredibly relevant even if you're mainly
Speaker 1: in the cloud. Now, let's start right at the beginning.
Speaker 1: Domains and forests, these fundamental building blocks. When does adding
Speaker 1: a whole new domain actually make sense?
Speaker 2: That's a great starting point. The rationale for a new
Speaker 2: domain usually comes down to needing very specific boundaries. So
Speaker 2: maybe you need a totally separate DNS domain name, like
Speaker 2: for a new business venture or something. Okay, that also
Speaker 2: lets you limit how eighty integrated DNS zones replicate, keep
Speaker 2: that DNS info just within that domain, and perhaps most importantly,
Speaker 2: it gives you a boundary for different password policies, different
Speaker 2: account logout rules, or maybe shielding sensitive accounts that you
Speaker 2: don't want visible everywhere else.
Speaker 1: Right, So fine grain control within that boundary. But Microsoft
Speaker 1: often advises keeping things simple, don't they? What are the
Speaker 1: kind of downsides or the hidden costs of adding that
Speaker 1: new domain?
Speaker 2: They definitely advise simplicity, and for good reason. Look, adding
Speaker 2: a new domain isn't trivial. You're immediately talking about needing
Speaker 2: at least two extra domain control right, redundancy exactly, more
Speaker 2: active directory trust to manage between the domains, and just
Speaker 2: generally a bigger administrative workload. It's complexity.
Speaker 1: Okay, so that's the domain boundary. If that creates one level,
Speaker 1: what about a forest that sounds like an even bigger step.
Speaker 1: Where does that fit in?
Speaker 2: It's a much bigger step. Yes, a new active directory
Speaker 2: forest is essentially a completely new independent AD environment. By default,
Speaker 2: there's no relationship, no trust with any existing forests.
Speaker 1: You might have total separation.
Speaker 2: Total separation. It creates the strongest possible boundary. Think about
Speaker 2: things like the schema and configuration petitions in AD. If
Speaker 2: you have an application that needs specific schema changes, maybe
Speaker 2: something that could conflict with your main AD.
Speaker 1: Like a legacy app or something really cutting.
Speaker 2: Edge precisely, or maybe you need absolute separation for the
Speaker 2: global catalog. You don't want certain object details replicating across
Speaker 2: that boundary. The forest is really your ultimate security and
Speaker 2: administrative boundary. It's also the go to structure if you're
Speaker 2: planning for say acquisition or to vestiture down the line,
Speaker 2: you know you'll need to cleanly separate things later.
Speaker 1: That makes sense for M and A heavy businesses, but
Speaker 1: doubling the admin effort difficulty sharing resources like address lists
Speaker 1: or apps, that sounds like a serious commitment.
Speaker 2: Oh it is. You really have to weigh the need
Speaker 2: for that absolute separation against the ongoing operational cost and complexity.
Speaker 2: It's a major architectural decision with long term consequences.
Speaker 1: It really highlights those critical choices admins make early on,
Speaker 1: doesn't it decisions that just ripple through the whole life cycle?
Speaker 1: No wonder. Sanderberkauer calls himself an active directory of ficionado.
Speaker 1: These are big.
Speaker 2: Calls, absolutely foundational stuff.
Speaker 1: So once you have that structure, that blueprint, you need
Speaker 1: the actual servers running at the domain controllers. These are
Speaker 1: like the identity castles right offering LDAP, corberos, the core services.
Speaker 1: What's key to managing these today, especially since they're not
Speaker 1: always physical boxes anymore.
Speaker 2: That's right, Managing dcs involves, you know, the basics, promoting
Speaker 2: a server to become a DC and solling the ad
Speaker 2: domain services role and then demoting it when it's no
Speaker 2: longer needed. And yeah, these days they're very often virtual machines, which.
Speaker 1: Brings its own considerations. I imagine it does.
Speaker 2: Things like snapshotting clumbing, which we can touch on. But
Speaker 2: one really interesting type of DC is the read only
Speaker 2: domain controller.
Speaker 1: The RDC AH Yes, rodcs. I know. They're often used
Speaker 1: in places like branch offices or perimeter networks. What makes
Speaker 1: them special from a security angle?
Speaker 2: Their main purpose is security in less secure locations. They
Speaker 2: hold a read only copy of the eighty database and
Speaker 2: the NSYS vol share. Crucially, they use what's called scoped reputation,
Speaker 2: meaning you can figure exactly which user and computer accounts
Speaker 2: and importantly, which passwords are allowed to be cased on
Speaker 2: that RODC, so only the necessary accounts for that location
Speaker 2: are stored there. If it gets compromised, the blast radius
Speaker 2: is much.
Speaker 1: Smaller because sensitive admin accounts, for instance, wouldn't be cashed there.
Speaker 2: Hopefully ideally know you can figure password replication policies to
Speaker 2: prevent that. Plus they have a unique security feature related
Speaker 2: to Corberos. Each RODC gets its own special care BTG account.
Speaker 2: It looks like CARABGGT followed by some numbers.
Speaker 1: Right, the standard Carbero's Ticket Granting Service account is just krebtwgt.
Speaker 2: Exactly, this unique RODC account is used to encrypt Carbero's
Speaker 2: tickets issued by that RODC, So if someone physically steals
Speaker 2: an RODC, they can't use.
Speaker 1: Its krabtgkey to decrypt tickets and impersonate users across the
Speaker 1: whole domain.
Speaker 2: Precisely, they can only compromise the tickets issued by that
Speaker 2: specific RODC, and only for the account's casturre it. It
Speaker 2: significantly contains the damage compared to compromising a writeable DC.
Speaker 1: That's a clever bit of security design for those edge scenarios. Okay,
Speaker 1: RDCs helps secure distributed spots, but what about just getting
Speaker 1: new dcs up and running quickly? You mentioned virtualization brings changes.
Speaker 1: Is there anything there?
Speaker 2: Yes? Absolutely, Speed and consistency are key, especially in virtual environments.
Speaker 2: And this is where domain controller cloning comes in. It's
Speaker 2: a feature that lets you well clone existing virtual.
Speaker 1: Dcs, clone a domain controller. That sounds risky. Didn't That
Speaker 1: used to cause major problems?
Speaker 2: It absolutely used to be a huge no. No. Cloning
Speaker 2: could lead to duplicate security identifiers, sids, USN, rollback issues,
Speaker 2: all sorts of nightmares. But starting with Windowserver twenty twelve,
Speaker 2: they introduced safe cloning.
Speaker 1: Okay, how does that work safely?
Speaker 2: The magic ingredient is a hypervisor feature called VM generation ID.
Speaker 2: Most modern hypervisors support this now hyper v.
Speaker 1: VMware And what does VM generation ID do.
Speaker 2: It's basically a one hundred and twenty eight bit random
Speaker 2: number that's stored in the virtual machin's memory, but also
Speaker 2: gets written into the active directory database by the DC.
Speaker 2: If you restore a snapshot of a DC, or if
Speaker 2: you clone a vhdx file, the hypervisor generates a new
Speaker 2: VM generation ID.
Speaker 1: AH, so the DC boots up, sees the ID in
Speaker 1: memory doesn't match the one in its database exactly.
Speaker 2: It knows something major happened to roll back or a clone.
Speaker 2: It then takes safety precautions like invalidating its local rid
Speaker 2: pool to prevent duplicate sids, and if it's a clone,
Speaker 2: it goes through a process to make itself unique. It
Speaker 2: essentially allows safe rapid deployment of new dcs from a
Speaker 2: template image, as long as the source DC is properly
Speaker 2: prepared and doesn't hold certain sensitive FSMO rolls like the
Speaker 2: PDC emulator.
Speaker 1: That VM generation ID is a fantastic example of AD
Speaker 1: adapting to virtualization, really neat tech. So okay, let's loop
Speaker 1: back to the RODC for a second. If one does
Speaker 1: get compromised, say stolen from a branch office, how fast
Speaker 1: can you lock it down?
Speaker 2: The recovery is designed to be quick because it has
Speaker 2: that unique care. BTG account admins can immediately reset the
Speaker 2: password for that specific account an ad they can also
Speaker 2: trigger a password reset for all the user accounts whose
Speaker 2: credentials might have been cached on that RODC.
Speaker 1: So you invalidate its ability to issue tickets and reset
Speaker 1: potentially exposed passwords.
Speaker 2: Right, it renders the stolen device pretty much useless from
Speaker 2: an AD perspective, very quickly, much faster and less impactful
Speaker 2: than losing a full writeable DC.
Speaker 1: Okay, makes sense. Let's shift gears a bit. Users, groups,
Speaker 1: computer objects. This is the daily grind for many AD admins,
Speaker 1: the bread and butter. What are some key things, maybe
Speaker 1: beyond the absolute basics, that help manage these effectively and
Speaker 1: securely well?
Speaker 2: PowerShell is obviously key for anything beyond simple one off
Speaker 2: tasks in the GI for automation bulk changes, it's essential.
Speaker 2: But AD itself has gained some interesting features. One I
Speaker 2: find particularly useful is expiring group memberships.
Speaker 1: Expiring group memberships? How does that work?
Speaker 2: It came in with Windows Server twenty sixteen. It uses
Speaker 2: something called expiring links for attributes like group membership. You
Speaker 2: can basically add a user to a group, but set
Speaker 2: a time to live and expiry date on that membership.
Speaker 1: Oh nice, So temporary access grants become much easier to
Speaker 1: manage exactly.
Speaker 2: Think about contractors temporary project access instead of relying on
Speaker 2: manual cleanup later, which often gets missed. The membership just
Speaker 2: automatically disappears when the time is up. It's great for
Speaker 2: enforcing least privilege and just another access.
Speaker 1: That sounds incredibly useful for security hygiene. What about computer objects?
Speaker 1: Anything specific there admins should be aware of.
Speaker 2: There's a default setting that often catches people out, or
Speaker 2: maybe they just don't realize the implication. By default, any
Speaker 2: authenticated user in your domain can join up to ten
Speaker 2: machines to active directory.
Speaker 1: Ten machines, any user.
Speaker 2: Any user. It's controlled by an attribute called MSDS machine
Speaker 2: account quota on the domain object itself. The default value
Speaker 2: is ten.
Speaker 1: That seems potentially problematic.
Speaker 2: It can be from a security standpoint. The strong recommendation
Speaker 2: is to change that quota to zero.
Speaker 1: So only privileged accounts can join computers.
Speaker 2: Right domain admins, account operators, or specific accounts you delegate
Speaker 2: the permission to. It stops unauthorized devices potentially being added
Speaker 2: to your trusted domain environment. It's a simple change with
Speaker 2: a significant security benefit.
Speaker 1: Good tip. Okay, and sticking with device security local administrator
Speaker 1: passwords on potentially thousands of machines. That's always been a nightmare,
Speaker 1: hasn't it?
Speaker 2: Oh? A massive headache trying to maintain unique, strong, regularly
Speaker 2: changed local admin passwords across a fleet of workstations and
Speaker 2: servers manually. It's basically impossible and a huge security risk.
Speaker 2: If an attacker gets one local admin password and it's
Speaker 2: reused everywhere.
Speaker 1: They can move laterally across the network very easily, past
Speaker 1: the hash attacks and so on.
Speaker 2: Exactly. That's where LAPS comes in the Local Administrator Password Solution.
Speaker 2: It's a free Microsoft tool now even built into Windows.
Speaker 1: And LAPS solves this how.
Speaker 2: It automatically manages the password for the built in local
Speaker 2: administrator account on domain joint machines. It generates a unique,
Speaker 2: complex password for each machine, stores it securely within specific
Speaker 2: attributes on the computer object in active directory.
Speaker 1: Which attributes are those.
Speaker 2: Ms and mcs at MBWD for password itself and ms
Speaker 2: mcs at ampi ud expiration time for when it should
Speaker 2: be automatically rotated again.
Speaker 1: And how is access to those password attributes protect it?
Speaker 1: I want just anyone reading them?
Speaker 2: No, absolutely not. Access is tightly controlled, typically using something
Speaker 2: called a filtered attribute set in AD or just standard
Speaker 2: AD permissions. Usually only domain admins or maybe dedicated helpdesk
Speaker 2: peers you explicitly authorize can read those passwords. So an
Speaker 2: authorized admin needs the local admin password for a specific machine.
Speaker 2: The query ad get the current unique password, use it,
Speaker 2: and LAPS will rotate it again later.
Speaker 1: That completely breaks the reused password problem and makes lateral
Speaker 1: movement much harder.
Speaker 2: It's a fundamental security improvement for endpoints. Honestly, if you're
Speaker 2: running AD, you should be using LAPS.
Speaker 1: Okay, LAPS expiring memberships, controlling machine account quotas great practical tips.
Speaker 1: But active directory isn't just living safely inside the corporate
Speaker 1: network anymore. Is it the cloud, the Internet, It's everywhere.
Speaker 1: How does AD fit into this hybrid world?
Speaker 2: That's the big evolution, isn't it. We've moved firmly into
Speaker 2: the hybrid identity era. Your on premises active director is
Speaker 2: very often connected as you're Active directory now called Microsoft
Speaker 2: entra Id. But the concept's the same. Identity becomes a
Speaker 2: new security perimeter and.
Speaker 1: The protocols change too. Right on prem we had Carbero's
Speaker 1: and TLM. What about the cloud exactly?
Speaker 2: Cloud and web applications speak a different language. They use
Speaker 2: open standards like ws Federation, SML two point zero open
Speaker 2: a D connect, so bridging that gap connecting your established
Speaker 2: on prem identity with these cloud services. That's the core
Speaker 2: challenge of hybrid identity.
Speaker 1: So how do you actually connect them? What are the
Speaker 1: main ways to handle authentication when you link on PREMAD
Speaker 1: with azure AD.
Speaker 2: They're essentially three main methods provided by Microsoft Azure AD connect.
Speaker 2: The default and usually recommended method is password hash sync
Speaker 2: or PHS.
Speaker 1: Okay, synking password hashes to the cloud. How secure is that? Really?
Speaker 2: That's the crucial point to understand. BHS does not sync
Speaker 2: your actual NTLM password hash one stored in AD. Instead,
Speaker 2: it takes that hash, hashes it again using SAHA two
Speaker 2: fifty six, and sinks that result hash of the hash
Speaker 2: to azure.
Speaker 1: Ad ah, so the hash stored in the cloud can't
Speaker 1: be used directly for pass the hash attacks against your
Speaker 1: on prem AD.
Speaker 2: Correct It protects your on prem credentials. Azure AD handles
Speaker 2: the cloud authentication using the synchronized half to a hash.
Speaker 2: It's surprisingly secure and also enables features like leaked credential
Speaker 2: detection in azure AD. It's the simplest, most resilient option
Speaker 2: for most organizations.
Speaker 1: Okay, PHS is the default. What are the other options?
Speaker 2: The second is pass through authentication or PTA. With PTA,
Speaker 2: you install lightweight agents on servers inside your network. When
Speaker 2: a user tries to authenticate to azure AD, azure ad
Speaker 2: sends the credential validation request back down to these agents.
Speaker 1: And the agents validate the password directly against your on
Speaker 1: prem active directory.
Speaker 2: Exactly the password validation happens on your network. It gives
Speaker 2: you that direct on prem audit trail and control, maybe
Speaker 2: if you have specific security policies that must be enforced
Speaker 2: by AD itself during the log in. It provides single
Speaker 2: sign on two, but it does rely on connectivity to
Speaker 2: those agents.
Speaker 1: Right adds a dependence and the third option.
Speaker 2: The third is the more traditional approach, Active directory Federation
Speaker 2: Services or ADFS. This involves running your own federation servers
Speaker 2: on premises, usually with Web application proxy servers in a DMZ.
Speaker 1: Or infrastructure to manage.
Speaker 2: Definitely more infrastructure. ADFS handles the authentication requests issue SAML
Speaker 2: tokens and gives you the most control over the authentication process,
Speaker 2: custom claims, rules, branding, potentially integrating with third party MJ
Speaker 2: providers on prem It's powerful, but complex compared to PHS
Speaker 2: or PTA.
Speaker 1: So PHS for simplicity and resilience PTA for on prem
Speaker 1: validation with less infra than adfs and ADFS for maximum
Speaker 1: control and complex scenarios. Clear Now, once users are authenticating
Speaker 1: to cloud apps via azure AD, how do you control
Speaker 1: what they can access and under what conditions? Just using
Speaker 1: groups feels a bit basic for the cloud.
Speaker 2: It is basic and often insufficient. This is where conditional
Speaker 2: access in azure AD, specifically azure AD Premium, becomes absolutely essential.
Speaker 2: It's a complete game changer for cloud security.
Speaker 1: What makes it a game changer.
Speaker 2: It lets you define granular attribute based access policies. You
Speaker 2: move beyond just is this user in this group? Instead
Speaker 2: you make access decisions based on real time signals and conditions.
Speaker 2: What kind of signals things like the user's sign in risk?
Speaker 2: Is azure AD detecting anything suspicious about this log in?
Speaker 2: The state of the device they're using, is compliant with
Speaker 2: your policies? Is at hybrid azure AD join their physical
Speaker 2: location based on IP address, even the specific application they're
Speaker 2: trying to access or the client app they're using.
Speaker 1: Okay, so you gather all that context, than what controls
Speaker 1: can you.
Speaker 2: Apply based on those conditions? You can enforce specific controls.
Speaker 2: You can simply allow access or block it entirely. More commonly,
Speaker 2: you'd require multi factor authentication MFA, or maybe force them
Speaker 2: to accept terms of use or require the device to
Speaker 2: be marked as compliant by in tune. You can even
Speaker 2: get really granular, like limiting sessions and share points, change
Speaker 2: online to be browser only, no downloads allowed.
Speaker 1: Wow, that's incredibly fine grain control.
Speaker 2: It is the key insight, or maybe the default state
Speaker 2: you need to fight against is that without conditional access,
Speaker 2: pretty much everyone can access everything from anywhere at any
Speaker 2: time once they authenticate. Conditional access is how you implement
Speaker 2: zero trust principles, verify explicitly, use least privileged access, assume breach.
Speaker 1: And you mentioned what f tool That sounds useful for
Speaker 1: not locking yourself out.
Speaker 2: Oh, it's a lifesaver. Before you enable a new policy,
Speaker 2: you can use the what if tool to select a user,
Speaker 2: select an application, maybe assimulate certain conditions like location or
Speaker 2: device state, and see exactly which conditional access policies would
Speaker 2: apply and what the outcome would be. It helps you
Speaker 2: test and validate before impacting real users.
Speaker 1: Essential for complex policy sets. Okay, conditional access secures the
Speaker 1: front door. What about monitoring the health of this whole
Speaker 1: hybrid identity setup.
Speaker 2: That's where as your ad connect Health comes in. It's
Speaker 2: a monitoring service with agents you install in your critical
Speaker 2: identity infrastructure, your on prem domain controllers, your ADFS servers
Speaker 2: if you have them, and the Azure ad connects sinc
Speaker 2: server itself, and.
Speaker 1: It gives you visibility into their.
Speaker 2: Health, performance, replication status, synchronization errors. It provides alerts and
Speaker 2: insights into potential problems. Basically, it helps you proactively maintain
Speaker 2: the availability and performance of that crucial bridge between your
Speaker 2: on premises world and the cloud.
Speaker 1: So keeping the identity infrastructure healthy good. One more area
Speaker 1: especially critical for security privileged accounts, those admin accounts with
Speaker 1: powerful permissions. How do we manage those better in the cloud.
Speaker 2: This is another area where azure ad offers a massive
Speaker 2: improvement over traditional approaches using Privileged Identity Management or PIME.
Speaker 2: It requires Azure ad Premium P two licensing.
Speaker 1: Okay, PIME, what's the core problem it solves?
Speaker 2: The problem is persistent standing administrative privileges. Accounts that are
Speaker 2: always domain admins are always global admins in Azure AD.
Speaker 2: These are prying targets for attackers. If one gets compromised,
Speaker 2: the damage can be.
Speaker 1: Catastrophic, so PI aims to reduce that standing access precisely.
Speaker 2: PI provides just in time got access to privileged roles.
Speaker 2: Instead of being a permanent admin, a user is made
Speaker 2: eligible for an admin role when they actually need to
Speaker 2: perform administrative tasks. They go through an activation process in BIME.
Speaker 1: Like requesting access.
Speaker 2: Yes, they request to activate their role. Maybe they need
Speaker 2: to provide justification, perhaps go through an approval workflow, maybe
Speaker 2: even satisfy an MFA check. Again. If approved, they get
Speaker 2: the admin privileges, but only for a limited time, say
Speaker 2: four hours, eight hours, whatever.
Speaker 1: You can figure. And after that time expires, their privileges.
Speaker 2: Are automatically revoked. They go back to being just a
Speaker 2: standard user until they need to activate the role again.
Speaker 1: So it enforces least privilege by default and drastically shrinks
Speaker 1: the window of opportunity for attackers. If an admin account
Speaker 1: is compromised.
Speaker 2: Exactly, it reduces the overall risk, significantly, provides a clear
Speaker 2: audit trail of who activated what role, and really changes
Speaker 2: the mindset around administrative access. It moves from always on
Speaker 2: to on demand.
Speaker 1: Wow, Okay, what a journey we've gone from the absolute foundations,
Speaker 1: those critical choices about domains and forests, through managing the
Speaker 1: dcs themselves, rodcs cloning, then optimizing the everyday user in
Speaker 1: computer management with things like expiring memberships and laps, and
Speaker 1: finally landing squarely in the hybrid cloud with PHS PTA adfs.
Speaker 1: The power of conditional access and securing privileged access with
Speaker 1: PM active directory has definitely not been standing still, not
Speaker 1: at all.
Speaker 2: It's constantly evolving in understanding that whole picture, the on
Speaker 2: prem structure, how to manage the core components efficiently and securely,
Speaker 2: and then how to embrace these modern cloud security concepts
Speaker 2: like conditional access and PM. That's really crucial, that ability
Speaker 2: to bridge on prem in cloud identity. It's not just
Speaker 2: a nice to have anymore, is it. It's pretty much
Speaker 2: the key skill for identity admins today.
Speaker 1: Absolutely. So to wrap up, here's maybe a provocative thought
Speaker 1: for you to consider f this step dive. Even as
Speaker 1: we see more cloud native identity solutions emerge, think about
Speaker 1: how those fundamental concepts AD pioneered decades ago, things like
Speaker 1: trust relationships, hierarchical structures, the need for secure access based
Speaker 1: on identity. How those ideas continue to shape and inform
Speaker 1: how we design identity security in entirely new cloud and
Speaker 1: hybrid environments. It seems the more things change, the more
Speaker 1: those core principles stick around, even if the tools in
Speaker 1: tech look completely different.
Speaker 2: That's a great point. The fundamentals endure.
Speaker 1: Thank you so much for joining us on this steep
Speaker 1: dive today. We really hope this gave you some valuable insights.
Speaker 1: Keep learning, keep exploring that ever evolving world of identity management.