Our organization has not yet enabled the "password must meet complexity requirements" option in the Active Directory
Group Policy password policy settings for our domain. I would like to enable this setting, but I am concerned about what this will do to existing user accounts. Will it immediately invalidate all user passwords if they do not currently meet the new standards, or will it only take effect the next time they are prompted to change their password? How should we go about managing the transition?
The Group Policy setting in Active Directory that you describe will have no effect on existing accounts until users try to change or update their passwords. So, yes, if their passwords don't meet the password complexity requirements, they'll stay the same until they're prompted to change them. (Note: Systems running OSes older than Windows 2000 don't support Active Directory password policy management.)
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:
- In this tip, Joel Dubin offers best practices and tools for ensuring password compliance.
- Learn how to safely distribute passwords to new users.
Dig deeper on Active Directory and LDAP Security
Related Q&A from Joel Dubin, past SearchSecurity.com expert
The security of RFID chips and smart cards may not be fully mature, but there are best practices to keep facilities safe. Identity and access ...continue reading
Picture passwords for mobile device security aren't a new idea, but they have been recently improved. Identity and access management expert Joel ...continue reading
Hacked smart cards are a large potential threat to enterprises that utilize them. Learn how to thwart smart card hackers.continue reading
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.