[Solved] Attach item in Sitecore Application Access Denied error

One of the most frustrating things to see is an Access Denied error, because, usually, you were supposed to have the clearance to perform the action you are being blocked for.

This week, I received a request saying that an Application Access Denied error was popping up when trying to Attach an item in Sitecore. And here is how the error looks like.

Server Error in ‘/’ Application.
Application access denied.
Description: An unhandled exception occurred during the execution of th current web request. Please review the stack trace for more information about the error and where it originated in the code.
Exception Details: Sitecore.Exceptions.AccessDeniedException: Application access denied.

It is possible to check for the error in Application Insights, and occurs during the operation GET /sitecore/shell/Applications/Dialogs/Attach/Attach2.aspx

Initial verification

Check User Membership

Let’s check which permissions the user has by going to User Manager

Then find the user, click twice to open its information, and choose Member Of tab

Check Role Permissions

Since we now know which Role the user is assigned to, let’s go back to Sitecore Experience Platform and go to Desktop

At your bottom right, click in master and then in Core. This is going to change the database context.

Navigate to Sitecore icon, Security Tools, and click in Access Viewer

In Access Viewer’s window, click in Account, search for the correspondent Role the user is assigned, in my case sitecore\Author, select it and press OK

Now, expand Applications > Dialogs and look for Upload. Please note the Read permission is being denied and that’s the reason the user is getting the Access Denied error.

By clicking at the Read permission, you will notice, at your right, that Sitecore shows the properties of access rights for the item

The permission is being inherited from Everyone, and since this is a fresh Sitecore 9.1.0 installation, this is a default security setting.

Solving the issue

There are two different ways to address this issue: you can either remove change the inheritance by removing or allow the inheritance permission you want OR add the Read permission to the Upload Item

Removing the inheritance / Allow inheritance permission

In the Access Viewer, select the Upload item, click Assign

Select Everyone

And now, you can either Remove the Inheritance from Everyone by pressing the Remove button OR you can choose to change the Inheritance from Deny the item to Allow the item

And finally, press OK

Add Read permission

In the Access Viewer, select the Upload item, click Security Editor

Find the Upload item, and select it, then click in Allowed option in the Read permission and press the X to close

Check with the user

Voilá! It is working now

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

Photo by Kelli McClintock on Unsplash

Sitecore Identity Server and Azure AD security groups limit part 3

Part 1 – A 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.

Part 2 – User was member of 54 Security Groups, and after provide its credentials, it was receiving “You do not have access to the system. If you think this is wrong, please contact the system administrator” error. After further analysis, it seems the user belongs to nested groups that were exceeding the Azure AD integration limit.

Part 3 here we go… 🙂

Sitecore support believes the user belongs to nested groups exceeding the limit of 170 groups, and 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 get a confirmation about the Azure AD integration limit and have the analysis from Microsoft, and suggested by Sitecore as well, a ticket with Azure Support was opened.

Microsoft verified the user, and the total of groups totalized 350 because of the existence of nested group, as pointed by Sitecore support. In addition to that, they also confirmed the limitation with Azure AD.

In larger organizations the number of groups a user is a member of may exceed the limit that Azure Active Directory will add to a token. 150 groups for a SAML token, and 200 for a JWT. This can lead to unpredictable results. If your users have large numbers of group memberships, we recommend using the option to restrict the groups emitted in claims to the relevant groups for the application

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-fed-group-claims

And Microsoft also made a couple suggestions

  1. Azure AD Application Roles (same as suggested by Sitecore)
  2. Azure AD Application Registration for group attributes

SPOILER ALERT
Both suggestions work smoothly, however, the Azure AD Application Registration for group attributes has minimal disruption for the current flow as well as to the Active Directory configuration BUT it requires one of the following subscriptions in your Azure AD: Enterprise Mobility + Security E5 or Azure AD Premium P2.

Azure AD Application Roles

Assuming you’ve already configured Azure AD integration with Sitecore, let’s get things moving

  1. In Azure, visit the App Registration and find the one you are using in your Sitecore Identity Server / Sitecore environment, then click on its Manifest

2. Currently, that’s how your Manifest should look like, and you’ll need to modify the highlight parameters in Manifest: appRoles and groupMembershipClaims

The appRoles will replace the need of Azure AD Security Groups to claim for Sitecore Roles, instead you are going to set everything you need inside of this parameter. And, since the Application is no longer look for Azure AD Security Groups, groupMembershipClaims parameter will be set as null.

