I just wasted a day and a half banging my head against this problem, and while I suspect there are probably only about a half-dozen other sites on the planet that are likely to encounter this problem, I wanted to write down the solution. So, just in case anyone else has been furiously Googling for some combination of “ActiveLdap SASL GSSAPI bind connection error”, here’s one possible solution.
We use MIT Kerberos, OpenLDAP, and Cyrus SASL to provide single-sign-on across our network services at Reed. I’ve been working for a while to port legacy Perl-based systems over to Ruby, and using ActiveLdap for much of that work, but have hit a snag that limits its utility to use in many cases: namely, that GSSAPI-mech SASL binds fail if there is no corresponding LDAP directory entry for the principal under which you’re doing the bind.
Let me explain a bit of background:
OpenLDAP ACLs allow you to specify something like the following:
authz-regexp
uid=(.*),cn=gssapi,cn=auth
This basically says, “for any principal that our authentication backend accepts, treat them as a valid LDAP entity with the DN ‘uid=[principal-name],cn=gssapi,cn=auth’”. This is incredibly handy when coupled with Kerberos keytab files, as it lets us get the same basic benefit as certificate-based authentication without maintaining a certificate authority. (As an aside, we do actually maintain a small CA setup, but since the CA data lives on an external drive in a locked cabinet, rolling a new cert is a huge pain compared to creating a new keytab from kadmin.)
This is all well and good, and lets us set up background processes which have keytab-based privileges to selectively read and edit protected attributes on our directory, without putting passwords into configuration files or source code. It also means we don’t have to create a full-fledged directory entry for every little background service which may need to authenticate.
Unfortunately, ActiveLdap is unable to determine that it has successfully bound to the directory if the SASL GSSAPI principal it uses to bind doesn’t have a corresponding entry. It just loops over the reconnect method until the configured number of attempts is reached, then falls back to an anonymous bind.
If all of that was gibberish to you, rest easy; like I said, our particular mixture of infrastructure and directory-maintenance practices is pretty rare, especially outside academia, so you’ll probably never have to worry about any of this.
Recent Comments