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 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. ...