On Wed, Nov 16, 2016 at 05:13:17PM -0000, brettswift(a)gmail.com 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 -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org