Authenticating Active Directory users on Linux with Likewise Open

Historically, if you wanted to use Active Directory to authenticate users on a UNIX box, you were pretty much limited to using LDAP. This works fine for some people, but it’s not particularly elegant – especially if you’re having to create users home directories all the time, which negates some of the point of centralising authentication to begin with.

I’m from a UNIX (mostly Linux) background, so I’m more at home using UNIX-alike platforms. That said, there’s a few things that Microsoft do that are particularly useful, and in my opinion AD is one of them (quiet at the back, there). Handily, there’s a project that can marry the two, and it goes by the name of Likewise.

Likewise Enterprise is Likewise Software’s commercial offering, but they also provide an open-source edition in the form of Likewise Open, which is what I’m going to focus on here. Conceptually, using Likewise is equivalent to binding a Windows machine to a domain, and the method of doing it is similar. The code is somewhat related to Samba, so some parts of it may be familiar to anyone who’s meddled around with Samba in any depth.

Starting out

First off, you’ll need the Likewise Open installer, which you can get from here (signup required). Grab the installer for your particular distro or operating system – for this example I’m using a fresh Debian (lenny) GNU/Linux install, but the process is essentially the same for others, such as Solaris. One you’ve got it, installing it is just a matter of running it:-

adtest:~# chmod +x ./LikewiseIdentityServiceOpen-...-linux-i386-deb-installer
adtest:~# ./LikewiseIdentityServiceOpen-...-linux-i386-deb-installer

Follow the prompts, and after a few seconds you’ll be returned to a prompt. Assuming the install completed successfully, in the case of Debian (or Ubuntu), running ‘dpkg -l | grep likewise‘ will show a few new packages have been installed (for RedHat/CentOS, replace ‘dpkg -l‘ with ‘rpm -qa‘).

Before going any further, make sure your resolvers are set up correctly, and that the local machine’s time is synchronised – either against an external NTP source, or one of the domain controllers. You can check that DNS resolution is working correctly by running:-

adtest:~# host test.example.com

…and all being well, you’ll see something like this:-

test.example.com          A     10.1.1.1
test.example.com          A     10.1.2.1

If you’re okay so far, configuring the machine to use AD requires one command:-

adtest:~# /opt/likewise/bin/domainjoin-cli join test.example.com andys

After a few seconds, providing the local machine can see the domain controllers, you should be prompted for your domain password. As when binding a Windows machine to a domain, the account you use must have the right privileges, which usually means that it’s in the Domain Admins group or similar. So:-

Joining to AD Domain:   test.example.com
With Computer DNS Name: adtest.test.example.com

andys@TEST.EXAMPLE.COM's password: <domain password>

…wait a few seconds…

Warning: System restart required
Your system has been configured to authenticate to Active Directory
for the first time. It is recommended that you restart your system
to ensure that all applications recognize the new settings.

SUCCESS

Now, in my experience you don’t strictly need to reboot, however it’s a good idea to, so go ahead and reboot the machine.

The basics

Assuming the box rebooted, we can now test that AD integration is working. Log in, and at a prompt type:-

adtest:~# id TEST\\andys

…replacing ‘TEST\\andys‘ with your domain and username. The double backslash is important, because most UNIX shells use ‘\’ for escaping characters. If you want, you can also use the ‘user@domain‘ syntax. If all is well, you’ll see something like this:-

uid=2096628820(TEST\andys) gid=2096628225(TEST\domain^users)
groups=2096628225(TEST\domain^users),2096628224(TEST\domain^admins)

At this point I should offer a word of caution: Because the machine is now bound to the domain, it means users on the domain can log into it. Obviously this is the whole point, but it’s something to be mindful of, especially if the domain is used by many people.

The UIDs and GIDs may look ridiculously large, but don’t worry – UIDs under most UNIXen are 32-bit, so this will be fine. There’s also a good reason for it – Likewise guarantees that the IDs will be unique and consistent across all machines bound to the same domain. You’ll also notice that the user’s primary group is set to the primary group from AD, which is usually ‘Domain Users‘.

The domainjoin-cli command also makes some changes to /etc/nsswitch.conf and the PAM configuration. On my example Debian box, having a peek at /etc/pam.d/common-auth reveals:-

auth    sufficient    /lib/security/pam_lsass.so
auth    required    pam_unix.so nullok_secure try_first_pass

pam_lsass.so is the PAM shared library for the lsass – or Local Security Authority Subsystem Service – part of Likewise. The example above is simple enough, and accepts domain users, falling back to standard UNIX users if the given username isn’t a domain user.

Making changes

