Identity Engineering

NOTE: Please visit docs.lithnet.io for the most up-to-date setup instructions  In this guide, we will look at how to set up Lithnet Password Protection for Active Directory (LPP) from scratch. We'll configure a basic password policy, and integrate the haveibeenpwned.com pwned password data set to prevent users from changing their password to one that is known to be compromised. This guide will focus on testing in an Active Directory domain, by installing the agent on a domain controller. However, for testing purposes, you can install the agent on a member server or workstation. The only difference is you'll need to test using local accounts, rather than domain accounts. Prerequisites You'll need to be using an x64 version of windows. LPP is a x64-only application. You must have local administrator rights on the server you want to install the agent on. For domain controllers, this means being a member of the Domain Admins group. Download the latest version of the N...

Password complexity requirements can be frustrating. It comes as no surprise that the current NIST guidelines recommend doing away with them altogether. There was no way I was getting approval to do that across the board in my organization, but I could make the case for having less stringent requirements on longer passwords. Lithnet Password Protection for Active Directory (LPP) has a built-in policy to do exactly this. You can define up to 3 password-length thresholds, each with their own complexity requirements. In my organization, we still have the usual '3 out of 4' character set policy in place for passwords less than 13 characters in length. However, we decided that passwords over 13 characters would have no special requirements. You'll need to determine what rules are appropriate for your organization. Use resources such as https://howsecureismypassword.net/ to help you gauge the relative strength of passwords based on length and character sets, and come t...

In part 1 , we saw how Lithnet Password Protection for Active Directory (LPP) allows us to test incoming password changes for exact matches against known compromised passwords. Well, what if we want to prevent paswords based on certain words? Most users understandably want a password that is easy to remember, but in many cases, they end up choosing a well known 'password pattern' that can easily fall to brute force attacks. A common password pattern I have seen is where a user combines a season with the current year, for example Winter2018 or Summer2017. Now, while this and previous year's versions of these passwords are in HIBP, future ones may not be. We can prevent the use of all passwords based on these words, by using the banned word functionality of LPP. Banned words checks work a bit differently to compromised password checks. The compromised password check looks for an exact match in the store against the incoming password. The banned word check first  n...

Hackers have never had it easier when it comes to performing credential-based attacks. Massive lists of breached user names and passwords are readily available on the internet for use in credential stuffing attacks against organizations. Even without the help of such lists, attackers can rely on the fact that people generally choose terrible, predictable passwords. Target a large enough organization, and you have a chance of finding a user with a password from a top 100 bad password  list. Keeping up with these sorts of threats is a challenge for every organization, no matter the technology they use. For a significant number of organizations, Microsoft's Active Directory is the core authentication service, connecting users and services across the enterprise. It is disappointing then, that AD hasn't done much to adapt to the changing threat landscape, with password protection capabilities that haven't changed in decades. A true sign of its age is that it stores passwor...

Okta is a leading provider of single sign-on, MFA, lifecycle management, and API access management products. And starting today, you can easily integrate Okta with Microsoft Identity Manager using the Lithnet Okta Management Agent .  Using the native Okta API platform, the management agent can add, delete, and update users, as well as synchronize password changes. You can manage users independently, or coexist with Okta's native AD sync agents, to provide supplementary attributes to objects that are not found in your AD. The management agent provides support for importing groups, but not modifying them. Why? Well, at this stage, Okta doesn't support nested groups (🤦‍♂️!), a fundamental capability of MIM and Active Directory. There's simply no reliable way to translate these concepts using only the MIM connector model. Okta's AD sync agent flattens groups before syncing them to Okta, so if you need to use AD groups, that's still the best way to get them in ...