> ./ldapmodify -h localhost -p 1389 -D "cn=directory manager,o=gluu" -w "..." -f /root/changeAuth.ldif OpenDJ in Gluu Server defaults to 1636. Here's a sample modify command: `/opt/opendj/bin/ldapmodify -p 1636 -Z -X -D 'cn=directory manager' -w secret -b o=gluu -f example.ldif`

Okay! That got me farther, however now it's saying invalid credentials. I'm certain I have the ldap pw correct, any info about what might cause this?

Note that OpenLDAP uses `cn=directory manager,o=gluu` and OpenDJ uses `cn=directory manager`. Using a LDAP Explorer of some time just requires the hostname, port, LDAPS(SSL/TLS) and your simple bind dn(cn=directory manager) and bind password.

> it's saying invalid credentials Please use `-D "cn=directory manager"` not `-D "cn=directory manager,o=gluu"`

Okay, I pushed this file that is in the troubleshooting doc: ``` -bash-4.2# cat /root/changeAuth.ldif dn: inum=@!58DC.934E.7B4B.6152!0002!88C9.DAA4,ou=appliances,o=gluu changetype: modify delete: oxAuthenticationMode ``` And the result after your guys' help is ``` Processing MODIFY request for inum=@!58DC.934E.7B4B.6152!0002!88C9.DAA4,ou=appliances,o=gluu MODIFY operation successful for DN inum=@!58DC.934E.7B4B.6152!0002!88C9.DAA4,ou=appliances,o=gluu ``` However, I'm still getting the same error response in my initial request, which tells me it hasn't reverted the auth method back to auth_ldap_server. Any ideas?

Am I doing this correctly for jxplorer? https://i.imgur.com/mDaPGJx.png

No, just enter `cn=directory manager` in that portion.

Also `base DN` should be `o=gluu`

Here's what I've got and the response that's given. https://imgur.com/a/19OQ3gE Is the hostname just the hostname of the server which has gluu hosted on it? The password is the ldap password, correct? I'm sorry if I'm frantic, this is locking users out and I was not anticipating this error. I appreciate all the responses you guys have been giving me.

The hostname needs to be reachable from the computer you're running JXplorer on. If it's not a FQDN, just use the IP Address of the server running LDAP.

>Is the hostname just the hostname of the server which has gluu hosted on it? Yes so for example I would use `test.gluu.org` as the hostname and the port as `1636`

Oh, it is. It's the same address I go to when logging in with the gluu admin. Is there a way I could continue with the command line method? Deleting the field did not work, so I tried pushing this update with success, but it doesn't appear to make the change when testing: ``` -bash-4.2# cat /root/changeAuth.ldif dn: inum=@!58DC.934E.7B4B.6152!0002!88C9.DAA4,ou=appliances,o=gluu changetype: modify add: oxAuthenticationMode oxAuthenticationMode: auth_ldap_server ```

Please send the output of this: ``` /opt/opendj/bin/ldapsearch -p 1636 -Z -X -D 'cn=directory manager' -w secret -b 'inum=@!58DC.934E.7B4B.6152!0002!88C9.DAA4,ou=appliances,o=gluu' 'objectclass=gluuAppliance' ```

Sure: ``` dn: inum=@!58DC.934E.7B4B.6152!0002!88C9.DAA4,ou=appliances,o=gluu objectClass: top objectClass: gluuAppliance oxTrustAuthenticationMode: basic passwordResetAllowed: enabled oxAuthenticationMode: auth_ldap_server gluuPassportEnabled: disabled gluuWhitePagesEnabled: disabled oxTrustStoreConf: {"useJreCertificates":true} inum: @!58DC.934E.7B4B.6152!0002!88C9.DAA4 oxTrustCacheRefreshServerIpAddress: 255.255.255.255 oxSmtpConfiguration: {"host":"mail.clearobject.com","port":25,"password":null,"r equires-ssl":false,"trust-host":false,"from-name":"password-reset","from-email- address":"support@clearobject.com","requires-authentication":false,"user-name": ""} gluuPersonCount: 74 gluuOrgProfileMgt: disabled gluuScimEnabled: enabled gluuVdsCacheRefreshEnabled: disabled gluuDSstatus: true gluuIpAddress: 10.128.2.30 gluuBandwidthTX: -1 gluuBandwidthRX: -1 oxCacheConfiguration: {"cacheProviderType":"IN_MEMORY","memcachedConfiguration": {"servers":"localhost:11211","maxOperationQueueLength":100000,"bufferSize":3276 8,"defaultPutExpiration":60,"connectionFactoryType":"DEFAULT"},"inMemoryConfigu ration":{"defaultPutExpiration":60},"redisConfiguration":{"redisProviderType":" STANDALONE","servers":"localhost:6379","defaultPutExpiration":60}} 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\":\"88QPjP6gf660CQ tZY42XJQ==\",\"servers\":[\"localhost:1636\"],\"maxConnections\":1000,\"useSSL\ ":true,\"baseDNs\":[\"o=gluu\"],\"primaryKey\":\"uid\",\"localPrimaryKey\":\"ui d\",\"useAnonymousBind\":false,\"enabled\":true,\"version\":0,\"level\":0}"} oxTrustEmail: support@clearobject.com oxLogViewerConfig: { "log_template":[ { "value1":"oxAuth logs", "value 2":"/opt/gluu/jetty/oxauth/logs/*.log", "description":"" }, { "valu e1":"oxTrust logs", "value2":"/opt/gluu/jetty/identity/logs/*.log", "de scription":"" } ]} gluuManageIdentityPermission: enabled gluuFreeDiskSpace: 87 gluuSystemUptime: 7768363 gluuFederationHostingEnabled: disabled gluuSslExpiry: 462 gluuLastUpdate: 20181119185658.102Z gluuHostname: stg gluuMaxLogSize: 200 gluuGroupCount: 1 gluuHTTPstatus: false gluuFreeMemory: 45 ```

It looks like only oxtrust doesn't have the proper change. Your applications should work but if you want oxtrust to use the `auth_ldap_server` mechanism, please change your previous ldif file to `oxTrustAuthenticationMode`.

I noticed that as soon as I put my reply in. Thanks so much for the help, we have restored availability. Just a quick inquiry, if I wanted to do this smoke test, I would only change "Default acr" to basic (the auth script that I modified), and not "oxTrust acr" to basic, but instead leave it at auth_ldap_server?

It depends on what you want to do. If you're wanting to smoke test your application, you can change the `Default acr` to `basic`. Alternatively you can change the `Default requested Authentication Context Class Reference (ACR) values:` value in a particular client to a certain acr value, like `basic`, `auth_ldap_server`, `u2f`, etc. This would override the global value.

Great! Thanks for all the help, that was stressful, but it ended up being an easy fix. I appreciate it, I'm going to close this ticket now. Josh N.

Glad it all worked out, Josh!

I have a quick inquiry about this issue. I'm going to try and replicate again, but I was wondering what provoked this issue originally. Once I can replicate it, I'll have more specific info, but for now, I'm looking for potential reasons/methods to avoid this in the future, as we will be performing the "smoke test" going forward. I have enabled a custom auth method by modifying the "basic" auth method to only allow certain usernames, which I've learned in [this ticket](https://support.gluu.org/authentication/6259/temporarily-block-authentication-for-all-but-one-user/). Then, to activate it, I will go into **Manage Authentication** to switch both **Default acr** and **oxTrust acr** to that basic auth. This works, it seems, about 95% of the time with no issue. However, I have replicated the above behavior twice. I'm wondering what might provoke this behavior when making this change. I had tested it on a sandbox environment and seen multiple successes. However, once we moved on to do the testing in an environment which was actively being used, we ran into this issue, which provoked downtime and caused many issues until I worked in here to get it fixed. I'm going to try and replicate this, so I can demonstrate it or provide log files, but like I said, it only seems to occur only 5% of the time. Thanks for your time! If I need to open a new ticket for this, I can! Josh N.

Hey Josh, Let's open a new ticket so we can better isolate the issue and bring in extra people as is necessary.