In my post that covers my standard directory structure, I recommend using a third-level OU as the effective root of all non-domain controller members. "But," I can hear you saying, "what about all the computer objects that get created in the default Computers container?" To that, I say: block 'em. Do you have build procedures for new servers and workstations? Do you have agents or other utilities that need to be installed on all members? Do you have custom security or group policy settings that need to apply to certain computers? Do all devices need to undergo a security review before being joined to the domain? If so, this is the best first step to ensure all new computers are compliant before being put into production. Once you've established that there will be no creation in the default container, that logically means a few things: New objects must be intentionally created by either support personnel or approved automated systems. Elevated dir...

Just like everyone else, I think it is very common for the contribution of my role to go underappreciated. I can't count the number of times I've been in a meeting with a business unit or other team within the company and heard some version of, "Do we really need to involve the Active Directory team? I mean, it's just managing a few service accounts and groups. I feel like we can take care of that." Because of our track record (and those of some of those business units), my team is pretty fortunate to mostly get auto-approval from management to manage directory resources now, even when those questions come up. A recent situation reminded me why. A little background: we have a business unit that was spun up as part of a DevOps initiative several years ago. In that spirit, they requested elevated access over significant portions of the domain they requested. I fought back against the request, but was overruled by a senior director who shied from conflict of that...

This is one of those points of confusion I kind of hope you experience. The reason: if you have your security set up properly, as soon as someone hears the words "domain controller," they will assume they don't have access and need to contact a member of the directory services team. However, checking the operating system version for all domain controllers in a domain is very simple for any user. Simply open Active Directory Users and Computers , right-click on the domain root, then select Change Domain Controller . The major version will be listed in the DC Version column. Change Domain Controller box in ADUC If the requester needs a more specific version, they can still look it up themselves. Back in ADUC, simply look up the computer object and go to the Operating System tab. It will have version and build info that can easily be translated with a quick online search. Domain controller computer object Doing these lookups doesn't require any elevated...

Symptoms Out of nowhere, domain members start throwing errors about their trust relationship with the domain not working. You could also be receiving general logon errors by interactive users and service accounts. The behavior will likely be limited to one AD site, but will occur on seemingly random servers within that site. Resolution Check the drives where the NTDS database exists on all domain controllers in that domain. If any have filled up, expand them or clean them off, then reboot the affected servers. If you cannot log into the servers via console or RDP, try to force a shutdown through the hypervisor or chassis (if applicable). As a last resort, do a manual power-down via button or power cable, then boot up. See the Notes section for more details of this specific incident. Cause Normally, when a Windows machine does a domain authentication/authorization check, quite a few things happen in the background. One of those things is finding a working domain controller...

Symptoms This can manifest in many different ways. Here are some of the most common: Support personnel report they can't unlock or reset the password for a user even though the target user's account is in the same OU as many other accounts that are behaving normally. Support personnel report they can't change the membership of a group even though the target group is in the same OU as many other groups that are behaving normally. Support personnel report they can't modify an attribute for a user even though the target user's account is in the same OU as many other accounts that are behaving normally. The primary identifying characteristic of the situation described here is the resetting of the security of whatever object they're trying to modify. IE, you may be able to grant support personnel rights to modify it, and it will work, but the next time they go back to do the same, the permissions are missing again. To confirm the underlying issue is the on...

This is part of my ongoing AD Design series. Check here for primer on the intent. As mentioned in my last post, I'm going to assume a certain level of knowledge about Active Directory is held by the readers of this series. One of those assumptions is you can navigate the wizards necessary to promote a couple domain controllers and get a base domain up and running. Again, if that's outside of your abilities, there are many, many guides for that online. For this post, I'm going to assume you're starting with a brand new domain. It may seem elementary, but two of the most important things to consider in AD design are: How your configurations will affect existing systems within the domain.  How your configurations will affect future efforts within the environment. How long you've been managing domains and your knowledge of how your systems integrate with your domain will determine how well you're able to guess at those (and make no mistake, you are ...

Active Directory (AD) is one of the more flexible products provided by Microsoft. While they have spreadsheets and white papers for how many users should be in each on-prem Exchange database or how you should structure your site collections in SCCM, guidance on AD design is kind of sparse. My assumption is because directory designs are so environment-specific as to be resistant to generic instructions. This flexibility means two things: You can tailor the configuration and security of a domain to precisely and efficiently match the requirements of the environment it's there to support, making maintenance easy and allowing for future expansion.   You can screw things up really, really badly and not even know it. You see, the assumption in AD overall is you know what you're doing. There are very few warnings, no popup to let you know you just granted Bob in Accounting the keys to the kingdom or an easy wizard that lets you review your configurations before deploying them to ...

In my company, my overall department often takes over environments for business units who have built their own, then found they lack the time/knowledge to manage it effectively. It then falls upon my team to reorganize the Active Directory domain to follow industry/internal security standards and best practices. This article covers one of the most common low-level offenses we encounter: shared service accounts. Like so many questionable decisions, using a shared service account seems like such a good idea on the surface. You only have to create one account in AD, you only have to record and track one set of credentials, app installers only have to remember one set of credentials, permissions for different processes will likely overlap (meaning you only have to grant the access once), etc. However, I have a personal story that will help highlight why you're playing with fire. Let's travel back to early 2008. It was the first week of my current job, and I was trying to learn ...

Summary Most Active Directory object types have hundreds, if not thousands, of attributes. It's obviously not reasonable to put them all in the GUI, and even though Microsoft did everyone a favor by introducing the Attribute Editor tab in Server 2008, that doesn't help those looking to manage access to those attributes in the Advanced Security section. Yes, the security assignment can be done via PowerShell, but I often encounter users who aren't familiar with its syntax/output, and a screenshot showing checkboxes is far more useful than trying to explain a block of PowerShell text. There are ways to display attributes via Active Directory Users and Computers (ADUC) by modifying the schema, but customizing the schema is bad (mmkay?), and we're more concerned with displaying these attributes in the Advanced Security list than on reporting the values in them. Thankfully, we can accomplish this on a per-client basis without affecting the directory itself: the dssec.dat...

Summary A significant portion of being a good systems administrator is knowing how to accomplish tasks without doing more than is required. Maybe the best example of this is granting access to resources in Active Directory. When a user or team needs access to something in the directory, the beginner/bad sysadmin will take the easy way out, probably by using a default role like Account Operators or granting full control over the OU where the resources reside. After a while, you'll start seeing users in places where only groups should be or realize you've given someone the ability to reset the passwords on your elevated or production service accounts when you only wanted them to be able to unlock standard users. I'm not overstating things when I say the ACLs below are the basis for my entire directory design. AD's ability to grant permissions on a per-attribute level is what makes things like the separation of resources, the deployment of a proper role-based security ...

Summary Several things suck about Microsoft's DNS implentation, but the top two for me have to be security and backups. I don't know how many times I've had to explain to a team that I was not going to give them access to the DNS MMC snap-in because it would mean dozens or hundreds of Deny ACLs on zones in that environment. But that's another post. This post is about DNS backups. After experiencing the kind of event that causes one to review one's DNS backup plan, I found there wasn't a tidy way to back up AD-integrated zones like the options for AD, DHCP, and other infrastructure services. I started with a 36-line .bat file that required modification and an individual scheduled task for each zone that needed to be backed up. With the advent of the basic DNS cmdlets in Server 2008 R2, I moved on to an unholy combination of a PowerShell script that gathered zone info and called my old script in a loop. Not efficient, but it only needed one scheduled task. ...