And, as it often goes, the saving grace that smacked some sense back into me came from a 13-year-old article on a WordPress blog I'd never heard of.

Setting the Stage

I have a .NET web application hosted in IIS, let's call it WebApp. WebApp allows users to authenticate with their Domain accounts via Basic Authentication or Windows Authentication. It also supports federation via WS-Fed and SAML2.0, utilizing ASP.NET Impersonation behind the scenes. When using ADFS for federation in an interesting AD environment, I encountered the following issue, which was completely novel to me.

A Wild AD Environment Appears

This environment has the following 2 forests, in a 2-way transitive trust, with the following UPN Suffixes:

WebApp is installed in example.com, and configured with Basic Authentication. If I authenticate as a user with each UPN Suffix across both forests using their UserPrincipalName as the username, here is what happens.

When Jacob authenticates as Jacob@acme.com, it fails for this web app. Although I didn't realize this at the time, I now know this is due to Microsoft’s Collision Detection when routing name suffixes across forests. If I authenticate to example.com using my UPN, and my UPN Suffix exists in multiple forests in the trust, Microsoft will not cross the trust to find my account. It will only search in example.com.

However, if I instead authenticate with the username in the legacy form of NetBiosName\SamAccountName, then every user can successfully authenticate.

Federation Uses Confusion. It's a Critical Hit.

After this, I switched to Federated Authentication using ADFS. As expected, when authenticating to ADFS, I experienced the same results. company\Jacob succeeds, jacob@acme.com fails. However, once Jacob authenticates to ADFS and tries to federate to WebApp, WebApp fails to authenticate.

WebApp: Authentication Failed.

So, what's going on here? Again I didn't know about forest trusts sharing UPN Suffixes across multiple forests, the collision detection enforcement that triggers, or how authentication with different username formats would apply. After my initial testing and research, I gathered this conclusion:

Authentication with UPN fails. Authentication with NetBiosName\SamAccountName works. The code uses UPN. Let's change that.

WebApp is Confused... It hit itself in its confusion!

Now let's examine what's happening in the code. Well, some abstract pseudocode, at least.

// Search for user in forest & trusted forests
user = findUserByclaims(claimAttribute, claimValue);

// Throw error if no user was found
if (user == null) {
    throw new Exception("User could not be identified from the provided claims.");
};

// Else, create WindowsIdentity object from UPN and impersonate
else {
    // Error is here
    WindowsIdentity userIdentity = new WindowsIdentity(user.upn);

    userIdentity.Impersonate();
};

So when a user federates to WebApp, I first search for that user's Active Directory account in the current domain and all trusted domains and forests based on the provided claims. If I find an account, I then try to instantiate a WindowsIdentity object from the user's UPN value, and then impersonate that user.

The problem doesn't occur on the .Impersonate() method as I thought it might, but when trying to create the WindowsIdentity from the UPN value. This works perfectly fine for users in example.com and users in company.com who have a routable UPN Suffix, but not for users in company.com who have a non-routable UPN Suffix, i.e. acme.com which exists in both forests.

Okay, easy fix. I'll just use NetBiosName\SamAccountName instead of userPrincipalName. Unfortunately, that throws an error.

An unhandled exception of type 'System.Security.SecurityException' occurred in System.Security.Principal.Windows.dll: 'The name provided is not a properly formed account name.'

Okay, what else can I try? Let's read the docs for the WindowsIdentity class.

Why Documentation is Sometimes the Enemy

Here's where the aquatic assault began as red herrings attacked me from all angles. Per the docs, I am using this constructor, which just requires the user's UPN as an argument. Assuming the service account has the right permissions, creating a WindowsIdentity object with this constructor will automatically retrieve a token for that user via the LsaLogonUser function, utilizing the KERB-S4U_LOGON structure. This is how WebApp can then impersonate the user without knowing their password. Per the docs:

...The UPN identified in sUserPrincipalName is used to retrieve a token for that user through the Windows API LsaLogonUser function. In turn that token is used to identify the user. An exception might be returned due to the inability to log on using the supplied UPN.

...this constructor uses the KERB_S4U_LOGON structure, which was first introduced in Windows Server 2003

It's clear as day, right there in the remarks! LsaLogonUser may fail due to the UPN value I'm supplying. So what I really should be doing is...calling LsaLogonUser directly with my own arguments and using a different WindowsIdentity constructor that accepts the Kerberos Token that returns...right?

I Was Not Right

And here begins a furious, relentless, desperate session of intense Google-fu, prying for any relevant sample code to copy/paste. Sprinkled with very reassuring StackOverflow threads annotating that I'm wading in waters that have never been waded in before, experiencing a unique issue that no one but me seems to understand.

...In conclusion

There is only one use case were[sic] LsaLogonUser is better than LogonUser. But since WindowsIdentity provides a constructor for that (S4U), I don't see why one would ever use LsaLogonUser in a .Net application.

No, ixe013, Security Engineer at Google, there are TWO use cases! I've outsmarted you! Now please point me to sample code that my (at this point) fully-rotted-husk of a brain can steal!

Of course, ixe013 was right. The more I looked, the more the realization struck that even if I had to use LsaLogonUser myself, it's...uhh...very complicated. Daunting. The thought alone gives me stress-induced cold sweats and shivers.

I started looking elsewhere, digging into Kerberos Authentication, the details of Forest Trust Relationships, "how the f*** does IIS Basic Auth work". Finally, I looped back to a simple question.

What even IS a UPN?

The Lightbulb/Eureka/Got'Em Moment...It's Super Effective

