ADFS - Combining Claims from Provider Trusts and AD

Question

As part of implementing a SharePoint 2013 installation, I have configured SSO with ADFS on Windows Server 2012R2.

There are two separate AD forests, one as part of the Hosted SharePoint/ADFS and one onsite corporate forest.

Currently, I have the corporate AD set up as a Claims Provider Trust in the SharePoint ADFS. I am able to successfully pass through the email attribute from the corporate AD to SharePoint.

What I want to achieve is some form of claim injection from the Hosted AD Forest as part of logging on with a Corporate AD account.
Specifically, users will be members of security groups to determine SharePoint licencing. For security reasons I do not want to get this claim information from the Corporate AD as this means users will be able to change their licencing status.

So, all users will actually have an AD account in both forests. Single Sign On provided by entering their Corporate credentials as part of the sign in process.

Is there some way that I can tell my hosted ADFS to look for a user in it's own AD forest which matches the incoming Email Address Claim from the Corporate ADFS, and then inject the Role claim from the hosted forest with said email claim?

Please see the picture below for what I'm trying to achieve (Sorry for the quick MS Paint drawing!):

How do I achieve steps 4 & 5?

Current Claim Rules
On the Hosted ADFS, Acceptance Transform Rules for the Corporate Claim Provider Trust:

1. Pass Through incoming E-mail Address claim, pass through all values

On the Hosted ADFS, Issuance Transform Rules for the SharePoint Relying Party:

1. Send LDAP Attributes as Claims (UPN -> UPN, Token Groups -> Role, Email-Addresses -> Email)
2. Pass Through incoming E-mail Address claim, pass through all values

Answer 1

Yes, that should work. If you control the claim rules on the hosted ADFS and if you have some key from the Corp ADFS in a claim, then you can do the regular AD search claim rule with that key.

Answer 2

I ended up getting this working, and it actually wasn't as bad as I thought it would be - I just needed to code a custom Issuance Transform Rule on my SharePoint Relying Party.

This is what I came up with:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"]
 => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn", "http://schemas.microsoft.com/ws/2008/06/identity/claims/role"), query = "userPrincipalName={0};userPrincipalName,tokenGroups;MYDOMAIN\accountthatdoesnotexist", param = c.Value);

Essentially, this will see that if an email address claim is defined in the incoming claim set it will query AD with the email address and find a userPrincipalName which matches the email address. Then it simply returns the upn and tokenGroups attributes as the upn and role claims which I need.

I've inserted this as rule number 1 in my Relying Party. Because some users will not have a third party ADFS to auth against I believe this should give it the most compatibility.

After inspecting the default claims code when using the Send AD Attributes template, it will only actually run if the rule receives a windowsaccountname claim (this claim is only ever passed to the Relying Party if a user signs in without a third party ADFS).

So I have a situation here where if a user is signing in without a third party ADFS, it will ignore my custom rule since the Active Directory attribute store does not send an email address claim. Additionally, if a user is signing in WITH a third party ADFS, it will ignore the Send LDAP Attributes rule since there is no windowsaccountname claim set!

Lastly, on my first attempt I initially thought I was stuck since I'm only using UPNs and not traditional domain\username accounts in the hosted AD because I was getting an error message in the event logs:

Microsoft.IdentityServer.ClaimsPolicy.Engine.AttributeStore.AttributeStoreQueryFormatException: 
POLICY3826: 
User name 'myuser@mycorp.com' in LDAP query';userPrincipalName,tokenGroups;myuser@mycorp.com' 
is not in the required 'domain\user' format.

However, good news to me is that the username portion of the domain\username is actually ignored! https://technet.microsoft.com/en-us/library/adfs2-help-attribute-stores%28WS.10%29.aspx

QUERY = <QUERY_FILTER>;<ATTRIBUTES>;<DOMAIN_NAME>\<USERNAME>

This part of the query identifies and locates the domain controller to connect to for execution of the LDAP query

Also note that USERNAME is ignored, even for Active Directory attribute stores.

So with a slight tweak to ensure the LDAP filter matches on userPrincipalName rather than the default (if query filter is left blank) samAccountName, this is now working perfectly!