Single Sign On / Authentication against Active Directory (Unix Schema Extension) for Windows, Linux (via LDAP access to AD) and Mac with a common home via Samba.

(Last Updated 06/11/2009, email ashley@csse.uwa.edu.au)

Background Information

This documentation will detail how to get single authentication against Active Directory with a common user 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.

This variation doesn’t use Winbind so Linux / Unix information ie such as UID, GID etc are stored in the AD an accessed as a normal LDAP directory. In saying this that means the default Active Directory schema needs to be extended to accommodate these attributes.

The Winbind solution I presented in an earlier document can be thought has a client solution with next to zero overhead Linux /Unix administration but may not be possible with all Linux / Unix clients ie maintain existing legacy system which don’t support the latest Winbind, or support of an existing system which already have a UID / GID mappings in place already etc.

That’s where you would transfer the solution to be server sided and make it as transparent as possible to the client. This is done by making the AD into providing LDAP like directory services.

Note this is the preferred option if you have an existing mapping of users and groups in an existing Directory Service ie NIS or LDAP, you would map over the settings then sign over he Directory service to the AD with the extended Linux / Unix Schema.

Requirements

1. A Functional Windows 2003 R2 Server with Active Directory Configured (Schema Extension required for LDAP like services, 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 LDAP Directory service support

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. If you want to test the Mac OSX with the Virtual machines just bridge the virtual machines on your machine and connect it to a common switch along with the Mac.

Windows Server

Operating System : Windows Server 2003r2 sp2

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)

Specifics: No AD schema extensions

AD Domain Administrator: administrator

AD Domain Passwd: ADtesting2009

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)

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)

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. This is pretty generic for Unix / Linux system which uses AD to talk to Samba.

The next thing we need to do is basically extend the schema to provide so it behaves like a LDAP directory server to Linux / Unix clients.

Previously you would install “Windows Services for Unix Version 3.50” from Microsoft buts it’s pretty much built into Windows 2003r2 or later by adding a component.

Start -> Settings -> Add/Remove Programs -> Add/Remove Windows Components

There should be a section “Active Directory Services”, which you should check the box which is shown in figure 1.

Figure 1 – Active Directory Services

Once that box is checked, select details which will give you the subcomponents which you can install, but the only one that I am interested in is “Identity Management for Unix” which is shown in Figure 2. Once that is installed you might have to reboot the Windows Server.

Figure 2 – “Identity Management for Unix”

By installing the “Identity Management for Unix” the schema should be automatically extended with Linux / Unix attributes. You should be able to verify this when you run “Active Directory Users and Computers” tool and click on an existing user ie such as “administrator”, you will see there is a new “Unix Attributes” tab which has all the traditional Unix attributes as seen in figure 3.

There are also “Unix Attributes” tab for Windows groups as well as in Figure 4.

Figure 3 – Unix Attributes for Users in AD

Figure 4 – Unix Attributes for Groups in AD

Now it would be useful to create an AD user and group with the “Unix Attributes” for testing purposes.

AD Group

Group Name: linux

Description: linux

Group Scope: global

Group Type: security

Nis Domain: csse

GID: 99000

AD User

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

NIS Domain: csse

UID: 10000

Login Shell: /bin/zsh

Home Directory: /home/CSSE/adtestnfs/linux

Primary Group name / GID: linux

Password: qazWSC123

Configuration of Linux NFS/CIFS Server

We basically need to configure the Linux box to be mapped to the Active Directory via LDAP so it can see the mappings ie such as UID/GID, home area etc. Once that is done we have to configure a common home area for all client workstation system to store the user area via NFS and CIFS.

The first step is to make sure the LDAP port on the win2kr2.csse.sso.edu.au is opened to your client. So from fc10nfs.csse.sso.edu.au, do a telnet test to the port ie

telnet win2k3r2.csse.sso.edu.au 389

If you can’t connect make sure the firewall has a port patched for 389.

The second test I would do is do a ldapsearch test to see if the AD responds to normal ldap queries ie from at a terminal on fc10nfs.csse.sso.edu.au I typed.

