Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
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