On Wed, Oct 28, 2009 at 7:02 PM, Glenn Barry <Glenn.Barry at sun.com> wrote: > > (adding Cc: of kerberos-discuss)
(dropped security-discuss after notifying list) >> >> >> >> >> 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 That's not quite right. My sample username is mapping of the 9-digit number to something that is compatible with Solaris. For example, 100456789 at AD.MYCOMPANY.COM has a Solaris username of a0456789. I need pam_krb5 to realize that when a username of a0456789 is provided that it corresponds to the principal 100456789 at AD.MYCOMPANY.COM. While there is a pretty simple algorithm to do the mapping, I am happy solving a more general problem by doing a lookup. > > 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. Yeah, that is a risk too. However, that risk on its own doesn't grant access to a machine. It does greatly simplify attacks to get access. > >> - 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). That would be too easy. How about a0456789 at UNIX.MYCOMPANY.COM == 123456789 at AD.MYCOMPANY.COM? That is, the username mapping trips me up. > > 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'll let the thread go for a couple days so that if anything useful comes out of it that I can get that in there. Unfortunately, I only get one chance to put my thoughts into a RFE - after that I have to bug others. :( > 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 Thanks much, Mike > >> >> >> 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? >> >> > > -- Mike Gerdts http://mgerdts.blogspot.com/
