Single Sign On / Authentication against Active Directory for Windows ...

Single Sign On / Authentication against Active Directory for Windows, Linux and Mac with a common home area via Samba and Winbind Background Information This documentation will detail how to get single authentication against Active Directory with a common home area for Windows, Linux and Mac OSX workstation clients. There are variations and methodology on how this can be done, but in my case the limiting factor is that the main authentication method has to be Windows Active Directory because of how passwords are being push from top down. I believe it can be done otherwise by getting the password hash fields and injecting them directly in the Directory Service be in Active Directory, LDAP server etc. Now basically all clients except for Linux / Unix based client except for the Mac OSX can be joint to the Active Directory thus effectively being authenticated and binding the personal home area specified by users profile tab. The home area for these clients will be served via CIFS by Samba from Linux CIFS / NFS server joint to the AD. With Unix / Linux system, we will use Winbind with Kerberos to authenticate against the AD and access their home area via NFS from the same Linux CIFS /NFS server. By using a Linux NFS / CIFS server we can provide a common network home area for any Windows and Linux / Unix based and Mac system by consolidating various disk servers for various system. There are also other flow on effects which should be considered ie for example consolidation of storage space, backup maintenance and ease of access of data for users and administrators which are just a few examples One thing I wanted to point out, I am using Winbind with idmap_rid (Also know as rid in earlier samba version) support. What this does is that the UID and GID are generated from SIDs in the AD. Thus any machine joint to the AD domain with idmap rid support will have consistent UID and GID mappings, thus zero administration in terms of maintaining UID / GID for traditional directory services as its handled transparently client sided. Please note, if you use Winbind without idmap rid support, the workstation will maintain its own local workstation UID / GID mappings for users / groups thus there will be no consistency between workstations and be unworkable for NFS mounted drives.

Last Updated 20/11/2009, email [email protected]

There is another variation, where you modify the AD schema with POSIX attributes which then the AD in a sense is an LDAP / NIS directory but I will detail this in a different document once I get to it. Requirements 1. A Functional Windows 2003 R2 Server with Active Directory Configured (No Schema Extension required, AD with integrated DNS functioning) where clients can join the domain (I’m assuming most people know how to use AD) 2. Linux Client with Samba 3.x (3.2x is preferable as the syntax has changed significantly since 3.x) along with Winbind 3.2x. In my case it will be a Red Hat Fedora Core 10 installation. 3. Mac OSX Leopard running 10.5.8 or later (Higher revision has better AD support but I can’t quite comment on Snow Leopard) 4. Linux NFS / CIFS server serving a common network home area to all client machines. 5. Windows Client (I believe this is really optional if a WinXP or Windows 7 client can’t bind to Windows AD there would be a big outcry) 6. All machines must have the same date and time (even better if they are time synced as AD services don’t allow client machines with a time skew of 5min to do any queries be it authentication or joining to the domain Assumptions I have virtual machines for all of these except for Mac OSX to demonstrate it is a functional test model system which should scale. Windows Server Operating System : Windows Server 2003r2 sp2 (With no Schema Extensions) Domain Name: csse.sso.edu.au Hostname: win2k3r2 FQDN: win2k3r2.csse.sso.edu.au IP Address: 192.168.1.10 Netmask: 255.255.255.0 DNS: When the AD was configured, it should know it is the only AD and it should have been configured to look at itself for directory information) Gateway: None (I don’t want it going out, just for testing purposes on 192.168.1.x subnet) Linux NFS / CIFS server Operating System : Fedora Core 10 Hostname: fc10nfs FQDN: fc10nfs.csse.sso.edu.au IP Address: 192.168.1.11 Netmask: 255.255.255.0 DNS: 192.168.1.10 (For clients to join to AD, the AD servers needs to be first on DNS lookup) Gateway: None (I don’t want it going out just for testing purposes on 192.168.1.x subnet) Specifics: Samba and Winbind 3.2x (Make sure the package has idmap_rid / rid support) Last Updated 20/11/2009, email [email protected]

