What security requirements do you have for Domain Administrators?

Question

With regard to managing a Windows network, what security polices and processes do you use? For example

• Do you require/support Smart Card Authentication?
• Restrict logins from a particular workstation?
• Require more complex passwords for Administrator accounts?
• Issue two accounts per use (admin, and standard account)?
• Enforce through policy or otherwise, that the non admin account is used locally
• The use of a different computer, or VM for administrative tasks

etc..

It would be helpful to know your practice, what industry you are in, and approximately how large your company/business/school is. Ideally, we can use this information to compare practices amongst peers.

---

Note:

If you're discussing policies regarding your current, live, place of business, consider replying to this survey in a confidential manner. This may require you to "log out" and log in using a different OpenID.

You be the best judge as to what works for you. In the meantime more information can be found here:

http://meta.security.stackexchange.com/questions/37/should-we-support-anonymous-postings

Answer 1

Having worked in both Public and Private sectors as an Info Sec guy I have had the opportunity to see how many organisations approach this and here are some of my observations;

Do you require/support Smart Card Authentication?

I have yet to find an organisation that has deployed smart card auth.

Restrict logins from a particular workstation?

This should be a basic building block, but many sites still fail to restrict access in this way. Further to this, specific accounts that require admin privileges should also be restricted to the specific servers / workstations required. Overly permissive rights can lead to domain compromise.

Require more complex passwords for Administrator accounts?

One site had a fantastic approach to this, they used a long pass phrase for the admin accounts. This served two aims. One - It protected against brute force attacks (who is going to have a dictionary or hash table for a fifteen word sentence?) and secondly it was used to stop the support team from giving the password out on the phone, as it would be obvious they were doing so. That team had a long history of passing out the admin passwords to stop them from having to leave their office and visiting users!

The use of a different computer, or VM for administrative tasks

The use of a management VLAN or other segregation is a good approach. Taking sensitive traffic and access away from the corporate lan is a start.

You should also have an approach to address the use and update to management tools. Deprecated management tools can lead to full domain compromise and a prolific on internal networks. How many times have you thought to patch your 'HP Management Service' or even turn it off? How many remote connection tools do your support team need? I have been on site where Terminal Services / VNC / DameWare and other remote tools were all in use on the same network for the same servers!

So take away here would be to review your approach to the use of management tools, disable those you don't need, reduce overlap of tools used to complete the same task and patch those you choose to maintain.

Answer 2

David and AviD have covered off the majority of my experiences too, the only addition I will give is for a large government department which used smart card authentication throughout.

This was done to meet a perceived requirement for absolute granularity on activities. These cards were used for physical access to locations, and logical access to computer terminals. Unfortunately the implementation made it very hard to cover absences so the staff developed a set of unofficial procedures which effectively undermined the entire framework (sharing and cloning of cards etc)

There was an argument made that it was overkill and far too onerous for the actual requirements.

YMMV - but it seemed a relevant datum point

Answer 3

This doesnt really apply to my company (very small business), but these are among the recommendations I usually make to my consulting clients:

• Do you require/support Smart Card Authentication? Highly recommended, but often not deployed. In high security orgs (e.g. large banks, military, etc) you actually can often find partially deployed smart cards, for admins only.
• Restrict logins from a particular workstation?
• The use of a different computer, or VM for administrative tasks
  These two actually go together, and this would depend greatly on the size, complexity, and sensitivity of the systems and network. For a larger network / sensitive systems, yes this is usually required. Also a network that is already complex i.e. not "flat" this would be easier to implement sensibly.
• Require more complex passwords for Administrator accounts? Absolutely, a seperate, much stricter password policy is required for admins. Longer, more complex, with shorter expiry and longer history. Also randomish passwords are encouraged, or better yet complicated passphrases. (This is also connected to the next point, to discourage oft-use.)
• Issue two accounts per use (admin, and standard account)? Again, for larger networks / highly secure organizations, very recommended. Smaller, less-sensitive networks can forego this requirement, especially considering UAC in current Windows versions.
• Enforce through policy or otherwise, that the non admin account is used locally Same as previous, and GPO is a very easy mechanism to deploy (though admins can usually bypass this - depends how it's deployed).
• Additional points you didnt mention: AUDIT, i.e. security logs. Stricter auditing requirements should be placed on use of administrative functions, and on administrator actions in general (e.g. via SCLs and Local/Domain Security Policy).
• Also the other kind of audit, outsiders/3rd party should review periodically both the above logs, and all the above configurations. Also any users with elevated privileges.
• In highly sensitive orgs, dual control is often required. E.g. the admin cannot access the sensitive server, unless the security officer unlocks the door and grants him physical access. (Often seen in military-type environments.)
• Administrative restrictions - while in principle the admin is enabled to do anything on "his" system, there are products (e.g. from CA) that can restrict his OS permissions. I've seen this deployed in numerous banks/financial companies.