On Wed, Nov 16, 2016 at 05:13:17PM -0000, [email protected] wrote: > Update: > > I had the Unix guy add a GID to the group.
Whether this is needed depends on whether the setup uses POSIX attributes (id mapping = false) or ID mapping. By default the ad provider uses ID mapping. The name of the group in the allow list must match the group as listed in the "id" output. > The group scope is set to "Domain.local" and one of our "Unix Admins" said > the group needed to have it set to "universal". Which I have not yet done. This shouldn't be the case as long as the group comes from the joined domain. Domain-local groups are only filtered out from results from trusted domains. > > However, I am getting 60% success rate logging in. You're running a pretty old version and we had a bug with ignore_group_members together with AD provider for some time. I would suggest to upgrade for sure -- the 1.13 version in RHEL-6.8 is quite stable. If you can't can you at least temporarily disable ignore_group_members=false? This old version had IIRC also some bugs when the (default) tokengroups optimization was enabled. You might want to try disabling that, too for a test if you can't upgrade. > > If anyone has any advice on what I can grep from the log files that would > help me find the issue here, that would help. > > running tcpdump shows that the AD server (i'm using DNS to resolve them) I > connect to, doesn't show consistency. IE: out of 4-5 IPs it's connecting > to, some IP's show both successful logins and failures. That to me, > eliminates flaky AD response - and maybe highlights a network issue. > > Is there anything on the SSSD side I can inspect to see if the linux config > itself might be an issue? > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
