AD User Desync

tomaslindev · ‎01-14-2025

Hi everyone

Currently our instance is synchronized with the AD through the LDAP Server, Source and SSO Sourcer fields, the client needs to maintain the synchronization of this data in other auxiliary fields and desynchronize the users from the AD so that they can access the instance locally. Is this feasible taking into account the passwords of each user?
Thank you very much and best regards.

-O- · ‎01-14-2025

Cleaning all that stuff up is not necessary.

Back to the problem, I guess you should do a few things:

define a role and assigned it to all users who are allowed to log on locally (preferably through group membership, of course).
For the sake of this example let's name the role "u_local_principal" and the group "Local Principals"
Go to Adaptive Authentication -> Filter Criteria -> Role Filter Criteria and create a new record, where "Condition" will be [ "Role" "is" "u_local_principal" ].
For the sake of this example let's name the new filter criteria "Local Principals"
To be frank you might also go to Adaptive Authentication -> Filter Criteria -> Group Filter Criteria to create a group based filter criteria, but role can be used in more places throughout the platform, so I'd make the settings role based.
Go to Adaptive Authentication -> Authentication Policies -> All Policies and open record with name "Allow Non Local Login Users"
- Modify the "Policy Inputs" related list by adding the Filter Criteria defined @ point 2 - "Local Principals".
- Open record "Allow Non Local Login Users" in related list "Policy Conditions" and update field Condition by adding an "OR" to it: [ "Local Principals" "is" "true" ].
  So the final Condition would look like:
  [ "Authentication Scheme" "is not" "Username and Password" ] or [ "Local Principals" "is" "true" ]

After this, granted that there are no other custom rules that nullify the one just configured, those users who are made members of group "Local Principals" and thus obtain role "u_local_principal" should be able to log in locally with username or password.

Hint: if you want to be able to distinguish between real "User name or password invalid" errors and ones caused by Authentication Policies, you can go to Adaptive Authentication -> Authentication Policies -> Properties and change property "Error message to be displayed to the user when login fails due to authentication policy failure" so that it will be some different recognizable text.

View solution in original post

PritamG · ‎01-14-2025

Yes, it is feasible to desynchronize users from AD while maintaining data synchronization in auxiliary fields. However, user passwords cannot be migrated directly due to security constraints. Instead, implement a local authentication system, reset passwords for users, or allow password creation for local access. Ensure security best practices and clear communication with users during the transition.

Mark Manders · ‎01-14-2025

If you are no longer able to use SSO, all users need to get a local password and since they already are using the platform, you don't want to give each and every one of them the same or a default one.
You could utilize the 'forgot password' option for users to do this themselves, but that isn't really client friendly.

The big question, however: why? If you need to keep the data, they are still using AD, right? Why not keep using it as is?

Please mark any helpful or correct solutions as such. That helps others find their solutions.
Mark

tomaslindev · ‎01-14-2025

Hi @Mark Manders apparently they are users who become external, they want to keep the AD data in other fields but desynchronize them and have local access to servicenow. It is a strange request, I understand the confusion.

-O- · ‎01-14-2025

Setting the password for the user should make it possible to also connect as a local account, but you would need to enable connecting locally.

I mean if SSO is enabled and adaptive authentication/account recovery is enabled, then local logins are not permitted.

When such users will try to connect by accessing the /login.do URL, they will receive the standard "username or password invalid" message, but in fact (even if the login is OK) the authentication policy rejected it.