Kerberos / PAM Usage ?
Marcus Watts
mdw at umich.edu
Thu Sep 18 15:05:39 EDT 2003
Tim Alsop <Tim.Alsop at cybersafe.ltd.uk> writes:
...
> 1. Do you, or the company you represent use Kerberos, or are you considering using Kerberos with PAM for authorisation, authentication, or both authentication and authorisation.
We (UMICH.EDU) extensively use kerberos for authentication. Some of this
uses pam. Kerberos, with or without pam, is *NOT* an authorization service.
We still end up spending some time explaining to people that
just because someone has a uniqname (campus identity) and a password
doesn't mean they're a UM employee, and they need to use some other
mechanism to determine authorization.
Using ".klogin" is an example of an authorization scheme - which is
mainly limited to dealing with user logins on Unix or similar machines
where the user is expecting to control which kerberos principals
can authenticate as that Unix account. This isn't a very interesting
problem to us. A lot of our authorization issues have to deal with
system administrators choosing which of a large population of users
with AFS home directories can access their department server,
many web services where the very concept of a home directory
does not exist, and various system administrative services where
we are concerned with issues such as proxy authentication and
of course identifying various groups of privileged "administrators".
>
> 2. If you are using, or considering using PAM for authorisation I would like to hear if you using it with .k5login files, or checking authorisation via an LDAP lookup, or some other method. Can you provide details of your usage, or intended usage of PAM for authorisation ?
We use AFS "pt" groups for a fair amount of authorization needs on campus.
We also make use of ldap for various purposes, some services have flat
files containing lists of principals, then there are services where
authorization data comes from or is contained in oracle, & there are
certainly other schemes deployed by various groups around campus that
we don't necessarily know in detail, due to the federated nature of our
operational environment.
>
> 3. Do you have any GSS-API enabled applications, or any Kerberos enabled applications that accept a security context to determine the users principal name and then use PAM for authorisation, or do you have any applications that you would like have enabled in this way ?
There are certainly GSS-API enabled applications out there. I can't
think of any particularly good example of why one would use GSS-API
*and then* PAM. PAM is generally higher level and usually deals with
"passwords", and is oriented around the concept of users logging into a
service -- ie humans who can interactively read text messages and type
strings. GSS-API is a lower-level structure that allows clients and
services to authenticate to each other at service time, which is not
necessarily at all the same thing as "login" time. I'd have serious
concerns about what you were doing with passwords if you really were
doing GSS-API and then PAM.
I would say that GSS-API is mainly of interest to us if it's part of
application and forms some sort of standard at either the API or the
wire level that allows potential interoperability, either between
vendors, or perhaps allows the use of different forms of cryptographic
infrastructure. For instance, that could be the use of x509
certificates, or kerberos tickets, or one vendor's client and another's
server.
PAM is mainly of interest to us for logins on Unix machines; there it
provides us a convenient hook to deploy kerberos authentication, AFS
specific login functionality (pags and tokens), some manner of
cross-realm ticket support, and gives system administrators some manner
of control over which entries in some global "account" and "home
directory" space get access to specific machines. It's especially
convenient to us that this works for multiple applications (ie, ssh,
xdm, and local terminal access) and that the pam modules themselves are
portable across multiple OS environments. Since pam does require that
you pump cleartext passwords into it, I don't know that it's
necessarily as attractive as all that for us to deploy this in *new*
applications, especially if they can be designed to work around
kerberos tickets or x509 certificates that live on the user's
workstation such that the user's password is never involved in actual
service interaction.
-Marcus Watts
UM ITCS Umich Systems Group
More information about the Kerberos
mailing list