Paul Vixie wrote: >>... The problem is we use a non-kerberized telnet client in the field. >>We are heavily dependant on this client, meaning we can not change >>clients and fyi, there are no kerberized upgrade for this client. Is >>there a way to "wrap" a non-kerberized telnet client so it will use >>kerberos authentication? ... > > > that depends on what benefits you're willing to forego. your non-kerberized > telnet client is probably not encrypting the session, so if you have to type > your kerberos password it will be in the clear, which is bad. (it seems > unlikely that it will be able to use ticket passing to avoid this typing > of passwords, since it's not a kerberized telnet client.)
The decision to prompt for a password is determined by the server and not the client. If the protocol wrapper properly implements AUTH KRB5 and AUTH ENCRYPT or the combination of START-TLS and AUTH KRB5 there would be an encrypted channel for the non-kerberized telnet client to use. Jeffrey Altman -- ----------------- This e-mail account is not read on a regular basis. Please send private responses to jaltman at mit dot edu ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
