Re: Kerberizing a non-kerberized telnet client
... 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.) -- Paul Vixie Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberizing a non-kerberized telnet client
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
Re: Kerberizing a non-kerberized telnet client
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Burkhardt, Andrew) wrote: ... We have setup a test Windows Server 2003 Domain/KDC. We have a Windows 2000 Professional computer using the kerberized Ktelnet client, connecting to a Red Hat 9 Linux box running kerberized telnetd, and successfully authenticating using Kerberos. Basically, everything is running correctly in the environment. 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? Has anyone had any experience with this problem? I am looking for any suggestions. Many thanks! I don't recall ever hearing of a Kerberos telnet wrapper, but it could be worth a look. We did something like that here with FTP, for the sake of web development tools that use it, and it seems to have worked out fairly well. You'd have to know something about the telnet protocol and how Kerberos fits in, which I guess you could get from the MIT source. Donn Cave, [EMAIL PROTECTED] Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberizing a non-kerberized telnet client
In regard to: Re: Kerberizing a non-kerberized telnet client, Donn Cave...: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Burkhardt, Andrew) wrote: ... We have setup a test Windows Server 2003 Domain/KDC. We have a Windows 2000 Professional computer using the kerberized Ktelnet client, connecting to a Red Hat 9 Linux box running kerberized telnetd, and successfully authenticating using Kerberos. Basically, everything is running correctly in the environment. 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? Has anyone had any experience with this problem? I am looking for any suggestions. Many thanks! I don't recall ever hearing of a Kerberos telnet wrapper, but it could be worth a look. We did something like that here with FTP, for the sake of web development tools that use it, and it seems to have worked out fairly well. You'd have to know something about the telnet protocol and how Kerberos fits in, which I guess you could get from the MIT source. If the field machines are Windows boxes, I would think that https://sourceforge.net/projects/kerberizer/ would be worth a look. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberizing a non-kerberized telnet client
The TELNET START-TLS, TELNET AUTH KRB5 and TELNET AUTH ENCRYPT options are linked together but have no relationship with other TELNET options. Most important, it is required that these three options be negotiated prior to any other options. It would be possible to implement a winsock wrapper which would always attempt to negotiate the secure telnet options. The most important trick is to cache any other attempted telnet negotiations until after the security options have completed. Feel free to contact me privately if you would like to see this developed. Jeffrey Altman Burkhardt, Andrew wrote: Hi, We have setup a test Windows Server 2003 Domain/KDC. We have a Windows 2000 Professional computer using the kerberized Ktelnet client, connecting to a Red Hat 9 Linux box running kerberized telnetd, and successfully authenticating using Kerberos. Basically, everything is running correctly in the environment. 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? Has anyone had any experience with this problem? I am looking for any suggestions. Many thanks! Andy Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos -- - 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
RE: Kerberizing a non-kerberized telnet client
Have you heard of any Kerberos proxy servers? A proxy which would handle kerberos requests on behalf of the non-kerberized client? -Original Message- From: Sam Hartman To: Burkhardt, Andrew Cc: '[EMAIL PROTECTED]' Sent: 5/14/2004 1:52 AM Subject: Re: Kerberizing a non-kerberized telnet client Burkhardt, == Burkhardt, Andrew [EMAIL PROTECTED] writes: Burkhardt, Hi, We have setup a test Windows Server 2003 Burkhardt, Domain/KDC. We have a Windows 2000 Professional Burkhardt, computer using the kerberized Ktelnet client, Burkhardt, connecting to a Red Hat 9 Linux box running kerberized Burkhardt, telnetd, and successfully authenticating using Burkhardt, Kerberos. Basically, everything is running correctly Burkhardt, in the environment. The problem is we use a Burkhardt, non-kerberized telnet client in the field. We are Burkhardt, heavily dependant on this client, meaning we can not Burkhardt, change clients and fyi, there are no kerberized Burkhardt, upgrade for this client. Is there a way to wrap a Burkhardt, non-kerberized telnet client so it will use kerberos Burkhardt, authentication? Has anyone had any experience with Burkhardt, this problem? I am looking for any suggestions. Many Burkhardt, thanks! You could use Kerberized ssh to forward the telnet port. You would not get single sign-on, but you would at least get security. Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Kerberizing a non-kerberized telnet client
Burkhardt, == Burkhardt, Andrew [EMAIL PROTECTED] writes: Burkhardt, Hi, We have setup a test Windows Server 2003 Burkhardt, Domain/KDC. We have a Windows 2000 Professional Burkhardt, computer using the kerberized Ktelnet client, Burkhardt, connecting to a Red Hat 9 Linux box running kerberized Burkhardt, telnetd, and successfully authenticating using Burkhardt, Kerberos. Basically, everything is running correctly Burkhardt, in the environment. The problem is we use a Burkhardt, non-kerberized telnet client in the field. We are Burkhardt, heavily dependant on this client, meaning we can not Burkhardt, change clients and fyi, there are no kerberized Burkhardt, upgrade for this client. Is there a way to wrap a Burkhardt, non-kerberized telnet client so it will use kerberos Burkhardt, authentication? Has anyone had any experience with Burkhardt, this problem? I am looking for any suggestions. Many Burkhardt, thanks! You could use Kerberized ssh to forward the telnet port. You would not get single sign-on, but you would at least get security. Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
