[2006] in Kerberos
Re: Kerberos question - user password authentication (for xlock)
daemon@ATHENA.MIT.EDU (Shawn Mamros)
Fri Jun 26 19:36:40 1992
Date: 26 Jun 92 22:49:34 GMT
From: mamros@athena.lkg.dec.com (Shawn Mamros)
Reply-To: mamros@athena.lkg.dec.com (Shawn Mamros)
To: kerberos@shelby.Stanford.EDU
peterd@pjd.dev.cdx.mot.com (Peter Desnoyers) writes:
|> We are running the enhanced security package, so you can't just get
|> the password entry, encrypt your input, and compare the two, which is
|> what xlock tries to do.
|>
|> Not only that, but only "system" names are in /etc/auth, while user
|> passwords come from Kerberos, so you can't even use the auth routines
|> like checkpass or getauthid. (I tried; I made sure the program ran as
|> root and everything...)
|>
|> Finally I got a copy of the Berkeley NET/2 login code, and tried
|> using the Kerberos code from that. No luck there, either - it would
|> always fail with "principle unknown". The only other person here who
|> knows anything about this thinks that it's because we don't have a
|> full Kerberos installation - just enough to do passwords for login and
|> su.
Right... With ULTRIX enhanced security and a Hesiod-distributed auth database
setup, individual users do NOT have Kerberos principals associated with them.
So it's not correct to say that "user passwords come from Kerberos". Probably
the BSD Net/2 code expects an Athena-style environment, where users have their
own principals.
Under ULTRIX enhanced security, the auth database (whether local or distributed
via Hesiod) stores the user's encrypted password (encrypted with crypt16(3)
instead of crypt(3)). In order to prevent anyone on the net from looking
at the encrypted passwords available via Hesiod, the ULTRIX named requires
Kerberos authentication for Hesiod auth lookups. The ticket for Kerberos
authentication, in turn, is obtained from the client's /etc/srvtab file.
The "magic incantation" for obtaining this authentication is the following:
krb_svc_init("hesiod", hostname, (char *)NULL, 0, (char *)NULL,
ticketfile);
where hostname is the unqualified hostname of the machine running xlock, and
ticketfile is wherever you want to put the ticket file (I recommend something
like /tmp/tkt.xlock.%d, where %d can be a PID or a UID to make it more-or-less
unique). You'll want to remove the ticket file afterwards. (Also note this
ticket only lasts 5 minutes - see the krb_svc_init(3) man page for more
details.)
Once you do this, you can use getauthuid(3) to obtain the auth database
entry (assuming the auth line in /etc/svc.conf is set to "local,bind" as
it should if you're using Hesiod) and crypt16(3) to encrypt the typed
password. You may also need to double-check and make sure your xlock code
will accept a 16-character password; I wouldn't be surprised if it only
takes eight normally... Actually, to make this code portable between
different security levels (if you're concerned about that), take a look
and see if you have the authenticate_user(3) library routine (I know this
is in place in ULTRIX V4.2 and later, but I'm not sure about V4.1).
Disclaimer: I don't work for the ULTRIX group, and I had nothing to do with
the design or implementation of the ULTRIX enhanced security setup, so don't
flame me if you prefer per-user Kerberos authentication (which, in fact,
I do ;-).
-Shawn Mamros
E-mail to: mamros@athena.lkg.dec.com
