Solaris and Windows interoperability: using Solaris CIFS to share directories and to map identities

In an earlier post I described how easy is setting up CIFS and share Solaris directories with Windows clients. ZFS sharesmb properties, moreover, makes the process even easier: just set it to on, or to name=sharename to change the share's default name, and the job is done.

The next step in configuring your CIFS server is: how do you assign privileges to your user? Well, despite what you might be accustomed during your life with Samba, Solaris has been enhanced and now it supports Windows SIDs and Windows ACLs. As usual, Solaris documentation is the best place to look for information. In this post, I'll give you a brief introduction.

Let's suppose you completed the steps in the previous post and you did set up a share correctly. Right now, you'd be probably working on it from your Windows client. The first thing you could be noticing while inspecting the security permission of the shared folder is the following: your solaris user is listed and an unknown SID might be listed as well. What's that SID? Let's open a shell.

The Identity Mapping Service is a service whose purpose is just that: mapping identities between Solaris and Windows. You can dump the currently mapped identities with the command idmap dump -nv. The first thing you might want to do is mapping your user's default group into a Windows group. In this example I'll map the Solaris staff group into Windows' Administrator group:

$ idmap add wingroup:Administrators@BUILTIN unixgroup:staff

This is a bidirectional map which says both operating systems what corresponds to what. After logging in and out you can recheck your shares security permissions. In Solaris I have:

$ ls -adl software

drwxr-xr-x  14 enrico   staff         14 Aug 18 17:29 software

while on Windows I read:

Really easy, isn't it? The same way you can change permissions with Solaris ACLs, you can do it from Windows. The following directory has got the same permission set depicted in the previous figures:

$ ls -dV subversion/
drwxr-xr-x   2 enrico   staff          3 Feb 22 01:10 subversion/
                 owner@:--------------:-------:deny
                 owner@:rwxp---A-W-Co-:-------:allow
                 group@:-w-p----------:-------:deny
                 group@:r-x-----------:-------:allow
              everyone@:-w-p---A-W-Co-:-------:deny
              everyone@:r-x---a-R-c--s:-------:allow

Basically, it's a directory owned by enrico:staff, with a permission mask of 755 and no ACLs. Now let's add the SOLARIS\enrico user a couple of permissions: Delete subfolders and files and Delete. As soon as you do that, you'll find:

$ ls -dV subversion/
dr-xr-xr-x+  2 enrico   staff          3 Feb 22 01:10 subversion/
            group:staff:-w-p----------:-------:deny
              everyone@:-w-p---A-W-Co-:-------:deny
            user:enrico:rwxpdD-A-W-Cos:-------:allow
            group:staff:r-x----------s:-------:allow
              everyone@:r-x---a-R-c--s:-------:allow


That is: modifications done in Windows are correctly reflected on the Solaris side.

This is really the starting point. You can establish users and groups maps, you can set your Solaris ACLs and having them propagated to the Windows clients. In domain mode you can also rely on a directory service for identity mapping.

Happy interoperability!