Likewise installs its configuration files in /etc/likewise. The one that’s probably of most interest is lsassd.conf, which controls how the lsass daemon lsassd handles users. Before going into any detail, you’ll notice that lsassd.conf is split into two sections – the first being for domain users (the [auth provider:lsa-activedirectory-provider] section), and the second being for ‘local’ users (under [auth provider:lsa-local-provider]). The local users are usually just ‘COMPUTER\Administrator‘ and ‘COMPUTER\Guest‘ (where COMPUTER is the name of the local machine), and are synonymous to the Administrator and Guest accounts on Windows machines. Chances are you won’t need to touch the local users section, so we can safely ignore it.

There’s quite a few options to play with in lssasd.conf, but the main ones we’re interested in are:-

• login-shell-template, which allows us to set the default shell for domain users. This is (by default) set to /bin/sh, so in many cases you might want to change it to /bin/bash.
• homedir-template, which specifies where domain users’ home directories will be created. The default for this is %H/local/%D/%U, which in our example would expand to /home/local/TEST/andys for my account. Personally, I prefer to drop the ‘local’ bit and use %H/%D/%U, which would change my home directory to /home/TEST/andys.
• require-membership-of, which lets us specify which groups are allowed to authenticate against this machine in a comma-separated list.

It’s important to note that if you use the last option, any domain user which isn’t a member of one of the specified groups will fail any PAM configuration that calls pam_lsass.so. This means that if you wanted to allow certains groups SSH access, whilst allowing a larger set of groups access to FTP, you don’t want to omit the FTP user groups from here. If you’re building this kind of setup, you’ll want to allow all the groups in lsassd.conf, and then build your PAM configuration to conditionally allow access based on group membership using pam_group.

Once you’ve finished making your configuration changes, you’ll need to tell Likewise to reload the configuration:-

adtest:~# /opt/likewise/bin/lw-refresh-configuration
Configuration successfully loaded from disk.

It also doesn’t hurt (and I’ve sometimes found it neccessary) to clear the local AD cache:-

adtest:~# /opt/likewise/bin/lw-ad-cache --delete-all
The cache has been emptied successfully.

…and that’s it! You should now have AD authentication working through PAM.

Useful commands

Likewise installs quite a few tools in /opt/likewise/bin (many of which are symlinks to lw-lsa), some of which come in handy for testing:-

• lw-refresh-configuration, which as mentioned above reloads the lsassd configuration from lsassd.conf.
• lw-ad-cache (also partly mentioned above), which lets us manipulate the local AD cache. For example, lw-ad-cache –enum-users will list the users’ details currently stored in the cache.
• lw-enum-users/lw-enum-groups, which predictably list all the users and groups in the domain.
• lw-get-status, which shows quite a bit of information about the domain itself.

These are just a few, so it’s useful to have a poke about in /opt/likewise/bin and see what there is.

Hints

Because Likewise integrates itself via PAM, pretty much everything which can work with normal UNIX users can cope fine with domain users. For instance:-

• You can use the tilde (~) shortcut to go to a domain user’s home directory, for example cd ~andys@TEST. For some reason, the backslash notation doesn’t work here, and you may also notice that tab completion doesn’t work either.
• With most things, you can refer to domain users as either TEST\\andys, TEST.EXAMPLE.COM\\andys, andys@TEST or andys@TEST.EXAMPLE.COM, including when logging in on the console or via SSH. There are exceptions (such as the previous point), but they’re few and far between.
• Sudo happily works with domain groups – just remember to double-backslash.
• You can use chown and chgrp in the ways you’d normally expect, using either the domain group names, or their GIDs.
• ACLs (under Linux) also work, so if you’ve mounted a partition with the ‘acl‘ option, you can use setfacl as normal.

If it all goes wrong…

Sometimes things go wrong. With Likewise, it’s usually straightforward. If you’re getting errors when binding to the domain with domainjoin-cli, it’s usually because it’s having problems connecting to the domain controller. If your domain controllers are on a different network, check that any firewalls inbetween aren’t dropping SMB traffic. The domainjoin-cli command should give you a definitive list of ports it needs open to communicate with the domain controller.

Once up and running, I’ve found Likewise Open to be very stable, but on the odd occasion that something has gone awry, it’s often enough to just restart the lsassd daemon. Failing that, try emptying the cache (with lw-ad-cache –delete-all). If you’re still getting odd errors, it might be worth checking out the documentation or the forums.

Where to from here?

Because the PAM magic happens with pam_lsass, in theory anything which uses PAM can be made AD-aware. I’ve personally used it with Pure-FTPd to provide company-wide access to an fileserver, and it works flawlessly with gdm, so you can use it on your desktop. Again, because it’s PAM-based, it can be stacked with other modules such as pam_securid (for RSA’s SecurID tokens) or pam_opie (for one-time password sets).

Ironically, one thing that does require a little bit more configuration is Samba – something I’ll cover in a future post.

Update: Yvo van Doorn comments below with a handy hint if you only need access to one domain, which should save on keyboard wear for some users