Identity Engineering

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

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 NTLM passwords from the  haveibeenpwned.com pwned password list  (scroll to the

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

In January last year, I wrote a (long) post detailing a curious behavior I stumbled across in Active Directory's LDAP interface. By providing a username, but leaving the password blank, you were authenticated as an 'anonymous user'. This is technically a valid LDAP behavior, and is known as an 'unauthenticated bind'. However it's obscure, not well known, and the cause of many security vulnerabilities . To recap, the LDAP RFC states the following; 5.1.2.  Unauthenticated Authentication  Mechanism of Simple Bind An LDAP client may use the unauthenticated authentication mechanism of the simple Bind method to establish an anonymous authorization state by sending a Bind request with a name value (a distinguished name in LDAP string form [ RFC4514 ] of non-zero length) and specifying the simple authentication choice containing a password value of zero length The RFC goes on to acknowledge this is an objectively terrible idea, and recommends that servers

Microsoft's Local Admin Password Solution (LAPS) is a very important tool that protects against the risk of lateral movement of threats between computers when the same local admin password is used on each machine. It is an agent that is deployed to each computer that randomises and rotates the local administrator password on each machine, and securely stores it in the Active Directory. While the LAPS mechanism itself is robust and does exactly what it needs to do, the process of accessing the LAPS passwords, and auditing that access is not so straight forward. Support staff out in the field may not have easy access to the tools required to get those passwords. You either need to use PowerShell, LAPS client, or another directory tool such as AD Users and Computers. Auditing access to LAPS passwords is a bit of a nightmare. It requires configuring audit policies on domain controllers for directory object access, which is a very board audit category and can be very noisy. You

You could walk into just about any organization today, and you’re bound to find an LDAP directory populated with its users. Look a bit further, and you’ll likely find one or more applications using that directory for ‘authentication’. I say 'authentication' with quotes, because LDAP authentication is something of a misnomer. LDAP is a directory access protocol, designed for reading, writing, and searching a directory service. It's not an authentication protocol. LDAP authentication typically refers to the part of the protocol (binding) that is meant to establish who you are in order to determine what privileges you have to the information in the directory.  Over time, it’s become a de facto authentication service. The wide-spread availability of LDAP services, such as Active Directory, has turned it into an easy win for software developers who are looking to build authentication into their products. LDAP client libraries are available for just about any framework, and

One of the things that I've always believed was missing from MIM and its predecessors was the ability to automatically 'run' the sync engine. The supported way of 'automating' the sync engine is to develop scripts that call the MIIS WMI methods. However, those scripts usually just cycle through the management agents and run profiles in a predetermined order, at a predetermined interval. Over the years, I've often thought that there must be a better way than this! When we consider the various operations that can be performed on each management agent, the clues to how to do this start to become clear. Delta import Performed when a change occurs in a connected system Delta synchronization Performed when an import operation stages changes in a connector space Export Performed when a synchronization stages outbound changes in a connector space Confirming import Performed when an export leaves  unconfirmed imports in the connector space In all

Microsoft Identity Manager and its predecessor, Forefront Identity Manager cater for self-service password reset (SSPR) scenarios with out of the box workflows that support SMS, email, and question/answer authentication. Self-service password reset is a very important capability for any organization, and when properly deployed, can significantly reduce calls to the service desk. However, even when SSPR is available in an organization, there will always be a percentage of password resets that the service desk performs. It could be that the user is not enrolled in SSPR, that they didn't know SSPR was available, or their registered SSPR mechanisms were no longer available (eg they have a new phone number, or no longer have access to their registered email address). In these cases, the service desk is usually called and a manual password reset is performed. This is not a scenario that is current supported by MIM directly, which typically results in the service desk dropping back to t