(adding Cc: of kerberos-discuss) > > > > > I'm trying to understand the feasibility of leveraging Kerberos > provided by an existing Active Directory implementation for use with > Solaris machines. The tricky part of it is that the the user names > chosen in AD are all 9-digit numbers, which are not compatible with > OpenSolaris, Solaris, etc. > > I'm not expecting that my questions have simple answers. I'm willing > and able to write code to solve my specific problem as well as the > general problem of Kerberos to UNIX credential mapping across a large > number of machines. I'm starting this discussion to gain an > understanding of the scope of the effort and to gain any historical > insight as to why things are the way they are. I am particularly > interested in approaches that allow a port to Solaris 10, RHEL, etc. > Note that I have not yet promised to do this. :) > > > Use Cases > > To deal with mapping of user names to principals, it seems as though > there are the following use cases: > > UC1. User without existing kerberos ticket authenticates through a > normal login program (gdm, sshd, etc.). > UC2. User with an existing kerberos ticket logs into a remote machine > via ssh. > UC3. User with an existing kerberos ticket would like to access other > remote kerberized services (e.g. NFS) > > I believe that UC1 is not handled gracefully right now because > pam_krb5 has no hooks into anything that knows to try to obtain a > ticket for principal that is anything other than login at REALM.
Correct. It's RFE 6670117 Allow pam_krb5 to switch Kerberos realm Pls add your name/company to it so we have justification to fund a future project, thx. > > I believe that UC2 can be handled today, but not elegantly. That is, > krb5_auth_rules(5) says that each user can have a ~/.k5login file that > provides a list of principals that are authorized access to the > account. Alternatively, gsscred(1M) can be used to map principals to > UID's. I'll cover the lack of elegance later. > > I beieve that UC3 may or may not be handled today. In a pure > Solaris/OpenSolaris environment, I think it is covered with the > gsscred(1M) mechanism above. I'm not sure what the story is if other > NFS servers (e.g. NetApp) or other NFS clients (HP-UX, Linux) are > involved. > > > Lack of Elegance > > As mentioned in UC2 above, there is some lack of elegance where > support does exist. In particular: > > - If ~/.k5login is on NFS either there is a reliance on the extremely > weak AUTH_SYS RPC security or the home directory and file need to be > world-readable. (fishing for corrections on this one... I haven't > done kerberized NFS in a while) Correct, if you want good NFS sec you should use RPCSEC_GSS RPC flavor w/krb5 mechanism. But if you are worried about .k5login avail via AUTH_SYS you may have other important files like ~/.profile ($PATH changes and such) that are vulnerable now/too. > - Credential mapping needs to be managed through gsscred(1M) on all > hosts. This is a rather daunting task when you have more than a > handfull of machines and any sort of user turnover. Yes, it needs to have an nss/ldap (secure) backend for cases like yours. I think the gsscred backend was originally via FNS (w/multiple backends) but then it got EOLed which left a file per sys (and each user *had* to be in that file). We then in Sol10 changed it to dynamically gen the mapping for the local realm which was a big win on several levels. Also note there are easy ways to map realms via krb5.conf to make realms equiv (bob at R1 == bob at SUB.R1, for example). But a net backend for gsscred is probably best for your case where you want to map per user realm-wide. I looked for an RFE but could not find one so pls file one and we can track it. Or if you want me to do it, let me know. And if you have time/inclination to do it via an opensolaris project that would cool. I won't comment on the solution space at the moment but will ask around to see if there is any good way of doing this now for Sol 10 that I missed. Thanks, glenn barry Solaris Kerberos > > > Likely Solutions > > 1. Dump this whole notion of trying to use the existing AD Kerberos > and establish a new realm that doesn't have the username mapping > issues. The key reason not to do this is because this one already > has integration with an identity managment system, has a support > team, etc. > 2. Discover a way to have some sort of a proxy kerberos > infrastructure that transparently mapsunixuser at UNIX.MYCOMPANY.COM > toaduser at AD.MYCOMPANY.COM. I've searched a bit and haven't found > such a thing. Pointers welcome. > 3. Write some code. > > With option 3, I think the code to write is: > > 1. Extend the existing LDAP schema used for UNIX accounts such that > it contains the kerberos principal name for each account > 2. Enhance pam_krb5 so that it uses pam_get_data() to see if a > login to principal mapping exists. If so, use it instead of the > built-in algorithm. > 3. Write a PAM module that makes a call to LDAP to get the login to > principal mapping, if it exists. Use pam_set_data() to provide > the information to pam_krb5. Call or mimic gsscred(1M) to update > gssd, presumably as part of pam_sm_setcred(). > > > General Questions > > Does it seem like I am heading down the right path by trying to > establish this type of interoperability? > > Is there a good reason that gssd doesn't have an NSS or similar > backend? > > Surely I've missed some landmines. Where are they? > >
