NexentaStor CIFS Shares with Active Directory Authentication

June 15, 2010

Sharing folders in NexentaStor is pretty easy in Workgroup mode, but Active Directory integration takes a few extra steps.  Unfortunately, it’s not (yet) as easy as point-and-click, but it doesn’t have to be too difficult either. (The following assumes/requires that the NexentaStor appliance has been correctly configured-in and joined-to Active Directory.)

Typical user and group permissions for a local hard disk in Windows.

Let’s examine the case where a domain admin group will have “Full Control” of the share, and “Everyone” will have read/execute permissions. This is a typical use case where a single share contains multiple user directories under administrative control. It’s the same configuration as local disks in a Windows environment. For our example, we’re going to mimic this setup using a CIFS share from a NexentaStor CE appliance and create the basic ACL to allow for Windows AD control.

For this process to work, we need to join the NexentaStor appliance to the Active Directory Domain. The best practice is to create the machine account in AD first, assign control user/group rights (if possible) and then attempt to join. It is IMPORTANT that the host name and DNS configuration of the NexentaStor appliance match domain norms, or things will come crashing to a halt pretty quickly.

That said, assuming that your DC is and your BDC is with a “short” domain of “SOLORI” and a FQDN of “SOLORI.MSFT” your NexentaStor’s name server configuration (Settings->Network->Name Servers) would look something like this:

This is important because the AD queries will pull service records from the configured domain name servers. If these point to an “Internet” DNS server, the AD entries may not be reflected in that server’s database and AD authentication (as well as join) will fail.

The other way the NexentaStor appliance knows what AD Domain to look into is by its own host name. For AD authentication to work properly, the NexentaStor host name must reflect the AD domain. For example, if the FQDN of your AD domain is “SOLORI.MSFT” then your domain name on the appliance would be configured like this (Appliance->Basic Settings->Domainname):

The next step is to create the machine account in AD using “Active Directory Users and Computers” administrator’s configuration tool. Find your domain folder and right-click “Computers” – select New->Computer from the menu and enter the computer name (no domain). The default user group assigned to administrative control should be Domain Admins. Since this works for our example, no changes are necessary so click “OK” to complete.

Now it’s time to join the AD domain from NexentaStor. Any user with permissions to join a machine to the domain will do. Armed with that information, drill down to Data Management->Shares->CIFS Server->Join AD/DNS Server and enter the AD/DNS server. AD server, AD user and user password into the configuration box:

If your permissions and credentials are good, your NexentaStor appliance is not now a member of your domain. As such, it can now identify AD users and groups by unique gid and uid data created from AD. This gid and uid information will be used to create our ACLs for the CIFS share.

To uncover the gid for the “Domain Admins” and “Domain Users” groups, we issue the following from the NexentaStor NMC (CLI):

nmc@san01:/$ idmap dump -n | grep "Domain Admins"
wingroup:Domain Admins@solori.msft     ==      gid:3036392745
nmc@san01:/$ idmap dump -n | grep “Domain Users”
wingroup:Domain Users@solori.msft     ==      gid:1238392562

Now we can construct a CIFS share (with anonymous read/write disabled) and apply the Domain Admin gid to an ACL – just click on the share, and then click “(+) Add Permissions for Group”:

Applying administrative permissions with the AD group ID for Domain Admins.

We do similarly with the Domain User gid:

Applying the Domain User gid to CIFS share ACL.

Note that the “Domain Users” group gets only “execute” and “read” permissions while the “Domain Admins” group gets full control – just like the local disk! Now, with CIFS sharing enabled and the ACL suited to our AD authentication, we can access the share from any domain machine provided our user is in the Domain Users or Admins group.

Administrators can now create “personal” folders and assign detailed user rights just as they would do with any shared storage device. The only trick is in creating the initial ACL for the CIFS share – as about – and you’ve successfully integrated your NexentaStor appliance into your AD domain.

NOTE: If you’re running Windows Server 2008 (or SBS 2008) as your AD controller, you will need to update the share mode prior to joining the domain using the following command (from root CLI):

# sharectl set -p lmauth_level=2 smb

