Subject: login.conf for selecting password verification method (was Re: Kerberos is on by default?)
To: None <>
From: Aidan Cully <>
List: tech-userlevel
Date: 06/30/2000 02:55:48
[ re-directed to tech-userlevel ]

On Thu, Jun 29, 2000 at 10:19:30PM +0200, Manuel Bouyer wrote:
> On Wed, Jun 28, 2000 at 06:00:13PM -0400, Brandon D. Valentine wrote:
> > Well I got NetBSD installed on those sparcs.  Wow, I'm impressed.  I did
> > a netboot install off of an IRiX box.  Very smooth.  I'm presently
> > getting pkgsrc and more software installed onto them.  But the primary
> > issue I'm dealing with right now is that Kerberos seems to be on by
> > default.  Is there some glaringly obvious way to rip out the Kerberos
> > stuff?  It takes forever to login because it goes looking for Kerberos
> > tickets I don't have.  I don't run Kerberos servers for a number of
> > reasons and I'm not going to change anytime soon.  I'd rather just rip
> > out the Kerberos stuff and go with straight NIS for authentication.
> Unfortunably, not rigth now. Crypto has just been integrated in the base
> system (it was an optional set before), and the problem showed up at this
> time. I believe (I hope :) it's being worked on.

FWIW, the assumption I made with k5 integration on passwd and login
(which was valid for the MIT code) was that the existance of a krb5.conf
was the way to enable/disable krb5.  krb5_init_context() would return an
error code when that file didn't exist, so I checked its return value as
an indication of if or not to use kerberos.  Under Heimdal, I don't see
a case (except ENOMEM) where krb5_init_context will return error, and
that's probably what's causing the behaviour people are seeing.

I'm not convinced that it would be a good idea to change Heimdal's
behaviour when the krb5.conf file doesn't exist to match MIT's (at
least, the MIT version I'm familiar with).  What I'd like to do is use
the login.conf interface to select authentication mechanisms...  My
first thought is to mirror BSDI's login.conf keys for this purpose
(since I guess it supports something like this through hook programs),
but I've got no practical idea how it works.

I'm not at the stage, yet, where I'll suggest adding hooks for external
authenticators, but I'd like to know if BSDI can handle fallback
authentication at the login.conf level...  e.g., krb5 auth fails, try
local with the same password.  Or (and this is secondary) if it can
support stuff like 'try krb5 and krb4, if either succeeds we're good'.
Without having access to a BSDI system to experiment, I couldn't really
follow their login.conf man page.