Download pdf - 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.6

© April 2007, Kefa Rabah, Global Open Versity, Vancouver Canada www.globalopenversity.org A GOV Open Knowledge Access License Technical Publication

1

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

[email protected]

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

mailto:[email protected]

http://www.globalopenversity.org/



2

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



3

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

mailto:[email protected]

http://www.serengetisys.com/



4

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

http://www.scribd.com/doc/17731521/Using-Webmin-and-Bind9-to-Setup-DNS-Server-on-Linux-v12

http://www.scribd.com/doc/17731521/Using-Webmin-and-Bind9-to-Setup-DNS-Server-on-Linux-v12



5

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



6

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:

http://www.samba.org/samba/docs/man/Samba-HOWTO-Collection/compiling.html



7

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



8

[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 [email protected] Password for [email protected] 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: [email protected] Valid starting Expires Service principal 10/03/09 10:14:17 10/03/09 20:14:32 krbtgt/[email protected] 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:



9

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:



10

]# 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]



11

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 directory mask = 0700 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 directory 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



12

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 following procedure:

]# /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



13

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

following procedure: [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



14

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



15

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

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'



16

• 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



17

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/administrator:/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 LDAP server name: server02.medtech.com Realm: MEDTECH.COM Bind Path: dc=MEDTECH,dc=COM



18

LDAP port: 389 Server time: Sat, 03 Oct 2009 10:32:23 PDT KDC server: 192.168.83.10 Server time offset: 0

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



19

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



20

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.



21

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



22

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



23

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"



24

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



25

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



26

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



27

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:



28

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



29

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:



30

Fig. 20

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

Fig. 21



31

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



32

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.



33

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

http://rhe5/shared/



34

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



35

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.

http://www.linkedin.com/in/krabah

http://www.serengetisys.com/

http://www.globalopenversity.org/