LDAP Resolver Broken after 3.1.2 to 3.2 Upgrade

[wwalker]

I have three realms configured for different access levels; admin, helpdesk, and users (default). Level of access is controlled via policies. Each realm is using an LDAP resolver with appropriate user filters. All users that exist in the admin realm will also exist in the helpdesk and users realm. All users that exist in the helpdesk realm also exist in the users realm.

After performing the upgrade, I get the following error: Authentication failed. Authentication failure. Wrong credentials when attempting to login with an LDAP account on the admin or helpdesk realms. /var/log/privacyidea.log states:

[6914][140652655691520][ERROR][privacyidea.lib.user:373] The user User(login='admin\\USERNAME', realm='users', resolver='') exists in NO resolver.

I’ve logged in using the local administrator account and done the following:

• Verified the admin and helpdesk realms are still present in pi.cfg under SUPERUSER_REALM
• Disabled all policies to ensure the issue isn’t with permissions.
• Verified the LDAP resolvers are able to connect to AD.
• All three realms populate the appropriate users when viewing the userlist.
• Disabled all custom page rewrites in Apache2 site config.

[cornelinux]

The LDAP resolver is actually not broken! It works as designed.
Something looks strange in your login process and we do need to check your config. You need to do this. We can not do this.

However, the realm handling, which was not completely consistent, was standardized in version 3.2.
Read your log entries and put some effort in understanding them:

User(login='admin\\USERNAME', realm='users', resolver='')

So for some reason you are logging in in an “incorrect” way. You are passing a username “admin\USERNAME” that you think contains a realm and in addition you pass an explicit realm parameter “users”. This realm parameter takes precedence.
Read https://privacyidea.readthedocs.io/en/latest/configuration/realms.html#relate-realm

1. Also: Check your split@sign
2. Also: you might want to login as “USERNAME@admin”, if you have the possibility to choose.

[wwalker]

The LDAP resolver is actually not broken! It works as designed.
Something looks strange in your login process and we do need to check your config. You need to do this. We can not do this.

I’ll admit, it was a poorly worded subject. I also never meant to imply that you must fix my environment, only that what once worked, no longer did and I couldn’t decipher why.

Read your log entries and put some effort in understanding them:

I’m primarily a Windows sys admin, forgive me for not having a complete understanding like a developer would. The fact that I tracked down the log and tried to understand what was in it as well as perform some level of troubleshooting, I thought, would imply effort was made.

However, the realm handling, which was not completely consistent, was standardized in version 3.2.
…
User(login=‘admin\USERNAME’, realm=‘users’, resolver=’’)

So for some reason you are logging in in an “incorrect” way. You are passing a username “admin\USERNAME” that you think contains a realm and in addition you pass an explicit realm parameter “users”. This realm parameter takes precedence.
Read https://privacyidea.readthedocs.io/en/latest/configuration/realms.html#relate-realm

1. Also: Check your split@sign
2. Also: you might want to login as “USERNAME@admin”, if you have the possibility to choose.

It appears the standardization is what broke my “incorrect” login method. domain\username is a widespread, well understood login method by users in my environment and I was hoping to maintain that standard.

[wwalker]

For the sake of completeness, I’ve verified that, after upgrading and enabling split @ sign, username logins in the format username@realm still works. As does using an email address to login, which I feared would be broken.

[cornelinux]

I’m primarily a Windows sys admin, forgive me for not having a complete understanding like a developer would. The fact that I tracked down the log and tried to understand what was in it as well as perform some level of troubleshooting, I thought, would imply effort was made.

You found the right line, so I thought it would be simple. However, it was simple for us. Thanks for the line.

It appears the standardization is what broke my “incorrect” login method. domain\username is a widespread, well understood login method by users in my environment and I was hoping to maintain that standard.

It is not incorrect, that you authenticated with “realm\username”. But the question is, how the realm=users was set at the same time when logging in to the UI. This should not happen, unless you maybe activated the realm dropdown box?
And providing two diffrent realms in parameters like username="REALM1\user" and realm=REALM2 can easily lead to unexpected behaviour. So the data given looked like you are logging in an unusal way (providing two different realms).

[cornelinux]

For the sake of completeness, I’ve verified that, after upgrading and enabling split @ sign , username logins in the format username@realm still works. As does using an email address to login, which I feared would be broken.

Did you not have splitatsign active before?

With the splitAtSign active, you should be able to login as username=realm\user, but take care to not provide an explicit other realm.

[wwalker]

For the sake of completeness, I’ve verified that, after upgrading and enabling split @ sign , username logins in the format username@realm still works. As does using an email address to login, which I feared would be broken.

Did you not have splitatsign active before?

With the splitAtSign active, you should be able to login as username=realm\user, but take care to not provide an explicit other realm.

I did not have that setting active in previous versions.

*facepalm, realm\username still works…guess I should have tried that prior to posting instead of making an assumption.

[cornelinux]

So if you did not have splitAtSign active, I wonder why it worked in the first place…

[wwalker]

I’m doing things a bit backwards here in that I have our POC environment running the older version and our soon to be production environment running the latest version, 3.2.

In my POC environment, I ran apt list --installed | grep privacyidea and got the following:

privacyidea/now 3.0-1xenial amd64 [installed,upgradable to: 3.2-1xenial]
privacyidea-apache2/now 3.1.1-1xenial all [installed,upgradable to: 3.2-1xenial]
privacyidea-radius/stable,stable,now 3.1-1xenial all [installed]
privacyideaadm/xenial,xenial,now 2.15.1-1xenial all [installed]

In the WebUI, I can confirm that the Split@sign setting is disabled and I can log in using realm\username. Is there something you’d like me to look for to figure out why it was working?