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