Kerberos / PAM Usage ?

[Tim Alsop]

Marcus,

Sorry for the long delay with my response.

Anyway, Thankyou for your feedback. I have a few comments which I have added to your text below : 

Thanks, Tim.

-----Original Message-----
From: Marcus Watts [mailto:mdw at umich.edu] 
Sent: 18 September 2003 20:06
To: kerberos at mit.edu
Subject: Re: Kerberos / PAM Usage ? 

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.

Tim> Yes, I also spend time explaining to prospective customers and repositioning their understanding of authorisation versus authentication. They are often confused, but generally the market is getting more educated now ...

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".

Tim> I should have been more clear with my original email/post, but essentially I am considering a scenario where a Kerberos enabled application needs to log a user onto a UNIX system. Clearly the authorisation decision, where we need to determine if a user who has authenticated with a principal such as 'user at REALM.COM' is authorised to access a unix account called 'unixuser' can be done using .k5login files. However, this is clearly not easy to manage on a large scale and the desire is to migrate towards a centrally managed authorisating service, perhaps based on an LDAP directory. So, my thinking is that the application could authentiate the user to determine their principal name and then interface with a PAM module to determine if they are authorised to log onto a specific account on the system. The PAM module could then be configured to use .k5login, LDAP or some other form of authorisation rule lookup. Having a common way to determin the authorisation such as that provi!
 ded by PAM would allow the application to stay the same and only the PAM module needs to change when migrating to a better authorisation solution.

Tim> I would welcome your comments on the above suggestion ? Once again, sorry I was not more specific with my original questions.

>  
> 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.

Tim> If you have more than one service on a particular host (telnetd, AFS, other) do you see any advantages in using a PAM authorisation module so that authorisation checks can be made in one place rather than each service having to determine its preferred way to check authorisation ?

>  
> 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.

Tim> I was thinking of PAM for authorisation with GSS and not PAM for authentication purposes. Clearly when GSS is used to accept a security context it is authenticating the user and hence knows the principal name. My questions relate mainly to what happens when we have the principal name and want to determine what the specific principal is able to do within the realm of the application or service.

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.

Tim> Yes, this is good news. I was/am particularly interested to hear about using PAM as a common interface for authorisation across multiple applications such as ssh, xdm, local access etc. Regarding PAM and cleartext passwords - this is only for authentication, but if we take this out of the discussion and just look at PAM for authorisation of principals there are less issues.

				-Marcus Watts
				UM ITCS Umich Systems Group
________________________________________________
Kerberos mailing list           Kerberos at mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos