In my previous post, I discussed how to setup Kerberos constrained delegation and a limitation of using that method. This post will discuss how we can used resource-based Kerberos constrained delegation to do the same thing.
Resource-based KCD was introduced in Windows Server 2012, and is defined as…
Windows Server 2012 and later gives service administrators the ability to configure constrained delegation for their service. This model is known as resource-based KCD. With this approach, the back-end service administrator can allow or deny specific front-end services from using KCD.
Kerberos Constrained Delegation Overview | Microsoft Docs
Our environment will be setup with the following configuration.
- User
- Workstation = SOLO
- Login = GOVLAB\patrick-admin
- PowerBI Report Server (on-premise)
- Hostname = CORELLIA
- URL = https://powerbi.govlab.corp/reports/
- gMSA Account = GOVLAB\CORELLIABI1$
- Data Source
- SQL Server = DEATHSTAR\SQL2019
- Database = DBA
- gMSA Account = GOVLAB\DEATHSTAREN5$
The data source credential is configured to login “As the user viewing the report”.
Resource-based KCD still requires Service Principal Names (SPNs) to be setup for each account. This is accomplished by using the SETSPN command with the “-S”. This option will only create the SPN if a duplicate does not already exist.
SETSPN -S MSSQLSvc/DEATHSTAR.govlab.corp:SQL2019 GOVLAB\DEATHSTAREN5$
SETSPN -S MSSQLSvc/DEATHSTAR.govlab.corp:11004 GOVLAB\DEATHSTAREN5$
SETSPN -S HTTP/CORELLIA.govlab.corp GOVLAB\CORELLIABI1$
You can verify them using SETSPN and the “-L” option. This option just lists any current SPNs.
SETSPN -L GOVLAB\DEATHSTAREN5$
SETSPN -L GOVLAB\CORELLIABI1$
Next, we need to configure delegation on the SQL Server service account, which will can only be done using one of the following PowerShell commands.
- Set-ADUser – for user accounts
- Set-ADComputer – for computer accounts
- Set-ADServiceAccount – for service accounts
Since we’re configuring a gMSA, we will need to use Get-ADServiceAccount, and then use Get-ADServiceAccount to verify the settings.
Set-ADServiceAccount -Identity DEATHSTAREN5$ -PrincipalsAllowedToDelegateToAccount $CORELLIABI1$
Get-ADServiceAccount -Identity DEATHSTAREN5$ -Properties PrincipalsAllowedToDelegateToAccount
We need to stop and restart both services so they can pick up the SPNs and the delegation options, and then we can test the data source in the report.
And finally test the report.
The PrincipalsAllowedToDelegateToAccount property is an array that can hold multiple values. This is useful if need to specify more than one account.
Set-ADServiceAccount -Identity DEATHSTAREN5$ -PrincipalsAllowedToDelegateToAccount $CORELLIABI1$, $CORELLIAEN1$, $CORELLIAAG1$
Get-ADServiceAccount -Identity DEATHSTAREN5$ -Properties PrincipalsAllowedToDelegateToAccount
Finally, you can also have the option to specify a domain group.
Set-ADServiceAccount -Identity DEATHSTAREN5$ -PrincipalsAllowedToDelegateToAccount gDEATHSTAR_KCD
Get-ADServiceAccount -Identity DEATHSTAREN5$ -Properties PrincipalsAllowedToDelegateToAccount
This makes your configuration even easier since you just add the one group name and then add/remove members from that domain group.
Turning off resource-based KCD only requires you to set PrincipalsAllowedToDelegateToAccount to $null.
Set-ADServiceAccount -Identity DEATHSTAREN5$ -PrincipalsAllowedToDelegateToAccount $null
In my opinion, using resource-based KCD is easier than having to specify individual SPNs and it can be controlled by the DBAs because it only involved changes to the SQL Server service account.
Keep in mind there are other prerequisites to make Kerberos delegation work within Activity Directory, including ones that are specific to your environment. I didn’t cover those here, but I did cover a few in my previous post.
Additional reference:
https://docs.microsoft.com/en-us/azure/active-directory-domain-services/deploy-kcd
