By: Arthur Barrett user 12 Jun 2021 at 10:15 p.m. CDT

3 Responses
Arthur Barrett gravatar
I’ve installed an out of the box Gluu 4.2.3, and then use oxtrust to navigate to “manage authentication” and the “manage ldap authentication” tab and press activate and reboot the server, now I can’t login to oxtrust. ie: I ‘activate’ LDAP with uid as the primary key then reboot - I can’t login to oxtrust. If I didn’t log out, I see this error on the screen (I can't work out how to attach a screenshot): Oops Something wrong happened. Login failed, oxTrust wasn't allowed to access user data /opt/gluu/jetty/identity/logs/oxtrust.log ``` 2021-06-13 02:00:41,936 INFO [qtp1840976765-14] [org.gluu.oxtrust.action.Authenticator] (Authenticator.java:319) - Session validation successful. User is logged in 2021-06-13 02:00:42,031 ERROR [qtp1840976765-14] [org.gluu.oxtrust.action.Authenticator] (Authenticator.java:361) - User info response doesn't contains acr claim ``` /opt/gluu/jetty/oxauth/logs/oxauth.log ``` 2021-06-13 02:00:31,904 INFO [qtp831236296-13] [org.gluu.oxauth.auth.Authenticator] (Authenticator.java:279) - Authentication success for Client: '1501.700e8dd1-efaa-4c42-b311-da9ca2c91afa' 2021-06-13 02:00:41,889 INFO [qtp831236296-16] [org.gluu.oxauth.auth.Authenticator] (Authenticator.java:279) - Authentication success for Client: '1001.0d24b906-cf1b-4986-9e3e-de5d94e16dc2' ``` If I use a clean session/new browser/log out, I see this error on screen: OOPS An unexpected error has occurred at null login.errorSessionInvalidMessage /opt/gluu/jetty/identity/logs/oxtrust.log `*nothing*` /opt/gluu/jetty/oxauth/logs/oxauth.log ``` 2021-06-13 02:04:58,131 ERROR [qtp831236296-15] [org.gluu.oxauth.service.SessionIdService] (SessionIdService.java:793) - Failed to get session by dn: oxId=65f46394-fa5d-4601-ba59-b0eb1cc6db2c,ou=sessions,o=gluu org.gluu.persist.exception.EntryPersistenceException: Failed to find entry: oxId=65f46394-fa5d-4601-ba59-b0eb1cc6db2c,ou=sessions,o=gluu . . . 2021-06-13 02:05:32,103 INFO [qtp831236296-15] [org.gluu.oxauth.auth.Authenticator] (Authenticator.java:279) - Authentication success for Client: '1501.700e8dd1-efaa-4c42-b311-da9ca2c91afa' ``` I can login to CASA OK. So this appears to be a oxtrust issue with accessing the LDAP server. I looked in oxtrust UI “JSON Configuration” “OxTrust Configuration” ``` idpLdapServer is localhost:1636 oxAuthClientScope is openid+profile+email+user_name passportUmaClientId Is 1501.700e8dd1-efaa-4c42-b311-da9ca2c91afa ``` This seems kinda related to: https://support.gluu.org/single-sign-on/7649/unable-to-login-with-email/ And also: https://support.gluu.org/identity-management/9702/change-login-from-uid-to-mail-and-casa-login-fails/ And maybe: https://support.gluu.org/single-sign-on/9240/lost-access-to-the-server/ Gluu 4.2.3, OpenDJ, Ubuntu 18.04.5 16GB RAM/16GB SWAP (66.9% free memory according to oxtrust dashboard). SCIM & Passport & SAML support enabled. Gluu Radius not enabled. I guess I don't really understand what 'activate' on this page does since prior to activating, oxauth and oxtrust and casa and scim all seem to be using the opendj ldap server already. But I want to change the login from uid to email, which will require activating it - and when i do that, it seems to break oxtrust ui login. So I thought it's worth testing to see what happens when you activate with the default settings before changing them. That also seems to break oxtrust UI. So 'activate' has got me stumped. Any help appreciated, thanks!

By Arthur Barrett user 13 Jun 2021 at 5:24 a.m. CDT

Arthur Barrett gravatar
I've got both oxTrust and CASA successfully logging in using email address instead of username! YAY! How? Well I guessed that it must be possible, but that I'm hitting a case which lots of other people hit too, where it fails, but the failure case is one that the authors and frequent users of the product don't hit it. So I took each step carefully and slowly and with lots of testing, and viola! it works! I suspect the error condition arises when you don't do all the right steps at once. eg: if you change the primary key to mail, then reboot, then activate, then reboot - you end up in a fail state. But if the primary key is uid, and the 'default authentication method' is already casa and tested and working, and this is a clean boot, and noone else is using the server - then you change the primary key from uid to email, save, activate, save, test ldap connection, reboot. wait. be patient. wait. now it works! I'm not going to close this case immediately, even though for me it's fixed. I want to see if there is any official feedback on this. I think the whole 'activate' thing is confusing and the necessity to use it when changing primary key from uid to mail is not documented and the reason why it's not activated for the default primary key as uid is also not documented.

By Mohib Zico staff 14 Jun 2021 at 11:40 p.m. CDT

Mohib Zico gravatar
>> User info response doesn't contains acr claim That's the main issue and reason behind of that is stated by you already: "*I suspect the error condition arises when you don't do all the right steps at once*" Normal default username/password ACR is `simple_password_auth`. In your case, Gluu Server couldn't found proper ACR ( I am guessing you don't have any other customization done other than what you stated in first comment ), so that means... definitely something missed during your configuration.

By Arthur Barrett user 15 Jun 2021 at 4:10 a.m. CDT

Arthur Barrett gravatar
The documentation on switching uid for email doesn't mention ACR at all - but I think it should. I did work out that once the LDAP is 'activated' that 'simple_password_auth' is no longer available as an option in the 'defaut authentication method' dropdown lists. So I tested the server with CASA as the 'default authentication method' before doing the uid/mail swap and activate step.