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