This is part 3 of an 8 part post covering the process used to trace down and correct a problem with semanage login record group matching. If you have not already read the previous parts, you may want to start at the beginning

Finding a reproducer

System group to selinux user mapping had to be working in general or we would have had an uproar as all sorts of things broke down (my account included), but I tested it anyway. Sure enough, an existing test user in an existing test group was mapped into its correct selinux categories, a new session as my user was similarly fine. A new test user in a new test group with a new test mapping worked too. One group mapping was failing while other very similar ones worked without issue, strange.

At least that eliminated a global ldap or sssd problem. So far, the problem appeared to be isolated to Alice, which did not make much sense.

Not exactly in a hurry to start diving into the weeds blind, nor thrilled about continuing to pick on the brand new hire's account, I wanted a way to reproduce this with a test user. There was not a whole lot of different between the two accounts to begin with, except or course one was working and the other wasn't. Two obvious variables came to mind, but neither seemed particularly likely:

  1. The uidNumber on Alice's account happened to be a new high water mark
  2. The test user had been provisioned into a set of test groups, not as a production member of 'ft-financial-accounting'.

Simple enough to test. I had been bitten by a number of sssd problems recently, maybe there is some strange interaction with the high uidNumber. That was pretty unlikely given that id was working, but it was quick and easy to confirm. One minute later I had a test user with an even higher uidNumber (details of the situation prohibited just trying with the number Alice's account had been assigned) and no group mapping problem. That left one other significant difference, the group itself.

Checking the group was also relatively simple, it just required migrating the test user's role to that of a live member of the 'ft-financial-accounting'. When I did so, the test user's mapping stopped working.

So, some group mappings were working fine, it was not a global ldap or sssd problem, just 'ft-financial-accounting' (a new group to the system) seemed to be having problems. After eliminating the common sources of NSS user/group issues, namely typos or ldap mistakes (user not in group, gidnumber conflicts, ...), I started hunting for what would cause one group mapping to work and not another.

Next up, part 4: Narrowing the scope.