Services for Unix has made large strides in its development. From initial skepticism, the product has developed into a formidable integration and migration utility that allows for a great deal of inter-environment flexibility. The first versions of the software, 1.x and 2.x, were limited in many ways, however. Subsequent updates to the software vastly improved its capabilities and further integrated it with the core operating system.

A watershed development in the development of Services for Unix was the introduction of the 3.0 version of the software. This version enhanced support for Unix through the addition or enhancement of nearly all components. Included with version 3.0 was the Interix product as well, an extension to the POSIX infrastructure of Windows to support Unix scripting and applications natively on a Windows Server.

Then, version 3.5 of SFU WCS released, which included several functionality improvements over SFU 3.0. The following components and improvements have been made in the 3.5 release:

Finally, we come to the Server 2003 R2–integrated version of SFU. Besides being slip-streamed directly into the operating system, some functional changes have been made. Most importantly, the structure of SFU has changed considerably. Here is the structure of major improvements for the R2 SFU offering:

Services for Unix is composed of several key components, each of which provides a specific integration task with different Unix environments. Any or all of these components can be used as part of Services for Unix as the installation of the suite can be customized, depending on an organization’s needs. The major components of SFU are as follows:

Each component can be installed separately or multiple components can be installed on a single server as necessary. All components are available from the Add/Remove Window Components Wizard in the Control Panel. Each component is described in more detail in the following sections.

Services for Unix R2 interoperates with various flavors of Unix, but was tested and specifically written for use with the following Unix iterations:

Services for Unix has some other important prerequisites and limitations that must be taken into account before considering it for use in an environment. These factors include the following:

The installation of Services for Unix for Windows Server 2003 R2 is as simple as adding another Windows component. From the Control Panel, go to Add/Remove programs, and then Add/Remove Windows Components. The various parts that make up SFU are all available in their appropriate areas.

The installation of Services for Unix is straightforward and uses the familiar Microsoft Add/Remove Windows Components Installation Wizard. After the prerequisites have been satisfied and the desired functionality has been identified.

To install SFU R2, perform the following steps:

Figure 8.1. Download the Utilities and SDK for Unix-based Applications.

Figure 8.2. Reviewing the Utilities and SDK for Unix-based Applications options.

Figure 8.3. Active Directory Services details.

Figure 8.4. Microsoft Services for NFS options.

Once installed, the various functionalities can be tested in a lab environment or deployed into production.

Administrators familiar with Unix environments will feel at home working with Interix as both the Korn and C shells are available, and both behave exactly as they would in Unix.

SFU also supports the single-rooted file system through these shells, which negates the need to convert scripts to support drive letters. The single-rooted file system allows for a great deal of functionality, allowing scripts written for Unix to more natively port over to a Windows environment.

SUA supports all common Unix tools and utilities, with all the familiar commands such as grep, man, env, pr, nice, ps, kill, and many others. Each tool was built to respond exactly the way it is expected to behave in Unix, as illustrated in Figure 8.5, and Interix users can build or import their own customizable tools using the same procedures that they would in a Unix environment.

Figure 8.5. Using standard Unix commands with the C shell.

Server for NFS acts as a Unix-standard NFS server. It provides disk space from any Windows-based computer on a network to NFS clients, translating their NFS requests to Windows SMB-based requests. No additional client software is necessary, and the Windows Server 2003 server acts and functions like a normal NFS-based Unix server for these clients. This is a great way to bring a standardized share format to a heterogeneous network as Unix and Apple have difficulties using CIFS.

The NFS Client component can be installed directly on Windows workstations to allow them to map to NFS exports on a network. The NFS servers can be viewed in the standard Windows Explorer, and no additional software is required on NFS servers. Windows authentication requests are sent to the NFS servers using the UID or GID of a user who is mapped using the User Name Mapping service in SFU. In addition, Unix NFS commands such as net and mount can be used directly from the client.

User Name Mapping allows specific user accounts in Windows Server 2003 Active Directory to be associated with corresponding Unix user accounts. In addition to mapping identically named user accounts, User Name Mapping allows for the association of user accounts with different names in each organization. This factor is particularly useful considering that Unix user accounts are case sensitive and Windows accounts are not.

User Name Mapping supports the capability to map multiple Windows user accounts to a single user account in Unix. This capability allows, for example, multiple administrators to map Windows Server 2003 Active Directory accounts with the Unix root administrator account.

Going hand in hand with the User Name Mapping service, Password Synchronization allows for those user accounts that have been mapped to automatically update their passwords between the two environments. This functionality, accessible from the IDMU MMC Console, as illustrated in Figure 8.6, allows users on either side to change their passwords and have the changes reflected on the mapped user accounts in the opposite platform.

Figure 8.6. Adding a Unix server to synchronize with and from.

As previously mentioned, Password Synchronization must be installed on all domain controllers on the Active Directory side because all the DCs must be able to understand the Unix password requests forwarded to them. In addition, Password Synchronization is only supported out of the box in the following Unix platforms:

All other flavors of Unix require a recompile of the platform, which is made easier by the inclusion of makefiles and SFU source code. SFU R2 also includes the encryption libraries, making it even easier to compile a customized solution.

For users who want their existing NIS servers to continue to provide authentication for Unix and Linux servers, the NIS Migration Wizard is not the best choice. A package of Korn shell scripts downloadable from Microsoft.com makes this process simple. The getusers.ksh script gets a list of all users in a NIS database, including the comment field. This script must be run with an account with the permission to run ypcat passwd. The makeusers.ksh script, which must be run by a user with domain admin privileges, imports these users to Active Directory. The -e flag enables accounts because by default the accounts are created in a disabled state. This is a perfect solution for migrations that require the existing NIS servers to remain intact indefinitely.

Services for Unix uses two distinct and separate Telnet servers. The first, a Windows-based Telnet server, is essentially the same Telnet server that is included in Windows Server 2003 and Windows XP. The second Telnet server is controlled by the SFU inetd component, uses the SUA shell, and must be utilized separately from the Windows Telnet server. Each version of Telnet server supports NT LAN Manager (NTLM) authentication in addition to basic login that supports Unix users.

In Services for Unix, you can write scripts using the ActivePerl tool, which was fully ported from Unix Perl. Perl scripts can be used in a Windows environment, and ActivePerl directly supports use of the Windows Scripting Host (WSH), which enables Perl scripts to be executed on WSH server systems.

Integration of a Windows environment with Novell network operating systems is simplified through the use of Gateway Services for NetWare, a robust integration product that allows Windows Server 2003 to integrate and share resources with Novell NetWare. GSNW provides for the following functional elements:

Specific scenarios for GSNW include the following:

Services for NetWare (SFNW) 5.02 Service Pack 2 (SP2) provides companies with the tools to integrate or migrate Novell users and resources to Windows environments. SFNW provides the following tools:

The installation of SFNW is not without its caveats. First and foremost, MSDSS needs to be installed on a domain controller and the forest schema of Active Directory needs to be extended. Because forest schema changes are not to be taken lightly, this factor alone warrants consideration before the installation procedure. After the schema has been upgraded, the base program can be installed and the latest service pack applied. To install SFNW, perform the following steps:

Figure 8.7. Choosing to extend the AD schema for MSDSS.

Figure 8.8. Choosing to install MSDSS.

Figure 8.9. Reviewing installation options for SFNW.

Services for NetWare is now installed and ready for configuration. The applications will be listed under the Administrative Tools menu, as illustrated in Figure 8.10.

Figure 8.10. Finding the Services for NetWare Admin tools.

File and Print Services for NetWare is a back-end service that allows a Windows server to emulate a NetWare File and Print Server. NetWare clients can connect to the file and printer shares as if they were connecting to a Novell server. Novell clients use the same user interface to access file and printer resources running on an FPNW server. Essentially, FPNW allows an FPNW server to spoof an existing NetWare server after it has been retired, allowing administrators the time to gradually migrate desktops over to the Windows environment.

Specific scenarios for FPNW include the following:

Microsoft Directory Synchronization Services (MSDSS) is a tool used for synchronization of directory information stored in the Active Directory and Novell Directory Services (NDS). MSDSS synchronizes directory information stored in Active Directory with all versions of NetWare; MSDSS supports a two-way synchronization with NDS and a one-way synchronization with Novell 3.x bindery services.

Because Active Directory does not support a container comparable to an NDS root organization and because Active Directory security differs from Novell, MSDSS, in migration mode only, creates a corresponding domain local security group in Active Directory for each NDS organizational unit (OU) and organization. MSDSS then maps each Novell OU or organization to the corresponding Active Directory domain local security group.

MSDSS provides a single point of administration. With a one-way synchronization, changes made to Active Directory will be propagated over to NDS during synchronization. Synchronization from Active Directory to NDS allows changes to object attributes, such as a user’s middle name or address, to be propagated. In two-way synchronization mode, changes from NDS to Active Directory require a full synchronization of the object (all attributes of the user object).

One of the key benefits to MSDSS is password synchronization. Passwords can be administered in Active Directory and the changes propagated over to NDS during synchronization. Password synchronization allows users access to Windows Server 2003 and NDS resources with the same logon credentials.

The MSDSS architecture is made up of the following three components. These components manage, map, read, and write changes that occur in Active Directory, NDS, and NetWare bindery services.

In addition to the core components of MSDSS, the session configuration settings (session database) are securely stored in Active Directory.

Specific scenarios for MSDSS would include the following:

The File Migration Utility is used to automatically manage the migration of files from NetWare file and print servers to Windows Server 2003 systems.

Integrated with MSDSS, FMU copies files while preserving the permissions and access control lists (ACLs) associated with each file. FMU copies the file permissions using a user-mapping file that matches an NDS user account with an Active Directory account. Through this mapping file created with MSDSS, files and the rights inherited or assigned in NetWare are calculated and maintained in the Windows network, preserving security and minimizing the time-consuming process of reassigning file rights and permissions. Without the mapping file, FMU will assign file permissions on all migrated files to the administrator.

MIIS is Microsoft’s metadirectory solution. A metadirectory can be considered a master directory that contains the most authoritative directory services data within an organization. In 1996, when the Burton Group (http://www.tbg.com) coined and defined the term, no products existed on the market. Since then, many companies have created their own version of a metadirectory, but each might have its own complicated setup and functionality.

The original version of Microsoft’s metadirectory solution was known as Microsoft Metadirectory Services (MMS). This version of the application was effective, but was extremely technical. Many components required customized scripting to function properly, and support for third-party products was minimal.

With the 3.0 release of the product came a change in branding, and Microsoft Identity Integration Server (MIIS) 2003 was born. MIIS introduced more of the metadirectory power that its predecessor possessed, and expanded on the capabilities by introducing built-in Management Agents to provide for synchronization to a wide variety of directories, as listed here:

One of the important new features of MIIS 2003 is the capability to allow users to reset their own passwords through a self-service Web page. This frees up a lot of help desk and security time formerly used to reset user passwords, as well as providing a more secure and private method of resetting the passwords.

Realizing the need for a “lite” version of MIIS, Microsoft made available the Identity Integration Feature Pack (IIFP), a free download from Microsoft that allows for metadirectory functionality between Active Directory, Exchange 2000/2003 Global Address List (GAL), and Active Directory in Application Mode (ADAM) forests. This version is as functional as MIIS, except for the fact that it only supports synchronization and provisioning between AD, and not to the other supported directories of MIIS. If you only need to synchronize between two or more AD forests, however, IIFP is perfect for the job. IIFP can be downloaded from one of the links on the MIIS Web site at Microsoft at http://www.microsoft.com/miis.

MIIS and the IIFP require the use of a back-end Microsoft SQL Server 2000 database. This database is used to store configuration information and the person-objects stored in the metaverse. The database can be located on a dedicated MIIS server, or it can be on an existing SQL Server box. All of the maintenance and administrative needs of any other SQL database exist for the MIIS databases as well.

Organizations that have many different directories and need to keep information synchronized between these directories need a metadirectory product such as MIIS. MIIS provides a single interface for administrators to access the different directories and to configure how the directories will synchronize and/or replicate with one another, through the metadirectory. Before discussing MIIS any further, an understanding of some key terms is required.

MIIS can be used for many tasks but is most commonly used for managing directory entry identity information. The intention here is to manage user accounts by synchronizing attributes such as login ID, first name, last name, telephone number, title, and department. For example, if a user named Jane Doe is promoted and her title is changed from manager to vice president, the title change could first be entered in the HR or Payroll databases, and through MIIS management agents, the change can be replicated to other directories within the organization. This ensures that when someone looks up the title attribute for Jane Doe, it is the same in all the directories synchronized with MIIS. This is a common and basic use of MIIS referred to as identity management. Other common uses of MIIS include account provisioning/deprovisioning, or the automatic centralized creation and deletion of user accounts and group management.

MIIS 2003 comes with many built-in management agents to simplify an MIIS implementation. These agents are used to configure how MIIS will communicate and interact with the connected directories when the agent is run. The type of management agent chosen depends on what type of directory is being connected.

When a management agent is first created, all the configuration of that agent can be performed during that instance. The elements that can be configured include which type of directory objects will be replicated to the connector namespace, which attributes will be replicated, directory entry join and projection rules, attribute flow rules between the connector namespace and the metaverse namespace, plus more. If a necessary configuration is unknown during the MA creation, it can be revisited and modified later.

After creating a management agent, run profiles must be created to define how the management agent will perform. Options include Full Import, Delta Import, Export Apply Rules, and Full Import and Re-Evaluate Rules. This allows MIIS administrators to give finer administrative privileges to run agents without compromising data integrity—for example, if only an import run profile was created. If you only have to import a profile, the management agent would import the desired directory objects and attributes from the connected directory to the respective connector namespace. The data in the connected directory would never be modified.

Installation of MIIS 2003 is straightforward because Service Pack 1 for MIIS eliminated the need to install MIIS on SQL Server 2000 Enterprise edition. Instead, it can be installed on either Standard or Enterprise Edition. To install, perform the following tasks:

At this point, MIIS should be installed and ready for the configuration of management agents, run profiles, and other necessary components for identity management.

MIIS can be used for the most basic and easiest configurations. For example, MIIS can be used to synchronize identity information between accounts in different directories. Identity information could include names, email and physical addresses, titles, department affiliations, and much more. Generally speaking, identity information is the type of data commonly found in corporate phone books or intranets. To use MIIS for identity management between Active Directory and an LDAP directory server, follow these high-level steps:

Figure 8.15. Using the MA Wizard.

These steps can be used to simplify account maintenance tasks when several directories need to be managed simultaneously. In addition to performing identity management for user accounts, MIIS can also can used to perform management tasks for groups. When a group is projected into the metaverse namespace, the group membership attribute can be replicated out to other connected directories through their management agents. This allows a group membership change to occur in one directory and be replicated to other directories automatically.

Account provisioning in MIIS allows advanced configurations of directory management agents, along with special provisioning agents, to be used to automate account creation and deletion in several directories. For example, if a new user account is created in Active Directory, the Active Directory MA could tag this account. Then, when the respective MAs are run for other connected directories, a new user account can be automatically generated in those other accounts.

The provisioning and deprovisioning process in MIIS can be an extremely useful tool in situations where automatic creation and deletion of user accounts is required. For example, a single user account can be created in an HR PeopleSoft database, which can initiate a chain-event of account creations, as illustrated in Figure 8.16.

Figure 8.16. Provisioning accounts with MIIS.

In addition to creating these accounts, all associated accounts can be automatically deleted through a deprovisioning process in MIIS. By automating this process, administration of the multitude of user accounts in an organization can be simplified and the risk of accidentally leaving a user account enabled after an employee has been terminated can be minimized.

The following high-level example demonstrates the steps required to set up simple account provisioning. In this example, a connected Windows NT domain is connected to MIIS. Any user accounts created in that domain has corresponding Exchange Server 2003 mailboxes created in a separate Active Directory forest.

Figure 8.17. Configuring attribute flow in the NT MA.

Figure 8.18. Configuring attribute flow in an MA.

Figure 8.19. Installing a customized rules extension DLL into the metaverse.

The example described previously, although complex, is useful in situations in which a single Exchange Server 2003 or Exchange 2000 forest is used by multiple organizations. The Security ID (SID) of the NT Domain account is imported into the metaverse and used to create a mailbox in the resource forest that has the external domain account listed as the Associated External Account. Through a centralized MIIS implementation, the Exchange resource forest can support the automatic creation of resource mailboxes for a large number of connected domains.

MIIS is a versatile and powerful directory synchronization tool that can be used to simplify and automate some directory management tasks. Due to the nature of MIIS, it can also be a very dangerous tool because the management agents can have full access to the connected directories. Misconfiguration of MIIS management agents could result in data loss, so careful planning and extensive lab testing should be performed before MIIS is released to the production directories of any organization. It is often wise to contact certified Microsoft solution providers/partners to help decide whether MIIS is right for your environment, or even to design and facilitate the implementation.

ADFS is composed of three different server components as follows:

Each of these components can be individually installed in an ADFS structure, or they all can be installed on the same system.

Installing ADFS on a Windows Server 2003 R2 requires several key prerequisites:

When the prerequisites have been satisfied and all necessary components, such as ASP.NET 2.0 and IIS 6.0, have been installed, ADFS can be installed via the following process:

Figure 8.21. Installing ADFS.

Figure 8.22. Specifying Federation Service information in ADFS.

ADFS works by inputting information about connected partners, such as AD forests or ADAM orgs, and inputting specific partner and application information. Each set of information can be inputted by running the various wizards installed by ADFS as follows:

Figure 8.23. Using the Add Account Partner Wizard in ADFS.

By entering the information about the various web-based applications, and which directories and identities are to be granted access, ADFS can provide for seamless sign-on capabilities among various directories. It can be a valuable asset for an organization that wants to share corporate information with trusted partners, without exposing their valuable internal assets to unnecessary exposure.