Linux

Ldapsearch Syntax for Simple LDAP and SLDAP

Another case of “I’ve done this before, but never wrote it down”, so revisiting this took far longer than it should have. But now it is here, that won’t happen again.. right?? I’ll probably never need it again now… typical..

OK, so a straight forward non-secure ldapsearch command, obtains everything (-h can be IP or FQDN):

ldapsearch -h 192.168.1.201 -p 389 -b “DC=oholics,DC=net” -D “CN=svc-LDAPBind,OU=ServiceAccounts,DC=oholics,DC=net” -w “<MyPass>”

A secure ldapsearch command, using TLS on port 389, obtains everything (Note the use of the -Z switch and the use of FQDN):

ldapsearch -h dc.oholics.net -p 389 -b “DC=oholics,DC=net” -D “CN=svc-LDAPBind,OU=ServiceAccounts,DC=oholics,DC=net” -w “<MyPass>” -Z

A secure ldapsearch command, using SSL on port 636, obtains everything (note the use of -H and the LDAP Uniform Resource Identifier):

ldapsearch -H ldaps://dc.oholics.net:636 -b “DC=oholics,DC=net” -D “CN=svc-LDAPBind,OU=ServiceAccounts,DC=oholics,DC=net” -w “<MyPass>”

These commands all work just fine. Just for fun, make the last query type find something in particular – Look for a user account by its DN:

ldapsearch -H ldaps://dc.oholics.net:636 -b “DC=oholics,DC=net” -D “CN=svc-LDAPBind,OU=ServiceAccounts,DC=oholics,DC=net” -w “<MyPass>” “(&(objectclass=User)(distinguishedName=CN=John E Smoke,OU=Users,DC=oholics,DC=net))”

Now for some errors!

For both TLS and SSL on port 636, using the IP as the host (-h or -H) fails. It MUST use the FQDN of the target system. Why? because the certificate on the DC only refers to the FQDN of the server.

SSL/ 636 – The error “Can’t contact LDAP server (-1)” was really stumping me as there is little to go on in the error message. Doing a network capture, just shows the handshake start, but the DC ultimately just says “Go Away!”. It resets the connection attempt.

A few things learnt:

1. Using -h FQDN and -p 636 results in Can’t contact LDAP server (-1) (the URI method above must be used)

ldapsearch -h dc.oholics.net -p 636 -b “DC=oholics,DC=net” -D “CN=svc-LDAPBind,OU=ServiceAccounts,DC=oholics,DC=net” -w “<MyPass>”
ldap_sasl_bind(SIMPLE): Can’t contact LDAP server (-1)

2. Using -h IP Address and -p 636 results in Can’t contact LDAP server (-1)

ldapsearch -h 192.168.1.201 -p 636 -b “DC=oholics,DC=net” -D “CN=svc-LDAPBind,OU=ServiceAccounts,DC=oholics,DC=net” -w “<MyPass>”
ldap_sasl_bind(SIMPLE): Can’t contact LDAP server (-1)

3. Using -H with IP Address in URI and -p 636 results in Can’t contact LDAP server (-1)

ldapsearch -H ldaps://192.168.1.201:636 -b “DC=oholics,DC=net” -D “CN=svc-LDAPBind,OU=ServiceAccounts,DC=oholics,DC=net” -w “<MyPass>”
ldap_sasl_bind(SIMPLE): Can’t contact LDAP server (-1)

Additionally, for TLS connection. Using the IP address of the DC, resulted in a different, but much more helpful error message:

ldapsearch -h 192.168.1.201 -p 389 -b “DC=oholics,DC=net” -D “CN=svc-LDAPBind,OU=ServiceAccounts,DC=oholics,DC=net” -w “<MyPass>” -Z
ldap_start_tls: Connect error (-11)
additional info: TLS: hostname does not match CN in peer certificate

Also, where a Domain Controller has the setting “Domain controller: LDAP server signing requirements” set to Require signing. When trying to initiate an insecure LDAP query with ldapsearch, it fails as follows:

ldapsearch -h 192.168.1.201 -p 389 -b “DC=oholics,DC=net” -D “CN=svc-LDAPBind,OU=ServiceAccounts,DC=oholics,DC=net” -w “<MyPass>”
ldap_bind: Strong(er) authentication required (8)
additional info: 00002028: LdapErr: DSID-0C090257, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active on the connection, data 0, v2580

Well that was a fun day 🙂

U2F Login for WordPress – OPENSSL_VERSION_NUMBER Undefined

While looking to get this working: https://github.com/shield-9/u2f-login/, I was seeing errors in the http logs referring to OPENSSL_VERSION_TEXT. These were being generated by the following lines in the u2f.php file:

After running a few more tests, it seemed that this PHP Constant should have been defined, but was not. Goggling didn’t provide any quick answers, but I soon worked it out for myself.

In the php.ini file (under arch in /etc/php/), uncomment the line: “extension=openssl.so” and restart httpd. Once the extension is enabled, the Constant is then available.

In the end I did not use this plugin, I was unable to register my Yubikeys. The plugin seems to have been superseded by this one: http://github.com/georgestephanis/two-factor/. In order to have the ability to use U2F login using this plugin, the openssl.so extension has to be enabled; otherwise, the U2F login option is not available.

Getting PiGlow working on Arch Linux with Raspberry Pi 2

It initially seemed like a trivial task; after all getting the PiGLow working under Raspian was very simple!

But under Arch the method is significantly different…So, after digging about, getting all the pieces together – this is what I have and it works!

Now to get this to run on start-up…