As previously promised, here is a followup report on my on-again/off again attempt to integrate a windows 2000 KDC with LINUX krb5 and Services for UNIX version 2.0 (or later).
The executive summary is that it works, and it seems to have all the desirable features I want (and some potential security throwbacks to the prehistoric beginnings of UNIX).
I'm in the process of integrating kerberos 5 enabled services (minimally login, gssftp and kerberized telnet for laughs during this test) on a Red Hat 7.x LINUX host (actually an entire parallel cluster), which is supposed to interoperate with Windows 2000 running Services for UNIX 2.0 (soon it will be SFU (apologies for swearing) 3.0 ). The point is for all users (except for a handful of locally defined administrative users) to be authenticated against the Windows 2000 domain controler KDC in the default (for the sake of argument) W2k realm; I have the following requirements
1. The users under LINUX are UID/GID mapped to a w2k sid via NIS+ SFU 2.0 user/group name mapping. It's necessary to define a GID not lower than 1000 (or 500 - the exact lower bound doesn't matter for conceptual purposes, so bear with me, all you insufferable fuss budgets out there ;)
2. The home directory of the user is the NFS exported windows user share; the NFS
home directory should be automountable without the automounter maps having to specify which server the home directory came from (this is easy).
3. Users are defined in one and only one place: active directory. Period. The need for ANY user specific system administration under LINUX should be ZERO. That means, no more useradd commands, or their equivalent under linuxconf (except for a handful of locally defined administrative accounts).
Requirements 1 and 2 work without kerberos authentication without any trouble, but it's only half of what you and I want.
Microsoft has step by step instructions to add a LINUX host to a W2K KDC,
available at http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp, however I've deviated from their instructions for generating the keytab file
for my host principal; I use the form
C:> Ktpass –princ host/hostname@NT-DNS-REALM-NAME –mapuser account -pass password -crypto DES_CBC_MD5 –out unixmachine.keytab
instead of the form shown in this document (without the
-crypto argument).
Should I show you my /etc/krb5.conf file for this test? OK, you've talked me into it:
logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
ticket_lifetime = 24000
default_realm = GCROOT
default_tkt_enctypes = des-cbc-md5
default_tgs_enctypes = des-cbc-md5
dns_lookup_realm = false
dns_lookup_kdc = false
[realms]
GCROOT = {
kdc = rdc2.gcroot:88
admin_server = rdc2.gcroot:749
default_domain = gcroot
}
[domain_realm]
.gcroot = GCROOT
gcroot = GCROOT
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
[pam]
debug = true
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
Adding SFU 2.0 extends active directory, so that user properties will have UNIX attributes, such as a UID/GID pair, and so that you can specify how the user's share should be NFS exported. However, if the passwd database resides on a LINUX box functioning as the NIS master, you'll still have to define the user in two places: in active directory and in the NIS passwd database. This violates requirement 3. SFU 2.0 has a server for NIS called "server for NIS" along with a wizard that is supposed to facilitate moving the NIS master from your UNIX box to your domain controller. The question is whether once your domain controller is the NIS master, whether adding new users in active directory and setting their UNIX attributes is automatically reflected in Server for NIS's NIS maps?
The answer, now that I've done it, is well, yes. If you insist on a kerberized login on the LINUX host (the principal host/hostname@NT-DNS-REALM-NAME above), then the user's windows 2000 password will be used authenticate against the KDC.
Some not so nice news though: here's a partial listing of my passwd file (from ypcat passwd):
flengyel:.ux7rvYBeJLijE:1000:1000:Florian Lengyel w2k+krb5+SFU 2.0 test account :/home/m1/flengyel:/bin/smash
mrlinux:ERK22N41D3FdhZU:1001:1000::/home/rdc2/mrlinux:/bin/gash
(I've mangled the ciphertext and some of the plaintext). The flengyel account existed before I migrated my NIS server from my LINUX host; the "mrlinux" account was added directly to active directory from the Windows 2000 Micro$oft Management Con$ole after the migration. The bad news is that the shadow file has been merged into the password file. Perhaps the situation is improved in SFU 3.0 (i've migrated the shadow file in SFU 2.0, but to no avail), or it's my fault for not modifying /var/yp/Makefile before creating my test NIS domain. I suppose it's worth starting over...
Also, the user's Windows 2000 user share is NFS exported in the form
The LINUX host automounts the user directories with the auto.home map
*
so that user shares can be NFS exported from any w2k file server running server
for NFS, which comes with SFU.
Fortunately these hosts are behind a firewall (a small consolation), although the SFU services aren't themselves kerberized, which they could be since they run on a w2k domain controller, which comes with a KDC...
At the moment I have a silly problem with SFU 2.0: it's damned management console crashes before you can manage anything. The services run, however ;)
SFU 2.0 hasn't addressed the issue of copying /etc/skel files to the user's account once it's created under active directory - there isn't anything like /etc/skel in SFU 2.0. You have to create any initial dot configuration files and directories yourself in the user's w2k share.
Graduate School and University Center of the City University of New York
Room 2402, 365 Fifth Avenue, New York, NY 10016
212-817-7374
