Chapter 8 - Windows-UNIX Interoperability and Data Sharing

On This Page

Overview
Windows to UNIX Connectivity
User Authentication and Authorization
Resource and Data Sharing
Summary

Overview

If you are moving from CATIA V4 running on UNIX to CATIA V5 running on Microsoft Windows, you must ensure that the two environments can communicate smoothly. However there are significant differences in the way these systems approach common tasks, such as file serving, security, and the user interface.

During a migration project UNIX and Windows-based systems must communicate or interoperate. Even if the migration is to be done very quickly, data must be transferred and custom scripts and applications migrated. If you have planned your migration to run in phases, it might last several weeks or even months, and there will be a sustained period when the two operating systems must share information in a variety of ways.

This chapter presents the issues that arise in Windows and UNIX interoperability and the tools available to address the issues.

A more detailed approach can be found in UNIX Application Migration Guide Patterns & Practices at https://msdn.microsoft.com/library/en-us/dnucmg/html/ucmglp.asp

Four categories of interoperability issues and the tools to address them are presented in the following sections:

• Windows to UNIX Connectivity. This section discusses how a user on one operating system can connect to and use the other operating system over a network.

• User Authentication and Authorization. This section discusses the UNIX and Windows security models and how to integrate them so that users on one operating system can securely use resources on the other.

• Resource and Data Sharing. This section discusses how to provide access to UNIX and Windows-based resources (specifically, networked file systems) across the two operating systems.

• Choosing Interoperability Solutions. This section presents strategic considerations posed by Win32 and Interix environments and by cross-platform support for interoperability.

• More information about Interix is available at https://www.interix.com/

A CATIA migration is likely to use many of the solutions presented here. For example, if you have planned to migrate the desktop computers before the file servers, Windows 2000 or XP computers will need to access CATIA files hosted on UNIX file servers. If there is a need for those computers to run a custom CATIA script, they may need to issue a command to run on the UNIX computer. For more information on interoperability in general, see the "References" chapter at the end of this document.

Windows to UNIX Connectivity

A CATIA administrator or user on Windows may wish to access a UNIX server to run a command or custom script that manipulates a CATIA file. This can be done with a command line shell accessed by using a terminal or terminal emulator. Similar situations may arise for UNIX users who wish to access Windows computers. To do more complex tasks such as run a full implementation of CATIA installed on a Windows code server from UNIX, a GUI may be required.

Command line access tools include telnet, Berkeley r access commands such as rsh, rexec, rcp, and secure shell (ssh). The telnet client allows the user to operate in the multi-user, command-driven environment provided by a host with a telnet server. Telnet servers and clients exist for both Windows and UNIX. The rsh command allows the user to run commands remotely from the local computer.

In UNIX, the GUI is provided by the X Windows system. This has always been designed as a multi-user system, and so it extends to remote clients quite simply. With an X Windows server on the desktop, developers can also use a GUI to connect to UNIX-based applications. Windows operating systems do not provide X Windows. For X Windows connectivity, developers need a third-party X Windows server.

Windows, by contrast, is traditionally thought of as a single user operating system. However, the recent addition of Terminal Services to Windows 2000, as well as third party systems like Citrix Metaframe, has allowed multiple users to gain GUI access from remote computers.

These access methods are of particular importance when migrating custom applications and scripts (see Chapter 7, "Migrating Custom Applications and Scripts"). While migrating, developers need access to the UNIX development servers from their Windows desktops. Even during a rewrite to Win32—which replaces the UNIX environment permanently—developers must have access to the UNIX environment.

Developers need access for operations such as:

• Running the UNIX application to check the original functionality.

• Referring to UNIX code, the build configuration, or management scripts.

• Migrating any missing portions of code or scripts.

The following sections describe the main connectivity solutions available.

Note: In X Windows terminology, server refers to the software running on the users desktop that provides the user interface; and client is the application running on the UNIX server.

Terminal Emulation and Command Line Connectivity

UNIX developers and administrators use the tools described in this section to access UNIX servers from the command line. If a UNIX application has a command line interface, these tools are also helpful to users. Various aspects of CATIA can be accessed from a command line, and custom scripts can be run.

Windows Telnet Clients

The Windows telnet client provides basic command line access to UNIX systems. Its command syntax is identical to the telnet clients found on UNIX operating systems. The Windows telnet client can be initiated by typing the command telnet at the command prompt or Run box. Users can cut and paste text between the UNIX command line and Windows-based applications.

The Microsoft HyperTerminal application also includes a telnet client. HyperTerminal offers more configuration options than the command line telnet client. Terminal types for the client range from American National Standards Institute (ANSI) to VT52 to VT100, which allows you to select an environment you are already used to. It is straightforward to cut and paste text between HyperTerminal and Windows-based applications.

A third-party telnet client may be required for command line tools that use terminal characteristics beyond those provided by HyperTerminal, such as function keys or full-screen operation.

Windows Telnet Server

Developers who need to connect from UNIX to Windows-based servers can set up the telnet server included in the Windows operating systems.

To connect from UNIX to a Windows-based server, follow these steps:

1. Use the tlntadmn command to modify the NTLM authentication option. NTLM authentication is only supported by other Windows computers. If you want to connect to the Windows telnet server from a UNIX computer, the default value needs to be changed from 2 to 1 as follows:

   1. Run the tlntadmn command utility.

   2. Choose option 3 to configure registry settings.

   3. Then choose option 7 for NTLM settings.

   4. Change the value to 2.

   5. Exit the utility.

2. Start the server by typing net start tlntsvr.

Note: Standard telnet is inherently insecure in that passwords are transmitted over the network in clear text. Some UNIX telnet servers and clients make use of Kerberos authentication, and the Windows client and servers can use NT authentication for added security. If the application to be migrated makes use of standard telnet, consider migrating it to a more secure version of telnet.

Remote Shell (rsh), Remote Copy (rcp), and Remote Execute (rexec)

Using the Berkeley r commands for remote access into UNIX servers can simplify access. Authentication occurs only once on first connection to the UNIX system a user does not need to log on again to connect to other systems.

The remote shell client (rsh) is available on all Windows computers and provides a shell for running commands on UNIX servers elsewhere. The syntax is as follows:

rsh [Host] [-l UserName] [-n] [Command]

The remote execute tool (rexec) has similar syntax and performs similar remote commands. The tool you use will depend on whether the UNIX server is running the rsh or rexec daemon:

rexec [Host] [-l UserName] [-n] [Command]

For copying files between remote computers, the rcp tool is provided. The syntax is as follows:

rcp [{-a | -b}] [-h] [-r] [Host][.User:] [Source] [Host][.User:]

[Path\Destination]

On Windows-based clients, the UserName parameter is required if user names on UNIX and Windows are different.

The Windows 2000 Resource Kit includes an rsh server; Rshsvc.exe.

Note: Authentication for Berkeley r commands is based on the existence of a valid client host and username combination as command parameters because if this information is revealed, these commands can present a security risk. For this reason, the commands are often disabled and replaced by the ssh command, as described later in this chapter.

Secure Shell (ssh)

The secure shell provides extra authentication and encryption features. It is often used to replace telnet and the Berkeley r commands where security is an issue. The ssh command functionality is similar to the rsh command, except that ssh can be made secure (client and user information is not revealed to third parties).

Windows operating systems do not include a secure shell client or server. However, third-party products do provide ssh functionality.

Remote Graphical User Interfaces

Users who require GUI access to a UNIX server from the Windows-based desktop normally use an X Windows server. In the opposite direction, remote desktop services are provided by Windows Terminal Services and its clients, which can be run on UNIX, Linux, and other operating systems.

GUI access to a CATIA code server allows users to enjoy all the features and convenience they would if they were running CATIA on their local desktop.

X Windows

Windows operating systems do not include an X Windows server. However, the Interix environment, included in Microsoft Services for UNIX 3.0, does include X Windows clients, which can be used to develop applications that use an X Windows user interface. Xterm can be run from Interix with an X Server.

Third-party products that provide Windows-based X Windows servers are well integrated with the Windows desktop. Users of the third-party products can cut and paste text and graphics between X Windows and Windows. The following are popular X Windows servers for Windows clients:

• Hummingbird Exceed. For more information, refer to the Hummingbird Web site at https://www.hummingbird.com/

• MKS Toolkit. For more information, refer to the MKS Web site at https://www.mks.com

• WRQ Reflection(r) X. For more information, refer to the WRQ Web site at https://www.wrq.com

These products provide support for most X Windows standards. Each product also includes extras. For example, MKS Toolkit also includes more than 300 UNIX commands that can be used within Windows.

Remote Desktops

A Windows operating system and UNIX each handle multiple users in a different way. Traditionally, only a single user at a time could log onto a Windows computer. However, by using Windows 2000 Terminal Services, multiple users, seated at remote computers, can log on to a single server. A Windows-based server can thus provide a desktop to remote users on clients spread over the network, including those on other operating systems. The software that runs on the remote desktops is often called a thin client, because the client only has to handle input and output while the application runs on the server. With Windows XP Pro, even local sessions use Remote Display Protocol (RDP), which means that you can log off your machine, someone else can log on to your machine, and then log off, and you can log on again with all your programs still running.

For UNIX to Windows connectivity, UNIX and Linux can implement the RDP) used by Terminal Services by installing the Terminal Services client software on them. At the time of writing, these products are new. It has not been determined whether they are appropriate for a commercial environment.

Such a system can be made more manageable and scalable using Citrix MetaFrame. This product is an add-on to Terminal Services and eases administration while improving the end users experience. MetaFrame also has clients for a wide range of operating systems, including UNIX and Linux.

(For more information about Citrix MetaFrame, refer to the Citrix Web site at: https://www.citrix.com/site/PS/index.asp. An X Windows interface to UNIX is required to use the product.

User Authentication and Authorization

This section discusses security issues during UNIX to Windows migration and potential solutions.

In any heterogeneous network such as a network migrating to Windows users need to work across systems and the systems themselves need to interoperate. This situation is very likely to arise when migrating to CATIA V5 running on Windows from a previous version running on UNIX. In order to maintain security, each user must be identifiable on both systems. This can be done by providing each user with two accounts: one in UNIX, the other in Windows.

Migration planners need to consider the following security questions:

• Do users require two sets of user names and passwords: one for UNIX and one for Windows?

• If so, how will users keep their passwords synchronized?

• Do administrators need to manage two user databases?

• How do administrators manage user security on shared resources, such as network file systems?

The greater the need for interoperability during the migration, the more important these questions become. The rest of this section presents information about Windows and UNIX security and how to integrate them. This should enable you to answer the above questions.

Security models for both operating systems typically have two components:

• Authentication to verify the users identity.

• Authorization to control access to resources and to limit what a user can do.

Authentication and Authorization in UNIX

UNIX security relies on user credentials and file permissions. In UNIX, user credentials consist of two unique identifiers for each user: a user identifier (UID) and a group identifier (GID). Every UNIX process runs in the context of such identifiers and this determines what that process is able to do. UIDs and GIDs are integers assigned by the administrator. They are not guaranteed to be unique across a network.

Users are listed in the /etc/passwd file. This file contains a single line of text for each user. The line has fields for the user name, user ID, password, home directory, default shell, and others. The password is encrypted so neither the administrator nor anyone else can read it.

Groups are listed in the /etc/group file, which lists the names of the users in each group.

UNIX assigns permissions to every file, directory, and device. The permissions are for the user (that is, the owner of the file), for the group, and for everyone else.

When a process seeks access to a file, UNIX uses the UID and GID of the process to determine which permissions apply to that process.

To authenticate a user at logon, UNIX uses protocols such as clear text authentication, Kerberos, and other proprietary schemes. After logon, every process a user creates has the same UID and GID, and thus the access rights of the user referenced by the UID.

To secure stations, some UNIX installations may also use a Host.equiv or .Rhosts file containing host information based on the host name and IP address. These files define the set of trusted hosts, users, and host-user pairs that certain UNIX processes use to verify access. For example, rlogin (remote logon) and rsh (remote shell) bypass the normal logon and password security mechanisms of /etc/passwd or Network Information Service (NIS) and use these files instead. The /etc/hosts.equiv file contains trusted hosts and/or trusted host-user pairs.

The UNIX user database can be centralized for a network of UNIX computers using NIS. NIS maps the /etc/passwd and /etc/group files to a central database held on the NIS servers. All other aspects of UNIX security continue to work in the same manner, but use UIDs and GIDs from the NIS server rather than local files.

Authentication and Authorization in Windows

Windows security relies on user credentials and object permissions. When a user logs on to a Windows-based computer or domain, Windows authenticates them using either Kerberos or NT LAN Manager (NTLM) authentication. These are protocols that provide a secure way to check the user name and password typed by the user against a centralized user list. Kerberos is used if the computers involved all have Windows 2000 or later; for earlier versions, NTLM is used. The user list is stored locally if this is a stand-alone computer, or on domain controller servers if this computer is a member of a domain.

Each user account, once authenticated, is identified by means of a security identifier (SID). This is a long number unique to that account. Each group that the account is a member of also has a SID. A list of the SIDs of the user account and its groups is created at logon and used when resources are accessed around the network. This list is called the Access Token.

Windows objects (including files and directories) have a security descriptor (SD) associated with them. The information in the security descriptor includes the owner of the object and a discretionary access control list (DACL). This DACL is a list of SIDs together with the level of access granted to that account and it allows a much greater range of permissions than UNIX does. Further, those permissions can be assigned more selectively than those provided by UNIX. When a user tries to access a resource, the Access Token is compared with the DACL to determine the appropriate level of access.

Integrating UNIX and Windows Security

Figure 8.1 illustrates the differences between the UNIX and Windows security models. Although the differences in this example focus on NIS and Active Directory domains, the differences are identical for UNIX and Windows-based computers that are not part of a security domain.

Figure 8.1: UNIX and Windows security model differences

The following figure summarizes the differences illustrated in Figure 8.1.

Figure 8.2: UNIX and Windows Security Model Differences

These differences raise a number of interoperability issues:

• How to map UNIX-style user names to Windows-style user names.

• How to map UIDs to SIDs and SIDs to UIDs to control access to resources, such as files, when accessed across the two systems.

• How to convert incompatible file and resource permissions.

• How to centralize the management of UNIX and Windows users.

The following sections describe some tools for integrating UNIX and Windows security.

User Account Management and Synchronization

There are three possible approaches to managing user accounts across UNIX and Windows:

1. Create separate and unrelated accounts for UNIX and Windows.

   This solution is simple, but requires the most effort for users of both platforms. It complicates cross-system authentication and security permissions. This solution is appropriate when the need for interoperability between UNIX and Windows is limited and brief.

2. Create duplicate, identical accounts on UNIX and Windows.

   Duplication of accounts simplifies interoperability because UNIX and Windows accounts can relate to each other. It also simplifies the conversion of permissions. However, it does double administration and results in each user having two passwords.

3. Integrate UNIX and Windows account management.

   This long-term solution accommodates a long-term migration project or a target environment that includes both UNIX and Windows-based servers. In this case, administrators should centralize user management into one place, such as the Windows Active Directory. Management from Windows Active Directory is consistent with a migration to the Windows platform.

Many third-party and Microsoft interoperability products provide UNIX-to-Windows user mapping. For example, Samba provides its own methods of mapping user names. (For more information about Samba, see references to Samba in the "Resource and Data Sharing" section later in this chapter.) Although sometimes helpful, these methods can create a need for additional administration and could complicate the system.

Microsoft Services for UNIX Server for NIS

Microsoft Services for UNIX 3.0 includes a Network Information System (NIS) server called Server for NIS. This service uses Windows 2000 Active Directory to implement NIS.

Administrators can use Server for NIS to:

• Store NIS maps in the Active Directory.

• Integrate NIS objects (such as users) with corresponding Active Directory objects.

• Use Windows 2000-based servers as NIS servers.

• Migrate NIS domains to Active Directory.

• Merge multiple NIS domains.

• Synchronize passwords (see the "Microsoft Services for UNIX Password Synchronization" section later in this chapter).

Figure 8.3 shows the architecture of Server for NIS. Notice that although UNIX slave NIS servers are still usable, the master NIS server now resides on Windows.

Figure 8.3: Architecture of Server for NIS

Server for NIS is especially useful for large networks that already have NIS and Active Directory. However, administrators need to be aware of how Server for NIS interoperation works.

Server for NIS must be installed on a Windows 2000 domain controller. The Windows-based server uses Active Directory to store the NIS information. Normal Active Directory replication is used to propagate the NIS data to other Windows domain controllers.

• The computer running Server for NIS must be the master NIS server. This means that all the other Windows-based and UNIX NIS servers are subordinates.

• The Active Directory tools on the master computer administer both the NIS and the Active Directory domains.

• An NIS to Active Directory Migration Wizard assists in moving the existing NIS domain into Active Directory.

For more information on Server for NIS, refer to the Microsoft white paper, Server for NIS Overview, at: https://www.microsoft.com/technet/itsolutions/interop/sfu/servnis.mspx

Microsoft Services for UNIX Password Synchronization

Microsoft Services for UNIX includes two-way password synchronization between UNIX and Windows. This is not necessary if you are using Server for NIS because Active Directory and NIS are already closely integrated. Use this system if you wish to maintain separate UNIX and Windows user lists, but ensure their passwords match.

To synchronize from UNIX to Windows, a single sign-on daemon (SSOD) must be running on the UNIX NIS server. Microsoft Services for UNIX supplies precompiled SSODs for popular UNIX versions. For UNIX versions without a precompiled SSOD, Microsoft Services for UNIX supplies the source code to create one. You must compile this code on your UNIX platform.

Password synchronization occurs only between systems that are configured to synchronize by an administrator. A file on the UNIX side contains a list of computers to notify of password changes. Tools on the Windows side maintain the list in the registry. In addition, administrators can specify which users have passwords that must be synchronized.

To synchronize passwords for Windows 2000 domain accounts, all domain controllers on the network must be running the synchronization service, and all participating UNIX computers must be running the SSOD. When synchronizing passwords for local user accounts, the service must be installed on all Windows 2000-based computers.

Because password synchronization does not use user name mapping, the user names must be exactly the same for both UNIX and Windows. Therefore, user names must conform to the most restrictive definition of length and structure. For example, because Windows user names are not case sensitive, but UNIX user names are, all Windows user names must be in lowercase.

Resource and Data Sharing

Any migration from UNIX to Windows requires the two very different environments to share data and resources. In the simplest case, UNIX servers quickly migrate files to Windows-based servers. At the other end of the spectrum, UNIX servers and Windows-based servers share data and resources, such as printers and folders, during and after migration. Your situation will depend on the complexity of both your original and your new CATIA implementations.

This section presents the options for sharing resources between the two environments, concentrating on networked file systems. By using networked file systems, users of Windows or UNIX can manipulate files as though they were stored on a local file system.

Less integrated methods exist to transport files between systems, such as the File Transfer Protocol (FTP) and removable media such as tapes or compact disks. These methods are not considered here because they do not provide close interoperability. However, removable media and FTP can be useful during the migration. Tapes are particularly effective for transferring volumes of data too large to feasibly move across the network.

Developers or application users should ideally be able to use the files they need in their local environment transparently, that is, they should not need to know whether the files are on a UNIX server or a Windows-based server. However, UNIX systems and Windows-based systems use different network protocols, functionality, and naming conventions for file sharing, and so this can be challenging.

In Windows-based networks, the most common file-sharing protocol is Server Message Block (SMB), also known as the Common Internet File System (CIFS). In this document SMB and CIFS are used interchangeably. The most common network file system on UNIX systems is called, simply, the Network File System (NFS). NFS and CIFS protocols are not compatible.

The following sections review the file-sharing environments in UNIX and Windows and the options for providing interoperability.

UNIX Data Sharing Environment

The network file system (NFS) protocol is a UNIX-style file system that can be shared over the network. NFS uses UNIX user identification, group identification, and permissions.

NFS uses the export naming convention, in which an exported file system is referred to by the host name and the export name. For example,

server:/usr/local/pub

where server is the host name and /usr/local/pub is the export name.

An NFS client mounts the NFS export into its file system tree just as it mounts any other file system, such as one on a local disk drive. To the user, the network file system looks like another directory under the root of the file system (/).

The mount command can be used to connect to an NFS file system. Such a command might look like this:

mount t nfs server:/usr/local/pub /pub

NFS is used in many ways in UNIX environments. Servers can share common data by using NFS. Desktops or workstations can streamline administration by centralizing user data on an NFS server.

Windows Data Sharing Environment

CIFS was designed to integrate transparently into Windows operating systems. It uses Windows security to control access to resources, including the SIDs, Access Tokens, and DACLs already described. Available networked file systems are called shares.

A Universal Naming Convention (UNC) name identifies the networked file. The UNC name consists of a server name and a share name, for example; \\SERVER\SHARE.

On a client, a share can be accessed directly with these UNC names. Alternatively, it can be mapped to a drive letter in the same way as a disk partition or floppy disk. For example, the path X:, could be mapped to the UNC name above. Drive letters can be mapped in a number of ways. The most basic way is to use the command line utility net use. For example:

net use X: \\SERVER\SHARE

Windows also provides Browser Services, which compiles a list of all the servers in the Windows environment with the shares on them. Users can navigate this hierarchy with the Explorer program, just as they would navigate their local disk drives.

File-naming conventions and other features of the networked file system are the same as for other Windows file systems.

As in UNIX with NIS, desktop clients can thus store all their data on a centralized server, which simplifies administration.

Network File System Interoperability

The Windows and UNIX networked file systems are incompatible, but there are three ways in which they can interoperate:

• Using a service installed on the file server. For example, Samba can be installed on a UNIX server to make it appear to be a Windows server, or an NFS server can be installed on a Windows server.

• Using a client on the workstation computers. For example, an NFS client can be installed on a Windows 2000 Professional computer to allow it to access the NFS UNIX servers.

• Using a gateway. This could be a Windows server with a service installed on it that allows Windows clients to access the UNIX NFS shared file system through it. No extra software must be installed on the Windows clients or the UNIX server. Gateway schemes place significant load on the gateway server, which must translate between the protocols. Although they are relatively easy to configure, they are usually less scalable than the previous approaches for this reason.

The scheme you choose may be influenced by the order of your CATIA migration. For example, if you plan to migrate the data to Windows file server before migrating the application itself, UNIX users will need regular access to those servers during the migration. You might consider installing an NFS server on the Windows computers to facilitate this, or a CIFS client on the UNIX desktops.

For interoperability, network file system software must provide some basic functionality:

• It must provide connectivity between the network client and the file server.

• It must translate between opposing environments.

• It must provide for security mapping between the two systems (for more information, see the "User Authentication and Authorization" section earlier in this chapter).

• It must convert file system features between UNIX and Windows; for example, links and file locking.

File sharing between UNIX and Windows-based systems can be implemented in many ways. Figure 8.4 provides an overview of the options. Each of the interoperability solutions can be implemented either on a UNIX platform or on a Windows platform.

The following combinations are commonly used:

• A UNIX server provides CIFS file shares to Windows clients via Samba and NFS file shares to UNIX clients.

• A UNIX server provides NFS file shares to both Windows and UNIX clients. The Windows clients must have a NFS client, such as that provided with Microsoft Services for UNIX 3.0, installed locally.

• A Windows-based server provides CIFS file shares to Windows clients and NFS file shares to UNIX clients via a NFS server for Windows. Such a NFS server is provided with Microsoft Services for UNIX 3.0.

• A Windows-based server provides CIFS file shares to Windows and UNIX clients. The UNIX clients must have a CIFS client installed locally.

  

  Figure 8.4: File-sharing options for UNIX and Windows

NFS for Data Sharing

If you have elected to use the NFS protocol to share files between UNIX and Windows, NFS software must be running on the Windows-based server or client or an NFS gateway must exist to convert an NFS export into a Windows share.

One system must be the NFS file server and the other must be the client. Often, because it probably already runs NFS, the UNIX side becomes the server. In this case, the Windows-based client computer must run an NFS client program.

If files must be shared from a Windows-based server to UNIX clients, then it is easiest to set up the Windows-based system as the NFS file server. The Windows-based server needs to run NFS server software.

NFS software products for Windows, including clients and servers, are available from Microsoft and others. The next sections discuss these products.

Microsoft Services for UNIX

Microsoft Services for UNIX provide the tools needed to set up sharing between UNIX and Windows-based systems. In addition to shells and command line tools, Microsoft Services for UNIX delivers a server and a client for NFS and an NFS gateway. In addition, Microsoft Services for UNIX delivers User Name Mapping, which allows NFS access via the users Windows credentials.

The most straightforward way to set up NFS sharing is to install an NFS client on each Windows client computer that needs access to NFS shares. By using the NFS client, users have access to files saved on NFS shares just as they have access to files on Windows-based servers. The same mechanisms used to map drive letters to Windows shares can be used with NFS shares. The share can be assigned a drive letter or the client can access the share by using an UNC name. After the share is accessed, users have normal access to the files.

Authentication and Permissions

The Microsoft Services for UNIX NFS system uses User Name Mapping to authenticate the user to the server, whether or not the names match on both systems. Actual name mapping makes it possible to set up different schemes for allowing access to the NFS shares.

Note that UNIX user names are case sensitive and Windows user names are not. Name mapping can handle this discrepancy by mapping names with uppercase letters to the UNIX convention of all lowercase letters. However, if your UNIX user names do not conform to this convention, this issue may cause trouble.

When Microsoft Services for UNIX NFS client software is being used to provide file-sharing integration, each workstation client uses its native authentication protocol: Windows NTLM and Kerberos for the Windows-based workstation user and NIS for the UNIX workstation user. However the Microsoft Services for UNIX NFS Client uses the Microsoft Services for UNIX User Name Mapping Server to map the authenticated Windows user to a corresponding UNIX user name using the user SID. It obtains the UID and GID to use for authorization (for example, file access permissions) in an NFS request to the NFS server.

Microsoft Services for UNIX Gateway for NFS

Gateway for NFS is another Microsoft Services for UNIX feature. In this case, the gateway computer, which runs Windows, communicates with the client computers by using the usual Windows file-sharing protocol: CIFS. This eliminates the need to install the NFS client software on each client.

However, the best environment in which to use the gateway has a limited number of NFS shares that need to be available to the Windows clients. The server makes shares available as though they were shares on the gateway computer. Each share must be mapped to an available drive letter on the gateway computer. It is possible to use more than one gateway computer, but any single gateway computer is limited by the number of available drive letters.

Hummingbird NFS

The Hummingbird NFS Maestro suite offers NFS solutions similar to those in Microsoft Services for UNIX. NFS Maestro includes an NFS client package, an NFS server, and an NFS gateway product. The NFS Maestro gateway also eliminates the need to install NFS client software on each client computer.

For more information, see Host Access and Network Connectivity on the Hummingbird Web site at https://www.hummingbird.com

WRQ Reflection

WRQ Reflection products also deliver NFS functionality for Windows computers. The WRQ Reflection NFS Client offers client functionality, and WRQ Reflection Suite for X contains the NFS client, X Windows capabilities, and connectivity to UNIX and mainframe systems.

For more information, see the WRQ Web site at https://www.wrq.com

Microsoft Windows Powered NAS Solution

Windows Powered Network Attached Storage (NAS) is a product designed specifically for file serving. It is intended to be simple to configure, stable, scalable, easy to administer, and flexible in different file serving situations.

Preconfigured Windows Powered NAS solutions are available from third parties. These include all the hardware and software required to roll out an efficient file server or system of servers in a very short time. By running such a locked-down version of Windows 2000, the more complex setup required for general purpose servers is eliminated. This allows Windows Powered NAS appliances to be quickly configured and integrated into an existing Windows 2000 infrastructure.

Windows Powered NAS supports standard TCP/IP connections and provides access to a full range of file sharing protocols including the CIFS, NFS, Netware Core Protocol (NCP), Apple Talk, File Transfer Protocol (FTP), and Web-based Distributed Authoring and Versioning (WebDAV).

The support for CIFS and NFS is of prime importance for a CATIA migration from UNIX to Windows. This allows a single server, or set of servers, to be used for data storage throughout the migration, regardless of the clients operating systems. If you have decided to perform a local installation of CATIA on many client computers, perhaps using Group Policy as described in Chapter 3, you will need high performance file servers from which to download the setup files to CATIA workstations. Windows Powered NAS servers are ideal for this. See Chapter 3, "CATIA Local Installation" for a full discussion.

Windows Powered NAS, however, should not be thought of as a tool useful exclusively during the migration. Once this is over, the high availability, optimized performance, advanced backup and restore, replication, and ease of use become highly advantageous, particularly for large systems with large amounts of CATIA data and large numbers of users distributed over several sites. The low cost per megabyte of storage space is also attractive.

Why Windows Powered NAS?

The following table summarizes the business needs solved by a Windows Powered NAS solution:

Table 6.1 Windows Powered NAS and Business Needs

Technical scenario	Business Need	Why Windows Powered NAS
File Serving	Low TCO High availability High reliability Ease of management Integration into existing infrastructure	Optimized for File Serving No overhead of running applications Replace multiple GP servers used for file serving with single solution
Backup/Restore and Replication	Business continuity - Disaster recovery - Availability of data	Backup without taking servers offline Geographic replication
Server Consolidation	Optimize IT resources - Lower touch points - High availability - Reduce admin costs	Low $/MB Consolidate multiple file servers More data per server per admin

Active Directory-Based Deployment Scenarios

Here are three real-world scenarios that illustrate how Windows Powered NAS appliances can be deployed within an Active Directory infrastructure and use specific Windows 2000 services to create robust enterprise storage solutions. Each scenario has different priorities; in the first scalability and availability, in the second security, and in the third disaster recovery.

In your CATIA implementation your priorities may be similar to one of these, a combination of them, or entirely different. The scenarios are intended as illustrations of common implementations:

1. Deploying Windows Powered NAS Appliances for High Availability and High Performance File Services

   Company ABC has deployed an Active Directory infrastructure and wants to reduce software installation and configuration management costs through an automated process. In order to configure 20,000 Windows 2000 clients distributed across five locations, applications will be deployed using Group Policy software installation and the Windows Installer technology. All of the software distribution points will be hosted on Windows Powered NAS appliances. The set of applications distributed includes CATIA installed locally.

   In order to minimize wide area network (WAN) traffic, Company ABC wants client computers to find the closest NAS appliance to use as the software distribution share. In addition, Company ABC would like to reduce software deployment complexity by deploying software anywhere in their infrastructure using a single UNC mapping. With Windows Powered NAS appliances, Active Directory, DFS, and File Replication Services (FRS), Company ABC can create a highly available software distribution system that will meet these criteria.

   Implementing Domain-based DFS

   Company ABC begins by deploying a new Windows Powered NAS appliance in the company headquarters.

   The DFS namespace will be configured as follows:

   \\CompanyABC\Files\Software-->\\NASServerHQ1\Software

   A newly installed Windows Powered NAS appliance will provide the company headquarters location with Group Policy based software installation. The use of DFS will enable installation of software anywhere in the world using the common \\CompanyABC \Files\Software UNC mapping.

   While this configuration will provide local software installation for the company headquarters clients, it still does not meet the requirement for local software installation at the four remote locations. At this stage, if users in the remote locations attempt to install software, the installation process would occur over the WAN and the bandwidth utilization could affect critical business processes.

   In order to allow clients to install software locally using the common UNC, \\Company ABC \Files\Software, a Windows powered NAS appliance will be deployed at each of the remote locations and host a DFS link replica of the \Software share that is synchronized using File Replication Service (FRS) replication.

   The DFS namespace hierarchy would then look like:

   \\CompanyABC\Files\Software -->\\NASServerHQ1\Software

   -->\\NASServerRL1\Software

   -->\\NASServerRL2\Software

   -->\\NASServerRL3\Software

   -->\\NASServerRL4\Software

   NASServerRL1 through NASServerRL4 will hold an exact copy of the \Software share on NASServerHQ1. When a client in a remote site requests installation of software using the \\CompanyABC\Files\Software UNC mapping, they will be referred to the DFS server located at their remote location and the software will be installed using the LAN. If a remote location DFS server happens to be unavailable due to system maintenance or component failure, a client initiating a software installation would be automatically and transparently referred to another DFS server. The client would not be aware of or be affected by this type of event.

   FRS will take care of reliably and efficiently replicating the package to the Windows Powered NAS appliances in the other sites.

   After six months, Company ABC grows by 75 percent at one of the four remote locations. Because of the growth, clients at this location have started to experience slower software installation performance. The IT organization wants to improve the client software installation experience without incurring additional management costs.

   Company ABC decides to use the automatic load balancing features of DFS by deploying two more replicas of the \Software share at the remote location that experiences the problem.

   Adding two new NAS appliances to distribute the load, the DFS namespace will reflect the following:

   \\CompanyABC\Files\Software-->\\NASServerHQ1\Software

   -->\\NASServerRL1\Software

   -->\\NASServerRL2\Software

   -->\\NASServerRL3\Software

   -->\\NASServerRL3A\Software

   -->\\NASServerRL3B\Software

   -->\\NASServerRL4\Software

   With the deployment of the two new Windows Powered NAS appliances, clients at the remote location still use the common UNC, \\CompanyABC\Files\Software, to access any available software installation point. The two new replicas added to the existing replica set will synchronize their content through FRS. DFS will transparently allocate client requests in this site to the underlying shared folders on \\NASServerRL3 through \\NASServerRL3B, providing a degree of load balancing across the NAS appliances.

2. Deploying Windows Powered NAS Appliances for Highly Secure File Services

   Company XYZ relies heavily on proprietary financial data to provide services to its customers. Loss or theft of this financial data could translate into the loss of millions of dollars of revenue.

   Although this scenario concentrates on financial data, your engineering and design data, including CATIA files, may have similar sensitivity. You may wish to protect your investment against industrial espionage, for example.

   Company XYZ has deployed a Windows 2000 Active Directory infrastructure that allows their mobile work force to upload the financial data from their notebooks to Windows Powered NAS appliances on the corporate network on a daily basis. In order to maximize the protection of the financial data, Company XYZ has decided to implement a secure enterprise file storage infrastructure based on the following criteria:

   • Encryption of the data on the notebooks to prevent data being compromised if the notebooks are lost or stolen.

   • Encryption of the data on the Windows Powered NAS appliances to prevent data being compromised if an intruder gains access into the enterprise network.

   • Encryption of data flowing across the network between client notebooks and Windows Powered NAS appliances to prevent data being compromised during transfer.

   • A centralized management solution.

   • Smart cards for all authentication requirements.

   Using a combination of Windows 2000 Active Directory, Group Policy, Encrypted File System (EFS), IP Security Protocol (IPSec), and Windows Powered NAS devices, Company XYZ can achieve an integrated solution based on the standard Kerberos v5 authentication protocol or certificates.

   Implementing EFS to Encrypt Client and Server Data

   The Encrypted File System (EFS) is built on top of NTFS to store encrypted files on file system volumes. Encryption is transparent to the user that encrypted the file and a file does not have to be manually decrypted before it can be used. Files can be opened and modified without any special action being taken by the file owner. Using EFS services, Windows Powered NAS appliances can provide encrypted data storage on a user-by-user basis.

   An unauthorized user who gains physical access to encrypted files or folders will be prevented from reading them. If the intruder tries to open or copy an encrypted file or folder, an access denied message will be displayed.

   Encryption and decryption of files and folders is configured by setting an encryption property similar to other file and folder attributes such as read-only, compressed, or hidden. If a folder is encrypted, all files and subfolders created in the encrypted folder are automatically encrypted.

   Files and folders may be encrypted on standalone or domain member computers. Recovery agent user accounts are required to recover encrypted files and folders that can no longer be accessed by the file owner. For a standalone computer, the local administrator is the default recovery agent, but you can designate other local accounts as recovery agents. For computers that are a member of a domain, members of the Domain Admins group can designate recovery agents.

   If EFS will be used on an enterprise-wide scale, then all participating systems, including Windows Powered NAS appliances, should be members of an Active Directory domain. You can assign one or more recovery agent accounts to a set of computers within a domain by using Group Policy. Any of the designated recovery accounts can be used to recover users' files. EFS stores the recovery agent information for EFS recovery policy in Active Directory. This centralizes and simplifies the management of recovery agents for large numbers of enterprise systems, a task which would quickly become unmanageable for hundreds or thousands of standalone systems, each requiring management of individual recovery agents stored in Local Group Policy.

   By implementing EFS in an Active Directory environment, Company XYZ can ensure that data remains encrypted on both the company notebooks and Windows Powered NAS appliances that will provide file services. Without Active Directory integration, enterprise-wide recovery agents cannot be defined. Local computer accounts would have to be maintained and saved in an external store. If the external store was corrupted, the encrypted data stored on the standalone notebooks may not be recovered if the original file owner leaves the company or forgets their authentication credentials.

   By implementing EFS in an Active Directory environment, Windows 2000 domain accounts can be designated using Group Policy as recovery agents for all notebooks and Windows Powered NAS appliances in the domain. This allows recovery regardless of the state of any local computer account database and provides a centrally managed and fault tolerant solution as both the domain accounts and recovery agent Group Policy configuration information is stored in the Active Directory.

   For EFS to function correctly, the file owner must have a valid EFS user certificate, and the current EFS recovery policy must specify at least one valid recovery agent certificate. If available, EFS requests certificates from a Windows 2000 enterprise Certificate Authority (CA), but EFS does not require a CA to issue certificates. If an enterprise CA is not available, EFS automatically generates its own certificates to users and to default recovery agent accounts.

   EFS certificates that are self-signed are identified by Windows 2000 as "not trusted" because the certifying authority does not have a certificate in the Trusted Root Certification Authorities store. Nevertheless, self-signed EFS certificates are valid for use by EFS.

   Implementing IPSec for Data Transfers between Clients and Servers

   Windows Powered NAS appliances can also use the IPSec integrated in Windows 2000 to provide enhanced protection of network data flowing across enterprise networks.

   IPSec is a network protocol that was designed by the Internet Engineering Task Force (IETF) to provide IP packets with data authentication, integrity, confidentiality, and replay protection. IPSec is implemented at the IP Transport Layer, which enables a high level of protection for applications, services, and upper layer protocols such as TCP and UDP.

   IPSec negotiations between the source and destination systems require mutual authentication before the exchange of secured data. Windows 2000 IPSec provides multiple methods of authentication to ensure compatibility with legacy systems, non-Windows-based systems, and remote computers.

   In order to ensure that Company XYZ data remains encrypted during data transfers between client notebooks and Windows Powered NAS appliances, IPSec can be implemented in the Active Directory environment. The flexibility of IPSec can be utilized to assign different polices and levels of security for different computers and users. In addition, computers can be configured to accept or transmit data only if an IPSec secure channel can be established.

   The amount of configuration required to enable IPSec will be minimized by using the default Windows 2000 IPSec authentication method: Kerberos v5. This is also the standard authentication protocol used between Windows 2000 systems that are members of an Active Directory domain. Company XYZ selected Kerberos authentication and domain trusts to simplify the management of IPSec configuration. If required in the future, certificates or pre-shared keys can be used for non-trusted domains or third-party interoperability.

   To enforce the use of IPSec for all network communications between the company-owned notebooks and the Windows Powered NAS appliance without applying it to all other computers in the Active Directory domain, Company XYZ creates an organizational unit (OU) named Financial Systems that contains two child OUs: NAS and Notebooks. The NAS OU contains all appropriate Windows Powered NAS appliance computer objects. The Notebooks OU contains all appropriate notebook computer objects.

   A Group Policy is created and linked to the NAS OU that sets configuration parameters for IPSec policy to require security. This will require that all IP traffic between the Windows Powered NAS appliances and clients use IPSec to encrypt network data transfers and will not allow any unsecured communication with non-trusted clients.

   A second Group Policy is created and linked to the Notebooks OU that sets configuration parameters for IPSec policy to request security. This will allow computers in the Notebook OU to communicate normally with all other servers, but to use IPSec for network data transfers to the Windows Powered NAS appliances.

3. Deploying Windows Powered NAS Appliances for Business Continuance

   This scenario illustrates how NAS and DFS can be used to build a disaster recovery solution. Using commodity hardware and off-the-shelf software, a business continuance solution can be built at a fraction of the cost of other proprietary solutions. Apply these configurations to your CATIA system if you need to ensure that a major failure, resulting in data loss, disrupts the productivity of your design team as little as possible.

   Company RST has deployed Active Directory at three locationsone main datacenter and two regional datacenters. The company deploys large Windows Powered NAS systems in each datacenter to host data for users at that site. Each regional site has a domain controller replica. DFS is configured in such a way that each share on the NAS appliance in the regional datacenters has a replica in the main datacenter. DFS replicas in the main datacenter are set to the offline state to avoid users being directed to these data shares.

   In case of data loss at either of the regional datacenters, an administrator in the main datacenter can set the appropriate DFS target online in order to redirect clients to access the regional data stored at the main site.

   FRS takes care of replicating all files from the regional datacenters to the main datacenter. In case of a server going down, all users would be redirected to access data stored on the Windows Powered NAS appliance at the main datacenter. The main site would contain all files replicated up to the last replication cycle. The replication cycle can be adjusted to minimize data discrepancies. In any case, the customer can be back in business in the time required by an administrator at the main site to change the status of the DFS target to be online.

   The DFS namespace will be configured as follows:

   \\CompanyRST\Files\Data -->\\main\userdata1 (offline)

   -->\\main\userdata2 (offline)

   -->\\reg1\userdata1 (online)

   -->\\reg2\userdata2 (online)

   In day-to-day operations, users in the first regional datacenter are always directed to \\reg1\userdata1 to access their data. If the Windows Powered NAS server in this regional datacenter becomes unavailable, an administrator at the main site can bring online the data replica stored on \\main\userdata1. Clients from the regional site are automatically redirected to the data stored at the main datacenter.

Summary

In any migration from UNIX to Windows, including migrations to CATIA V5, the two operating systems must cooperate, even if it is only for a small period of time. In real-world situations, with complex systems and hundreds or thousands of users, the migration may take months to complete. You may also need to continue using UNIX long-term, as in situations where part of your user base continues to use CATIA V4 or you have other applications specific to UNIX. Thus the communication between UNIX and Windows is of great importance to those moving CATIA to Windows.

There are three main areas of interoperability:

• Connectivity. communications between UNIX and Windows for running commands or applications on the opposing operating system.

• Authentication and authorization. the identification of users for the purpose of controlling their level of access.

• Resource Sharing. the serving of files from Windows to UNIX, or from UNIX to Windows.

When selecting your interoperability solutions, you should pay close attention to the final system you are moving toward. For example, there seems little point in using a solution running on UNIX, if UNIX is to be phased out.

Disclaimer and Copyright Information

CATIA is a registered trademark of Dassault Systemes SA. The names of other actual companies and products mentioned herein may be the trademarks of their respective owners.