HP’s CIFS/9000 And Windows 2000 Interoperability Version 1.03, October 2002 Updates for version 1.03: * Page 27: “Pre-Windows 2000 Compatible Access” required Eric Roseme SNSL Advanced Technology Center E0300 Printed in: U.S.A.
CIFS/9000 and Windows 2000 Interoperability Legal Notices The information in this document is subject to change without notice. Hewlett-Packard makes no warranty of any kind with regard to this manual, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose.
CIFS/9000 and Windows 2000 Interoperability Contents Legal Notices .....................................................................................................................2 Contents ............................................................................................................................3 Chapter 1 Introduction ......................................................................................................5 Chapter 2 CIFS/9000 Overview...................................
CIFS/9000 and Windows 2000 Interoperability 7.4 CIFS/9000 and DFS................................................................................................. 43 7.4.1 CIFS/9000 Connection Sequence ..................................................................... 43 7.4.2 CIFS/9000 DFS Transaction Interoperation .................................................... 46 7.5 Windows 2000 DFS Features................................................................................... 46 7.
CIFS/9000 and Windows 2000 Interoperability Chapter 1 Introduction CIFS/9000 is HP’s Common Internet File System (SMB) distributed file system that runs on HP-UX 11. CIFS/9000 is HP’s strategic HP-UX and Windows interoperability platform, and is an important component of the HP Multi-OS platform proposition. As with most industry Windows interoperability products, CIFS/9000 is based upon Windows NT4.0 technology. Microsoft Windows is the dominant desktop platform.
CIFS/9000 and Windows 2000 Interoperability Chapter 2 CIFS/9000 Overview HP’s CIFS/9000 Server product is based upon Samba open source. CIFS/9000 Server is only supported on HP-UX 11 and newer releases. CIFS/9000 Server updates follow Samba open source updates as follows: • March 2000 HP-UX Application Release: Samba 2.0.6 • March 2001 HP-UX Application Release: Samba 2.0.7 • September 2001 HP-UX Application Release: Samba 2.0.
CIFS/9000 and Windows 2000 Interoperability In addition, because CIFS/9000 Server resides on the underlying UNIX operating system, UNIX security policy is enforced using account data that is stored on: • /etc/passwd • NIS • NIS+ • LDAP 2.1 Migration to Windows 2000 Because CIFS/9000 is based upon NT4.0 technology, in order to understand how it interoperates with Windows 2000 we must address NT4.0-to-Windows2000 migration principles.
CIFS/9000 and Windows 2000 Interoperability clients remains. This flexibility must be offset against the added benefits of enabling Native Mode. In Native Mode, a one-way transition is executed. Once the Native Mode switch has been enabled, there is no returning to Mixed Mode. It is a permanent, one-way change. The benefits are: the addition of Domain Local groups, Universal Groups, and grou p nesting.
CIFS/9000 and Windows 2000 Interoperability Chapter 3 W2000 Domain Mode: Mixed vs Native The initial foray into Windows 2000 is dominated by the decision: Mixed Mode or Native Mode? Before addressing this question, it is important to understand: • • • • • 3.
CIFS/9000 and Windows 2000 Interoperability Enable if: MIXED *Enable if: NATIVE What this screen actually does is to allow the built-in group Everyone to be nested under the built-in group “Pre-Windows 2000 Compatible Access Group.” This nesting is configured when choosing the option labeled “Permissions compatible with pre-Windows 2000 servers.” Nesting the Everyone group allows anonymous connections to domain resources. NT4.
CIFS/9000 and Windows 2000 Interoperability The Windows 2000 Domain Controller will be installed in Mixed Mode by default. To enable Native mode, go to the following screen in the “Active Directory Domains and Trusts” administrative tool: ONE WAY Choosing Native Mode is a one-way operation – there is no going back to Mixed Mode without a reinstall of Windows 2000 Advanced Server or restoring a back-up.
CIFS/9000 and Windows 2000 Interoperability 3.3 Domain Mode Effect Upon Feature Set The one-way nature of Native Mode configuration requires a clear understanding of the advantages and disadvantages of Native Mode and Mixed Mode. The following table illustrates the major differences: FEATURE MIXED NATIVE Support NT4.
CIFS/9000 and Windows 2000 Interoperability Native Mode also allows group conversions from one group type to another: • Between Security and Distribution Groups • Between Universal Groups and Global Groups • Between Universal Groups and Domain Local Groups 3.3.2 Dial-In Options Some Dial-In options are only available in Native Mode (see Q193897): • • • • • 3.3.
CIFS/9000 and Windows 2000 Interoperability SIDHistory and the accompanying tools are important elements that must be fully understood. Microsoft has provided many documents explaining SIDHistory in detail. If a new Windows 2000 domain is being designed, then SIDHistory’s Native Mode dependancy is not so important. Also, SIDHistory emphasis is directly related to usage of ACLs on domain resources.
CIFS/9000 and Windows 2000 Interoperability For CIFS/9000 Server interoperability in the Windows 2000 domain, the following functionality must be enabled when in Native Mode: • NetBIOS (see the Name Resolution module) • NLTM (see the Authentication module) • WINS (see the Name Resolution module) • Permissions compatible with pre-Windows 2000 servers It is essential that the effect of Mixed Mode versus Native Mode is fully understood upon all domain resources before designing the domain infrastructure.
CIFS/9000 and Windows 2000 Interoperability Chapter 4 Authentication: Kerberos and NTLM Authentication technology is a key feature of Windows 2000. The adoption of Kerberos as the default Windows authentication protocol is a primary differentiator from NT4.0 and a compelling motivation to upgrade. The NT4.0 authentication protocol is NTLM, and it is important to understand the benefits that Kerberos provides over NTLM so that the migration implications are fully understood.
CIFS/9000 and Windows 2000 Interoperability • Requires complex manual trust management for multi-domains like masterresource NTLM has a version 2 that includes a better encryption mechanism. NTLM v2 was delivered for NT4.0 in Service Pack 4. However, NTLM v2 requires editing of the client registry to enable, and it has not been widely adopted. 4.2 Windows 2000 and Kerberos The Windows 2000 default authentication protocol (from Windows 2000 Pro clients only) is Kerberos.
CIFS/9000 and Windows 2000 Interoperability • 4.3.1 Windows 2000 client in a Native Mode Windows 2000 domain NT4.0 Client in an NT4.0 Domain Discovery Discovery Reply 14-Char Encrypted password NT4.0 Client SID NT4.0 Server CIFS/9000 Server This is the standard NT4.0 client authentication procedure. The Network Monitor trace shows that the ROS87252OLK NT4.0 client negotiates the authentication protocol with the NT4.0 server by presenting the NTLM 0.
CIFS/9000 and Windows 2000 Interoperability protocol to the server in packet number 11. The SNSLATC-NT NT4.0 server replies in packet number 12 that Dialect #5 (the expanded SMB shows dialect #5 to be NTLM 0.12) is accepted as the protocol. After the client is authenticated, it maps a network drive on the CIFS/9000 Server that is a member of the NT4.0 domain: NT4.0 Client Pro toc ol Ma pD riv e NT4.
CIFS/9000 and Windows 2000 Interoperability Client to CIFS/9000 Server CIFS/9000 Server to NT4.0 PDC The Nt4.0 client ROS87252OLK begins the protocol negotiation with the CIFS/9000 Server in packet 87. The CIFS/9000 Server confirms the NTLM v1 authentication protocol in packet 88. The CIFS/9000 Server then begins the pass-through authentication request to the NT4.0 PDC or BDC by negotiating the protocol with the NT4.0 server in packet 94. The NT4.0 server confirms the NTLM v1 protocol in packet 95.
CIFS/9000 and Windows 2000 Interoperability 4.3.2 Windows 2000 Client Logon with Kerberos: Mixed or Native DNS Query DNS Reply Request Secure Connection Secure Connection Reply W2000 Client Kerberos (TGT, TGS, Service) W2000 Server Kerberos Replies CIFS/9000 Server This is the Windows 2000 Pro client logon procedure. After finding the domain controller by DNS lookup and establishing a secure connection with MSRPCs (Microsoft Remote Procedure Calls), the client will request domain authentication.
CIFS/9000 and Windows 2000 Interoperability 4.3.
CIFS/9000 and Windows 2000 Interoperability Client to CIFS/9000 Server CIFS/9000 Server to W2000 DC 1. 2. 3. 4. Packet 108: The Windows 2000 Pro client ROS87208ERIC proposes NTLM v1 to the CIFS/9000 member server EMONSTER Packet 109: The CIFS/9000 Server EMONSTER confirms NTLM v1 Packet 124: The CIFS/9000 member server EMONSTER proposes NTLM v1 to the Windows 2000 domain controller ROS87252OLK Packet 125: The Windows 2000 domain controller ROS87252OLK confirms NTLM v1.
CIFS/9000 and Windows 2000 Interoperability NATIVE MODE W2000 Client Ma p W2000 Server Dr Pro ive toc ol N eg otia tion ru -Th on ati oti g Ne ol toc o r P ss Pa Co mp lete ply Re h t Au CIFS/9000 Server The mapping procedure between the Windows 2000 client, the CIFS/9000 Server, and the Windows 2000 Domain Controller is functionally the same in a Native Mode domain as it is in a Mixed Mode domain or an NT4.0 domain.
CIFS/9000 and Windows 2000 Interoperability The Network Monitor trace shows that the Native Mode protocol authentication exchange is the same as Mixed Mode: 1. Packet 16: The Windows 2000 Pro client ROS87208ERIC proposes NTLM v1 to the CIFS/9000 member server EMONSTER 2. Packet 17: The CIFS/9000 Server EMONSTER confirms NTLM v1 3. Packet 32: The CIFS/9000 member server EMONSTER proposes NTLM v1 to the Windows 2000 domain controller ROS87252OLK 4.
CIFS/9000 and Windows 2000 Interoperability Kerberos pass-through authentication for the CIFS/9000 Server is currently under investigation.
CIFS/9000 and Windows 2000 Interoperability Chapter 5 Active Directory Integration Active Directory is the flagship of Microsoft’s Windows 2000 product. Although Active Directory actually refers to the directory services and LDAP portion of the server feature set, ADS incorporates a colossal assortment of client and domain management utilities.
CIFS/9000 and Windows 2000 Interoperability This operation creates an object in the Active Directory for the CIFS/9000 server. 5.2 Windows 2000 and CIFS/9000 Account Interoperability Windows 2000 file system security is based upon NTFS file system attributes. User and group permissions are set and enforced by the usage of user and group Security Identifiers (SIDs) on Access Control Entries (ACEs) that are contained on Access Control Lists (ACLs).
CIFS/9000 and Windows 2000 Interoperability …or the separate account databases can be combined onto the Windows 2000 ADS using HP’s Unified Login capability. 5.3 Unified Login Unified Login is officially known as “Integrating HP-UX Account Management and Authentication with Microsoft Windows 2000 Active Directory” at http://www.docs.hp.com/hpux/internet/index.html. Unified Login is an acceptable abbreviation.
CIFS/9000 and Windows 2000 Interoperability • Web Server 1. Web user access secure page 2. Look up account data (etc\passwd or NIS/LDAP server) 5.3.2 Unified Login Scenario HP-UX Aut hen tica te Client •Windows •HP-UX • • • Acco unt L ooku p hare er \s v r e \\S Map CIFS Server Telnet hostname Unix Server Auth/Acct Lookup Web Server kup t Loo /Acc h t u A http ://se rver .com Active Directory Username •SID •UID •GID CIFS/9000 Share Map 1. Authenticate to W2000 domain controller (ADS) 2.
CIFS/9000 and Windows 2000 Interoperability 5.3.3 User and Group Management The Active Directory schema changes are most visible through the management interfaces. The SFU modifications include modifying the admin “snap-ins” to accommodate the POSIX attributes. 5.3.3.1 1. 2. 3.
CIFS/9000 and Windows 2000 Interoperability A user properties screen from the extended schema shows the following modifications: • UNIX Attributes tab • UID • Login Shell • Group membership list These attributes are on the same user principal as the Windows user attributes, and they use the same password field. There are not dual records – just more data for the same user. 5.3.3.3 1. 2. 3.
CIFS/9000 and Windows 2000 Interoperability A group properties screen from the extended schema shows the following attributes: • UNIX Attributes tab • UNIX Group ID • UNIX group members 5.4 CIFS/9000 Access Control Lists Windows 2000 resides on the Microsoft Windows NTFS file system, and utilizes NTFS ACLs. CIFS/9000 preferably resides on the JFS 3.3 file system, and utilizes POSIX ACLs.
CIFS/9000 and Windows 2000 Interoperability the same user name in 2 different attributes in the schema: UserPrincipalName and mssfuname. Changing only the Windows user name will cause the 2 name fields to be out of sync. Both name fields must be changed. 5.6 Active Directory Integration: CIFS/9000 Interoperability The standard HP-UX account administration for CIFS/9000 utilizes the native UNIX account management utilities like /etc/passwd or NIS.
CIFS/9000 and Windows 2000 Interoperability Chapter 6 Name Address Resolution The convergence of Windows 2000, CIFS/9000, and HP-UX in a single operating environment combines three different methods of resolving names to addresses: • • • NetBIOS/WINS (NT4.
CIFS/9000 and Windows 2000 Interoperability CIFS/9000 starts a single nmbd daemon on the system to listen on port 137 for all incoming NetBIOS name service requests. While the number of smbd daemons on the system equates to the number of client connections to the server, the nmbd always stays at 1 daemon per server. The third most important rule to remember when integrating CIFS/9000 Server with Windows 2000 is that Windows 2000 enables NetBIOS by default.
CIFS/9000 and Windows 2000 Interoperability DNS is based upon a hierarchical namespace (represented by the dots in the names) that is much more powerful and flexible than NetBIOS, and is designed to be distributed. Additionally, DNS is implemented with the TCP transport protocol as opposed to UDP, so it is a more network-efficient naming mechanism. BIND is traditionally considered the “gold standard” of domain name resolution.
CIFS/9000 and Windows 2000 Interoperability Do not disable NetBIOS and WINS when a CIFS/9000 member server is part of the domain. So Microsoft chose to call Windows 2000 DNS “dynamic”, but the integration aspect into the Active Directory is probably the single most effective feature of DDNS. By integrating it into ADS, the replication of DNS servers is handled automatically by the ADS, and there is no requirement to manually configure DNS server distribution.
CIFS/9000 and Windows 2000 Interoperability 6.4 Name Address Resolution: CIFS/9000 Interoperability When designing a windows 2000 domain, the DNS design has a profound effect upon the overall ADS design. Both should be considered during the initial Windows 2000 ADS design phase. The integration of CIFS/9000 into the Windows 2000 domain often implies the pre-existence of HP-UX in the enterprise.
CIFS/9000 and Windows 2000 Interoperability • • 6.4.
CIFS/9000 and Windows 2000 Interoperability Chapter 7 Windows 2000 DFS DFS represents Distributed File System. Microsoft DFS refers to the ability to combine multiple servers and/or shares into a common namespace. Be aware that the industry common definition of DFS refers to OSF DCE/DFS, which is a very robust distributed file system used primarily in technical UNIX environments. Windows 2000 DFS bears no relation to OSF DCE/DFS. The key feature of Windows 2000 DFS is referrals.
CIFS/9000 and Windows 2000 Interoperability 7.2 DFS Namespace Compare the standard namespace with the same data consolidated into a single DFS namespace: The red arrows point to: • • • • The single DFS root share (dfshpact) Single namespace (dfshpatc) 3 remote file servers (DOM1DC,EMONSTER, HPATCUX1) 1 local filesystem (local to the root share) The single DFS namespace can be exported to, and mounted by, any authenticated client. 7.
CIFS/9000 and Windows 2000 Interoperability Map Root Share Query for DFSLink Path Not Covered W2000 Client Get Referral W2000 Server Referral Response Pro toc ol Ma pD rive ss Pa ru -Th on ati oti g Ne ply ol Re oc t h t o u Pr Ne go tia tion Co mp lete A CIFS/9000 Server • • • • • • 7.4 The client maps the root share (single namespace) The client user clicks on a subdirectory, which is really a DFSLink.
CIFS/9000 and Windows 2000 Interoperability 7.4.1.1 DFS Query The client queries the DFS root server for the sharename that actually resides on a CIFS/9000 server 7.4.1.
CIFS/9000 and Windows 2000 Interoperability 7.4.1.3 DFS Referral Request The client requests a referral to a DFS “Leaf Node” 7.4.1.4 DFS Referral Reply The DFS Root server replies with the CIFS/9000 server and share name The client now has the actual server name and share name where the DFSLink actually resides, and will send a map request to the server – in this case, a CIFS/9000 server.
CIFS/9000 and Windows 2000 Interoperability 7.4.2 CIFS/9000 DFS Transaction Interoperation The DFSLink (or leaf node) is not cognizant of the exchange between the DFSRoot and the client – the transaction appears to be a standard share map just like any other. Therefore, the CIFS/9000 server can operate as a DFSLink with no special modifications or enhancements. However, Windows 2000 DFS has numerous extra features, some of which are dependent upon Windows-specific technology. 7.
CIFS/9000 and Windows 2000 Interoperability The DFS administration tool resides on the ADS server. If the DFS root is a standalone server, then it must be administered on that server. If the DFS root is on ADS, then it can be administered on any DC in the domain.
CIFS/9000 and Windows 2000 Interoperability Chapter 8 Summary: CIFS/9000 and Windows 2000 Interoperability CIFS/9000 Server is based upon NT4.0 technology. CIFS/9000 Server integration within a Windows 2000 domain is simplified to a large degree by the member server status of CIFS/9000. As a member server, CIFS/9000 simply handles file storage within a domain. The complicated client management features of Windows 2000 must be handled by domain controllers that carry a copy of the Active Directory.
CIFS/9000 and Windows 2000 Interoperability Appendix A UPN Logon Name Windows 2000 Pro clients can logon to a domain in a number of different ways: • SAM logon o Security Account Manager • FQDN logon o Fully Qualified Domain Name • UPN logon o User Principal Name A.1 Security Account Manager Logon Name The SAM logon name is the default NT4.0 style logon method. The user enters a user name and then selects a domain from a pull-down menu on the dialog box: A.
CIFS/9000 and Windows 2000 Interoperability A.3 User Principal Logon Name The UPN logon name consists of a user name followed by an “@” sign, then a configured logon name. Instead of supplying the FQDN, the user supplies a name that has been configured on the Global Catalog, and the domain controller does a lookup on the Global Catalog to find the FQDN that is associated with the configured name. This is useful for standardizing user logons when there are multiple sub-domains in an organization.
