We are seeing the following in our sssd_default.log which appears to coincide
with some authentication failures. What would cause the hostname resolution to
expire? Can we change the length of whatever timeout might be causing this?
Sorry I have to obfuscate the hostnames per company policy.
>The way the code is currently written is, if there is a duplicate:
>- check if the "new" group has the same SID, uniqueID or original DN
> as the "old" one
> - yes, same: this is a rename, allow
> - no, different: this is a duplicate, error
I'm not clear on the start of this
It's a good discussion, and I don't necessarily disagree with your thoughts on
groups with the same GID, despite the nss_ldap implementation. I'd agree that
any change in behavior should have an option to revert to previous but that it
shouldn't be the default.
However, is the issue with
>I’m not so sure it would be a good idea to support this, honestly.
Well that rather depends on what you mean by "this". I was reporting a problem
that seemed an inconsistency to me. Either multiple groups with the same GID
are supported, or they aren't. The current implementation is
We are running SUSE 12 SP3 which uses SSSD 1.13.4 which I believe is a LTM
version.
Due to the large number of users and groups in our LDAP directory, and the
limitations of some legacy Unix systems, we have some large groups that have
been broken into "sub-groups" with the same GID but an
