[Cvsnt] Secure Linux Client Access

Sun Feb 10 13:49:52 GMT 2002

On Friday, February 8, 2002, at 07:15  PM, Brian Smith wrote:

>  have exactly one user that would like to access the CVS repository
> from a linux box. The server is CVSNT with NTSERVER authentication. What
> is the easiest way to support this one user's linux client in a secure
> manner? I want to support this user without affecting all the other
> users that all (will) use TortoiseCVS in NTSERVER mode.
>
> I know this user can interact with our domain's KDC so that he can use
> his Windows 2000 domain login on his linux box. Is there some way to use
> NTSERVER mode with the linux client? Or do I have to do something
> special to enable full Kerberos support on server side? If I have to set
> up Kerberos on the server, where can I find information about how to do
> it? The README.NT just says "consult a Kerberos expert."
>

I am no Kerberos expert. By no means that I proclaim being a Kerberos 
expert by answering this question here!!!

Basically, you need to do these:
1. on the KDC, add a cvs/<cvsservername>.<REALM> service principal with 
random key.
2. add/export this service key to the krb5.keytab (krb5kt on Windows) on 
the CVS server,
3. configure the CVS server to use the KDC which holds the service key 
(krb5.conf on Unix, krb5.ini on Windows).

If you know exactly how to do the above 3 things, read no further. The 
followings are the gory details.

Assuming the CVSNT server's name is cvsntserver.xxx.com and your KDC is 
a Unix machine.
A. on the KDC, you need to,
	a. create an instance of cvs/cvsntserver.xxx.com with random key, and
	b. export this new principal to a temporary keytab (/tmp/krb5kt).
	    Note that you don't want it to go into the default krb5.keytab, 
because the CVS server does not run on the KDC! Remember a KDC should 
run as little service as possible to make it as secured as possible.

	So, what you need to do for this are, as root on the KDC:
	# kadmin.local
	kadmin.local: addprinc -randkey cvs/cvsntserver.xxx.com
	Principal "cvs/cvsnt.xxx.com" created.
	kadmin.local: ktadd -k /tmp/krb5kt cvs/cvsntserver.xxx.com
	Entry for principal cvs/cvsntserver.xxx.com with kvno 1, encryption 
type DES-CBC-CRC added to keytab WRFILE:/tmp/krb5kt.
	kadmin.local: quit
	#

	(Originally, you should be able to use kadmin on the cvsnntserver 
to do "ktadd", but since KRB5 does not compile the server portion on 
Windows, you ain't got kadmin on Windows.)
	(If your CVS server is a Unix box, you need to use kadmin on the 
cvs server with "ktadd cvs/<cvsunixserver>.<realm> to append the key to 
/etc/krb5/krb5.keytab)

B. You need to transfer this /tmp/krb5kt file SECURELY to the 
cvsntserver.xxx.com and put it in %SYSTEMROOT% (that is,  
%SYSTEMROOT%\krb5kt). If your CVSNT server already has some other 
service keys in krb5kt, you need to find a way to append this new key in 
there. Hint: transfer the krb5kt to Unix to do ktadd and then transfer 
it back.

C. You must put a correct krb5.ini pointing to your KDC on the 
cvsntserver.xxx.com You can basically copy the krb5.conf from the Linux 
machine, rename, and put it in %CVSNTDIR% (that is, %CVSNTDIR%\krb5.ini)

I have no idea how you do step A above on WinNT (Tony knows), but since 
your client is a Linux box, I hope your KDC is also a Unix box. I also 
have no idea whether this will work if the KDC is a WinNT (Tony said it 
works as well.).

I have tested this with:
	1. a Sparc Solaris 8 KDC (Sun Enterprise Authentication Mechanism 
(SEAM) v.1.0.1),
	2. a W2K SP2 machine running CVSNT 1.11.1.2 Beta 3 (build 33)(as 
cvs server),
	3. clients: a MacOS X 10.1.2, a Sparc Solaris 8, a W2K SP2, and a 
RedHat 6 x86.

CAUTION:
	When you export the service principal key this way, if you export 
it again, you must replace the krb5kt on cvsntserver with the new 
export. This is because each time you do the "ktadd -k" command, the 
kvno increases by 1.
	The symptom is -- on the client ,when the cvsntserver has a 
different kvno service key from the service key on the KDC, cvs -d 
:gserver:cvsntserver;...  says something like this:
		Client: Concurrent Versions System (CVS) 1.11.1p1 (client/server)
		Server: cvs [version aborted]: error from server clara.home: 
cvs [pserver aborted]: could not verify credentials

Assuming the CVSROOT on cvsntserver is at d:/cvsroot.
On the Linux client, you can test it this way:
1. kinit and klist to test that you indeed get a tgt from KDC.
2. cvs -d :gserver:cvsntserver.xxx.com:/d//cvsroot version. You should 
get both the versions of the CVS client and server. (this should verify 
the Kerberos authentication using GSSAPI). Note the /d//cvsroot, this is 
the syntax on Unix to specify the equivalent of d:/cvsroot on Windows.

If any one of your cvs client,s cvs servers, are behind a NAT router so 
that the IP#s str ranslated, it will cause Kerberos authentication to 
fail and says something like:
	Client: Concurrent Versions System (CVS) 1.11.1.3 Beta 7 (Build 49) 
(client/serv
er)
	Server: cvs version: GSSAPI authentication failed: Miscellaneous 
failure cvs [version aborted]: GSSAPI authentication failed: Incorrect 
net address

There are 2 solutions:
1. Use "kinit -A" to request a no address ticket. This somehow increases 
risk, because when this addessless ticket is stolen, it can be used on 
any machine. Not that IP spoofing is impossible, but this indeed reduces 
the security of Kerberos tickets. Note that I have only seen the -A 
option available in MIT's KRB5 1.2.1, and it's not in Sun's KRB5 (SEAM) 
implementation.

2. Add the NAT router/gateway's address when requesting a Kerberos TGT. 
The KRB5 srouce code "seems" to be able to do so, but I have no idea how 
or what the command line option is to do so. In addition, this solution 
is rather nasty, b/c in many cases the NAT router uses DHCP so its IP 
chages. Even if the NAT router has a static IP,  you will be requiring 
the users to know the NAT router's IP#. Plus, a stolen ticket can still 
be used on any machine behind the NAT router.

I will recommend solution 1 if the client is your home machine behind 
your home NAT router.

Hope this helps!

Jonah Tsai
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 6399 bytes
Desc: not available
Url : http://www.cvsnt.org/pipermail/cvsnt/attachments/20020210/f107a38d/attachment.bin 