NOTE: I’ve also noticed that, upon reboot of the appliance (i.e. after a major update of the kernel/modules) your ephemeral id mapping takes some time to populate during which time authentication failures to CIFS shares can fail. This appears to have something to do with the state of ephemeral-to-SID mapping after re-boot.

To enable the mapping of unresolvable SIDs, do the following:

$ svccfg -s idmap setprop config/unresolvable_sid_mapping = boolean: true
$ svcadm refresh idmap


  1. […] This post was mentioned on Twitter by Collin C MacMillan, Mike Horwath. Mike Horwath said: RT @nexenta: RT @solori: New blog post on CIFS shares with AD authentication using a NexentaStor appliance: http://bit.ly/9d4LPi […]


  2. I’ve been struggling with this AD authentication for a couple of weeks now. I was sure I was doing everything right. Is there as specific reason why you need to use the group and user IDs as opposed to the friendly names?

    The little note at the end, was what I was missing.
    # sharectl set -p lmauth_level=2 smb

    Great post, thanks for sharing!


    • The sharectl command is necessary if you are connecting to a Server 2008 domain controller. It also works for Server 2003, so I suggest setting it in the assumption that you will – at some point – migrate to Server 2008.

      I’ve also noticed that, upon reboot of the appliance (i.e. after a major update of the kernel/modules) your ephemeral id mapping takes some time to populate during which time authentication failures to CIFS shares can fail. This appears to have something to do with the state of ephemeral-to-SID mapping after re-boot.

      To enable the mapping of unresolvable SIDs, do the following:
      $ svccfg -s idmap setprop config/unresolvable_sid_mapping = boolean: true
      $ svcadm refresh idmap

      The purpose of the approach outlined herein was not to create a user-managed approach to CIFS shares within the NexentaStor appliance but and administrator-based approach. This means an administrator or admin group is always delegated the share from which they will need to manually extend rights to individual users or groups from within native Windows/AD tools.


    • Here’s a link to the OpenSolaris forum about the sharectl command and why it’s needed in Windows 2008:



  3. […] Authentication of CIFS shares on NexentaStor is AD-based; […]


  4. I’ve got my NexentaStor joined to my AD domain, but have a problem where the Domain Admins can’t *rename* folders they create in NexentaStor shares. Detailed description at , any help appreciated.


    • This happens when you’re too aggressive with inheritance on the NexentaStor side. The simplest permissions are likely best for your admin group:

      list_directory, read_data, add_file, write_data, add_subdirectory, append_data, write_xattr, execute, delete_child, write_attributes, delete, write_acl, write_owner

      Any other permission default (inheritance, etc.) need to be set from Windows unless you really know what you’re doing with ACLs. When admins create a folder they will be the owner of that folder but no additional groups or permissions will attach. Your admins need to add the Admin group (at the Windows folder level) to the newly created (sub) folders with the proper inheritance, etc. for child files/folders with that folder. Any other users or groups should be added at this step as well (along with inheritance, etc.)


  5. Great Tip! I have been looking all night for a resource on how to get this done properly. Unfortunately I’m still facing one issue. With two users on a network, both using the shares, I am unable to access a share created by another user and I cannot change anything they change. Even if both users are administrators. Any help on the correct ACL would be much appreciated.


    • Lane-

      It’s likely you’ve employed “inheritance” at the ZFS layer. You’ll want to avoid this (note example share has “inherit” unchecked.)

      Also, employ just the basic permissions at the share level, then manage the share from your Windows environment as needed, leaving the ZFS permissions alone. I typically grant appropriate “admin group” permissions to the share, and add user/group permissions as needed directly from the Windows file browser. This accomplishes the desired result in the minimum number of steps (and headaches).


      • Colin,

        When I created the share I did inherit the ACL as you recommend not to do. Unfortunately, I only found your blog after creating the share and encountering the problem. I’ve tried removing/adding the CIFS service to the share and resetting the ACL to defaults. Unfortunately this has no affect on the problem. Any ideas on how to fix this? If you do consulting on these types of issues then email me, I would like to retain your services for a quick fix.



  6. […] In-the-Lab: Default Rights on CIFS Shares December 6, 2010 Following-up on the last installment of managing CIFS shares, there has been a considerable number of questions as to how to establish domain user rights on the […]


  7. “Mike Horwath said: RT @nexenta: RT @solori: New blog post on CIFS shares with AD authentication using a NexentaStor appliance: http://bit.ly/9d4LPi […”
    Where I have been able to read about it?


  8. I’m getting the following error when trying to join to my AD domain using my account which has privilege to join on this particular computer object which was already created by the domain administrator:

    Mar 17 13:57:21 server smbd[3675]: [ID 232655 daemon.notice] ldap_modify: Insufficient access
    Mar 17 13:57:21 server smbd[3675]: [ID 702911 daemon.notice] Failed to modify the workstation trust account.
    Mar 17 13:57:21 server smbd[3675]: [ID 871254 daemon.error] smbd: failed joining domain.example.com (UNSUCCESSFUL)

    Why would this happen? What particular permissions do I need to join to the account? The permissions I’ve been given work for Windows, Linux, & Mac Servers. Any advice appreciated.


    • As illustrated in the blog, the following must be true for the NexentaStor appliance:

      1) host name MUST be in AD domain (i.e. san.mydomain.local)
      2) DNS configuration MUST point to AD DNS servers only (or bind secondaries)
      3) Machine account must be in AD prior to add and match configured host name
      4) User credentials for join must have host add authority
      5) If joining to Server 2008 AD, you MUST change the mode on NexentaStor to match (see blog notes)
      6) Appliance’s host name in AD DNS
      7) Appliance’s in-addr.arpa resolves in AD DNS

      If all of these things are correct, you may want to check your security settings.


  9. This post has been invaluable to me – thank you!

    However I’m having a problem – for some reason I can’t see the Domain Admins group – I’ve successfully joined to the domain on a 2008r2 server following most of your instructions, however when I run;

    # idmap dump -n | grep Domain

    I get;

    wingroup:Domain Users@solaris == gid:2147483652
    wingroup:Domain Users@domain.com.au == gid:2147483655

    And there is no Domain Admins group. The Domain Admins group appears on the 2008r2 server.

    If I do;

    # idmap dump -n

    I get;

    wingroup:Domain Users@solaris == gid:2147483652
    wingroup:Guests@BUILTIN == gid:2147483653
    wingroup:Administrators@BUILTIN == gid:2147483654
    winuser:auadmin@domain.com.au == uid:2147483650
    wingroup:Domain Users@domain.com.au == gid:2147483655
    winuser:Guest@solaris == uid:2147483649
    wingroup:Network == gid:2147483650
    wingroup:Authenticated Users == gid:2147483651

    (I took out the unix users that showed up)

    Also I appear to be missing a user that I’ve added to the domain which is in the group Domain Users.

    I can’t work out why I can only see some users and not others?

    The same machine is/was joined to a Workgroup previously of the same domain name – DOMAIN – however I couldn’t work out how to un-join, and just joined the AD domain – seemingly without a problem.

    I’m running SunOS 5.11 rather than NexetaStor however I believe that most of the commands are the same?

    Any help would be greatly appreciated!


    • Check you service logs and kernel logs for errors. Also, there are references to checking the domain join in the blog and supplemental links. As this post was for NexentaStor, not all processes will translate directly to Solaris 10, but assuming you have smb services installed correctly, NTP synch’d with the domain controller, DNS configured such that ONLY active directory servers are references, and the AD machine account created referencing your Solaris host as named locally (i.e. /etc/hosts has matching entry) you should be good. If you still need some pointers, have a look at the following links:


      It’s important to make sure the domain mode is correctly configured for 2008R2 as stated in the SOLORI blog, otherwise your going to have a tough go of it… Cheers!


  10. […] where the servers were Windows Server 2008 and running their native authentication mode. The fix was to change the “lmauth_level” to two (2) via the NMV or NMC (“sharectl set … and restart the service. If you have this issue, the giveaway kernel log entries are as […]


  11. “our NexentaStor appliance is not a member of your domain. ” – dont you mean “now” ?


Comments are closed.

%d bloggers like this: