VCFA OIDC Groups and the Case Sensitivity Trap

I federated one of my VCF Automation tenant orgs to vIDB the other day. I imported the labAdmins@int.sentania.net group from AD, gave it Organization Owner, and figured I was done. Individual users I'd imported logged in and got their roles just fine. The group did not. Same identity provider, same login flow, and the group members landed in the org with nothing.

Where things went sideways

My first instinct was that the OIDC config on the org itself must be wrong, the scopes or the claim mapping not set up right. I went and checked, and it was fine (that's actually a separate post, because I found a different tenant with that exact problem). So the token was carrying the group. VCFA just wasn't matching it.

vIDB emits the groups claim in lowercase, straight off the sAMAccountName: labadmins, which for consistency I had renamed from labAdmins a while back.

VCFA matches the token's group claim against the imported group name as an exact, case-sensitive string. labadmins from the token never equals labAdmins as imported, so the member gets into the org with no group and no roles to go with it.

The fix, and the part that cost me the most time

The obvious move is to just re-import the group as lowercase and move on. I tried that first. It didn't work...

It turns out, VCFA's group import de-duplicates case-insensitively. So when I imported labadmins, VCFA looked at what was already there, matched it to the existing labAdmins entry, and merged into it, keeping the original capital-A name on the stored object. The group list still showed one labAdmins, same object ID as before. Import matching is case-insensitive. Login matching is case-sensitive. Those are two different rules living in the same feature, and nothing in the UI tells you that's what just happened.

The only way out is to delete the mis-cased entry outright.

With nothing left to merge into, importing labadmins fresh stores it exactly as typed.

I assigned Organization Owner and this time the group's members picked up the role on their next login. While I was in there I also added a couple of the individual admins, Navani among them, as OIDC users with the same role, matching how I'd already set up the service account.

If you're federating a tenant org and users log in fine but a group doesn't, check the casing on the claim before you check anything else. The group_names value coming out of vIDB is the source of truth, not whatever casing the rest of your VMware stack has trained you to expect.