• Sun
    November 10, 2008

Windows Features and Interoperability

Guest Author

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
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.

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.

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
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.

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

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.

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.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.