I was not expecting to write another post about Sitecore Identity Server and Azure Security Groups limit since I thought that by finding the magic number last time and the workaround by reducing users’ membership would be sufficient.

If you are reading this, note that I WAS WRONG! 🙂

In summary, the first blog about Sitecore Identity Server and Azure AD Security groups limits, the user was member of 180 Security Groups and after provide its credentials, it was either redirect to a HTTP 431 error page or a blank page but never to Sitecore Experience Platform.

Differently from last time, the user is getting the following error message

You do not have access to the system. If you think this is wrong, please contact the system administrator.

Well, this is exactly the error I wrote on the troubleshooting guide on my last post, so if you didn’t read yet, please do! And prior to continue my investigation, I have followed the three steps listed there

1. User’s Azure AD Security Groups
2. Check the existence of the Azure AD Security Groups claiming a Sitecore Role in ..\sitecore\Sitecore.Plugin.IdentityProvider.AzureAd\Config\Sitecore.Plugin.IdentityProvider.AzureAd.xml
3. Verify the existence of the Sitecore Role

In addition to that, I’ve also checked the number of the Azure AD Security Groups the user was member of, and for my surprise the user had 54 groups which is a way far from the magic number – 170 – we have found in the first part of this series.

Since the user couldn’t sign-in and, apparently, nothing was wrong with the account, its membership, and so on, a Sitecore ticket was opened. And in order to performa a further analysis, a Fiddler Session from the problematic user, and a working user was requested.

The Fiddler Session must be configured to leave all the calls in the session and check Tools -> Options -> HTTPS -> Decrypt HTTPS Traffic

Once, you have the Fiddler Session, look for the following line /signin-oidc because there you will be able to find the token used to request authentication at the Azure AD.

Fiddler analysis of problematic user

1. Look for /signin-oidc
2. Click at Inspectors
3. Click at Raw
4. Click at View in Notepad
5. Copy everything after id_token=
6. Access jwt.ms, and paste the content from item 5

Fiddler analysis of working user

Basically, repeat all the steps we’ve made for the problematic user, and check its id_token in jwt.ms

Working vs Problematic user

While the working user is sending the groups through the token, the problematic user is not hence there’s no way the user authenticate properly.

After coming up with this analysis, Sitecore Support believes the user might belong to nested groups which exceeds the 170 Azure AD Groups hence it is causing the claims not being returned.

Sitecore support then suggested the following

1. Decrease the number of groups some of your users are in
2. Create a separate Azure Active Directory for managing just Sitecore groups
3. Move the Sitecore permissions from the “Azure AD Security Groups” to “Azure AD Application Roles”

In order to keep our sanity here, I am going to cover these possibilities in the part 3 of this blog post.

I hope I hope you liked it, and I’ll see you on my next post!

Photo by Meritt Thomas on Unsplash