“The displayName cannot contain spaces”

“The id must be a Unique GUID”

“The value property can’t contain spaces”

“The value property of each app role definition should exactly match the strings that are used in the code in the application”

https://docs.microsoft.com/pt-br/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps

3. Now that you create the appRoles, and changed the Manifest, please go to Enterprise Applications

At your top left, click at the Portal Menu, then click Azure Active Directory

Once you open Azure AD, under Manage click at Enterprise Applications, then All Applications and select the application in which you want to assign users

4. Select the Users and Groups pane in the application’s left-hand navigation menu, then select the Add user

5. In the Add Assignment, click at Users and groups. A list of users will be shown along with a search field to locate and select the proper user

5. Once you are done selecting the user, you now need to choose Select Role in Add Assignment. All the roles declared earlier in the app manifest will show up along with a search field to locate and select the proper role

6. Finally, you have to click in the Assign button at Add Assignment

Tip
If by any chance you need to assign multiple roles per user, you must add the user twice, or three, four times, depending the number of roles you want to assign, and assign roles individually to each of duplicated users.

Alright, from Azure perspective you are done, so let’s move to Sitecore changes since adjustments are required in Sitecore.Plugin.IdentityProvider.AzureAd.xml

7. Navigate to your App Services, click on the Sitecore Identity App Service, and look for App Service Editor, then click Go

8. In the App Service Editor navigate to sitecore\Sitecore.Plugin.IdentityProvider.AzureAd\Config and click Sitecore.Plugin.IdentityProvider.AzureAd.xml

9. At your right, the file shows up and you have to modify a couple parameters

Let’s first show how the file is currently

<SourceClaims>
    <Claim1 type="groups" value="33ccc70e-c375-4dcc-a7be-48de24a40f1b" />
 </SourceClaims>
 <NewClaims>
    <Claim1 type="role" value="sitecore\Author" />
 </NewClaims>

And here is the modified version

<SourceClaims>
    <Claim1 type="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" value="SitecoreAuthor" />
</SourceClaims>
<NewClaims>
    <Claim1 type="role" value="sitecore\Author" />
</NewClaims>

Basically, the SourceClaims’ type parameter changed from “group” to http://schemas.microsoft.com/ws/2008/06/identity/claims/role&#8221;, and the SourceClaims’ value parameter should exactly match the strings that are used in the code in the application, so it changed from Azure AD Security Group GUID to the value defined at the App Registration Manifest.

Tip
Your file probably contain a lot of SourceClaims, and up to now, using Azure Security Group GUID, so instead of using a String in your value parameter App Registration Manifest, please consider to use the existent Azure AD Security Group GUID for each appRole you have to create, because to modify the file will require less effort.

10. Once you modified everything, restart your Sitecore Identity Server and check if you are able to properly login using Azure AD

Azure AD Application Registration for group attributes

Important note!
You must have one of the following specific subscription associated with your Azure AD: Enterprise Mobility + Security E5 or Azure AD Premium P2, otherwise you will find yourself stuck during the Add Assignment step

  1. In Azure, visit the App Registration and find the one you are using in your Sitecore Identity Server / Sitecore environment, then click on its Manifest

2. Currently, that’s how your Manifest should look like, and you’ll need to modify the highlight parameters in Manifest: groupMembershipClaims

At this time, Azure AD Security Groups are still needed but the difference is that instead of having the application to look for all of them, we want to only emit the groups that are explicity assigned to the application and the user is member of, so groupMembershipClaims parameter will be set as ApplicationGroup.

3. Now that modified the groupMembershipClaims, and changed the Manifest, please go to Enterprise Applications

At your top left, click at the Portal Menu, then click Azure Active Directory

Once you open Azure AD, under Manage click at Enterprise Applications, then All Applications and select the application in which you want to assign users

4. Select the Users and Groups pane in the application’s left-hand navigation menu, then select the Add user

5. In the Add Assignment, click at Users and groups. A list of users and groups will be shown along with a search field to locate and select the proper group

6. Finally, you have to click in the Assign button at Add Assignment

As you might have multiple Azure AD Security Groups and Enterprise Application consider using a Powershell Script to accomplish it

$azureAdGroups = Get-Content .\AzureADGroups.txt
$enterpriseApplication = Get-Content .\EnterpriseApplication.txt

