Will enabling Group Policy password settings affect existing user accounts?

Password policies are set through the Group Policy Objects editor, which is part of the Active Directory administration GUI. These policies should be configured for the whole domain, rather than individual workstations, to maintain consistency across the network.

Additionally, Active Directory can be used to manage password age, history and length. Plus it can manage password complexity, which means using a mix of uppercase and lowercase letters and numbers, and ensuring a password doesn't have at least three consecutive characters from the username. This not only prevents someone from using his or her user ID as a password, but also can cut down on many common brute force and dictionary attacks. Of course, it's not foolproof, but it's an effective part of a multilayered authentication.

The Group Policy should also be set to force users to change their passwords after a set time period, with frequency depending on the risk level of the data being protected and, of course, your organization's business needs and requirements.

The best way to manage such a transition would depend on the size of the organization. For a larger organization, a phased-in approach is best. Send an announcement to users -- either through the corporate Intranet, a logon banner, or a mass email -- giving them dates and locations for the changes in password policies.

For a customer portal application, once a user has successfully logged in, should he/she be allowed to see his/her current security password-retrieval answer? Does it matter if the portal uses a single sign-on (SSO) system?

Security questions and answers are still authentication credentials, just like a user ID and password, or any other login credential, for that matter. As such, they should have the same protections as a user ID and password. Whether or not the portal uses SSO is irrelevant. A login is a login, no matter whether it comes through a single authentication system, or a complex one, like SSO.

You wouldn't expose a user's password on a desktop or online, right? Think of a security question and answer as an extension to a password.

Just as a reminder, here are some rules, or best practices, for safe handling of passwords that should be applied to security questions and answers, as well.

• The answers to a question, once answered by the user, should never be displayed again. In future instances when it would be displayed, it should be blanked out, or covered with asterisks, just like a password.
• If a user needs to reset the answer to a question, he or she should be redirected to that question and asked to answer it again.
• If a user forgets the answer to a question, again, just like resetting a password, he or she should be redirected to the question to re-answer it, or be sent to a question-reset page.
• If the user wants to add, delete or change a question, the same rule applies. He or she should be asked to start the question-and-answer process again from scratch.

Now, keep in mind there's one key difference between a question reset and a password reset. When a password is reset, it's a best practice for a system administrator or the help desk to issue a temporary password good only once and then only for a short period, say 24 hours. Once the user logs on with the temporary password, he or she is prompted for a new password, and the temporary password is invalidated. This way, the password is always kept secret and isn't accessible even to system administrators or the help desk.

This is because, unlike a password, security answers are almost always initially set up by the user, while initial passwords are usually set up by an administrator or other IT staff.

For more information: