which krb5 PAM module on Solaris 8?

Tim Mooney mooney at dogbert.cc.ndsu.NoDak.edu
Mon Aug 4 15:42:50 EDT 2003


In regard to: Re: which krb5 PAM module on Solaris 8?, Sam Hartman said (at...:

>>>>>> "Brian" == Brian Davidson <bdavids1 at gmu.edu> writes:
>
>    Brian> Why not use nsswitch for authorization?  I'm assuming it's
>    Brian> available on Solaris since Sun developed it (I don't have
>    Brian> any Solaris boxes at the moment).  Basically all password
>    Brian> file lookups are redirected to LDAP via nss_ldap.  It seems
>    Brian> to me that authentication is best left to PAM, while
>    Brian> authorization is better handled by a hook into the system
>    Brian> calls that are used for authorization (i.e. what nsswitch
>    Brian> does).
>
>Because existence in the password file should not be tied to
>authorization.

Agreed, wholeheartedly!

>Also, for things like time-of-day based authorization, having the user
>suddenly drop out of the password file would be undesirable.

Exactly.

>PAM has hooks for this; they work about as well as the rest of PAM.

In your opinion, how well is that?

As the person that started this thread, I definitely appreciate everyone's
responses so far.  There are more pam_krb5 modules out there than I thought,
and (unfortunately) there isn't a clear-cut favorite, at least if you're
going to restrict yourself to source-available modules.

Sam and others have suggested what seems to be the "Right Way", i.e. use
the SEAM pam_krb5 module for authentication, and write our own
authorization module.  This is the most elegant solution and it's
something I'm definitely going to look at long-term.

There are a couple possible problems with "The Right Way", though.  First,
I'm no PAM expert.  Assuming there's enough valid documentation out there
for how it works on Solaris, I could certainly become one, but that may
not be feasible in the time I have available before I need the module.

Second, the North Dakota University System and especially NDSU, where I
work, have been essentially a testbed for the development of the Hurderos
IAA system.  In the Hurderos system, users have a (mutable) unique electronic
identifier, generally FirstName.LastName but users are allowed to change
their electronic identifier and since it must be unique
collision-avoidance might give you something like FirstName.MI.LastName.2
as your electronic ID.

That electronic ID is tied to their unique POSIX username, which is
immutable.  The POSIX username is what they would have in the passwd file
on a UNIX box, and it's also how they appear in the Kerberos 5 realm.

For a UNIX system to fully function as a part of the Hurderos system, a
user should be able to telnet (or whatever) to the box, type in their
electronic ID, e.g.

	Tim.Mooney

have the system look up their immutable POSIX username (e.g. mooney) via
an LDAP search, and from then on their POSIX username is what the box
knows them as *and* it's what's used when the system does authentication
against the Kerberos 5 realm.

Assuming they authenticate correctly, the authorization phase needs to
check LDAP to see if the given POSIX username is authorized for the
service(s) that are hosted on the box they're trying to connect to.  For
example, on a box that provides UNIX login services, the authorization
phase would need to check LDAP for the user in question, making sure that
they have a

services=UNIX_LOGIN

LDAP attribute (the service attribute is multi-valued, not that it matters
for this example).  If they don't have UNIX_LOGIN somewhere in their
services attribute, they're not authorized and hence don't get in.

As you can see, though, to fully function within this system, I'm in need
of a PAM module that can essentially do "username conversion" as part of
the authentication phase, because what a user supplies at the telnet
prompt as their username may not be what their actual underlying
identifier is on the system (and it may not be what is used as part of
Kerberos 5 authentication, so the "username conversion" needs to happen
*in* the authentication phase)

It's my understanding that the PAM API supports this feature (i.e. who
you supply at a login prompt may be different from your underlying ID on
the box), but most PAM modules don't bother to call whatever function it
is that PAM has that does the username conversion.  I'm not (yet) a PAM
guru, though, so I could be wildly mistaken.

That's why I believe I need a source-available pam_krb5 module for
authentication, instead of going with something like SEAM's authentication
module.  If I'm wrong, I would love to hear about it.

For the particular Solaris box in question, it's not currently doing the
electronic ID to POSIX username conversion anyway, so it's not fully
functioning as part of the Hurderos system right now.  Users that want to
authenticate to that system are required to know and use their POSIX
username.  That means that I wouldn't be losing any functionality over
what I currently have if I do go the route of SEAM for authentication and
homegrown for authorization, but it would be best if I could find a way
of fully integrating our Solaris boxes into the IAA system we're currently
using.

I appreciate all the info people have provided, and I look forward to any
additional comments or suggestions people might have.

Tim
-- 
Tim Mooney                              mooney at dogbert.cc.ndsu.NoDak.edu
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164


More information about the Kerberos mailing list