Cross-forest Kerberos custom SPN routing

One day I was working on a problem of setting up a kerberized service with custom SPN across multiple trusted AD forests. Cross-forest Kerberos is not unusual but I had never worked with custom/disjoint SPNs/domains.

User forest containing domainA.com would need to authenticate to SPN myservice.com located at resource forest containing domain forestB.com.

By default you get suffix routing for default UPN/domain name/Kerberos realm name. As client nor DC will search GC in other forests for SPNs, i scratched my head a bit and went back to documentation that I hadn’d probably read for over a decade.

Thank god Microsoft hasn’t yet deleted all Windows 2003 era stuff. While initially reading about name suffix routing i was a bit puzzled as it was talking about SPNs and UPNs together yet I could not remember nor find anything specific to SPNs. Cross-forest access pointed me to Trust Domain Objects (TDO). This is a bit of dead end as the important msDS-TrustForestTrustInfo attribute is a blob and I didn’t really want to start parsing it.

However as again UPN and SPN suffixed were being discussed together, I added custom UPN suffix myservice.com to forestB.com. After enabling routing – lo and behold – it worked for SPNs as well. This clicked some memories where I had browsed some old AD environments and seen some UPN suffixes that had not made any sense. Probably the same case.

This didn’t leave me satisfied as there definitely there had to be a more elegant solution. UPNs show up in user management and this may not be something that you want.

After digging through schema and some other searches I came upon ms-DS-SPN-Suffixes attribute that seemed interesting and actually seemed to do the job when manually edited. Yet more searches led me (back) to Set-ADForest CmdLet that has parameter to modify SPN suffixes. Huh, never noticed that.

Now looking back and knowing what to look for, it has been well described in great detail for 10 years. The linked blog post has some other great details or options.

TL;DR: For cross-forest Kerberos with custom SPN suffixes you need to use Set-ADForest to set routing hints for trusts.

Azure MFA plugin for NPS is all or nothing

Some time ago, a customer wanted to use Azure MFA for some NPS authenication requests (network policies). It turns out that it affects all authentication attempts. Imagine a (quite real-world) scenario where NPS or NPS farm should service:

  • VPN appliance authentication backend, that should have MFA
  • 802.1x with EAP-TLS

Well you can’t pick and choose. All requests get MFA treatment though I’d say you don’t need (or want) it for internal 802.1X. I haven’t found any information or documentation to say otherwise.

So if you need some network policies to have MFA and other not to have then you need to look to other solutions or just deploy a separate NPS server or farm for MFA.