Subject: Re: Centralized User and Password Management
To: Dick Davies <rasputnik@hellooperator.net>
From: John Nemeth <jnemeth@victoria.tc.ca>
List: netbsd-users
Date: 11/28/2004 13:08:41
On Apr 17,  5:57pm, Dick Davies wrote:
} * Tillman Hodgson <tillman@seekingfire.com> [1103 22:03]:
} > On Thu, Nov 25, 2004 at 04:52:39PM -0500, Greg A. Woods wrote:
} 
} My understanding of PAM/Kerberos is sketchy, but I assume the client
} just blindly sends its user/pass to the server (which then gets a ticket

     The client would have to send whatever the server wants, which
would be dictated by the protocol being used.  With my understanding of
Kerberos, the client would only send the username to the server.  The
server would send back some information encrypted with the user's
password.  The client would then decrypt the information using the
user's password.  If the client can successfully decrypt the
information, then it can use that information to get services from
other servers.

} on the users behalf to validate the passphrase?), since
} PAM is fundamentally user/pass based. 

     PAM is not fundamentally user/pass based.  It is in fact not based
on any particular authentication method.  The authentication methods
used is completely determined by the modules used, which is determined
by a configuration file.  With the right modules, authentication could
be driven by a certificate stored on a smart card, by a retina scan, or
anything else that is unique; or, any combination of things, such as a
username and a smart card.  Of course, from the authentication
information given, a username would have to be derived if it isn't
given explicitly.

} So you lose your SSO features anyway, and also you have no real

     Actually, PAM is part of the X/Open Single Sign On specification.
The API does specify functions for handling secondary logons.  However,
I don't know of any implementations providing those functions.

} server identification (there are no tickets coming back from the 
} server to the client). You'd have to rely on SSL CRLs to 'untrust'

     If you use Kerberos, you would get the appropriate information
back.  You'd just have to have a secure way of storing the TGT so that
different applications could get to it.

} I gave up and went to ldap auth - it has its warts but load balancing
} works well, and it feels like a better match to pam, plus it does 

     PAM is fully modular and thus can use any protocol you want.

} But the single password feature is definitely a double-edged sword,
} especially when keyloggers are so prevalent. You need to be careful about

     Keyloggers would record all passwords entered, so it doesn't
matter how many passwords are used, unless you restrict the places from
which they can be entered.

} what groups have access to what service, and certain clients just can't
} be trusted.
} 
}-- End of excerpt from Dick Davies