So we have deployed the Managed Service Accounts, and now we want a password policy set on them.. usually the service accounts have a different password policy set, so most of you will probably use PSO’s (Password Setting Object). In my demo I’ve set a new policy stating that the max age of a password is only 10 minutes ( msDS-MaximumPasswordAge: 0:00:10:00). I’ve set the PSO’s msDS-PSOAppliesTo attribute to be the Active Directory Group “Service Accounts” so that all managed service accounts that are member of this group MUST change their password every 10 minutes. For the sanity check, I’ve also created a simple useraccount and added that to the group also. Now we only needed to wait 10 minutes.. When logging in as the user onto the SQL box, I indeed got the message that I needed to change my password. My demo users’ pwdLastSet attribute indeed jumped from : 2/4/2009 4:58:20 PM W. Europe Standard Time; to pwdLastSet: 2/4/2009 5:28:05 PM W. Europe Standard Time;
When I observed the pwsLastSet from the ServiceAccount however, it still stated: pwdLastSet: 2/4/2009 1:10:57 PM W. Europe Standard Time;
Off course you can argue and say I must restart the service, or complete server, however, the server has already been restarted twice, and for the sanity check I restarted the service manually.. no updates to the managed service account password..
Although one might expect the PSO to be applied to the new Service Account that is incorrect, the PSO can only be applied to user objects (or inetOrgPerson objects). They cannot be applied to Computer objects. http://technet.microsoft.com/en-us/library/cc770842.aspx
Question is.. will it listen to the default domain policy? I’ve set the policy to have the maxPasswordAge at 1 day.. and now.. we wait 🙂 (just kidding).. I’ve set the time 1 day ahead, when logging into the SQL box as the domain administrator I indeed needed to change my password (proving the Default Domain Policy is active and my system indeed thinks we’re 1 day further). Let’s reset the service and see if the pwdLastSet time bumps up… : pwdLastSet: 2/4/2009 1:10:57 PM W. Europe Standard Time;
There you have it.. no change .. which is actually expected again.. the default domain password policy only applies again to user objects and not the computers.
When you read the powershell help for the command reset-ADServiceAccount you will find the following note:
Note: When you reset the password for a computer, you also reset all of the service account passwords for that computer.
So if we change the password for a machine, the service accounts also change their password!
Again just for verification, the SQL server is a domain member and it’s current pwdLastSet: 2/7/2009 9:58:46 PM W. Europe Standard Time;
We change the computer account password by issuing the NLtest command
Connection Status = 0 0x0 NERR_Success
The command completed successfully
SQL03: pwdLastSet: 2/7/2009 10:07:32 PM W. Europe Standard Time;
MSA: pwdLastSet: 2/7/2009 9:58:46 PM W. Europe Standard Time
SQL03: pwdLastSet: 2/9/2009 10:15:22 PM W. Europe Standard Time;
MSA: pwdLastSet: 2/9/2009 10:15:22 PM W. Europe Standard Time;
And there you have it.. the service accounts only change password when the machine itself is triggered from Active Directory that their password has expired and change their passwords automatically. In general this will mean that your service account password will change every 30 days! If however you would like to reset the password sooner/or manually, you can do so by typing:
Resetting the computer account password using NLtest does NOT change the ServiceAccount password.
The Install-ADService account cmdlet installs an existing Active Directory
service account on the computer on which the cmdlet is run. This cmdlet
verifies that the computer is eligible to host the service account. The cmdlet
also makes the required changes in Netlogon and the Local System Authority
(LSA) so that the service account password can be periodically reset by
the computer without requiring any user action.
However on one of my test machines, the computer password WAS reset, while the service account password was not, on that computer the reset-adserviceaccount cmd’let did also not work.. perhaps something to keep track on in the future..