Tag Archives: #OpenLDAP

More changes at simulakrum.org

Simulakrum moved from OpenBSD’s OpenLDAP 2.3 to a fancy CentOS’ 389 DirectoryServer. Let me know if your account is not working.

Password manager is upgraded to a recent snapshot of 1.8, and there is no more a possibility of self-served adding to the LDAP.

Owncloud moved from ownCloud 8 on Fedora 22 to Owncloud 9 on CentOS 7. Let me know if there are things missing.


Confluence and JIRA memberOf problem against OpenLDAP

I’ve just spent hours trying to figure out filters for either users or groups that would allow Confluence and JIRA to authenticate against OpenLDAP only those users that had “member” attribute for respective groups, all in vain. Both Confluence and JIRA simply ignore group membership unless “memberOf” attribute is used during the search. But simply turning the point around works – do not try to force Confluence or JIRA to use “member” attribute found in groups, but simply add “memberOf” attributes to each user you’d like in respective groups.

Mediawiki in chroot – php in hell

Setting Mediawiki’s LDAP authentication and mail functionality while it is running in an OpenBSD’s nginx chroot took some time to debug and prepare.

As always, the first thing should be the set-up of a log:

$wgDebugLogFile = “../logs/mediawiki/debug-{$wgDBname}.log”;
error_reporting( -1 );
ini_set( ‘display_errors’, 1 );

Continue reading

Apache 2 and LDAP group auth on OpenBSD 5.4

Recently I’ve ended up with only OpenBSD’s Apache 2 available to serve some pages that had to be authorised and authenticated through LDAP’s groups. Installing a few packages before that set-up pulled /usr/port/devel/apr-util that Apache’s FLAVOR=ldap simply didn’t like, because apr-utils were missing ldap flavour, too:

