Many organizations' IT infrastructures are a mix of Windows, UNIX, and mainframe computers. Platform and application integration inevitably includes integrating core UNIX and Windows security services such as account management (i.e., the management of security principals' identities and attributes—and possibly user privileges) and authentication (i.e., the verification of security principals' identities). Late last year, Microsoft released Windows Services for UNIX (SFU) 3.0, a software suite that facilitates the integration of Windows and UNIX. SFU offers three features that help integrate Windows and UNIX security: Server for Network Information Service (NIS), User Name Mapping, and Password Synchronization.
Server for NIS
Server for NIS is an SFU service that lets Windows Server 2003 and Windows 2000 Server domain controllers (DCs) act as NIS master servers. NIS, which Sun Microsystems released in 1985, was one of the first UNIX-based distributed naming services and is still in use today despite its data-model, replication, and security deficiencies. (The NIS data model can't be extended easily and NIS can't use incremental replication, but NIS's biggest deficiency is its complete lack of security. NIS doesn't authenticate users and transmits data in the clear, and NIS updates can be spoofed.)
You typically install Server for NIS on all the DCs in your Windows domain. As part of the installation process, SFU extends the Active Directory (AD) schema to store NIS-specific user and group data and to provide a single point of administration for Windows and UNIX authentication and authorization. You can define the UNIX data in AD manually, or you can use SFU's nis2ad.exe command-line utility or GUI-based Migration Wizard to pull over all the data from an existing UNIX NIS server.
A Server for NIS DC can receive NIS query requests from UNIX NIS clients, translate those requests into AD queries, and return the data in NIS format to the NIS clients. The Server for NIS DC also uses the AD replication model to replicate updated data to other Windows DCs and uses the NIS yppush protocol to replicate updated data to UNIX NIS servers, as Figure 1 shows.
SFU supports two client-side Pluggable Authentication Module (PAM) options, the pam_unix module and the pam_sso module, so that UNIX clients can use AD-stored credentials to authenticate against both Windows and UNIX systems. PAM technology lets UNIX applications take advantage of different authentication methods. The pam_unix module is UNIX's default PAM module and supports a local or NIS-based repository for crypt(3) hash-based authentication, password updates, and account management. The pam_sso module, which is a special Microsoft PAM module that provides SFU-based password synchronization between Windows and UNIX systems, supports crypt(3) hash-based authentication and password updates. The pam_sso module uses Triple Data Encryption Standard (3DES) to secure exchanges between the module's host (i.e., the UNIX client) and the Server for NIS DC but, unlike the pam_unix module, can't let the host authenticate against a UNIX NIS server.
User Name Mapping
The User Name Mapping service provides centralized user management for both UNIX and Windows environments, basically letting UNIX and Windows applications retrieve correct credentials automatically from a central location. User Name Mapping provides Windows-to-UNIX and UNIX-to-Windows credential mapping to the following SFU UNIX applications: Microsoft Interix, Client for NFS, Gateway for NFS, Server for NFS, and the Remote Shell Service.
User Name Mapping supports simple and advanced username mappings—or maps, as Microsoft calls them. You use simple maps to define one-to-one (1:1) mappings for users or groups that have the same name in UNIX and Windows; you use advanced maps to define 1:1 mappings for users or groups that have different names in UNIX and Windows or to define many-to-one mappings. (A many-to-one mapping can be useful when many UNIX accounts need the same level of access to a Windows-based resource. You can map all the accounts to one Windows account and use that account to set access controls for the resource.)
User Name Mapping doesn't use AD as a repository for mapping data, so you can install it on any Windows 2003, Windows XP, Win2K, or Windows NT 4.0 system, regardless of whether that system has access to AD. The service can access UNIX user and group information from any Server for NIS DC, any Windows client running Personal Computer NFS (PCNFS), any UNIX NIS server, or any UNIX client running the PCNFS daemon (PCNFSD). PCNFS is a simple service that lets a user submit his or her username and password, compares the password with the password in the service's local password file, and—if the passwords match—returns the requested UNIX authorization information (i.e., user identifiers—UIDs—and group identifiers—GIDs).
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.
