How to Authenticate a SAMBA Server as a Domain Member of the CSCF Active Directory.

This is an outline for how to join a SAMBA 3.0 server (the samba-3.0 xhier package) to an Active directory domain such that the SAMBA server will utilize kerberos authentication (through the AD domain) for client access of SAMBA services. Essentially, we will be making the SAMBA server a member of a kerberos realm which is generated by an Active Directory domain. For this example, that domain will be CS-TEACHING (see ADForestLayout) also known as the STUDENT.CS.UWATERLOO.CA realm.

The SAMBA server does not need to be running during any part of this procedure and may be started later if desired.

We will assume that the xhier package samba-3.0 and its dependencies (including a kerberos and an ldap client) are installed and samba-3.0 is asserted as the default samba package on the system hosting the SAMBA server. With these packages installed, two files must be created/edited in preparation for the SAMBA server to join a domain in the Active Directory as a kerberos client.

SAMBA Server Configuration

The first file is SAMBA's own configuration file smb.conf. Below are listed the essential configuration entries for making the SAMBA server a kerberos realm member. All of these entries are listed in the [global] section of the smb.conf file. Other entries such as service definitions are not listed here.

/software/samba/config/local/smb.conf:

[global]
   encrypted passwords = yes
   domain master = no
   preferred master = no

   ; These following lines are to set up samba to function as a member
   ; of the CS-TEACHING domain in the CSCF Active Directory.
   ; This domain is also known as the STUDENT.CS.UWATERLOO.CA kerberos
   ; realm
   ;
   ; NOTE: Since security is set to ADS, the value of
   ;       encrypted passwords must be set to yes.
   ;
   security = ADS   
   realm = STUDENT.CS.UWATERLOO.CA
   workgroup = CS-TEACHING
   announce as = CS-TEACHING - Samba 3.0 Server
   password server = eponina.student.cs.uwaterloo.ca cyanea.student.cs.uwaterloo.ca canadenis.student.cs.uwaterloo.ca
   ldap suffix = dc=student,dc=cs,dc=uwaterloo,dc=ca
   log level = all:3
   max log size = 760000
   comment = Samba 3.0 Testing Server for CS-TEACHING Domain - Not In Full Production
   ;
   ; We are interested in ensuring that the SAMBA server uses kerberos (Simple and
   ; Protected NEGOciation) only for client authentication.
   ;
   client use spnego = yes
   use spnego = yes
   ;
   ; We do not support Windows 95/98/ME anymore so this SAMBA server will not use
   ; LANMAN authentication.
   ;
   client lanman auth = no
   lanman auth = no
   ;
   ; We do not support Windows NT4 clients or servers anymore and all later operating
   ; systems can use kerberos
   ;
   client ntlmv2 auth = yes
   ntlm auth = no
   ;
   ; This is a SAMBA server which is authenticated strictly from a Windows 2003
   ; domain (Active Directory) and whose clients are Window 2000 or later
   ; so we can have SMB packet signing at the SAMBA server end when feasible.
   ; Macintosh terminals cannot packet sign as of yet so signing must still
   ; remain optional.
   ;
   client signing = yes
   server signing = auto
   ;
   ; We also do not want to allow the smbclient to attempt plain text password
   ; authentication under any circumstances.
   ;
   client plaintext auth = no
   ;
   ; We also want to restrict access to within UW networks for all shares.
   ;
   hosts allow = 129.97.0.0/255.255.0.0

Kerberos Client Configuration

The second file is the configuration file for the host system's kerberos client: krb5.conf. Below is listed the essential configuration information for the kerberos client in order for it to interface with the desired realm (Active Directory domain). Of interest is the entry dns_lookup_kdc = false, normally this feature instructs the kerberos client to consult DNS (SRV records) when locating the kerberos servers (KDC) for the realm. We do maintain such records in the CS DNS servers space (see ADDnsConfiguration for further details), however this manner of lookup has thus far been unreliable. Therefore the option is set to false and we rely on specifically listed KDC names in the krb5.conf file.

/etc/krb5/krb5.conf:

[libdefaults]
 default_realm = CS.UWATERLOO.CA
 dns_lookup_realm = false
 dns_lookup_kdc = false
 ticket_lifetime = 24h
 forwardable = yes
 verify_ap_req_nofail = false

[realms]
 CSCF.UWATERLOO.CA = {
   kdc = elisa.cscf.uwaterloo.ca:88
   kdc = aeshena.cscf.uwaterloo.ca:88
   kdc = glaciais.cscf.uwaterloo.ca:88
   admin_server = elisa.cscf.uwaterloo.ca:464
   kpasswd_server = elisa.cscf.uwaterloo.ca:464
   kpasswd_protocol = SET_CHANGE
 }

 CS.UWATERLOO.CA = {
   kdc = intacta.cs.uwaterloo.ca:88
   kdc = serverus.cs.uwaterloo.ca:88
   kdc = viridis.cs.uwaterloo.ca:88
   admin_server = intacta.cs.uwaterloo.ca:464
   kpasswd_server = intacta.cs.uwaterloo.ca:464
   kpasswd_protocol = SET_CHANGE
  }

 STUDENT.CS.UWATERLOO.CA = {
   kdc = eponina.student.cs.uwaterloo.ca:88
   kdc = candenis.student.cs.uwaterloo.ca:88
   kdc = cyanea.student.cs.uwaterloo.ca:88   
   admin_server = eponina.student.cs.uwaterloo.ca:464
   kpasswd_server = eponina.student.cs.uwaterloo.ca:464
   kpasswd_protocol = SET_CHANGE
  }

[domain_realm]
 .cscf.uwaterloo.ca = CSCF.UWATERLOO.CA
 cscf.uwaterloo.ca = CSCF.UWATERLOO.CA
 .cs.uwaterloo.ca = CS.UWATERLOO.CA
 cs.uwaterloo.ca = CS.UWATERLOO.CA
 .student.cs.uwaterloo.ca = STUDENT.CS.UWATERLOO.CA
 student.cs.uwaterloo.ca = STUDENT.CS.UWATERLOO.CA

[kdc]
 profile = /etc/krb5/kdc.conf

[logging]
        default = FILE:/var/log/krb5/kdc.log
        kdc = FILE:/var/log/krb5/kdc.log
        admin_server = FILE:/var/log/krb5/kadmind.log

[appdefaults]
        pam = {
         debug = true
         ticket_lifetime = 36000
         renew_lifetime = 36000
         forwardable = true
         krb4_convert = false
        }
        kinit = {
                renewable = true
                forwardable= true
        }

Domain Controller Configuration

Due to legacy issues, kerberos communicates using UDP by default. However, the size and complexity of information supplied by a Windows 2003 domain controller is often too large for UDP packets to handle. UDP is also connectionless, so packets can be lost and never recovered - very bad. Furthermore, there appears to be a difference in maximum kerberos packet size between Windows 2003, XP, 2000 and presumably SAMBA as well. For all these reasons, it is recommended and, in our case, essential to force the domain controllers (KDC servers) in our domain (kerberos realm) to only use TCP for kerberos.

The procedure for configuring a domain controller to use TCP for kerberos is outlined in the following Microsoft web document.
http://support.microsoft.com/?id=244474
Simply, it requires creating/editing a DWORD registry value called MaxPacketSize and setting it to the value one (1) in the following registry key for each domain controller in the domain.

HKLM\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters

The domain controllers must all be rebooted (not all at once, of course) for this change to take effect.

Completing the Joining Process

According to the SAMBA documentation, one initializes the kerberos client using domain administrator credentials. This involves issuing the following command on the host running the SAMBA server.

kinit Administrator@STUDENT.CS.UWATERLOO.CA

In this case, I opted to not use the vendor version of the kinit command, it is old but still in the search rules on many of our systems. Instead I utilized a newer kinit command in the krb5-1.4 package. Issuing the above command, one is prompted for the password of Administrator@STUDENT.CS.UWATERLOO.CA. If successful, this obtains and caches an initial ticket-granting ticket (credential). This ticket is used for authentication by the Kerberos system. After entering the password, if there are no errors then the kerberos client on the SAMBA server will be able to talk with its kerberos realm.

The last step is to officially join the domain with the following command.

net ads join