|
Actions:
|
2013-04-29 09:16 AEST by Arthur Barrett - Using gserver from linux with Windows Server 2008R2 member (not PDC or BDC).
I've been able to reproduce this problem, and I've also been able to get my installation working OK.
I believe that there are 4 things that each need to be 'fixed' to use gserver from linux with a Windows
Server 2008R2 domain member that is not a Primary Domain Controller (PDC) or Backup Domain
Controller (BDC).
My test setup was:
Red Hat Linux 5.4 x64 (rhel54cli)
Windows Server 2003 SP2 PDC (dedd-dc1)
Windows Server 2003 SP2 BDC (dedd-dc2)
Windows Server 2008R2 Standard SP1 x64 BDC (dedd-dc4)
Windows Server 2008R2 Standard x64 CVS Suite Server 2009R2 (dedd-test)
Background:
There are two changes in Windows Server 2008R2 that contribute to this problem.
i) the SYSTEM account no longer has the same privileges that it did on previous releases of Windows which
affects the CVSNT Server Service's ability to authenticate users. We've known this for a long time, so the
CVS Suite 2009R2 install creates a user 'CVSMANAGER_USER' with a random password and assigned it the
required privileges. The 'High Performance Server Service' is configured to 'run as' the
CVSMANAGER_USER account. Each 'CVSNT Server' process initially runs as this user, then after the client
connects and authenticates immediately impersonates the connecting user - this automatically ensures
that the user cannot do anything that their account is restricted from - it's good security. However the
'CVSMANAGER_USER' is a 'LOCAL' user and cannot access some 'domain' resources (the SYSTEM account is
also a 'LOCAL' user but Windows is hard-coded to allow it access to Active Directory/Domain resources).
ii) the kerberos authentication system uses new encryption standards (higher encryption) than earlier
windows releases.
So the 4 things that must be 'fixed' in a linux/windows server 2008r2 installation to get gserver to work
are:
1) when the administrator exports the windows active directory keytab - all cryptographic signatures must
be exported and then all must be imported to the linux /etc/krb5.keytab, eg:
Note: In my example the domain is 'paderborn.march-hare.local' (Domain: PADERBORN) and the linux
computer is 'rhelv54cli'.
Step 1a) export they keytab for the linux computer from windows active directory
C:\Users\Administrator.PADERBORN\Documents>ktpass -princ rhelv54cli/rhelv54cli.paderborn.march-
hare.local@paderborn.march-hare.local -mapuser rhelv54cli -pass **pasword** -crypto all -out
"rhelv54cli-all.keytab"
Step 1b) copy the generated keytab to linux
Step 1c) import the keytab on linux:
/usr/kerberos/sbin/ktutil
ktutil: rkt rhelv54cli-all.keytab
ktutil: wkt /etc/krb5.keytab
ktutil: q
2) the [libdefaults] section of the /etc/krb5.conf file must specifically authorise the new kerberos
encryption types for windows 2008r2:
default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
3) the cvsmanager process (CVS Suite Server Service) must be ran once in the SYSTEM account to ensure
the SPN is correctly registered. see bug 6659.
3a) Use the 'services' control panel
3b) stop the 'CVS Suite Server Service'
3c) modify the properties of the 'CVS Suite Server Service' so that it is ran as 'SYSTEM'
3d) start the 'CVS Suite Server Service'
4) the CVS Suite Server Service needs to be permanently configured to run as a member of the 'Domain
Administrators' group
4a) Use the 'services' control panel
4b) stop the 'CVS Suite Server Service'
4c) modify the properties of the 'CVS Suite Server Service' so that it is ran as a domain administrator, in
my example 'PADERBORN\Administrator'. Ensure you set the password of this account.
4d) start the 'CVS Suite Server Service'
Now when the linux client is tested the gserver protocol should work OK:
[test@rhelv54cli ~]$ kdestroy
[test@rhelv54cli ~]$ kinit
Password for test@PADERBORN.MARCH-HARE.LOCAL:
[test@rhelv54cli ~]$ cvs -d :gserver:dedd-test.paderborn.march-hare.local:/myrepo ver
Client: Concurrent Versions System (CVSNT) 2.8.01 (Soolin) Build 4669 (client/server)
Server: Concurrent Versions System (CVSNT) 2.8.01 (Soolin) Build 4843 (client/server)
The client should also work ok from a windows workstation (when logged in using a domain user), eg:
C:\Users\17000038>cvs -d :gserver:dedd-test.paderborn.march-hare.local:/myrepo ver
Client: Concurrent Versions System (CVSNT) 2.8.01 (Soolin) Build 4843 (client/server)
Server: Concurrent Versions System (CVSNT) 2.8.01 (Soolin) Build 4843 (client/server)
C:\Users\17000038>cvs -d :sspi:dedd-test.paderborn.march-hare.local:/myrepo ver
Client: Concurrent Versions System (CVSNT) 2.8.01 (Soolin) Build 4843 (client/server)
Server: Concurrent Versions System (CVSNT) 2.8.01 (Soolin) Build 4843 (client/server)
On my test setup I initially couldn't get any combination to work, so I shutdown all my domain servers and
then started just one (a BDC) and ran it for a day (on the weekend) then brought up the PDC and the other
BDC, then used the above procedure and it all worked perfectly. That's going to be difficult or impossible
for a customer to do in their workplace, but they should be warned that it may not work 'first time'.
We view some of these issues as Linux administration (eg: using the correct keytab cryptographics), and
some as 'bugs' in Windows Server 2008 (like SYSTEM no longer having all the 'required' privileges). At this
time we are not anticipating being able to 'fix' this in the CVS Suite 2009 installer, but we will be trying to
make the installers for our next two releases (2.8.02 and 2.8.03) a bit 'smarter' to handle this 'better'. |