Buried deep in the comments section of yet another long-abandoned StackOverflow thread, I encountered a link to this 2010 series of articles from the Jorge's Quest for Knowledge Wordpress site. Jorge's Knowledge reminded me of a basic fact about UPNs, which had been so irrelevant to me for so many years that my hollow husk-brain never once considered it as the obvious answer it was.

Users have 2 UPNs.

1. Explicit UPN (eUPN). This is the value that shows in the user's userPrincipalName attribute, and is configurable on every user account. This value contains my particularly frustrating UPN Suffix that breaks the rules of a forest trust.
   jacob@acme.com

2. Implicit UPN (iUPN). ALL users have this, whether you define an eUPN or not, but is not stored in any AD Attribute. The iUPN is always available in the format sAMAccountName@FQDN.
   jacob@company.com

Yeah, it was that simple the whole time. Instead of passing the user's userPrincipalName attribute, I can pass the iUPN instead. new WindowsIdentity("jacob@company.com");. It doesn't matter that Jacob's UPN attribute is jacob@acme.com. I have the domain, and I have a user object with a bunch of AD Attributes, including sAMAccountname. Sure enough, this solves the issue with an incredibly simple code change. No tricky LsaLogonUser implementation, no major code rewrite. Just send a different value for UPN that uniquely identifies the user across all trusted forests.

As a side note, if you're also thinking "well, he isn't authenticating to ADFS with jacob@acme.com either", you're correct. But, this is federation. It could be ADFS or any other SAML or WS-Fed provider, and I'm not necessarily getting the value entered in the username field, or even the UPN as a claim. It might be something else like objectGUID or email. Either way, I'm still searching for his AD account across all trusted forests/domains, and attempting to impersonate him with a UPN value.

You Defeated Trainer "Annoying Problem". You Gained ¥100.

Here are my final takeaways.

1. Breaking down the problem into simple, testable scenarios is always a great first step.

2. Occam's Razor is often the reason I can't sleep.

3. Documentation doesn't lie, but it often omits relevant details for niche situations.

4. The StackOverflow user you think is wrong probably isn't.

5. I don't know how to write .NET apps.

6. Heading sections of your blog post with Pokémon references is always a great first step.

1. "We have an IGA solution. It already manages our Active Directory just fine. Why do I need this?"

2. "We don't have an IGA solution yet, but would like to implement one in the next X months/years. Wouldn't we just be repeating ourselves if we implement this now?"

3. "We have an IGA solution. It's not quite doing everything we need in Active Directory today, but it could with additional implementation. Why would we bring in a separate solution for that?"

These situations come from customers on all points of the "Identity Security Maturity" spectrum. Those who have nothing in place or some things in place or an entire stack of fully implemented solutions in every category. Although all of them have different needs, pain points and solution gaps, as long as they have Active Directory (AD), they all need an AD Management solution like Active Roles.

Before discussing the benefits Active Roles provides that Identity Governance & Administration (IGA) solutions can't, it helps to highlight what each of these solutions is designed to do, what they typically do and where they overlap.

IGA Solution Overview

IGA solutions, like Identity Manager by One Identity, aim to fully govern the identities within your organization. This includes all accounts, entitlements, permissions, etc., across your entire on-premises and cloud infrastructure. These identities typically include employees, contractors and others who need access to any number of corporate systems. Often, this extends to vendors and other third parties, and sometimes service identities, customers and more. The picturesque end goal is to build a consolidated, unified source for all identities that have access to anything within your organization by correlating data from source systems, like an HRIS or ERP, and by automatically controlling the access they have to all possible target systems, like AD, email, on-premises and cloud applications.

IGA solutions offer a broad spectrum of capabilities, and anyone who's implemented one knows that it's not just a project to implement these features, but an ongoing journey.

Common Features of an IGA Solution

• Identity/User Lifecycle Management (ILM/ULM): Automated provisioning of user access to all target systems within your environment, access changes within those systems stemming from requests or role changes and deprovisioning of access to those systems

• Role-Based Access Controls (RBAC): ILM/ULM processes are commonly driven in part by roles granted automatically to identities based on attributes like their job title, department or location

• Self-Service Access Requests: End users or their managers can request appropriate access to target systems or applications needed to do their job, usually with an approval process

• Access Management for Administrators: System admins and owners can manage who has access (and how and when) to the systems or applications that they are responsible for

• Attestations (a.k.a Certifications): System owners, managers and others can be required to perform regular, or ad-hoc, campaigns to ensure that only the right people have the right access to the right systems at the right time

• Segregation/Separation of Duties: Policies enforce the access identities have across all managed target systems so that no inappropriate access is possible, outside of exceptions that are configured, approved, logged and auditable

• Reporting & Auditing: Custom reporting features and audit portals allow the necessary people to ensure that all access is correct and/or to validate how and why someone may have inappropriate or otherwise non-compliant access across all target systems

In summary, IGA solutions are identity centric. They keep track of a person. This person was created directly or came from some other source system. This person has access to one or more target systems, and within those, they have entitlements. The entitlements they have in those systems are managed automatically via RBAC rules based on data from the source system or from that access being requested, and is kept in check by system owners and managers testifying to that access regularly. When that person is no longer with the company, all their access is removed.

IGA solutions, generally, treat Active Directory just like any other target system. However, Active Directory is much more than just an application that employees need access to.

AD Management Overview (Active Roles)

