Configuring kerberos on Solaris

[Marcus Watts]

ganeshv at india.hp.com (Ganesh) writes:
> From: ganeshv at india.hp.com (Ganesh)
> From: ganeshv at india.hp.com (Ganesh)
> X-Newsgroups: comp.protocols.kerberos
> Date: 1 Apr 2003 08:48:08 -0800
> Organization: http://groups.google.com/
> Message-ID: <f0532362.0304010848.ba4e52b at posting.google.com>
> To: kerberos at mit.edu
> Subject: Configuring kerberos on Solaris
> X-BeenThere: kerberos at mit.edu
> X-Mailman-Version: 2.1
> Precedence: list
> 
> I'm tring to authenticate the users of my application
> from web with the kerberos set up. I've successfully 
> compiled the pam_krb5.so.1 from the source code provided in
> http://www.fcusack.com.
> I've set up my apache to load the pam module and all
> other related stuff. Now I'm able to authenticate the 
> users with all that I've.
> 
> But with the existing source code for pam_krb5.so, I'm
> able to authenticate only those users who have a valid
> unix account also apart from having a Kerberos account.
> My application has nothing to do with the unix login,
> so can I go ahead and tailor the source code to my need,
> i.e comment out the portion which looks for the unix login.
> 
> Is there any vulnarability, with this approach or is there
> any better way with which I can overcome this issue ?
> Please let me know your ideas and suggestions.
> 
> With Regards,
> Ganesh.

The most obvious problem I can see that you're going to have is what to
name whatever ticket file you create.  This is going to be a special
problem if you have the ability to authenticate more than one person at
the same time - or if you want to retain tickets for use "later on".
You can probably use ccache=/somewhere/using/%p for the "auth" module
type (and not %u) to get around this, but you'll still have to worry
about what Unix user ends up owning the file later on.

Another problem I think you'll have is mapping kerberos identities to
local identities.  That is what krb5_aname_to_localname does in
fcusack's code, which is affected by [realms]->realm->"auth_to_local"
in krb5.conf.  Possibly you can use this mechanism to map all kerberos
users in a given realm to one local unix user, then always do
krb5_aname_to_localname even for for users in the "default" realm.

			-Marcus Watts
			UM ITCS Umich Systems Group