[SSSD-users] sdap_save_user save user SID issue

Chris Gray fathed at gmail.com
Thu Jan 30 08:56:31 UTC 2014


Hello, all this to inform you all of the solution to the problem I
encountered.

It of course follows what is often said on this list, don't add ldap
parameters unless you really know what you're doing.

I had an ldap_search_base that was set to an OU, and SSSD needed access to
a lower level of the AD structure than was allowed by my search base
setting.

I of course thought setting that would optimize the queries to AD, as all
the accounts were below the OU I had specified. I was incorrect.

Sumit from RedHat helped me out and suggested removing the search base.

Thanks!
Chris


On Fri, Jan 10, 2014 at 3:06 AM, Chris Gray <fathed at gmail.com> wrote:

> I'll check with my security team, and hopefully be able to send them to
> you tomorrow. I might do so from my work email account, but I'll mention my
> gmail address on there as well.
>
> I assume you'll want a copy the configuration files, so I'll send those
> with the logs if I'm able.
>
> Unfortunately gmail didn't notify me of your response (or I missed it),
> while I was sending that one.
>
> Thanks again!
> Chris
>
>
> On Fri, Jan 10, 2014 at 3:01 AM, Sumit Bose <sbose at redhat.com> wrote:
>
>> On Fri, Jan 10, 2014 at 02:32:48AM -0800, Chris Gray wrote:
>> > I'll install the ldb-tools tomorrow (I went home) and try that out.
>> >
>> > The SID and the RID are correct, verified visually and used a windows
>> > utility to search the domain based on the SID to verify it was correct
>> and
>> > returning the correct account from AD (psgetsid.exe). I'm also working
>> on
>> > converting the SID and RID to reverse hex so I can use ldapsearch on the
>> > linux machine to triple verify, but I haven't completed that yet.
>> >
>> > The computers with SSSD version 1.9 correctly show the RID as the last
>> > digits of the unix UID. My default domain group is Domain Users as well,
>> > which always has a RID of 0513, and that correctly shows as the last 4
>> > digits unix GID on the computers with 1.9.
>> >
>> > Reading those bug reports more may had lead to a solution.
>> >
>> >          ldap_idmap_default_domain_sid (string)
>> >                Specify the domain SID of the default domain. This will
>> >                guarantee that this domain will always be assigned to
>> slice
>> >                zero in the ID map, bypassing the murmurhash algorithm
>> >                described above.
>> >
>> >                Default: not set
>> >
>> >            ldap_idmap_default_domain (string)
>> >                Specify the name of the default domain.
>> >
>> >                Default: not set
>> >
>>
>> Please note that those options have a special purpose and should not be
>> needed in your setup. Nevertheless they might lead to a working
>> solution by hiding the original issue. With those two option a domain is
>> pre-created in the idmapping code. If the SID matches the domain SID of
>> your user the user will get a POSIX ID and you won't see the errors you
>> posted earlier. But in general the AD provider is able to auto-detect all
>> domain in your forest and create the needed idmapping entries
>> automatically. I assume that there is an issue to detect of domain and
>> its domain SID or to create the needed idmapping entries. This is why I
>> asekd for the full logs.
>>
>> bye,
>> Sumit
>>
>> >
>> >
>> > I'll try those out tomorrow as well. I'm not sure they'll work since I
>> > got them from version 1.9 docs. I don't have them set on the computers
>> > I have that use SSSD 1.9, and they don't exhibit the problem.
>> >
>> >
>> > Thanks again,
>> >
>> > Chris
>>
>> > _______________________________________________
>> > sssd-users mailing list
>> > sssd-users at lists.fedorahosted.org
>> > https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>>
>> _______________________________________________
>> sssd-users mailing list
>> sssd-users at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>>
>
>
>
> --
> Intelligence is a matter of opinion.
>



-- 
Intelligence is a matter of opinion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/sssd-users/attachments/20140130/97fa5fdc/attachment.html>


More information about the sssd-users mailing list