Sitecore Identity Server Azure AD plugin issue when user has more than 250 roles

Our team recently ran into an issue when a user Azure AD account refused to work with Sitecore Identity Server. Each time the user would try to log in, Sitecore would refuse to let him in displaying an error message consistent with the user not being assigned to any groups in AD that would match with any Sitecore roles. After a few hours of debugging and googling I have decided to run the following SQL script that helped to get some visibility into the issue.

SELECT TOP (1000) [SessionKey]

      ,[Data]

      ,[Accessed]

      ,[ID]

  FROM [ClientData]

The script was run in the Master DB. The select statement returned a few records with the one in question among them. Each record that represented the user that ended up being signed in into Sitecore without any issue had the group claims collection populated. However, the user that experiences issues instead if the groups claim collection had two new claims while group claims were totally empty.

The new claims looked like this:

{

  ...

  "_claim_names": {

    "groups": "src1"

    },

    {

   "_claim_sources": {

    "src1": {

        "endpoint":"[Graph Url to get this user's group membership from]"

        }

    }

  ...

}

It turns out that the user was a member of a lot of groups in Azure AD and the number of groups exceeded 250 and that resulted in two additional claims and empty group claim collection.

This is a very rare occurrence as far as I know, and we ended up leaving it alone simply because we had only one user who had this issue and he wasn't a person who would be signing in into Sitecore on a regular basis. However, we did confirm that to make the roles work properly we would have to have a custom implementation of AzureAD plugin where we would have to have a call to Graph API for these users to retrieve the full list of groups that the user belongs to.

Coveo for Sitecore CD configurations and Encryption Keys

This topic is covered in Coveo documentation, but we found a quicker way to sync up Encryption Keys between all CMs and CDs. It might not be the best option if you are don't feel comfortable making database changes directly, but if you are confident in your SQL skills you might find the following script handy.

As Coveo documentation states the Encryption Keys values must match between all instances. By default, the key is generated at the first request and inserted into the Properties table in Sitecore Master or Web database depending on the version of Sitecore you are using.

The following SQL script will give you the value of the key:

SELECT TOP (1000) [ID]
      ,[Key]
      ,[Value]
  FROM [Properties]
  WHERE [Key] = 'WEB_ENCRYPTIONKEYS'

Copy the value of the "Value" column, update it in the following script and run it in all CM and CD Master or Web databases (depending on the Sitecore version).

  UPDATE [Properties]
  SET [Value] = 'MfAX2CR14H8mZFlzGoE6dEnLjXX48S5Ho2b/9RP7L7kl4LEg6CENyMCLx6kLjzh4'
  WHERE [Key] = 'WEB_ENCRYPTIONKEYS'

Reset IIS in all instances.

Sitecore Identity Server Azure AD plugin and "Site can't be reached" error

Recently we ran into an issue while configuring Azure AD plugin in Sitecore Identity Server. After enabling the plugin and double-checking of the Tenant and Client IDs values we were still getting the following error when the user would return from Azure back to Sitecore Identity Server endpoint.

Running a Fiddler trace showed that when the request is made to the Sitecore Identity Server the error code that is returned was 400 - Request too long. After several hours of trying different things and googling for the "Sitecore can't be reached" error, I finally found the cause of our issue. 

A very nice and detailed blog that I found explained not only the issue but also provided the solution which worked perfectly in our solution. You can find it at https://topic.alibabacloud.com/a/modify-maxfieldlength-and-maxrequestbytes-to-completely-resolve-request-too-long-problem-_win-server_8_8_20115811.html

Apparently "when IIS7/7.5 receives a request header that is longer than 16K (the default), a bad request-request Too Long is raised. HTTP Error 400. The size of the request headers is too long. of errors."

To resolve this error we added the two registry keys that the blog was calling for. 

In Registry under "Hkey_local_machine\system\currentcontrolset\services\http\parameters" we added two DWORD (32-bit) keys:

1. MaxFieldLength with a value of decimal 32768;
2. MaxRequestBytes with a value of decimal 32768.

After these changes were made and the server was restarted the error went away!