Single Sign On LINUX Windows Active Directory

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.
Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

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
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
Windows client
Operating System : WinXPSP3
Hostname: winxpsp3
FQDN: winxpsp3.csse.sso.edu.au
IP Address: 192.168.1.23
Netmask: 255.255.255.0
(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.

Single Sign On LINUX Windows Active Directory

Hochgeladen von

Dokumentinformationen

Originalbeschreibung:

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Single Sign On LINUX Windows Active Directory

Hochgeladen von

Copyright:

Verfügbare Formate

Single Sign On / Authentication against Active Directory (Unix

Schema Extension) for Windows, Linux (via LDAP access to AD)

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

Linux NFS / CIFS server

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

Mac OSX client

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

Configuration of Windows Server

You will need to change the two followings.

Microsoft Network Server: Digitally sign communications (always) -> Disabled

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

Configuration of Linux NFS/CIFS Server

telnet win2k3r2.csse.sso.edu.au 389

ldapsearch -LLL -H ldap://win2k3r2.csse.sso.edu.au:389 -b 'dc=csse,dc=sso,dc=edu,dc=au' -D

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

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

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

Figure 5: GUI Authentication Configuration

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

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

ldapsearch -LLL -H ldap://win2k3r2.csse.sso.edu.au:389 -b 'dc=csse,dc=sso,dc=edu,dc=au' -D

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

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

#New Style Binding

#Old Stype Mappings MS SFU Unix tools

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

So what you want to do is edit /etc/nsswitch.conf and couple of PAM modules if

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

passwd: files ldap

#hosts: db files nisplus nis dns

# Example - obey only what nisplus tells us...

bootparams: nisplus [NOTFOUND=return] files

netgroup: files ldap

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

Now if we look at system-auth file ( /etc/pam.d/system-auth ), mine has been modified

account required pam_unix.so broken_shadow

password requisite pam_cracklib.so try_first_pass retry=3

session optional pam_keyinit.so revoke

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

Figure 6 - LDAP getent passwd test

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

Note it is case sensitive, as again “CSSE.CSSE.EDU.AU” refers to the Kerberos defined

Figure 9: Kerberos Ticket from AD server

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

# Generated by authconfig on 2009/10/31 21:45:35

#Not Used -> Winbind Specifics

#Ashley Personal Configuration files for home areas

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

# Unhash below for linux client nfs home

127.0.0.1 locahost,localdomain localhost

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

Figure 10 : Joining a Linux Client to AD

One you have successfully joined the AD, start Samba

Last Updated 20/11/2009, email ashley@csse.uwa.edu.au

Figure 11 : Domain Lookup Information for Users and Groups