In the last few years, some of the gains I've made toward making my role more focused on long-term efforts to continually improve and standardize our systems have been rolled back. The organizational details are boring and immaterial to the story; it boils down to the fact my team has less people to do more work, so much more of my time must be spent dealing with the churn of my team's daily duties. As a result, all parts of my job have suffered, and not just in obvious ways. My primary frustration with this situation is IT systems are entropic. They are constantly changing, and without clear and enforced policies, they get more chaotic as they grow. For a couple years, I felt like I was really making progress toward bringing my company's domains to an acceptable level of standardization, many of which we took over after their previous owners failed an audit or were essentially told to give us the reigns because we were better equipped for managing the services associated w

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

If you work in an operations center that receives or routes requests, your life is probably dominated by case numbers. You see them all day, and they likely represent the most granular version of a work task for you. They are invaluable to your job and allow you to quickly look up required information. Unfortunately, when you contact me (a systems administrator), only giving me a case number is almost worthless, especially when I may be away from my workstation. That made sound hyperbolic, but it's true. Whereas that number represents a completed task to you (transferred to a queue), it doesn't help me do any part of my job or tell me if I can even help the person who put in the case. It's just a random number. It never ceases to amuse and annoy me when someone from our operations center calls me (especially off hours), tells me they've routed a case to my queue, only gives me the number, then seems prepared to hang up, thinking they've done their job. Here ar

Background A very common request I get from business units (and end users, even) is to be granted read access to internal Microsoft DNS servers. I completely understand the motivation: it could be very convenient to be able to review both the existence and resolution data of DNS records. I mean, you can grant read-only access to a file share and a database, so you should be able to do the same for DNS, right? Unfortunately, it's not that simple, and for one main reason: Microsoft DNS security sucks. I'm not going to go into all the technical details here (may do a full post with all that later), but because of the way Microsoft has set up their default permissions, the security principal Authenticated Users can create and modify all records in any zone hosted by a Windows DNS server. This is to allow and enforce secure dynamic updates. However, the major takeaway for today's post is that anyone who is granted the ability to connect to a Windows DNS server via MMC can cr

A while back, my team was asked to take over a domain from a business unit that had built one, then realized it was more difficult/complex than they thought. I was asked to do an urgent reorganization, ripping out directory access and forcing them to use the least permissions principle. We barely made the deadline, and even though I did my best to explain to them the fact that they would no longer have carte blanche in the domain, they were surprised and annoyed to find they couldn't create service accounts or do other customer onboarding tasks. Just like I've done dozens of times before, I worked with them to define their undocumented processes, focusing on the ones for which my team would be responsible going forward. During this process, I noticed they were using a very simplistic naming scheme for their customer resources, including a 3-character alpha identifier for service accounts and groups. After asking, I was told this code was based on a single physical location of

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