# FLAVOR=ldap make 
===> apache-httpd-2.2.25-ldap depends on: groff->=1.21 -> groff-1.22.2p1
===> apache-httpd-2.2.25-ldap depends on: pcre-* -> pcre-8.33
===> apache-httpd-2.2.25-ldap depends on: openldap-client-* -> openldap-client-2.4.35p1
===> apache-httpd-2.2.25-ldap depends on: apr-util-*-ldap – not found
===>  Verifying install for apr-util-*-ldap in devel/apr-util
`/usr/ports/bulk/amd64/apr-util-1.4.1p2-ldap’ is up to date.
===>  Installing apr-util-1.4.1p2-ldap from /usr/ports/packages/amd64/all/
Can’t install apr-util-1.4.1p2-ldap because of conflicts (apr-util-1.4.1p2)
— apr-util-1.4.1p2-ldap ——————-
Can’t install apr-util-1.4.1p2-ldap: conflicts
*** Error 1 in /usr/ports/devel/apr-util (/usr/ports/infrastructure/mk/bsd.port.mk:1876 ‘/var/db/pkg/apr-util-1.4.1p2-ldap/+CONTENTS’: @ /us…)
*** Error 1 in /usr/ports/devel/apr-util (/usr/ports/infrastructure/mk/bsd.port.mk:2388 ‘install’)
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2016 ‘/usr/ports/pobj/apache-httpd-2.2.25-ldap/.dep-apr-util-ANY-ldap-devel-apr-util,ldap’)
*** Error 1 in /usr/ports/www/apache-httpd (/usr/ports/infrastructure/mk/bsd.port.mk:2388 ‘all’)

Removing apr-util, subversion and apache-httpd helped, so I was able to build Apache 2 with support for LDAP from ports. If you need subversion, too, don’t forget to add it again, because Apache will, of course, build only apr-util as a dependency. Trying to remove apr-util on its own won’t be successful:

# FLAVOR=ldap make deinstall
===> Deinstalling for apr-util-1.4.1p2-ldap
Problem finding apr-util-1.4.1p2-ldap
*** Error 1 in /usr/ports/devel/apr-util (/usr/ports/infrastructure/mk/bsd.port.mk:3360 ‘deinstall’: @ /usr/sbin/pkg_delete -m apr-util-1.4….)
# FLAVOR=ldap make reinstall 
===>  Cleaning for apr-util-1.4.1p2-ldap
/usr/sbin/pkg_delete -m apr-util-1.4.1p2-ldap
Problem finding apr-util-1.4.1p2-ldap
*** Error 1 in target ‘_internal-clean’ (ignored)
===>  Installing apr-util-1.4.1p2-ldap from /usr/ports/packages/amd64/all/
Can’t install apr-util-1.4.1p2-ldap because of conflicts (apr-util-1.4.1p2)
— apr-util-1.4.1p2-ldap ——————-
Can’t install apr-util-1.4.1p2-ldap: conflicts
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:1876 ‘/var/db/pkg/apr-util-1.4.1p2-ldap/+CONTENTS’: @ /usr/bin/env -i PKG_TMPDIR=…)
*** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2388 ‘install’)
*** Error 1 in /usr/ports/devel/apr-util (/usr/ports/infrastructure/mk/bsd.port.mk:3348 ‘reinstall’)

Using SSL for LDAP was the other part of the problem. The combination that makes it all play nicely is the following: in the root, we need

LDAPVerifyServerCert off
LDAPTrustedGlobalCert CA_BASE64 /etc/apache2/ldap/ldap.pem
LDAPTrustedGlobalCert CERT_BASE64 /etc/apache2/ldap/ldap.pem

and for the directory we need

<Directory “/directory/that/we/auth/through/ldap/”>
Order allow,deny
Allow from all
AuthType Basic
AuthBasicProvider ldap
AuthName “Protected zone”
AuthLDAPBindDN “cn=ldapproxy,ou=users,dc=example,dc=com”
AuthLDAPBindPassword averysecretpass
AuthLDAPURL ldaps://thesslldap.example.com/ou=users,dc=example,dc=com?cn?sub
AuthzLDAPAuthoritative on
Require ldap-group cn=ThePrivilegedGroup,ou=bands,dc=example,dc=com

Your distinguished names will vary, though, as well as the pass, but this should be sufficient for the group auth with Apache 2 and OpenLDAP on OpenBSD.

slapd won’t start after a power failure

I had a power failure earlier in the day, and apparently all of the services came back to normal afterward. However, a warning message from PWM Password Self Service said it could not connect to LDAP.  Since nothing was listening neither at port 389 nor port 636, I had to restart the daemon. Trying to start the slapd manually resulted in failure, indeed:

 # /etc/rc.d/slapd start 

Starting the daemon directly, but with -u and -g options, and -h, while skipping the rest of the rc.d script worked (sometimes :))

# /usr/local/libexec/slapd -u _openldap -g _openldap -h ldap://\ ldaps://

# netstat -anf inet |grep 389
tcp          0      0          *.*                    LISTEN

and stopping the daemon immediately after such starting worked, but a subsequent start would fail again.

A brief insight in slightly re-crafted /etc/rc.d/slapd exposed the problem:

cat /etc/rc.d/slapd
# $OpenBSD: slapd.rc,v 1.4 2012/05/05 14:41:30 sthen Exp $

daemon_flags=”-u _openldap -g _openldap -h ldap://\ ldaps://\ ldapi://%2fvar%2frun%2fslapd.sock”

# To bind to multiple URLs, pass this to rc.d(8) via /etc/rc.conf.local:
# slapd_flags=”-u _openldap -h ldap:///\ ldaps:///”
# Note the escaped space between URLs. ^^

. /etc/rc.d/rc.subr


rc_pre() {
/usr/bin/install -d -o _openldap /var/run/openldap
rm /var/run/slapd.sock

rc_cmd $1

And there was no /var/run/slapd.sock, required once the rc.subr is sourced later in the script, and I wasn’t re-creating one with the above-mentioned manual command, which ultimately lead to this confusion! After touching it and a chown to _openldap, the script worked well again.

Integrate OpenLDAP groups and Gerrit 2.8.3

There had been a few changes regarding group organisation in the Gerrit’s schema after version 2.4, so versions newer than 2.5 will not have the “ldap” type in ls-groups search:

gerrit@continuum $ ssh -p 29418 gerrit.simulakrum.org gerrit ls-groups –type system
Anonymous Users
Project Owners
Registered Users

gerrit@continuum $ ssh -p 29418 gerrit.simulakrum.org gerrit ls-groups –type ldap
fatal: “ldap” is not a valid value for “–type”

This affects the searches in the WebGUI, too, and also implicates that a slightly different organisation of groups is necessary in Gerrit, starting from version 2.5. Tune your [ldap] section for OpenLDAP, so you could use groups from OpenLDAP as groups in Gerrit:

server = ldaps://openldap.example.com:636
sslVerify = false
referral = follow
username = cn=gerritproxy,ou=people,dc=example,dc=com
accountScope = subtree
accountBase = ou=people,dc=example,dc=com
accountPattern = (&(objectClass=person)(cn=${username}))
accountFullName = ${givenName} ${sn}
accountEmailAddress = mail
accountSshUserName =
groupScope = subtree
groupBase = ou=groups,dc=example,dc=com
groupPattern = (&(objectClass=groupOfNames)(cn=${groupname}))
groupMemberPattern = (member=${dn})

If the groups are read, once you start typing the name of the group from OpenLDAP, prefixed by “ldap/…”, the group name completion will be offered by Gerrit, just like it is for internal and system groups:

Screenshot from 2014-03-31 06:09:31

With this, the groups should be usable through Gerrit, and the only problem I found with version 2.8.3 is inability to somehow pull and populate the username from any of the OpenLDAP data, thus the accountSshUserName had to be unset (as can be seen above on the excerpt from the gerrit.config) so the user has to set it on the first log-in. Otherwise, no “account_external_ids” would be written in the database, and the user couldn’t use ssh and https access, even with the rest of the data in place.


P.S. if you play with asterisks, as discussed here, make sure you actually made what you intended: asterisks in Gerrit’s searches are happily expanded to the max, allowing everyone do everything, which is hardly acceptable!