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(a)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(a)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(a)lists.fedorahosted.org
> >
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
>
--
Intelligence is a matter of opinion.
--
Intelligence is a matter of opinion.