In a recent article, we discussed how Password Self-Service (PSS) needs to be managed with a degree of granularity. The basis for this argument is that users with varying levels of elevated privileges should be protected with additional layers of complexity and scrutiny. This allows an organization to ensure appropriate levels security are enforced based on the role of the individual accessing the network, applications, and your data.
But even without PSS in place, this same secure position should be taken by every organization, providing there are ways to do so with the directory service serving as the foundation for all security. I put it this way because with many organizations utilizing single sign-on or federated services, the definition of exactly who is dictating password policies can get a bit blurry.
Assuming you, like most organizations, are using Active Directory, let’s drill into a few places you can implement a far more secure environment that aligns with the elevated privileges individual users may have.
Password policies have been around since the dawn of Windows NT. It wasn’t until Server 2008 that fine-grained password policies (FGPP) were available – albeit you needed to jump through some serious hoops to create and configure these FGPPs via tools like ADSIEdit or LDIFDE. It’s only with Server 2012 that this management moved into the mainstream and can be found within the AD Administrative Center (ADAC), as shown below.
If you’ve been around Windows for many years, nearly every setting is somewhat familiar to you already. But there are a few whose values should be considered carefully when applied to a granular policy scenario. They are:
- Policy Precedence – It is theoretically possible for more than one password policy to affect a given user. So, it’s important to establish for each policy created the precedence it will have over other FGPPs. The lower the precedence value, the higher, the priority. If you plan on having multiple policies that overlap in their application to users, you need to consider higher precedence values for broader sets of lower-level users, and lower precedence values for each set of users that have elevated sets of access to resources and data.
- Password Complexity – At a minimum, elevated users should be required to have a complex password – as defined by the policy (which breaks password characters into 5 groups and requires 3 of the 5 are used, while disallowing any use of the username or parts of the user’s full name in the password). Should you need more complex requirements, using a third-party password self-service solution may be necessary.
- Account Lockout Settings – As a given user has more access to applications and data, giving them less leeway with regard to incorrect logons is called for. Specifying a very low account lockout threshold (that is, the number of incorrect attempts before the account is locked out), and a lockout duration set to zero, which requires an administrator unlock the account.
There’s one last issue around FGPPs you need to consider, as there are some serious repercussions. It’s who the FGPP is applied to. Both security groups and user objects can be selected, in the Directly Applies To section of the FGPP, with the natural inclination being to use groups so as to cover a multitude of users with a single policy.
But the challenge with groups is the lack of consistency in both how they are managed and how frequently they are managed. If your groups are lacking the attention necessary to ensure they are providing your organization with the proper secure foundation for any applications and initiatives that rely on them, you should consider focusing on group management to create better security. Without doing so, you’re only complicating your security by establishing FGPPs on a less-then-solid foundation. In specific, when applying policies to groups where membership isn’t validated, your precedence values can either lock down a user that shouldn’t, or – even worse – allow a user with elevated privileges to have higher lockout thresholds, giving attackers more leeway to attempt to gain access.
Use of group management solutions can automate and simplify the often overlooked details that put even FGPP into a state of insecurity. They ensure group memberships are up-to-date, while empowering ownership so that the entire lifecycle of a given group – from cradle to grave – is managed by an individual.
The whole reason for FGPP is to create levels of password security that match the levels of access users have to do their job, in order to lower risk and improve your security stance. The first step is to take advantage of what’s included with Windows Server. Should you need to go further and establish new password complexity requirements, or more finely establish who has which password policies, you may need to look at a PSS solution. Lastly, consider the foundation for your FGPP implementation – groups – and evaluate whether your groups are in a secure state and, if necessary, utilize group management solutions to improve the foundation of FGPP and other security initiatives like it.