Linux Client Operating System : Fedora Core 10 Hostname: fc10vm FQDN: fc10nfs.csse.sso.edu.au IP Address: 192.168.1.20 Netmask: 255.255.255.0 DNS: 192.168.1.10 (For clients to join to AD, the AD servers needs to be first on DNS lookup) Gateway: None (I don’t want it going out just for testing purposes on 192.168.1.x subnet) Specifics: Samba and Winbind 3.2x (Make sure the package used has idmap_rid / rid support) Mac OSX client Operating System : Mac OSX 10.5.x (Newer is better but not quite sure on 10.6.x) Hostname: macosx FQDN: macosx.csse.sso.edu.au IP Address: 192.168.1.22 Netmask: 255.255.255.0 DNS: 192.168.1.10 (For clients to join to AD, the AD servers needs to be first on DNS lookup) Gateway: None (I don’t want it going out just for testing purposes on 192.168.1.x subnet) Windows client Operating System : WinXPSP3 Hostname: winxpsp3 FQDN: winxpsp3.csse.sso.edu.au IP Address: 192.168.1.23 Netmask: 255.255.255.0 DNS: 192.168.1.10 (For clients to join to AD, the AD servers needs to be first on DNS lookup) Gateway: None (I don’t want it going out just for testing purposes on 192.168.1.x subnet) (All of this is available for my Fellow UWA administrators as Virtual machines for the exception of the Mac OSX. But you could bridge the network traffic for virtual machines to a switch and get real Mac OSX clients to interact with the Virtual Machines like I have)

Last Updated 20/11/2009, email [email protected]

Installation / Configuration of Server and Workstations Configuration of Windows Server As mentioned before you should have a functional Active directory with functional DNS. You need to make some changes in terms of communications allowed to the Active Directory for Samba. Go into the administrative tools, run the AD Users and Computers, right click on your domain in my case “csse.sso.edu.au” and select properties and click on the group policy tab. There should a “Default Domain Policy”, select it and click edit. You will need to change the two followings. Computer configuration -> Windows Settings -> Security Settings -> local policies -> Security Options. Microsoft Network Server: Digitally sign communications (always) -> Disabled Microsoft Network Server: Digitally sign communications (if client agrees) -> Disabled Run gpupdate from a command prompt to updated it or simply reboot it, a AD user would be also useful for testing purposes. First Name: AD Last Name: Test Comment: AD Test User Logon Name: adtestnfs Domain: csse.sso.edu.au Profile: \\fc10nfs.csse.sso.edu.au\adtestnfs\profile.usr Connect: Z to: \\fc10nfs.csse.sso.edu.au\adtestnfs Password: qazWSC123

Configuration of Linux NFS/CIFS Server We basically need to configure the Linux box to be able to join the Windows AD so it gets UID/GID mappings, then setup an area to be exported as a home area via CIFS though Samba for Windows and Mac clients and similarly the same area via NFS for Linux / Unix clients To join the Linux Client in my case a Fedora Core 10 installation to the Active Directory, you will need to configure the Kerberos, Samba and some authentication related configuration files.

Last Updated 20/11/2009, email [email protected]