Active Roles, on the other hand, aims to be your "Swiss Army Knife" for securing access to and performing day-to-day operations in AD. And, whenever I say "AD," that includes Exchange, Azure AD and Microsoft 365. While IGA solutions focus on identities or people, Active Roles focuses on directory objects (e.g., user accounts, groups, OUs, mailboxes, computers, etc.).

At the core of Active Roles is its delegation model, which acts somewhat like a proxy or a firewall in front of AD, providing fine-grained access controls to enforce a true least privilege access model for all users and administrators. Think of this as Privileged Access Management (PAM) for AD and Azure AD. Taking advantage of this and other features in the toolset further allows you to:

• Enforce data standards to ensure that your objects and their attributes align with your requirements

• Automatically organize objects into virtual containers based on queries or group memberships, and delegate access to those objects

• Manually or automatically clean up unused and non-compliant objects

• Simplify Help Desk processes and shift responsibilities from Help Desk staff to system owners and managers

• Automate the management of directory objects and much more

In short, they're designed around two entirely different paradigms, and each have distinct features. However, the slight functional overlap is what often brings about confusion.

The Functional Overlap

There are three key functions that both IGA solutions and Active Roles can perform, to varying degrees, in AD and Azure AD:

1. Identity/User Lifecycle Management (ILM/ULM)

2. Role-Based and Attribute-Based Access Controls (RBAC/ABAC)

3. Administrative Access

When an IGA solution is in place, or is planned for implementation, best practices dictate that it be the driver of these functions for your employees. So, to reiterate, why would you still need Active Roles? Let's return to the two questions from the beginning of the article and discuss how it fits into both scenarios.

AD-Centric Identity

We don't have an IGA solution yet, but would like to implement one in the next X months/years. Wouldn't we just be repeating ourselves if we implement this now?

This approach is typically for organizations that are new or not very mature in their identity strategy, and for whom AD is the primary source of user access. In this scenario, Active Roles provides User Lifecycle Management capabilities to provision, update and deprovision AD accounts for your user identities.

User Lifecycle Management

For those that have a reliable HR system or another accurate employee data source, this process can be entirely automated with the Active Roles Synchronization Service. For those that don't, users can be managed semi-automatically via the Active Roles web interface. You can delegate appropriate access to those with the authority to create, update and de-provision user accounts and streamline the process by auto-generating certain attributes, restricting certain fields (like department or title) to a predefined list of options or automating additional provisioning tasks with workflows. So, even if manual provisioning is required, the entire process can be delegated and streamlined.

Role-Based and Attribute-Based Access Controls

Active Roles can automatically assign access to AD groups via dynamic group membership. This membership is calculated based on a query you configure and is updated automatically whenever a user's relevant attributes are changed. Based on group hierarchy and the query logic, this can enable both RBAC and ABAC.

Administrative Access

By "Administrative Access," I mean delegating responsibility to people within your organization to manage some degree of operations on users or objects. Active Roles is designed around its delegation model for AD, which allows you to grant permissions to people like HR, Help Desk staff and system owners to manage the users, groups or other objects they are responsible for.

Summary

For an AD-centric organization, Active Roles is a simpler, more lightweight approach to quickly get started with building an identity strategy when compared to the more laborious process of implementing IGA. It gets you from a state of little-to-no identity management into a state where you have automated lifecycle processes, clean and accurate user data, roles defined for users based on their attributes and a clear idea on who needs access to manage these users.

As your organization matures and your needs expand to include IGA capabilities, you already have a clear model in place to jumpstart that project. Or, in the case of Identity Manager, the direct integration with Active Roles can utilize much of what you've already built, allowing you to focus your implementation on other target systems.

Meanwhile, Active Roles is still utilized for the other functionality it offers that is either not possible in your IGA solution or not rational to do with IGA.

IGA for Identities, Active Roles for Everything Else AD

We have an IGA solution. It already manages our Active Directory just fine. Why do I need this?

For organizations that already have an IGA solution, or otherwise don’t need to manage the lifecycle of user AD accounts, the premise is this:

IGA covers your employees, contractors, vendors, etc. It creates their AD accounts with the appropriate access, updates their access upon role changes, access requests and attestations and de-provisions their account upon termination. However, managing AD requires much more than managing employee user accounts.

AD Management Questions to Consider

• Who’s responsible for and how are they currently managing the following: organizational units, groups, mailboxes, service accounts, computers, contacts, etc.?

• Is everything structured in a way that makes sense for your business requirements?

• Does access to AD objects follow a least privilege model? Remember, by default, everyone in your organization has full read access to the directory

• Do all your other AD objects follow the standard practices that you've defined within your organization? Here are a few basic examples:

  • Service Accounts

    • All begin with SVC_

    • Have an owner, description and department assigned

    • Are set to “Password Never Expires”

    • Have a “Service Type” attribute set that is either “Server, Database, Application or Other,” and have a computer object assigned to the “Server” attribute if “Service Type” is set to “Server”

  • Computers

    • Are linked either to a user (for workstations) or an owner (for servers)

    • Have a “Cost Center” attribute that’s restricted based on a list populated by a data feed

    • Have an "Eligible for Refresh Date" attribute, which is auto-calculated based on the date they were created, and eligible computers are automatically available in a custom container where IT staff can see them

  • AD Groups

    • Have a primary and secondary owner who have the ability to manage attributes of that group and its memberships

    • Require approvals if anyone besides the owner changes the group memberships

    • Have an “Applications” attribute to denote which apps they grant access to

  • Are you tracking unused objects and risky permissions and either automatically remediating those or delegating restricted access to manually remove them? For example:

    • A team of three people has access to all computer objects that have not logged on in more than 90 days. They can read all properties, disable the object, change the owner and check/uncheck an "exception" that requires approval from an IT admin before they are removed from the list

    • Changes to domain admins, enterprise admins and other privileged groups require multi-step approval and trigger notifications to administrators. This membership is evaluated regularly and, where possible, access is granted via more fine-grained permissions

    • De-provisioned groups and user accounts, including service accounts, are automatically deleted after a retention period. Disabled objects that are not scheduled for deletion are regularly checked and remediated appropriately

