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