On Wed, Apr 12, 2017 at 08:59:51AM -0600, Joshua Schaeffer wrote:
On Wed, Apr 12, 2017 at 1:26 AM, Jakub Hrozek
<jhrozek(a)redhat.com> wrote:
> [...]
>
> Here is the reason:
>
> > (Tue Apr 11 16:13:42 2017) [sssd[be[WINNT]]]
> > [sdap_nested_group_hash_group] (0x2000): Marking group as non-posix and
> > setting GID=0!
>
> So the group was found and saved, but SSSD decided the group is not
> eligible to be returned for the OS. This could be because SSSD filtered
> the group type (domain-local groups from trusted domains are filtered)
> or because the sssd is configured to use POSIX attributes, but the
> object doesn't have them.
>
> Increasing the debug_level some more would show more messages,
>
Thanks Jakub. I have the debug_level at 8 right now. I was wary of turning
it to 9 as that may have outputted a lot of trace messages, but I could
definitely try that and see what messages I get.
You can try:
truncate --size 0 /var/log/sssd/*
sss_debuglevel 9
sss_cache -E
getent group $groupname
sss_debuglevel 0
That way the debug logs would only contain the single lookup of the
group..
Should I configure this
domain to not use POSIX attributes? Is that a wise decision and/or
recommended?
It's already done, actually. The id_provider=ad defaults to
altorithmically mapping UIDs and GIDs from Windows SIDs (see the section
"ID MAPPING" in the sssd-ad manpage). So I think the only reason the
group could have been marked as non-POSIX (and at that point, the group
being non-POSIX is just internal SSSD lingo) could be the group type
which would only be shown with a higher debug level I think.