Hello Neemash, Yep, you locked yourself out. [Here](https://support.gluu.org/installation/revert-back-to-default-auth-module-1998) is how you can revert the configuration back. >> If I re-run setup.py, I assume this will reset all my configurations/trust relations up until this point and revert to default? Don't! :-) Without uninstalling one / existing Gluu Server, running setup.py will crash the whole setup.

> Don't! :-) Without uninstalling one / existing Gluu Server, running setup.py will crash the whole setup. Thanks for the warning, glad you mentioned that, I'll steer clear of re-running that command. Using the ticket you pointed me to, I ran the below (what I believe is correct, but please say if not. I'm fairly new to LDAP and LDIF), but still am unable to login. It may be because of some of the settings I changed, so it may require more modifies in the LDIF. Just some output if it helps you verify that's the case: I used the following command to identify the inum ``` /opt/opendj/bin/ldapsearch -h localhost -p 1636 --useSSL -X -D "cn=directory manager" -w **secret** -b "ou=appliances,o=gluu" -s one "objectclass=*" oxAuthenticationMode ``` I replaced "secret" with the password, used the port 1636 as that was the original port number in the configuration and I also added in --useSSl and -X. This returned me an inum to use. I then created a file with the following information: ``` dn: inum=@**myinum**,ou=appliances,o=gluu changetype: modify replace: oxAuthenticationMode oxAuthenticationMode: internal ``` Where "myinum" has been replaced with the inum from the previous ldapsearch command. I then ran the command ``` /opt/opendj/bin/ldapmodify -h localhost -p 1636 --useSSL -X -D "cn=directory manager" -w **secret** -f ~/.ldifCommand ``` Where secret is the password and ~./ldifCommand is the file mentioned above. This resulted in the output: ``` Processing MODIFY request for inum=@**myinum**,ou=appliances,o=gluu MODIFY operation successful for DN inum=@**myinum**,ou=appliances,o=gluu ``` Again, "myinum" in the output matches the one returned via ldapsearch. Once this was done, I couldn't login as admin still. I tried restarting the gluu server just to be sure, but still no dice. So I've run the command ``` /opt/opendj/bin/ldapsearch -h localhost -p 1636 --useSSL -X -D "cn=directory manager" -w **secret** -b "ou=appliances,o=gluu" -s one "objectclass=*" ``` Which gives me more verbose output. It provides me with the below. - Do I need to use LDIF to modify the settings in oxIDPAuthentication as it still mentioned my external LDAP server I tried to (and failed to) implement? - If so, any chance you could give me a steer on that as I'm fairly new to LDIF/LDAP? In the output below, "myldapserver" is our LDAP server I was trying to configure gluu with. "myport" is the port for it (http at the moment), "mypasswordhash" is the has from the bind password I set, "myorg" is the organisation name in the LDAP server I want to pull users for, useSSL was set to false as LDAP is http at the moment for us. ``` dn: inum=@**myinum**,ou=appliances,o=gluu gluuScimEnabled: disabled passwordResetAllowed: disabled gluuGroupCount: 1 oxTrustCacheRefreshServerIpAddress: 255.255.255.255 gluuLastUpdate: 1461678683 gluuSPTR: @!C8BE.9ED6.F0CA.A55D!0002!8E61.4D80!0006!BE7F.4D99 oxAuthenticationMode: internal gluuHTTPstatus: false oxTrustStoreConf: {"useJreCertificates":true} gluuSmtpRequiresAuthentication: false oxIDPAuthentication: {"type":"auth","name":"auth_ldap_server","level":0,"priorit y":0,"enabled":true,"version":1,"fields":[],"config":"{\"configId\":\"auth_ldap _server\",\"bindDN\":\"cn=directory manager\",\"bindPassword\":\"**mypasswordhash**",\"servers\":[\"**myldapserver**:**myport**\"],\"maxConnections\":1000,\"useSS L\":**false**,\"baseDNs\":[\"o=**myorg**\"],\"primaryKey\":\"uid\",\"localPrimaryKey\" :\"uid\",\"useAnonymousBind\":false,\"enabled\":true,\"version\":0}"} gluuHostname: identity gluuVdsCacheRefreshPollingInterval: 15 gluuManageIdentityPermission: enabled oxSmtpConfiguration: {"host":"","port":25,"requiresSsl":false,"fromName":"","fro mEmailAddress":"","requiresAuthentication":false,"userName":"","password":null} gluuIpAddress: **internalIP** gluuBandwidthTX: -1 gluuWhitePagesEnabled: disabled inum: @**myinum** gluuFederationHostingEnabled: disabled gluuFreeSwap: 100 gluuBandwidthRX: -1 gluuOrgProfileMgt: disabled ``` Thanks

>> /opt/opendj/bin/ldapsearch -h localhost -p 1636 --useSSL -X -D "cn=directory manager" -w **secret** -b "ou=appliances,o=gluu" -s one "objectclass=*" oxAuthenticationMode BaseDN is not correct, you need to specify full baseDN. >> dn: inum=@**myinum**,ou=appliances,o=gluu >> changetype: modify >> replace: oxAuthenticationMode >> oxAuthenticationMode: internal Use 'Default' AuthenticationMode.

Also you need to change 'oxIDPAuthentication' as it can point to internal Gluu LDAP. Because user 'admin' is inside Gluu LDAP, not in your backend AD/LDAP server.

> Use 'Default' AuthenticationMode. I changed the ldif file so it now sets oxAuthenticationMode to "Default" instead of "internal". So the ldif file looks like the below now ``` dn: inum=@**myinum**,ou=appliances,o=gluu changetype: modify replace: oxAuthenticationMode oxAuthenticationMode: Default ``` Again myinum being the inum I obtain from the ldapsearch. > /opt/opendj/bin/ldapsearch -h localhost -p 1636 --useSSL -X -D "cn=directory manager" -w secret -b "ou=appliances,o=gluu" -s one "objectclass=*" oxAuthenticationMode > > BaseDN is not correct, you need to specify full baseDN. When you say the BaseDN is not correct, I'm not actually sure what it should be (first time LDAP user here, sorry!). The hostname we have set up is https://gluu.company.com if that is of any help. If I use the ldif file above (where I have it now set to "Default"), I now get takent o a blank page (instead of a login page) https://gluu.company.com/identity/authentication/authcode?error=access_denied&error_description=The+resource+owner+or+authorization+server+denied+the+request. > Also you need to change 'oxIDPAuthentication' as it can point to internal Gluu LDAP. Because user 'admin' is inside Gluu LDAP, not in your backend AD/LDAP server. Sorry again if this is something basic that'm not grasping, but any chance you clarify what I need to do. Again really sorry, completely new to LDAP so I'm learning as I go. Thanks

Ok. Lemme share you an easier way. - Remove 'AuthenticationMode' entry totally. Whichever is configured now, will be converted to 'Default' if you remove AuthenticationMode. Here is how you can write an ldif and use ldapmodify to run this ldif. ``` dn: inum=@xxx.xxxx.xxx....,ou=appliances,o=gluu changetype: modify delete: oxAuthenticationMode - delete: oxTrustAuthenticationMode ``` - Then modify oxIDPAuthentication section as it can point to your Gluu Server's internal LDAP as you can authenticate with it. Here is the ldif which you can use.... ``` dn: inum=@xxxx.xxxx.xxxx.xxxx...,ou=appliances,o=gluu changetype: modify replace: oxIDPAuthentication oxIDPAuthentication: {"type":"auth","name":"auth_ldap_server","level":0,"priority":0,"enabled":true,"version":1,"fields":[],"config":"{\"configId\":\"auth_ldap_server\",\"bindDN\":\"cn=directory manager\",\"bindPassword\":\"<encoded_pass_for_directory_manager_admin>\",\"servers\":[\"<hostname_of_your_gluu_server>:1636\"],\"maxConnections\":1000,\"useSSL\":true,\"baseDNs\":[\"o=gluu\"],\"primaryKey\":\"uid\",\"localPrimaryKey\":\"uid\",\"useAnonymousBind\":false,\"enabled\":true,\"version\":0}"} ``` - Restart tomcat

Thanks for providing a more laymans method for me. Within the second ldif, it mentions I should add the "<encoded_pass_for_directory_manager_admin>" which I am sure is the LDAP superuser password I set up during Gluu installation. How would I create the encoded pass from the plain text pass so I can include it in this ldif? For instance if we pretend my password was "**secret**" during the setup of gluu (setup.py), how would I create the encoded pass to add into that ldif? Thanks again!

There is a script named 'encode.py' inside /opt/gluu/bin of container. You can use that to encode/decode any text.

Fantastic! Thanks a lot for the help I can now get back in. I'll raise a separate ticket on what I was trying to do with LDAP to make sure I don't get myself in this situation again. Thanks for the assistance and feel free to close the ticket.