In regard to: Re: which krb5 PAM module on Solaris 8?, Sam Hartman said (at...:
>>>>>> "Brian" == Brian Davidson <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ________________________________________________ Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos