Private Personal Identifier with 2 nodes ADFS : how generate same PPID from both servers ?

DS 106

I try to generate a PPID claim on ADFS windows 2019 with the rule (from https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/when-to-use-a-custom-claim-rule) :
c:[Type == "https://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
=> issue(store = "_OpaqueIdStore", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier"), query = "{0};{1};{2}", param = "ppid", param = c.Value, param = c.OriginalIssuer);

But my setup is a two nodes ADFS Farm (with SQL cluster as a back end) behind a load balancer

My problem is that each node generate a different PPID for the same user.

To my understing adfs should generate the same PPID from both servers?

Is it possible (and how) with _OpaqueIdStore to generate same PPID from different servers of the same ADFS farm ?

Thank you in advance.

Pierre Audonnet - MSFT 10,166 Reputation points Microsoft Employee

2020-03-13T16:11:38.28+00:00

Are you sure they are both members of the same farm?

What do you get when you run this on both nodes:
Get-ADFSFarmInformation
DS 106 Reputation points

2020-03-13T16:59:57.627+00:00

thank you Pierre
from both nodes, Get-ADFSFarmInformation gives :
CurrentFarmBehavior : 4
FarmNodes : {I-IDD-A0.contoso.com, I-IDD-B0.contoso.com}
FarmRoles : {UserState}

Servers are both Server 2019 build 17763.1098 now.
Each node continue to give a different value for same user.
Pierre Audonnet - MSFT 10,166 Reputation points Microsoft Employee

2020-03-13T19:24:38.057+00:00

I cannot repro in my lab. DO you mind copy/pasting the exact rules you are using for this relying party?

DS 106

context : we build an Identity Provider (SAML 2) announced in Research Federation (FER in France and EduGain)
We have in fact two claims rules

firstrule : Synthesize Persistent-ID

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"]
 => add(store = "_OpaqueIdStore", types = ("http://i-idd.contoso.com/internal/persistid"), query = "{0};{1};{2}", param = "ppid", param = c1.Value, param = c1.OriginalIssuer);

DS 106

second rule : Issue NameID persistent eduPersonTargetedID

c:[Type == "http://i-idd.contoso.com/internal/persistid"]
 => issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] = "urn:oasis:names:tc:SAML:2.0:nameid-format:persistent", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/spnamequalifier"] = "https://test-sp.federation.renater.fr", Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/namequalifier"] = "http://i-idd.contoso.com/adfs/services/trust");

DS 106

from first node it generate the following (in response to auth request from service provider

<Subject>
  <NameID Format=&#34;urn:oasis:names:tc:SAML:2.0:nameid-format:persistent&#34;
          NameQualifier=&#34;http://i-idd.contoso.com/adfs/services/trust&#34;
          SPNameQualifier=&#34;https://test-sp.federation.renater.fr&#34;>X89GytsVbVU/CJRIaTIkSY7aM+zHTxfO6fQEyWky1pE=</NameID>
  <SubjectConfirmation Method=&#34;urn:oasis:names:tc:SAML:2.0:cm:bearer&#34;>
    <SubjectConfirmationData InResponseTo=&#34;_43316f4d8bec99f1e007d03e4c61d050&#34;
                             NotOnOrAfter=&#34;2020-03-13T16:35:57.912Z&#34;
                             Recipient=&#34;https://test-sp.federation.renater.fr/Shibboleth.sso/SAML2/POST&#34; />
  </SubjectConfirmation>
</Subject>

Pierre Audonnet - MSFT 10,166 Reputation points Microsoft Employee

2020-03-13T20:09:46.353+00:00

Are your users all coming for the Active Directory claim provider trust?
Also, do you have any other rules on the RP else than those two?

DS 106

from second node we obtain
       <Subject>
          <NameID Format=&#34;urn:oasis:names:tc:SAML:2.0:nameid-format:persistent&#34;
                  NameQualifier=&#34;http://i-idd.contoso.com/adfs/services/trust&#34;
                  SPNameQualifier=&#34;https://test-sp.federation.renater.fr&#34;>3BlZDv1YYF1knAcJaXyyojqQ4MarlOBwz38a+vngpYc=</NameID>
          <SubjectConfirmation Method=&#34;urn:oasis:names:tc:SAML:2.0:cm:bearer&#34;>
            <SubjectConfirmationData InResponseTo=&#34;_528f9fc0f3b8da19be2ef70b62aaf1dc&#34;
                                     NotOnOrAfter=&#34;2020-03-13T16:41:42.552Z&#34;
                                     Recipient=&#34;https://test-sp.federation.renater.fr/Shibboleth.sso/SAML2/POST&#34; />
          </SubjectConfirmation>
        </Subject>

DS 106 Reputation points

2020-03-13T20:26:44.757+00:00
yes all users coming from same AD. In my test/repro this is the very same user.
in example given, the expected output is same value of element NameID (sub element of subject) for same user
but from first node we have X89... and second node we have 3Bl...
as "semanticaly" a urn:oasis:names:tc:SAML:2.0:nameid-format:persistent should be a persistent identifier, so does not change from login to login, this is a problem.

yes i have other claims issuance rules but this one is the only wich generate a nameidentifier

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"
DS 106 Reputation points

2020-03-13T20:29:32.1+00:00

thank for your suggestion of simplifying the test case
will try with only thoses rules and then reply here
Pierre Audonnet - MSFT 10,166 Reputation points Microsoft Employee

2020-03-13T20:30:23.803+00:00

But is that other rules modifying or adding another http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname?
Pierre Audonnet - MSFT 10,166 Reputation points Microsoft Employee

2020-03-25T21:21:10.35+00:00

Hello, do you have any update? Let us know!

Accepted answer

Pierre Audonnet - MSFT 10,166 Reputation points Microsoft Employee

2020-04-16T13:00:30.413+00:00

It reminds me of this: https://social.technet.microsoft.com/Forums/en-US/bf84042b-28c1-4c9e-b859-5d2945c6b9fb/adfs-converts-upper-case-upn-to-small?forum=ADFS

Base on the observation at the time, it seemed that the UPN coming from the acceptance rules was always in lower case. So maybe replace the windowsaccountname by the UPN from the acceptance rules (what I mean by from the acceptance rules is that you don't extract the UPN from an LDAP query but just create a pass-through rule at the relying party trust level).

Else, worst case you can still create convert the windowsaccountname in lowercase (or upper case). You can do that with a custom attribute store: https://learn.microsoft.com/en-us/previous-versions/adfs-2.0/hh599320(v=msdn.10)?redirectedfrom=MSDN or use the fancy regexp from here: https://social.technet.microsoft.com/Forums/en-US/109a226d-b9c5-47b4-98ab-2d9e6446b1e4/adfs-claim-to-convert-user-id-to-uppercase?forum=ADFS.
Please sign in to rate this answer.
DS 106 Reputation points

2020-04-16T17:06:34.277+00:00

Thank you Pierre,
Case sensitivity is a pain sometimes...
Thank you for the links.
Have a good day
Sign in to comment

1 additional answer

DS 106 Reputation points

2020-04-15T14:51:40.553+00:00
Hello, sorry for the delay to follow up but I was a bit busy.... you were on the right track ! Simplified the rules and tested against Claims X-Ray....

And it shows that the problem is NOT in store _OpaqueIdStore, whose arguments are case-sensitive (sound logical) but, as strangely seems, that the CASE of http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname is not consistent beetween node A and node B of my farm

on node A Windows Account name is like CONTOSO\ds123456

on node B Windows Account Name is like CONTOSO\DS123456 (for the very same user, same AD ....) : different case

very strange behaviour...

my simplifed rule

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"] => issue(store = "_OpaqueIdStore", types = ("http://i-idd.silab.cea.fr/internal/ppidwan"), query = "{0};{1};{2}", param = "ppid", param = c1.Value, param = c1.OriginalIssuer);
Please sign in to rate this answer.

0 comments No comments
Sign in to comment