SEAM - Windows 2000
Hi all We're trying to make SEAM (Solaris 8) work with a Windows 2000 KDC. Here are the settings : KDC : Windows 2000 SEAM Kerberized Telnet Server : Solaris (/usr/krb5/lib/telnetd) SEAM Kerberized Telnet Client : Solaris (/usr/krb5/bin/telnet) Acquiring the TGT works fine (kinit). But when running the telnet client, we get the following error : Kerberos V5 refuses authentication because telnetd: krb5_rd_req failed: Unknown code 2 Any idea of what the problem might be ? Thanx a lot Philippe P Francois L
Re: wrong pinciple message in simple server
Sounds to me like the QNX box is not doing hostname canonicalization properly, at least through the interface we're using. Often this means you have an /etc/hosts file listing the machine, with the unqualified name first, and some other config file (nssswitch.conf or equivalent) tells the hostname lookup code to consult that file before DNS. Yes, it was indeed a /etc/hosts problem on the QNX box, and also the fact that I didn't set up the principle as: [EMAIL PROTECTED] Thanks for the help. Regards Alan Keane [EMAIL PROTECTED]
Re: SEAM - Windows 2000
Philippe - Verify that you have the Solaris Encryption Pack software installed. SEAM by default does not include support for encryption for export reasons. http://www.sun.com/solaris/encryption Also, note that SEAM for Solaris 8 only supports single DES, so if your Win2K KDC is issuing keys with stronger crypto (e.g. 3DES), your SEAM clients and servers wont work. You can request specific encryption types when you create your principals in Win2K, I dont know the exact syntax of the commands but I'm pretty sure it can be done. Microsoft has a white paper on Win2K and Kerberos interoperability, check it out if you havent already: http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.asp Finally, verify that the keytab on the server side contains the correct host principal key so telnetd can properly authenticate the client (host/f.q.d.n @REALM). -Wyllys Philippe Perrin wrote: Hi all We're trying to make SEAM (Solaris 8) work with a Windows 2000 KDC. Here are the settings : KDC : Windows 2000 SEAM Kerberized Telnet Server : Solaris (/usr/krb5/lib/telnetd) SEAM Kerberized Telnet Client : Solaris (/usr/krb5/bin/telnet) Acquiring the TGT works fine (kinit). But when running the telnet client, we get the following error : Kerberos V5 refuses authentication because telnetd: krb5_rd_req failed: Unknown code 2 Any idea of what the problem might be ? Thanx a lot Philippe P Francois L
Re: Paper about kerberos' password security
Andreas Hasenack [EMAIL PROTECTED] wrote: [snip] Yes, but you're forcing the attacker to be more active and so you can try to detect her. But I switched to kerberos so that, among other things, I wouldn't have to worry about sniffers :) No secret is 100% secure. Someone could type random stuff that happens to be the correct response to a Kerberos challenge. Someone could find a bit of metal in the junkyard that happens to open your front door lock. The most we can say is that success in single events such as these is wildly improbable. You still need to keep an eye on that door, no matter how good your lock is, but you can check less often and the bad guys still know that they should be detected before they can pick the lock. You switch to Kerberos so that you don't have to worry *as much* about sniffers. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Our lives are forever changed. But *that* is exactly as it always was.
Re: Paper about kerberos' password security
On Fri, Feb 01, 2002 at 03:04:34PM +, Mark H. Wood wrote: Nicolas Williams [EMAIL PROTECTED] wrote: Hardware is improving faster than culture... :) Culture, nothing. Our neural structure itself is against us. I simply can't learn a really strong password within a really strong expiration interval. I'll have to write it down. Poof! there goes the security of strong passwords changed frequently. Yes, that's it. Hardware can help. A smart token can learn fearfully long keys and remember them for me. (Of course if you can get my token then the problem reduces once more to a moderately-strong password.)-: Someday we'll be able to implant computers in our brains and thought-type and what not. -- Mark H. Wood, Lead System Programmer [EMAIL PROTECTED] Our lives are forever changed. But *that* is exactly as it always was. Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Re: Very Large KDCs
On Fri Feb 1 11:07:22 2002, Nicolas Williams said: On Fri, Feb 01, 2002 at 10:20:04AM -0800, Mike Friedman wrote: Looking down the road around here, we may wind up having to populate our KDC with alumni, in addition to the students, staff and 'affiliates' that we have now. Which means possibly exceeding 1M principals in the database. Does anyone know if I should anticipate problems when/if the database gets that large? Are there folks out there actually running a KDC with anywhere near that many principals? - perf knees in BDB? I doubt it. OK, good. - load; how many of those 1M records are going to be active? Good point. Concurrent activity will probably always involve only a small percentage of our registered principals. - replication; how long does it take to kprop a database with 1M records? How long does it take to dump such a KDB? I forgot about that. Right now, the entire propagation (unload, transmit db, reload) takes about 5 minutes (the unload no more than 2 minutes). In our environment, where we do mostly web 'proxy' authentication, I have to deal with the fact that while the master is being unloaded, updates (eg, passphrase changes) don't work properly. When these are being done by my cgi scripts, I have to be prepared to handle this condition. Currently, my code does this rather primitively, but since the condition occurs rarely it hasn't been a problem. So, if dumping the db is going to take a significant amount of time, I'll need to make my code more robust. I have implemented an incremental replication system in-house for dealing with replication. I recommend you look into doing the same. I guess I'll need to consider this. Thanks for the feedback. My initial concern was mainly with the MIT K5 software itself, but clearly I need to worry about ancillary processes as well. Mike -- Mike Friedman System and Network Security [EMAIL PROTECTED]2484 Shattuck Avenue 1-510-642-1410University of California at Berkeley http://ack.Berkeley.EDU/~mikefhttp://security.berkeley.edu --
Re: Paper about kerberos' password security
Culture, nothing. Our neural structure itself is against us. I simply can't learn a really strong password within a really strong expiration interval. I'll have to write it down. Poof! there goes the security of strong passwords changed frequently. So call it a passphrase; that seems to help, from my experience. --Ken
how to *not* create a stash file with kdb5_util?
I'm running on an odd problem, but I might be just fooling myself, I don't know. It doesn't matter if I specify or not the -s option to kdb5_util create, I always end up having a stash file. It also doesn't matter if I have a stash file configured in kdc.conf. Anyway, I can just go on and remove the .k5.REALM file, no problem there. Ah, this with 1.2.2 and 1.2.3.
Re: Very Large KDCs
On Fri, Feb 01, 2002 at 11:34:43AM -0800, Mike Friedman wrote: Thanks for the feedback. My initial concern was mainly with the MIT K5 software itself, but clearly I need to worry about ancillary processes as well. I would say the biggest issue is replication, not the operation of the krb5kdc process. The performance of the krb5kdc process in the face of a large KDB will depend on the performance of the KDB (BDB). Similarly with kadmind, but there you have locking interactions with the replication system. Hint: whole dumps lock the whole database, whereas partial dumps lock the individual records being dumped. So if you're doing incremental replication then kadmind's performance should not be affected(*). BTW, Heimdal has incremental replication... (*) unless there is much contention for a given record, and be mindful of the fact that kadmind fork()s for each connection, so too many admins (hundreds?) might not fly - dunno if kadmind fork()s for kpasswd requests, but those are short anyways. Mike Cheers, Nico -- -DISCLAIMER: an automatically appended disclaimer may follow. By posting- -to a public e-mail mailing list I hereby grant permission to distribute- -and copy this message.- Visit our website at http://www.ubswarburg.com This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments.
Re: SEAM - Windows 2000
Hi again Wyllys, thanks for helping us. You were right, we hadn't installed the Solaris Encryption Pack, but it's done now. And the problem is still here. :- So we read carefully your hints : - the Solaris Encryption Pack didn't solve the problem (one difference now : the error message doesn't appear any more ! the connection simply breaks) - we made sure that the keys generated by Windows 2000 are single DES compliant. By running the ktpass command described in your URL (on microsoft.com), the output says Keytab version: 0x502 keysize 54 [EMAIL PROTECTED] ptype 1 (KRB5_NT_PRINCIPAL) vno 1 etype 0x1 (DES-CBC-CRC) keylength 8 (0xb02f4a611515f1a1) Account has been set for DES-only encryption. That doesn't look like DES3... - and finally, the keytab file : here is a ktutil set of commands : ktutil: rkt /etc/krb5/krb5.keytab ktutil: list slot KVNO Principal -- 11 [EMAIL PROTECTED] So I'd say the principal is correctly installed on the server (whose name is thot.mds, as you may have guessed). Did you see anything incorrect here ? Thanks a lot for your help Philippe Francois Wyllys Ingersoll [EMAIL PROTECTED] a écrit dans le message de news: [EMAIL PROTECTED] Philippe - Verify that you have the Solaris Encryption Pack software installed. SEAM by default does not include support for encryption for export reasons. http://www.sun.com/solaris/encryption Also, note that SEAM for Solaris 8 only supports single DES, so if your Win2K KDC is issuing keys with stronger crypto (e.g. 3DES), your SEAM clients and servers wont work. You can request specific encryption types when you create your principals in Win2K, I dont know the exact syntax of the commands but I'm pretty sure it can be done. Microsoft has a white paper on Win2K and Kerberos interoperability, check it out if you havent already: http://www.microsoft.com/windows2000/techinfo/planning/security/kerbsteps.as p Finally, verify that the keytab on the server side contains the correct host principal key so telnetd can properly authenticate the client (host/f.q.d.n @REALM). -Wyllys Philippe Perrin wrote: Hi all We're trying to make SEAM (Solaris 8) work with a Windows 2000 KDC. Here are the settings : KDC : Windows 2000 SEAM Kerberized Telnet Server : Solaris (/usr/krb5/lib/telnetd) SEAM Kerberized Telnet Client : Solaris (/usr/krb5/bin/telnet) Acquiring the TGT works fine (kinit). But when running the telnet client, we get the following error : Kerberos V5 refuses authentication because telnetd: krb5_rd_req failed: Unknown code 2 Any idea of what the problem might be ? Thanx a lot Philippe P Francois L
Can't telnet - Error - Connection closed by foreign host.
I am trying to setup a small test environment with Kerberos in our lab
environment.
We have 3 Solaris 8 machines. One is a master KDC, one is a slave, and one
is a client and Kerberos application (telnet) servers.
We are using SEAM 1.0.1 from SUN.
We follow the documentation to setup the 3 machines above and so far it is
looking good.
Our goal is allow user to telnet between these machines without re-enter the
password (Single Sign On).
We login to a KDC and do klist and see that we got a ticket.
From there we try to telnet to a client and got the following error:
client01{lehong}: /usr/krb5/bin/telnet client01
Trying 144.201.100.22...
Connected to client01.tech.abc.com (144.201.100.22)
Escape character is '^]'.
[Kerberos V5 accepts you as : : [EMAIL PROTECTED]]
[Kerberos V5 accepted forwarded credentials]
Last login: Fri Feb 1 15:44:16 from slave01.tech.
Connection closed by foreign host.
We try to telnet into the client from a slave KDC also but got the same
error.
We try to telnet from master KDC to slave KDC but got the same error.
We have tried the following line in /etc/inetd.conf
telnet stream tcp nowait root /usr/krb5/lib/telnetd telnetd -a valid
or
telnet stream tcp nowait root /usr/krb5/lib/telnetd telnetd -a user
If we just use the regular telnet and default telnet entry for
/etc/inetd.conf then we can login but we have to re-enter the password.
We try to avoid re-enter password.
Anyone have any idea or suggestion? Please help.
