2

We are using Sitecore 10.1.3 PRE. The Azure AD login is setup only for the PRD environment.
A particular user is unable to login with AD.

On login, the error says

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

But on the top right of the CMS login page, the user's email is visible. The user is able to use Azure AD login successfully with other portals.

In CMS, a user is being created when logging in, but there are no roles. When I try to add roles. The next time that user logs in, all the roles are removed.

But, for some other users in User Management, who are also using AD to login, we can see the roles.

What could be the issue here.

Will changing the value to false help? Wanted to check first before making changes in PRD and lso not to impact existing users.

<externalUserBuilder type="Sitecore.Owin.Authentication.Services.DefaultExternalUserBuilder, Sitecore.Owin.Authentication" resolve="true">
<IsPersistentUser>true</IsPersistentUser>
</externalUserBuilder>
Improve this question

3 Answers 3

Reset to default
3

It is very likely to be what happened to me when applying a hotfix for 10.2. I wrote more about it here.

My interpretation of what Sitecore support conveyed in my support ticket:

The correct behavior for Federated Authentication is to allow the Identity Provider to control the user roles. The original implementation did not adhere to this and as such you could override the roles assigned to users from within Sitecore.

How to fix it:

  1. Apply custom code (as seen in my article) to restore back to previous version
  2. Use Azure AD/ADFS to control the access through the claims.
  3. Suffer through the issue until a hotfix for 10.3 is released.
Improve this answer
3

If anyone faces the same problem of roles getting wiped out in Sitecore 10.3, when logging in using federated authentication, here is the solution.

In the Sitecore config file Sitecore.Owin.Authentication.IdentityServer.config. We need to add the below setting inside the identity provider section just below the "domain" setting.

<clearroleswhensingin>false</clearroleswhensingin>

Please note that there is a typo error in the setting. Instead of "clearroleswhensignin" it is "clearroleswhensingin". Sitecore support informed that it will be fixed in upcoming release.

More details about the setting below:

The clearroleswhensignin setting determines whether the roles assigned to a user are managed in Sitecore, or in an external identity provider.

The default value is true. When set to true, when a user logs in, any roles that the user already has in Sitecore are removed and replaced by the roles assigned to the user in the external provider. If clearroleswhensignin is set to false, the roles already assigned to the user in Sitecore are preserved.

Change the setting to false if users come from an external provider, but you want to manage their roles within Sitecore.

https://doc.sitecore.com/xp/en/developers/103/sitecore-experience-manager/configure-federated-authentication.html

Improve this answer
1

Sitecore Persistent and Virtual Users

With external users, you have the option of creating virtual or persistent users. The difference being, virtual user dont exist in sitecore (information about this user is passed in cookie from IS). Persistent user is created in sitecore membership tables.

However - neither persistent or virtual users can have their roles changed in the user/role manager. Also, access viewer does not show the effect of these roles and associated permissions. The reason for this is because the roles are controlled by the external provider (Azure AD).

If your user does not have sufficient permissions to view a page, then it is most likely they do not have the necessary role in azure AD. For this you need to see what info is being passed back during the login process.

Viewing token passed from Azure / IS

To see what roles are being passed for a user, one option would be to capture a fiddler session of their login attempt. Then you need to look for server to server call to /userinfo endpoint.

The id_token, which is passed from the Azure AD can be found in the body of the response (SyntaxView) on the following request: https://login.microsoftonline.com/kmsi

You can decode the token using JWT.io website

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.