ldapsearch -LLL -H ldap://win2k3r2.csse.sso.edu.au:389 -b 'dc=csse,dc=sso,dc=edu,dc=au' -D 'CSSE\administrator' -w 'ADtesting2009' '(sAMAccountName=adtest)' -x

You should see something like this shown below from the AD, if you don’t its no point proceeding as you can’t query the AD as LDAP directory Services. It won’t be a client issue, it will be an AD configuration problem.

dn: CN=AD Test via NFS,CN=Users,DC=csse,DC=sso,DC=edu,DC=au

objectClass: top

objectClass: person

objectClass: organizationalPerson

objectClass: user

cn: AD Test via NFS

sn: Test

givenName: AD

distinguishedName: CN=AD Test via NFS,CN=Users,DC=csse,DC=sso,DC=edu,DC=au

instanceType: 4

whenCreated: 20091105080301.0Z

whenChanged: 20091118032846.0Z

displayName: AD Test via Unix NFS

uSNCreated: 49191

uSNChanged: 90146

name: AD Test via NFS

objectGUID:: mZ8e9F/AB0SpBWCEjm1c6g==

userAccountControl: 512

badPwdCount: 0

codePage: 0

countryCode: 0

homeDirectory: \\fc10nfs.csse.sso.edu.au\adtestnfs

homeDrive: Z:

badPasswordTime: 129023211758906250

lastLogoff: 0

lastLogon: 129023769793437500

pwdLastSet: 129023211294062500

primaryGroupID: 513

profilePath: \\fc10nfs.csse.sso.edu.au\adtestnfs\profile.usr

objectSid:: AQUAAAAAAAUVAAAAQW75C5ApCxTdxHWRWAQAAA==

accountExpires: 9223372036854775807

logonCount: 24

sAMAccountName: adtestnfs

sAMAccountType: 805306368

userPrincipalName: adtestnfs@csse.sso.edu.au

objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=csse,DC=sso,DC=edu,DC=

au

unixUserPassword: ABCD!efgh12345$67890

uid: adtestnfs

msSFU30Name: adtestnfs

msSFU30NisDomain: csse

uidNumber: 10000

gidNumber: 99000

unixHomeDirectory: /home/CSSE/adtestnfs/linux

loginShell: /bin/zsh

# refldap://ForestDnsZones.csse.sso.edu.au/DC=ForestDnsZones,DC=csse,DC=sso,D

C=edu,DC=au

# refldap://DomainDnsZones.csse.sso.edu.au/DC=DomainDnsZones,DC=csse,DC=sso,D

C=edu,DC=au

# refldap://csse.sso.edu.au/CN=Configuration,DC=csse,DC=sso,DC=edu,DC=au

You can query the AD via ldap effectively as a user which is a good sign, now we have to setup the client system to query the AD. Make sure your Linux distribution physically supports ldap pam query and authentication. In Fedora Core 10 it’s called nss_ldap_xxx but also known as libpam-ldap for other linux distros.

For Red Hat base system like Fedora core you can type “setup” at a terminal and choose authentication to have a GUI page for selecting and changing modules such as authentication method as shown in figure 5.

Figure 5: GUI Authentication Configuration

But I’m not going to do this as I know exactly what I want to do and this would be applicable for any other Unix / Linux distros out there.

First you need to do, is locate where the ldap configuration file is located, typically it is in /etc/ldap.conf but in the case of Fedora 10 there was also a /etc/openldap/ldap.conf. I just deleted one and sym linked them in ie

rm –rf /etc/openldap/ldap.conf

ln –s /etc/ldap.conf /etc/openldap/ldap.conf

I did this just as a precaution just in case they look for the ldap configuration file in either places.

Now we edit to the ldap.conf file to place some partial details for a system ldap query.

#/etc/ldap.conf

uri ldap://win2k3r2.csse.sso.edu.au:389

base dc=csse,dc=sso,dc=edu,dc=au

ldap_version 3

ssl no

Save the file and do another ldap search without specifying a ldap directory or ldap base which then should default to the specified in /etc/ldap.conf ie

ldapsearch –LLL –D ‘CSSE\administrator’ –w ‘ADtesting2009’ ‘(sAMAccount=adtestnfs)’ -x

Which should give the same result when you did the ldap previously with the below command.

ldapsearch -LLL -H ldap://win2k3r2.csse.sso.edu.au:389 -b 'dc=csse,dc=sso,dc=edu,dc=au' -D 'CSSE\administrator' -w 'ADtesting2009' '(sAMAccountName=adtest)' -x

Now we know that it should be functional we should fill in the rest of the details in the ldap.conf so the client system can bind automatically to the AD to do ldap queries.

#/etc/ldap.conf

uri ldap://win2k3r2.csse.sso.edu.au:389

base dc=csse,dc=sso,dc=edu,dc=au

ldap_versiob 3

ssl no

#Shouln't be using administrator should create guest account for bind

#Doing this as test purposes

base cn=Users,dc=csse,dc=sso,dc=edu,dc=au

binddn cn=administrator,cn=Users,dc=csse,dc=sso,dc=edu,dc=au

bindpw ADtesting2009

scope sub

timelimit 30

#New Style Binding

#If not sure do a list of the attributes then you can manually remap values

#ie do a full listing of ldapsearch then manually map values over if needed.

#ldapsearch -D "cn=administrator,cn=Users,dc=csse,dc=sso,dc=edu,dc=au" -W "sAMAccountName=adtestnfs" -x

nss_map_objectclass posixAccount user

nss_map_objectclass shadowAccount user

nss_map_objectclass posixGroup group

nss_map_attribute homedirectory unixHomeDirectory

#Old Stype Mappings MS SFU Unix tools

#nss_base_passwd cn=Users,dc=csse,dc=sso,dc=edu,dc=au?sub

#nss_base_shadow cn=Users,dc=csse,dc=sso,dc=edu,dc=au?sub

#nss_base_group cn=Users,dc=csse,dc=sso,dc=edu,dc=au?sub

#nss_map_objectclass posixAccount user

#nss_map_objectclass shadowAccount user

#nss_map_attribute uid sAMAccountName

#nss_map_attribute uidNumber msSFU30UidNumber

#nss_map_attribute gidNumber msSFU30GidNumber

#nss_map_attribute loginshell msSFU30LoginShell

#nss_map_attribute gecos name

#nss_map_attribute userPassword msSFU30Password

#nss_map_attribute homedirectory msSFU30Homedirectory

#nss_map_objectclass posixGroup Group

#nss_map_attribute uniqueMember msSFU30PosixMember

#nss_map_attribute cn cn

#pam_login_attribute sAMAccountName

#pam_filter objectclass=user

#pam_member_attribute msSFU30PosixMember

#pam_groupdn cn=unixusergroup,dc=csse,dc=sso,dc=edu,dc=au

#pam_password ad

Point to note you shouldn’t be using the administrator account to do lookups. You should create a generic account with extremely low permissions to do lookups on behalf of the systems.

That basically tells the system how to do directory lookups via ldap but you have to tell the system to actually use it.

You have to configure the PAM (Pluggable Authentication Model) to actually use the information for users and groups fro LDAP. You can use the built in GUI to modify the Authentication ie System -> Administration -> Authentication GUI or use “setup” from a terminal

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 if necessary.

# /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+ Use NIS+ (NIS version 3)

# nis or yp Use NIS (NIS version 2), also called YP

# dns Use DNS (Domain Name Service)

# files Use the local files

# db Use the local database (.db) files

# compat Use NIS on compat mode

# hesiod Use Hesiod for user lookups

# [NOTFOUND=return] Stop searching if not found so far

#

# To use db, put the "db" in front of "files" for entries you want to be

# looked up first in the databases

#

# Example:

#passwd: db files nisplus nis

#shadow: db files nisplus nis

#group: db files nisplus nis

passwd: files ldap

shadow: files ldap

group: files ldap

#hosts: db files nisplus nis dns

hosts: 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: files

netmasks: files

networks: files

protocols: files

rpc: files

services: files

netgroup: files ldap

publickey: nisplus

automount: files ldap

aliases: files ldap

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 ldap.

#%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_ldap.so use_first_pass

auth required pam_deny.so

account required pam_unix.so broken_shadow

account sufficient pam_localuser.so

account sufficient pam_succeed_if.so uid < 500 quiet

account [default=bad success=ok user_unknown=ignore] pam_ldap.so

account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3

password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok

password sufficient pam_ldap.so use_authtok

password required pam_deny.so

session optional pam_keyinit.so revoke

session required pam_limits.so

session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid

session required pam_unix.so

session optional pam_ldap.so

Now that you have made the changes you use the typical Unix / Linux test of “getent passwd” or “getent group” to see if you can your Linux / Unix enabled AD user.

As you can see in figure 6, I can see my AD test user with uid=10000 and gid=99000 as specified in the AD with the extended schema.

Figure 6 - LDAP getent passwd test

Now if you look at figure 7 which does the “getent group” test you also see it has sourced the group “linux” defined as 99000 as in the AD so we know it is functional.

Figure 7 - LDAP getent group test

Currently only the lookup information is working correctly, you have test whether actual PAM authentication by LDAP is working.

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 its not locked it down). You can see me do the ssh test in figure 8.

Figure 8 – ssh ldap test

This is the easiest way to test LDAP PAM authentication instead of logging in and out at the console. I wouldn’t worry about the missing home directory part ie

“/home/CSSE/adtestnfs/linux”

The reason for this error is that, we simply we haven’t configured the common shared home area as of yet via CIFS or NFS or the home area itself which will be detailed shortly.

Please Note all steps till now is exactly the same for Linux Client, steps after this point is only applicable for Linux CIFS / NFS server.

Serving the home area via CIFS is provided by Samba. With the newer revision of Samba, you have to actually join the Linux Machine to the Windows Domain so it can authenticate against the Active Directory. Previously you could just nominate the Domain Controller to authenticate against without joining the Domain. This is now a compulsory step with Samba 3.2.x I believe.

To join the my Fedora Core 10 Linux installation to the Active Directory, you will need to configure the Kerberos and samba files.

In Fedora Core 10, the kerberos file that needs to be configured is /etc/krb5.conf, it is case sensitive. Please 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 administrator@CSSE.SSO.EDU.AU

klist

Note it is case sensitive, as again “CSSE.CSSE.EDU.AU” refers to the Kerberos defined realm. What you should see is in Figure 9.

Figure 9: 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.

Please note although the steps are very similar in terms of Single Sign On with Winbind and Samba, there is a distinct difference. Winbind was used to generate consistent unique user / group mappings and authentication from the AD windows schema.

Whereas now we are using LDAP query to AD Unix schema components where the mappings are stored (not generated on the fly as with Winbind). You can think of one technology as client sided generated mappings whereas the other is a server sided mappings.

But these two methodology for Single Sign On still relies on Samba to provide the CIFS service for home areas. To do so, the linux CIFS/NFS aka fc10nfs.csse.sso.edu.au has to be joinet to the Active Directory Domain.

The other file you will need to edit is /etc/samba/smb.conf. This file configures the shares via CIFS though Samba and the authentication information from the AD.

Samba, the only section you need to edit is the “global” and “homes” section.

*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

log level = 1

syslog = 0

log file=/var/log/samba/%m

#Not Used -> Winbind Specifics

#allow trusted domains = No

#idmap backend = idmap_rid:CSSE=16777216-33554431

#idmap uid = 16777216-33554431

#idmap gid = 16777216-33554431

#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

#Winbind Specifics directives doesn’t work if you not using Winbind

#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

# template homedir

# Unhash below for linux server for cifs/nfs linux server

# Winbind Specifics directives doesn’t work if you not enabled Winbind

# Export User root home area

template homedir = /home/CSSE/%U

# Unhash below for linux client nfs home

# Winbind Specifics directives doesn’t work if you not enabled Winbind

# 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

I’ve stripped anything related to Winbind in the smb.conf file as these features are redundant and can’t be used with LDAP query to the AD Unix schema.

Values like “idmap uid”, “idmap uid”, “template homedir” etc are defunct as these values were not explicitely defined, but are generated consistently as required. Whereas the AD with the extended Unix schema, all these values are explicitely defined. That’s why I term Winbind as a client sided generated mappings vs LDAP bound AD Unix schema extension as server sided mappings.

