8.4 Windows and UNIX account management and authentication integration approaches

The account management and authentication integration approaches for the Windows and UNIX platforms that are discussed in this chapter can be categorized as follows:

• Coexistence Solutions: In these solutions the NIS and AD/LDAP infrastructures coexist. Usually these solutions do not provide a single point of administration. Also they do not provide single sign-on (SSO), but they do provide integrated authentication. In this context “integrated authentication” means using the same authentication credentials and/or protocols in the UNIX and the Windows environment. A well-known set of solutions in this category is credential synchronization services. Such services simply synchronize the credentials between the UNIX and Windows security authentication authorities and their repositories.

• Centralized User Management: Solutions that are using this approach provide a single point of administration for both UNIX and Windows accounts and credentials. This approach is also referred to as single-source sign-on. In an AD-centric Windows environment, it is quite obvious to use AD as the central repository. Some solutions in this category provide a special front end to AD, so users can keep using their legacy communication protocol (e.g., NIS) and do not need to change to LDAP to communicate with AD.

• Single Sign-On (SSO): Whereas the two previous approaches still require users to enter a set of credentials each time they access another environment, true SSO only requires users to enter their credentials once: to the primary authentication authority (e.g., a Windows DC). Afterward, authentication to secondary authentication authorities (e.g., a UNIX resource server) happens transparently. There are quite a few different SSO architectures available. For a high-level outline of the different SSO architectures and examples of commercial software supporting them, see Chapter 9.

The solutions for integrated account management and authentication discussed in this chapter are listed in Table 8.3. Note that there is a strong focus on the integration solutions that MS offers as part of their Services for UNIX 3.0 (SFU 3.0) suite.

Table 8.3: Solution Overview

Coexistence Solutions (Mixed NIS and AD Infrastructure)	Centralized User Management using AD/LDAP Repository
Server for NIS (AD-integrated NIS) (SFU 3.0) User Mapping Service (SFU 3.0) Samba Password Synchronization Password Synchronization using SFU 3.0	PADL NIS/LDAP gateway pam_unix-centric pam_ldap-centric pam_kerberos-centric Vintela Authentication Services (VAS) Samba WinBind

8.4.1 Coexistence solutions between an NIS and an AD infrastructure

This section focuses on the coexistence solutions coming with the MS Services for UNIX 3.0 suite: Server for NIS, the User mapping service, and the Password Synchronization Service. In late 2002, Microsoft released version 3 of its Services for UNIX (SFU) software suite: a collection of software facilitating the integration of the Windows and the UNIX platform. We will also look at how Samba can be used to provide security coexistence between UNIX and Windows for SMB-based file and print sharing.

SFU server for NIS

Server for NIS is an SFU 3.0 service that allows Windows 2000 and Windows Server 2003 domain controllers (DCs) to act as NIS master servers. During the installation of Server for NIS, SFU extends the AD schema to enable AD to store the NIS-specific data. Figure 8.6 shows how the AD user and group properties are extended to provide a single point of administration for both Windows and UNIX authentication and authorization data. The overall architecture of this solution is illustrated in Figure 8.7.

Figure 8.6: AD user and group object properties with a UNIX-specific property tab.

Figure 8.7: SFU Server for NIS architecture.

Server for NIS allows Windows administrators to define the UNIX user and group attributes in AD. This can be done manually or the attributes can also be pulled over all at once from an existing UNIX NIS server. To do the latter, the Server for NIS installation installs a set of migration utilities. Migration can be done from the command line using the nis2ad executable or using the GUI-based Migration Wizard.

A Server for NIS-enabled Windows DC can receive NIS query requests from UNIX NIS clients, translate them into AD queries, and return the data to the NIS clients in an NIS format. It can also replicate the NIS data to both Windows and UNIX NIS servers (as illustrated in Figure 8.7). The Windows servers with which it replicates are also Windows DCs. In this case the NIS data are replicated using the AD replication model. The UNIX servers with which it replicates are NIS slave servers. In this case NIS data are replicated using the NIS yppush protocol.

Server for NIS also provides a one-directional password synchronization service: If a user’s Windows password is changed in AD, it will be automatically changed in the corresponding UNIX password property of the AD user object. Server for NIS will automatically replicate the password change to the other Windows NIS servers and the UNIX NIS slave servers.

