As you probably know, the requirement for Setting Up Nomad synchronization in a distributed environment using Constrained Kerberos Delegation and is very difficult to implement and even more difficult to actually get working. I thought it was already difficult enough until I recently came to learn (the hard way) that when using Constrained Kerberos Delegation, the service accounts and the computer accounts hosting the applications need to be in the same domain.
In desperate need of an alternative solution, I came across a relatively new and sparsely-documented solution called Resource-Based Kerberos Constrained Delegation. Not only does this new delegation approach overcome the cross-domain limitation of the older, traditional Constrained delegation, it’s much, much easier to set up. I thought I’d share my findings in hopes that we can all spend less time configuring Kerberos Delegation and more time doing…well…whatever you like.
What is it?
Resource-Based Kerberos Constrained Delegation was first introduced with Server 2012. It enables delegation to be configured by modification of the account of the resource that the impersonating account will access (e.g., the ConfigMgr SQL Service account) instead of configuring the account doing the impersonation (e.g., the ActiveEfficiency SQL Server Service Account). More importantly, Resource-Based Constrained Delegation has the ability to function across domain (and even forest) boundaries.
Resource-Based Kerberos Constrained Delegation requires:
- Both the ConfigMgr database and ActiveEfficiency database servers are running Server 2012.
- There must be at least one Server 2012 domain controller in each of the referenced domains.
How do I set it up?
Picture the following environment:
That’s it. You’re done!
Since the feedback, you’ll receive from the above command (which is nothing) is rather underwhelming, I’ll point out that there are no SPN’s to create, no concern about duplicate SPN’s, no need to delegate to the correct SPN. Also, we’ve only changed the ConfigMgr SQL service account object in AD and not the ActiveEfficiency database server’s SQL service account. This means that if your ActiveEfficiency database is running on a shared SQL server, you won’t need to explain to over and over to the DBA why want/need to modify his/her shared SQL Service account.
If you think this sounds too easy, feel free to check the configuration changes with the following commands. The preceding command should set the PrincipalAllowedToDelegateToAccount to the DN of ActiveEfficiency SQL Server service account and the msDS-AllowedToActOnBehalfOfOtherIdentity property of the ConfigMgr SQL Service account should be set to the SID of ActiveEfficiency SQL server’s service account as in the example below. (Again, replace Get-ADUser with Get-ADComputer as appropriate to your configuration.)
Before you test a the Nomad Sync, either restart the ActiveEfficiency Database Server (the Server, not just the service) or wait 15 minutes for the KDC cache to clear. Its best to the stop the ActiveEfficiency Service while you’re waiting (or before you start), because if a sync kicks off while you are waiting, it may reset the TTL on the relevant items in the KDC cache.
