Figure 2 shows the User Name Mapping process. A user at a Windows-based Client for NFS system uses Windows credentials to ask a DC that's running User Name Mapping for the user's corresponding UNIX credentials; the mapping service returns the matching UID and GID (Steps A1 and A2). The user then uses those credentials to access an NFS resource on a UNIX-based NFS server (Step A3). In a different scenario, a user at a UNIX NFS client system submits UNIX credentials to a Windows-based Server for NFS system (Step B1), which sends a query for the corresponding Windows credentials to a DC running User Name Mapping (Step B2). If User Name Mapping finds matching credentials, Server for NFS uses them to authenticate the user to the DC (Step B3) and to perform an authorization check so that the user can access NFS data.
To authorize machines that query the User Name Mapping service, the service maintains a text-based authorization file called .maphosts. This file, which resides in the %SFUDIR%\mapper directory, lists the host names of all the machines that are authorized to query User Name Mapping.
Password Synchronization
The Password Synchronization service, which is installed with Server for NIS, provides either one-way (i.e., Windows-to-UNIX or UNIX-to-Windows) or two-way (i.e., Windows-to-UNIX and UNIX-to-Windows) password synchronization, depending on how you configure the service. When a user's Windows password changes in AD, Password Synchronization automatically changes the AD user object's corresponding UNIX password property. The Password Synchronization service then replicates the password change throughout AD and to UNIX NIS servers. This automatic synchronization simplifies user management in a mixed environment, letting users use one password in both Windows and UNIX. As I mentioned earlier, you must install Server for NIS and Password Synchronization on all the DCs in your Windows domain. In a multimaster replication model such as the one that AD uses, the original password change can occur on any DC in the domain.
Password Synchronization provides synchronization between Windows 2003, XP, Win2K Server, Win2K Professional, NT Server 4.0, and NT Workstation 4.0 systems and IBM's AIX 4.3.3, HP-UX 11, Red Hat Linux 7.0, and Sun's Solaris 7 systems. (Because you can use SFU to manage passwords on Linux systems, SFU is a great solution for Windows shops that want to add Linux boxes to the environment.) You can configure synchronization to work in both directions on all platforms except AIX, which supports only Windows-to-UNIX synchronization.
Windows-to-UNIX synchronization. To provide secure password synchronization, the service uses the 3DES algorithm and a secret key that the UNIX and Windows platforms share to encrypt passwords. Figure 3 shows several possible Windows-to-UNIX password-synchronization scenarios.
When a Windows domain user initiates a password update, the Windows client relays the update to a DC running the Password Synchronization service. Password Synchronization then synchronizes the updated password with the UNIX NIS database. When the DC serves as the NIS master, the DC simply pushes the changes to the other DCs and UNIX NIS servers (Figure 3 doesn't show this scenario).
Suppose a UNIX server is the NIS master server. That server must run the single sign-on daemon (SSOD—aka the password synchronization daemon). In this scenario, Password Synchronization on the DC synchronizes the updated password with the NIS master server (Step A1). SSOD then updates the NIS mappings and initiates a push to all UNIX NIS slave servers (Step A2).
Suppose the credentials database resides on a standalone UNIX machine (i.e., a machine that doesn't participate in a UNIX NIS domain). Password Synchronization synchronizes the change with the UNIX machine, and the UNIX machine's local SSOD daemon makes the change in the machine's local credentials database (Step B1).
What about a Windows user working on a standalone Windows machine? In this scenario, the standalone system must run the Password Synchronization service. When the user initiates a password update to the local authority and credential database (the SAM), Password Synchronization synchronizes the password with the NIS database on a UNIX master server or standalone UNIX machine, as described in the previous paragraphs (Step C1 or Step C2, respectively).
UNIX-to-Windows synchronization. Figure 4, page 12, shows several possible UNIX-to-Windows password-synchronization scenarios. When a UNIX user initiates a password update, the pam_sso module running on the UNIX client initiates the synchronization process. When the NIS database resides on a Windows-based Server for NIS DC, the pam_sso module uses the NIS yppasswd command to synchronize the password directly with the DC, which then pushes the changes to the other DCs and UNIX-based NIS servers (Figure 4 doesn't show this scenario).
Suppose the NIS database resides on a UNIX NIS master server. In this case, Password Synchronization on the DC replicates the change to all other DCs in the AD domain and synchronizes the change with the NIS master (Step A1), which pushes the change to any NIS slave servers (Step A2). This scenario requires all DCs to run Password Synchronization configured for two-way synchronization with the NIS master server and one-way UNIX-to-Windows synchronization with all UNIX NIS clients.
When the UNIX client is a standalone machine, Password Synchronization on the DC simply replicates the change to all other DCs in the Windows domain. In this scenario, the DCs must run Password Synchronization configured for one-way UNIX-to-Windows synchronization with the standalone UNIX client.
When a standalone UNIX client wants to synchronize with a standalone Windows machine, the pam_sso module simply synchronizes the password change with the Windows machine, which must run Password Synchronization configured for one-way UNIX-to-Windows synchronization with the standalone UNIX client.
Powerful Security Integration
SFU provides powerful Windows and UNIX (or Linux) security integration. Although a UNIX IT staff that adopts Microsoft solutions will face a learning curve, these tools are probably the best option for integrating with the Windows OS; Windows environments that need to integrate UNIX and Linux security will appreciate the familiarity of Windows-based tools. You can find more information about SFU at http://www.microsoft.com/windows/sfu/default.asp.