Are there any performance issues with having lots of views?
> On Apr 10, 2018, at 7:55 AM, Simo Sorce <s...@redhat.com> wrote:
> SSSD cares only about the users it detects by design.
> The solution is to use ID Views on IPA to change the users UIDs on those
> machines. Hving the same users in files and ipa with different UIDs is not
> going to go down well and messing with PAM is just going to mnake the system
> even more brittle.
> The proper migration is to remove users from /etc/passwd, and use an ID View
> "correct" any posix data on the target machines, until you can rebuild new
> with the central names.
> On Mon, 2018-04-09 at 16:32 +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).
>> sssd-users mailing list -- firstname.lastname@example.org
>> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
> Simo Sorce
> Sr. Principal Software Engineer
> Red Hat, Inc
> sssd-users mailing list -- email@example.com
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
sssd-users mailing list -- firstname.lastname@example.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org