Kerberized telnetd: -a valid option & eight char limit on account names

[Donn Cave]

In article <2_9ed.91331$Ot3.14630 at twister.nyc.rr.com>,
 Jeffrey Altman <jaltman2 at nyc.rr.com> 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: [xxx]@PARLIAMENT.UK
> > 
> > Valid starting     Expires            Service principal
> > 10/22/04 10:00:13  10/22/04 20:00:14 
> > krbtgt/PARLIAMENT.UK at PARLIAMENT.UK
> >         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, donn at u.washington.edu