In the previous F5 posts we did, we always used a single forest, single domain setup. Obviously, this is not always the case, certainly when cross-forest migrations are being performed. Even in these situations we could leverage F5 and AAD’s federation capabilities to provide an SSO experience.
- 2 Forests with a forest trust (two-way) ForestWide Authentication
- 1 Forest with multiple domains in the forest
- Azure AD Connect configured and synchronizing both domains
- Manual setup of AAD+F5 in SSO (Guided Configuration won’t allow changes outside of the wizard)
In my example I used a single UPN Suffix in combination with PassThrough Authentication (PTH) enabled, but password synchronization or 2 ADFS implementations should also work.
First of all, we need to make sure that we send the forest DNS name (FQDN) in the claims to the F5 applications.
In Azure AD, go to Enterprise Applications, select the F5 published application and select Single Sign-On. Under option 2 User Attributes & Claims, select edit, by clicking the pen
In the new windows, click + Add new claim
For the name, type dnsdomainname and select user.dnsdomainname from the dropdown list
Click save and return to the F5 Administrative page.
On the F5 device, go to Access, Single Sign-on, Kerberos. You should see an entry for every application created. Select the configuration desired and for the realm source, type session.saml.last.attr.name.dnsdomainname and click Update.
You should now be able to login with a user from the trusted domain and still get the website with Kerberos. You can also view if the claim was transmitted successfully when viewing the session variables: