Dealing with Windows SIDs in Solaris, part 2
By nico on Nov 07, 2007
As described in my first post on this subject, Solaris can now map SIDs to POSIX UIDs/GIDs and back, and it can store SIDs in ZFS. The identity models of Windows and Solaris are now unified, and the ACL model of ZFS has been extended. And we have a unified administration of SMB and NFS shares. Wow. I find this exciting, and not just because I've worked on parts of this story.
In this post I want to walk through the identity mapping facility's design. Next I'll talk about implementation, and then about how to use the facility.
Design of the Solaris ID mapping facility
The salient points of the design of the ID mapping facility are:
/var/idmap/idmap.db-- contains persistent name-based ID mapping
/var/run/idmap/idmap.db-- caches Windows name<->SID lookups, ID mappings and ephemeral ID allocations
- ephemeral ID mapping, where we dynamically allocate the next available UID or GID from the erstwhile negative uid_t/gid_t namespace (uid_t and gid_t are now unsigned), but we forget these mappings on reboot (see part 1 for more)
- name-based ID mapping, where the sysadmin provides rules for mapping Windows users and groups to Solaris users and groups; these rules use names and wildcards, not SIDs and UIDs/GIDs.
- idmap_reg() to register idmapd's door; besides a door fd argument there's a boolean that tells the kernel whether idmapd was unable to open/recover
- idmap_unreg(), which is called when idmapd exits cleanly
- allocids(), which allocates a number of ephemeral UIDs and GIDs for idmapd to use for dynamic ID allocation
I've run out of time. I'll cover implementation details next.