The following is a summary detailing step-by-step how to setup Solaris 10 as an active directory integrated file server using Samba and ZFS. The following example comes from a production configuration on an x4500 and previously a similar configuration was used on a production Linux file server for three years. I will update this web site as I test my final configurations.

I make no promises/warranties regarding any of this information. The following information contains my opinions from my own experience with Solaris/Samba/ZFS. The following documentation is provided for educational purposes only and should be used at your own risk.

Solaris 10 08/07 w/ Samba 3.0.25a

If you are running this version of Samba your child domains will not work and you need to disable the zfsacl module or you will have issues.

Solaris 10 08/07 w/ Samba 3.0.28

So far I have not found any issues and everything seems to be working correctly with Windows XP, Macintosh 10.5/10.4 and Linux. UPDATE - Vista appears to have issues after the release of Vista SP1. I can access the share but as soon as I try to open a folder I get an access denied. If I open the share by ip address I can then open the folder (i.e \\123.123.123.50\Share instead of \\fs0\Share). This looks like an NTLMv2 issue caused by a PAC mismatch. Samba team reports that this is fixed in newer releases but I have not tested yet.

By default the Solaris kernel only allows a user to be a member of 32 groups. If you do not set this the default maximum will be 16 and if a user is over this amount he or she will be denied access to all share points. Unfortunately nesting groups does not cut down on this number since the system will still see the user as a member of each nested group. CAUTION - This will create NFS server incompatibilities.

Edit /etc/system and make sure there are no spaces after the = sign and everything is spelled correctly.

set ngroups_max=32

Note -If you make a mistake and your system fails to boot just boot interactively and point to /dev/null when it asks for the location of your /etc/system file.

Create the ntp file

cd /etc/inet

cp ntp.client ntp.conf

Edit the file taking out the multicast option and setting up your DC as the server to sync with.

# ident "@(#)ntp.client 1.3     00/07/17 SMI"
#
# /etc/inet/ntp.client
#
# An example file that could be copied over to /etc/inet/ntp.conf; it
# provides a configuration for a host that passively waits for a server
# to provide NTP packets on the ntp multicast net.
#

server <INSERT YOUR PDC EMULATOR AD DC IP ADDRESS>

#multicastclient 224.0.1.1

Start the xntpd service

svcadm enable network/ntp

For consistency I will rename the ipnodes file and link it to /etc/inet/hosts so I dont need to update two files

mv /etc/inet/ipnodes /etc/inet/ipnodes.old
ln -s /etc/inet/hosts /etc/inet/ipnodes

Edit the hosts file

vi /etc/inet/hosts

Setup host and alias entries for both of your DC's and for your system. The host entries for your DC's may not be completely necessary as long as you have DNS setup properly. I just always do this just in case.

#
# Internet host table
#
#
# Merged entries from ipnodes into hosts on
# Backup files saved in /etc/inet/ directory: hosts.premerge, ipnodes.premerge
#
127.0.0.1       localhost
::1     localhost

192.168.5.50     fs0  fs0.domain.local   loghost

# Network Domain Controllers
192.168.5.10     dc0  dc0.domain.local
192.168.5.11     dc1  dc1.domain.local
192.168.6.10      child-dc0  child-dc0.child.domain.local

Check your /etc/hostname.<INTERFACE> to make sure you have your IP or host name properly configured. If you are using a host name it must also be defined in /etc/inet/hosts

fs0

Check your /etc/defaultdomain and make sure that you have you active directory domain defined here (This must also correspond to what you have in /etc/inet/hosts)

domain.local

Make sure that /etc/resolv.conf contains nameserver entries for each of your Active Directory DNS servers as well as a domain and search field.

domain domain.local
search domain.local
nameserver 192.168.5.10
nameserver 192.168.5.11

WEIRDNESS - Not sure why but you need to create a keystore file otherwise you will get login errors when accessing your samba share via a host name (As of Solaris 08/07)

touch /etc/krb5/krb5.keytab

Setup your /etc/krb5/krb5.conf with your domain controllers

[libdefaults]
default_realm = DOMAIN.LOCAL
dns_lookup_realm = false
dns_lookup_kdc = false