This automatic password synchronization facilitates user management in a mixed environment. It is made possible thanks to a password synchronization service shipping with SFU. This service is automatically installed when Server for NIS is installed. If you want bidirectional password synchronization in order to also replicate the password changes that are originating in the UNIX environment, read the text concerning SFU password synchronization service later in this section.

This password synchronization feature mandates that in a Windows domain that is made up of multiple DCs, Server for NIS (together with the password synchronization service) is installed on all DCs. In a multimaster directory replication model like the one AD uses, a user’s original password change can occur on any of the DCs in the domain.

To enable UNIX users to authenticate against a UNIX host using the credentials stored in the AD-based NIS server, one of the following PAM modules should be installed on the UNIX host:

• The pam_unix module: This is the default UNIX PAM module, supporting crypt(3) hash-based authentication, password updates, and account management using a local or NIS-based repository.

• The Microsoft SFU pam_sso module: This is a special PAM module that MS provides as part of SFU 3.0. It can be used for crypt(3) hashbased authentication and also for password updates. The nice thing about pam_sso is that it uses 3DES to secure the exchanges between the UNIX host and the Windows AD server. Contrary to the pam_unix module, the pam_sso module cannot be used to let a UNIX host communicate with a non-AD-based NIS server.

Samba

Samba can be used to provide an integrated authentication solution between Windows and UNIX for the users of SMB-based file and print services. This capability (which is illustrated in Figure 8.8) is based on the following Samba features:

• Samba’s capability to let a UNIX machine become a member server of a Windows 2000 or later domain

• Samba’s support for Windows NTLM-based pass-through authentication

  
  Figure 8.8: Samba architecture.

This solution cannot provide integrated account management because on the UNIX side a UID and GID are needed for every user. UNIX needs UIDs and GIDs in order to maintain file ownership and permissions on UNIX file system resources. A UID and GID on their turn require a UNIX account for every user. In other words, even though the password is kept in AD and the Windows 2000 or later DC can take care of integrated authentication, there’s still a double bookkeeping problem: Every UNIX SMB user needs both a UNIX account (and UID and GID) and a Windows account.

Remember that Samba does not support the Kerberos authentication protocol. Samba can be configured to use the NTLM challenge/responsebased authentication protocol. NTLM is not the default authentication protocol in Samba versions 2.2 and earlier: By default, they use an insecure plaintext password-based authentication mechanism. In these versions

Samba will only use NTLM if the “encrypt passwords” directive is set to yes in the Samba configuration file. The encrypt passwords directive will be switched on by default in Samba 3.0.

On the UNIX client-side SMB resource access obviously requires an SMB client. One of the following SMB clients can be used:

• The smbclient program coming with the Samba software kit

• The smbfs filesystem: This feature is only available on the Linux platform.

• The smbsh program: This client is available on most UNIX clients with the exceptions of HP-UX and Linux.

SFU user name mapping service

The SFU 3.0 User Name Mapping Service enables other SFU applications to automatically retrieve the Windows credentials corresponding to a set of UNIX credentials (or the other way around) from a central location. The User Name Mapping Service provides this service to the following SFU applications: Microsoft Interix, the client for NFS, Gateway for NFS and Server for NFS, and the Remote Shell Service. The service can be installed on a Windows NT 4.0, Windows XP, Windows 2000, or Windows Server 2003 platform. Because it does not use Active Directory as the repository to store its mapping data, it can be installed on any Windows server.

The Name Mapping Service cannot be categorized as a true SSO solution because of its limited scope. It only works for NFS-based file access and the Remote Shell service. In that sense you can look at it as an NFS- equivalent for Samba.

The User Name Mapping Service supports two types of user name mappings:

• Simple mappings (or “maps,” as Microsoft calls them) can be used to define one-to-one mappings for users or groups that have the same name in both the UNIX and the Windows environment.

• Advanced maps can be used to define many-to-one mappings and also for one-to-one mappings when users or groups have different names in the UNIX and the Windows environment.

The User Name Mapping Service can get its UNIX information from different sources: a UNIX or Windows NIS server, or a UNIX or Windows client that has the PCNFS daemon installed (as illustrated in Figure 8.9). PCNFS is a fairly simple service that allows users to obtain UNIX authorization information (UIDs and GIDs) given their username and password. Users simply have to send their username and password to the PCNFS service, the latter compares the password to the one stored in its local password file, and if the two match, the PCNFS service returns the UNIX authorization information to the user.

