In article <[EMAIL PROTECTED]>, Jeffrey Altman <[EMAIL PROTECTED]> wrote: > hwntw wrote: ... > > The Kerberos bit comes in because Vintela vas authentication is > > essentially Kerberos auth. If I log in and do klist I get< Ticket > > cache: FILE:/tmp/krb5cc_1001_SQ2421 > > Default principal: [EMAIL PROTECTED] > > > > Valid starting Expires Service principal > > 10/22/04 10:00:13 10/22/04 20:00:14 > > krbtgt/[EMAIL PROTECTED] > > renew until 10/23/04 10:00:13 > > > > > That is the result of the VIntela product authenticating to Active > > Directory. Point is I telnet using a kerberised telnetd from the MIT > > distribution. Praps I am being unrealistic in expecting the -a valid > > argument to telnetd to work in this case. Nevertheless, the issue of > > the eight char limit on accounts names is still germane, as this is a > > Kerberos telnetd we are talking about, not the in.telnetd that comes > > with Solaris 9 (and which does not work at all with Vintela VAS). I > > should have mentioned that ssh connections do not exhibit this eight > > char account name limit
> The Vintela product is performing a Kerberos initial ticket request > upon login. The telnet session is not being authenticated using > Kerberos. You are typing in a user name and password. Hoping that it will help to make this semantic distinction, actually the Vintela product apparently isn't authenticating at all but rather leaving that to the MIT telnetd ... which, as you say, gets an initial ticket, which naturally appears on the remote end. Vintela appears to me to be the client. > I am not aware of any restrictions on the length of the user name > in MIT's telnetd. In particular, because telnetd does not know anything > about usernames. The username is determined by the text entered into > the 'login' program on the machine. 'login' more then likely is being > replaced by Vintela. Could have been replaced by something, anyway. The system administrator on this host may know more about what's going on. To start with though, it might be worth looking at /etc/passwd on the remote host to see if these long names are in fact in there, in the first field as user IDs. Donn Cave, [EMAIL PROTECTED] ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos