-- Main.ctucker - 13 Feb 2007
How to Authenticate a SAMBA system as a member of the NEXUS Environment.(THIS PAGE NEEDS UPDATING)
This page outlines how to join a SAMBA 3.0 server (the
samba-3.0 xhier package) in SCS's DNS space to the
NEXUS domain environment managed by Engineering using kerberos. Essentially, we will be making the SAMBA server a member of a kerberos realm
NEXUS.UWATERLOO.CA which is generated by the
NEXUS domain.
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 plus 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 as a kerberos client.
Create The SAMBA Server Computer Account In NEXUS
Because the administrative powers of CSCF staff are limited in the
NEXUS, it is practical to create the computer account for the SAMBA server within the domain first instead of allowing the SAMBA server to created it during the membership process.
Use the
Active Directory Users and Groups console on CSCF's
NEXUS management server (
pyxis.cs) to create the computer account for the new SAMBA server. This will have to be somewhere in the
Computer Science\Computers OU or one of its sub-OU's. Name the computer account with the same name as the hostname for the SAMBA server, minus the
.cs or
.student.cs stuff, and do not use an alias name.
SAMBA Server Configuration
The next step 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
prefered master = no
; These following lines are to set up samba to function as a member
; of the NEXUS domain in Engineering's Active Directory.
; This domain is also known as the NEXUS.UWATERLOO.CA kerberos
; realm
;
; NOTE: Since security is set to ADS, the value of
; encrypted passwords must be set to yes.
;
security = ADS
realm = NEXUS.UWATERLOO.CA
workgroup = NEXUS
announce as = NEXUS - Samba 3.0 Server
ldap suffix = ou=Computer Science,ou=Faculties,dc=nexus,dc=uwaterloo,dc=ca
log level = all:3
max log size = 760000
comment = Samba 3.0 Server for NEXUS Domain Users in SCS
;
; 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 SAMBA server's kerberos client:
krb5.conf. Below is listed the essential configuration information for the kerberos client in order for it to interface with the
NEXUS.UWATERLOO.CA realm.
/etc/krb5/krb5.conf:
#
#pragma ident "@(#)krb5.conf 1.2 99/07/20 SMI"
# Copyright (c) 1999, by Sun Microsystems, Inc.
# All rights reserved.
[libdefaults]
default_realm = NEXUS.UWATERLOO.CA
[realms]
NEXUS.UWATERLOO.CA = {
kdc = eng2k.uwaterloo.ca:88
kdc = grandis.uwaterloo.ca:88
kdc = nausicaa.uwaterloo.ca:88
kdc = madoka.uwaterloo.ca:88
admin_server = eng2k.uwaterloo.ca:464
default_domain = nexus.uwaterloo.ca
}
[domain_realm]
.apex.uwaterloo.ca = APEX.UWATERLOO.CA
.nexus.uwaterloo.ca = NEXUS.UWATERLOO.CA
nexus.uwaterloo.ca = NEXUS.UWATERLOO.CA
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
kdc_rotate = {
# How often to rotate kdc.log. Logs will get rotated no more
# often than the period, and less often if the KDC is not used
# frequently.
period = 1d
# how many versions of kdc.log to keep around (kdc.log.0, kdc.log.1, ...)
versions = 10
}
[appdefaults]
kinit = {
renewable = true
forwardable= true
}
Special DNS Configuration
As outlined in
ADDnsConfiguration, an Active Directory relies upon information stored in DNS to locate key servers and services. However,
NEXUS is a domain in a foreign Active Directory managed by Engineering and not linked (no "trusts") to CSCF's Active Directory. DNS information about the
NEXUS domain cannot be automatically recorded into the CSCF's AD DNS space. Further, Engineering does not permit zone transfer of their own Active Directory DNS data from their own AD DNS space.
Therefore, for the time being we will implement a strategy initially recommended by Naji Alamrony of MFCF. Required
NEXUS DNS information is to be added manually into the CS DNS space. To accomplish this, two new forward lookup zones need to be created in CSCF's AD DNS space:
- _tcp.nexus.uwaterloo.ca (Kerberos client support)
- _msdcs.nexus.uwaterloo.ca
- This zone also requires a new subdomain named:
_tcp.dc._msdcs.nexus.uwaterloo.ca (SAMBA server support)
Most resulting subdomains can be left empty. But within
_tcp.nexus.uwaterloo.ca and
_tcp.dc._msdcs.nexus.uwaterloo.ca, SRV records must be manually created to direct the following service names to each domain controller in
NEXUS. That's 24 SRV records in all for the current list of
NEXUS domain controllers. Fully qualified domain names (FQDN) must be used, ie. they all end with a dot.
Services:
- _ldap (Priority 0, Weight 100, Port 389)
- _kerberos (Priority 0, Weight 100, Port 88)
- _kpasswd (Priority 0, Weight 100, Port 464)
- Not really required under the _msdcs zone, but won't hurt either.
Current
NEXUS Domain Controller FQDNs:
- eng2k.uwaterloo.ca.
- nausicaa.uwaterloo.ca.
- grandis.uwaterloo.ca.
- madoka.uwaterloo.ca.
Adding New Zones To CS DNS Space
Zone transfer must be enabled for the new AD DNS zones. This will allow the AD DNS server to forward its data to existing CS DNS servers (
core.cs and
student.cs). New slave zones must then be defined on the CS DNS servers for the two new AD zones. This is done by editing the local
zone.info file in the
nsdata package on the CSCF administrative master
cscf.cs. The
nsdata package is then distributed to the CS DNS servers.
Additional entries to file: /software/nsdata/data/admin/zone.info
// subdomains needed from NEXUS which are maintained on the
// CSCF AD system.
zone "_tcp.nexus.uwaterloo.ca" {
type slave;
file "cache/_tcp.nexus.uwaterloo.ca";
// check-names ignore;
masters {
129.97.152.31;
};
allow-query { any; };
};
zone "_msdcs.nexus.uwaterloo.ca" {
type slave;
file "cache/_msdcs.nexus.uwaterloo.ca";
// check-names ignore;
masters {
129.97.152.31;
};
allow-query { any; };
};
A Final DNS Kluge
On your SAMBA server make a temporary edit to the
/etc/resolv.conf file. Comment out the line for the localhost nameserver entry (
127.0.0.1). Then add, as the
first listed nameserver,
129.97.150.252. This is will allow the SAMBA server to register with
NEXUS DNS services when you attempt to join the server to the domain.
Then follow through with the
kinit and
net ads join commands as outlined in
ADAddSamba using the CSCF credentials for joining a computer to the
NEXUS domain.
> kinit nexus_join_to_ad_username@NEXUS.UWATERLOO.CA
> net ads join -U nexus_join_to_ad_username
Once the SAMBA server is joined to
NEXUS, you may remove the above modifications to the
/etc/resolv.conf file. DNS registration in
NEXUS is a one time event.