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 1.1.1.1 and your BDC is 1.1.1.2 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.

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

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.

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.

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

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.

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

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.

[…] 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 […]

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:

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.

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:

[…] 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 […]

Popular Posts

In Medio Stat Veritas

SOLORI's Take and Quick Take posts express my personal opinion unless explicitly attributed to other sources. Where possible, supporting facts are presented to properly frame and ground these opinions, however they are presented "AS-IS" without regard to warranty or promise: expressed or implied.

Comments are open to all registered users and may be edited for decorum. Spam is deleted with prejudice.