Enhanced Active Directory Governance

We have an IGA solution. It's not quite doing everything we need in Active Directory today, but it could with additional implementation. Why would we bring in a separate solution for that?

Whether it’s due to time constraints, budgetary limitations, a lack of planning, or some combination thereof, IGA implementations rarely account for the entirety of the nuances of managing accounts in a complex enterprise AD environment. Too often, there are elements missing within role definitions, workflow processes, attribute generation rules, and so many other nuances that may, quite frankly, be a bit of a headache to architect in IGA, but are mandatory to achieve a healthy AD. We need to not only cover the previous scenario, where Active Roles governs the non-identity objects in Active Directory, but break the dichotomy and allow its functionality to supplement what's already being driven by IGA, enabling Enhanced Active Directory Governance.

Common Pitfalls of IGA Solutions with AD Account Lifecycle Management

• Role definitions are too broad in scope, requiring manual assignment of hundreds of AD groups that could otherwise be assigned automatically by a more granular set of Attribute-Based Access Controls. The Dynamic Group functionality discussed earlier enables this easily, while still allowing IGA to governs the account by controlling the attribute data upon which the Dynamic Group engine operates.

• Accounts do not flow in and out of all the appropriate OUs throughout their lifecycle, causing issues in reports, downstream automations, and Group Policy assignments. This often gets extra complex with employees transferring between subsidiaries, contractors becoming full time employees, or many of the vertical-specific complications like student workers. With Active Roles, simple Change Workflows can detect user account creations and attribute updates to place objects in their correct OUs throughout their entire lifecycle, bypassing the need to configure those logic flows in the IGA solution.

• Certain attributes, especially multi-valued attributes with specific formatting expectations, are not being set correctly; others, especially custom schema attributes, are not being set at all. Some of those attributes combine multiple fields with complex logic that is then used for reporting purposes, but those are still being controlled by custom powershell scripts because it's a larger effort to define that with the IGA solution. Active Roles can define Provisioning Policies to enforce attribute values and naming conventions, or otherwise fully generate the values of any attributes with a simple-to-use rule engine that is purpose designed for AD.

• Helpdesk staff, IT administrators, and even HR still regularly access AD directly to make changes to user accounts and other objects, often when immediate changes are required or synchronization errors occurred. Since this doesn't go through IGA, there is no enforcement around these changes or an audit trail for them. This returns to the topic of Administrative Access or Delegated Administration, where least-privileged permissions can be delegated to any staff who needs to manage objects in AD, and the same policies and workflows mentioned earlier can be used to enforce standards and naming conventions, prompt for approvals, automate tasks, and so much more, while all actions are logged in an audit trail.

Summary

Active Roles enables you to delegate access to any user to make only the changes they need to in AD, streamlines the day-to-day management of AD and provides capabilities that native AD tools and IGA solutions don't offer.

Could you build some of this in an IGA solution to meet your requirements? Sure, most IGA solutions are endlessly customizable. However, the effort involved would be extensive, the user experience would be more complicated and lacking and extending it to adapt to future requirements would be daunting. IGA solutions are simply not designed for directory management the way Active Roles is.

To stick with the "Swiss Army Knife" analogy: you can consider both IGA and Active Roles as multitools, but with different tools available. They both have a screwdriver, scissors and a file. However, IGA has a serrated knife and a bottle opener, while Active Roles has a straight blade and a can opener. Sure, you could use IGA's serrated knife to open a can, but it's going to be tedious, and you'll probably cut yourself a few times. The same applies the other way around. The straight blade could probably open a bottle, but I'm not going to try that when I have a bottle opener.

However, by combining both tools and using each where they make the most sense, you can achieve full governance of all your identities, their AD accounts, and all your other AD objects and eliminate all chaos from AD.

External Links

View this article elsewhere:

• One Identity Blog

It's a good question, and if you're curious about whether any of your email addresses or passwords were included in a data breach, you can easily find out at HaveIBeenPwned.com. This entirely free service, managed by Microsoft Regional Director & MVP Troy Hunt, lets you enter an email address or password to see how many breaches it has been included in. For an email, it goes as far as informing you which breaches included your data, and you can check the "Who's been pwned" page to get the full list of breaches included in the repository. If you want to go really crazy, you can download the entire pwned passwords list as a torrent, in SHA-1 or NTLM formats.

It Gets Better

Have I Been Pwned also includes a set of APIs that you can use to programatically access data from the collection. The PwnedPasswords endpoint allows you to check if a Password appears in the pwned passwords list using a REST call. The best part is this is entirely free, with no rate limits or license requirements!

Can I trust this site?

Well, I'll leave that entirely up to you, but Troy is a highly respected security expert, and you can read all about the Have I Been Pwned service, how it handles privacy, and what all this stuff means directly on the website, as well as tons of detailed blog posts on Troy's website. The short answer is that this is a well-known, trusted, and secure service that's been used by organizations and government entities all around the world for years as another security layer to protect against attacks like Password Spraying and Credential Stuffing. In the end, I'll just reiterate Troy's own words from the FAQ:

The site is simply intended to be a free service for people to assess risk in relation to their account being caught up in a breach. As with any website, if you're concerned about the intent or security, don't use it.

How does this apply to me?

Glad you asked. The short answer is we can use this service with One Identity Password Manager to ensure that the passwords your users are setting have not been compromised in a data breach!

I've talked before about One Identity Password Manager, and how configurable and customizable it is. One of the configurable options is to enable the "Credential Checker on" setting, which runs all passwords through a Powershell script before allowing users to set them. See where I'm going with this?

By default, this script utilizes a service called CredVerify from VeriClouds, which requires authentication. If you have, or can obtain, a URL, Client Key, and Client Secret for this service, you can simply plug them into the script and get going.

However, we can use Have I Been Pwned as an alternative, which is totally free, and has no authentication requirements or rate limiting for the PwnedPasswords API!

The full script, and install instructions, are available on GitHub. You can simply replace the out-of-the-box script with the new one, enable the "Credential Checker on" setting, and you're good to go. Your Password Reset processes will now reject any passwords found in the HIBP database.

If that's all you need, head on over to GitHub and get going! If you're interested in the details of how this all works, keep reading.

Exploring the PwnedPasswords API

The first thing to get straight is that HIBP passwords are provided as SHA1 hashes. Now if you're thinking SHA1? Isn't that an unreliable algorithm these days?, I'll let Troy speak for himself:

It doesn't matter that SHA1 is a fast algorithm unsuitable for storing your customers' passwords with because that's not what we're doing here, it's simply about ensuring the source passwords are not immediately visible.

When the PwnedPasswords API was first launched, you could query the API with the full SHA1 hash of the password to return any hits. However, version 2 improved privacy (and speed) by introducing Cloudflare's k-Anonimity model. This model is still in use in the current version 3 of the API, and if you're still not convinced, have another Troy Hunt blog post explaining the model in depth.

How do we use this thing?

In practice, the model for this API works by accepting a 5 character substring of the SHA-1 hash for a password, and returning a list with all matches, only containing the remaining substring of the hash. Sounds more complicated than it is, let's walk through it.

Take my incredibly secure password, "Password123". First, I need to compute the SHA-1 Hash of that password. With Powershell, that's simple enough.

PS C:\> $PlaintextPassword = "Password123"
PS C:\> $PasswordStream = [IO.MemoryStream]::new([byte[]][char[]]$PlaintextPassword)
PS C:\> $HashedPassword = (Get-FileHash -InputStream $PasswordStream -Algorithm SHA1).Hash
PS C:\> $HashedPassword
B2E98AD6F6EB8508DD6A14CFA704BAD7F05F6FB1

Now to..."k-Anonymize". We need to send the first 5 characters of the hash to HIBP, so let's call that the $hashPrefix and the remainder of the hash the $hashSuffix.

PS C:\> $hashPrefix = $HashedPassword.Substring(0,5)
PS C:\> $hashPrefix
B2E98

Great, now we can send that to the PwnedPasswords API to get a list of matches. But first, we need to ensure we are using at least TLS 1.2

