 |
|
Figure 1 is a high-level overview of the design architecture of the multi-platform option for IFS. Here, the concept is "optimize the common, and make the less common possible". That manifests itself into a separate and distinct file system for the PC and Macintosh clients. Since PCs and Macs share similar locking requirements of a networked file system (mandatory locking enforceable by the server), it should not be necessary to build a third, parallel filesystem for Macintosh clients. This will keep the complexity of the solution lower. The existing environment (access to AFS) will not be modified by this |
|
project. Unix clients will continue to use the AFS client to access AFS. Likewise, Macintosh clients will still rely on NetaTalk translators for access to AFS. PC clients will have the option of Samba translators or the AFS client provided for Win32. The addition of client software may be necessary on some platforms if access to the CIFS filesystem is desired. |
 |
| Figure 2 depicts the authentication and access of Windows 2000 clients to IFS, where CIFS will be served from a Windows 2000 server cluster. The Win2K file server cluster will be a member of the Win2K native domain, allowing Win2K clients to authenticate to the file space using Kerberos v5. Authorization to data will be handled via Microsoft's "extension" to the K5 protocol. The Privilege Attribute Certificate (PAC) will be included in the token that the MS-KDC offers the client in response to a service ticket request. The PAC is examined by the file servers and used to determine authorization. |
 |
| Figure 3 depicts the authentication and access of non-Windows 2000 clients to IFS, where CIFS will be served from a Windows 2000 server cluster. Here the clients will rely on NTLM v2 for authentication. Win9x clients can have the ability to negotiate NTLM v2 added by incorporating a piece of the Active Directory client (without it, they rely on the older and less secure LM protocol). Macintosh clients could be fitted with a client that allows them to also utilize NTLM and CIFS to authenticate and use the file space. Or, the Win2K servers can have the AppleTalk Services installed and serve |
|
AFP directly to Macintosh clients for authentication and access (though AFP is significantly less secure than NTLM). UNIX clients also would be able to access the CIFS space through a client. The Sharity client allows UNIX workstations to mount the CIFS space as it would an AFS or NFS mount. Linux, could also use samba to achieve the same goal with a little more compatibility since the Linux kernel has smbfs built in thanks to Andrew Tridgell and Linus Torvalds and other open source developers. Solaris could use the samba command-line ftp-style client to access the CIFS space if mounting the file system is not desirable. |
|
Current NAS implementations are limited to NT4-style authentication. They can participate in and be members of NT4-style domains, but as of yet, cannot support Active Directory and/or Kerberos 5. This limits an IFS solution built upon NAS by requiring NT4 domain services to be available for authentication. Two architectural possiblities exist to accomplish this. The NAS file servers can be joined to the existing NT4 "ND" (NTatND v2) domain, or it can join the W2K domain by allowing NTLM v2 authentication. |
 |
| Figure 4 depicts the authentication and access of Windows 2000 clients to IFS, where CIFS will be served by NAS as a member server to the NT4 domain. Since Kerberos 5 will not be negotiated as an authentication protocol by the NAS, Win2K clients will back down to NTLM v2. Domain authentication then follows with the NAS passing authentication thru to an NT4 domain controller which, in turn, passes authentication on to the W2K domain utilizing the domain trust relationship set up between them. |
 |
| Figure 5 depicts the authentication and access of non-Windows 2000 clients to IFS, where CIFS will be served by NAS as a member server to the NT4 domain. Domain authentication then follows with the NAS passing authentication thru to an NT4 domain controller. |
|
|
 |
| Figure 6 depicts the authentication and access of clients to IFS, where CIFS will be served by NAS as a member server to the W2K domain. Since Kerberos 5 will not be negotiated as an authentication protocol by the NAS, Win2K clients will back down to NTLM v2. Domain authentication then follows with the NAS passing authentication thru to a W2K domain controller which will emulate NT4-style authentication in a "multi-master" fasion. |
|
|
 |
 |