Cache refresh not running with remote AD server. Failed to connect to LDAP server.

By: Aleksandar Petkovski user 21 Nov 2018 at 10:36 a.m. CST

8 Responses
Aleksandar Petkovski gravatar
Hello. We tried to configure the Cache refresh to use the Microsoft AD from our company, as suggested in https://www.gluu.org/gluu-server-cache-refresh-configuration-part-2/ video. For Source Backend LDAP servers under Cache Refresh configuration, we have these parameters. * Bind DN: cn=Aleksandar Petkovski,ou=Users,ou=Slovenia,dc=snt-is,dc=com * Max connections: 5 * Server:Port: sidc10.snt-is.com:389 * Base DN: CN=Configuration,DC=snt-is,DC=com * Bind Password : ******** * Use SSL : No I can bind to the AD server through different LDAP browsers on Fedora and read data from it, so I confirm that all connections work, but the GLUU Cache refresh produces the following error in the oxtrust_cache_refresh.log: > 2018-11-21 17:24:24,680 ERROR [Thread-1391] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:1080) - Failed to connect to LDAP server using configuration SNT Backend > 2018-11-21 17:24:24,777 ERROR [Thread-1391] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:283) - Skipping cache refresh due to invalid server configuration > 2018-11-21 17:24:24,953 DEBUG [Thread-1391] [gluu.oxtrust.ldap.cache.service.CacheRefreshTimer] (CacheRefreshTimer.java:181) - Allowing to run new process exclusively I tried over ldapsearch to get the same data, but it returns: > [root@idm-1 bin]# ldapsearch -h sidc10.snt-is.com -p 389 -Z -X -D "CN=Aleksandar%20Petkovski,OU=Users,OU=Slovenia,DC=snt-is,DC=com" -b 'DC=snt-is,DC=com' 'objectclass=*' -W ldap_start_tls: Connect error (-11) additional info: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (unable to get local issuer certificate) Enter LDAP Password: ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) additional info: error:14090086:SSL routines:ssl3_get_server_certificate:certificate verify failed (unable to get local issuer certificate) Active directory server sidc10.snt-is.com does not use SSL and uses port 389. Gluu is installed on a Fedora virtual machine that can telnet and ping sidc10.snt-is.com, and using Apache Directory Studio can connect to the AD server with the credentials provided above. Can you please provide me a solution on how to resolve this problem with connection?
CentOS 7.5
closed

Answers

By Chris Blanton user 21 Nov 2018 at 10:45 a.m. CST

Copy
Chris Blanton gravatar
Can you try running this command from inside the Gluu chroot: ``` /opt/opendj/bin/ldapsearch -p 389 -D 'cn=Aleksandar Petkovski,ou=Users,ou=Slovenia,dc=snt-is,dc=com' -w ${YOUR_BIND_PASS} -b 'CN=Configuration,DC=snt-is,DC=com' "objectclass=*" ```

By Aleksandar Petkovski user 21 Nov 2018 at 10:53 a.m. CST

Copy
Aleksandar Petkovski gravatar
`ldapsearch -p 389 -D 'cn=Aleksandar Petkovski,ou=Users,ou=Slovenia,dc=snt-is,dc=com' -w ${PSW1234567} -b 'CN=Configuration,DC=snt-is,DC=com' "objectclass=*" -h sidc10.snt-is.com` ldap_bind: Invalid credentials (49) additional info: 80090308: LdapErr: DSID-0C09042F, comment: AcceptSecurityContext error, data 52e, v2580

By Chris Blanton user 21 Nov 2018 at 10:59 a.m. CST

Copy
Chris Blanton gravatar
Are you using the binary from opendj or the ldapsearch binary? Also it seems like your bind credentials are invalid based on that output. Do you have an example of a working ldap command on any system?

By Aleksandar Petkovski user 21 Nov 2018 at 11:14 a.m. CST

Copy
Aleksandar Petkovski gravatar
Sorry, password was wrong. Here you have the correct output:

By Chris Blanton user 21 Nov 2018 at 11:17 a.m. CST

Copy
Chris Blanton gravatar
Okay thanks. I removed the information as it's not necessary to share publicly, but we needed to confirm the search function is working external to Gluu Server cache refresh. Are you sure the bind credentials in the Gluu Server cache refresh configuration were accurate as well?

By Mohib Zico staff 21 Nov 2018 at 11:53 a.m. CST

Copy
Mohib Zico gravatar
Hi Aleksandar, There are couple of Cache Refresh related tickets available from community; please feel free to take a look at them. Here is one recent one: https://support.gluu.org/installation/6181/cache-refresh-configured-but-not-working/

By Aleksandar Petkovski user 22 Nov 2018 at 9:32 a.m. CST

Copy
Aleksandar Petkovski gravatar
Hello. I managed to make a connection to our AD server and also manage the LDAP authentication, so the user from the AD can connect to our gluu server. I will here write the settings, so someone having the same problems can use it in the future. # Cache Refresh Configuration: **Source Backend LDAP Servers:** * Name: source ##Very important to be exactly source * Max connections: 10 * Base DN: dc=snt-is,dc=com **Customer Backend Key/Attributes:** * Key attribute: sAMAccountName * Object class: user * Source Attribute: cn,sn.mail,givenName,displayName **Cache Refresh** * Refresh Method: Copy * Add source attribute to destination attribute mapping: samaaccountname->uid, cn->cn, sn->sn, mail->mail, givenname->givenname, displaynae->displayname * Polling interval (minutes): 1 * Server IP address: <ip of gluu> * Snapshots count: 20 * Search size limit:1000 * Cache Refresh: **Disabled** After this we choose **Update**, after that, change the Cache Refresh to Enabled, and press **Update** again. **# Manage Authentication:** Add Source LDAP server. Use the same parameters as in **Source Backend LDAP Servers:**. Add: * Primary Key: SAMAccountName * Local primary key: uid * Activate the LDAP connection and press Test LDAP Connection to check. That's it.

By William Lowe user 23 Nov 2018 at 2:17 p.m. CST

Copy
William Lowe gravatar
great, thanks!

Post an answer