Can't log in to new deployment after not being used for a few weeks

By: Thomas Maerz user 04 Feb 2016 at 7:31 a.m. CST

5 Responses
Thomas Maerz gravatar
I have set up gluu several times following this guide: [https://www.gluu.org/docs///admin-guide/deployment/centos/](https://www.gluu.org/docs///admin-guide/deployment/centos/) with fresh deployment on CentOS 6, setting up LDAP connection and other basic settings, verifying that I can still log into the admin interface on other computers and fresh browsers with no sessions or cookies. I then work on to another project for a while, only to discover upon returning that I am locked out of the administrative interface once again, with errors like this: [http://pastebin.com/gRrqqn9h](http://pastebin.com/gRrqqn9h). Any ideas why this might be happening? The LDAP connection was successful and the tests were working when I last logged in. As far as why I was able to log in while configuring it but at some point it no longer lets me in, is Gluu caching my credentials internally for some period of time? That is the only explanation I can think of as Administrative logins to the web interface were working fine and the lasspass password from the config file (which I also recorded into my password vault at that time) does not work when I come back. I have tried reverting my authentication method per [https://www.gluu.org/docs///articles/auth-script/#reverting-authentication-method](https://www.gluu.org/docs///articles/auth-script/#reverting-authentication-method) but when I run that command I get this output: [http://pastebin.com/2L2rJNXS](http://pastebin.com/2L2rJNXS), so either I am doing something wrong, there's something wrong with my deployment, or the documentation is wrong. The only solution I have found thus far is to wipe it all out and start over, but I am reluctant to do that at this point because I have already set this up several times and I have no reason to think it won't happen again. Help!
None
closed

Answers

By Mohib Zico Account Admin 06 Feb 2016 at 1:01 a.m. CST

Copy
Mohib Zico gravatar
>> I then work on to another project for a while, only to discover upon returning that I am locked out of the administrative interface once again, with errors like this: http://pastebin.com/gRrqqn9h. Your baseDN is messed up. > Failed to find entries with baseDN: o=users, filter: (&(&(objectClass=top))(&(uid=administrator)))

By Thomas Maerz user 08 Feb 2016 at 4:49 p.m. CST

Copy
Thomas Maerz gravatar
I see now that the Test LDAP Connection will work even with a bad Base DN value (or none at all). I was able to revert my VMWare snapshot to before I attempted to configure LDAP and get back in, but no matter what base DN I try, I can't get it to log in. Active Directory reports that the base DN for the entire domain is DC=ad,DC=company,DC=com And the Users OU is CN=Users,DC=ad,DC=company,DC=com but neither of these nor any alternate form of these seem to work. Do you have an example of a working base DN for an Active Directory setup? Also, can you verify that I am interpreting the documentation correctly here: Manage Authentication controls access to the web interface and Cache Refresh populates gluu with user information for use with SAML and other SSO operations?

By Thomas Maerz user 08 Feb 2016 at 5:24 p.m. CST

Copy
Thomas Maerz gravatar
Update: I got the base DN to work by removing the uppercase letters from the CN/DN labels, i.e.: CN=Users,DC=ad,DC=company,DC=com --> cn=Users,dc=ad,dc=company,dc=com. Now it doesn't seem to like my UID (local primary key): [http://pastebin.com/TNGBwprP](http://pastebin.com/TNGBwprP) When I look at the AD attribute editor for my backend, both mail and uid are blank. I already have set the primary key to samaccountname as suggested in the docs and that seems to have gotten me past some errors, but the local primary key doesn't work with mail or uid or samaccountname. So far here are my settings: name: backend auth servers bind dn: ad\administrator max connections: 1000 primary key: samaccountname local primary key: uid server: auth1.company.com:636 server: auth2.company.com:636 base dn: dc=ad,dc=company,dc=com use ssl: yes enabled: yes Test LDAP connection succeeds every time. Any ideas?

By Mohib Zico Account Admin 09 Feb 2016 at 4:27 a.m. CST

Copy
Mohib Zico gravatar
>> Also, can you verify that I am interpreting the documentation correctly here: Manage Authentication controls access to the web interface and Cache Refresh populates gluu with user information for use with SAML and other SSO operations? Correct. >> Now it doesn't seem to like my UID (local primary key): http://pastebin.com/TNGBwprP You can do a quick ldapsearch with your uid inside Gluu Server. Most probably this user's information is no more here now.

By Thomas Maerz user 10 Feb 2016 at 7:10 p.m. CST

Copy
Thomas Maerz gravatar
I was able to get it to work after mapping samaccountname --> uid! You can close this ticket, thank you.

Post an answer