Password policies can help administrators secure their environment, letting users change their passwords on regular basis makes it harder for hackers to get in to a system by guessing a password. There is one group of accounts though that usually do not have the password policy applied to.. they almost never change their password and when they do.. it is a load of work for the admin, there is service downtime involved.. and after the password has been changed.. it will be not be changed for a long time.. Yes, I’m talking about Service Account.. the accounts administrators usually apply the “Password Never Expires” option to. These accounts usually have more rights to systems, perhaps even local Administrator access to machines (like SQL or mail) or even worse (Don’t tell me you have these in place) Domain Admin rights. Changing passwords for these accounts is crucial to the security of your environment. To make life easier Windows 2008 R2 introduces the Managed Service Accounts, with these, you can easily change the password of an account, and the client computers where these service accounts are operational will change the password in the service configuration.

To have managed service accounts your services must be hosted on Windows 7 or Windows 2008 R2 (another good argument to upgrade all those old systems asap once Windows 2008 R2 comes out.. ), but your schema does not have to be in 2008R2 mode, although this will have some advantages. In Windows 2008 R2 Schema, SPN management of service accounts will be done in the background automatically for you. If you are in 2003 or 2008 mode, you need to manually register/unregister the SPN’s. It looks like all the new features(in R2)  require the upgrade of your domain controllers, this one does not. Although your schema needs to be prepared to support Managed Service Accounts, your domain controllers can still be Wndows 2003 or Windows 20038. The feature can be managed by a member server running Windows 2008 R2.

So what’s the catch of this great new feature.. well the first one we already mentioned; you need Windows 7 or Windows 2008 as the client. The second one is that one service account can only be used for one client. So no sharing of accounts between clients (can you hear web farm?). Nor is it possible to manage service accounts for clusters services, where the service itself is clustered over more than one node.Note that only services that are in the Services console on the client computer will have their password changes.. off course passwords in .ini files will not be changed.. 

In the sample below, I’m already running in Windows 2008R2 mode. My domain has been installed from scratch, and after the dcpromo you already have the new Managed Service Accounts OU. If you right click, and choose new, you also see the new option msDS-ManagedServiceAccount. InPpowershell you can use the New-ADServiceAccount commandlet. In my example I will create a service account for SQL. I name the account SA-SQL01-SQL, according to my naming conventions (SA for ServiceAccount, SQL01 is the SQL servername and SQL is the service type). 

Although the GUI let’s you create an account, you should NOT use this method and user powershell instead. 

!!!!Note that the wizard does not ask you for a password!!!!!

New-ADServiceAccount SA-SQL01-SQL  -Enabled $true -Path “CN=Managed Service Accounts,DC=ROOTDOMAIN,DC=LOCAL” -ServicePrincipalNames “MSSQLSVC/SQL01.ROOTDOMAIN.LOCAL:1456”

This command will create the account, in the right container (you can choose your own) and set’s the SPN for the account automatically. (else you must you SETSPN -A).

If you would open the properties of this new account, you would not see the normal tab’s as you do with regular user accounts. Instead the last tab is the attribute editor. This editor gives you direct access to the attributes of the ServiceAccount and can be used to control the service account behavior. Like when the account must expire (if it does), if the account is trusted for delegation (see Kerberos delegation), etc. 

Kerberos Delegation: Normally you would have a tab that gives you the option “Trusted for Delegation” after an SPN has been registered to a useraccount. To enable the service account for delegation, use the Set-ADServiceAccount -TrustedForDelegation true command after creation or during new-ADServiceAccount commandlet.

For the client side, we need to install the AD-Powershell features. This can be done through Server Manager, Features, Add Features, Remote Administration Tools, Role Administration Tools, AD DS and AD  LDS Tools and choosing Active Directory Powershell Snap-in. We need this, since the next command we need to run is a script to install the Service Account. Open the Active Directory Powershell from Administrative tools in the start menu. 

Install-ADServiceAccount -identity <SA name>

This command will check if the local computer is eligible to host the service account and makes the changes to Netlogon and the LSA, so that the password reset’s can be requested by the computer, without user interaction. 

Next I installed SQL2005SP2 on the SQL01 server, that server is also running Windows 2008R2. I’m not going to detail on that installation, just use all the defaults etc or use on of the many install guides. Note however that I used the Local System as the Service Account to be used for SQL. We will change this later to be the Managed Service Account.

Because I’m running SQL2005 on Windows 2008R2, I also installed Service Pack 2 for SQL. 

Next, we go to the services of the SQL01 computer, (services.msc) and look for the SQL service which now starts under the Local System account.Go to the logon tab and change this to domainaccount$. Do not forget the $ sign or the account will not be found. If you specified a password with the New-ADServiceAccount commandlet enter that password and click ok. The account will be given the logon-as rights on the system. If you need to make the service account member of one of the local groups, you must use the groups from Active Directory. Since the accounts are not recognized as normal user accounts, they cannot be found through the standard finder, this is also why the setup of (for example SQL) cannot find the service account during setup, either with or without the $ sign. 

However in Active Directory you can create a new group and add the Managed Service accounts, that group, you can add to the local groups of the computer hosting the service, note that the picker in Active Directory now actually has the object type Service Accounts as an option. For my SQL installation I added the new Active Directory group to the appropriate groups locally.

So the idea of centrally managed service accounts look nice, the service accounts are not real accounts and are therefore only usable to run service accounts (eg no GUI login).. however delegating the rights to these accounts can be approved alot.. same for the GUI itself when creating a new Service Account…