How to Configure Authentication Extender in a Resource Forest Topology?

Introduction

To avoid the use of domain credentials for Skype for Business and use SphereShield for SfB credentials instead, deployment must include KCD capabilities.
One approach is to perform the delegation from the Authentication Extender to the Front End directly. This requires domain functional level of 2008+ as well as other system requirements.

Note that this document refers to Skype for Business, but also applies to Lync 2013.

Active Directory requirements

User forest

At least one Windows 2012+ domain controller.
Any Windows 2008 domain controllers must have the hotfix in KB 2665790 applied.
No Windows 2003 domain controllers are permitted in the domain.
Domain functional level: 2008+.

Resource forest

At least one Windows 2012+ domain controller.
Any Windows 2008 domain controllers must have the hotfix in KB 2665790 applied.
No Windows 2003 domain controllers are permitted in domain.
Domain functional level: 2008+.

Server requirements

DMZ Bastion reverse proxy server(s). Windows 2012+.

User forest

If two-way trust is configured, then there is no need to create another server in the User forest.

Resource forest

SfB Front End and Director (if applicable) servers should run on Windows 2012+
Internal Bastion reverse proxy (authentication extender) server(s). Windows 2012+.
Access Portal registration site server(s). Windows 2012+.
Access Portal database – Windows 2008+ with Full SQL Server 2012+.

HA is supported. Non HA diagram is shown for simplicity.

Explanation

First, this is possible only on Windows 2012 and above.

This is due to a new feature: msDS-AllowedToActOnBehalfOfOtherIdentity which is added to a resource account and determines which accounts are allowed to delegate to it. It lists the account’s SID, which can even be the SIDs of accounts outside your forest, as long as SID's are unique.

Previously Windows only supported the attribute msDS-AllowedToDelegateTo on an account, which told it what SPNs this account is permitted to delegate to (this is what the GUI was setting). Since there is no access to that attribute in an account which resides in another forest (even if there is a trust relationship), KCD was not possible across forest boundaries.

How to make it work?

The basic setup you need to have:

A Resource Forest and one or more User Forests
There must be a one-way forest trust (external and realm trusts are NOT supported) between the resource forest and each of the user forests.
The DNS server of each forest must be accessible to the other forests (i.e. use zone transfers in the Windows DNS server, DON’T use /etc/hosts hacks, it probably won’t work properly).
Each domain inside the forests in which you would either request or receive (and check) a KCD ticket, must have at least one DC with Windows 2012 or higher installed. Other DCs in
the forest (and even in the same domain) may run Windows 2008 or higher, but they might need this hotfix. It’s recommended to have Windows 2012 on every server.
You’ll definitely need to have at least one Windows 2012 server in each of the forests, and probably more if they have multiple domains.
Both the delegating machine (i.e. the machine running Bastion) and the receiving machine should run Windows 2012 or higher.

Once everything is set up, you may want to make sure simple (non-delegated) cross-forest Kerberos works by logging in from a machine in the user forest with an account from the user forest to an IIS server in the resource forest and capturing the connection with Fiddler. Look at the Authentication inspector in Fiddler and make sure the Negotiate header sent is Kerberos and not NTLM. If it’s NTLM, it could also be because the domain name in the URL doesn’t match the server's SPN (but with KCD we don’t need to care about that).
Now, let’s say you want to set up delegation from KCDBastion in the forest users.agat.com to MyIIS in the forest res.agat.com.

Now, you should go to a machine on res.agat.com and fire up PowerShell:

Take care to use the -Server argument in the first line to get an account object from an entirely different forest. This server should be the DC for the domain where the account is (a GC server in another domain in the forest might also work).

The second line is where you set the:

msDS-AllowedToActOnBehalfOfOtherIdentity/PrincipalsAllowedToDelegateToAccount attribute. There is no GUI for that yet, so it has to be done from PowerShell, though creating a simple GUI in C# would probably be easy. Since you’re setting an attribute here, you’re going to override any
previous values (or at least that’s what I think), so if there were already some accounts configured as allowed to delegate to that resource, they’ll get overwritten! To avoid that, you should probably get the attribute value (with Get-ADComputer of course!) first and then add the new account on top of the existing one (you can separate multiple accounts with a comma). After setting up all these - delegation should work. In some cases it may require closing the browser or rebooting the servers, but should indeed work properly afterward.

When there is two-way trust enabled between the forests, the Authentication Extender (AE) can be in either domain for user forest users. However, when there is only one way trust it appears that the AE must be in the user forest for user forest users.

To check the assigned properties of the FE account:
Get-ADComputer lync -Properties *
There SPN specified in the KCD.xml file must exist. This may have been created by the delegation GUI, if delegation has been configured there. If not, configure it manually using ADSI Edit.

Restarts of all servers involved (2xDC + AE + FE) may be required after configurations
When the AE is in the UF, the Windows Event Log may show successful authentications even when the FE IIS doesn't accept the authentication header. This hasn't been observed in the RF.

Possible Errors

The SAM database on the Windows Server does not have a computer account for this workstation trust relationship - Seen on AE in resource forest when there's only a one way trust. Fixed with 2 way trust or moving AE to User Forest.
There are currently no logon servers available to service the logon request. - on resource forest when AE is not in the "allowed to delegate to" list or user is in resource forest when there's only a 1 way trust.
Are we authorized to delegate this SPN? - in user forest with 1 way trust without HTTP/FEFQDN SPN configured for FE.

Multiple Auth Extenders
$bastionInRes = Get-ADComputer -Identity OurRFAESServername
$bastionInUser = Get-ADComputer -Identity OurNewUserForestAESServername -Server UserForestDCFQDN
Set-ADComputer -Identity SFB-FE -PrincipalsAllowedToDelegateToAccount $bastionInRes, $bastionInUser

Testing

For testing KCD filter:
Ensure you use a UPN for testing and real use. Using a domain\user format will cause the KCD to ignore the domain and it may use an unintended domain.
Add to KCD xml to test a specific user:

To test KCD with Exchange go to the EWS url: /autodiscover without KCD you will see an authentication prompt. With KCD it should go straight through to the page. Note the name of the user.
Another option is /ews/exchange.asmx. This will give a service page after successful auth. Just be careful the it's not failing and then logging on as the signed in user.

Testing with Skype for Business

Go to https://localhost:4431/WebTicket/WebTicketService.svc

Ensure Negotiate is configured for the External Site Webticket service.

If authentication fails you'll probably get a 500 fail from the filter and a blank page will be shown.
If it succeeds you'll get a service error page indicating that it's an error with the service.

IIS logs can show if the user successfully connected. Note that Chrome may be required to see the username, as it seems to appear with the favicon.

Other references

Creating Shadow Users in Resource Forest to mirror Users in User Forest

https://ucsorted.com/2015/08/31/understanding-user-mapping-in-a-skype-for-business-resource-forest/

https://technet.microsoft.com/en-us/library/mt603995.aspx