Git repository for ‘Single Sign On’-project

When I first made my installer for OpenLDAP I did this for my own convenience. But while doing so I realized the script could be useful for more people and I published it on my blog. Then it became big, and I invited Sean to write for my blog about this project. For Sean and you guys I just made a git repository on GitHub so anyone can edit the installer to be the best (and first) SSO-installer ever.

So please help this project and fork the project at https://github.com/hermanbanken/Ultimate-Single-Sign-On-Enviroment-Installer.

Single-Sign-On OpenLDAP: Part 2 – Schemas

Schemas

So what are these schema files anyway?  What do they do and why do we need to add a new one to get authentication with Windoze?  Drop the “a” from the end and it will give you a hint.  They are schemes or models or layouts for what our LDAP directory and all of it’s objects will look like.  They describe every attribute of the directory from top to bottom and put governing rules on what is allowed in the directory.  They don’t contain any real directory data at all, they only describe what the objects will look like.

There are attributes; which describe each of the individual variable pieces of data, and then there are objectClasses; which describe how all of the attributes are attached and combined so as to describe actual objects.  An example attribute might be called “name” and it might be a member of a “person” objectClass.  Whenever a “person” object is stored in the database, there will always be a spot to put the person’s “name”

What’s neat about these schemas is that you can describe an object once, and then use that to add meaning to other objects.  For example, you might define a “posix-user” class that contains attributes that are relevant to user in a posix environment.  It might have attributes for GID and UID.  Once we describe the “posix-user” schema, we can apply that schema to our “person” object from before.  Now we have a person that also contains the needed attributes of UID and GID.  If we take this a bit farther and add home directory, shell and password attributes, our “person” object  might soon contain all the necessary attributes to be a valid posix user.  Once that happens, suddenly they can log in and galavant around in Linux land.

This is what Herman did with the apple schema, and exactly what we need to do with the samba schema.  To create a “user”, I believe the base objectClass we use is “inetOrgPerson” which contains all the generic “person” info…address, name, phone numbers, etc.  Then we also give it the “apple-user” objectClass (which give it all of the apple specific things), and also now the “sambaSamAccount” objectClass (which gives it all of the Windows specific attributes).  When we add the samba schema, it leaves all of the apple info intact and simply sets up a new area for the Samba attributes.  In other words, we are adding an objectClass and all of its attributes, but not messing with whats already there.

Herman’s installer did include a samba schema file, but after some trial and error, I found out that it was a legacy samba schema file..perhaps for Samba 2.0.  It didn’t have all of the needed attributes, and many of the attributes it did have used a different naming scheme.  Even if we had had Samba up and running as a PDC, it wouldn’t have been looking in the right places for the needed attributes.

I’ll post the schema as soon as I can figure out how to get the system to let me post it.  I don’t really feel like comparing, but I’ll bet that what I have matches this.

This was the first part of the puzzle for me… I’ll be back with more soon.

~Sean

Single-Sign-On OpenLDAP

First off, let me say I am not any kind of OpenLDAP guru.  I came to Herman’s blog looking for help.  I have been messing around with LDAP in many forms for a few years now, and have never really understood much about it.  I could follow a tutorial, and sometimes get a working sign on system on one OS, but the idea of a single-sign-on authentication system always seemed out of my grasp.  This stuff is not easy to understand.  There’s a steep learning curve and I’m just rounding the corner of discovery, so go easy on me!

Why?

I’m a sys admin, and the idea of a single-sign-on system that allows you to maintain users for all OSes in one place is a shangri-la for me.  As admins, we are a busy people.  Adding users to groups and changing passwords in three places are not high on our priority lists.  Anything that takes away maintenance responsibilities gives us more time to “work” on our current lan game championship.  And that, of course, is time well spent.

Adding to my motivation is the current state of affairs at my shop.  We use a patchwork of systems; Active directory with windows Unix Services to link users with an NIS server.  The macs aren’t even on the domain.  So if you want to add a new user, you need to create them in active directory, then go to the samba server and do a `smbpasswd -a`, then take note of their UID and GID and update those values in the Unix Services plugin in Active Directory.  And the Macs need to be updated individually.  It’s a mess.  There’s lots of places for things to go wrong, and changes to users don’t get published when you change them in active directory, you have to manually push them out to the different servers.

I found out about OpenLDAP a few years ago and on my free time have tried to come up with (or…can you say Google?) a good solution to our work problems.  I’ve had little bits of success, but without the boss actually behind me in these ventures it becomes tough to find the time.   I found some time again recently and for the first time, with Herman’s help, a single-sign-on system is a reality (for me).  I also must give tons of credit to this post on the Ubuntu forums. He gave me the building blocks to get the Samba side of things going.

I know there are plenty of people that have set up this kind of system before, but they never seem to share it in it’s entirety.  I’m hoping to fill that gap.  This system allows you to go to one machine to add a user, and as soon as you set a password, that user can log into any box on the domain, whether it is Linux, Mac or (god forbid) Windows.  When you change the password, the change is instantly recognized on all systems.  Permissions work seamlessly on shared resources…Samba, NFS, CVFS, etc.  Also, because Herman spent the time to carefully set up all of the Mac specific attributes, you get to store all of the cool stuff that Open Directory contains.

It’s not quite right, but (I think) it is the foundation of a great system.  I will try to write a nice installer like Herman has done with the changes/additions needed for this system.

Before I get into details (and because Im not prepared…) here’s an overview of what we will do.

Samba, Schemas and Pam

A few major things need to be added/changed in Herman’s setup to get the login system to work on Windows.  (and Linux)  The missing piece of software to allow this is Samba.  We are going to set up Samba as a PDC (Primary Domain Controller) and have it use the same OpenLDAP directory data that we used for Herman’s all mac setup.  Well, actually we will modify his installer script, and add/update a few schemas, so that when users are created, not only do they include the mandatory attributes for Mac, but they contain the mandatory attributes for authenticating against Samba.  We will also set up PAM authentication for the server and Linux clients. Finally, once we get the directory up and running and Samba configured, we will modify the Smbldap-tools so that they add users with all of the needed objectClasses for all OSes.

Be back in a few days.

~Sean