How to add a new schema to openLDAP 2.4+

I tried to stay away from the new config type in LDAP introduced in v.2.3 as much as I could but today I had to face it.

I understand the reasons behind but I have to say that the docs are pretty scarce and any newbie has a pretty steep learning curve ahead especially if used to the old way of configuring LDAP.

The configuration now is in ldif format and it follows a pretty logical scheme which is clearly shown in this picture

What you find inside these trees (which are also directories inside /etc/ldap/slapd.d dir) is all your LDAP server knows about, all the rest in the /etc/ldap is not really that interesting.

Anyway you are to read something else, I know. I could not honestly find a straight answer to the question which gives the title to this post, even though there are a lot of places that contain bits of info but as usual the amount of work needed to get everything in place is still some. That's why I am writing this post.

[UPDATE: just found this which is pretty close to what I needed.]

I will start with a practical real-life example: Adding the sshPublicKey schema kindly provided here to your LDAP server. [I am basing my example on a Debian Squeeze installation]

Now you will find in /etc/ldap/schema/ a lot of .schema files. And there is where you will start to get confused... so forget the schema files.

Copy paste the openssh-lpk_openldap.schema in /etc/ldap/schema/ directory (just to keep them happy together):

#
# LDAP Public Key Patch schema for use with openssh-ldappubkey
# Author: Eric AUGE <eau@phear.org>
# 
# Based on the proposal of : Mark Ruijter
#


# octetString SYNTAX
attributetype ( 1.3.6.1.4.1.24552.500.1.1.1.13 NAME 'sshPublicKey' 
 DESC 'MANDATORY: OpenSSH Public key' 
 EQUALITY octetStringMatch
 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 )

# printableString SYNTAX yes|no
objectclass ( 1.3.6.1.4.1.24552.500.1.1.2.0 NAME 'ldapPublicKey' SUP top AUXILIARY
 DESC 'MANDATORY: OpenSSH LPK objectclass'
 MAY ( sshPublicKey $ uid ) 
 )

Create a tmp directory, e.g. /tmp/ldapstuff and create a dummy file there called for instance slapd.conf which simply has this line

include /etc/ldap/schema/openssh-lpk_openldap.schema

Run

cd /tmp/ldapstuff && slaptest -f slapd.conf -F .

This will create in place a dir called cn=config and a file cn=config.ldif.

Run

cd cn=config/cn=schema && vim cn={0}openssh-lpk_openldap.ldif 

 The only interesting things that need to stay in that file are the  following:

dn:
cn:
objectClass:
olcAttributeTypes:
olcObjectClasses: 

So remove everything else and edit dn and cn. This is a schema so it will need to be inside the cn=schema,cn=config LDAP tree, so the result should be

dn: cn=openssh-lpk_openldap,cn=schema,cn=config
cn: openssh-lpk_openldap

Now you are ready to add this to your LDAP server:

ldapadd -Dcn=admin,cn=config -W -f /tmp/ldapstuff/cn=config/cn=schema/cn={0}openssh-lpk_openldap.ldif

That's it, you can verify that it's really there by

ldapsearch -xLLL -D cn=admin,cn=config -W -b cn=config cn=*ssh*

This should give you some result. This is pretty much applicable to any other schema.

Mocking LDAP calls with minimock in python

When using unittest in python you often need to mock objects and calls to those objects.

You don't need _an_entire_ LDAP server just to test a search nor you need a full blown SMTP server to test a function that accidentally sends a mail (that you don't want to send while testing anyway).

So minimock is one easy way (the easiest I found) to do the job.

What the docs don't really tell you (nor does a google search) is how to return real things when you need to call a method of an object.

Say you have some code like this:

import ldap
class MyClass:
...
    def ldapsearch(self, uid):
        self.conn = ldap.open(self.conf.ldapserver)
        self.conn.bind_s(binddn, bindpw, ldap.AUTH_SIMPLE)
        self.conn.search_s(basedn, ldap.SCOPE_SUBTREE, 'uid=%s' % uid, ['uid'])
        return True

and you want to test this and moreover you want that search to return a given set of data.

from minimock import Mock
import ldap
from my_program import MyClass

class MyClassTest(unittest.TestCase):
...
    def test_ldapsearch(self):
        # create your fake ldap connection
        ldap.open = Mock('ldap.open')
        ldap.open.mock_returns = Mock('ldap_connection')
        # instantiate your class
        myclass = MyClass()
        # now tell to minimock that in case we do a search_s on 
        # a conn method this should be intercepted and mocked
        # returning a testuser1 value the way LDAP would do
        myclass.conn.search_s.mock_returns = [[1,{'uid':['testuser1'], \
                                        'mail':['test.user1@mail.com']}]]
        # This will return testuser1 no matter what
        # and show you on screen the operations performed
        self.assertEqual(myclass.ldapsearch('onetwoonetwo'), True)

This should help you inject whatever values you want there and also clarify a bit how to minimock wants you to think (that is the only way I could make it work).

Apache2.2, LDAP authentication / authorization and require ldap-group

In Apache2.2 (default in Debian Etch) all the LDAP authentication/authorization was rewritten. (Thank you guys for a great piece of FREE software.)

The module that performs both authentication (Authn) and authorization (Authz) for Apache sometimes is not very intuitive as Brad Nicholes says in this comment.

The problem is this: I have a nice way to provide an authentication Alias through mod_authn_alias to keep my Apache config clean and understandable BUT I cannot use that Alias to perform Authorization in many cases...

For example if I want to use

Require ldap-group

directive I have two ways of doing it.

either you DON'T use AuthnProviderAlias (BTW I just understood that Authn stands for authentication while Authz stands for Authorization... VERY intuitive) like this:

<Directory /mydir>
AuthType Basic
AuthUserFile /dev/null
AuthName "Access"
AuthBasicProvider ldap
AuthLDAPUrl ldap://myldap.server.com/o=myorg?uid?sub
AuthLDAPBindDN cn=account,ou=accounts,o=myorg
AuthLDAPBindPassword ****
require ldap-group cn=AGroup, ou=Groups, o=myorg
Options Indexes FollowSymLinks
Order deny,allow
Allow from all
</Directory>

Or you DO specify both the Authn alias AND the AuthLDAPUrl in the Directory, so like this:

<AuthnProviderAlias ldap ldap-alias>
AuthLDAPUrl ldap://myldap.server.com/o=myorg?uid?sub
AuthLDAPBindDN cn=account,ou=accounts,o=myorg
AuthLDAPBindPassword ****
</AuthnProviderAlias>
<Directory /mydir>
AuthType Basic
AuthUserFile /dev/null
AuthName "Access"
AuthBasicProvider ldap-alias
AuthLDAPUrl ldap://myldap.server.com/o=myorg?uid?sub
AuthLDAPBindDN cn=account,ou=accounts,o=myorg
AuthLDAPBindPassword ****
require ldap-group cn=AGroup, ou=Groups, o=myorg
Options Indexes FollowSymLinks
Order deny,allow
Allow from all
</Directory>

In a few words it doesn't make sense to use AuthnProviderAlias in this case... Just use the first approach, even though it looks very bad... it looks better than the other :D