Monday Nov 10, 2008

Windows Features and Interoperability

Mike Shapiro and Bryan Cantrill have given a great overview of our new storage appliance, the Sun Storage Server 7xxx Series. I'm going to dive right in and give a summary of how our appliance fits into existing Windows environments, and explain what features we've created to help Windows administrators. Because our Sun Storage Server 7xxx series is built on top of Solaris, we're able to leverage many innovative Solaris technologies. The recent addition of a native Solaris CIFS server provides a new CIFS service tightly integrated with the Solaris kernel. This tight integration allows a richer set of functionality for CIFS clients, including seamless integration with NFSv4 clients.

Active Directory integration

Our storage appliance can join an Active Directory domain, which involves creating an account for that computer in the requisite location of the Active Directory database. Once that account has been established and the appliance has performed the necessary authentication, the appliance can query the Active Directory database for information about Windows users, groups, and other important objects. Because the appliance can join the Active Directory domain in this manner, no changes are needed to a customer's environment to support CIFS clients.

In addition to delegating client authentication to an Active Directory domain controller, the CIFS service can also operate in workgroup mode. A Windows workgroup is a collection of computers which authenticate users locally instead of storing user information in a centralized database like Active Directory or LDAP. We expect that workgroup mode will be used mainly for evaluation purposes, as any environment with more than about a dozen users would find workgroup mode extremely unwieldy.

Credential management

One of the goals of the Solaris CIFS project was to simplify how NFSv4 and CIFS clients access files concurrently. Because NFSv4 and CIFS clients use different tokens to represent the credentials of a user or group (UID/GIDs and SIDs, respectively), the underlying filesystem must have knowledge of both types of credentials to accurately allow and deny access. Existing solutions involve storing one type of credential, and then performing a translation of that credential to the other form. While this approach solves the problem of the disjoint sets of identities, it is brittle and has a large administrative burden.

When we set out to solve the problem of credential management and mapping more cleanly, Mike developed a plan to unify UID/GID and SID credentials on the ZFS filesystem. The resulting plan changed how access tokens were stored in the kernel and in ZFS, and allowed the identity mapping service to translate Windows credentials to Unix credentials and vice versa.

The identity mapping service maps Windows identities to Unix identities to allow CIFS and NFSv4 clients to share the same identity. If only CIFS or NFS clients are accessing a particular share, or if CIFS and NFS clients are accessing disjoint directories within a share, then no identity mapping configuration is necessary. If NFS and CIFS clients must share the same identity (i.e. if one employee wants to access her home directory over both protocols), then the identity mapping service needs to know how to correlate those two identities. When the identity mapping service sees a request for a user or group which is not already mapped, there are three methods of resolving that mapping: directory-based mapping, name-based mapping, and ephemeral mapping.

Directory-based identity mapping allows annotation of a user's object in both an LDAP and Active Directory database. The LDAP object is annotated with attributes about that user's Windows identity, and the AD object is annotated with information about that user's Unix identity. When the identity mapping service is configured to use directory-based mapping, the service will lookup these additional attributes in the corresponding directory, and create a mapping based on those attributes. The identity mapping service can be configured to use directory-based mapping in either direction: mapping from Windows to Unix ("AD-only"), Unix to Windows ("LDAP-only"), or both directions ("mixed"). This approach to identity mapping is the most scalable, as these attributes will only need to be created once per identity, and are stored in only one place for each mapping direction.

Name-based identity mapping uses various identity mapping rules which map users to other users. These identity mapping rules can either map a particular Windows user or groups to a particular Unix user or group, or can create more general mappings which map across all users or groups in an Active Directory domain. Again, this name-based mapping approach is only needed when NFS and CIFS clients share the same identity.

Finally, the identity mapping service falls back on ephemeral mapping if a mapping cannot be handled through directory-based or name-based mapping. An ephemeral mapping is a temporary mapping for a Windows user which is not persistent across reboots, but is stored persistently on disk. That is, when an appliance reboots, the same Windows user may map to a different ephemeral UID (UIDs above 2\^31 are reserved for ephemeral UIDs.), but that Windows user will have the same access to files as before the reboot. Because these ephemeral UIDs are transient and not static, NFS clients cannot use these same UIDs. However, ephemeral UIDs and GIDs are perfectly valid when defining permissions on shares, and you may see them occasionally in a share's ACL if the appliance cannot communicate with an Active Directory server.

I hope you've received a good overview of some of Windows features and how identities are managed to create a truly native interoperable environment. Once the identity mapping scheme has been established, NFSv4 and CIFS clients can access common files with no restrictions or limitations. In the future, I'll blog about some other interesting Windows features, including:

  • Our DTrace analytics system which can observe CIFS traffic like never before.
  • Our full support for NT ACLs and ACL inheritance.
  • Autohome shares, which are home directory shares created on-demand for all users.

The blog of Bill Pijewski, a member of the Fishworks engineering team.


« April 2014