prepping deployment of sssd in an environment with ~60,000 accounts,
~4500 groups, backend is AD. Some accounts are members of ~200
groups, whose total members might exceed 35,000 members total. None
of this is ideal, and frankly most of my issues can be attributed to
poor historic decisions around managing identity in this decades old
environment.
With "ignore_group_members = false", if a single account ( who is a
member of 200 groups, some of which have 35,000 members) runs "id" it
can take minutes to complete on an uncached sssd client. With this
configuration option set to true, the operation can complete in a few
seconds on an uncached sssd client. This is great, however the
accounts in this environment are fond of running getent group
<some_group> and returning <some_group>'s member list, which is
disabled with "ignore_group_members = true".
I was wondering if I missed a configuration item that might allow both
"quick" id <account_with_many_large_groups_as_member> operations AND
getent group <some_group>?
Assuming no configuration item to address this, Is it conceivable that
sssd could consider foregrounding "id" type operations for accounts
when all that is being requested is a list of group ids and group
names for a single account, while deferring or backgrounding all of
the group member enumeration happening on the backend when "id
<account>" is run? If this is conceivable perhaps a pointer to where
I might look in the code to see about this?
Perhaps I'm barking up the wrong tree, and it's simpler to write a
wrapper for getent group that caches the equivalent ldapsearch?
Thank you for your consideration and development of this software.