Single Sign-On and the Corporate Directory, Part III

Welcome to the third installment of how to
implement a single sign-on and corporate directory system. In this
article, we tackle integrating Microsoft Windows clients. There's
a lot involved to make it all happen, so put on your work gloves and
let's get to it.

When you want to integrate Windows clients into a heterogeneous
environment, you have some choices to make. Although you can run an Active
Directory (AD) server and have your Linux and Apple clients bind to it
for authentication and identity management, the costs involved are not
minimal. It also wouldn't make for an interesting article on an open-source single sign-on and directory implementation.

When you're binding
Windows clients to an open-source solution, you have two more choices to
make. Do you bind them to the Kerberos realm for authentication or do you
bind them to LDAP for identity management? This is an either/or choice
because although Windows clients know how to speak both Kerberos and LDAP,
they know how to speak them at the same time only when talking to an AD
server. In other words, Windows clients can talk to a non-AD Kerberos
server only when the user's identities are kept locally. Likewise,
a Windows client can get identities from LDAP via Samba, but only when
the passwords are also served via Samba, and Samba can't, at the moment,
authenticate via Kerberos.

Having Windows authenticate against our Kerberos KDC is easier to
set up, but it could be harder to maintain because every user who uses
the Windows client needs to have a local account. This is fine if
all you have is one Windows client to maintain, but if you have any more
than that, you'll need to add every user to every client. I won't explore this
option; however, if you're interested you should pick up Jason Garman's
Kerberos: The Definitive Guide.

Configuring Samba

Because we're dealing with a corporate directory, I'm assuming you probably
have more than one Windows machine on your network. In order to make using
them and incorporating them as painless as possible, we use Samba tied
to our LDAP directory as a back end. Even though we'll be configuring
Samba a little differently, you should first read Craig Swanson and Matt
Lung's “OpenLDAP Everywhere
Revisited” (see the on-line Resources), as it will give you a good foundation
on which to build. I
created an organizational unit branch in the directory named samba for
Samba specific entries such as machines and ID maps. Listing 1 shows the
hierarchy of these special branches, and Listing 2 shows the LDIF for them.

I don't use the smbldap scripts from IDEALX for creating necessary
entries,
because I'm using LDAP for more than just Samba authentication. One main
reason for not using the smbldap tool is because it assumes that it
and Samba will be the only point for actions such as adding users and
groups. In my environment, all users don't have the ability to log in
to Windows machines. Some users may start off as Linux-only users,
but then need to be given access to Windows machines later. The smbldap
tools don't handle this case very well. However, the smbldap tools do
handle other things nicely, so like all things, investigate all the
tools available and choose the best one(s) suited to your needs.

We need several users in LDAP that will do various tasks. First we need
a user who has write access to certain pieces of the directory. If
you notice in /etc/samba/smb.conf, there is an option, ldap admin dn,
that defines the DN of this user. This user, named samba_server, should
be stored in the LDAP directory itself, and it will be the only user in
the directory with a password associated with it. Because this user isn't
of the posixAccount objectClass, the account is not recognized under
Linux. To create this user, first run slappasswd to generate the hashed
password. Then, take the hash and create an ldif file that's similar to
Listing 3.

Trending Topics

Webinar: 8 Signs You’re Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
11am CDT, April 29th

Join Linux Journal and Pat Cameron, Director of Automation Technology at HelpSystems, as they discuss the eight primary advantages of moving beyond cron job scheduling. In this webinar, you’ll learn about integrating cron with an enterprise scheduler.