On Wed, Apr 12, 2017 at 08:59:51AM -0600, Joshua Schaeffer wrote:
> On Wed, Apr 12, 2017 at 1:26 AM, Jakub Hrozek <[email protected]> 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.
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
