Single Sign on LINUX windows active directory

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

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 [email protected])

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



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=e du,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=c sse,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\pr ofile.usr objectSid:: AQUAAAAAAAUVAAAAQW75C5ApCxTdxHWRWAQAAA== accountExpires: 9223372036854775807 logonCount: 24 sAMAccountName: adtestnfs sAMAccountType: 805306368 userPrincipalName: [email protected] 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=Fores tDnsZones,DC=csse,DC=sso,D C=edu,DC=au # refldap://DomainDnsZones.csse.sso.edu.au/DC=Domai nDnsZones,DC=csse,DC=sso,D C=edu,DC=au # refldap://csse.sso.edu.au/CN=Configuration,DC=css e,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 gues t 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 c an manually remap values #ie do a full listing of ldapsearch then manually m ap values over if needed. #ldapsearch -D "cn=administrator,cn=Users,dc=csse,d c=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=a u?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 msSFU30Homedirecto ry #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 beginni ng. # # The entry '[NOTFOUND=return]' means that the sear ch for an # entry should stop if the search in the previous e ntry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search c ontinues 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 Y P # 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 e ntries 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 auth config is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_fi rst_pass auth requisite pam_succeed_if.so uid >= 500 quiet auth sufficient pam_ldap.so use_first_pas s auth required pam_deny.so account required pam_unix.so broken_shadow account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 5 00 quiet account [default=bad success=ok user_unknown=ig nore] 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 nu llok 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 [email protected] 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-li ne--/--end-line--) # Any modification may be deleted or altered by aut hconfig 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-3355443 1 #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 disable d 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 n ot using Winbind #No default homedir value specified, the default ar ea is /home/%D/%U #Specifiy home area to separate Linux and Windows a rea 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 a nd %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 maintai ned under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/o r vol_id(8) for more info # /dev/sda2 / ext 3 defaults 1 1 tmpfs /dev/shm tmp fs defaults 0 0 devpts /dev/pts dev pts gid=5,mode=620 0 0 sysfs /sys sys fs defaults 0 0 proc /proc pro c defaults 0 0 /dev/sda1 swap swa p defaults 0 0 # Specific NFS Mounts fc10nfs.csse.sso.edu.au:/storage/CSSE /home/CSSE nf s 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, rea d-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 (sm bfs, 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.

Date post:	29-Dec-2014
Category:	Documents
Upload:	jayrod101
View:	354 times
Download:	2 times

Single Sign on LINUX windows active directory

Documents