Hi,
Despite some progress (thanks to offline discussions with @ThiefMaster !), I’m still struggling with some of our users after doing the change described above. During my tests before the change I was able (I thought I was!) to assess that the email matching was using the LDAP attribute defined for Indico email aattribute, in our case (in the mappings section of the identity provider):
'email': 'physicalDeliveryOfficeName',
But I have a user failing to get the access honoured since the change and I was only able to restore its access by restting the LDAP mail attribute to its previous value. For this user no identifier was matching the LDAP mail attribute (only the physicalDeliveryOfficeName) and the Indico username was different from the AD userid.
Reading LDAP groups authorization, I tried the different checks suggested and was surprised to see that the member list of the group involved in the access control cannot be listed, despite it works for hundred of users… Not sure what does it mean but the suggested checks for group membership don’t work even for the users having in fact access to the restricted pages, so it’s probably something different. On the AD side this group is made of nested groups, may be this the reason…
Michel