AD authentication over LDAPS port 636

Darren4 · February 28, 2018, 11:17pm

I am able to use active directory as my database for authentication over LDAP, however I have found no documentation to serve LDAPS port 636. I have set my domain controllers to use this and tests are successful. I see where I can change the port to 636 and use ldaps, but when I test it there is no joy from admin console. Can someone please help, I am running openfire on ubuntu server, currently using openfire 4.1.4

speedy · March 1, 2018, 12:03am

after changing the port, look for a system property called ldap.sslEnabled and set it to true. Then restart openfire service.

Darren4 · March 1, 2018, 2:48am

I can do that, however I first wanted to test it, and have been testing it under Server Settings > Profile Settings. Plain old LDAP over port 389 returns success, when I change it to port 663 and hit advance to use SSL, it fails. Is this not an accurate test?

wroot · March 1, 2018, 4:54am

I guess the test doesn’t work as that setting is not enabled and system wide ldaps is not working (test is using the same core).

Darren4 · March 1, 2018, 2:49pm

I plan on testing this tonight, however since this is purely AD authentication, I don’t want to lock myself out should it not work. Won’t let me create a local admin, anyway around this should it not work I can go in a change it back?

speedy · March 1, 2018, 3:11pm

if you are using an external database, you can simply update the tables directly

Darren4 · March 1, 2018, 11:30pm

Sorry, I don’t follow you on creating a local user by update the tables directly?

speedy · March 2, 2018, 3:37pm

sorry…I was referring to the configuration options. if you lock yourself out, you can revert your settings directly on the database…you dont have to use the web console

Darren4 · March 2, 2018, 4:39pm

Thanks for the tip on that. I moved to port 636 and set ldap.sslEnabled to true, and was unable to connect. I am guessing that since the server is running from Ubuntu it needs the private key from the LDAPS cert on the domain controller imported into one of the cert stores on openfire? Maybe even some additional steps that need to be taken. Any help would be appreciated, or if there was a step by step guide, I have not been able to locate one.

speedy · March 2, 2018, 5:23pm

you shouldn’t have to do anything special…
ldap.port 636
ldap.sslEnabled true
ldap.startTlsEnabled false

you could try turning on debugging to see if anything interesting pops up
ldap.ldapDebugEnabled true

Also, might be worth running wireshark or something to see if the connection is being attempted.

Darren4 · March 2, 2018, 5:52pm

Okay thanks for the info, I’ll look at the debug logs and then wireshark. I suspect it has something to do with the certificate I issued and the domain name given the ubuntu server is not a member of the domain. Also, can you enlighten me on the name of the db file I could edit, openfire.script?

speedy · March 2, 2018, 5:56pm

I think thats right, but I’m not sure. I only use an external database like mysql or ms sql. Another option maybe to just run through the setup again and select ldaps options. you can do that without losing your config. to do that, stop openfire, edit openfire.xml file. look for the tag called setup, and change it to false. restart openfire, and you’ll get the setup wizard.

Cosmo1 · March 8, 2018, 10:26pm

I’d suggest trying the below 2 items:

Install a Stand-alone (.i.e. DMZ) ‘Server Authentication’ AD CS (Certificate Services)PKI certificate on your Ubuntu non AD joined chat server, along with the ‘Root CA’ certificate from the same AD CS, so that Server Authentication’ Cert can see the complete path to the RootCA Cert and therefore be fully trusted and valid. The following article details the required steps, however you may need your AD PKI SME to assist you with this task, as it can be very, very tricky, especially with getting AD CS certs working on a non-AD joined computer. https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx
Once both PKI certs are installed on your chat server, ensure the Firewall on both AD Domain Controller that is likely to provide AD user authentication to your chat users and your Ubuntu server have port 636 open (and confirm it is open on both servers via the netstat –a | find “636” command. Furthermore, as you are touching the Firewall of the Domain Controller, you will need your ICT Security team approval before doing so, as you are opening up a major AD security hole for a possible Cyber attack.

Cheers,
Cosmo