In Fedora Core 10, the kerberos file that needs to be configured is /etc/krb5.conf (It’s case sensitive). Note “CSSE.SSO.EDU.AU” is the Kerberos realm defined here as opposed to the domain name “csse.sso.edu.au”. [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = CSSE.SSO.EDU.AU dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h forwardable = yes [realms] CSSE.SSO.EDU.AU = { kdc = win2k3r2.csse.sso.edu.au admin_server = win2k3r2.csse.sso.edu.au default_domain = CSSE.SSO.EDU.AU } [domain_realm] csse.sso.edu.au = CSSE.SSO.EDU.AU .csse.sso.edu.au = CSSE.SSO.EDU.AU

[appdefaults] pam = { debug = false ticket_lifetime = 36000 renew_lifetime = 36000 forwardable = true krb4_convert = false }

Now if you have configured kerberos client correctly you should be able to get a Kerberos authentication ticket from the AD ie by running the following command from the terminal ie kinit [email protected] klist

Note it’s case sensitive, as again “CSSE.CSSE.EDU.AU” refers to the Kerberos defined realm. You should see something similar as in Figure 1 when you run those commands.

Last Updated 20/11/2009, email [email protected]

Figure 1: Kerberos Ticket from AD server

If you can’t get a ticket, basically you have configured the Kerberos configuration incorrectly assuming your Windows Server is working correctly. It would be pointless to proceed any further until you can get your client to get a Kerberos ticket successfully as Winbind uses Kerberos authentication to verify users. The other file you will need to edit for Winbind for the authentication is /etc/samba/smb.conf. This file also configures the shares via CIFS though Samba, the only section you need to edit is the “global” and “homes” section.

Last Updated 20/11/2009, email [email protected]

*snip* [global] #--authconfig--start-line-# Generated by authconfig on 2009/10/31 21:45:35 # DO NOT EDIT THIS SECTION (delimited by --start-line--/--end-line--) # Any modification may be deleted or altered by authconfig in future workgroup = CSSE password server = win2k3r2.csse.sso.edu.au realm = CSSE.SSO.EDU.AU security = ads allow trusted domains = No idmap backend = idmap_rid:CSSE=16777216-33554431 idmap uid = 16777216-33554431 idmap gid = 16777216-33554431 log level=1 syslog = 0 log file=/var/log/samba/%m template shell = /bin/zsh winbind use default domain = true winbind offline logon = false #winbind enum groups and users should be disabled with large ADs winbind enum groups = yes winbind enum users = yes #Ashley Personal Configuration files for home areas #No default homedir value specified, the default area is /home/%D/%U #Specifiy home area to separate Linux and Windows area ie #where %U = username, %D = domain, %G is group # /home/CSSE/%U/profile.usr -> Linux Profile Area # /home/CSSE/%U/linux -> Linux Home Area # Unhash below for linux server for cifs/nfs linux server # Export User root home area template homedir /home/CSSE/%U # Unhash below for linux client nfs home # Separate Windows / Linux area ie %U/profile.usr and %U/linux # template homedir /home/CSSE/%U/linux #--authconfig--end-line-*snip* [homes] comment = Home Directories browseable = no writable = yes create mode = 0664 directory mode = 0775 ; valid users = %S ; valid users = MYDOMAIN\%S

Last Updated 20/11/2009, email [email protected]

I am using the IDMAP_RID support of Winbind which allows a consistent mappings as quoted from the Samba Page “The idmap_rid facility is a new tool that, unlike native Winbind, creates a predictable mapping of MS Windows SIDs to UNIX UIDs and GIDs. The key benefit of this method of implementing the Samba IDMAP facility is that it eliminates the need to store the IDMAP data in a central place” You have to package enabled “idmap_rid” support in Samba/Winbind. If you are not sure you can run “smbd –b” to get a build information look for something referring to rid (Older samba refers to rid, newer version revision refers to idmap_rid). Another thing to point out I believe rid support is only available in Samba/Winbind version 3.08 or greater I believe. Bow if you have configured everything, you are almost there to join the linux CIFS/NFS server to the domain. Please make sure that you have configured the linux box with the proper FQDN ie in /etc/hosts 127.0.0.1 192.168.1.11 ::1 192.168.1.10

locahost,localdomain localhost fc10nfs.csse.sso.edu.au fc10nfs localhost.localdomain localhost6 localhost win2k3r2.csse.sso.edu.au win2k3r2.csse.sso.edu.au

So the FQDN should match that to the AD domain you are joining, as DNS and Directory services provided by the AD are integrated. Giving it a weird FQDN that’s different to the domain will create incorrect or incomplete objects in the AD. Here is a hint you can’t join an AD that already has an object of the same name, so delete the object first before attempting to join it, the other piece of advice is make sure the DNS search order points to the AD first ie 192.168.0.10 in my case which should be in /etc/resolv.conf. Now to join to the AD for the domain “csse.sso.edu.au” you just type “net rpc join –U administrator” (It use to be net ads command but that’s deprecated, if you are unsure “type net rpc” which should show you a valid list of commands) which then you should see something similar to that in figure 2.

Last Updated 20/11/2009, email [email protected]

Figure 2 : Joining a Linux Client to AD One you have successfully joined the AD, start Winbind and Samba ie /etc/init.d/winbind start /etc/init.d/smbd start /etc/init.d/nmbd start (Optional but windows uses netbios look ups) You need to make these service start up automatically, what we did above was just to kick start it for this session. If you have installed “ntsysv” or something similar, you can type that to check it on to start up at boot time. Now if it is properly jointed to the domain and you have started the appropriate services, you should be able to get AD information about users and groups ie by typing “wbinfo –u” for user information or “wbinfo –g” for group information such as that show in Figure 3.

Last Updated 20/11/2009, email [email protected]

Figure 3 : Domain Lookup Information for Users and Groups Now you know it that it has successfully joint to the domain, you have to configure the PAM to actually use this information for users and groups. You can use the built in GUI to modify the Authentication ie System -> Administration -> Authentication GUI. But for me, it’s easier for me to modify the files directly as I know what I want to do and this would be applicable to just about any Unix / Linux system using PAM modules. So what you want to do is edit /etc/nsswitch.conf and couple of PAM modules.

Last Updated 20/11/2009, email [email protected]

# # # # # # # # # # # # # # # # # # # # # # #

/etc/nsswitch.conf An example Name Service Switch config file. This file should be sorted with the most-used services at the beginning. The entry '[NOTFOUND=return]' means that the search for an entry should stop if the search in the previous entry turned up nothing. Note that if the search failed due to some other reason (like no NIS server responding) then the search continues with the next entry. Legal entries are: nisplus or nis+ nis or yp dns files db compat hesiod [NOTFOUND=return]

# To use db, put the # looked up first in # # Example: #passwd: db files #shadow: db files #group: db files

Use NIS+ (NIS version 3) Use NIS (NIS version 2), also called YP Use DNS (Domain Name Service) Use the local files Use the local database (.db) files Use NIS on compat mode Use Hesiod for user lookups Stop searching if not found so far

"db" in front of "files" for entries you want to be the databases nisplus nis nisplus nis nisplus nis

passwd: shadow: group:

files winbind files winbind files winbind

#hosts: hosts:

db files nisplus nis dns files wins dns

# Example - obey only what nisplus tells us... #services: nisplus [NOTFOUND=return] files #networks: nisplus [NOTFOUND=return] files #protocols: nisplus [NOTFOUND=return] files #rpc: nisplus [NOTFOUND=return] files #ethers: nisplus [NOTFOUND=return] files #netmasks: nisplus [NOTFOUND=return] files bootparams: nisplus [NOTFOUND=return] files ethers: netmasks: networks: protocols: rpc: services:

files files files files files files

netgroup:

files

publickey:

nisplus

automount: aliases:

files files nisplus

Last Updated 20/11/2009, email [email protected]

With Fedora Core 10, all the authentication are handled by PAM in /etc/pam.d, but all services are linked to a general PAM module. Ie for ssh pam module (/etc/pam.d/sshd)shown below, you can see the account and authentication is done by a module called system-auth. #%PAM-1.0 auth include system-auth account required pam_nologin.so account include system-auth password include system-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session include system-auth session required pam_loginuid.so # pam_selinux.so open should only be followed by sessions to be executed in the user context session required pam_selinux.so open env_params session optional pam_keyinit.so force revoke

Now if we look at system-auth file ( /etc/pam.d/system-auth ), mine has been modified to use Winbind and Kerberos. #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_krb5.so use_first_pass auth sufficient pam_winbind.so use _first_pass auth required pam_deny.so account account account account account account password password password password password session session session session session

required pam_unix.so broken_shadow sufficient pam_localuser.so sufficient pam_succeed_if.so uid < 500 quiet [default=bad success=ok user_unknown=ignore] pam_krb5.so [default=bad success=ok user_unknown=ignore] pam_winbind.so required pam_permit.so requisite sufficient sufficient sufficient required

pam_cracklib.so try_first_pass retry=3 pam_unix.so md5 shadow nullok try_first_pass use_authtok pam_krb5.so use_authtok pam_winbind.so use_authtok pam_deny.so

optional pam_keyinit.so revoke required pam_limits.so [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid required pam_unix.so optional pam_krb5.so

Last Updated 20/11/2009, email [email protected]

Now that you have made the changes, you can use the typical Unix / Linux test of “getent passwd” or “getent group” to see if your AD users and groups are visible. As you can see in figure 4, I can see my AD users as an example.

Figure 4 : “getent passwd” test It should be noted if you left out “winbind enum users|groups = yes” or you have set it to “winbind enum users|group = no”. The getent test for user or group would fail, although you can still log in. The reason for this is the Winbind enum option if enabled, enumerate all users or groups in the AD so it allows you to see all features if you were viewing from a traditional directory service like NIS or LDAP. But it is undesirable if there is a large number of AD users and groups. Imagine a couple of hundred machines repeatedly querying the AD where it had to enumerate all the SID of users Last Updated 20/11/2009, email [email protected]

and groups. It would be a big processing over head on the AD half and that’s why it is turned off. What I would do is enable it, once I know everything is working, I would turn it off. Now if the “getent passwd” and “getent groups” work, you should be able to ssh into the local box (Assuming you have ssh started and it’s not locked down) ssh [email protected] Once you are in, you basically have configured the authentication mechanism. Everything done up to know is the same basic process which you would do for a Linux Client. The remaining section of “Configuration of Linux NFS/CIFS Server” will detail how the server will provide a home area to your Windows, Linux and Mac clients. For Windows it will access the fc10nfs.csse.sso.edu.au disk server via CIFS, remember we created a AD user called adtest which had the following properties which defines their home aresa and mapped network drive Profile -> \\fc10nfs.csse.sso.edu.au\adtestnfs\profile.usr” Map Network Drive -> \\fc10nfs.csse.sso.edu.au\adtestnfs We already preconfigured their home area via CIFS ie for Windows when we edited /etc/samba/smb.conf which was under [homes] and [global] section. One thing I wanted to point out “homedir” variable is only applicable when you are using Winbind with Samba. We want to separate the home areas by specifying where the User desktop area will be stored in their user home root area. Ie with Windows the area will in username/profile.usr whereas the Unix / Linux home area is username/linux. That’s why for the Linux CIFS / NFS server we will be defining this. template homedir /home/CSSE/%U

Thus when users access the fc10nfs disk server via CIFS ie Windows you will be able to traverse down to the “linux” directory where is the Unix / Linux Desktop area and similarly for profile.usr where they can access their Windows Desktop area.

Last Updated 20/11/2009, email [email protected]

Note the “ homedir” in /etc/samba/smb.conf is different on a Linux client, because the home area on Linux client is derived partially from the AD but is ultimately defined locally on the machine by the homedir variable as Winbind is acting as mediator with the AD. By doing this it will explicitly define the users home area to write to ie template homedir /home/CSSE/%U/linux

Now to activate the CIFS service on fc10nfs.csse.uwa.edu.au to serve the home area, we just have to start the smb service ie “/etc/init.d/smb start” but you should check the service on to start at boot time as we already pre-configured it in the [homes] and [global] section in smb.conf. That is one network file service activated, now we have to configure NFS services on fc10nfs.csse.uwa.edu.au for the Unix / Linux clients. Now the only part you need to edit is the /etc/exports which basically tells which area to allow for NFS traffic and which clients are allowed to mount it. The contents of my exports file is shown below. #Export /home/CSSE to all of 192.168.1.xxx /home/CSSE 192.168.1.0(rw,sync)

Once configured, all you need to do is kick start the nfs services ie nfs and nfslock which can be done with these lines /etc/init.d/nfs start /etc/init.d/nfslock start As again you want this to automatically start at boot time, example in figure 5 shows “ntsysv” for Fedora Core 10 where you can selectively select service to start and run at boot time.

Last Updated 20/11/2009, email [email protected]

Figure 5 : “ntsysv” system startup services Last of all I’ve assumed that you have already created the home area specified for CIFS/NFS serving and the area for our test user, if not then follow this. mkdir /home/CSSE chown –R 755 /home/CSSE cd /home/CSSE mkdir adtest (repeat this and below for other users area ie administrators) mkdir adtest/linux mkdir adtest/profile.usr chown –R adtest adtest chmod –R 700 adtest

Then restart or reboot fc10nfs.csse.uwa.edu.au, after the reboot if everything is working nfs, nfslock, winbind and smb services should be running and the home area permission should resolve to the appropriate users and groups. In figure 6 you can see me checking the status of services, user lookup from AD and user / group mappings of home areas created. Last Updated 20/11/2009, email [email protected]

Figure 6 : Status check of fc10nfs.csse.sso.edu.au

Last Updated 20/11/2009, email [email protected]

Configuration of Linux Client As I mentioned before, configuration of a Linux client is almost exactly as configuring a Linux NFS/CIFS Server. The only difference is that you will not be configuring any NFS related configuration or services ie /etc/exports, nfs or nfslock The only difference is there is a slight difference in “homedir” variable because I want to separate the Unix / Linux login area to “username/linux” on client workstations defined as defined /etc/samba/smb.conf. So in the global section of the configuration it would be this *snip* [global] #--authconfig--start-line-# Generated by authconfig on 2009/10/31 21:45:35 # DO NOT EDIT THIS SECTION (delimited by --start-line--/--end-line--) # Any modification may be deleted or altered by authconfig in future workgroup = CSSE password server = win2k3r2.csse.sso.edu.au realm = CSSE.SSO.EDU.AU security = ads allow trusted domains = No idmap backend = idmap_rid:CSSE=16777216-33554431 idmap uid = 16777216-33554431 idmap gid = 16777216-33554431 log level=1 syslog = 0 log file=/var/log/samba/%m template shell = /bin/zsh winbind use default domain = true winbind offline logon = false #winbind enum groups and users should be disabled with large ADs winbind enum groups = yes winbind enum users = yes #Ashley Personal Configuration files for home areas #No default homedir value specified, the default area is /home/%D/%U #Specifiy home area to separate Linux and Windows area ie #where %U = username, %D = domain, %G is group # /home/CSSE/%U/profile.usr -> Linux Profile Area # /home/CSSE/%U/linux -> Linux Home Area # Unhash below for linux server for cifs/nfs linux server # Export User root home area

# template homedir /home/CSSE/%U # Unhash below for linux client nfs home # Separate Windows / Linux area ie %U/profile.usr and %U/linux

template homedir /home/CSSE/%U/linux #--authconfig--end-line--

Last Updated 20/11/2009, email [email protected]

Everything apart from the slight change in /etc/samba/smb.conf, /etc/krb5.conf, pam configuration, /etc/nsswitch.conf, joining to the csse.sso.edu.au domain etc will be the same neglecting the CIFS/NFS configuration as it is not needed. The only other minor change is to make the home area via NFS from fc10.sso.edu.au accessible on the client machine. I just force a mount on boot time which you can define in the /etc/fstab # # /etc/fstab # Created by anaconda on Fri Dec 5 06:59:07 2008 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or vol_id(8) for more info # /dev/sda2 / ext3 defaults 1 1 tmpfs /dev/shm tmpfs defaults 0 0 devpts /dev/pts devpts gid=5,mode=620 0 0 sysfs /sys sysfs defaults 0 0 proc /proc proc defaults 0 0 /dev/sda1 swap swap defaults 0 0 # Specific NFS Mounts fc10nfs.csse.sso.edu.au:/home/CSSE

/home/CSSE

nfs

rw,bg,hard,intr

0 0

In Figure 7, it shows you the entries I have made in the /etc/fstab on the client and you can see that the NFS drive from fc10nfs.csse.sso.edu.au is properly mounted.

Last Updated 20/11/2009, email [email protected]

Figure 7 : NFS mount entry and check on Linux Client Now that everything is properly configured, I just use the ssh test to fc10vm to see if I can log in correctly remotely, if it does you should be able to log onto the console. You can see my remote ssh test session in figure 8, before I try logging into the console which also works.

Last Updated 20/11/2009, email [email protected]

Figure 8 : ssh remote test on fc10vm.csse.sso.edu.au

Last Updated 20/11/2009, email [email protected]

Configuration of Windows Client There isn’t much to say for here, there is really only one way. This step is for a Windows XP Professional client but other versions including Vista or Windows 7 are very similar 1. 2. 3. 4.

Go Start > Settings -> Control Panel -> Network Connections Click Advanced -> Network Identification Go to “To rename or join a domain, Click Change” and click Change. Check your Computer Name is unique and Click the Domain option, and fill in the domain which in this case is “csse.sso.edu.au” or “csse”. Either should work depending on how you configured your AD. 5. Reboot 6. When you login as AD test you will be mapped via CIFS If it doesn’t work, usually that means you incorrectly configured the CIFS service via Samba incorrectly. I would test if you see the shares of fc10nfs.csse.sso.edu.au (ie run start -> run -> \\fc10nfs.csse.uwa.edu.au) then work what is wrong from there. If you can’t see the share, make sure you made the changes in regards to [home] and [global] section in smb.conf on fc10. Both Winbind and smb has to be correctly configured as Winbind does the authentication plus figures where the home area where as Samba servers the home area. After typing \\fc10nfs.csse.uwa.edu.au and it doesn’t respond, make sure smb service is running on fc10nfs.

Last Updated 20/11/2009, email [email protected]

Configuration of Mac OSX Client I haven’t mentioned as much about OSX as I have about the Windows or Linux client, as Mac OSX is kind of a unique positions. As it has a rather unique feature where it allows you to join to an Existing AD without any existing add-ons just like a Windows Workstation. In saying that, the Apple Mac OSX uses the same information as specified in the Profile Tab for the AD users thus will write their files in the same Desktop area. So essentially it will use the CIFS services as like a Windows Client. Here are the steps to join the Apple Mac OSX to the AD (Newer is always better but be careful of Snow Leopard its rather still quite new and not polished so Leopard would be a safer bet) 1. 2. 3. 4. 5. 6. 7. 8. 9.

Macintosh HD -> Applications -> Utilities -> Directory Utility Show Advanced Settings Click Services Tab Check the box for “Active Directory” to enable it Then double click on Active Directory to configure it For Active Directory Forest / Active Directory Domain was set to “csse.sso.edu.au” Computer ID to “macosx” Click the down arrow to Show Advanced Options Under User Experience, I had “Use UNC path from AD to derive network home location” and the “network protocol to be used” as “SMB” checked on along with “default user shell “ set to “/bin/zsh”. All other options in the User Experience was unchecked. 10. Under Mappings ie “Map UID to attribute”, “Map GID to attribute” and “Map group GID to attribute” are unchecked, these are used if the AD schema is extended and UID/GID in the schema which you specifically map to. 11. Under Administrative section, I checked Allow administration by “csse\domain admins”, “csse\enterprise admins”. I also checked “allow authentication from any domains in the forrest” 12. Click bind, username = administrator, password = domain password, Computer OU= CN=Computers,DC=csse,DC=sso,DC=edu,DC=au. Don’t forget to also check the box for “use for authentication” and “use for Contacts” before you click the bind button.

Now if you log into the Mac with adtest at the console, you notice that it will write all it Desktop files to whatever you have mapped in your AD ie in our case. “Connect: Z -> \\fc10nfs.csse.sso.edu.au\adtestnfs”

Last Updated 20/11/2009, email [email protected]

It basically writes the files to root area of the user’s home area specified by the above. It’s not desirable, but and least it doesn’t really conflict with the other two systems ie in terms of files and directory structure where there is no overlap Windows -> username\profile.usr Linux -> username\linux Mac OSX -> username If you type mount as your adtest user you can see its mounted the home area from fc10nfs via CIFs like windows. mactest% pwd /Network/Servers/fc10nfs.csse.sso.edu.au/adtest mactest% whoami adtest mactest% mount /dev/disk0s2 on / (hfs, local, journaled) devfs on /dev (devfs, local) fdesc on /dev (fdesc, union) map -hosts on /net (autofs, automounted) map -static on /home/honours (autofs, automounted) map -static on /home/staff (autofs, automounted) map -static on /cslinux (autofs, automounted) /dev/disk0s4 on /Volumes/Untitled (ntfs, local, read-only, noowners) map -fstab on /Network/Servers (autofs, automounted) trigger on /Network/Servers/fc10nfs.csse.sso.edu.au/adtest (autofs, automounted) //[email protected]/adtestnfs on /Network/Servers/fc10nfs.csse.sso.edu.au/adtest (smbfs, nodev, nosuid, automounted, mounted by adtest)

Basically that’s it, this is working single sign on with all three client system authentication to AD with a single home area and single password.

Last Updated 20/11/2009, email [email protected]