Using Samba & Kerberos Technology For Mac OSX & AD-based SSO Identity Management v1.6

Global Open Versity Vancouver Canada Samba 3 Mac OSX and Windows AD SSO Integration HowTo v1.
Global Open Versity

Systems Integration Hands-on Linux Labs Training Manual
Using Samba & Kerberos Technology for Mac OSX & AD-based SSO
Identity Management
Kefa Rabah
Global Open Versity, Vancouver Canada
krabah@globalopenversity.org
www.globalopenversity.org
Table of Contents Page No.
USING SAMBA & KERBEROS TECHNOLOGY FOR MAC OSX & AD-BASED SSO
IDENTITY MANAGEMENT 3
1.0 Introduction 3
1.1 Our Implementing Plan 3
Part 1: Install and Check necessary packages 4
Part 2: Install & Configure Samba 3 5
Part 2: Install & Configure Kerberos 5 6

Step 1: Install Kerberos 6
Step 2: Server Clocks Synchronization 6
Step 3: Configure and Test Kerberos 7
Part 2: Use Winbind Authentication to Setup Samba-Windows Connectivity 9

Step 1: Configure Samba 10
Step 2: Add Users & Machines to Samba Account 12
Step 3: Add Users Profiles & Netlogon to Samba Account 13
Step 4: How to Delete Users from Your Samba Domain 14
Part 3: Enabling Windbind on Linux Box 14

Step 1: Modify /etc/nsswitch.conf. file 15
Step 2: (Re)starting Samba and Winbind 15
Part 4: Configure Pluggable Authentication Module (PAM) 18
Part 5: Accessing your Client & Server Machines 19

5.1 Connecting to a Samba Machine in Linux 20
5.2 Configuring Windows Machines 20
Step 1: Access Shares on the Windows desktop. 20
Step 2: Mounting shared drives on Windows 22
Step 3: Binding to the Domain Controller. 23
Step 4: Accessing Windows shares from the Linux node. 23
Step 5: Accessing Network Machines from Mac OS X 24
Part 6: Mac OS/Linux/Windows Single Sign-On 25
1
© April 2007, Kefa Rabah, Global Open Versity, Vancouver Canada
www.globalopenversity.org A GOV Open Knowledge Access License Technical Publication

Global Open Versity Vancouver Canada Samba 3 Mac OSX and Windows AD SSO Integration HowTo v1.6
Step 1: Configure DNS on Mac OS X 25

Step 2: Configure Directory Access: 26
Step 3: Join the AD Domain: 28
Step 4: Test it out: 32
Part 7: Easier Web Access to Shared Data 32
Part 8: SSH Support 33
Part 9: Rational for this System Integration 33

9.1 Windows Authentication 33
9.2 Linux Authentication 34
9.3 Samba and Windbind 34
9.4 Three Authentication Strategies 34
9.4.1 Using LDAP authentication: 34
9.4.2 Using LDAP and Kerberos 35
9.4.3 Using Winbind 35
2

Global Open Versity

Systems Integration Hands-on Labs Training Manual
Using Samba & Kerberos Technology for Mac OSX & AD-based SSO
Identity Management
By Kefa Rabah, krabah@globalopenversity.org Oct., 03, 2009 SerengetiSys Labs
1.0 Introduction
A popular thing to do with Samba these days is to join a Samba 3 host to a Windows Active Directory
domain using Kerberos ticketing. You may freely set up any number of Samba servers in a Windows
network and Mac OSX without joining them to the domain giving you the power of single-sign-on (SSO)
identity management to all your network resources. You can share files, map drives and provide
centralized printer services. The advantages of domain membership are central management and
authentication, and single sign-on. Using Winbind allows Linux clients to log on to the AD domain without
requiring local Linux system accounts, which is a lovely time- and hassle-saver. We have also joined Mac
OS X to the network to achieve a complete system integration of the three major operating systems.
1.1 Our Implementing Plan

Because of the enhanced integration with Active Directory (AD) and Mac OS X 10, I choose to use
Winbind on Red Hat Enterprise 5 (RHE5) for my Linux-to- Win 2k3 AD and Mac OSX integration project,
which is schematically represented by Fig. 1.
Fig. 1: A Samba, Windows-AD and Mac OS X systems integration network.
Figure 1 shows a simple network that would be one AD server, One Samba and a few client workstations,
connected through a router or switch (most home network routers have at least four ports of switch
3

included in the device). This grows over time, usually by adding more switches, routers, clients and
additional storage on the server.
This HowTo training manual we assume that you already have a functioning Win2k3 Active Directory
domain, and know how to run it. AD is very dependent on DNS (domain name system) so I'll assume your
DNS house is also in order, if not check out this excellent HowTo setup and configure a DNS server . On
your Linux box you'll need Samba 3, version 3.0.8 or newer. Plus MIT Kerberos 5, version 1.3.1 or newer,
and OpenLDAP. (The Samba documentation states that Heimdal Kerberos, version 0.6.3 or newer, also
works. The examples in this HowTo use MIT Kerberos.) Debian users need the krb5-user, krb5-config,
krb5-doc, and libkrb53 packages. Red Hat and Red Hat family users need the krb5 and krb5-client RPMs.
The following setup is used:
192.168.83.10 Server02.medtech.com the AD server, hereafter known as "the server"
192.168.83.33 rhe5.groptech.com samba3 "client" machine
The Samba system is based upon a stock standard RHE5 system with the samba 3 software.
The following steps are needed to get the system functioning:
1. install and check necessary packages

2. configure name resolution using either DNS or a hosts file
3. configure samba and winbind
4. configure kerberos
5. testing Samba and winbind
6. good luck
Part 1: Install and Check necessary packages

The following packages are required to successfully run all the commands detailed in this guide:
Samba:
1. system-config-samba
2. samba-common
3. samba-client
4. samba
Kerberos:
1. pam_krb5
2. krb5-workstation
3. krb5-client
4. krb5-libs
5. krbafs
You can query if these packages are installed by running:

rpm -q package-name
4

Part 2: Install & Configure Samba 3
First and foremost check if Samba is installed, as follows:
]# rpm –qa | grep samba* \\ the start * allows you to parse all
installed Samba files
[root@rhe5 ~]# rpm -qa | grep samba*

system-config-samba-1.2.39-1.el5
samba-common-3.0.28-1.el5_2.1
samba-swat-3.0.28-1.el5_2.1
samba-3.0.28-1.el5_2.1
samba-client-3.0.28-1.el5_2.1
In case you get blank result, then Samba is not installed. Best way to get Samba is to compile it from the
source file. However, I have found that the RPM files obtained via Yum, if you use CentOS4 and later,
Fedora Core 8 and later, or Yast with OpenSuse 11.1 contain all the required files. To install all Samba
files with RHE5, do the following:
[root@rhe5 ~]# yum install samba* -y
The next task is to verify that your Samba installation has been compiled to support Kerberos, LDAP,
Active Directory, and Winbind. Most likely it has, but you need to make sure. The smbd command
has a switch for printing build information. You will see a lot more lines of output than are shown here:
[root@rhe5 ~]# cd /usr/sbin

root@rhe5:/usr/sbin]# smbd -b | grep LDAP
HAVE_LDAP_H
HAVE_LDAP
HAVE_LDAP_DOMAIN2HOSTLIST
...
root@rhe5:/usr/sbin]# smbd -b | grep KRB

HAVE_KRB5_H
HAVE_ADDRTYPE_IN_KRB5_ADDRESS
HAVE_KRB5
...
root@rhe5:/usr/sbin]# smbd -b | grep ADS

WITH_ADS
WITH_ADS
root@rhe5:/usr/sbin]# smbd -b | grep WINBIND

WITH_WINBIND
WITH_WINBIND
5

Fortunately, in our case all the required support for Kerberos, ADS and Winbind is present. However, if
you are in the unfortunate position of missing any of these, which will be indicated by a blank line, you
need to recompile Samba, or installed per your Linux box as indicated above. Also, see Chapter 37 of the
Official Samba-3 HOWTO and Reference Guide.
Configure /etc/hosts
Even if your DNS servers are perfect in every way, it is always a good idea to add important servers to
your local /etc/hosts file. It speeds up lookups and provides a fallback in case the DNS servers go
down:
192.168.83.10 server02.medtech.com medtech
Part 2: Install & Configure Kerberos 5
Step 1: Install Kerberos

Our next task is to install Kerberos. Again as with Samba installation, you can compile Kerberos support
using source file or via RPM using Yum, Yast, or Apt depending on your Linux box. Here we have used
CentOS5 RPM via Yum. First verify if Kerberos is installed:
]# rpm –qa | grep krb* \\ the start * allows you to parse all installed krb files
[root@rhe5 ~]# rpm -qa | grep krb*

pam_krb5-2.2.14-1.el5_2.1
krb5-devel-1.6.1-25.el5_2.1
krb5-workstation-1.6.1-25.el5_2.1
krb5-server-1.6.1-25.el5_2.1
krb5-libs-1.6.1-25.el5_2.1
krb5-auth-dialog-0.7-1
If not, use Yum to install, as follows:
[root@rhe5 ~]# yum install krb* -y
The next task is to configure and test the Kerberos installation, but first we have to ensure that the
servers’ clocks are synchronized.
Step 2: Server Clocks Synchronization

Before moving to join your Linux box to AD server, check to make sure that the two machine’s clocks are
synchronized, as follows:
1. Set NET TIME on Win 2k3 DC to use to synchronize network clock:
6

1. On Linux SAMBA server, click System > Administration > Data & Time, then click Network Time
Protocol tab. Check "Enable Network Time Protocol",
2. Click button and enter our AD domain hostname: "server02.medtech.com", click OK to
close Date/Time Properties dialog box.
3. Next step is update NTP and also synchronize the server clocks:
]# ntpdate -u <server IP address>\\ or "sntp –r <server IP address>"
Note: Kerberos is very finicky if time difference is off by more than 5 minutes. So a simple test in our
case gave:
]# ntpdate -u 192.168.83.10
3 Oct 10:12:04 ntpdate[4268]: step time server 192.168.83.10 offset
7.988582 sec
• Which gives a poor time offset, repeat the same procedure again:
]# ntpdate -u 192.168.83.10
3 Oct 10:12:07 ntpdate[4269]: adjust time server 192.168.83.10 offset
0.003387 sec
• We’re now ok and good to go!
Step 3: Configure and Test Kerberos

Let's say our Active Directory domain server is server02.meddtech.com, and the Samba server is
named rhe5. This is the absolute minimum Kerberos configuration file, /etc/krb5.conf, for
connecting to this domain, as shown in Listing 1:
Listing 1: krb5.conf code

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
7

[libdefaults]
default_realm = MEDTECH.COM
clockskew = 300
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
forwardable = yes
[realms]
MEDTECH.COM = {
kdc = server02.medtech.com
admin_server = server02.medtech.com
}
[domain_realms]
medtech.com = MEDTECH.COM
.medtech.com = MEDTECH.COM
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
Very important: Use uppercase where it shows. Now try to connect, and mind your cases:
]# kinit Administrator@MEDTECH.COM
Password for Administrator@MEDTECH.COM
Now test to see if your krb5 infrastructure is working and able to provide the key exchange and
authentication. To do this, use klist command:
[root@rhe5 ~]# klist

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: Administrator@MEDTECH.COM
Valid starting Expires Service principal

10/03/09 10:14:17 10/03/09 20:14:32 krbtgt/MEDTECH.COM@MEDTECH.COM
renew until 10/04/09 10:14:17
Kerberos 4 ticket cache: /tmp/tkt0

klist: You have no tickets cached
Note: To destroy the krb ticket, use kdestroy command, followed by klist command to verify that indeed
the ticket has been destroyed.
Occasionally, you will be required to renew your Network Authentication Ticket if it expires, as shown in
the Fig. 2:
8

Fig. 2
Part 2: Use Winbind Authentication to Setup Samba-Windows Connectivity

The easiest way to connect Samba to Windows system is via Winbind. To achieve this perform the
following procedure:
1. Click System > Administration > Authentication, and then under User Information tab, check
Enable Winbind Support (a) Click Configure Winbind button to access Winbind Settings dialog
box (b), see Fig. 3.
2. From Winbind Settings dialog box (b), complete the settings as shown and click OK.
Fig. 3
3. Next let’s test if we managed to connect Windows AD domain, to achieve this issue the following
command:
9

]# net ads info

LDAP server: 192.168.83.10
LDAP server name: server02.medtech.com
Realm: MEDTECH.COM
Bind Path: dc=MEDTECH,dc=COM
LDAP port: 389
Server time: Sat, 03 Oct 2009 10:32:23 PDT
KDC server: 192.168.83.10
Server time offset: 0
Success! We can connect to our AD domain and pull some information about the server. The next step is
to clean-up and configure Samba to suit our requirements.
Step 1: Configure Samba

In this section we edit smb.conf file to meet our basic Samba-AD authentication requirements. In this
example the /etc/samba/smb.conf file shows our basic setup for a printer server and home shares.
Shares are configured in the usual manner, only the global section changes when you join to an AD
domain.
Listing 2: smb.conf code

# Global parameters
[global]
workgroup = MEDTECH
realm = MEDTECH.COM
security = ADS
password server = server02.medtech.com
username map = /etc/samba/smbusers
log file = /var/log/samba/%m.log
max log size = 0
printcap name = cups
addprinter command = /usr/bin/addprint
add user script = /usr/sbin/useradd -m %u
delete user script = /usr/sbin/userdel -r %u
add group script = /usr/sbin/groupadd %g
delete group script = /usr/sbin/groupdel %g
add user to group script = /usr/sbin/groupmod -A %u %g
delete user from group script = /usr/sbin/groupmod -R %u %g
add machine script = /usr/sbin/useradd -s /bin/false -d
/var/lib/nobody %u
logon path = \\%L\profiles\%U
logon drive = H:
logon home = \\%L\%U
os level = 65
preferred master = Yes
wins support = Yes
idmap uid = 15000-20000
idmap gid = 15000-20000
template shell = /bin/bash
winbind separator = +
winbind enum users = Yes
winbind enum groups = Yes
[homes]
10

comment = Home Directories

valid users = %D%U
read only = No
create mask = 0664
directory mask = 0775
browseable = No
[musicstore]
comment = Samba music center
path = /data/musicstore
valid users = krabah, root, @smbusers, "@MEDTECH+domain users"
read only = No
create mask = 0600
guest ok = Yes
[datastore]
comment = Samba data center
path = /data/datastore
valid users = krabah, root, @smbusers, "@MEDTECH+domain users"
read only = No
create mask = 0777
guest ok = Yes
[public]
comment = Samba Public files
path = /data/public
public = yes
write list = @smbusers, "@MEDTECH+domain users"
browseable = yes
[shared]
comment = Samba Totally open shared area
path = /data/shared
public = yes
read only = no
browseable = yes
[printers]
comment = All Printers
path = /var/spool/samba
printable = Yes
browseable = No
[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon
admin users = root
browseable = No
[Profiles]
comment = Roaming Profile Share
path = /var/lib/samba/profiles
read only = No
profile acls = Yes
11

Note: The important things to pay attention to here are the name of our samba machine (netbios name),
the workgroup, and the Active Directory stuff.
1. The workgroup is the name of your AD domain, in this case MEDTECH. Server string is a comment
describing the server, make this anything you want. Log level runs from 0, for no logging, to 10,
extreme logging. See man smbd.conf for the rest.
2. The shared directory /data/share is only for the users: krabah, root, @smbusers,
"@MEDTECH+domain users". It is writable which means the listed security users have read, write,
and execute permissions to the shared directory. Any files/directories created in the shared directory
will have the permission 0777 allow for universal permission to all domain security users.
3. The [public] and [shared] sections, which create the \\SERVER\public and
\\SERVER\shared are publicly shared directories, respectively (where, as usual, SERVER is the
name of your Samba server). These shares have nearly the same settings, but with one difference.
With the [public] share, only members of the Samba & domain users group (represented by the
@smbusers, "@MEDTECH+domain users")
Warning! You should only create a completely open share like the one here if you trust the
people who have access to your Samba server; open FTP servers, for example, have been
compromised in the past and abused as drop boxes for pirated software.
4. After you've added these shares to your smb.conf configuration file, remember to either restart
Samba or tell it to reload its configuration files, however, before doing that run the : testparm
command.
5. Save your changes and run testparm command to test your samba configuration:
]# testparm
6. This checks smb.conf for syntax errors. Any errors must be corrected before going ahead. Once all
is ok, you can start up Samba, as follows:
]# /etc/init.d/smb start \\ or "service smb restart"
Step 2: Add Users & Machines to Samba Account

1. Add new users (Zulu and Administrator & their password) to Samba account by performing the
]# /usr/sbin/useradd -g users -d /home/szulu -s /bin/bash -c "Shaka Zulu"

szulu
]# /usr/bin/smbpasswd -a szulu
]# /usr/sbin/useradd -g users -d /home/Administrator -s /bin/bash -c "Medtech

Administrator" Administrator
]# /usr/bin/smbpasswd -a Administrator
12

2. Add existing users (krabah, root and musicusers & their password) to Samba account by
performing the following procedure:
[root@rhe5 ~]# /usr/bin/smbpasswd -a krabah

[root@rhe5 ~]# /usr/bin/smbpasswd -a root
3. Add existing user: musicusers & password and enable its account by performing the following
procedure:
[root@rhe5 ~]# /usr/bin/smbpasswd -L -a musicusers

[root@rhe5 ~]# /usr/bin/smbpasswd -L -e musicusers
4. To add Machine accounts (e.g., WinXP ) & their password to Samba server by performing the
[root@rhe5 ~]# useradd -g users -d /dev/null -s /dev/null winxp01\$

[root@rhe5 ~]# smbpasswd -a -m winxp01
Step 3: Add Users Profiles & Netlogon to Samba Account

1. Add users’ (szulu, krabah, root & administrator) rooming profiles directories
]# mkdir -p /var/lib/samba/profiles/szulu
]#
]# chown szulu.users /var/lib/samba/profiles/szulu
]#
]# mkdir -p /var/lib/samba/profiles/krabah
]#
]# chown krabah.users /var/lib/samba/profiles/krabah
]#
]# mkdir -p /var/lib/samba/profiles/root
]#
]# chown root.users /var/lib/samba/profiles/root
]#
]# mkdir -p /var/lib/samba/profiles/Administrator
]#
]# chown Administrator.users /var/lib/samba/profiles/Administrator
2. Make rooming profile directory writeable
[root@rhe5 ~]# chmod 777 /var/lib/samba/profiles
3. Add Netlogon directory and make it writeable
[root@rhe5 ~]# mkdir -p /var/lib/samba/netlogon

[root@rhe5 ~]# chmod 755 /var/lib/samba/netlogon
13

4. Add musicstore and datastore directories
[root@rhe5 ~]# mkdir -p /data/datastore

[root@rhe5 ~]# mkdir -p /data/musicstore
[root@rhe5 ~]# chmod 755 /data/datastore
[root@rhe5 ~]# chmod 755 /data/musicstore
5. Issue ldconfig command:
[root@rhe5 ~]# ldconfig
Note: ldconfig creates the necessary links and cache to the most recent shared libraries found in the
directories specified on the command line.
6. Restart Samba (smb) service:
[root@rhe5 ~]# service smb restart
Note:
1. chmod 755 means read and execute access for everyone and also write access for the owner of the
file.
2. chmod 777 makes files writeable.
7. The next step is to enable Winbind on Linux.
Step 4: How to Delete Users from Your Samba Domain
Deleting users from your Samba domain is a two stage process in which you have to remove the user
from the Linux server and also remove the user's corresponding smbpasswd entry. Here's how:
1. Delete the users using the smbpasswd with the -x switch
[root@rhe5 ~]# smbpasswd -x kjude

Deleted user kjude.
[root@rhe5 ~]#
2. Delete the Linux User by following the normal deletion process. For example, to delete the user kjude
and all her files from the Linux server use:
[root@rhe5 ~]# userdel -r kjude
Sometimes you may not want to delete the user's files so that they can be accessed by other users at
some other time. In this case you can just deactivate the user's account using the passwd -l username
command.
Part 3: Enabling Windbind on Linux Box
14

Step 1: Modify /etc/nsswitch.conf. file
1. Debian & OpenSuse users may need to install the winbind package separately. For OpenSuse
users, they can install winbind using (yast -i samba-winbind). RPM users will find it in the
samba-common RPM. First, using your favorite text editor, edit /etc/nsswitch.conf. The first
three lines are the most important; the others vary according to your system:
passwd: compat winbind

group: compat winbind
shadow: compat winbind
hosts: files dns winbind
networks: files dns
protocols: db files
services: db files
ethers: db files
rpc: db files
2. Save your changes, and fire up Winbind and Samba.
Step 2: (Re)starting Samba and Winbind

1. First we test our Samba configuration and our winbind settings, before proceed to modify our samba
startup script. Perform the following procedure to fire winbind and samba (smb):
]# /etc/init.d/smb start
]# /etc/init.d/winbind start
2. Now we have a time offset that is ok, which upon testing using net ads info gives a zero time
offset:
]# net ads info

LDAP server: 192.168.83.10
Realm: MEDTECH.COM
LDAP port: 389
KDC server: 192.168.83.10
3. Finally, join your Samba Linux box to Active Directory using net command as follows:
]# net ads join -U Administrator

Enter Administrator's password:
Using short domain name -- MEDTECH
Joined 'rhe5' to realm 'medtech.com'
15

• Hurrah! Success. The Samba box will now appear as a machine account under "Computers" in
your “AD Users and Computers” console. Now stop Samba until the final steps are
completed.
4. First check to see if our winbindd is actually running using:
]# ps fax | grep winbindd
5. Next verify that windbind is working and able to communicate and get some information off our AD
domain controller. The following commands verify RPC status and pull lists of users and groups from
the AD domain controller:
# wbinfo -t
checking the trust secret via RPC calls succeeded
6. Next test using wbinfo -u command, and we should get a list of users in the format
"MEDTECH+<username>" as follows
# wbinfo -u
RHE5+krabah
RHE5+szulu
RHE5+musicusers
RHE5+administrator
MEDTECH+administrator
MEDTECH+guest
MEDTECH+support_388945a0
MEDTECH+krbtgt
MEDTECH+dsmith
MEDTECH+rgomez
MEDTECH+root
MEDTECH+iusr_server02
MEDTECH+iwam_server02
MEDTECH+krabah
MEDTECH+mwong
MEDTECH+8edae942-8bab-4f97-9
MEDTECH+fds
MEDTECH+sqlservice
7. And we do the same for our list of groups:
]# wbinfo -g
MEDTECH+domain computers
MEDTECH+domain controllers
MEDTECH+schema admins
MEDTECH+enterprise admins
MEDTECH+domain admins
16

MEDTECH+domain users
MEDTECH+domain guests
MEDTECH+group policy creator owners
MEDTECH+dnsupdateproxy
MEDTECH+engineering gg
MEDTECH+sales gg
MEDTECH+human resources gg
MEDTECH+exchange domain servers
MEDTECH+medtech staff
MEDTECH+medtech students
8. We can now use the getent utility to get a unified list of both the local Linux samba box and DC
users and groups. That is, it verifies that indeed the logins and passwords are coming from the AD
server, and not the local machine. When run, it generates a list of data similar in format to the Linux
/etc/passwd and /etc/group files respectively.
]# getent passwd
MEDTECH+administrator:*:10000:10004:Administrator:/home/MEDTECH/administrat
or:/bin/bash
9. And for group password use:
]# /usr/bin/getent group
• If winbind is not working and local authentication is still active, they will not have the MEDTECH\
prefix.
10. It is now a good idea to do one more test to ensure your Active Directory usernames are valid on the
Samba box system. Try the following:
]# chown "MEDTECH+username" filename
• (where MEDTECH is the active directory short name)

• Note: If 'wbinfo -u' and 'getent passwd' work fine but your chown says this is an unknown
user, you probably have NSCD running. You should disable NSCD and restart winbind. (See
http://us4.samba.org/samba/docs/man/winbind.html#id2958310 for more)
11. After this we can fix up our init.d startup scripts to automate the startup of winbindd and not start
NSCD.
12. Finally, as root run net ads info command to display the AD domain server information.
]# net ads info

LDAP server: 192.168.83.10
Realm: MEDTECH.COM
17

LDAP port: 389

KDC server: 192.168.83.10
Part 4: Configure Pluggable Authentication Module (PAM)

Warning: Before you do anything at all here, you need to make a backup of our /etc/pam.d/* files. Or
if you’re using VMware like men then backup your current image before we proceed. And also have a
Linux bootdisk available if possible just in case! If anything goes wrong here, you may not be able to
login to your Linux system properly. (So don't reboot or logoff to test, but use a text console)
1. Modify /etc/pam.d/samba (on woody) or the appropriate pam file to add "sufficient" for auth
and account using pam_winbind.so. These need to go BEFORE the pam_unix.so calls for
samba. My /etc/pam.d/samba is as follows:
auth sufficient pam_winbind.so

auth required pam_unix.so nullok
account sufficient pam_winbind.so
account required pam_unix.so
session required pam_unix.so
password required pam_unix.so
2. Modify /etc/nsswitch.conf with the following:
passwd: winbind compat

group: winbind compat
shadow: winbind compat
3. Finally, to have our ActiveDirectory users be able to login to our server, we have to modify our
/etc/pam.d/login as follows:
#%PAM-1.0
auth required pam_securetty.so
auth sufficient pam_winbind.so
auth sufficient pam_unix.so use_first_pass
auth required pam_stack.so service=system-auth
auth required pam_nologin.so
account sufficient pam_winbind.so
account required pam_stack.so service=system-auth
password required pam_stack.so service=system-auth
session required pam_stack.so service=system-auth
session optional pam_console.so
4. 11. It is useful to add an extra entry to the file /etc/pam.d/system-auth to enable the creation of
home directories on first login to the Linux system by a user. In the session section of this file towards
the end, add the line:
session required pam_mkhomedir.so skel=/etc/skel umask=0022
18

After we save this file, we should now be able to login to our Linux machine with the username
MEDTECH+Administrator, and get yourself a login prompt. Now the system may complain if you do
not have the specified home directory created (in this case /home/MEDTECH/Administrator)
5. Restart samba and winbind.

6. Logout and try to login as: MEDTECH+Administrator, which works ash shown in Fig. 4.
Fig. 4
7. Voila! All is working. :) Browse your server and see...
Part 5: Accessing your Client & Server Machines

1. Within Linux Samba server you can access your Network location machines as shown in the Fig. 5.
Fig. 5
19

2. From the Windows Network your can access other network machines’ shares form both Windows and
Mac machines as shown in Fig. 6.
Fig. 6
5.1 Connecting to a Samba Machine in Linux

To connect to a Samba machine (Windows or Linux running Samba) from the command line, execute
the command (replace MACHINENAME and sharename with the appropriate values)
# smbclient //MACHINENAME/sharename
If you want to pass a different username to the Samba Server, execute the command (replace
username with your username).
# smbclient //MACHINENAME/sharename -U username
If a password is associated with the username, you will be prompted for it. Once you are authorized
by the SMB protocol, you will be at a smb: \> prompt. This is similar to an ftp session where get, put,
pwd, ls, etc. can be used to navigate. Type help for a list of commands.
5.2 Configuring Windows Machines

Connect to a Linux machine running Samba the same way you connect to any Windows machine -
browse through Network Neighborhood or Windows Explorer entering a password if required. Note:
Windows 9x only prompts for a password and assumes the Windows Login name as the username.
You need to either create a user on your Linux box with your Windows Login or create a Windows
Login with the same username on your Linux machine. Optionally, you can have the Windows Login
and password for Windows 9x/NT/2000 to be the same as your Linux machine Samba username and
password and it will not prompt for a password. Obviously, this is a security issue if others have
access to your system. Be warned! For security reason, upgrade to Win XP/Vista clients, which
prompts you for username and password each time you attempt to logon.
Step 1: Access Shares on the Windows desktop.

3. From Windows machines go to Entire Networks > Microsoft Windows Network to locate all
the Samba-Windows integrated network machines as shown in Fig. 7:
• Browsing and accessing the SMB shares from a Windows machine. On a Windows machine, click
on "My Network Places"; click on "Entire Contents"; Microsoft Windows Network;
choose the Domain you specified in smb.conf; choose the SMB server; provide user name and
password of any user who has an account in smbpasswd. In the new window, you should see the
home directory content on the SMB server.
20

• To log to any machine, just double-click its icon and provide your proper credentials and you’re
good to go.
Fig. 7
4. You can access the resources on RHE5 (Samba server) just as you do with Windows WORKGROUP, Fig. 8. In
this case I had logged in as root user, as is indicated by root folder.
21

Fig. 8
Step 2: Mounting shared drives on Windows

Right click on "My Computer"; choose "Map network drive"; choose drive letter, for
example, F; for the folder, type \\rhe5\datastore; provide user name and password. You
should see a new drive F appeared in folder My Computer, see Fig. 9.
Fig. 9
• Unmounting shared drives.

Right click on "My Computer"; choose "Disconnect Network Drive"; select the Drive to
disconnect; OK.
• Mounting and Unmounting shared drives can also be done through DOS prompt.
- To mount share homes from rhe5:
net use F: \\rhe5\datastore /USER:krabah
- To check what shares are mounted:

net use
- To unmount the share:

net use F: /delete
22

Step 3: Binding to the Domain Controller.
• Right click on "My Computer"; slide to Properties; choose Network Identification;
• Click on Properties; check-in Member of Domain; type-in the Domain Name, which you have
specified on the Samba server; OK.
• When you reboot the machine, you should be able to logon to the Domain with your user name
and password stored on the Samba server.
• You home directory would be mapped as drive Z. When you logon to the Domain at first time,
Windows creates folder profile in your home directory.
Step 4: Accessing Windows shares from the Linux node.
• Your Samba server can act as an SMB client accessing Windows shares.
• For example, create a new folder, C:\win2k3-shares, on your Windows computer.
• Right click on folder shares; choose sharing; check-in Share this folder; name it "win2k3-shares";
click on Permissions; Add; in MEDTECH domain put your login name and password; add also
Administrator; click Apply; OK.
• Create some text file in folder C:\win2k3-shares.
1. Mounting Windows shared drives on Linux:

# mkdir /mnt/smb
# mount -t smbfs -o username="SERVER02\Administrator",passwd=password

//SERVER02/win2k3-shares /mnt/smb
# df -h
• Check the content of directory /mnt/smb.
• Unmount it:
# umount /mnt/smb
• Mount the directory again accessing it as a Domain user:
# mount -t smbfs -o username=krabah,passwd=mypassword //server02/win2k3-

shares /mnt/smb
# df -h
• Then unmount it, umount /mnt/smb
2. Run SMB client on the Linux machine:

# smbclient //srver02/win2k3-shares -U "SERVER02\Administrator"
23

Type-in password
• To exit, type "quit" at the prompt:

smb: \> quit
• Access it again as a Domain user:

# smbclient //server02/win2k3-shares -U krabah
• To see the list of the commands, type "help" or "?"

# smb: \> help
# smb: \> quit
Step 5: Accessing Network Machines from Mac OS X

It is important that the account you log in with on your XP system has a password set, if it does not you
will not be able to login to your Windows share from OS X.
1. Mac OS X has built-in capabilities through Samba to play nicely with Windows & Linux networks. An
early step to working seamlessly with a Windows workgroup is joining that network.
2. Open the Directory Access utility (under Applications -> Utilities).
3. If the window is locked (padlock closed on the lower left), click on the padlock to unlock it.
4. Select SMB and click Configure…
5. Type in the name of the desired workgroup in the Workgroup field, e.g., in our case MEDTECH, enter
a WINS server (if appropriate) and click OK, then Apply.
5. Alternatively, from Mac OSX server you can access your other network machines. Click Go menu >
Connect to Server …. Enter the smb://<samba – IP address> to access your Network servers
as shown in the Fig. 10.
Fig. 10: Mac OSX Desktop
24

6. Enjoy and have fun – from Linux Samba – Windows – to Mac OSX!
Part 6: Mac OS/Linux/Windows Single Sign-On

Step 1: Configure DNS on Mac OS X
To find networking information on a Mac running OS X 10.4 (Tiger), navigate to the Network
Preferences panel.
1. Go to the Apple Menu, then select System Preferences, see Fig. 11.
Fig. 11
2. In the Internet & Network, click Network to access the Network dialog box, Fig.
3. In the TCP/IP configuration of your network device, add a DNS server and Search domain for
local DNS resolution, see Fig. 12:
Fig. 12
25

Step 2: Configure Directory Access:

1. Open the Directory Access utility (under Applications -> Utilities). In the Services screen,
highlight Active Directory and click Configure, see Fig. 13:
Fig. 13
2. In the Active Directory configuration, enter the Domain name and Computer name:
Fig. 14
26

3. Under Advanced Options, User Experience, set home location to use SMB, and set default user
shell /bin/bash, see Fig. 15.
Fig. 15
4. Under the Administrative Advanced Options, allow administration by domain and enterprise
admins, and allow authentication from any domain in the forest, see Fig. 16:
27

Fig. 16
Step 3: Join the AD Domain:

1. Click Bind to join the Mac to the Windows Domain. Enter username and password of a Windows
user that has permission to join a computer to the domain. Check options to use AD for
authentication and contacts, see Fig. 17.
Fig. 17
28

2. You will get warning alert as shown in Fig 18; click OK to access Fig. 19.
Fig. 18
Fig. 19
3. Under Directory Access, Authentication, make sure Active Directory is in the search path, see
Fig. 20:
29

Fig. 20
4. Under Directory Access, Contacts, make sure Active Directory is in the search path, see Fig. 21:
Fig. 21
30

4. Under Directory Access, Services tab, configure SMB/CIFS, adding the Workgroup name and WINS
server address, see Fig. 22:
Fig. 22
Step 3: Configure login options:
1. Launch System Preferences, System > Accounts. Under Login Options, uncheck ‘Automatically
login’, and choose ‘Display login window as: Name and password’, see Fig. 23
Fig. 23
31

Step 4: Test it out:

1. Restart and login using domain\user username format. In this example, the login name is
medtech\krabah. The user’s network home folder will automount and appear as a folder on the
dock:
You’re done – and good to go.
Stay tuned as I will continue to update this article from time to time!
Part 7: Easier Web Access to Shared Data

Now things should be working well for systems and users that want to log on to the Samba server;
however, you also want to provide access through Web browsers so anyone can download files from your
public shares. Recall that earlier in Listing 2; we had created two shared directories: /data/shared and
/data/public. To have them accessible via the Web, you'll need to add the shares to the Apache Web
server that you have running on your Samba server.
Locate your httpd.conf file (mine is in /etc/httpd/conf) and add the code shown in Listing 3.
These two declarations, <Alias> and <Directory>, create http://server/public/ and
http://server/shared/ on the server, turn on fancy directory listings, and allow access from any
Web browser.
Listing 3: Web access to the public shares
Alias /public/ "/data/public/"

<Directory "/data/public">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
Alias /shared/ "/data/shared/"
<Directory "/data/shared">
Options Indexes MultiViews
AllowOverride None
Order allow,deny
Allow from all
</Directory>
Save the file and use the apachectl or httpd command to tell Apache to reload its configuration file
and activate the new URLs.
32

# service httpd restart \\ or /usr/sbin/apachectl restart
In addition to having convenient Samba access to these shared directories, they're accessible to anyone
with a Web browser. Figure 11 shows shared data accessibility via Web browser: http://rhe5/shared/ .
Fig. 11
Part 8: SSH Support
Do the same additions that you made to /etc/pam.d/login to /etc/pam.d/sshd to support logins
via SSH.
Part 9: Rational for this System Integration

This rational is kept at the end of the HowTo to avoid cluttering the real work for those who are not
interested in lots of reading and would rather dive into the real stuff right-away!
9.1 Windows Authentication

Windows has shipped with integrated authentication and single sign-on (SSO) system for quite some time
now. Before Windows 2000, Windows NT domain controllers (DCs) provided authentication services to
the Windows clients using the NT LAN Manager (NTLM) protocol. Although, it is very helpful because it
neatly solved the problem of needing to maintain duplicate user accounts across multiple servers on the
network.
33

Starting with Windows 2000, Microsoft moved from NTLM to Active Directory (AD) and its integrated
Kerberos authentication services. Kerberos was considerably more secure than NTLM, and it scaled
better, too. And Kerberos was an industry standard already used by Linux and UNIX systems, which
opened the door to integrating with those platforms with Windows.
9.2 Linux Authentication

Originally, Linux (and the GNU tools and libraries that run on it) was not built with a single authentication
mechanism in mind. As a result, Linux application developers generally tool to creating their own
authentication scheme. They managed to accomplish this by either looking up names and password
hashes in /etc/passwd (the traditional text file containing Linux users credentials) or providing and entirely
(and separate) mechanism.
The resulting plethora of authentication mechanism was unmanageable. In 1995, Sun proposed a
mechanism called Pluggable Authentication Modules (PAM). PAM provided a common set of
authentication APIs that all application developers could use, along an administrator-configured back end
that allowed for multiple “pluggable” schemes. By using the PAM APIs for authentication and Name
Servers Switch (NSS) APIs for looking up user information, Linux application developers could write could
have a single place to configure and manage the authentication process.
Most Linux distributions come with several PAM authentication modules, including modules that support
authentication to an LDAP directory and the authentication using Kerberos. You can use these modules to
authenticate to AD, but there are some significant limitations as we will later in the text.
9.3 Samba and Windbind

Samba (www.samba.org) is an open-source project that aims to provide integration between Windows
and Linux environments. Samba contains components that give Linux machines access to Windows file
and print servers as well as provide Linux-based service that emulate Windows NT 4.0 DCs. Using the
Samba client components, Linux machines can take advantage of Windows authentication services
provided by Windows Active Directory DCs.
The particular part of Samba that is most interesting to us for this project is called Windows Winbind.
Winbind is daemon (service in Windows parlance) that runs on Samba clients and acts like a proxy for
communication between PAM and NSS running on the Linux machine and Active Directory on a DC. In
particular, Winbind uses Kerberos and LDAP to retrieve user and group information. Winbind also
provides additional services such as the ability to locate DCs using an algorithm similar to the
DCLOCATOR in AD and the ability to reset AD passwords by communicating with a DC using RPC.
Winbind solves a few problems that simply using Kerberos with PAM doesn’t. In particular, instead of
hard-coding a DC to authenticate to the way the PAM Kerberos module does, Winbind selects a DC by
searching DNS locator records similar to the way the Microsoft DC LOCATOR module does.
9.4 Three Authentication Strategies

Given the availability of LDAP, Kerberos and Winbind on Linux machines, there are three different
implementation strategies we can employ to allow our Linux machine to use AD for authentication.
9.4.1 Using LDAP authentication:

The easiest but least satisfactory way to use AD for authentication is to configure PAM to use LDAP
authentication, as shown in Fig. 1. Although AD is an LDAPv3 service – Windows clients use Kerberos
(with fallback to NTLM), not LDAP, for authentication purposes.
LDAP authentication (called LDAP binding) passes the username and password in cleartext over the
network. This is insecure and unacceptable for most purposes. The only way to mitigate this risk of
passing credential in the clear is to encrypt the client-Active directory communication channel using
34

something such as SSL. While this certainly doable, it imposes the additional burden of managing the SSL
certificates on both the DC and Linux machines. Furthermore, using the PAM-LDAP module does not
support change, reset or expired passwords.
9.4.2 Using LDAP and Kerberos

Another strategy for leveraging AD for Linux authentication is to configure PAM to use Kerberos
authentication and NSS to use LDAP to lookup user and group information, as shown in Fig. 2. This
scheme has the advantage of being relatively more secure, and it leverages the “in-the-box” capabilities of
Linux. But it doesn’t take advantage of the DNS Service Locater (SRV) records that Active Directory DCs
publish, so you are forced to pick a specific set of DCs to authenticate to. It also doesn’t provide a very
intuitive way of managing expiring AD passwords or, until recently, for proper group membership lookups.
9.4.3 Using Winbind

The third way to use AD for Linux authentication is to configure PAM and NSS to make calls to the
Winbind daemon. Winbind will translate the different PAM and NSS requests into the corresponding AD
calls, using either LDAP, Kerberos or RPC, depending on which is most appropriate. Figure 3 shows this
strategy.
Have fun
And congrats it works, if you want to configure further items such as mail and other things you may need
to modify the appropriate PAM modules, and isn't covered here.
Stay tuned – this lab module will be regularly updated to make it more practical for business applications.
-----------------------------------------------
Kefa Rabah is the Founder and CIO, of Serengeti Systems Group Inc. Kefa is knowledgeable in
several fields of Science & Technology, IT Security Compliance and Project Management, and
Renewable Energy Systems. He is also the founder of Global Open Versity, a Center of Excellence
in eLearning.
35

Using Samba & Kerberos Technology For Mac OSX & AD-based SSO Identity Management v1.6

Hochgeladen von

Dokumentinformationen

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

Using Samba & Kerberos Technology For Mac OSX & AD-based SSO Identity Management v1.6

Hochgeladen von

Copyright:

Verfügbare Formate

Global Open Versity Vancouver Canada Samba 3 Mac OSX and Windows AD SSO Integration HowTo v1.

Global Open Versity

Table of Contents Page No.

Part 1: Install and Check necessary packages 4

Part 2: Install & Configure Samba 3 5

Part 2: Install & Configure Kerberos 5 6

Part 2: Use Winbind Authentication to Setup Samba-Windows Connectivity 9

Part 3: Enabling Windbind on Linux Box 14

Part 4: Configure Pluggable Authentication Module (PAM) 18

Part 5: Accessing your Client & Server Machines 19

Part 6: Mac OS/Linux/Windows Single Sign-On 25

www.globalopenversity.org A GOV Open Knowledge Access License Technical Publication

Step 1: Configure DNS on Mac OS X 25

Part 7: Easier Web Access to Shared Data 32

Part 8: SSH Support 33

Part 9: Rational for this System Integration 33

www.globalopenversity.org A GOV Open Knowledge Access License Technical Publication

Global Open Versity

By Kefa Rabah, krabah@globalopenversity.org Oct., 03, 2009 SerengetiSys Labs

1.1 Our Implementing Plan

Fig. 1: A Samba, Windows-AD and Mac OS X systems integration network.

www.globalopenversity.org A GOV Open Knowledge Access License Technical Publication

The following setup is used:

192.168.83.10 Server02.medtech.com the AD server, hereafter known as "the server"

192.168.83.33 rhe5.groptech.com samba3 "client" machine

The following steps are needed to get the system functioning:

1. install and check necessary packages

Part 1: Install and Check necessary packages

You can query if these packages are installed by running:

www.globalopenversity.org A GOV Open Knowledge Access License Technical Publication

Part 2: Install & Configure Samba 3

First and foremost check if Samba is installed, as follows:

[root@rhe5 ~]# rpm -qa | grep samba*

[root@rhe5 ~]# yum install samba* -y

[root@rhe5 ~]# cd /usr/sbin

root@rhe5:/usr/sbin]# smbd -b | grep KRB

root@rhe5:/usr/sbin]# smbd -b | grep ADS

root@rhe5:/usr/sbin]# smbd -b | grep WINBIND

www.globalopenversity.org A GOV Open Knowledge Access License Technical Publication

192.168.83.10 server02.medtech.com medtech

Part 2: Install & Configure Kerberos 5

Step 1: Install Kerberos

[root@rhe5 ~]# rpm -qa | grep krb*

If not, use Yum to install, as follows:

[root@rhe5 ~]# yum install krb* -y

Step 2: Server Clocks Synchronization

1. Set NET TIME on Win 2k3 DC to use to synchronize network clock:

www.globalopenversity.org A GOV Open Knowledge Access License Technical Publication

]# ntpdate -u <server IP address>\\ or "sntp –r <server IP address>"

• We’re now ok and good to go!

Step 3: Configure and Test Kerberos

Listing 1: krb5.conf code

www.globalopenversity.org A GOV Open Knowledge Access License Technical Publication

[root@rhe5 ~]# klist

Valid starting Expires Service principal

Kerberos 4 ticket cache: /tmp/tkt0

www.globalopenversity.org A GOV Open Knowledge Access License Technical Publication

Part 2: Use Winbind Authentication to Setup Samba-Windows Connectivity

www.globalopenversity.org A GOV Open Knowledge Access License Technical Publication

]# net ads info

Step 1: Configure Samba

Listing 2: smb.conf code

www.globalopenversity.org A GOV Open Knowledge Access License Technical Publication