Sean Wallbridge
Here is a listing of best practices I put together for a client some time ago, enjoy or throw away. Whatever. 🙂
The following best practices are based on the amount of risk and expense a corporation can afford. For example, a small company running Small Business Server will typically only have one server so the Domain Controller (DC) role cannot be moved to a dedicated machine. Alternatively, a corporation such as a bank does have the monetary resources (and increased risk) and should separate Domain Controller roles from any Line of Business Applications or Internet Exposed equipment.
1. Domain Controllers (the centralized user account/password database) should not house applications that require specialized permissions or rights as these can result in compromise and weakness in a Windows Domain Design
2. Domain Controllers should never be Internet exposed (i.e. an Exchange Server, installed on a Domain Controller will likely be Internet accessible as it provides SMTP and WWW access, at a minimum)
3. Based on #1 and #2, if Domain Controllers are dedicated to their purpose and/or simply provide simplified capabilities (print serving, file serving, i.e. Non-applications), there should never be a need for a service account to ever require Domain Admin” privileges
- A “Domain Administrator” has Administrative capabilities across ALL Domain Controllers, All Member Servers (by default) and All Workstations (by default)
- An Application, installed on a non-DC Member Server will only ever need “local administrator” access to the server (and perhaps rights such as “Log On As A Service” or “Run As A Batch Job”) on which it runs OR possibly matching local administrator privileges across several Member Servers (Which you would manage by creating a dedicated application group)
4. Service Accounts are common (and perhaps important) as they provide a few things:
- A separate password that shouldn’t be shared with others (set and forgotten)
- Typically, this account is set to ‘never expire’ its password. While this isn’t a great idea (Service Accounts should be ‘Managed’), it is common place for service accounts to have this attribute
- A user account or the default ‘administrator’ account should never be used for services as their passwords may expire, may be changed due to someone being terminated, etc. and thus applications could break immediately or even weeks later after a server is restarted
5. Service accounts should follow a naming convention, such as ‘Service-SQL’. This is so that they can be easily identified as to their purpose. If SQL Server was no longer used, this account should be able to be safely disabled without any detrimental impact
6. Often, a single Service Account will be created, such as ‘service-master’. While this will limit how many service accounts get created (just one), it typically results in several people knowing its password. Thus in the case of a termination, this account password will need to be reset and subsequently, services and applications will need immediate (and often production impacting) attention
7. Does the application even require a service account anymore? Perhaps due to legacy information or upgrades, a service account was assumed. Note that Windows 2003 was the first Windows operating system to introduce the “local service account” and the “network service account”. Perhaps this is all that is required
8. The default ‘Administrator’ account password should not be known (nor should it be ‘administrator’, it should be renamed but that is for a different document). In addition, the Service-Account Passwords should be protected as well. It may be inconvenient to have the ‘CTO’ type in a service account password but it does ensure delegation of responsibility and access control
9. Procedures should be put in place to manage ‘changing’ of service account passwords. Typically this would involve:
- Notifying users of an upcoming change (change control, usually no impact)
- Changing the password for the service account in the domain
- Changing the password entered in the Windows Service dialog for the service(s) and possibly, within the application itself (many applications will manage the changing of the service password within the application interface)
Note: If your domain is Windows 2003 based and/or your Servers are Windows 2003 based, the following document should prove a worthwhile reference as well: https://www.microsoft.com/technet/security/guidance/serversecurity/serviceaccount/default.mspx
How Did We Get Here?
Q. Why are there often so many Domain Admins in a Windows Domain?
A. Typically, Laziness and/or Inexperience
- Service accounts often end up as Domain Admins because an application install will ‘work the first time’. The service account has all the capabilities it needs (and then some) and thus the installation goes smoothly instead of smartly. No effort is taken after the fact to ensure the application is actually secure or aligns with the corporate security policy
- Sometimes IT Administrators (or 3rd party vendors onsite) just don’t know any better. They always
used a Domain Admin before, why not now?
Powered by www.itgroove.net
Sponsored by Major Change (.com) – The Online Change Register