PS C:\> [Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12

Now we can make our REST Web Request:

PS C:\> $url = "https://api.pwnedpasswords.com/range/$hashPrefix"
PS C:\> $HIBP = Invoke-RestMethod -Uri $url -Method GET -UseBasicParsing

If we inspect the $HIBP response, we'll see that it's a large string of newline-delimited results. Each of these results contains a hash suffix for a matching password beginning with our prefix, followed by a colon (:) and the count of how many times that password has appeared.

PS C:\> $HIBP
004FAC2FA6779235D4D835A4B518D563F3F:3
00540184B698E09B3977E74434933FF1A6D:8
0078FBA31E1A8034F55AAB06C61337D377A:1
00D24723161C97D6C16B9139B1279DD7B53:2
01183CA5E4C40A960A98EC3F9DB4A705007:1
011969830985B5E941F7285B22393130EA0:1
0123A5B3069D0CA31210A184BB79927B9C9:64
012A94FB50CFC1267DEC3EE8C3826AA2405:3
01A148B7911D34BC9697D1FB203706D00BC:1
01E8A15747D1289B6E8D960008BC990C798:1
01FB7A423C3AD369B173E4F88EC836B1BA9:2
0283F368CB5A6850390AF940A4D79097637:4
02A5DB2458D4235579AED00A5D6304F6043:2
032BF92F00C1C365999BCE1F6B8A74403BD:1
045EB79206C8C42998D632FB0619542ABEB:1
...

For our purposes, we really only care about 1 thing. Is our original password hash in this list of breached passwords? To check, we need to standardize this response.

We first need to split this giant string into an array of strings, one item for each line. We can split on the newline character with $HIBP.Split("`n"). Then, we can loop through each of these lines and do 2 things.

1. Split it on the colon (:) so we can parse out the $hashSuffix in the first index [0].

2. Append the original $hashPrefix to the beginning of the string.

Finally, store the result of this in a nice $HashMatches array.

$HashMatches = ForEach ($result in $HIBP.Split("`n")) {
        $hashSuffix = $Result.Split(":")[0]
        "$hashPrefix$hashSuffix".ToUpper()
}

PS C:\> $HashMatches
B2E98004FAC2FA6779235D4D835A4B518D563F3F
B2E9800540184B698E09B3977E74434933FF1A6D
B2E980078FBA31E1A8034F55AAB06C61337D377A
B2E9800D24723161C97D6C16B9139B1279DD7B53
B2E9801183CA5E4C40A960A98EC3F9DB4A705007
B2E98011969830985B5E941F7285B22393130EA0
B2E980123A5B3069D0CA31210A184BB79927B9C9
B2E98012A94FB50CFC1267DEC3EE8C3826AA2405
B2E9801A148B7911D34BC9697D1FB203706D00BC
B2E9801E8A15747D1289B6E8D960008BC990C798
B2E9801FB7A423C3AD369B173E4F88EC836B1BA9
B2E980283F368CB5A6850390AF940A4D79097637
B2E9802A5DB2458D4235579AED00A5D6304F6043
B2E98032BF92F00C1C365999BCE1F6B8A74403BD
B2E98045EB79206C8C42998D632FB0619542ABEB
B2E98049670AA6A430AE0911C189E8E456FF92E0
...

Great, we have a lovely array filled with hashes that begin with the same 5 characters as our password's hash. Now we just need to see if our password is in that array, and if so, return $true.

$PasswordLeaked = ($HashedPassword.ToUpper() -in $HashMatches)
Return $PasswordLeaked

And of course, we can wrap all this up in a cmdlet, let's call it Confirm-PwnedPassword. As part of that, it should also be able to support both a plaintext password and a SHA1 hash as options, just for flexibility. If it receives a plaintext password, it can perform the hashing function before processing.

function Confirm-PwnedPassword {

    [cmdletbinding()]
    param(
        [parameter(position=1,mandatory,ParameterSetName="Plaintext")]
        [string]
        $PlaintextPassword,

        [parameter(position=1,mandatory,ParameterSetName="Hash")]
        [string]
        $HashedPassword
    )

    if ($PSCmdlet.ParameterSetName -eq "Plaintext") {
        # Get & Hash the entered password
        $PasswordStream = [IO.MemoryStream]::new([byte[]][char[]]$PlaintextPassword)
        $HashedPassword = (Get-FileHash -InputStream $PasswordStream -Algorithm SHA1).Hash
    }

# the rest of the cmdlet here

The full function can be found in a standalone Confirm-PwnedPassword.ps1 script in the associated GitHub Repo, along with all the other files for this project.

Password Manager's Built-in Credential Checker

We now have a nice cmdlet to check if a password appears in the PwnedPasswords database, so how do we get Password Manager to run that against a user's about-to-be-set password?

The out-of-the-box Password Manager Credential Checker runs a Powershell Script that comes included with the Password Manager installation. This script runs 2 functions with specific data passed in for the parameters. We just need to modify this script appropriately.

The Script

With "Credential Checker On", any time a user tries to set a new password, it will first run this script against their username & password to determine if that should be accepted.

Get-HashAlgorithm returns a string for the hashing algorithm that Password Manager should use to hash the user's password. This defaults to SHA1, which is what we need for the PwnedPasswords API. Password Manager will hash the password using this algorithm before passing it into the following function.

Test-IsCompromisedCredential takes the username of the user resetting their password, and the SHA-1 hash provided by Password Manager, and runs some code with those parameters. If this code returns $true, Password Manager will reject the password the user entered.

To make this work with the PwnedPasswords API, all we need to do is plug in our Confirm-PwnedPassword cmdlet, and call that inside Test-IsCompromisedCredential, instead of the default API call to CredVerify.

Putting this all together, first Password Manager will run Get-HashAlgorithm, which will return the string SHA1. Next, Password Manager will hash the about-to-be-set password using the SHA-1 algorithm. Finally, Password Manager will call Test-IsCompromisedCredential, passing in the username to the $username parameter, and the SHA1 hash for the $passwordHash parameter. If that returns $true, the password will be rejected, and the user will see an error message. Otherwise, the password will be accepted, allowing the workflow to continue.

Some solutions, like the default CredVerify, check the combination of username and password against their database. Since HaveIBeenPwned only needs the password, we can simply ignore the $username parameter.

Conclusion

You now have another method of increasing your password security by ensuring your users can't set passwords that have been released or compromised as the result of a breach. If you're following NIST best practices for passwords, you'll know that this is one of the key principles:

Compare the set password against the list of breached passwords (commonly used passwords).

Take this a step further and combine this with a Password Policy that prioritizes length over complexity, restricts usage of particular AD Attributes in the password, and utilizes a curated dictionary. Even better, make sure the authentication process for your forgotten password process includes MultiFactor Authentication.

As always, you can keep up with the latest code changes on my personal GitHub or grab the latest stable release on the One Identity GitHub. Refer to the README for instructions.

One Identity GitHub Note

One Identity open source projects are supported through One Identity GitHub issues and the One Identity Community. This includes all scripts, plugins, SDKs, modules, code snippets or other solutions. For assistance with any One Identity GitHub project, please raise a new Issue on the One Identity GitHub project page. You may also visit the One Identity Community to ask questions. Requests for assistance made through official One Identity Support will be referred back to GitHub and the One Identity Community forums where those requests can benefit all users.

External Links

View this article elsewhere:

• One Identity Blog

Read it on the One Identity blog, One Login blog, or my personal blog

In that scenario, a user with a forgotten or expired password authenticates to the self-service portal with a combination of their Security Questions and MFA provided by OneLogin in order to reset their password.

With the release of Password Manager 5.11, we can take this a step further by enabling MFA and/or Single Sign-On for Admins and Helpdesk staff accessing Password Manager using OneLogin, or any other IdP (Identity Provider) that supports standard protocols like SAML (Security Assertion Markup Language).

Introducing Secure Token Server

I'll spare you the details on what this is and keep it simple. rSTS is the same component used in other One Identity products, like Safeguard for Privileged Passwords, to provide federated authentication or multi-step authentication using various providers and protocols like SAML, OAuth, RADIUS, and more. This has now been brought over to Password Manager for use within workflows, and for authentication to the helpdesk and admin web interfaces.

The cybersecurity frameworks, cyber insurance companies, and consulting firms are all correctly on the same page — MFA should be required for access to any privileged application. The admin and helpdesk pages for Password Manager are no exception. Admins can configure the product to do whatever they desire to accounts on all the included domains. Helpdesk staff often have access to unlock or enable accounts, reset passwords, issue BitLocker recovery keys, and more. Enabling MFA as a requirement to access these resources is a logical step towards securing your password reset process.

Options, options...

There are 2 supported methods of configuring federated authentication for the Password Manager Admin and Helpdesk pages, and since I love having options, I'll walk through them both.

• External Federation (SSO)

• Primary Directory Authentication + Secondary Authentication

External Federation (SSO)

This is a common standards-based scenario where your external Identity Provider of choice acts as the authentication mechanism. This can be both Service-Provider Initiated — where a user navigates to the Password Manager admin or helpdesk portal and gets redirected to the IdP (Identity Provider) for authentication — and Identity-Provider Initiated — where a user signs in to the IdP and clicks an icon on their dashboard to SSO into Password Manager.

Let's use OneLogin as an example. Since it supports SAML2.0, I can create a SAML application called Password Manager, point it to the Password Manager STS (Secure Token Server), and configure Password Manager to use that application for authentication.

When I access Password Manager's Admin or Helpdesk pages, it will automatically redirect me to authenticate through OneLogin.

But we can take this a step further. OneLogin QuickLinks allow you to create custom applications that show up on the user's SSO Dashboard. These can simply be a URL that the link takes them to, with a custom name and icon to make it easy to identify. So, you can have a single SAML application to handle the authentication, and a QuickLink each for the Admin and Helpdesk pages, that can be assigned to users appropriately.

When users sign in to their OneLogin Dashboard, they'll see these links if they are assigned:

Clicking the link will take them directly to the associated Password Manager URL. And, since they are already authenticated to OneLogin, they'll be automatically signed in.

Right, but what about the MFA?

Of course, the user may already have to authenticate with a second factor when initially signing into their OneLogin dashboard. However, depending on your configuration, this may not be the case. Certain OneLogin Users may have a Security Policy that does not require a second factor when authenticating to their dashboard, or you may be using OneLogin SmartFactor Authentication to suppress the MFA prompt when a low-risk sign-in is detected. In order to ensure MFA is provided when accessing critical applications, regardless of how the user authenticates to their dashboard, OneLogin allows you to create application-specific security policies.

These policies allow you to force an MFA prompt for specific applications, and can of course be configured to suppress that prompt for those users who already provided one in the last X minutes, to avoid multiple prompts in a row.

With an Application Security Policy that requires MFA assigned to the Password Manager SAML application, we can ensure that users will always need to provide a second authentication factor in order to access the Password Manager Administration and Helpdesk pages.

What about other IdPs?

Other Identity Providers have their own processes for configuring SAML, OAuth, or WS-Fed authentication, but it's all the same to Password Manager. Even better, it can support multiple Identity Providers for different user groups federating from multiple domains. Keep in mind, however, that this scenario typically expects the Identity Provider to handle both the Primary & Secondary authentication...but it doesn't have to!

Primary Directory Authentication + Secondary Authentication

Our STS allows you to separately configure a primary and secondary authentication method from a choice of standard providers. Want to still have AD (Active Directory) Authentication but use a RADIUS server for MFA? No problem! How about LDAP (Lightweight Directory Access Protocol) & Duo? That works too.

This scenario is more flexible for organizations who are not standardized to an IdP across the board or have existing standalone MFA solutions that only provide secondary authentication and rely on a primary authentication source like Active Directory.

Summary

Whether you're fully committed to the latest and greatest of security frameworks, fighting an uphill battle to implement any security controls you can, or balancing security and usability concerns anywhere in between, One Identity Password Manager offers configuration and extensibility options to help you design a secure password reset process that adheres to your unique requirements, without compromising the experience for your end users.

Requiring MFA for the privileged Admins and Helpdesk Users accessing Password Manager, and for the end users performing password resets, is one of the easiest first steps you can take towards securing the entire process.

External Links

Read the first post in the series on Secure Password Resets with One Identity Password Manager:

• One Identity Blog

• One Login Blog

• My Personal Blog

View this article elsewhere:

• One Login Blog

• One Identity Blog

As a Solutions Architect, the best part of my job is finding ways to make our products do what our customers want them to do...even when they don't exactly do that. So, when One Identity acquired OneLogin last October, we entered an exciting interim period—a time during which our products would not have native, built in, fully-supported integration, but one in which we would soon be selling integration, and customers would be asking to see integration.

So began a mad dash to configure, script, and pull together all the integrations we could feasibly manage--Single Sign-On into everything (Active Roles, Safeguard, Identity Manager) via native federation support (SAML2, WS-FED), lifecycle management of OneLogin accounts from Identity Manager via the API, device-level MFA using One Identity Defender (major kudos to Eric Hibar Jr. for that one). And, the topic of this blog post, OneLogin as a Multifactor Authentication step during a Self-Service Password Reset (or really ANY workflow) in One Identity Password Manager.

One Identity Password Manager

For those unfamiliar with Password Manager (PWM), it's a secure enterprise Self-Service Password Reset (SSPR) tool. What's particularly relevant here is that PWM is highly configurable and customizable, with a drag-and-drop interface for building end-user workflows, and custom activities built with PowerShell (my favorite!) and an in-depth SDK.

In short, you can customize the entire process an end-user goes through to do anything in PWM. In particular, we'll focus on a secure Password Reset.

OneLogin by One Identity

For those unfamiliar with OneLogin, it is a Market-Leading Identity & Access Management platform, providing SSO, MFA, Unified Directory, User Lifecycle Management, and so much more.

For this integration, we will focus on Multi-Factor Authentication (MFA) to include as part of a PWM workflow.

Sidebar: Standards-Based Authentication (RADIUS)

There's a reason I'm calling this "API-Based" MFA, and not just "MFA" or "OneLogin Integration" — RADIUS. PWM natively supports the RADIUS protocol to provide multifactor authentication in any workflow. And, of course, OneLogin includes a RADIUS server that PWM can authenticate against. Since Day 1 (okay...maybe day 7) of our OneLogin acquisition, we've been able to demonstrate and support this scenario.

But there are limitations.

1. RADIUS only works with TOTP or Push-based Security Factors in OneLogin.

   • OneLogin Protect

   • Authenticator (TOTP-based)

   • RADIUS Token

2. RADIUS only works for your primary Security Factor in OneLogin. You cannot select a different factor.

3. RADIUS configuration & customization options in PWM are limited.

   • There can only be 1 RADIUS provider configured for a PWM instance, that applies across the entire user base.

   • Customizing the text on the RADIUS action requires modifying an underlying .xml file, and therefore needs to be carried over and accounted for during upgrades

   • There is no SDK method for executing a RADIUS authentication with the stored RADIUS configuration, so a custom action cannot be built without implementing your own RADIUS authentication via PowerShell

Now, One Identity used to have an in-house MFA Solution, Starling 2FA, that had native support in PWM for auth via an Android & iOS app, as well as SMS, Email, and Voice. RADIUS by definition cannot support all of these features...but OneLogin can, with its REST API.

My Over-Zealous Plan

Before I even read the documentation of the OneLogin API, one of my talented colleagues in EMEA shared a set of scripts to do...well...exactly this. Use OneLogin for MFA in PWM. But also create users, register new Security Factors...really a whole dev kit of useful sample scripts (some more useful and relevant than others) that immediately grabbed my attention.

Now, my initial reaction was not to pop this into my lab and call it a day, or just to refactor it to fit the Unofficial PowerShell Style Guide (which, let's be honest...I rarely follow completely). It was "hey, pretty much all of our products support PowerShell for extensibility, it would be REALLY cool if there was a PowerShell Module SDK that wrapped the OneLogin API!

There was not

So, I thought "I can write that," and started working on what would be my first major PowerShell Module.

Perhaps I focused too much on trying to do it proper, and official or whatever, but after dumping tons of time and effort into the development with nothing to publicly share, I realized my scope was a bit large to start, at least for an "as I get the time during work hours" side project.

After getting the framework of an SDK, and wrapping enough endpoints to process MFA requests, I shifted focus to making this work seamlessly with Password Manager.

Introducing...

Password Manager: API-Based MFA with OneLogin

I am excited to release this project, which allows you to utilize the OneLogin REST API to provide flexible, secure Multifactor Authentication capabilities to Password Manager Workflows, without the limitations of the RADIUS protocol.

Take advantage of PWM's extensibility, and OneLogin's powerful REST API to support a wide range of Security Factors, so your users can authenticate the way they prefer:

• OneLogin Protect

• Voice

• SMS

• Email OTP & Magic Link

• TOTP-based Authenticators (e.g. Microsoft, Google)

The included OneLoginByOneIdentity Powershell Module takes care of all the necessary steps to interact with the API, so the PWM Actions can focus on the logic. This "early stages" SDK can also be used to streamline other OneLogin automations.

By utilizing features of the PWM SDK, the UI is generated by the code; no UI elements need to be created manually.

Sample exports of the actions, and an example authentication workflow, are included in the repository for ease of deployment.

Keep up with progress on my personal Github, or grab the latest stable release on the One Identity Github.

Refer to the README for instructions.

Summary

The initial purpose of this integration was to provide end users with a smoother experience when authenticating with MFA to reset their passwords. However, this same process can also be utilized by helpdesk staff when verifying the identities of users who need assistance.

Typically when a user contacts the helpdesk, a helpdesk staff member can run a workflow in Password Manager to verify that user’s identity based on the answers to their “helpdesk-only” security questions. Password Manager also natively supports the use of RADIUS MFA as part of this process to allow helpdesk staff to request an OTP from the end user as well. The OneLogin API-Based MFA Solution works in the same way! Including this in a Helpdesk Workflow will prompt the helpdesk staff member to select a Security Factor from the user’s list, and prompt the user for authentication. This can of course be combined with Push Authentication using the OneLogin Protect App so the helpdesk staff member never has to receive an OTP.

Combining this all together allows users to experience a seamless process for authenticating with OneLogin both when resetting their password, and when contacting the helpdesk for assistance.

One Identity Github Note

One Identity open source projects are supported through One Identity GitHub issues and the One Identity Community. This includes all scripts, plugins, SDKs, modules, code snippets or other solutions. For assistance with any One Identity GitHub project, please raise a new Issue on the One Identity GitHub project page. You may also visit the One Identity Community to ask questions. Requests for assistance made through official One Identity Support will be referred back to GitHub and the One Identity Community forums where those requests can benefit all users.

External Links

View the original post on the OneLogin Blog or the upload on the One Identity Blog