Active Directory Integration
From My Docs
Contents |
Introduction
These are the steps I followed to get my OpenSolaris (SXCE) fileserver integrated with a Windows 2003 Active Directory domain. The fileserver is using ZFS and the native Solaris CIFS protocol. This guide was originally written for snv_89 but has been confirmed to work up to the current release of SXCE (snv_95 at the time of writing this guide).
The following assumptions are made when following this guide:
- TCP/IP network is configured on your Solaris server
- You can communicate with the Active Directory domain server (ping it) by it's FQDN.
- You have a ZFS pool already setup (this guide will use the pool name tank)
NOTE: This is not intended to be an exhaustive guide, and does not cover every single troubleshooting option. Instead, it is meant to be an aide memoir for administrators.
Check DNS
Apart from basic networking which is beyond the scope of this guide, you should ensure that proper DNS is configured, so that the Solaris server can accurately query the DNS records pertaining to the domain you are integrating with. The DNS records associated with Active Directory are numerous and difficult to manually create. Assuming that you had Active Directory setup it's own DNS data, pointing the Solaris server to that DNS server will be sufficient.
Configure Kerberos
You now have to configure kerberos on the Solaris server so it can authenticate user data against the Active Directory domain. In this guide, we will use genestate.com as the domain, change this to suit your Active Directory domain. Edit the file /etc/krb5/krb5.conf as follows:
[libdefaults]
default_realm = GENESTATE.COM
[realms]
GENESTATE.COM = {
kdc = your_master_ad_server.genestate.com
admin_server = your_master_ad_server.genestate.com
kpasswd_server = your_master_ad_server.genestate.com
kpasswd_protocol = SET_CHANGE
}
[domain_realm]
.genestate.com = GENESTATE.COM
All other parts of this file are mainly concerned with logging and can be left or changed as you see fit.
Check Time and Date
It is critical that your Solaris server and your Active Directory domain's clocks are syncronised as closely as possible for Kerberos to function. To set sync the clock on your Solaris server to that of your Active Directory domain, run the following from the console:
ntpdate your_master_ad_server.genestate.com
Failure to sync the clocks to within necessary boundaries will result in failure to properly communicate between the two servers and cause errors to show in the logs.
Enable the CIFS Server
The smb service needs to be active before the next step is performed, so start it with the following command:
svcadm enable -r smb/server
Join the Domain
Now you can join your Solaris server to the domain using the following command. Replace the username and domain parts to suit your situation.
smbadm join -u admin_username genestate.com
The user you specify must have rights to join a computer to the domain (for example, an administrator). Providing everything is correct so far, you should be told that you successfully joined the domain.
After sucessfully joining, you will need to restart the CIFS server:
svcadm restart smb/server
User & Group Mapping
Solaris now needs to be able to map the Active Directory users and groups to those on the Solaris server using idmap. This example will deal with three basic mappings:
- Wildcard user mapping
- The "Domain Users" group
- The "Domain Admins" group
Any other mappings you require can be easily added in the same way. Issuing the following commands will instruct idmap to setup the mappings:
idmap add winuser:*@genestate.com unixuser:* idmap add "wingroup:Domain Users@genestate.com" unixgroup:users idmap add "wingroup:Domain Admis@genestate.com" unixgroup:staff
Remember to replate genestate.com with your own domain. Remember that for the wildcard user mapping will map the exact username to the same on the Solaris server. For example, you login with username joe.bloggs@genestate.com and create files on the Solaris server, the new files will be owned by the user joe.bloggs. You will need to create the users on the Solaris server with the appropriate username before they login and create/access files.
ZFS Datasets
We will share the appropriate parts of our fileserver using individual ZFS datasets, or filesystems. In this example we will create a dataset for generic data. The actual permssions (or ACLs) will be configured in the next section. Create a ZFS dataset with the following command:
zfs create -o casesensitivity=mixed tank/mydata
It is wise to create the dataset with the casesensitivity=mixed option to allow Windows clients to properly function. Now you can share your dataset using the sharesmb option:
zfs set sharesmb=name=mydata tank/mydata
We use the sharesmb=name=mydata format to set the share name explicitly (in this case it becomes mydata). If you only specify sharesmb=on, then you will end up with share names like tank_mydata.
The share should now be available to Windows clients that have authenticated on the domain, however no-one will be able to write to it as it is owned by root and only writable by the owner.
Setting ACLs
In our example, we want to grant read permissions to members of the Domain Users group and write permissions only to members of the Domain Admins group. We can accomplish this by issuing the following command:
chmod A=group:staff:rwxpdDaARWcCos:fd-----:allow,group:users:r-x---a-R-c--s:fd-----:allow /tank/mydata
This will set the permissions as we desire, and also force inheritance of these permissions for every newly created file or directory in the dataset. This ensures that Domain Users will always have read permissions to files and directories created by Domain Admins.
In another example, we want to grant full permissions to Domain Admins and also to a specific user. This is useful for a users' private home directory. We can do this like so:
chmod A=group:staff:rwxpdDaARWcCos:fd-----:allow,user:joe.bloggs:rwxpdDaARWcCos:fd-----:allow /tank/homes/joe.bloggs
This will let the user control his/her own home directory, while allowing Domain Admins to manage it also. ACLs are complex and some care should be taken when divising your own.
Auto-sharing Home Directories
If you have many users, you will probably find it too much work to share everyone's home directory manually. Apart from the management overhead, it will make a huge list of shares in the network view which most users don't want to see. There is a better way, smbautohome allows you to define rules by which users' home directories are automatically shared when the user authenticates against the domain controller.
In this example, all our users' home directories are stored in the same place, /tank/homes, so the home directory for joe.bloggs would be /tank/homes/joe.bloggs. Edit /etc/smbautohome (or create it if it doesn't exist) and add the following:
* /tank/homes/&
When joe.bloggs logs in, a share will be automatically created visible only to him. This is a wildcard mapping and will automatically create the share appropriately for any user. You can also segregate your users by the first letter of their username:
* /tank/homes/?/&
Which would map joe.bloggs home directory to /tank/homes/j/joe.bloggs. This might be useful if you have a very large number of users. Restart the smb server after your changes:
svcadm restart smb/server
And login to your domain. You should now have access to a share on the Solaris server with the same name as the user.
Further Reading
You might also want to read some of the administration guides, the relevant ones can be found here:
