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

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

Re: Kerberizing a non-kerberized telnet client

, 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

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

Re: Kerberizing a non-kerberized telnet client

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

RE: Kerberizing a non-kerberized telnet client

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

Kerberizing a non-kerbized Telnet client

. So basically the realm is setup correctly, everything is working fine. The problem is, we use a non-kerberized telnet client in the field and are highly dependent on it (meaning we can not switch clients and fyi, there are no kerberized upgrades). Is there any way to wrap a non-kerberized

Kerberizing a non-kerberized telnet client

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

Re: Kerberizing a non-kerberized telnet client

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

Re: Telnet client

[EMAIL PROTECTED], Ken Hornstein [EMAIL PROTECTED] wrote: : I am trying to develop a telnet client application, : : You should probably look at other Kerberos telnet clients as examples ... : : IAC SB AUTHENTICATION IS authentication-type-pair AUTH Kerberos V5 :KRB_AP_REQ message IAC SE

Telnet client

Dear All, I am trying to develop a telnet client application, it's working right to Unix machines without Kerberos authentication, but when I connect to Linux Server, it sends Kerberos 5 authentication in this detail: FF FD 25(IAC DO Auth ---the server wants authentication) FF FA 25 1

Re: Telnet client

I am trying to develop a telnet client application, You should probably look at other Kerberos telnet clients as examples ... IAC SB AUTHENTICATION IS authentication-type-pair AUTH Kerberos V5 KRB_AP_REQ message IAC SE But I can't implement this RFC 2942 procedure in hexa type just like