Limit Self Service Password Reset to a Single Managed Domain

Question

We have two on-prem domains; Domain A and Domain B. Domain A is our primary domain and syncs with Azure AD. Domain B contains accounts created for external users and is used to allow those external users to authenticate against the domain for services our company utilizes; Domain B does not sync with Azure AD. We utilize the self-service password reset functionality for both domains and use the "Email" property as a username.

Recently, we've upgraded to Adaxes 2023 and added our Azure infrastructure as a managed domain to Adaxes. In Azure AD we also have external user / guest accounts added to our tenancy.

After adding Azure as a managaged domain we are starting to experience an issue when Domain B users attempt to log in to the self-service password portal with the error:

The username is ambiguous. There is more than one account with the specified username

This is being cause by users having accounts in both Domain B (which does not sync with Azure) and Azure AD with the same email address. At this time we are unable to remove or combine either account, change the email addresses, or require the Domain B user principal name as the login name.

Domain B users will never need to reset their Azure AD guest account password via Adaxes self service. Is there a way to fully exclude the newly-added Azure AD managed domain from being evaluated as an authentication source during self service login so, that when a Domain B user attempts to authenticate, they are only authenticating against the Domain B on-prem domain?

Answer 1

Hello,

The issue is not related to the Password self-service feature in any way. It is just about logging in to Adaxes Web interface. Unfortunately, there is no possibility to exclude any accounts from authentication check. The only option is to either make sure that there are no duplicates or use another property as username for authentication.

Comments

Thank you. As we can't exlude domains from the authentication pool we have decided to user a separate property.

---

I've been experimenting with using an alternative attribute for the username and I'm still experiencing the issue.

Here's a quick rundown of the current configuration:

1. Removed the email address property as a username option for all of the various interfaces. All of the interfaces now only offer "User Logon Name" and "User Logon Name (pre-Windows 2000) as options - the "email" property should no longer be evaluated as a username.
2. Added the "Employee Number" property to the list of username options for the single interface in question. Neither employee number or email address are
3. For the users in this specific domain, the email address was copied to the employee number attribute.

This, unfortunately, has not resolved the issue. While while the email address does still exist on both the on-prem and Azure versions of the users' accounts it should be being ignored for login. Futhermore, there are no other duplicate properties between the two accounts since the Azure accounts are for guest users external to our company and not being synced from out on-prem AD.

For the record, I have not restarted IIS due to downtime contraints. Does IIS need to be restarted between interface configuration changes?

---

Hello,

Does IIS need to be restarted between interface configuration changes?

No, it is not required to restart IIS. After saving the changes in the Web interface configurator you just need to refresh the Web interface page using Ctrl+F5 or simply clear browser cache.

Futhermore, there are no other duplicate properties between the two accounts since the Azure accounts are for guest users external to our company and not being synced from out on-prem AD.

If the issue persists, there definitely is a duplicate. It does not matter where accoutns are synchronized or not and same goes for their location. If you have two accounts managed by Adaxes with the same User Logon Name or User Logon Name (pre-Windows 2000), the error will occur.