In order to authorize machines to query the User Name Mapping Service, the User Name Mapping Service maintains a text-based authorization file called .maphosts. The file lists all hostnames of the machines that are authorized to query the User Name Mapping Service. The file is stored in the %SFUDIR%/mapper directory.

The operation of the User Name Mapping Service in combination with an NFS resource access is illustrated in Figure 8.9. The figure shows two different scenarios:

Figure 8.9: SFU Name User Mapping Service architecture.

• Access from a Windows host to a UNIX-based NFS Server (steps A and B). In this case we have the client for NFS software installed on the Windows host. When a user tries to access an NFS resource, the NFS client will query the User Name Mapping Service using the user’s Windows credentials for the corresponding UNIX credentials. The mapping service will return the matching UID, password, and GID. These can then be used by the NFS client to access the resources on the NFS server.

• Access from a UNIX host to a Windows-based Server for NFS (steps 1, 2, and 3). In this case a UNIX NFS client tries to access an NFS resource on a Windows-based Server for NFS. The UNIX host offers his or her UNIX credentials to the Windows server. The Windows Server queries the User Name Mapping Service for the Windows credentials corresponding to the UNIX credentials. If matching credentials are found, the mapping service returns them to the NFS server. The NFS server can then use them to authenticate the user to a Windows DC. Finally, the NFS server performs an authorization check for the user.

Solutions providing password synchronization

Another alternative for providing security coexistence between a Windows and a UNIX environment is to keep the passwords synchronized between the two worlds. Because both Windows and UNIX use specific hashing algorithms to securely store user passwords, true password synchronization between the two credential databases is impossible. Password synchronization can only occur when the password is set or reset, before the hashing algorithm is applied. Hashing algorithms have the unique property that they are one-way functions.

SFU password synchronization

The Password Synchronization Service SFU version 3 allows for password synchronization between the Windows NT4 Server and Workstation, Windows 2000 Professional and Server, Windows XP, and Windows Server 2003 platforms on the Windows side, and the HP-UX 11, AIX 4.3.3, Redhat Linux 7.0, and Solaris 7 platforms on the UNIX side. For all the above-mentioned UNIX platforms—with the exception of AIX—password synchronization works in both directions: from Windows-to-UNIX and from UNIX-to-Windows. AIX password synchronization only works from Windows-to-UNIX.

SFU’s password synchronization provides secure password synchronization. The passwords are encrypted using the 3DES algorithm and a secret key that is shared between the UNIX and Windows platforms.

Figure 8.10 shows how password synchronization works from Win- dows-to-UNIX. The figure shows two scenarios: Windows-to-UNIX password synchronization in a Windows domain environment and Windowsto-UNIX password synchronization from a Windows stand-alone machine.

Figure 8.10: SFU password synchronization architecture: Windows to UNIX.

• A Windows domain user initiates a password update to its Windows domain controller (DC).

  • If password synchronization is set up between the AD and a UNIX NIS domain, the SFU password synchronization service will synchronize the password with the UNIX NIS database. This setup always requires the SFU password synchronization service to be installed on all Windows DCs (remember that a password update can occur on any server in a multimaster model).

    If the NIS master server is running on a UNIX platform, the Single Sign-On daemon (ssod) must be installed on the NIS master server (this daemon is also referred to as the password synchronization daemon). The ssod daemon will update the NIS maps and initiate a push to the other UNIX NIS slave servers.

    If the NIS master server is a Windows AD machine running the SFU Server for NIS extensions (this scenario is not shown in 8.4 Windows and UNIX account management and authentication integration approaches Figure 8.5), then the AD NIS master server will make sure that the changes are pushed to the other AD machines and the UNIX NIS slave servers.

  • If password synchronization is set up between the AD and a UNIX stand-alone machine (a machine that is not participating in a UNIX NIS domain), the SFU password synchronization service will synchronize the change with the UNIX machine. The UNIX machine’s local ssod daemon will make sure the change is made to the machine’s local credential database.

• A Windows user (working from a Windows stand-alone machine) initiates a password update to its local authority. This scenario requires the SFU password synchronization service to be installed on the Windows stand-alone machine. On the UNIX side the password synchronization operation and requirements are the same as the ones mentioned in the Windows domain scenario (for both a UNIX NIS and stand-alone setup).

Figure 8.11 shows how password synchronization works from UNIX- to-Windows. Again this picture shows two different scenarios: UNIX-to- Windows password synchronization from a NIS domain and UNIX- to-Windows password synchronization from a UNIX stand-alone machine.

