Building an LDAP Environment: Part 2

It’s been quite some time since the last part of this series, however I have been busy working on the soon to be announced Push application as well as the normal day-job duties.  As a result, I will attempt to resolve several questions that have arrisen as well.  However let us first delve into some of the gotchas that I have noticed and use CUGNet’s LDAP layout as an example here.  Please note that this post was originally going to be a lot more detailed, however in the interest of getting the information out I will be referencing a lot of external material.

LDAP Intricacies: Several Lessons learned

LDAP’s freeform nature can lead you down a path of frustration until some basic principles are grasped and how they can bite you in the butt.

• LDAP is an Object Oriented Database: I make a point to state the obvious here as sometimes simply stating this may light a lightbulb in your brain.  Every object in the directory is built upon a class or series of classes.  In some cases classes are mutually exclusive.  This can create some headaches when you want a specific field however you simply cannot add it because of class limitations.  There is a way out however; the extensibleObject class.  If you add this class to your object via the objectClass attribute then every attribute will become available.  Keep in mind however that this should be used with care as misuse can cause some really strange behavior.
• Try to stick to Standard Schema Designs: This is something I see more often in Active Directory than anything else.  Bad directory design can not only cost you lookup time, but can make your directory almost un-traversable with some applications.  Keep good standards in mind when designing your directory (e.g. Keep users and Groups in separate locations, and preferably in just those locations)
• Backup your Directory with LDIFs: It may be tempting to backup the directories where the ldap directories are being stored, and in some cases this may make sense as well, however always keep a LDIF backup available as well.  A full LDIF dump may take a little time (for most directories under 10 seconds) however in the long run having a backup that almost any ldap tool can understand is worth it’s weight in gold.
• Add redundancies in your Directory Architecture: Again another simple thing that many people overlook.  You may not need a complex multi-master environment, however at the minimum look into setting up a slave server somewhere.
• Test any large changes before applying them into your main directory: Apache Directory Studio is a great way to handle this one.  You can setup a development LDAP environment and import your schema & directory in no-time.  There can never be enough testing, trust me.

LDAP TLS: Why you should support TLS and SSL

LDAP has no way to encrypt the network traffic on it’s own, so it relies on using TLS and SSL at act as a transport to encrypt the traffic for it.  If you do not use either of these methods then all of your login information is sent in the clear over UDP 389.  As with LDAP directory layouts there are many ways you can encrypt the datastream using TLS or LDAP.  I will cover only the most basic method and highly encourage you to look at this page for more detailed documentation.

Server

Assuming you already have a self-signed certificate ready (if not, go here for a good walkthrough) first you will have to add the following to the slapd.conf file:

TLSCipherSuite        HIGH:MEDIUM:+SSLv2
TLSCACertificateFile  /etc/ldap/ssl/cacert.pem
TLSCertificateFile    /etc/ldap/ssl/servercert.pem
TLSCertificateKeyFile /etc/ldap/ssl/newkey.pem
TLSVerifyClient       Never

Once this is complete, restart slapd.  Note that we are simply adding TLS and SSL to plain auth, this should not remove current client’s ability to authenticate.

Client

On the client-side, all you should have to modify is the /etc/ldap.conf file to add the following:

ssl starttls

Go ahead and save out the file and run the following:

getent passwd

If you still see all of the ldap users then you should be good to go.

User ACLs: Define Permissions for users to access the Directory

User ACLs should be defined for for any environment beyond the most basic of directories.  I will not go into much details here however I will refer you to this documentation and show what we are doing with the CUGNet directory.  ACLs can be brutally complex and may need to be taylored to individual needs, so make sure you know what you want to do before mucking around with ACLs.

CUGNet Example from our slapd.conf file:

access to attrs=userPassword,shadowLastChange,mail,sn,givenName
            by dn="cn=admin,dc=cugnet,dc=local" write
            by dn="cn=admin4,ou=people,dc=cugnet,dc=local" write
            by dn="cn=admin3,ou=people,dc=cugnet,dc=local" write
            by dn="cn=admin2,ou=people,dc=cugnet,dc=local" write
            by dn="cn=admin1,ou=people,dc=cugnet,dc=local" write
            by anonymous auth
            by self write
            by * none
access to dn.base=""
            by * read
access to * by dn="cn=admin,dc=cugnet,dc=local" write
            by dn="cn=admin4,ou=people,dc=cugnet,dc=local" write
            by dn="cn=admin3,ou=people,dc=cugnet,dc=local" write
            by dn="cn=admin2,ou=people,dc=cugnet,dc=local" write
            by dn="cn=admin1,ou=people,dc=cugnet,dc=local" write
            by * read

Howto Build an OpenLDAP Server

As I have been building and maintaning LDAP servers for some time now, I keep getting asked over and over if I will ever write a document describing how to easily get an OpenLDAP server up, how to get a Linux client to connect to it, and what are some of the pitfalls.  Well everyone, here ya go!

Also, I went through the entire process step-by-step and threw the photos up on Flickr.  The entire photo set should be at the bottom of this page if you need some extra assistance.

[Read more]

CUGNet has gone LDAP!

For a long time coming now there has been a push to goto LDAP for authentication on CUG. The benefits of doing this allow for a single point of authentication for not only system logins, but also tie in applications and web apps all under the same authentication model. There is still a lot of work to do to get all of the environment moved over, however the hard part of getting cugshell authenticating to it over the flat file is a definate start.

Thing ofcourse didn’t go as smoothly as we had hoped as the salted md5 hashes in the shadow file did t seem to take in the LDAP tree, forcing us to ask the users to file support tickets to reset their passwords. Most of the heavy users have already done so, and those that haven’t will likely visit the website and see the message on the main page.

Once we have completed the move, the next stage is going to the the website redesign. Something a little easier to manage and cleaner to the eye seems to be a must at this point.

As you can see we have been busy in CUG land and intend to be for some time to come. As always if you have any ideas or suggestions, please feel free to comment!