Configure ExCM Password to Meet Corporate Complexity

One of my favorite help desk stories is the lady that was attempting to use “DocDopeySneezySleepyGrumpyBashfulHappy” as her password. When asked about it she stated, “Because it had to include 7 characters.”

These days, you would at least need to throw Snow White in there as well because most places require at least 8 characters… and do not get me started on alpha numeric and at least one special character with no repeating characters!

As an IT guy, I have been the recipient of a tongue lashing from a few “less-than-happy” end users, when I informed them that the password they were attempting to use does not meet their companies’ complexity policy. I have also spent the better part of 20 minutes informing a user that the word “Window” does in fact have a repeating character in it. Wouldn’t it be easier if we did not have end users passwords? But I do not think that either is going away anytime soon, so the best we can do is make it as easy as possible (or, at the very least, less likely that users will call us with password issues).

In this article, I will walk you through how to lock out a user after a certain number of unsuccessful attempts, how to change the length of time that a user has to attempt a password, and how to configure ExCM to enforce your company’s password policy. Before continuing with these steps, ensure that you have at least read and hopefully implemented our steps on Enabling User Automation as these steps give you even more options when it comes to password security.

To begin, you need to navigate to your ExCM web app’s web.config file. To do so, open IIS Manager by typing “INETMGR” into a command prompt. Once opened you will need to navigate to the IIS site for the extranet web application. Go ahead and make a backup copy of the web.config file by right clicking on it, choosing copy and paste it into the same directory. Now that we have an “Uh-Oh” copy, let’s open the web.config file.

The first change that we are going to make is the number of tries a user gets before the account is locked out. To do so, we need to do a search for the text “maxInvalidPasswordAttempts="10"”.  It should be in the membership “defaultProvider” section and there should be two of them. You will need to change both. By default this value is set to 10, which would give the user 10 attempts.

If Acme Corporation had a requirement of 3 invalid attempts before being locked out, and that is the only change we need to make, it would look like “maxInvalidPasswordAttempts="3”. We also need to make these changes in the SecurityTokenService web.config file. Then, we could just save our web.config files and test it using a test account. (FYI, it is not wise to test using your admin account as you will need this account to unlock the user… not that I have ever done that. Or if I did, it was only to show you what not to do.)

However, I am not done just yet. Let’s say that I also want to adjust the amount of time that a user has to make their attempts to log in. By default the user gets 10 tries in 10 minutes. If you were making changes along with me, your user would now have 3 attempts in 10 minutes.

As most of the bots that we are trying to protect against would likely make more than one attempt a minute, it is probably safe to drop this number down as well, so the user can try again quickly without getting locked out. (Please note that users have the ability to reset their own passwords, so unless there is a regulation against it, I suggest giving users a higher number of attempts than configured in these steps, and allowing them to reset their passwords once they have exhausted their guesses.)

To adjust the time allowed for guessing a password, we will search for “passwordAttemptWindow=”10”” and just as before, we will change that number to match the number of minutes to which you would like to change the window. Again, make the same changes in the SecurityTokenService web.config file.

Now that we have narrowed the number of attempts and how much time users have to attempt to enter their password let’s also ensure that the password cannot be guessed within the first few tries by making certain that the ExCM password meets your company’s password policy.

On the registration screen, when users first type in their password, they are presented with a strength meter that indicates if the password meets a predefined complexity level. By default, ExCM checks to see if there are 6 characters. To change this we need to navigate back to the same web.config file and search for “minRequiredPasswordLength=“6””. (It should be found in the same section as the last two steps.) As before, simply change the “6” to the number of characters that your complexity policy requires, mirror your changes in the STS we.config and save the file. This will satisfy your length requirement.

Unless you are collaborating with psychics (and possibly even then), you may want to find a way to inform your users of what the password should look like before they (not the psychics) get frustrated at trying to figure out your complexity policy. With the web.config file open, do a search for “passwordMessage”.

Make sure to adjust this message to fit your complexity policy as well as update the “passwordExample” as these will display on the registration screen to help guide your users into selecting a secure password that satisfies your organization’s password complexity policy.