Figure 8.11: SFU password synchronization architecture: UNIX to Windows.

In this case everything begins when a UNIX user initiates a password update. In this scenario, the basic setup on the UNIX side is always identical (independently of whether you are dealing with a stand-alone UNIX machine or a machine participating in an NIS domain).

• If password synchronization has to work between a UNIX NIS domain and a Windows AD domain environment, the UNIX SSO PAM module (pam_sso) installed on the UNIX client machine will initiate the password synchronization with a Windows DC. Only when this is done will the Windows SFU password synchronization service synchronize the password change with the UNIX NIS database. At the same time the Windows DC will then replicate the change to all other DCs in the Windows domain using the AD repli- cation model. This setup requires the SFU password synchronization service to be installed on all Windows DCs. Also, SFU password synchronization has to be configured for two-way synchronization with the NIS master server and one-way synchronization (UNIX-to- Windows) with the UNIX NIS clients.

  In this scenario, if the NIS master server is a Windows machine that has the SFU Server for NIS extensions installed (not shown in Figure 8.6), UNIX NIS clients can directly update their password to the Windows NIS master server (using the NIS yppasswd command and having the pam_sso module installed).

• If password synchronization has to work between a UNIX stand- alone machine and a Windows AD domain environment, the UNIX SSO PAM module (pam_sso) installed on the UNIX client machine will synchronize the password change with a Windows DC. The Windows DC will then replicate the change to all other DCs in the Windows domain using the AD replication model. In this scenario the Windows DC must have the SFU password synchronization service installed: It has to be configured for one-way synchronization (UNIX-to-Windows) with every stand-alone UNIX client.

If password synchronization has to work between a UNIX stand- alone machine and a stand-alone Windows machine, the UNIX SSO PAM module (pam_sso) installed on the UNIX client machine will simply synchronize the password change with the Windows stand- alone machine. In this scenario the Windows stand-alone machine must have the SFU password synchronization service installed: It has to be configured for one-way synchronization (UNIX-to-Windows) with the stand-alone UNIX client.

Other password synchronization solutions

Many IT software vendors provide password synchronization solutions for mixed Windows/UNIX environments. Table 8.4 provides a nonexhaustive list of some commercial solutions. A detailed discussion of these solutions is beyond the scope of this book.

Table 8.4: Password Synchronization Solutions

Vendor/Product	URL
Passgo InSync	http://www.passgo.com
Proginet SecurPass-Sync	http://www.proginet.com
M-Tech P-Synch	http://www.psynch.com

A very interesting open source solution for password synchronization between Windows and UNIX is the solution proposed in the OpenLDAP-based “LDAP Account Synchronization Project.” This solution is based on a password filtering DLL that intercepts password changes on the Windows DC and then synchronizes them with the OpenLDAP server. More information is available from http://acctsync.sourceforge.net.

8.4.2 Solutions providing centralized user management using an AD/LDAP repository

The following sections discuss solutions providing centralized user management for Windows 2000 (and later) and UNIX platforms using a central AD/LDAP repository. It is rather obvious that for this to work we will need to install extra software on the UNIX side.

Next we begin with a solution that is centered around an NIS-to-LDAP gateway. Then we explore several PAM-centric solutions: a solution using pam_unix, a solution using pam_ldap, and another solution using the Kerberos authentication protocol. Finally, we discuss a Samba-based solution that unfortunately only works for file and print sharing in a Linux environment.

NIS/LDAP gateway

