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