Working with Microsoft's Services for Unix, Part 2

In the second of a two-part series, Emmett walks through setting up password synchronization in heterogenous environments.

• By Emmett Dulaney
• 08/23/2006

While it's thought that password synchronization is necessary in an integrated environment for users to maintain their sanity, it's so often the root cause of an administrator's insanity. I wish I could tell you that if you just follow the map from A to Z, then all your troubles will melt away. The truth of the matter, however, is that password synchronization is still a black art. There are dozens of solutions for implementing password synchronization available, but I have yet to find one that can be configured once and never thought of again.

You can spend days getting the synchronization to work perfectly at a site, then leave that site and discover that it stopped working the minute you walked out the door. This can be caused by something as obvious as a system going down and reverting to a previous (non-sync configured) state to something as nebulous as it starting to rain outside.

A number of authors have done an excellent job of writing about single sign-on and password synchronization and I would be remiss if I didn't point you to them immediately. From the Windows perspective (and particularly Windows 2003), it's hard to beat anything by Bill Boswell and a good starting point is his column "Linux-Windows Single Sign-On." One of the all-around best books on integration is Windows and Linux Integration: Hands-on Solutions for a Mixed Environment by Jeremy Moskowitz and Thomas Boutell. The title is in the process of being updated to include the latest operating systems (including Windows 2003 Release 2) and should be out soon.

With that caveat given, I want to focus on using Microsoft's Services for Unix (SFU) for password synchronization, walk through a very simple example, and then discuss some of the things that can cause problems when working with this science. Last month, we introduced the one tool that belongs in every integrator's toolkit: SFU. We walked through a definition, explanation, installation and overview of the product, which is really an amalgamation of many products into a single package.

With SFU, there are multiple levels at which password synchronization can take place: between servers, on a local computer, etc., but generally this can occur in one of two ways: Active Directory can copy entries into NIS or NIS can copy entries to Active Directory (it can be argued whether "copy" is the right word or not, but it'll suffice for this discussion). What you choose to copy from and to should be based on the network that you're administering or system you're using. On the network, for example, if you consider your network a Windows-based network with just a few Linux servers, then you'll want to copy from Active Directory to NIS and do your administration within AD. On the other hand, if you consider yourself a Linux administrator who must contend with a few Windows-based servers, then you'll be more comfortable administering the other way.

In order for synchronization to be possible -- and function -- four things must be present:

1. PAM (Pluggable Authentication Module) for synchronization (pam_sso) must be installed on every Linux computer where a user can change their password.
2. The Password Synchronization daemon (ssod) must be running on Linux.
3. The Password Synchronization service has to be running on Windows.
4. The permissions/trusts/security must be in place for everything to work as it should.

To create a framework, we are going to walk through the configuration of the simplest possible scenario: password synchronization on a local machine running Windows XP to a Linux machine (running Red Hat, SUSE Linux 10 or similar). I've chosen this example because it's one you can replicate and experiment with by yourself, as well as because it offers an example of the basics of synchronization without needing to ramble through concepts that are unrelated to this topic.

Step One:
The first item of business is to copy the binary file from the unix\bins folder (shown in Figure 1) on the XP machine that SFU was installed upon to /usr/bin on your Linux machine. There are a number of different versions of ssod beneath this folder; the correct one that works for most versions of Linux is ssod.rhl (the .RHL extension is for Red Hat, but it seems to work with most other distributions as well).

[Click on image for larger view.]

Figure 1. The bins folder holds the files that must be copied to the Linux machine.

You must have root permissions on Linux to do this, and once copied there, you must rename the file to just ssod. Next, copy sso.cfg over to the /etc directory and rename it to sso.conf. You will need to edit this file, and vi works well, but you can use any Linux editor to accomplish the task. While you may want to change some lines depending upon your implementation (discussed later and should be ignored for now), the one line you must edit is the one that begins SYNC_HOSTS=. There is a default entry here that needs to be changed to the IP address of the XP workstation you'll be synchronizing with. Make the change and save the file.

Step Two:
The next thing to do is install the pluggable module on Linux. To do this, copy pam_sso.rhl to /lib/security on the Linux machine and rename it to pam_sso.so.1. You must also check for the presence of two files beneath /etc/pam.d. There should be (but occasionally is not) a file there named system-auth. If the file is there, copy it to ssod. If it is not there, create it (use these samples as your guide).

Start ssod and you are ready to turn your attention to the Windows XP machine. NOTE: If you make any subsequent changes to the configuration file, you will want to kill ssod and restart it (which often requires a kill –9).

Step Three:
Even though SFU is installed, password synchronization is not installed by default. To install this service, choose Add or Remove Programs in the Control Panel, and select Add/Remove Windows Components. Click on Microsoft Windows Services for Unix and click Change. This starts the Maintenance Wizard shown in Figure 2. Choose Add or Remove and click on Next. At the Selecting Components screen, choose Password Synchronization and "Will be installed on local hard drive" (the default is "Entire feature will not be installed") and click Next. The wizard will perform the installation and finish. You'll be required to reboot for the changes to be accessible.

[Click on image for larger view.]

Figure 2. The maintenance wizards walks you through the installation of additional Services for Unix components.

Step Four:
Once the reboot is finished, you can start Services For Unix Administration, and the module for configuring password synchronization will be present, as shown in Figure 3. Notice that there are two tabs: Default (shown in Figure 3) and Advanced.

[Click on image for larger view.]

Figure 3. You can now configure password synchronization on the local computer.

On the Default tab, you can choose which direction the synchronization will occur and choose a different port number. The values here must match the values in the sso.conf file or you'll end up scratching your head and wondering why the synchronization isn't working as it should. If you do make any changes here, verify that value is the same in the /etc/sso.conf file on the Linux host.

Note the checkbox option of enabling extensive logging. Logging is done by default, but only on completed synchronization and not the in-between steps. I highly recommend you enable the extensive logging when you're first experimenting with password synchronization so you can see what is occurring and verify that all is working as it should. Entries are written to the Application log and can be viewed with Event Viewer (on the Linux side, and unrelated to this checkbox, entries are written to the syslog - /var/log/messages).

[Click on image for larger view.]

Figure 4. The Advanced tab allows configuration of the Linux hosts.

The Advanced tab, shown in Figure 4, allows you to configure which Linux host(s) the synchronization will occur with. While the prompt is for computer name, you can also opt to use IP addresses and they work equally well. The Configure button brings up a Web page dialog allowing you to individually configure each host. You can check both boxes ("Synchronize password changes to" and "Synchronize password changes from") to create a two-way medium for password synchronization. This is also known as chaos, and I highly recommend just using "Synchronize password changes to" for this discussion and sticking to one or the other for most implementations.

Click Apply and exit.

Step Five:
It's time to put the synchronization to the test. Choose a username that appears on both hosts and change the password for that account on the Windows XP machine. There should be a way to force the updates (even just a button you could click on somewhere to make it seem like you did something), but there isn't and you have to assume that synchronization is being carried out.

Check Event Viewer (Application log) in Windows XP and verify that the change was made and the data sent to the Linux host. On the Linux host, check the syslog to see if the change was received and processed. You can also check the data/time associated with /etc/shadow to see if it was changed. If all worked as it should, you should be able to login on the Linux host as the user using the new password and the configuration is complete.

Real World Issues
The example just discussed set up a very simple synchronization that should work flawlessly. In the real world, synchronization should work exactly the same regardless of the size of the network and whether you're standardizing on NIS or Active Directory. Unfortunately, a number of problems can occur.

[Click on image for larger view.]

Figure 5. Errors are written to the Application log and can be viewed with Event Viewer.

Most problems will write an entry to the Application log that can be seen with Event Viewer, as shown in Figure 5. Although the entry is there, the "Generic Error" is essentially meaningless and not of much aid in troubleshooting. If you click on the link for more information, almost all SFU Event IDs result in no help at all, as shown in Figure 6. You have to be patient and use the log files as your eyes and ears to working through issues.

[Click on image for larger view.]

Figure 6. There is not much help available for SFU problems.

Among the first things to check for when trying to make this work is to verify that you have the service/domain running on all machines that should be synchronizing. Not only is the service there, but the configuration files have all the correct values in them (trusting hosts, etc.).

As simple as it sounds, you want to make sure that you check the correct box for which way the password changes are to flow. The last thing you need is for the changes to be overwritten by old values because you've checked the wrong checkbox.

Lastly, use something other than default values for the port number, encryption/decryption key and so on. These are well-known values and for security purposes you should avoid using them (particularly the key).