When the schema is set to AD and ID mapping is used, there is a one-time
check ran when searching for users to detect the presence of POSIX attributes
in LDAP. If this check fails, the search fails as if no entry was found
and returns a special error code.
If the AD identity lookup finds this error code, the GC is disabled for
the next search.
The sdap_server_opts structure is filled every time a client connects to
a server so the posix check boolean is reset to false again on connecting
to the server.
It might be better to move the check to where the rootDSE is retrieved,
but the check depends on several features that are not known to the code
that retrieves the rootDSE (or the connection code for example) such as what
the attribute mappings are or the authentication method that should be used.
Currently this patch only runs the check when users are requested. It
would be trivial to add the same code (about 70 lines) to the group
request as well.
Additionally, I wonder if the absence of POSIX attributes in GC should
be reported louder. Currently there is just MINOR_FAILURE.
We could go as far as report to syslog when a user or a group from
subdomains is requested and the GC was already disabled, but I wanted to
check with the other developers before implementing this.
Hi, there is a bit of a debate going on over on the samba list, about
using sssd or winbind. It is now being said that sssd should not be used
on a file server because sssd cannot do what winbind can do.
So here are the questions:
Just what are the differences between using sssd and winbind.
Can sssd be used on a fileserver and if not, why not.
Oh, and we are talking about an AD domain here.
While looking at another issue I realized that we used a wrong
formatting conversion for UID/GID values - %d. For very large values,
there were sometimes overflows (-1) in the DEBUG logs. The attached
patch converts the format specifier to PRIu32 as the value we print is
I'm fine with pushing this patch atop Nikolai's patches so that we don't
make him rebase the large patchset again.
another smaller issue I found when working on other patches. I quickly
scanned the rest of the code and I think we have a similar issue
elsewhere, so we can either accept this patch or file a ticket and fix