But these two methodology for Single Sign On still relies on Samba to provide the CIFS service for home areas for certain client which still require a user has to authenticate against the AD. To do so the fc10nfs.csse.sso.edu.au has to be joined to the Active Directory Domain.

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 locahost,localdomain localhost

192.168.1.11 fc10nfs.csse.sso.edu.au fc10nfs

::1 localhost.localdomain localhost6 localhost

192.168.1.10 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 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 10.

Figure 10 : Joining a Linux Client to AD

One you have successfully joined the AD, start Samba

/etc/init.d/smbd start

/etc/init.d/nmbd start (Optional but windows uses netbios look ups)

You need to ensure 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 properly joined 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 11.

Figure 11 : Domain Lookup Information for Users and Groups

Now you know it that it has successfully joint to the domain as we can lookup domain users and groups. Note the “getent password” and “getent group” test will only show the users and groups with Unix attributes enabled as its LDAP binded / mapped to the AD Unix schema section and not to AD Windows schema.

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 the AD user called adtestnfs which had the following properties which define their home areas and mapped network drive

Windows Related Home Area

Profile -> \\fc10nfs.csse.sso.edu.au\adtestnfs\profile.usr”

(physically on the linux CIFS / NFS system it would be /home/CSSE/adtestnfs/profile.usr)

Map Network Drive -> \\fc10nfs.csse.sso.edu.au\adtestnfs

(physically on the linux CIFS / NFS system it would be /home/CSSE/adtestnfs)

Linux / Unix Related Home Area

Home Directory -> /home/CSSE/adtestnfs/linux

We already preconfigured authentication and home area via CIFS ie for Windows when we edited /etc/samba/smb.conf which was detailed under [homes] and [global] section.

You would think it was as simple as configuring the CIFS /NFS server with Winbind but I’m sorry to say it not especially if you want to separate the different system desktop area in its own directory. The only reason why it worked well with Winbind is because values like the home areas are not predefined on the server it mapped on the client side via the “template homedir” value.

That’s why you saw me define “template homedir = /home/CSSE/%U” on the server on fc10.sso.uwa.edu.au which exports the users root area and on the linux client side “template homedir = /home/CSSE/%U/linux” where as a user they log on and write into their linux directory.

We can’t do this in Samba if you are not using Winbind and depends on how you are bound to a Directory Service. In our case we basically treating LDAP bounded Unix enabled AD like any LDAP directory server.

For our test user when you type “getent passwd | grep -i adtestnfs”, you get something like this.

adtestnfs:*:10000:99000:AD Test:/home/CSSE/adtestnfs/linux/bin/zh

This basically tells that adtestnfs home area is /home/CSSE/adtestnfs/linux, so when you log into a linux client as adtestnfs it will write it’s files in the linux directory which is correct.

Now if we were to access the share via Samba which provides the CIFS service what you would get is

\\fc10nfs.csse.sso.edu.au\adtestnfs\profile.usr -> /home/csse/adtestnfs/linux/profile.usr

Which is wrong as Samba sees the root area of adtestnfs as /home/csse/adtestnfs/linux, what you want is this

\\fc10nfs.csse.sso.edu.au\adtestnfs\profile.usr -> /home/csse/adtestnfs/profile.usr

There is no variable which you can remap this as in with Winbind with the “template homedir” value, but there is a way around it by doing some tricky things.

First I relocate the storage area which is going to be the NFS exported area ie

/storage/CSSE. Ie this will be used to exported to NFS clients ie

/storage/CSSE -> /home/CSSE (NFS mounted Linux clients)

I create a sym linked directory on the CIFS / NFS server

/home/CSSE/adtest/linux -> /storage/CSSE/adtestnfs

This way anything accessing the area via CIFS though Samba will go to the users root area on the linux CIFS / NFS server. Now you get the idea just by reshuffling things I get the same effect. For multiple users its really trivial to script something up to create the user sym links.

Now do not get confused with the home area provided via CIFS and via NFS they are different methods for different client but yet point to the same home area for users.

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

