Restrict use of domain admins
Hi I run an Infrastructure Services Department in a financial services organisation. We have been audited and told to reduce the use of admin (domain admins) accounts. We have tried my staff having a non admin account and also an admin account with -adm on the end [audit see this as a good idea!]. The theory is they aren’t logged in as admin so if they browse to a dangerous website it can’t hurt the domain. The problem is that its adding a lot of time to their work. Every time they load a utility such as AD Users and Computers they have to do “run as” and enter their full credentials. Windows Explorer won’t run as admin so they go to a terminal server, log in as their domain admin account and use that as their desktop. I know all this is in reality pointless but we do have to try. I was about to put in a paper rubbishing the whole idea as it only gives a false sense of security but then I wondered, does anyone else do this and how do they get over the problems I've highlighted? Is there a way of running a Windows shell via "run as" on their PC and then using this to run utilities and Windows Explorer? Thanks Simon
February 4th, 2011 2:41pm

This is a case where user education/training is the only way to go. It should be pretty simple, if your domain administrators can't follow basic security policies, they shouldn't be trusted with domain administration rights, and they should be replaced. As far as a false sense of security, it depends on the threat. If the threat is a rogue administrator then obviously it won't matter. If the threat is a zero-day vulnerability that hits some moron surfing MySpace in IE as a domain administrator, then running as a domain administrator vs a limited local user is the difference between resetting the user's profile or cleaning it from every single server and workstation in the company. That might be good for job security, but trojans and viruses that spread using a user's network credentials are a real threat. As far as making this easier, Microsoft doesn't make it easy since Explorer isn't capable of running under alternate credentials. My personal preference is to live as a Domain Admin within a VM, and use that VM exclusively for administration tasks, while the account I use on my primary desktop has no more power or control than any network user. While it's possible a threat on the host might get into the guest and use it's credentials, this simply hasn't happened in the real world.
Free Windows Admin Tool Kit Click here and download it now
February 4th, 2011 8:45pm

The whole idea of two separate user accounts is good for novice administrators, but once you have experience, its a burden. The novice administrator may stop and think before he does something using this second account, or it may prevent them from "accidents", but its mostly a false sense of security, because they still have the rights, and still lack the skill/training. I am not a believer in the whole separate accounts philosophy, but would be for it when it comes to junior/trainee administrators. May people take the whole two accounts issue to far, requiring it for any "administrative" account, which could be helpdesk, or desktop support personnel as well. Like Dave said, the best solution is Traininig. As for your Domain Admins / audit issue, that's an easy fix. Create another group that is Domain Admin equivalent, the auditors will most likely never now...especially if you don't tell them Domain Admins has two basic functions. First, it is a member of the domain built-in Administrators group, which provides all security within the Active Directory domain. Secondly, it is automatically made a member of every Workstation and Server Administrators group. If you create a new group, place it in the above groups, whola, you have a new "Domain Admins" equivalent group, that the auditors know nothing about. But even this solution isn't the best, its difficult to maintain unless you use GPO's to push the group members changes. Another option for dealing with auditors, it to promote the use of tracking. Tell the auditor that if you reduce the number of Domain Admin accounts, you will be force to Share a single Domain Admin account between all the administrators on your team. This will lessen your ability to TRACK changes in Active Directory to specific users. Thus, if you encounter mysterious change, un-authorized access, using that single account you will have know way to tell who did it...conclusively. Any good/experienced auditor will understand the importance of that implication, and will agree to let you keep your accounts. Last thing....Service accounts should never (rarely) be domain admins. Many adminsitrators break this rule creating many security holes in your environment. The only service account that is normally a domain admin is the backup account. That is true with few exceptions. If you have a lot of these accounts, you can usually remove them, and just make them administrators on the local servers.
February 4th, 2011 9:52pm

I consider you're doing it right way. All the administrators must have 2 user accounts, and that's how I'm working for at least 10 years, and all of my administrators do. For usability purposes, we log on to our computers as users and then establish Terminal Session with domain rights when needed. Let they keep their sessions disconnected and re-connect time to time, it's okay. To launch Explorer with alternate privileges, create a shortcut to "explorer.exe /separate" and RunAs it. (In fact, RunAs is disabled on most of our workstations because of the huge hole in Software Restriction Policies with it.) However, if you got a lot of administrators, consider reducing administrative account number + make the use of Delegation of tasks. There should be no more than 2-3 domain admin accounts.MCITP: Enterprise Administrator; MCT; Microsoft Security Trusted Advisor; CCNA
Free Windows Admin Tool Kit Click here and download it now
February 8th, 2011 3:06am

Hi, UAC may address some of your concerns, because Administrators logon computer with their standard user token. http://msdn.microsoft.com/en-us/library/aa511445.aspx http://technet.microsoft.com/en-us/library/cc709628(WS.10).aspxThis posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click Mark as Answer on the post that helps you, and to click Unmark as Answer if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
February 9th, 2011 1:18am

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics