Thursday, May 29, 2014

Password complexity gets complicated with AD Trusts

I came across an issue recently in a customer's SharePoint 2010 farm.  We were performing our annual service account password changes and ran into an issue.  The people picker in our DMZ stopped working and the service account that handles that authentication kept getting locked out.  Unless the account was already cached in the user information list, new user accounts could not be queried and the address book feature was broken as well.

Because we have a AD trust set up, we have to run the following command to restore the credentials:

stsadm -o setproperty -pn peoplepicker-searchadforests -pv "forest:web.net,domain1\svcacct1,password; forest:web.dmz,domain2\svcacct2,password" -url http://yourwebsite 

Even after running this, the people picker still did not work.  It got me thinking about the complexity of the password.  We actually had semi-colons and commas in the password for one of these service accounts, so when the command was run, it was picking up these special characters as part of the command, instead of part of the password.

After changing the password to remove these special characters, I was able to re-run the command and the password took successfully.  We then unlocked the accounts, performed an IISRESET, and BAM! the people picker again started working.

So keep in mind when choosing the complexity of your passwords.  We want to be secure, but there are some instances where special characters should be avoided.  My preference is to not use the following characters for service account passwords, particularly if you like to use powershell cmdlets:

$ - can be mistaken for a variable
; - is often used in a string to separate sections
, - same as above
Lastly, I try to avoid capital Os because they can get mistaken for a zero.

Hopefully this helps.

No comments:

Post a Comment