foreach ($eaId in $enterpriseApplication)
{
	$getEnterpriseApplication = Get-AzureADServicePrincipal -Filter "DisplayName eq '$eaId'"
	foreach ($securityGroups in $azureAdGroups)
	{	
		$getGroups = Get-AzureADGroup -Filter "DisplayName eq '$securityGroups'"
		try {
				New-AzureADGroupAppRoleAssignment -ObjectId $getGroups.ObjectId -PrincipalId $getGroups.ObjectId -ResourceId $getEnterpriseApplication.ObjectId -Id ([Guid]::Empty) | out-null
				try {
					New-AzureADGroupAppRoleAssignment -ObjectId $getGroups.ObjectId -PrincipalId $getGroups.ObjectId -ResourceId $getEnterpriseApplication.ObjectId -Id ([Guid]::Empty) | out-null
				}
				catch {
					Write-Host -NoNewLine -Foreground Green $getGroups.DisplayName "successfully added to" $getEnterpriseApplication.DisplayName "`n"
				}
		}
		catch {
			Write-Host -NoNewLine -Foreground Yellow $getGroups.DisplayName "already exists in" $getEnterpriseApplication.DisplayName "`n"
		}
    }
}

As soon as you finish adding the Azure AD Security Groups to the Enterprise Application, try to access Sitecore using your Azure AD credentials, it should work right away… and we are done!

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

Photo by Paule Knete on Unsplash

Sitecore Identity Server and Azure AD security groups limit part 2

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.

YoudonothaveaccessSitecore

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 Session from problematic user
Fiddler id_token
JSON Web Token from problematic user session

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

JSON Web Token from working user session

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.

Working vs Problematic user

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

Troubleshooting guide to You do not have access to the system in Sitecore Identity Server

A few weeks ago, a user complaint that couldn’t sign-in to Sitecore via Azure AD and was getting the following error message

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

YoudonothaveaccessSitecore

This error message leads us to believe the user is missing something on its account. So, let’s check a few hings

  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 Sitecore

User’s Azure AD Security Groups

It is possible to verify the user’s membership through Azure Portal or via Powershell, using Azure AD module.

The following script is similar to the one used for troubleshooting the number of groups a user belong to, however, this time the idea is to list just the security groups that are used to claim a Sitecore role.

$FindUser = “username@domain.com”

(Get-AzureADUser -SearchString $FindUser | Get-AzureADUserMembership -All $true | ? {$_.ObjectType -ne “Role”} | % {Get-AzureADGroup -ObjectId $_.ObjectId | select DisplayName,ObjectType,MailEnabled,SecurityEnabled,ObjectId} | ? {$_.SecurityEnabled -eq $true} | where-object { $_.DisplayName -like ‘Sitecore*’ } | select DisplayName,ObjectID )

Get-AzureADUser_SecurityGroup

Every environment has its own particularities, therefore note that the script is going to show groups named as Sitecore because that’s the way I decided to distinct them from the other groups.

Also, note that the group also highlights the environment it is associated to, which means, you can verify if the environment the user wants to access is the DEV environment, otherwise, you already know wthat’s going on 🙂

However, if that’s not the case, let’s continue to the next step…

Sitecore.Plugin.IdentityProvider.AzureAd.xml

There are plenty options to access this file, and for the purpose of this verification, let’s use App Service Editor.

Well, assuming you have access to the Azure Portal, navigate your Sitecore Identity Server App Service

1. Navigate to your App Services, click on the Sitecore Identity App Service, and look for App Service Editor, then click Go

AppServiceEditor

2. In the App Service Editor magnifier icon, provide the Azure AD ID, the file to search and hit enter. Then, if the group exists in the file, click at the search result

AppServiceEditorNavigate

3. At your right, the file appears and highlighting your search

AppServiceEditorSitecorePluginIdentityProviderAzureAd

As you can see the Azure AD Security Group ID is there but what if it doesn’t? What would be the next step?

Well, in my case, the Azure AD Security Group shows the permission it intents to claim, and in that case it would be Author, so please back to step 2 and search for Author and consider to check the following

  • Is there any <NewClaims> values pointing to Sitecore\Author or Author roles?
  • Does the <SourceClaims> have the wrong Azure AD Security Group ID or none at all?

However, if that’s not the case, let’s continue to the next step…

Sitecore Role existence

Go to your Sitecore Content Management

1. Access the Sitecore Experience Platform, and on Access Management, click in Role Manager