To activate the CIFS service on fc10nfs.csse.uwa.edu.au to serve the home area out, we just have to start the smb service ie “/etc/init.d/smb start”. Depending how or what directory service you have bounded it will look what is defined as their home area (you should be able to see always by doing the “getent passwd” and look at the home area field if you are not sure). You should check it on to start at boot time as we already preconfigured it in the [homes] 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 /storage/CSSE to all of 192.168.1.xxx

/storage/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 these services at boot time, example in figure 11 shows “ntsysv” for Fedora Core 10 where you can selectively select service to start and run at boot time.

Figure 11 : “ntsysv” system startup services

Last of all I’ve assumed that you created the home areas for NFS traffic and placed the sym link area for CIFS else follow these steps

mkdir /storage

mkdir /storage/CSSE

chown root.root /storage

chown root.root /storage/CSSE

chown –R 755 /storage

cd /storage/CSSE

mkdir adtestnfs (repeat this and below for other users area)

mkdir adtestnfs/linux

mkdir adtestnfs/profile.usr

chown –R adtest adtestnfs

chmod –R 700 adtestnfs

mkdir /home

mkdir /home/CSSE

chown root.root /home

chown root.root /home/CSSE

chown –R 755 /home

cd /home/CSSE

mkdir adtestnfs (repeat this for others users area)

chmod 755 adtestnfs

ln –s /storage/CSSE/adtestnfs adtestnfs/linux

Then restart or reboot fc10nfs.csse.uwa.edu.au, after the reboot if everything is working nfs, nfslock, and smb services should be running and the home area permission should resolve to the appropriate users and groups. In figure 12 you can see me checking my adtestnfs user and it is resolving correctly against the AD.

Figure 12 : Status check of adtestnfs on fc10nfs.csse.sso.edu.au

For me to test if the CIFS service is functioning, I can test it on my w2k3r2 server by logging on and hitting run -> start and typing \\fc10nfs.csse.sso.edu.au which prompt me for a username / password which I placed in the details of my adtestnfs user which should pop up their home as a shares which I should be a able to see a linux and profile.usr directory such as that shown in Figure 13.

Figure 13 –CIFS access test via Samba for user

My last test to test the NFS server of the home area, the easiest way to mount the nfs exported area onto itself ie using the mount command from the terminal as seen in Figure 14.

Figure 14 – NFS Test mounting

Configuration of Linux Client

As I mentioned before, configuration of a linux client is very simple, all you need functioning the LDAP lookup and LDAP PAM authentication. Everything else in regards to CIFS, NFS, Samba, Kerboros is not needed so refer that section to get LDAP lookup and authentication going

The only other minor change is to make the home area via NFS from fc10.csse.sso.edu.au accessible on the client machine. I just force a mount on boot time which you can define in the /etc/fstab. Remember I had to shuffle everything on server and placed sym-links for cifs and nfs to play nice for Single Sign On.

#

# /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:/storage/CSSE /home/CSSE nfs rw,bg,hard,intr 0 0

In Figure 15, 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.

Figure 15 : 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 16, before I try logging into the console which does work.

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

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. Go Start > Settings -> Control Panel -> Network Connections

2. Click Advanced -> Network Identification

3. Go to “To rename or join a domain, Click Change” and click Change.

4. 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.

After typing \\fc10nfs.csse.uwa.edu.au and it doesn’t respond, make sure smb service is running and configured correctly on fc10nfs.

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. Macintosh HD -> Applications -> Utilities -> Directory Utility

2. Show Advanced Settings

3. Click Services Tab

4. Check the box for “Active Directory” to enable it

5. Then double click on Active Directory to configure it

6. For Active Directory Forest / Active Directory Domain was set to “csse.sso.edu.au”

7. Computer ID to “macosx”

8. Click the down arrow to Show Advanced Options

9. 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”

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)

//adtest@fc10nfs.csse.sso.edu.au/adtestnfs on /Network/Servers/fc10nfs.csse.sso.edu.au/adtest (smbfs, nodev, nosuid, automounted, mounted by adtest)

As the AD has extended Unix Schema, you can also bind the Mac client via LDAP as well and mount their home area via NFS as much as a traditional Unix / Linux client but you have to mapped individual fields like I did /etc/ldap.conf for the Linux / Unix clients but I’m assuming most Administrators would be competent to know which fields to map so I just going to leave this as a side note.

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.