By submitting my Email address I confirm that I have read and accepted the Terms of Use and Declaration of Consent.

By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.

You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

-- many applications cannot function without service accounts. In the past, administrators had a choice between using domain accounts and the Local System account. Microsoft later added the Local Service and Network Service options, but neither local nor domain service accounts are ideal.

In Windows Server 2008 R2, Microsoft took measures to reduce some of the service account-related vulnerabilities with the introduction of managed service accounts. Let’s take a look at some of the known issues with service accounts before digging into how R2 can help.

The trouble with local and domain accounts The biggest problem with using a local account is it cannot be centrally managed. As for domain accounts, oftentimes they are not properly secured.

Most people don’t require password changes for domain service accounts because doing so can be a real pain. When the passwords expire they must be reset in the usual way, but the Service Control Manager must also be reconfigured to use the new password. When this happens, the affected service must be restarted, which can be disruptive to the applications that depend on it. As if that weren’t bad enough, many administrators also refuse to configure account lockout settings for service accounts. This is because no one wants to explain to their boss that a mission critical application failed when someone mistyped a password one too many times and locked out the account.

More security tips for R2

Another reason why domain service accounts have traditionally presented such a serious threat to security involves the way they are used. When an application requires a service account, that account is almost always granted permissions that allow it to act as part of the operating system. Depending on the application’s requirements, there may be additional rights that are also granted to the service account. The granting of these rights isn’t a problem. What is a problem, however, is that some administrators get in the habit of reusing service accounts.

To give you a better idea of what I mean, consider the case of Microsoft SharePoint 2007, which can require up to five different service accounts. There is nothing stopping an administrator from using the same domain account for each required account. Keep in mind that there is a reason why Microsoft designed SharePoint to ask for multiple service accounts rather than just using a single one for all of SharePoint’s needs. Each service account is granted a different set of rights. If you use a single domain account for all of SharePoint’s required service accounts then you will end up with a single domain account that has been granted excessive rights.

Considering that the account may also have a static password with no lockout requirements, it is easy to see why service accounts can pose such a threat to security. Furthermore, many organizations use the same service account on multiple servers, which means that any server using the account could potentially be exploited.

Enter managed service accounts A managed service account is a special type of domain account in Windows Server 2008 R2 that provides automated management of passwords and Service Principal Names (SPNs). One of the primary benefits of using managed service accounts is that because Windows manages the service account passwords, the entire process is seamless. Not only is there no administrative burden (once the initial setup is complete), there is no disruption of service when service account passwords are changed.

Additionally, Windows prevents the accounts from being reused. In other words, an administrator cannot use the same service account for all of his or her Exchange servers, as each Exchange server requires its own unique managed service account. While some administrators may find this frustrating, there is little doubt that preventing service account reuse improves security.

Applying managed service accounts In order to use a managed service account to its fullest, the domain must be running at the Windows Server 2008 R2 functional level and the computers that the managed services are operating on must be running either R2 or Windows 7.

Microsoft generally recommends that all of your domain controllers run Windows Server 2008 R2 if you want to use managed service accounts. That said, if your Active Directory schema has been extended to R2, but not all of your domain controllers are running R2, you can still use managed service accounts. Automated password management will still work as well, but you will have to manually configure the SPN data for your managed service accounts.

Finally, before you begin using managed service accounts, it is important to make sure that your application supports them. Although some Microsoft products such as Exchange Server allow you to use managed service accounts (with some minor limitations), there are other applications with which they won’t work. Surprisingly, SQL Server is one such application. Managed service accounts also cannot be used with the Windows Task Scheduler.

ABOUT THE AUTHORBrien M. Posey, MCSE, is a Microsoft MVP for his work with Windows 2000 Server, Exchange Server and IIS. He has served as CIO for a nationwide chain of hospitals and was once in charge of IT security for Fort Knox. For more information, visit www.brienposey.com.

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy