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.
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:
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
Also: Check your split@sign
Also: you might want to login as āUSERNAME@adminā, if you have the possibility to choose.
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.
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.
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.
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.
You found the right line, so I thought it would be simple. However, it was simple for us. Thanks for the line.
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).
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?