In this Chapter
Being the administrator of heterogeneous environments often requires compromise. You often have to use lowest-common-denominator protocols and tools. With a little research and an open mind, this doesn’t always have to be the case.
There are many standards and tools that allow Microsoft Windows–based servers and Unix to interact with their various directory services. With the correct configuration, and in some cases scripting, systems on different platforms can work well together.
Many of today’s applications require a platform decision. With more and more lines of business applications written for the Windows platform, Unix platforms need to be able to access those applications. Creating a directory structure, sign-in process, and file sharing services are critical.
Creating a single-sign-on environment is the panacea that most if not all administrators of Unix/Windows environments strive for. With vendors having different versions of LDAP and various levels of RFC compliance, this can be pretty difficult. Synchronizing different versions of LDAP and Active Directory requires some in-depth analysis and planning.
A truly integrated environment is possible with today’s tools. By putting aside any preconceptions about the other platform, whether Unix or Windows, administrators and network architects can make the two platforms work together in harmony.
One key factor in making the Windows and Unix environments work together is finding out which versions of LDAP, Kerberos, NIS and other components they have in common. Different platform vendors have chosen to adopt at different levels and versions of these Internet standards.
Knowing the location of each of the services and how they interact is crucial to determining the placement of common servers and services.
Client operating systems and versions also play an important role in determining the required services.
Microsoft uses a pretty well thought out and tested methodology for projects called Microsoft Solutions Framework (MSF). A complex undertaking like integrating disparate platforms requires a well thought out road map. The following list describes the high-level steps in an undertaking such as integrating Windows with other LDAP based systems:
Evaluate the current state of the company’s directory structures.
Plan what the new directory structure will provide.
Build the lab and test account creation and user authentication.
Deploy the directory solution into the production environment.
Operate and manage the new directory solution. This step also provides feedback in evaluating future solutions.
Defining the company’s business requirements should be part of an initial study. Administrative resources should always be considered. Your company might have to invest in either twice the number of administrators or administrators with twice the knowledge.
Before any servers or the services that they host can be integrated they have to be able to locate each other and to communicate. Creating a network infrastructure that all the involved platforms can work together on needs to be one of the first items on your agenda.
When it comes right down to it, most operating systems have more similarities than differences. They all need to store data, authenticate users, and store and locate resources both locally and on the network. Two of the services in common are Domain Name Services and Directories. By determining the versions that will work together you can create an integrated infrastructure.
One of the key strengths of Active Directory on Windows Server 2003 is that it’s based on several important industry standards. This conformity allows greater interoperability within a heterogeneous environment. The interaction between Active Directory and other vendor’s products isn’t always seamless, but it does provide the potential for information exchange in a multi-operating system environment. These common standards are ratified and published by the Internet Engineering Task Force (IETF) in the form of Request for Comments (RFC). Some of the standards and conventions that Active Directory is based on are listed in Table 16.1.
Table 16.1. Partial List of Standards Used by Windows Server 2003 and Active Directory
Standard | Reference | Description |
|---|---|---|
DNS Service (SVR) Resource Records and Dynamic Updates (DDNS) | RFCs 2052, 2163 | Dynamic host name management and Service Resource Records |
Dynamic Host Configuration Protocol (DHCP) | RFC 2131 | Network IP address management |
Kerberos v5 | RFC 1510 | Certificate-based authentication |
Lightweight Directory Access Protocol (LDAP)v3 | RFC 1777, RFC 2251 | Lightweight Directory Access Protocol and LDAP v3 |
LDAP ’C’ | RVC 1823 | Directory application programming interface (API) |
LDAP Schema | RFCs 2247, 2252, 2256 | Directory schema |
Simple Network Time Protocol (SNTP) | RFC 1769 | Distributed time service for networks |
Simple Mail Transfer Protocol (SMTP) | RFC 821 | Message transfer |
Transfer Control Protocol/Internet Protocol | RFCs 791, 793 | Network protocols |
X.509 v3 Certificates | ISO X.509 | Authentication of Identities |
RFCs are guidelines for vendors to follow. They make your life easier by being able to reference which functionalities in various vendors’ products might work together. It’s important for the IT community to have some common ground on which to build their systems.
Windows Server 2003 and Active Directory are very dependent on the DNS service for all their operations. There are three primary roles that DNS performs with Active Directory. Those roles are outlined in the following list:
Name Resolution. DNS maps the host names to IP addresses. This eliminates the need for WINS (Windows Internet Name Space), when Windows 2000 or newer clients are used.
Namespace Definition. The DNS namespace maps to the Active Directory namespace. This simplifies the Windows Server namespace.
SRV (Service) Resource Records. Used to locate physical components of the Active Directory. The DNS service provides a list of all the IP addresses to all the domain controllers.
A few of the LDAP-specific SRV resource records that are created in a Windows Server 2003 domain are as follows:
_ldap._tcp.<DNSDomainName>. This record enables the client to locate the domain controller.
_ldap._tcp.<SiteName._sites.<DNSDomainName>. This record enables the client to find the domain controller in a specific site.
_ldap._tcp.pdc._ms-dcs.<DNSDomainName>. This record enables the client to find the primary domain controller (PDC) flexible single master object (FSMO) role of a mixed-mode domain.
_ldap._tcp.gc._msdcs.<DNSTreeName>. This record enables the client to find a Global Catalog (GC) server.
_ldap._tcp.<SiteName>._sites.gc._msdcs.<DNSTreeName>. This record enables the client to find the GC server in a specific site.
_ldap._tcp.<DomainGUID>.domains._mscds.<DNSTreeName>. This record enables the client to find a domain controller based on its globally unique Identifier (GUID).
GUID
A GUID is a 128-bit (8 byte) number that is generated automatically for referencing Active Directory objects.
This is a partial list of the entries created when Active Directory is installed. A text file containing all the DNS resource records is called netlogon.dns and can be found in the %systemroot%system32config folder.
netlogon.dns
The netlogon.dns file contains all of the DNS SRV records that Active Directory uses to identify service resources in the domain. The entries in this file can be added manually to DNS servers that do not support Dynamic updates.
Active Directory can resolve names via DNS in a number of models. Four such scenarios are listed here:
Active Directory Dynamic DNS performs all name resolution within the domain.
A third-party (BIND) Dynamic DNS that supports SRV resource records performs all name resolution within the domain.
Making the Active Directory DNS the master and allowing zone transfers between the BIND DNS Server and the Active Directory DNS.
Making the BIND DNS the master and allowing zone transfers between the Active Directory DNS and the BIND DNS.
Directory services store much of the information about the users and resources contained on a computer network. These services are analogous to phone books for users and computers to locate resources. Authentication credentials can also be stored in the directory. A few of the desired characteristics of a directory service are security, fast read access, and fault-tolerance.
Microsoft’s Active Directory is based on LDAPv3. LDAP is a directory access protocol based on X.500 directory service. It’s derived from the X.500 directory service Directory Access Protocol (DAP). DAP is a heavyweight protocol that operates over an Open Systems Interconnection (OSI) protocol and is used to operate very powerful computer systems. Unlike DAP, LDAP is designed to operate over TCP/IP and maintains most features of DAP without using its expensive resources.
Some Unix systems still use the Sun Network Information System (NIS). NIS automated the task of manually administrating users and hostname resolution. This was performed by creating a NIS master and having Unix clients receive a replica of the files created and modified by you. This system is easier to manage than individual user accounts in the /etc/password files and host names in the /etc/hosts files. This method of administrating user and host name management is being replaced by services such as LDAP.
There are several ways to integrate directories across multiple environments. Two of the most popular architectures are creating a master/slave model or a metadirectory model. When designing a master/slave model the architect must decide which directory service will be used to manage directory objects actively and which one will only receive published updates. In the metadirectory model a separate directory management product is introduced to act as the master directory. The existing directories receive published updates from the metadirectory.
Active Directory’s LDAP is based on v3 of the LDAP standard. Not all LDAP implementations are based on LDAP v3. This makes it somewhat challenging to integrate them.
The LDAP schema objects that are going to be synchronized must match exactly. To do this you must do some planning and decide which of the versions of LDAP schemas will be the standard for the integration. By extending the LDAP schema you enable synchronization of entries within the schema and ensure that they will match correctly.
Different tools are available for accessing (reading) and manipulating or editing the LDAP schema of Active Directory. Tools can be purchased from third parties, such as Softerra’s LDAP Administrator, to manage multiple LDAP schemas on different platforms with one product. The native Windows Server 2003 tool to edit the Active Directory is an MMC snap-in named ADSI Edit.
To install the ADSI Edit snap-in into a new MMC console you need to perform the following steps:
The ADSI Edit MMC snap-in can be used to perform referrals to external naming contexts. This allows a limited coexistence for users and applications to access multiple directories during an integration/migration project. You create a referral by performing the following steps:
Open the ADSI Edit MMC snap-in console, right-click on ADSI Edit and choose the Connect To option, as shown in Figure 16.1.
In the Connection Settings dialog box, change the naming context to Configuration, as shown in Figure 16.2, and then click OK.
Right-click on CN=Partitions and select New, Object, as shown in Figure 16.3.
In the Select Create Object dialog box, shown in Figure 16.4, the default class option is crossRef. Choose Next.
In the CN Attributes dialog box, shown in Figure 16.5, enter a common name for the LDAP directory to be referred to and choose Next.
In the nCName (naming context name) attribute dialog box, shown in Figure 16.6, enter the naming context of the LDAP server, and choose Next.
In the dnsRoot Attribute dialog box enter the fully qualified domain name of the LDAP server, shown in Figure 16.7, and choose Next.
The final dialog box enables you to choose More Attributes, such as an administrative description of this object. Choose Finish to add the referrer object to the CN=Partitions container.
In larger environments where major investments have been made in large Unix or mainframe directory deployments, migration might not be an option. In cases such as these a metadirectory could be a desirable option to consider.
A metadirectory is used to consolidate disparate data from multiple directory structures. The metadirectory might consolidate a superset of data gathered from multiple disparate directories with different attributes, managed from different systems. A second option is a subset of data, while maintaining the company’s common namespace alongside the namespace mappings to all of the connected systems, as well as key attributes, such as e-mail and public keys. Either approach works, and depends on your company’s strategy for its directory usage.
Microsoft Identity Integration Server 2003 (MIIS) is an example of a LDAP metadirectory integration product. MIIS uses SQL Server 2000 (SP3 or later) to store the LDAP schema and synchronizes with multiple disparate LDAP schemas.
One of the more laborious tasks of a network administrator or, in larger environments, the help desk, is assigning and changing passwords. This becomes especially challenging when multiple disparate platforms are involved.
To automate password synchronization the multiple platforms must be able to communicate such events as password expiration, resets, and lockouts. This process is usually best accomplished through scripting or automation programs.
You can use password synchronization to make it easier on users by only having to remember one username and password for both Windows and Unix systems. One way to accomplish this is to synchronize the passwords when one of them changes. Synchronization can either be one-way or two-way, depending on how the systems are configured.
Microsoft SFU 3.0 password synchronization runs as an extension of the Local Security Authority (LSA) service on Windows Server 2003. On the Unix platform a daemon called the single-sign-on (ssod) daemon and the pluggable authentication module (PAM) perform the synchronization processing. The Windows and Unix password information is encrypted when transported over the network.
Microsoft SFU 3.0 supports password synchronization between the Windows Server and the following flavors of Unix running NIS:
Sun Microsystems Inc. Solaris version 7
Hewlett-Packard HP-UX version 11
IBM Corp. AIX version 4.3.3
Red Hat Inc. Linux version 6.2 and later
To perform a test password synchronization you must ensure that SFU password synchronization is installed (not installed in default installation).
Prior to testing, you should configure DNS and test connectivity between the two systems. TCP port 6677 must be allowed by the firewall. The following steps can be taken to confirm that password synchronization is configured correctly:
Create a couple of test users on the Windows server with the following settings:
Username “bsmith”, password “bgrvfe”
Username “rjones”, password “mjunhy”
Open up the Services for Unix Administration mmc console and select Password Synchronization.
In the right pane, configure the Password Synchronization Default settings as shown in Figure 16.8.
Click on the Advanced tab and configure the Password Synchronization Advanced settings (inserting the name of the desired Unix server) as shown in Figure 16.9.
Click on the Configure button at the bottom of the Password Synchronization Advanced page and configure the settings as shown in Figure 16.10 and click Apply.
On the Unix system (Red Hat Linux 7.3 in this test), you need to perform the following steps:
Log in as root.
In a console run the following commands:
useradd bsmithuseradd rjonespassword bsmith (set bgtvfr as password)password rjones (set mjunhy as password)
Copy the following files from the Microsoft SFU CD (located in the unixin folder) to the Unix system: pam_sso.l52, sso.cfg, and ssod.l52.
In a console, change to the directory where the files in the previous step were downloaded and run the following commands:
cp ssod.l52 /user/bin/ssodchmod +x /user/bin/ssodcp sso.cfg /etc/sso.conf
Edit the sso.conf file to specify the following:
ENCRYPT_KEY=ABCDZ#efgh$12345 (This is the same value as entered in the Default page in the SFU Password Synchronization on the Windows computer).
PORT_NUMBER=6677
SYNC_HOSTS=(windows-dc, 6677, ABCDZ#efgh$12345) (Replace windows-dc with the name of the Windows host performing password synchronization).
USE_NIS=0
USE_SHADOW=1 (if applicable)
Copy pam_sso.l52 to the /lib/security directory with the file name of pam_sso.so.1.
Edit the /etc/pam.d/system-auth file to specify the following:
password required /lib/security/pam_cracklib.so retry=3
password required /lib/security/pam_sso.so.1
Delete the line containing: password required /lib/security/pam_deny.co
Copy /etc/pam.d/password to the /etc/pam.d/ssod directory.
Run the /user/bin/ssod command.
The users will now be able to change their passwords on either Unix or Windows server and be able to log on to either platform with the same username and password.
Password management involves quite a set of complexities. Different platforms employ methods for encrypted storage and transmission of passwords. This usually involves installing management agents on the host system to ensure that a common set of technologies are employed. There are several commercially available LDAP Gateway and Synchronization products available. Cost and complexity are often key factors to consider prior to deploying such a system.
Microsoft Identity Integration Server (MIIS) 2003 (formerly known as Microsoft Metadirectory Services) provides password management for the following platforms:
Novell eDirectory 8.6.2 and 8.7
Sun and Netscape Directory Servers (formerly iPlanet Directory Server)
Lotus Notes Releases 4.6 and 5.0
Active Directory
Active Directory Application Mode
Windows NT 4.0
Installing Microsoft Identity Integration Server 2003 requires some advanced planning and should first be deployed in a lab environment. MIIS Password Management requires installation and configuration of the following products:
Microsoft Windows Server 2003, Enterprise Edition
Microsoft SQL Server 2000, Enterprise Edition, Service Pack 3 (SP3) or later
Microsoft Visual Studio .NET 2003
Microsoft Identity Integration Server 2003, Enterprise Edition
MIIS Password Management uses the .NET framework to generate Web-based forms that administrators and help desk personnel and end users can use to set and change passwords. This requires the installation of IIS 6.0, Active Server Pages. If development debugging is desired FrontPage 2002 Server Extensions must also be installed.
Over the past few years, Microsoft has been consolidating management resources for the various tools they have available. With the release of Windows 2000, the use of the Microsoft Management Console (MMC) has become the standard management interface used in the Microsoft tools. Windows Server 2003 continued to leverage the MMC for manageability; however for many of the non-Windows products covered in this chapter, you can also use native tools that might be more familiar to you for the administration and management of Unix, NetWare, or other environments.
Windows Server 2003 has added access to many command line utilities that allow you to access the server via telnet on the Unix platform and perform many administrative tasks that were only available through the graphical user interface (GUI) previously.
The MMC gives you a unified view of the Active Directory and LDAP schema. By installing snap-ins to manage the components of the Active Directory, you can customize and delegate control of discrete functions.
There are a couple of essential tools that ship with Windows Server 2003. These tools are the Active Directory Services Interfaces (ADSI) Edit and Active Directory Schema snap-ins. Setting up an MMC console that allows you to manage and extend the LDAP schema is described in the following sections.
To register the schmmgmt.dll either open a command window or from the Run dialog box, shown in Figure 16.11, type regsvr32.exe %systemroot$system32schmmgmt.dll. After the DLL is registered a message window appears as shown in Figure 16.12 that the registration succeeded.
Active Directory Schema MMC Snap-in
The Active Directory Schema MMC snap-in is disabled by default. Its DLL (schmmgmt.dll) must be registered before it can be installed.
To install the Active Directory Schema snap-in perform the following steps:
Select Start, Run and type in mmc and click OK.
In the new Console window select File, Add/Remove Snap-in.
Select the Add button in the Add/Remove Snap-in dialog box.
In the Available Standalone Snap-ins pane choose Active Directory Schema, and then choose Add, Close.
The Active Directory Schema snap-in should now be Add/Remove Snap-in window; choose OK.
MMC Console
By default, the newly created MMC console will be saved in the Administrative Tools folder. Choosing the default folder enables you to find the newly created console easily.
The Active Directory Schema snap-in is now available for use in the MMC console. This will allow you to browse all classes and attributes.
To modify the schema, the Schema Operations Master needs to be selected and modifications allowed on this domain controller. To enable this configuration you must right-click on the Active Directory Schema and select Operations Master, as shown in Figure 16.13.
For the two disparate systems to work together an important piece of the puzzle is securely sharing files. There are several possible ways to share files and folders between the two operating systems. The most prevalent method of sharing is emulating or hosting the native file sharing protocols of the other system.
In the case of Unix file sharing to Windows, either the native NFS shares can be accessed or use Samba, which emulates the Windows Server Message Block (SMB) sharing. These two approaches are discussed in more detail in the following sections.
The NFS Client that is included with SFU gives the Windows-based computer the ability to access Unix-based NFS resources. Once installed and configured the NFS client creates the ability to use UNC (\servernameshare) style mappings. To configure the NFS client on the Windows side perform the following:
NFS
By default, Server for NFS, Client for NFS or Gateway for NFS are not part of the Services for Unix installation.
To Configure the NFS Services...
To configure the NFS services you must ensure that the server for NFS is installed and started and that the client for NFS is installed.
On the Windows computer open Explorer and right-click on a directory to share and choose Sharing and Security.
On the NFS Sharing tab select Share This Folder, as shown in Figure 16.14.
In the Share Name box type a name for the new share, and then choose Allow Anonymous Access.
Click on the Permissions button and allow and configure the access rights, as shown in Figure 16.15.
Samba on Unix uses the /etc/samba/smb.conf as its configuration file. You need to edit this file to match your Windows environment to share files and printers. The following list shows some of the essential settings in the smb.conf file:
Encrypted Samba Passwords Required
Windows Server 2003, Windows 2000, and Windows NT 4.0 with Service Pack 3 or later require encrypted Samba passwords.
workgroup = <Windows Workgroup Name>server string = Brief Description of Serverhosts allow = <single IP or subnets of allowed hosts>comment = Description of the Sharepath = /home/share/valid users = usera userb usercpublic = nowritable = yesprintable = nocreate mask = 0765encrypt passwords = yessmb passwd file = /etc/samba/smbpasswd
The following command creates a Samba password file and encrypts the contents:
cat /etc/passwd | mksmbpasswd.sh > /etc/samba/smbpasswd
The new file will only be populated by user accounts. The passwords need to be set using the following command:
smbpassword <username>
smb.conf Changes
Any changes to the smb.conf file do not take effect until the Samba service is restarted.
This section only covers some of the very basic configuration settings to allow Windows users to access Unix resources shared using Samba. The detailed settings for each version of Samba are given in that version’s manual (man) pages.
On the Unix client the user can access Windows printer shares using Samba or with their native remote line printer (LPR) client. On the Windows Server 2003 platform you can use Print Services for Unix to enable the following:
Act as a Line Printer Daemon (LPD)
Remote Line Printer (LPR) client
Send print jobs to Unix servers
By default Print Services for Unix is not installed. To install this service you must perform the following steps:
With the adoption of Samba and the availability of mature file sharing utilities such as FTP and NFS, the lines have blurred where files are located on a computer network. Windows Server 2003 also exposes many command line tools for management that can be accessed via telnet from Unix-based clients.
Windows Server 2003 Must Be Run in Mixed Mode
For interoperation with utilities such as Samba, Windows Server 2003 must be run in Mixed mode. With the updated version of Samba (3.0.0 RC2 as of this writing), Windows Server 2003 can be run in Windows 2000 mode.
Unix system administration is predominantly command-line driven, with Telnet being one of the main tools of choice for this purpose. Windows Server 2003 has come a long way in providing command-line utilities, all of which are available through the Telnet server both natively and with Windows SFU.
An administrator telnetting to a Windows Server 2003 session can, for example, run command line scripting utilities such as adsutil.vbs, as shown in Figure 16.16.
On a Unix-based system Samba uses the smbclient to access Windows-based shares. This is a command-line interface-based tool that has many functions besides just connecting to Windows shares. It can also be used for testing configurations, debugging, and automating administrative tasks when used in shell scripts.
There are many combinations of variables and command line options with the smbclient. The following are a few examples:
To list the resources in the domain (rtds is the domain controller and master browser):
$ smblicent -L rtds
To list the services on a single computer (rtws01), run this command:
$ smbclient -L rtws01
To connect to a share using username/password authentication:
$ smbclient //rtws01/shared -U username%password
These are just a few examples of the smbclient command. The Samba documentation concerning smbclient contains a complete reference.
Samba allows the Unix/Linux user to print to a printer shared on a Windows system. This makes it convenient for you because you only have to set file and print sharing for Unix.
Many Unix variants, including Linux, use what is called the BSD printing system. With this system all the printers that will be used have an entry in the /etc/printcap file. This file describes printer capabilities used by the line printer daemon (lpd) and other programs that assist with printing.
Listing 16.1 shows a sample printcap.local file that shows a Hewlett-Packard LaserJet 4050 being shared on a Windows Server 2003 system named rtfnp.
The Red Hat Linux /etc/printcap File
In Red Hat Linux the /etc/printcap file is generated automatically and should not be edited. Any manual entries should be placed in the /etc/printcap.local file which is read by the /etc/printcap file.
This entry describes the server and printer as follows:
In line 1,
lpdesignates this as the default printer,rtfnp-hplj4050describes the name of the print server and the type of printer.In line 2, the
cmkeyword allows for a description of the printer share.In line 3, the
sdkeyword assigns the printer’s spool directory.In line 4, the
afkeyword assigns the printer’s accounting files.In line 5, the
ifkeyword assigns the print filter (in this case thesmbprintcommand to the shared printer).In line 6, the
mxkeyword sets the maximum file size to be printed. In this case it is set to zero, which allows any size file.In line 7, the
lpkeyword is set to/dev/nullto discard error messages.
This example can be used to create as many printers as desired on the client’s Unix-based system.
To set up Samba printing on the Unix client, perform the following steps:
Install the smbprint program (from the Samba source root directory):
# cp examples/printing/smbprint /user/local/samba/bin
Create the printer’s spool directory.
# cd /var/spool/lpd # mkdir rtfnp # chown lp:lp rtfnp # chmod 700 rtfnp
Create the .config file.
# cd rtfnp # >.config # chown lp:lp .config # chmod 600 .config
Insert the following information about the printer and how to connect with a text editor into the .config file:
server=rtfnp service=hplj4050 password="<domain password>"
Restart the printer daemon:
# /etc/rc.d/init.d/lpd restart
Following this procedure you have created a default printer on the local system that will print to the hp 4050 share on the Windows Server 2003 system named rtfnp. To print a test page (/etc/hosts file) to the default printer you can use the following command:
# lpr /etc/hosts
To print to a Windows-based printer from Unix using the LPR command, you must first set up Print Services for Unix on the Windows Server 2003 machine. This is accomplished by performing the following steps:
Select Start, Control Panel, Add or Remove Programs and then select Add/Remove Windows Components.
Select Other File and Print Services and then click on the Details button.
Choose the Print Services for Unix check box and then click on OK.
Select Next and then after the installation is complete choose Finish.
This procedure sets up what looks like a Unix server running the LPD service. The Unix system prints to this resource using the BSD printing system.
Maintaining multiple operating systems and various versions makes administration very difficult and time consuming. It should always be a goal to consolidate platforms onto a single operating system, if feasible. Window Server 2003 offers great promise in being able to consolidate many functions performed by Unix and other LDAP-based directory services.
LDAP services can be hosted by multiple platforms simultaneously in an enterprise. This should only be used as a stopgap measure. The Windows Server 2003 LDAP schema can be extended to accommodate a range of client requests.
Synchronization between LDAP servers should be configured as a one-way transaction to the Active Directory. This enables you to consolidate and manage all the directory resources from a central location.
File shares need to be consolidated for ease of management and security. To consolidate these resources you can methodically transition clients off the Unix file-sharing platform. NFS file shares can be hosted via Windows SFU-based NFS Server. Samba shares can be migrated to Windows-based DFS shares for fault-tolerance and load balancing.
In the short term, products such as Samba, Windows Services for Unix, and Microsoft Identity Integration Server provide seamless integration between the disparate platforms. This situation is complex to implement and costly to manage.
The long-term goal should be to consolidate on a single platform. Windows Server 2003 is proving to be a stable and more secure platform than previous generations of Windows-based servers. This provides a compelling argument for administrators who are familiar with the Windows platform. Migrating to a single platform tends to reduce training, licensing, and administrative costs.