NIS to LDAP gateway functionality is provided by ypldapd—a product from PADL software (http://www.padl.com). Ypldapd basically provides an NIS server interface. Contrary to a normal NIS server, however, the NIS server behind the ypldapd interface stores its data in an LDAP directory (and not in NIS maps). The intent of ypldapd is to allow an organization to leverage the scalability and distributed nature of LDAP directory services, while maintaining an existing NIS infrastructure. The ypldapd architecture is illustrated in Figure 8.12.

Figure 8.12: NIS/LDAP gateway architecture.

The ypldapd allows an organization to replace an NIS server with ypldapd without having to reconfigure any NIS client. The ypldapd acts as a broker between UNIX NIS clients and the LDAP server. Classical NIS utilities such as ypcat, ypmatch, and login will work unmodified. The only exception is the NIS password-changing utility (yppasswd): Because passwords are stored in LDAP, the classic NIS password-change utility will not work. To deal with this problem, ypldapd provides a special password- changing utility called ldappasswd.

When ypldapd starts, it binds to the LDAP server specified in its configuration file. This binding action is similar to logging into an operating system or application. An identifier is sent to the LDAP server along with an associated password. If the password matches, a connection to the LDAP server is established. This connection is maintained as long as ypldapd and the LDAP server are running.

Before ypldapd can access the data in the LDAP repository, special objects that can hold NIS data must be defined on the LDAP server. In Active Directory these special containers are created when the Services for UNIX (SFU) Server for NIS schema extensions are installed.

The binary distribution of ypldapd is available for Solaris 2.6, 7, and 8, Linux, and AIX 4.3.3 (on PowerPC). Source licensees may build ypldapd for other platforms, except for HP-UX. The ypldapd for HP-UX is available directly from HP.

Nss_ldap

Contrary to what was discussed earlier, in all the following solutions UNIX clients can access the AD/LDAP repository directly. In these solutions there is no more need for NIS servers or NIS-to-LDAP gateways translating NIS requests to LDAP queries. The basic enabler behind these solutions is the nss_ldap module, which allows UNIX clients and applications to communicate directly with an LDAP repository. The nss_ldap is a freeware module from PADL software (http://www.padl.com).

The nss_ldap module has a rich set of configuration options:

• It allows UNIX users to specify LDAP search filters to determine where in the directory tree to start the search and how deep to search.

• It allows for the definition of attribute mappings. The latter can be useful when searching LDAP repositories that do not store name service data in the format specified by RFC 2307 (a good example is SFU’s Server for NIS).

Two of the four solutions outlined next not only rely on nss_ldap to retrieve user profile information (home directory, login shell, and so forth) but also to help with the user authentication process.

Pam_unix-centric approach

The pam_unix module supports the typical UNIX authentication protocol that is based on the crypt(3) hash function. Pam_unix has the capability to calculate a crypt(3) hash given a user password, to compare this hash to another hash stored in some repository, and—based on the outcome of the comparison—to decide whether the user’s identity is authentic or not. The pam_unix module also provides password management and is supported on all UNIX flavors discussed in this chapter: Linux, HP-UX, Solaris, and AIX.

When UNIX clients rely on the pam_unix module, user authentication occurs as follows:

• Pam_unix first retrieves the user’s password hash from the LDAP repository. To connect to the LDAP repository, pam_unix calls on nss_ldap.

• The hash nss_ldap retrieved is then validated on the UNIX host by pam_unix. This means that pam_unix will compare it to the local password hash. The latter is the outcome of the application of a hash function on the password that was entered by the user.

• If the validation process by the pam_unix module is okay, the user is given access to the UNIX client.

• After the initial authentication, the UNIX login program usually calls on nss_ldap for a second time—this time to retrieve additional user profile information from the LDAP repository.

In this scenario the LDAP repository is not the true authentication authority—this is the local pam_unix module’s role. The LDAP repository provides only authentication data to the pam_unix module (via the nss_ldap module).

Security specialists can argue against this solution because it always uses the same account to access the LDAP repository. Access to the LDAP data does not occur using the identity of the user that must be authenticated, but using the identity of proxy account defined on the UNIX host. Some setups even dare to use anonymous access.

In order to support this in an AD environment (as illustrated in Figure 8.13), AD must have the SFU NIS extensions installed. Because the UNIX user password must be stored in the UNIX crypt(3) hash format.

Figure 8.13: The pam_unix-centric architecture.

In order to secure the LDAP network traffic between the UNIX client and AD, it is advisable to use LDAP over SSL or TLS (LDAPs). SSL/TLS support is available out of the box on the AD side. To support it on the UNIX side, you can use the stunnel software (http://www.stunnel.org).

Pam_LDAP-centric approach

The pam_LDAP module supports one or more LDAP-based authentication mechanisms: simple authentication (also known as plaintext authentication or a simple LDAP bind), CRAM-MD5-based authentication, or digest authentication (the last two are used in conjunction with the SASL negotiation protocol).

Pam_LDAP also provides password management. It does not provide account and session management services. That is why once a user is authenticated using pam_ldap, applications will need to call on another PAM module to retrieve user profile information. Just like pam_unix, pam_ldap calls on nss_ldap to retrieve user profile information from the LDAP repository.

A pam_LDAP module for HP-UX 11, Linux, and Solaris 2.6 and above is available from PADL software (http://www.padl.com). AIX can support it but requires reconfiguration (more information on this topic can be found in the IBM Redbook “AIX and Linux Interoperability”).

The pam_LDAP solution has several security advantages over the pam_unix solution:

• Contrary to the pam_unix-centrix approach, the LDAP repository acts as a true authentication authority. In this solution the LDAP server will decide whether the user authentication is successful or not and then return the result to the UNIX host.

• Access to the LDAP repository does not occur in the security context of a proxy account. In this case pam_LDAP authenticates to the LDAP server using the user credentials.

• All authentication attempts can be subjected to a central security policy that is stored in the LDAP repository.

Pam_LDAP can only work in conjunction with AD (as illustrated in Figure 8.14) when the AD4Unix AD schema extensions have been applied to AD. AD4Unix provides RFC2307-compliant AD schema extensions. The AD4Unix extensions can be downloaded from http://www.css-solutions.ca/ad4unix. To secure the LDAP traffic between the UNIX client and the LDAP server, it is once more advisable to use LDAP over SSL or TLS.

Pam_Kerberos-centric approach

Pam_Kerberos lets a UNIX host authenticate to a Kerberos Key Distribution Center (KDC). Most pam_kerberos modules also provide account, password, and session management capabilities. Most UNIX Kerberos PAM modules are known as pam_krb5, where krb5 refers to version 5 of the Kerberos authentication protocol.

Figure 8.14: Pam_LDAP-centric architecture.

The nice thing about using the Kerberos authentication protocol for a UNIX and Windows integration project is that it can also be used as an SSO solution for Windows and UNIX applications that understand the protocol. These applications are also referred to as Kerberized applications. Unfortunately, in the UNIX world, there are very few Kerberized applications.

In an AD-centric environment two Kerberos-based Windows-UNIX interoperability approaches are possible:

• Using only Windows KDCs (as illustrated in Figure 8.15). In this scenario UNIX Kerberos users and services will receive Kerberos tickets that are issued by a Windows KDC. Even though Windows embeds profile data in the Kerberos tickets (authorization data), these cannot be used by the UNIX principals. UNIX principals can, however, fall back to nss_ldap to retrieve their profile data from the LDAP repository.

  
  Figure 8.15: Kerberos-centric architecture: Windows KDCs.

• Using both Windows and UNIX KDCs and by setting up cross- realm trust relationships between the UNIX and Windows KDCs (as illustrated in Figure 8.16). In this scenario UNIX Kerberos users and services will receive Kerberos tickets that are issued by a UNIX KDC.

  
  Figure 8.16: Kerberos-centric architecture: UNIX and Windows KDCs.

As in the previous scenario, in this setup the UNIX hosts require nss_ldap in order to retrieve profile data from the LDAP repository.

For more information on Windows Kerberos interoperability, refer to Chapter 5 or the Microsoft Windows Kerberos Interoperability white paper available from http://www.microsoft.com/windows2000/docs/ Kerbinterop.doc.

Vintela Authentication Services (VAS)

Vintela Authentication Services (VAS) is a commercial software offering from Vintela that provides centralized AD-based account management for Windows and certain UNIX clients. The most important feature of this solution is that it integrates UNIX machines into a Windows domain environment. By doing so, it can take advantage of the UNIX machine’s Kerberos session key to secure users’ authentication exchanges. That is also why—as opposed to the previous solutions—there is no more need to set up an SSL-secured connection between the UNIX client and the AD server. This also eliminates the need for dummy user accounts (or proxyaccounts—see Chapter 5) and allows AD UNIX machine account attributes to be protected by the default AD authorization mechanisms. Just like all previous solutions, VAS enables users to use the same credentials on Windows and UNIX without needing special credentail sychronization software. VAS version 2.2 supports the following UNIX platforms: RedHat Linux 7.2 – 9.0, Suse Linux 8.x, Solaris 8,9, HP-UX 11.0, 11i, 11.11,11.22, AIX 4.3 – 5.2

Besides LDAP and Kerberos, VAS also builds on the following open standards—SASL, GSSAPI and SPNEGO:

• The Simple Authentication and Security Layer (SASL) protocol provides a method for adding authentication support to connection-based protocols. SASL includes a negotiation phase before the actual authentication takes place. More information on SASL can be found at http://asg.web.cmu.edu/sasl.

• The Generic Security Services API (GSSAPI) is an API for authentication in a distributed client-server environment. It is basically an abstraction layer that enables applications to call on different authentication methods and protocols. GSSAPI can be compared to the Windows SSPI (explained in Chapter 4). Most UNIX Kerberos implementations have a Kerberos authentication GSSAPI plug-in. More information on GSSAPI can be found at http://www.faqs.org/faqs/kerberos-faq/general/section-84.html .

• The Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) is closely linked to the GSSAPI. It allows applications to negotiate which authentication mechanism to use. SPNEGO is documented in RFC 2478 (available from http://www.ietf.org).

VAS includes several components for both the Windows and the UNIX side (as illustrated in Figure 8.17). On the Windows side it comes with a set of AD schema extensions (that are RFC 2307-compliant) and an extension for the AD Users and Computers MMC snap-in. On the UNIX side it comes with a special PAM (pam_vas) and NSS (nss_vas) module, and a special daemon called the vascd daemon. More information on VAS can be found at http://www.vintela.com/products/vas.

Figure 8.17: Vintela Authentication Services (VAS)

Other key VAS security features are the following:

• Automatic keytab maintenance. By joining UNIX workstations and servers to the domain, VAS eliminates the traditional Microsoft UNIX Kerberos interoperability steps of exporting and importing the keytab files. VAS automatically handles the creation of keytab files for both UNIX computer and UNIX service accounts.

• Full support for Microsoft Password Policies. VAS fully supports Microsoft password policies for password age, complexity, history and length.VAS users with expired passwords are prompted to change their password when logging on to UNIX workstations.

• Per workstation login access control based on users.allow/users.deny files. VAS introduces the concept of users.allow/users.deny files which can be configured to allow or deny login access based on Active Directory user name, group, or domain.

• Intelligent caching for better scalability. VAS uses patent pending caching technology that limits the amount and complexity of NSS/ PAM driven LDAP traffic and LDAP server load while allowing the immediate realization of AD stored identity changes.

• Disconnected Operation. VAS can be configured to continue to allow Active Directory user authentication when the Active Directory server is unavaliable—such as in dial-up environments or on laptop computers.

• Script friendly command line utilities. VAS delivers script friendly command line utilities that can be used to build extremely rich authentication and identity management solutions based on popular Unix scripting languages (Perl, PHP, Python, shell, etc).

• Simplified time synchronization. VAS includes time synchronization functionality that allows UNIX hosts to synchronize time with Windows domain controllers.

Samba Winbind

Winbind can provide both a unified logon and account management experience between UNIX and Windows systems for SMB-based file and print access. Remember that the Samba solution discussed previously only provided a unified logon experience. The great thing about Winbind is that it takes away the need to define UNIX accounts (and UIDs and GIDs) in the Samba smbpasswd database (remember the double bookkeeping problem). The Winbind architecture is illustrated in Figure 8.18.

Figure 8.18: Samba Winbind architecture.

Unfortunately, so far the Samba Winbind daemon is only available for the Linux operating system. A stable version of Winbind is available from Samba release 2.2.2 onward (the latest Samba release is 2.2.8).

Samba’s Winbind daemon is built on a UNIX implementation of Microsoft Remote Procedure Calls (RPCs), a special Pluggable Authentication Module (PAM) called pam_winbind, and the Name Service Switch (NSS).

• Winbind uses RPCs to enumerate Windows domain users and groups, to obtain Windows domain user and group details from a Windows domain controller, to authenticate users against an NT domain (using pass-through authentication), and to change passwords.

• Pam_winbind allows NT users to log in to the Samba Linux box and be authenticated by a Windows DC.

• The NSS module allows the Linux host and its services to resolve host-, group-, and user-names by calling on an LDAP repository (in this case AD).

The net result of all this together is that Windows domain users and groups will appear and work as UNIX users and groups on the UNIX box, and, most important, there is no more need for double bookkeeping.

A more detailed overview of the technologies behind Winbind can be found in Tim Potter and Andrew Tridgell’s paper “Unified Logons between Windows NT and UNIX Using Winbind,” available from http://us6.samba.org/samba/ftp/appliance/winbind.pdf. More information on how to set up Winbind and its different components can be found in the Samba documentation at http://de.samba.org/samba/ftp/docs/htmldocs/Samba-HOWTO-Collection.html#WINBIND .