Posts Tagged ‘sbs 2008’

h1

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.

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

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

Virtualizing Microsoft Small Business Server 2008

February 23, 2009

Microsoft Small Business Server 2008 appears to be a good option for “Microsoft shops” looking to consolidated Active Directory Domain Controller, Windows Update Services, Security and Virus Protection, SharePoint and Exchange functions on a single server. In practice, however, it takes a really “big” server to support this application – even for a very small office environment.

According to Microsoft’s system requirements page a target system will need a 2GHz core, 4GB of RAM and 60GB of disk space to be viable (minimum). As with past experiences with Microsoft’s products, this “minimum system specification” is offered as a “use this only if you want to under-perform horribly as to be unusable” configuration.

In reality, a single-user, clean installation with two 2.3GHz cores and 4GB of RAM committed to the installation, the server struggles with the minimum amount of memory. The “real” minimum should have been specified as 6GB instead of the optimistic 4GB. Where does the memory go?

It appears that Microsoft Exchange-related memory utilization weighs in at over 1.2GB (including 600MB for “store.exe”). Another 1.2GB is consumed by IIS, SharePoint and SQL. Forefront Client Security-related memory usage is around 1GB all by itself. That’s 3.4GB of “application space” drag in Windows Small Business Server 2008. Granted, the “killer app” for SBS is Exchange 2007 and some might argue SharePoint integration as well, so the use of the term “drag” may not be appropriate. However, let’s just agree that 4GB is a ridiculously low (optimistic) minimum.