Yeah, I knew we could fix this via an AD cleanup. I was just hoping to avoid an AD cleanup (much more paperwork than changing a sssd.conf client setting). No such luck.
It's about 100 users that have improper gidNumber.
What problem does this pose? Lamentably, this is a privileged group that has sudo privs that allows the user to become root. Only Linux SE's should be in this AD group (due to company's segregation of duties policy).
This particular instance is an Oracle DBA. So according to company policy, Oracle DBAs are supposed to have the sudo privs to fully manage an Oracle DB. (stop, start, view logs, etc.) Oracle DBAs are not supposed to have full root. We've identified several Oracle DBAs with these improper gidNumbers.
Several of these accounts with improper gidNumbers are really Linux SE's. That's not so bad -- they should have full root any way (via a 'membeOf' attribute). So they're not bad -- until they change roles, their "memberOf" attribute gets revoked, but then they still have full root (because of gidNumber).
We'll fix it -- with an AD cleanup.
Spike