SitecoreExperiencePlatformRoleManager

2. In the Search field, type Author and hit enter

SitecoreRoleManagerList

Once again, as you can see, my Sitecore has the sitecore\Author but what if it doesn’t? Well, in that case you have to create the role and test the access again.

Those steps are the initial ones to perform a troubleshoot when a user faces the “You do not have access to the system” error!

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

Photo by Tekton on Unsplash

Administrator checkbox overlaps Azure AD groups

Lately, I have been working a lot in Sitecore environments integrated with Azure AD and last week while troubleshooting a permission issue which I couldn’t reproduce using my user.

After struggling a bit, I decided to compare the problematic user with mine and move forward from there.

Azure AD membership

I want to check which groups I belong that are different from the problematic user, and vice-versa. In order to have a better overview I executed the following Powershell that highlights the differences between two users

Please note the Powershell script below shows ALL Azure AD groups and not just the ones used for Sitecore Claiming Roles, it is up to you to look into the output and make adjustments using the right groups

$referenceUser = “problematic.user@domain.com”

$differenceUser = “troubleshoot.user@domain.com”

Compare-Object -ReferenceObject (Get-AzureADUser -SearchString $referenceUser | Get-AzureADUserMembership -All $true | ? {$_.ObjectType -ne “Role”} | % {Get-AzureADGroup -ObjectId $_.ObjectId | select DisplayName | sort-object -property displayname}) -DifferenceObject (Get-AzureADUser -SearchString $differenceUser | Get-AzureADUserMembership -All $true | ? {$_.ObjectType -ne “Role”} | % {Get-AzureADGroup -ObjectId $_.ObjectId | select DisplayName | sort-object -property displayname}) -property DisplayName -passthru

PowershellAzureAD

The result of the comparison indicates whether a property value appeared only the reference object (<=) or only in the difference object (=>)

Having the following output, you will be able to determine whether you should be added / removed to match the reference User.

Then, I did adjustments and now I was part of the same Azure AD groups as the problematic user but still not able to reproduce the issue…

So, I’ve decided to double check Sitecore User Manager

Sitecore User Manager

When you first sign-in to a Sitecore that is integrated with Azure AD, a username is created into User Manager, and in a randomic set of letters and numbers as you can see

SitecoreUserManager_AzureAD

When I double-clicked at my user, I noticed that I had the Administrator checkbox marked

EditUser_SitecoreUserManager_AzureAD

I decided to uncheck the Administrator box, sign out from Sitecore CM and access it again.

Voilá! I was able to reproduce the issue, and figure out the Administrator box overlap the Azure AD claiming.

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

 

 

Sitecore Identity Server and Azure AD security groups limit

One of the most exciting – and easy – things to perform now with Sitecore Identity is the integration with Azure Active Directory (AD) which allows your users authenticate with the same credentials as for their corporate email.

Last September, I had the opportunity to set up an integration by following Derek Correia’s blog. So, I’d asssume you now know how the process of integrating Azure AD and Sitecore Identity Server works.

The authentication and authorization happens through Azure AD Security Group because we configured the App Registration Manifest to use SecurityGroup at groupMembershipClaims, and for the Sitecore Role claiming flow is based on the Security Group Object ID set at Sitecore.Plugin.IdentityProvider.AzureAd.xml file along with the role it should request.

Once you have configured the integration, you will notice users are now able to access Sitecore Content Management using their Azure AD credentials.

A couple weeks ago, I received a request saying a user was not able to sign-in using his Azure AD credentials and was seeing either HTTP ERROR 431 or a blank page with no further information.

Sitecore Identity Server and Azure AD security groups limit_HTTP_Erro431

I’ve asked the user to test

  1. On his cellphone but not connect to the company wireless
  2. In a coworker’s computer

Nothing worked, so I started to think it might be something with his profile on Azure AD. So, I’ve compared our accounts and the biggest difference was the number of Azure AD groups we belong to.

The user is member of 180 groups

Then, in order to validate this, I’ve added myself to the same groups and I was able to reproduce the error.

I decided to open a Sitecore ticket, explained the situation, shared logs and they come up with a possible solution but unfortunately didn’t work

Please consider applying the fixes suggested in the sample code below to your Identity Server and to all the loadbalancer/gateway/network infrastructure you put in place in front of Identity Server:
<system.web>
…..
<httpRuntime maxRequestLength=”2097152″ />
</system.web>