[realms]
DOMAIN.LOCAL = {
kdc = dc0.domain.local:88
kdc = dc1.domain.local:88
default_domain = domain.local
        }

CHILD.DOMAIN.LOCAL = {
kdc = child-dc0.child.domain.local:88
default_domain = child.domain.local
}

[domain_realm]
        .domain.local = DOMAIN.LOCAL
        domain.local = DOMAIN.LOCAL
        .child.domain.local = CHILD.DOMAIN.LOCAL
        child.domain.local = CHILD.DOMAIN.LOCAL

[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log

kdc_rotate = {
# How often to rotate kdc.log. Logs will get rotated no more
# often than the period, and less often if the KDC is not used
# frequently.
period = 1d
# how many versions of kdc.log to keep around (kdc.log.0, kdc.log.1, ...)
versions = 10
}

[appdefaults]
kinit = {
renewable = true
forwardable= true
}

Test your file using kinit. No response is a good response, otherwise you will receive an error

kinit 
 This e-mail address is being protected from spam bots, you need JavaScript enabled to view it
 

Create a new /etc/sfw/smb.conf

# Logging
log level = 2
syslog only = no
max log size = 50
log file = /var/samba/log/%m.log

realm = domain.local
workgroup = DOMAIN
security = ADS
encrypt passwords = true
unix extensions = no
password server = dc0.domain.local dc1.domain.local
server string = Corporate File Server
wins server = 192.168.5.10 192.168.5.11
domain master = no
socket options = TCP_NODELAY SO_KEEPALIVE
client schannel = no
client use spnego = yes
interfaces = aggr1*,lo
bind interfaces only = yes

kernel oplocks = yes
oplocks = yes
veto oplock files = /*.doc/*.DOC/*.xls/*.XLS/*.ppt/*.PPT/*.pst/*.PST/*.mdb/*.MDB/*.ldb/*.LDB/*.vsd/*.VSD/*.mpp/*.MPP/*.qbw/*.QBW/
*.qbb/*.QBB/*.qbI/*.qbl/*.dxf/*.DXF/*.dwg/*.DWG/*.cdr/*.CDR/*.bak/*.BAK/*.ord/*.xlo/*.igs/*.ipt/*.ipj/*.slp/*.stp/*.opt/*.xli/
*.stl/*.cur/*.sjb/*.log/*.LOG/*.sbs/*.iam/*.idv/*.pcbdoc/*.PcbDoc/*.PCBDOC/

# DFS
# host msdfs = yes
# strict locking
# strict sync

# winbind
winbind separator = +
idmap uid = 11000-19000
idmap gid = 11000-19000
winbind enum users = yes
winbind enum groups = yes
winbind nested groups = yes
allow trusted domains = yes
template homedir = /export/Corporate/Users/%U/Private

printcap name = /dev/null
load printers = no

[Corporate]
   comment = Corporate Share
   path = /export/Corporate
#Disabled acl check permissions and zfsacl due to zfsacl issues encountered Solaris 08/07 w/ Samba 3.0.25
   acl check permissions = False
  vfs objects = zfsacl
  nfs4: mode = special
  create mask = 0770
  directory mask = 0770
  public = yes
  writable = yes

#[Dfs]
#   path = /export/dfsroot
#   msdfs root = Yes

Test your configuration file for errors.

/usr/sfw/bin/testparm

We are now ready to join this box to the domain. If successful you should see “Joined 'FS0' to realm 'DOMAIN.LOCAL”

/usr/sfw/sbin/net ads join -U Administrator

Here we are going to enable the use of winbind through PAM. This will give us the capability of using active directory users and groups when assigning permissions on files and directories. We could also use this for other authentication methods that use PAM such as apache web sites (but that is another discussion).

Enable winbind in pam.conf

cp /etc/pam.conf /etc/pam.conf-OLD
cp /etc/pam.conf-winbind /etc/pam.conf

Enable winbind in nsswitch.conf to set up the search order for all authentication. The system will now look at the local files followed by a check against winbind.

vi /etc/nsswitch.conf

Edit the following lines so they read:

passwd:     files winbind
group:      files winbind

Before starting winbind we will perform a test so you can see what the nsswitch / pam changes did:

getent passwd
getent group

You should see a list of ONLY the users and groups in your Solaris /etc/passwd and /etc/groups files. So now lets enable services and run the commands again:

svcadm enable winbind
svcadm enable samba

getent passwd
getent group

If everything worked you should see all of your local users and groups plus all the users and groups from Active Directory. Winbind downloads this list from active directory maintaining a local cache in tdb files on your system.

By far this was the most time intensive portion of the whole process. While I can see the need and value for these ACL's I still miss the ease and cleanliness of the POSIX ACL's.

The following example illustrates how to setup root departmental shares along with user folders. The root departmental shares each have two groups associated with them:

1. corporate-<DEPARTMENT NAME> - Departmental group. Members of the department should be put here.
2. corporate-department-all - Access to ALL department folders (used for VP's and privileged users). This also helps us get around the 32 group limit (Since we cannot nest groups).

I use the naming strategy shown above to help keep my groups organized. Notice that corporate is the share name and department is going to be the departmental folder name. This helps make it easy associating shares / folders / sub-folders to groups. You do not need to setup your groups this way but I provide this example to help the ACL's make sense.

Before we get started we need to create our ZFS file system. You may have already noticed that I am creating the file system in export. If you already have a file system loaded in export you will need to backup your existing files/directories, remove your vfstab entry for export and create your zpool with the -f option or you can create your file system elsewhere and redefine the paths in this example. The following zpool shows a smaller system with only six disks. Your configuration will probably be different.

zpool create export raidz2 c0t0d0 c1t0d0 c4t0d0 c6t0d0 c7t0d0 c0t1d0

Now that the pool is created I am going to create my top-level shared folders.

zfs create export/Corporate
zfs create export/Corporate/Users
zfs create export/Corporate/Users/jdoe
zfs create export/Corporate/Sales
zfs create export/Corporate/Accounting

Set ZFS ACL inheritance to control how ACL's are inherited between file systems.

zfs set aclmode=passthrough export/Corporate
zfs set aclinherit=passthrough export/Corporate

Ok now we are ready to lay down our ACL's on our Corporate folder. By looking at this ACL you should notice I am first deleting any existing ACL's (Important when testing ACL's), then I am setting trivial permissions for user and group as rwx and telling the user and group permissions to inherit. I am then adding Domain Users to the ACL and allowing them to read the directory and list its contents. I always setup the root directories so users cannot add or remove files so Administrators can maintain organization by creating new departmental shares. Weird thing with ZFS acl's is I had to force domain users to inherit on the root folder and then explicitly deny on the child folders (departmental folders). When I tried giving Domain Users the ability to read and list they could not see any of the sub-directories.

chmod A- /export/Corporate
chmod 770 /export/Corporate
chmod A0=owner@::fdi:deny /export/Corporate
chmod A1=owner@:rwxpdDAWCo:fdi:allow /export/Corporate
chmod A2=group@::fdi:deny /export/Corporate
chmod A3=group@:rwxpdD:fdi:allow /export/Corporate
chmod A4=everyone@:rwxpaARWcCos:fdi:deny /export/Corporate
chmod A5=everyone@::fdi:allow /export/Corporate
chmod A+group:domain+domain\ users:rxcaRs:fdn:allow /export/Corporate

Here we will define the permissions on the Sales and Accounting Folders. ZFS ACL's are read from the top down once applied but when you apply an ACL the last entry gets added to the top of the ACL. So, in this example I am defining the same permissions and inheritance for user and group, giving each rwx while disabling access for everyone. Then I am giving Domain Admins the ability to manage ACL's and the departmental groups rwx access to the directories / files created within it. Lastly since I set inheritance for Domain Users on the share above I am explicitly denying access here.

chmod 770 /export/Corporate/Sales
chmod A0=owner@:--------------:fdi---:deny /export/Corporate/Sales
chmod A1=owner@:rwxpdD-A-W-Co-:fdi---:allow /export/Corporate/Sales
chmod A2=group@:--------------:fdi---:deny /export/Corporate/Sales
chmod A3=group@:rwxpdD--------:fdi---:allow /export/Corporate/Sales
chmod A4=everyone@:rwxp--aARWcCos:fdi---:deny /export/Corporate/Sales
chmod A+group:domain+domain\ users:rx:deny /export/Corporate/Sales
chmod A+group:domain+corporate-all:wpdDxrcaRAwW:fd:allow /export/Corporate/Sales
chmod A+group:domain+corporate-sales:wpdDxraRAwW:fd:allow /export/Corporate/Sales
chmod A+group:domain+domain\ admins:Co:fd:allow /export/Corporate/Sales 

chmod 770 /export/Corporate/Accounting
chmod A0=owner@:--------------:fdi---:deny /export/Corporate/Accounting
chmod A1=owner@:rwxpdD-A-W-Co-:fdi---:allow /export/Corporate/Accounting
chmod A2=group@:--------------:fdi---:deny /export/Corporate/Accounting
chmod A3=group@:rwxpdD--------:fdi---:allow /export/Corporate/Accounting
chmod A4=everyone@:rwxp--aARWcCos:fdi---:deny /export/Corporate/Accounting
chmod A+group:domain+domain\ users:rx:deny /export/Corporate/Accounting
chmod A+group:domain+corporate-all:wpdDxrcaRAwW:fd:allow /export/Corporate/Accounting
chmod A+group:domain+corporate-Accounting:wpdDxraRAwW:fd:allow /export/Corporate/Accounting
chmod A+group:domain+domain\ admins:Co:fd:allow /export/Corporate/Accounting

I am going to create the permissions on the Users folder as if it is another root level folder so that users cannot create directories under it (Like the Corporate share).

chmod A- /export/Corporate/Users
chmod 770 /export/Corporate/Users
chmod A0=owner@::fdi:deny /export/Corporate/Users
chmod A1=owner@:rwxpdDAWCo:fdi:allow /export/Corporate/Users
chmod A2=group@::fdi:deny /export/Corporate/Users
chmod A3=group@:rwxpdD:fdi:allow /export/Corporate/Users
chmod A4=everyone@:rwxpaARWcCos:fdi:deny /export/Corporate/Users
chmod A5=everyone@::fdi:allow /export/Corporate/Users
chmod A+group:domain+domain\ users:rxcaRs:fdn:allow /export/Corporate/Users

Now that the root folder is done it is time to set permissions on the user folders

chmod A- /export/Corporate/Users/*
chmod 770 /export/Corporate/Users/*
chmod A0=owner@:-w--dD--------:fd-n--:deny /export/Corporate/Users/*
chmod A1=owner@:r-xp---A-W-Co-:fd-n--:allow /export/Corporate/Users/*
chmod A2=group@:-w--dD--------:fd-n--:deny /export/Corporate/Users/*
chmod A3=group@:r-xp----------:fd-n--:allow /export/Corporate/Users/*
chmod A4=everyone@:rwxp--aARWcCos:fdi---:deny /export/Corporate/Users/*

…and finally on the folders themselves

chmod A+user:DOMAIN+jdoe:wpdDxraRAwW:fd:allow /export/Corporate/Users/jdoe

While I do know that this ACL setup does work I am going to continue experimenting to see if I can find any better ways to do this.

Issue 1:

With ZFSACL enabled and without “acl check permissions” enabled in Samba 3.0.25a/Solaris 10 08/07 I noticed that I could not rename or delete files or rename directories created under the root of a ZFS filesystem. I could however create a new directory using the default windows name “New Directory” and then all files under the “New Directory” behaved normally.

To resolve this I enabled “acl check permissions = False”

Issue 2:

As I started testing file creations with zfsacl enabled and “acl check permission = False” I noticed that if I created new Excel/Word files and saved them through Word or Excel sometime permissions would come back as ”———- 1 DOMAIN+user DOMAIN+Domain\ Users” even though I had my mask set in samba and proper permissions/inheritance on the directory.

To resolve this I disabled “vfs objects = zfsacl”

Issue 3:

Macintosh 10.5 (Leopard) clients were able to list the root of the share but they could not access any of the directories through Finder. They could however access the very same folders through Terminal.

To resolve this I set “unix extensions = no”