Updated 4/2/2018 – This blog post was quite old (over 4 years) and when I read it through I noticed that I definitely needed to update this one.
You can establish federation between two partner organization when both of the organizations deploy at least one ADFS federation server. In my demo environment I have two separate environments, feta.fi and monae.info.
The party holding account can be referred as Account STS (STS-A / monae.info) and the party serving actual application is referred as resource STS (STS-R / feta.fi). Example picture from such environment below
All pictures are from test my test lab and both domains are located at same VLAN. Referring to Microsoft in real world “No communication occurs over the network between the account Federation Service and the resource Federation Service”.
Pre-requirements for creating federation trusts are:
1. Two forest (feta.fi & monae.info in my case)
2. At least 1 AD FS Server in both forests or other 3th party Idp provider
3. Claims aware application. I’m not a coder and find some application from Web which was used in lab. Link to application is here. Link forwards you to PFE blog where is guidance how to build test lab with claims aware application. There is a script which build application and IIS settings automatically for you, quite nice:)
First step is to create Relaying Party trust between ADFS and application. In STS-A (feta.fi) select
- Relying party trust from Account STS (STS-A)
- Add Relaying Party Trust
Selection of Claims aware or non-claims aware application
Import metadata from url or manually from file. My test application is using self-signed certificate and I’m importing metadata from a file to ADFS.
Specify name for application
Choose Access Control Policy – this section is slightly different than in W2012R2. As seen I have created custom ACP’s for ADFS but in this case I’m using default “permit everyone” and not doing authorization check at ADFS level.
Configure advanced settings if needed and press finish, claims rule wizard opens but it can be ignored (defaults are fine with this app).
Next step is to “add Claims Provider Trust to Resource STS (STS-R / feta.fi) so that it trusts to Account STS (STS-A / monae.info)
Add claim provider trust
Import metadata and specify name for Claims Provider Trust (IDP)
If certificate chain is not trusted metadata import via URL fails. Add root ca public certification to ADFS “trusted root certification authorities” console to avoid error
Additional settings – not needed in this scenario
Both IDP’s are in place, home realm and fs.monae.info
Test SSO from Account and Resource domains
Now I have configured Relaying Party trusts between feta.fi ADFS and application. Claims provider trust is also in place make application work from account domain (monae.info).
From account (STS-A / monae.info) domain
I used Windows 8 for testing and application is asking forms based authentication because I’m coming from Extranet based on sts.feta.fi AD FS authentication settings.
From resource domain (STS-R / feta) to application
Naturally inside home realm SSO is working as expected and my test user is accessing application directly without any logon prompts when navigating to https://claimapp.feta.fi. Because application has self-signed certificate warning will be prompted if it’s not added to trusted store. Don’t forget to configure your IE to trust site either local intranet zone.
I wrote this blog because it was extremely difficult to collect necessary information to create own test lab with claims aware application. Hope this helps!
Sidenote, if you are facing authentication problems like I did check your webconfig file configuration
In first login I faced authentication error about missing thumbprint and name which has to be misconfiguration in webconfig file in application itself.
I added token-signing certificate thumbprint and STS name to webconfig file where they were missing from some reason
And authentication was successful
Thanks, nice write up! yet to validate in my test lab.
Let me know if you have any difficulties when setting up federation trust
Thanks, what needs to be changed to allow STS-A users to authenticate againts the ADFS proxy of STS-R ?
Usually ADFS proxy or WAP servers is at front of ADFS servers but I didn’t use them because main purpose was to test claim based autH between two ADFS instances. Wen we are talking basic ADFS configuration you don’t need to change anything, just install proxy/WAP to ADFS instance and then you can have more configuration layers at WAP for example for authentication. Authentication landing page is naturally at proxy/WAP after installation and all necessary configurations. More detailed information how to work with WAP below:
hello Matthias, can you please provide more info how we can make the connection unique to a customer if STS-A want to login the get the url ……… from STS-R
and if STS-B want to login the get the url …….. from STS-R
Can you provide more information what you are trying to achieve? You mentioned STS-A, STS-B and STS-R, I assume that in your scenario there are three (3) different companies and all of ADDS behind ADFS instances contains user accounts? Where the application is located in your scenario?
Hello Mathias I created as You said but I’m not getting role name claims?
Can you clarify what kind of situation or errors you are having? From where you don’t see the claims?
I configured this but somehow I couldnt pass extra claims like SamAccountName as NameID, userprincipalname as Email and SamAccountName as PPID from STS (Account partner) to STS (Resource partner) and then finally to application setup as relying party in STS (Resource partner).
Could you please provide more information in order to setup claim rules in both STS in order to pass NameID, Email, PPID and Group information.
I will test this again and get back to you. To make sure you would like to send sAMAccountName and userPrincipalName attributes to resource partner? Are there any additional claims you have tested?
Thanks Sami for quick response. Yes I tried with User group information as well. But, nothing is getting passed to the claims-aware application.
I got this fixed by writing custom claims rules!
You were quicker than me:) Unfortunately I have been extremely busy with customer project and haven’t had time to test this. Glad that you got it working.
Would this approach also allow me to use identifies from source AD to login to a server that is joined on the destination AD?
WIth federated identities, you can login to claims-aware application which is in another domain (or anywhere) as long as the client is able to reach your own IDP (ADFS in this case). Login to another server which is located in another forest via RDP is not doable in this scenario. A different case is if you use RDS to achieve your scenario…