While Sitecore was investigating, I continued the investigation and tried to find the following answers

  • Is Sitecore looking just for the groups listed in the Sitecore.Plugin.IdentityProvider.AzureAd.xml file?
  • Does it matter if the group is a Security or a Distribution group?
  • What’s the maximum of groups I can be member of and sign-in with no issues?

Is Sitecore looking just for the groups listed in the Sitecore.Plugin.IdentityProvider.AzureAd.xml file?

Please feel free to correct if I am wrong here but on my understading, during the authetication process all the membership is conveyed from Azure AD to Sitecore, and validated at the Sitecore.Plugin.IdentityProvider.AzureAd.xml. In summary, it does not matter if you have a single or a 1000 claims, what will matter is how many groups you belong to.

Does it matter if the group is a Security or a Distribution group?

As mentioned earlier, as the App Registration Manifest is set to use SecurityGroup at groupMembershipClaims the only group type that is being consider are the Security Groups

What’s the maximum of groups I can be member of and sign-in with no issues?

The only way I could determine was doing by trial and error

  1. Check # of groups I am member
  2. Remove from groups individually
  3. Test again

There’s a way to check the Group Membership through Azure Portal, however, it gives you the total and not just the Security Groups, so I had to use Powershell

$FindUser = “username@domain.com”

(Get-AzureADUser -SearchString $FindUser | Get-AzureADUserMembership -All $true | ? {$_.ObjectType -ne “Role”} | % {Get-AzureADGroup -ObjectId $_.ObjectId | select DisplayName,ObjectType,MailEnabled,SecurityEnabled,ObjectId} | ? {$_.SecurityEnabled -eq $true}).count

Source: https://www.michev.info/Blog/Post/1655/quickly-list-all-groups-a-user-is-member-of-or-owner-of-in-office-365

