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@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@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@lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/sssd-users

_______________________________________________
sssd-users mailing list
sssd-users@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users



--
Intelligence is a matter of opinion.



--
Intelligence is a matter of opinion.