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.)
[caption id="attachment_1562" align="alignright" width="170" caption="Typical user and group permissions for a local hard disk in Windows."]
[/caption]
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 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":
[caption id="attachment_1568" align="aligncenter" width="300" caption="Applying administrative permissions with the AD group ID for Domain Admins."]
[/caption]
We do similarly with the Domain User gid:
[caption id="attachment_1569" align="aligncenter" width="300" caption="Applying the Domain User gid to CIFS share ACL."]
[/caption]
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 you 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
[/caption]