Here is the expected output (please note the time may vary depending on the # of groups you are part of)

Powershell_Azure_AD_Membership

Note that the total of Security Groups is 175, and I am receiving either the HTTP Error 431 or blank page, so it’s time to test and find out the magic number!

1st attempt

Reduced to 150 Security Groups, and the error went away

2nd attempt

Increase 10 Security Groups, 160 in total and still NO ERRORS

3rd attempt

+10 Security Groups, and still NO ERRORS

So, fingers crossed I might have something now…

4th attempt

Now, +1 Security Group and BAM! THE ERROR IS BACK UP

170 is the magic number we were looking for

Why 170? What is causing this limitation?

Sitecore Support asked for a Fiddler Trace to perform further analysis and they back up saying the following

“I tested that the limit for the cookies is around 32KB and your request – while having 175 groups – was around 34KB”

In addition to that, Sitecore support said

To workaround this Azure limitation you could

  • Decrease the number of groups of your users are in
  • Move your Identity Provider from the App Service to a Windows Server VM where you have access to those registry keys
    • increase the value of MaxFieldLength and MaxRequestBytes in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\HTTP\Parameters registry

Once again, huge thanks to Sitecore Support

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

Publishing Service as Azure App Service and Connection Strings

Azure App Services provide plenty of features and options but you probably alredy know that.

One of the things that I like the most is the ability to configure things like Application Settings, Connection Strings at the App Service level and having these override the ones in Web.config or ConnectionStrings.config.

And, why would you want to remove settings from the original files and change the way it always worked? Well, first of all security reasons, as you would avoid storing either databases server addresses or connection credentials in your source, for example.

To configure Connection Strings, search for and select App Services, and then select your app. In the app’s left menu, select ConfigurationApplication Settings

ConnectionStrings_AppService

To add a new connection string, click New connection string and provide the information is being requested just like you would do at the ConnectionStrings.config

NewConnectionString

ConnectionStrings_Information

Name: master
Value: Encrypt=True;TrustServerCertificate=False;Data Source=sitecoresysadmin.database.windows.net,1433;Initial Catalog=sitecoresysadmin-master-db;User Id=sitecoresysadmin-master;Password=mysupersecret;
Type: SQLAzure

Needless to say that you need to add all Connection Strings at the App Service level if you want to start this feature from start to finish. Also, keep in mind by setting anything at the App Service level it will override the content at your ConnectionStrings.config file.

Well, introductions made, it’s time to talk about Publishing Service running as Azure App Service.

Martin Terpstra, a Valtech co-worker, and I were investigating a few things at Sitecore Publishing Service. And in order to apply some changes, he asked me to double check if the configurations at the App Service level for Publishing Service would also be overriden as it happens for any other Sitecore role.

The reason he asked it is because the way Sitecore present ConnectionStrings in Publishing Service is slighty different from the other roles

  1. Location is different ..\config\global
  2. File name is sc.connectionstrings.xml
  3. Structure differs from regular ConnectionStrings

<Settings>
<Sitecore>
<Publishing>
<ConnectionStrings>

PublishingService_ConnectionStrings

I’ve read the Publishing Service Installation Guide but couldn’t find anything related to Configuration files at App Service level versus file system, so I raised a ticket to Sitecore and here is their response

My understanding is that using the “Settings > Configuration” page on an app service you can modify override the “Application Settings” and “Connection Strings”, corresponding to the <appSettings> and <connectionStrings> nodes in the web.config.
Since, as you identified, the Publishing Service configuration does not follow the same configuration node structure you are not able to specify the connectionstrings to overwrite (because the publishing service web.config file does not contain a <connectionStrings> node).

That being said, Configuration > Application Settings can be used to override ConnectionStrings.config in all Sitecore Roles but Publishing Services.

I huge thanks to Sitecore Support, and being more especifically for Tyler Jass to assist with this question.

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

 

Sitecore announces 2020 MVPs

BAM! Another year starts, and as usual Sitecore announces their MVPs for 2020. And for the 4th time consecutive (2017, 2018, 2019 & 2020) I’ve been awarded as a Sitecore MVP. Let’s make another great year in the community and leading people through the Sitecore world!

celebration_mvp

I am dignified, thrilled and eager to keep the MVP title and sharing valuable content around Sitecore! Believe me, the responsibility is gigantic!

And I know I couldn’t reach my goals alone, so….

Raquel, for all support, understanding and love during the journey (AGAIN)! I LOVE YOU RAQUEL

Sitecore, Sitecore MVPs, Sitecore community and my readers, to believe in my potential and how helpful I am with the community.

Last but not least, congrats to all Sitecore 2020 MVPs!

3PllSbm

As usual, thanks for reading, and I’ll see you on my next post!

SSL/TLS error while rebuilding xDB index

During a troubleshoot session with Sitecore, I was asked to rebuild the xDB index and I thought “I should connect to Sitecore and be able to rebuild it, easy peasy”.

woah-bro-not-so-fast

Sitecore support provided me with the link, and there are some steps there in how to Rebuild the core

You cannot trigger an index rebuild from a user interface or via the xConnect Client API. You must explicitly trigger the rebuild process in one of the following ways:

To invoke the rebuild request command:

  1. Go to the server where the xConnect Search Indexer is running and open command line.
  2. Navigate to the folder that contains the service – for example: C:\inetpub\wwwroot\<xConnect Collection Search service root>\App_Data\jobs\continuous\IndexWorker.
  3. Run XConnectSearchIndexer -rr (alternatively XConnectSearchIndexer -requestrebuild). The command registers a small document in the live core signaling that the rebuild should be started. The xConnect Search Indexer will notice the document and start the rebuild process.

As my environment is running on Azure, here is how I complete the above steps

1. Navigate to App Services, and clicked on xConnect Collection Search App

xConnectSearchAppService

2. A new blade shows up, and I typed at the search field Advanced tools, clicked on it and then click Go

 

xConnectSearchAdvancedTools

3. Advanced Tools (aka Kudu) opens in a new tab, then click Debug console, and Powershell

xConnectSearchKudu

AzureKudu

4. Now, you can navigate throught the files & folders structures, so go to the following path site\wwwroot\App_data\jobs\continuous\IndexWorker

XConnectSearch_RebuildIndexFolder

5. In order to rebuild your index, type the following command and hit enter

XConnectSearchIndexer.exe -rr

xConnectSearchIndexer

THE ERROR

An error occurred while sending the request. —> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

SSLTLSERROR.PNG

As this rebuild process calls the SOLR, and for my surprise SOLR opened and without SSL errors, valid certificate at the address bar

SOLRSSL.png

Now, my challenge was to figure out where XConnectSearchIndexer is getting an invalid connection.

While navigating at the XConnect Collection Search via KUDU, I noticed a folder named App_Config at the App_Data\jobs\continuous\IndexWorker and decided to check what’s inside of it, and for my surprise there is a ConnectionStrings.config

ConnectionStringsXDBRebuild.png

Let’s look inside of it

xconnectsearch_connectionstrings.png

As you can see, the entry solrCore is using HTTPS but it calls the domain eastus.cloudapp.azure.com which was the initial address Solr had in my configuration, and as I don’t have the proper certificate for it, when I try to access it from the browser

SolrInvalidSSL

Fair enough, Solr is throwing an SSL error, so let’s change the ConnectionStrings.config at App_Data\jobs\continuous\IndexWorker to the working SOLR URL

FixedSolrSSL_XConnectSearch

Now, let’s execute the XConnectSearchIndexer.exe -rr again

XConnectRebuild_Done

Rebuild is complete!

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

 

Credits

Photo by Sarah Kilian on Unsplash

[Solved] Issue with Sitecore Identity Server and Azure AD

I had to set up an integration between Azure Active Directory and Sitecore 9.1, and I was able to accomplish it by following the steps on Derek Correia’s blog. Then, I had to map claims to User Profiles as well.

Once I had everything in place, I added users to the groups accordingly to the roles mapped in Sitecore and it was working fine.

A few days ago, one of the users complained about not being able to access Sitecore using its Azure AD account and, fair enough, the account was not part of the group. So, I’ve added the account to the group, and asked the user to check it again, and I received the following response

“I’m still seeing the same error as before You do not have access to the system. If you think this is wrong, please contact the system administrator.

Youdonothaveaccesstothesystem

Weird, right? Sitecore should check the group, and verify that now the user is part a member, then allow its access but for some reason it was not happening.

While troubleshooting, I observed the user was added to the Users in Sitecore

SitecoreUserCreated

And performed two additional steps

  • Removed the user created after the first sign-in, and asked the user to Login again but no luck (please note that once again, the user was automatically added in Sitecore)
  • Added the user to the Sitecore Authors group, and asked the user to sign-in again, and odd enoug the user was able to access Sitecore

Unfortunately, this didn’t address the problem because the main idea is to have the permissions mapped to Azure AD Groups and not at individuals, so I decided to open a Sitecore ticket.

Based on the information I provided, the Sitecore Support team then asked to perform some steps

  1. Delete Vinicius from the User Manager
  2. Make sure he is part of the Azure AD Group that allows access to Sitecore
  3. Restart Sitecore CMS and Sitecore Identity Server
  4. Have Vinicius try to log in again and let us know the results

After following the steps, Vinicius was able to log in without issues but I decided to perform additional steps

  1. Delete Vinicius from the User Manager
  2. Make sure he is NOT part of the Azure AD Group
  3. Have Vinicius try to log in again

And the user still have access to Sitecore, so I restarted Sitecore CMS and Sitecore Identity Server, and as expected Vinicius couldn’t sign-in anymore.

The workaround is keep restarting the Sitecore Identity Server every time you add or remove users from the Azure AD Group, however, isn’t acceptable for production environments.

After collecting this information, Sitecore Support team back with a hotfix

For your reference if you face the same issue Ticket #322237

Accordingly to Sitecore support response 

Be aware that the hotfix was built specifically for Sitecore 9.1.0, and you should not install it on other Sitecore versions or in combination with other hotfixes, unless explicitly instructed by Sitecore Support.
Please follow the readme instructions inside the zip file archive carefully to install the hotfix (note that the fix is being applied to the Sitecore IdentityServer, and not your Sitecore CMS site).

You should replace all the files in the original locations at your Sitecore Identity Server, please find the content of this hotfix

  • Website root folder\
    • Sitecore.Plugin.IdentityServer.dll
    • Sitecore.Plugin.IdentityServer.xml
  • Website root\sitecore\Sitecore.Plugin.IdentityServer\Config
    • identityServer.xml
  • Website root\sitecore\Sitecore.Plugin.IdentityServer\
    • Sitecore.Plugin.manifest

Then follow the steps

  1. Stop Sitecore Identity Server
  2. Copy the files to Sitecore Identity Server and overwrite existing files
  3. Start Sitecore Identity Server

Once you performed the steps above, I executed the following validation

  1. Delete Vinicius from the User Manager
  2. Make sure he is part of the Azure AD Group that allows access to Sitecore
  3. Have Vinicius try to log in again

IT WORKED!!!

No restart required after applying Sitecore hotfix

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

 

Credits

Photo by Louis Hansel on Unsplash