On Mon, Apr 09, 2018 at 08:51:41PM +0000, Charles Hedrick wrote: > Thanks.The krb5_map_user option does actually work for mapping usernames. > > But it doesn’t solve the more serious problem, which is that id_provider = > ipa leaves the credentials owned by the wrong UID. I tried auth_provider both > ipa and krb5, and it both has the same problem. It appears that sssd uses its > internal id provider rather than nsswitch when deciding what UID should own > the credentials.
Yes, SSSD will always use its "own" users. The krb5_map_user was added to allow Kerberos authentication for "completely" local users. But in this case you typically would use the proxy/files provider which does not work in your case because you want to manage the group memberships in IPA. > > I have a feeling I could use views for this, but managing them a large number > of user-owned systems systems difficult. Yes, views and overrides were created to handle this type of migration scenarios. Since the overrides are managed on the server using them might be easier than managing krb5_map_user on each client. HTH bye, Sumit > > To be clear, the problem is this: > > user foo is uid 1000 in /etc/passwd > They have an entry in IPA with uid 1005. > nsswitch.conf is “files sss" > > When foo logs into the system, “id” shows they are logged in with UID 1000, > as expected. But “echo $KRB5CCNAME” shows KEYRING:persistent:1005:xxxx” and > klist shows that they can’t access the credentials, even though they’re > actually there. > > I wrote a pam module that detects this condition and copies the credentials > to a new cache with the right owner. But I don’t think we want to commit to > maintaining that kind of hack. > > > On Apr 9, 2018, at 3:12 PM, Sumit Bose <sb...@redhat.com> wrote: > > > > On Mon, Apr 09, 2018 at 04:32:00PM +0000, Charles Hedrick wrote: > >> I’m trying to support an odd configuration. > >> > >> We have an IPA system, which is used in the normal way for systems run by > >> staff. But we have hundreds of systems run by faculty and grad students. > >> I’d like to encourage them to integrate with our system. However their > >> usernames and UIDs don’t typically match ours. I don’t think there’s much > >> I can do about usernames. But I’d at least like to survive differing UIDs. > >> Kerberos and even NFS V4 don’t care about UIDs. > >> > >> So I set up sssd pointing to IPA, with access_provider = deny (meaning > >> only people accepted by pam_unix can login), and nsswitch.conf having > >> “files sss." If a user logins in with the Kerberos password they’re logged > >> in correctly, but they can’t access their own Kerberos credentials. > >> > >> Their logged in UID is the one in /etc/passwd, because login correctly > >> obeys nsswitch. But their Kerberos credentials are for the UID in IPA. > >> > >> I can change id_provider to proxy/files. But then the sss nsswitch map > >> doesn’t work. I need to get groups from IPA in order to interpret groups > >> on our Netapp. I’d like to get users from IPA when there isn’t an entry in > >> /etc/passwd, so that ls -l on the Netapp can interpret user names. > >> > >> So what I’d like is that when sssd creates Kerberos credentials, it uses > >> the same user that login is going to use, i.e. that it obeys nsswitch. Is > >> this a reasonable expectation? > >> > >> Going further, I’d like a way to do username mapping that will work with > >> both sssd and Kerberos. One approach would be to pay attention to the > >> username map in /etc/krb5.conf or idmapd.conf, since I’d have to put the > >> mapping in both (I think). > > > > Maybe the krb5_map_user option can help, please see man sssd-krb5 for > > details. > > > > bye, > > Sumit > > > >> > >> _______________________________________________ > >> sssd-users mailing list -- sssd-users@lists.fedorahosted.org > >> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > > _______________________________________________ > > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org > > _______________________________________________ > sssd-users mailing list -- sssd-users@lists.fedorahosted.org > To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org _______________________________________________ sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
