Showing posts with label OpenLDAP. Show all posts
Showing posts with label OpenLDAP. Show all posts

Wednesday, August 22, 2018

sudo: ldap_start_tls_s(): Connect error

A quick hint for FreeBSD users of sudo that authorize via LDAP. If you're getting the following message when running sudo:

sudo: ldap_start_tls_s(): Connect error

associated with this error message in the logs:

sudo: in openpam_check_error_code(): pam_sm_authenticate(): unexpected return value 27

Check that your ldap.conf TLS parameters are correct! In my case, Ansible pushed a bunch of pending config changes (and an OS update) to a neglected host, one of which included moving the CA certificate file, but failed to update the ldap.conf file. I chased my tail for a bit, thinking the issue was with nslcd.conf.

You may also notice a corresponding error in the log of the LDAP server. In the case of slapd:

slapd[40731]: conn=4892528 fd=219 closed (TLS negotiation failure)

Thursday, March 3, 2016

LDAP password hashing in PHP, a better way

Reviewing some PHP code related to user password changes, I noticed that the code was using unsalted SHA-1 hashes to store the password in LDAP. This is potentially very bad, if an attacker were able to gain access to the password hashes, because pre-computed rainbow tables for unsalted SHA-1 are pretty common. This has been the basis for a number of high-profile data breaches in recent memory, and I don't want to be on the news.

Looking for a better solution on Google, I quickly discovered the source of the bad code, the OpenLDAP FAQ-o-matic. In this FAQ entry, there are code examples for a variety of languages, many offering higher security. However, the PHP example included only a SHA-1 variant, and was copy-pasted nearly verbatim into my subject code (I wonder how many other web applications have done this very thing).

OpenLDAP has support for a variety of different hashing algorithms, including an optional SHA-2 module, and passthrough to the OpenSSL crypto(3) library. The strongest native cipher supported by OpenLDAP is salted-SHA1 (SSHA), which allows sufficient strength for this application, when used with a decently-large salt. I wrote the following function to generate such hashes from PHP, provided here in hopes that people will quit using unsalted SHA in their web-apps.

/*
 * This is a helper function, returning a Salted SHA-1 hash, suitable for LDAP.
 * OpenLDAP uses a slightly strange scheme for generating these hashes, but it's
 * far better than unsalted SHA. The only limit on salt length appears to be the
 * maximum length of the userPassword attribute in LDAP (128), allowing us to
 * safely use a 64-byte salt, resulting in a 118-byte SSHA. For the curious,
 * this works out to:
 *
 *   6B ({SSHA} tag) + 28B (20B SHA, B64 encoded) + 88B (64B salt, B64 encoded)
 *
 */

function generate_ssha_hash($cleartext)
{

        /*
         * Generate a unique 64-byte salt value for the salt.
         *
         * Use mcrypt_create_iv to generate some random bytes. PHP 7 has a
         * random_bytes() function, and the OpenSSL extension provides
         * openssl_random_pseudo_bytes(), which may be better, but this
         * should work
         */
        $pw_salt = mcrypt_create_iv(64, MCRYPT_DEV_URANDOM);

        // Concatenate and hash password+salt.
        $hashed = sha1($cleartext . $pw_salt, TRUE);

        // Add the tag and encoded hash+salt.
        $hashed = '{SSHA}' . base64_encode($hashed . $pw_salt);

        // Clean up
        unset($pw_salt);

        return $hashed;


} // generate_ssha_hash

Wednesday, April 6, 2011

Apache startup problems

After spending the better part of a day trying to track this problem down, I figured I'd be nice and share the fix, since google wasn't helpful. I was trying to fix a previously working apache installation and found that I was unable to authenticate using LDAP. With the apache logging set to debug, I received the following messages.

At apache startup:
[Wed Apr 06 08:56:30 2011] [debug] mod_authnz_ldap.c(1010): [2999] auth_ldap url parse: `ldap://ldap.blissfulidiot.com/ou=people,dc=blissfulidiot,dc=com?uid?sub?(clxEnabled=TRUE)', Host: ldap.blissfulidiot.com, Port: 389, DN: ou=people,dc=blissfulidiot,dc=com, attrib: uid, scope: subtree, filter: (clxEnabled=TRUE), connection mode: not using SSL

At authentication attempt:
[Wed Apr 06 08:57:58 2011] [debug] mod_authnz_ldap.c(403): [client 10.0.3.6] [5604] auth_ldap authenticate: using URL ldap://ldap.blissfulidiot.com/ou=people,dc=blissfulidiot,dc=com?uid?sub?(clxEnabled=TRUE)
[Wed Apr 06 08:57:58 2011] [info] [client 10.0.3.6] [5604] auth_ldap authenticate: user tom authentication failed; URI / [LDAP: ldap initialization failed][Unknown (private extension) error]

The solution for me on FreeBSD, rebuild the apr port.

Tuesday, November 9, 2010

PAM LDAP error: unexpected return value 4?

Are you seeing this error in your logs, along with an inability to log in?

Nov 9 15:05:08 leoger sshd[41524]: in _openpam_check_error_code(): pam_sm_acct_mgmt(): unexpected return value 4
Nov 9 15:05:08 leoger kernel: Nov 9 15:05:08 leoger sshd[41524]: in _openpam_check_error_code(): pam_sm_acct_mgmt(): unexpected return value 4

I did, and I figured out that the problem was caused by having changed my system hostname in config files and DNS, without actually having changed the hostname of the server. Note, the hostname must also be resolvable, either by DNS or /etc/hosts.

Saturday, November 14, 2009

OpenLDAP in Ubuntu Karmic Koala (9.10)

I've decided to try Ubuntu again because she's prettier than her big sister Debian and I had the naive hope that she might have finally gotten some professional help and a big dose of the crazy pills she needed. I was wrong, once you get past the sexy exterior she's still the same old pile of crazy that she was before.

I've been trying to set up a bunch of services and the documentation is generally useless since it's usually incomplete or so wrong that I wonder if the documentation team is a bunch of chimps flinging poo. So there will be a number of posts here to fill in some of the blanks. Ubuntu doc team, if you read this, please fix the docs rather than just cut and paste the manual from the last release.

First up, LDAP! FWIW, here is the original doc.

Getting it running

OpenLDAP in Ubuntu Karmic Koala (9.10) is not installed as described in the Ubuntu community documentation. Among its many detestable qualities, you are not prompted for the initial directory configuration during the dpkg run, and the way LDAP is setup is different from my (admittedly sketchy) recollection of how it was previously set up.

There is some documentation in forums on getting LDAP working properly, some of it good, some of it not. The post that got OpenLDAP running (properly?) for me is here. At the very least it was enough to allow me to get access to the database with PHPLDAPAdmin.

Creating SSL/TLS Certificates for LDAP

The official SSL Certificate document is surprisingly good. I followed it to set up a CA and create certificates for LDAP with pretty good results. There was only important thing that was not mentioned in the doc:
  • Take care to make sure that the correct permissions are set on private keys. These keys should not be readable by any user other than absolutely necessary for security.
The section of the LDAP documentation that describes setting up certs does the trick, but there are a couple things I recommend changing.
  • The document instructs you to add the openldap user to the ssl-cert group. I don't like this because it means that an attacker that compromises openldap can now read any private SSL keys also owned by ssl-cert (Apache?, OpenVPN?, could be bad). As an alternative, I used ACLs to give the openldap user access to the one specific file that it needs access to.
  • The Common Name field on your LDAP certificate should match the hostname of the server that any LDAP clients connect to; otherwise the LDAP clients will freak out.
  • Any LDAP clients need to be given a copy of the CA cert and instructed to use it. The following line should be added to the /etc/ldap/ldap.conf file and changed as appropriate to point at the CA certificate.
      TLS_CACERT /usr/local/etc/openldap/cacert.pem
  • If you are having difficulty testing to see if your SSL LDAP is working properly, try the following command, substituting your LDAP information.
    ldapsearch -x -ZZ -d -1 -b 'dc=example,dc=com' \
    -D 'cn=user,dc=example,dc=com' -h ldap.example.com -W
  • The section that discusses adding additional schemas to OpenLDAP is accurate, but not very clear. Step 3 uses the slapcat command to convert schema files to LDIF format. Unless you want to import the misc schema only, the schema files that you actually want are the ones in the ldif_output directory. Change the first line to the format
    dn: cn=SCHEMA_NAME,dc=schema,dc=config
    and the third line to
    cn: SCHEMA_NAME
    Remove the lines at the bottom as instructed, then import the schema file as instructed (using the correct file name of course).