Reverting back to internal authentication issue

By: Mulk Anand named 16 Aug 2016 at 8:12 a.m. CDT

11 Responses
Mulk Anand gravatar
Hello, I have an internal lab environment where during the testing I enabled super gluu authentication for oxtrust console authentication. After enabling that I tried to authenticate by scanning QR code but was unable to do that. Then I realized that its because my phone was not connected to internal network and even if I connect it to the internal network it will not be able to identify the server DNS which I am using by making changes into server's and my laptop's /etc/hosts file. Now I can't login to Gluu admin console. I tried following https://www.gluu.org/docs/faq/troubleshooting/ to Revert Authentication Method but I get this when I try to run ldapmodify command: [root@sdggluu ~]# /opt/opendj/bin/ldapmodify -p 1389 -D 'cn=directory manager' -w 'xxxxx' -f /opt/opendj/changeAuth.ldif Connect Error Result Code: 91 (Connect Error) It also seems that nothing is running on port 1389. [root@sdggluu ~]# netstat -plnt Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:11211 0.0.0.0:* LISTEN 136/memcached tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN - tcp 0 0 10.10.10.149:80 0.0.0.0:* LISTEN 137/httpd tcp 0 0 0.0.0.0:60022 0.0.0.0:* LISTEN 133/sshd tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN - tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN - tcp 0 0 10.10.10.149:443 0.0.0.0:* LISTEN 137/httpd tcp 0 0 127.0.0.1:32000 0.0.0.0:* LISTEN 912/java tcp6 0 0 127.0.0.1:8009 :::* LISTEN 912/java tcp6 0 0 :::11211 :::* LISTEN 136/memcached tcp6 0 0 :::111 :::* LISTEN - tcp6 0 0 :::30865 :::* LISTEN 132/xinetd tcp6 0 0 :::60022 :::* LISTEN 133/sshd tcp6 0 0 :::22 :::* LISTEN - tcp6 0 0 :::1689 :::* LISTEN 693/java tcp6 0 0 ::1:25 :::* LISTEN - tcp6 0 0 127.0.0.1:8443 :::* LISTEN 912/java tcp6 0 0 :::4444 :::* LISTEN 693/java tcp6 0 0 :::37181 :::* LISTEN 693/java tcp6 0 0 :::8989 :::* LISTEN 693/java tcp6 0 0 :::1636 :::* LISTEN 693/java tcp6 0 0 127.0.0.1:8005 :::* LISTEN 912/java Please help..its killing me.
CentOS72
closed

Answers

By Mohib Zico Account Admin 16 Aug 2016 at 8:34 a.m. CDT

Copy
Mohib Zico gravatar
Hello Mulk, [Here](https://support.gluu.org/installation/revert-back-to-default-auth-module-1998) is how you can retrieve your login.

By Mulk Anand named 16 Aug 2016 at 8:37 a.m. CDT

Copy
Mulk Anand gravatar
I tried that...please go through the details I provided on this ticket. It did not work.

By Mohib Zico Account Admin 16 Aug 2016 at 8:49 a.m. CDT

Copy
Mohib Zico gravatar
Ah ok... >> [root@sdggluu ~]# /opt/opendj/bin/ldapmodify -p 1389 -D 'cn=directory manager' -w 'xxxxx' -f /opt/opendj/changeAuth.ldif Connect Error Result Code: 91 (Connect Error) Run in 1636 port please.

By Mulk Anand named 16 Aug 2016 at 8:52 a.m. CDT

Copy
Mulk Anand gravatar
[root@sdggluu bin]# /opt/opendj/bin/ldapmodify -p 1636 -D 'cn=directory manager' -w 'xxxxx' -f /opt/opendj/changeAuth.ldif Cannot read the bind response from the server. The port you are using may require a secured communication (--useSSL). The connection to the Directory Server was closed before the bind response could be read Result Code: 82 (Local Error) This is what I am getting now.

By Mohib Zico Account Admin 16 Aug 2016 at 8:56 a.m. CDT

Copy
Mohib Zico gravatar
Doc updated...

By Mulk Anand named 16 Aug 2016 at 9:04 a.m. CDT

Copy
Mulk Anand gravatar
not sure which doc you updated...and what you mean by that. But i was able to run these commands using --useSSL like below: [root@sdggluu bin]# /opt/opendj/bin/ldapsearch --useSSL -h localhost -p 1636 -D "cn=directory manager" -w xxxxx-b "ou=appliances,o=gluu" -s one "objectclass=*" oxAuthenticationMode [root@sdggluu bin]# /opt/opendj/bin/ldapmodify --useSSL -p 1636 -D 'cn=directory manager' -w 'xxxx' -f /opt/opendj/changeAuth.ldif The server is using the following certificate: Subject DN: CN=localhost, O=OpenDJ RSA Self-Signed Certificate Issuer DN: CN=localhost, O=OpenDJ RSA Self-Signed Certificate Validity: Tue Aug 02 02:45:02 EDT 2016 through Mon Jul 28 02:45:02 EDT 2036 Do you wish to trust this certificate and continue connecting to the server? Please enter "yes" or "no":yes Processing MODIFY request for inum=@!FE07.4E38.0111.7F1D!0002!158A.C89F,ou=appliances,o=gluu MODIFY operation successful for DN inum=@!FE07.4E38.0111.7F1D!0002!158A.C89F,ou=appliances,o=gluu However, I am still unable to login to gluu console. It is still giving me to https://myserver.dns/oxauth/auth/super-gluu/login page.

By Mulk Anand named 16 Aug 2016 at 9:37 a.m. CDT

Copy
Mulk Anand gravatar
can you please help quickly? I restarted Gluu CE but still getting Super Gluu QR code page..

By Mohib Zico Account Admin 16 Aug 2016 at 10:18 a.m. CDT

Copy
Mohib Zico gravatar
Ok... Not sure if you changed both Authentication mode or just oxTrust.... If you changed only oxAuth .. then delete 'oxAuthenticationMode'. But if you changed both oxAuth and oxTrust... then you need to delete 'oxTrustAuthenticationMode' and 'oxAuthenticationMode' values from LDAP. These values are under 'inum=........,ou=appliances,o=gluu' DN. By deleting 'oxTrustAuthenticationMode' and 'oxAuthenticationMode' will make your Gluu Server login to 'Default' method.

By Mulk Anand named 16 Aug 2016 at 10:34 a.m. CDT

Copy
Mulk Anand gravatar
That was what I had to do. I had only changed for oxTrust not for oxAuth..Thanks for your help.

By Mohib Zico Account Admin 16 Aug 2016 at 10:36 a.m. CDT

Copy
Mohib Zico gravatar
Great.. do you think we can close this issue now? BTW a suggestion... whenever you test a new 2FA; use different browser for testing. Keep first browser active all the time as you can revert the working condition.

By Yuriy Movchan staff 16 Aug 2016 at 1:33 p.m. CDT

Copy
Yuriy Movchan gravatar
Also during scripts development I always specify "Location Type"="File" to load script from file system. Application automatically reload script during 30 seconds on file modification date update. This allows to revert back to previous working script version or replace it with basic script to log in if needed. After finishing script development it's better to change "Location Type" back to 'LDAP'.

Post an answer