(2019-02-08) Troubleshooting HTTPS/LDAPS

My ADFS environment has an attribute store configured to an ADLDS and for that I used the “ldapattributestore” that still is available in the codeplex archives (https://archive.codeplex.com/?p=ldapattributestore). Because that ADLDS instance was running on a DC with ADDS, I configured the ADLDS instance to use port 5389 for LDAP and port 5636 for LDAPS. The “connection" string” for that LDAP Attribute Store was configured to use a secure connection (i.e. LDAPS) over port 5636. As I was checking functionality of my test environment I also tested this part by targeting the “Show My Claims” app (https://jorgequestforknowledge.wordpress.com/2015/07/04/displaying-the-issued-claims-in-a-security-token-on-screen/) that dives into that LDAP Attribute Store and displays specific claims on screen.

As I did not use my test environment for some time, several certs were expired and needed replacement. I opened the Local Machine certificate store and replaced every certificate that was expired or was going to expire soon with a new certificate using the exact same subject and SANs. After updating all certificates I started configuring and testing every single application using a certificate. So as you can imagine at some point in time I ended up with ADFS, the Show My Claims web site and with that the LDAPS attribute.

As an initial test I accessed the Show My Claims web site and due to the Issuance Transform Rules ADFS needed to dive into the ADLDS attribute store to source claims being displayed on screen. Unfortunately that failed. Looking at the ADFS Admin Event Log, ADFS was having issues accessing the Attribute Store. Those issues were related to the usage of LDAPS.

In that case I needed to start the basic testing of LDAPS through the good old LDP and see what was going on.

–

So after starting LDP and entered the FQDN of the ADLDS instance and its configured LDAPS port   

Figure 1: Starting LDP And Connecting To The ADLDS Instance Using The FQDN, The LDAPS Port

–

After clicking OK I was not surprised about the error “cannot open connection”. The more interesting question was “WHY?”

Figure 2: Error When Connecting To The ADLDS Instance

–

For this ADLDS instance I had a certificate with a subject and SAN that contained “IDSTORE.IAMTEC.NL”. I also permissioned the corresponding private key with the service account being used by the ADLDS instance. So far so good, but even with that it did not work. That’s when I decided to check all the requirements of a certificate to be used for LDAPS and used the following Microsoft article:

• How to enable LDAP over SSL with a third-party certification authority

–

The certificate that I was using fulfilled all requirements and with that in mind it was time to enable debug logging for SCHANNEL when using HTTPS or LDAPS:

• How to enable Schannel event logging in IIS

–

To make sure I was not missing any information, I configured the following for debug logging of SCHANNEL:

• 0x0001 Log error messages
• 0x0002 Log warnings
• 0x0004 Log informational and success events

–

After enabling debug logging for SCHANNEL I tried it again with LDP and in the SYSTEM Event Log I saw the following error.   

Figure 3: Error When Accessing The Private Key

–

A fatal error occurred when attempting to access the TLS server credential private key. The error code returned from the cryptographic module is 0x8009030D. The internal error state is 10001.

–

I reconfirmed the certificate for IDSTORE.IAMTEC.NL had its private key configured for the service account in use by the ADLDS instance. It still did nit work

–

I also saw the following event in the SYSTEM Event Log

Figure 4: The Private Key Being Used By The ADLDS Instance

–

The TLS server credential’s private key has the following properties:

   CSP name: Microsoft RSA SChannel Cryptographic Provider
   CSP type: 12
   Key name: d40c17eadd0fb4c1e33541e54ebf55b1_c9c5687f-fc0b-4765-bc6d-2435ba59e1b2
   Key Type: key exchange
    Key Flags: 0x20

The attached data contains the certificate.

–

The event shown above mentioned the private key being used by the the ADLDS instance, but it still did not mention which certificate was being used. Switching to the details TAB, it told me more about the corresponding certificate that was being used. Going through the data I noticed it contained the SANs “*.IAMTEC.NET” and “*.IAMTEC.NL”. That was surprising to me as the certificate that envisioned for the ADLDS only contained “IDSTORE.IAMTEC.NL” as subject and as SAN.

Figure 5: The Certificate Data That Belong To The Private Key

–

After seeing this I remembered the following listed in the first MSFT article:

Multiple SSL certificates

Schannel, the Microsoft SSL provider, selects the first valid certificate that it finds in the local computer store. If there are multiple valid certificates available in the local computer store, Schannel may not select the correct certificate

–

What I never realized was that my wildcard certificate was going to be used first before even considering the usage of the certificate that contained the more specific subject and SAN.

As displayed below I permissioned the private key that belonged to the wildcard certificate ….

Figure 6: Permissioning The Private Key Of The Wildcard Certificate

–

Retried my test with LDP as shown below….

Figure 7: Retrying The LDAPS Test With DP

–

….and now it worked. You can see at the top it is connecting securely through LDAPS and that it is using a cipher strength of 256 bits

–

After this I check the LDAP Attribute Store configuration to make sure everything was configured correctly. And it was. Retrying accessing the Show My Claims site I was able to the claims that were sourced from the ADLDS instance

Check!

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2017-09-07) Claims Rules Set For Your AAD/O365 RP Trust To Support User And Device Authentication

On the page “How to configure hybrid Azure Active Directory joined devices” Microsoft explains how to setup Domain Join ++, currently a.k.a. Hybrid AAD Join. This post is about, hopefully giving additional, clarification on how to setup the claims rules in ADFS. All the scenarios listed below work, it just on your scenario. Feel free to leave any comments if unclear. The import of the rules below should replace your current rules for the AAD RP Trust, and where applicable add rules to your AD CP trust. A final note, is that these rule sets are based upon Microsoft’s rule in the previous article.

Make sure to test this first in your test environment!

You may also want to have a look at the following blog post:

(2016-12-16) Automatic Azure AD Join With ADFS v3.0 And Higher And Conditional Access – What You Really Need In Detail

–

[OPTION 1]

The following works if you have claims rules in place on the AD CP trust that output the following claim types. This is true if you are using the default claim rule set in ADFSv3/ADFSv4:

• http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid
• http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname

–

Assumptions here:

• You have one ADFS environment servicing all the federated domains in AAD
• The federation identifier being used on your federated domains in AAD is default
• The primary group was not changed for any user or any computer
• The objectGUID is the attribute being used for the Immutable ID for users
• The objectGUID is the attribute being used for the Immutable ID for computers
• On-premises UPN is also the UPN used in AAD
• Whether or not you have multiple federated domains, the config below for the IssuerID for users works as long as the UPN of the user matches one of the federated domains in AAD
• You will replace FEDERATED-DOMAIN with one of the federated domains in AAD. It does not matter which one
• You will replace NAME-OF-AAD/O365-RP-TRUST with the actual name of the RP trust for AAD/O365

–

Remarks:

• Leave a comment if you have any deviation of the assumptions above

–

Thoughts here:

• It is making multiple LDAP calls to AD, and is therefore not that optimized. It works though!
• Still using groupsid claim type

–

Link to claims rules below: https://www.dropbox.com/s/vgzvnwhku2adp39/AzureAD-RP-Trust-Issuance-Rules1.txt

–

$aadRPTrustIssuanceRules = @"

@RuleName = "Issue UPN And ImmutableID (Domain User Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "-513$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"%5D

=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/claims/UPN", "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"), query = ";userPrincipalName,objectGUID;{0}", param = c2.Value);

@RuleName = "Issue IssuerID (Domain User Only)"

c:[Type == "http://schemas.xmlsoap.org/claims/UPN"%5D

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = regexreplace(c.Value, ".+@(?<domain>.+)", http://${domain}/adfs/services/trust/));

@RuleName = "Issue ImmutableID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(store = "Active Directory", types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID&quot;), query = ";objectguid;{0}", param = c2.Value);

@RuleName = "Issue Account Type (Domain Joined Computer Only)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2012/01/accounttype&quot;, Value = "DJ");

@RuleName = "Issue ObjectGUID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(store = "Active Directory", types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid&quot;), query = ";objectguid;{0}", param = c2.Value);

@RuleName = "Issue ObjectSID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(claim = c2);

@RuleName = "Issue IssuerID (Domain Joined Computer Only)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = http://FEDERATED-DOMAIN/adfs/services/trust/);

@RuleName = "Issue NameID (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"%5D

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier&quot;, Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"%5D = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

@RuleName = "Issue AuthN Methods References (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"%5D

=> issue(claim = c);

"@

Set-AdfsRelyingPartyTrust -TargetName "NAME-OF-AAD/O365-RP-TRUST" -IssuanceTransformRules $aadRPTrustIssuanceRules

–

[OPTION 2]

The following works if you have claims rules in place on the AD CP trust that output the following claim types. This is true if you are using the default claim rule set in ADFSv3/ADFSv4:

• http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid
• http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn

–

Assumptions here:

• You have one ADFS environment servicing all the federated domains in AAD
• The federation identifier being used on your federated domains in AAD is default
• The primary group was not changed for any user or any computer
• The objectGUID is the attribute being used for the Immutable ID for users
• The objectGUID is the attribute being used for the Immutable ID for computers
• On-premises UPN is also the UPN used in AAD
• Whether or not you have multiple federated domains, the config below for the IssuerID for users works as long as the UPN of the user matches one of the federated domains in AAD
• You will replace FEDERATED-DOMAIN with one of the federated domains in AAD. It does not matter which one
• You will replace NAME-OF-AAD/O365-RP-TRUST with the actual name of the RP trust for AAD/O365

–

Remarks:

• Leave a comment if you have any deviation of the assumptions above

–

Thoughts here:

• Although a few LDAP calls less, it is still making LDAP calls to AD. It works though!
• Still using groupsid claim type

–

Link to claims rules below: https://www.dropbox.com/s/udn1rudm5bgv7jq/AzureAD-RP-Trust-Issuance-Rules2.txt

–

$aadRPTrustIssuanceRules = @"

@RuleName = "Issue UPN (Domain User Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-513$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"%5D

=> issue(Type = "http://schemas.xmlsoap.org/claims/UPN&quot;, Issuer = c2.Issuer, OriginalIssuer = c2.OriginalIssuer, Value = c2.Value, ValueType = c2.ValueType);

@RuleName = "Issue IssuerID (Domain User Only)"

c:[Type == "http://schemas.xmlsoap.org/claims/UPN"%5D

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = regexreplace(c.Value, ".+@(?<domain>.+)", http://${domain}/adfs/services/trust/));

@RuleName = "Issue Account Type (Domain Joined Computer Only)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2012/01/accounttype&quot;, Value = "DJ");

@RuleName = "Issue ObjectGUID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(store = "Active Directory", types = ("http://schemas.microsoft.com/identity/claims/onpremobjectguid&quot;), query = ";objectguid;{0}", param = c2.Value);

@RuleName = "Issue ObjectSID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(claim = c2);

@RuleName = "Issue IssuerID (Domain Joined Computer Only)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = http://FEDERATED-DOMAIN/adfs/services/trust/);

@RuleName = "ImmutableID (Domain User And Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"%5D

=> issue(store = "Active Directory", types = ("http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID&quot;), query = ";objectGUID;{0}", param = c.Value);

@RuleName = "Issue NameID (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"%5D

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier&quot;, Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"%5D = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

@RuleName = "Issue AuthN Methods References (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"%5D

=> issue(claim = c);

"@

Set-AdfsRelyingPartyTrust -TargetName "NAME-OF-AAD/O365-RP-TRUST" -IssuanceTransformRules $aadRPTrustIssuanceRules

–

[OPTION 3]

The following works if you have claims rules in place on the AD CP trust that output the following claim types. This is true if you are using the default claim rule set in ADFSv3/ADFSv4:

• http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid
• http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
• http://temp.org/identity/claims/objectGUID

–

For the last claim type you would need the following claim rule on the AD CP trust if you are not already extracting additional data from AD

–

$additionalADCPTrustRule = @"
@RuleTemplate = "LdapClaims"
@RuleName = "Extract Extra Data From AD"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer == "AD AUTHORITY"]
  => issue(store = "Active Directory", types = ("http://temp.org/identity/claims/objectGUID&quot;), query = ";objectguid;{0}", param = c.Value);
"@

$existingADCPtrustAcceptRuleSet = (Get-AdfsClaimsProviderTrust -Name "Active Directory").AcceptanceTransformRules

$newADCPtrustAcceptRuleSet = $existingADCPtrustAcceptRuleSet + $additionalADCPTrustRule

Set-AdfsClaimsProviderTrust -TargetName "Active Directory" -AcceptanceTransformRules $newADCPtrustAcceptRuleSet

–

If you are already extracting additional data from AD, you need to add the claim type and attribute to that existing extraction

–

Assumptions here:

• You have one ADFS environment servicing all the federated domains in AAD
• The federation identifier being used on your federated domains in AAD is default
• The primary group was not changed for any user or any computer
• The objectGUID is the attribute being used for the Immutable ID for users
• The objectGUID is the attribute being used for the Immutable ID for computers
• On-premises UPN is also the UPN used in AAD
• Whether or not you have multiple federated domains, the config below for the IssuerID for users works as long as the UPN of the user matches one of the federated domains in AAD
• You will replace FEDERATED-DOMAIN with one of the federated domains in AAD. It does not matter which one
• You will replace NAME-OF-AAD/O365-RP-TRUST with the actual name of the RP trust for AAD/O365

–

Remarks:

• Leave a comment if you have any deviation of the assumptions above

–

Thoughts here:

• No LDAP calls!
• Still using groupsid claim type

–

Link to claims rules below: https://www.dropbox.com/s/8cicjpyusapsarj/AzureAD-RP-Trust-Issuance-Rules3.txt

–

$aadRPTrustIssuanceRules = @"

@RuleName = "Issue UPN (Domain User Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-513$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"%5D

=> issue(Type = "http://schemas.xmlsoap.org/claims/UPN&quot;, Issuer = c2.Issuer, OriginalIssuer = c2.OriginalIssuer, Value = c2.Value, ValueType = c2.ValueType);

@RuleName = "Issue IssuerID (Domain User Only)"

c:[Type == "http://schemas.xmlsoap.org/claims/UPN"%5D

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = regexreplace(c.Value, ".+@(?<domain>.+)", http://${domain}/adfs/services/trust/));

@RuleName = "Issue Account Type (Domain Joined Computer Only)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2012/01/accounttype&quot;, Value = "DJ");

@RuleName = "Issue ObjectGUID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://temp.org/identity/claims/objectGUID"%5D

=> issue(Type = "http://schemas.microsoft.com/identity/claims/onpremobjectguid&quot;, Issuer = c2.Issuer, OriginalIssuer = c2.OriginalIssuer, Value = c2.Value, ValueType = c2.ValueType);

@RuleName = "Issue ObjectSID (Domain Joined Computer Only)"

c1:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(claim = c2);

@RuleName = "Issue IssuerID (Domain Joined Computer Only)"

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid&quot;, Value =~ "-515$", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = http://FEDERATED-DOMAIN/adfs/services/trust/);

@RuleName = "ImmutableID (Domain User And Domain Joined Computer)"

c:[Type == "http://temp.org/identity/claims/objectGUID"%5D

=> issue(Type = "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

@RuleName = "Issue NameID (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"%5D

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier&quot;, Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"%5D = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

@RuleName = "Issue AuthN Methods References (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"%5D

=> issue(claim = c);

"@

Set-AdfsRelyingPartyTrust -TargetName "NAME-OF-AAD/O365-RP-TRUST" -IssuanceTransformRules $aadRPTrustIssuanceRules

–

[OPTION 4]

The following works if you have claims rules in place on the AD CP trust that output the following claim types.  This is true if you are using the default claim rule set in ADFSv3/ADFSv4 for the first 2 claim types, but not for the last 2 claim types. My main reason for not using groupsid is that the amount of values can be so huge it may not fit on a cookie and the browser chokes. Because of that, when not using the groupsid claim type, you need to design a better model to extract group data from AD and use authorization based claims types from that data. If you are not using the groupsid claim type you can also not identify the difference between a user and a computer. That’s why you can then specifically extract the primaryGroupID.:

• http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
• http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn
• http://temp.org/identity/claims/objectGUID
• http://temp.org/identity/claims/primaryGroupID

–

For the last 2 claim types you would need the following claim rule on the AD CP trust if you are not already extracting additional data from AD

–

$additionalADCPTrustRule = @"
@RuleTemplate = "LdapClaims"
@RuleName = "Extract Extra Data From AD"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer == "AD AUTHORITY"]
  => issue(store = "Active Directory", types = ("http://temp.org/identity/claims/objectGUID&quot;,"http://temp.org/identity/claims/primaryGroupID&quot;), query = ";objectguid,primaryGroupID;{0}", param = c.Value);
"@

$existingADCPtrustAcceptRuleSet = (Get-AdfsClaimsProviderTrust -Name "Active Directory").AcceptanceTransformRules

$newADCPtrustAcceptRuleSet = $existingADCPtrustAcceptRuleSet + $additionalADCPTrustRule

Set-AdfsClaimsProviderTrust -TargetName "Active Directory" -AcceptanceTransformRules $newADCPtrustAcceptRuleSet

–

If you are already extracting additional data from AD, you need to add the claim type and attribute to that existing extraction

–

Assumptions here:

• You have one ADFS environment servicing all the federated domains in AAD
• The federation identifier being used on your federated domains in AAD is default
• The primary group was not changed for any user or any computer
• The objectGUID is the attribute being used for the Immutable ID for users
• The objectGUID is the attribute being used for the Immutable ID for computers
• On-premises UPN is also the UPN used in AAD
• Whether or not you have multiple federated domains, the config below for the IssuerID for users works as long as the UPN of the user matches one of the federated domains in AAD
• You will replace FEDERATED-DOMAIN with one of the federated domains in AAD. It does not matter which one
• You will replace NAME-OF-AAD/O365-RP-TRUST with the actual name of the RP trust for AAD/O365

–

Remarks:

• Leave a comment if you have any deviation of the assumptions above

–

Thoughts here:

• No LDAP calls!
• No groupsid claim type!

–

Link to claims rules below: https://www.dropbox.com/s/6nbwuuxl677wb3p/AzureAD-RP-Trust-Issuance-Rules4.txt

–

$aadRPTrustIssuanceRules = @"

@RuleName = "Issue UPN (Domain User Only)"

c1:[Type == "http://temp.org/identity/claims/primaryGroupID&quot;, Value =~ "^513$"] &&

c2:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"%5D

=> issue(Type = "http://schemas.xmlsoap.org/claims/UPN&quot;, Issuer = c2.Issuer, OriginalIssuer = c2.OriginalIssuer, Value = c2.Value, ValueType = c2.ValueType);

@RuleName = "Issue IssuerID (Domain User Only)"

c:[Type == "http://schemas.xmlsoap.org/claims/UPN"%5D

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = regexreplace(c.Value, ".+@(?<domain>.+)", http://${domain}/adfs/services/trust/));

@RuleName = "Issue Account Type (Domain Joined Computer Only)"

c:[Type == "http://temp.org/identity/claims/primaryGroupID&quot;, Value =~ "^515$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2012/01/accounttype&quot;, Value = "DJ");

@RuleName = "Issue ObjectGUID (Domain Joined Computer Only)"

c1:[Type == "http://temp.org/identity/claims/primaryGroupID&quot;, Value =~ "^515$"] &&

c2:[Type == "http://temp.org/identity/claims/objectGUID"%5D

=> issue(Type = "http://schemas.microsoft.com/identity/claims/onpremobjectguid&quot;, Issuer = c2.Issuer, OriginalIssuer = c2.OriginalIssuer, Value = c2.Value, ValueType = c2.ValueType);

@RuleName = "Issue ObjectSID (Domain Joined Computer Only)"

c1:[Type == "http://temp.org/identity/claims/primaryGroupID&quot;, Value =~ "^515$"] &&

c2:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]

=> issue(claim = c2);

@RuleName = "Issue IssuerID (Domain Joined Computer Only)"

c:[Type == "http://temp.org/identity/claims/primaryGroupID&quot;, Value =~ "^515$"]

=> issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid&quot;, Value = http://FEDERATED-DOMAIN/adfs/services/trust/);

@RuleName = "ImmutableID (Domain User And Domain Joined Computer)"

c:[Type == "http://temp.org/identity/claims/objectGUID"%5D

=> issue(Type = "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

@RuleName = "Issue NameID (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID"%5D

=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier&quot;, Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"%5D = "urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified");

@RuleName = "Issue AuthN Methods References (Domain User and Domain Joined Computer)"

c:[Type == "http://schemas.microsoft.com/claims/authnmethodsreferences"%5D

=> issue(claim = c);

"@

Set-AdfsRelyingPartyTrust -TargetName "NAME-OF-AAD/O365-RP-TRUST" -IssuanceTransformRules $aadRPTrustIssuanceRules

–

Hopefully this blog post gives you the information you need to understand what is needed

–

Cheers,
Jorge

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2017-06-15) Displaying The Welcome Message On The MFA Page In ADFS 2016

In ADFS 2012 R2 when hitting the MFA page a welcome message was displayed with an explanation as shown in figure 1 below

Figure 1: MFA Page In ADFS 2012 R2 With The Default Value For The Name Claim Type

–

Looking at the default behavior in ADFS 2016 you will get the following instead

Figure 2: MFA Page In ADFS 2016 With The Default Value For The UPN Claim Type

–

There is no welcome message anymore and the identity value is now located in the explanation at the end.

If you want to revert back to the ADFS 2012 R2 behavior you can do the following:

[Step 1]

Clone the current active ADFS web theme to a new ADFS web theme

First determine the current web theme

Get-ADFSWebConfig

Clone the current active web theme to a new web theme

New-AdfsWebTheme -Name <New Web Theme Name> -SourceName <Active Web Theme Name>

–

[Step 2]

Export the cloned web theme to a folder on the file system

Export-AdfsWebTheme -Name <New Web Theme Name> -DirectoryPath <Some Folder On The File System>

–

[Step 3]

Edit the file “onload.js” in the folder “<Some Folder On The File System>\Script” and add the following piece of code to the end of the file to show the welcome message again

// Check if we are in the auth area
var authNArea = document.getElementById("authArea");
if (authNArea) {
    // if mfaGreeting element is present, modify its properties.
    var mfaGreeting = document.getElementById("mfaGreeting");
    if (mfaGreeting) {
        mfaGreeting.className = "fieldMargin bigText";
    }
}

–

[Step 4]

Import the new edited “onload.js” file

Set-AdfsWebTheme -TargetName <New Web Theme Name> -AdditionalFileResource @{Uri=’/adfs/portal/script/onload.js’;path="<Some Folder On The File System>\script\onload.js"}

–

[Step 5]

Activate the new web theme

Set-AdfsWebConfig -ActiveThemeName <New Web Theme Name>

–

[Step 6]

Reconfigure the explanation text if required

Set-AdfsGlobalWebContent -SignInPageAdditionalAuthenticationDescriptionText "For security reasons, we require additional information to verify your account"

–

Now access an application through ADFS for which MFA is required

–

If you did display the Welcome message and did not revert back to the explanation as shown in the ADFS 2012 R2 you would see something similar to

Figure 3: Customized MFA Page In ADFS 2016 With The Default Value For The UPN Claim Type

–

–

Cheers,
Jorge

 

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2017-06-12) Changing The Identity Type Displayed On The MFA Page In ADFS

By default when you hit the MFA page in ADFS 2012 R2, the identity type displayed is similar to DOMAIN\SAMACCOUNTNAME as you can see in figure 1 below. The MFA page in ADFS 2012 R2 by default uses the value from the name claim type (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name”) to display that same value in the MFA page in ADFS 2012 R2.

The name claim type is configured by default in an Acceptance Transform Rule on the “Active Directory” CP trust, and it is most likely read from the “msDS-PrincipalName” attribute in AD.

The Acceptance Transform Rule on the “Active Directory” CP trust for the name claim type may be similar to

@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass through all Name claims"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name&quot;, Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] => issue(claim = c);

Figure 1: MFA Page In ADFS 2012 R2 With The Default Value For The Name Claim Type

–

However, with all the cloud development going on and everything focusing on the mail address of a user instead, you may want to display the mail address of the user instead as displayed in figure 2 below.

To make this change you need to delete the default Acceptance Transform Rule on the “Active Directory” CP trust for the name claim type and create a new rule where you will flow the value of the mail claim value (MAIL@ADDRESS.COM) into the name claim type. The new Acceptance Transform Rule on the “Active Directory” CP trust would look like:

@RuleTemplate = "MapClaims"
@RuleName = "E-mail Address To Name"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"%5D
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

Figure 2: MFA Page In ADFS 2012 R2 With The Custom Value For The Name Claim Type

–

Is there a catch to this? Yes there is, or better yes there are!

–

[Catch 1]

By default the e-mail address is NOT extracted from AD by ADFS! Because of that you need to create your own Acceptance Transform Rule where you do that. The Acceptance Transform Rule you need at least is or looks similar to:

@RuleTemplate = "LdapClaims"
@RuleName = "E-mail Address"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname&quot;, Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress&quot;), query = ";mail;{0}", param = c.Value);

Because the name claim type depends on this Acceptance Transform Rule, this Acceptance Transform Rule for the mail claim type must be processed before the Acceptance Transform Rule for the name claim type

–

[Catch 2]

Some applications connected to ADFS may expect to receive a name claim value that looks like DOMAIN\SAMACCOUNTNAME instead of MAIL@ADDRESS.COM. By implementing the new Acceptance Transform Rule for the name claim type you will impact those applications.

To mitigate that impact before making those changes, you would need reconfigure the RP trust of the application that needs the name claim value. If RP trust has an Issuance Transform Rule that is similar to or looks like:

@RuleTemplate = "PassThroughClaims"
@RuleName = "Pass through all Name claims"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"%5D => issue(claim = c);

….you would need to delete that Issuance Transform Rule and replace it with:

@RuleTemplate = "MapClaims"
@RuleName = "Windows Account Name To Name"
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"%5D
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

–

[Catch 3]

By default when you hit the MFA page in ADFS 2016, the identity type displayed is similar to UPN@ADDRESS.COM as you can see in figure 1 below. The MFA page in ADFS 2016 by default uses the value from the upn claim type (“http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn”) to display that same value in the MFA page in ADFS 2016. However, if there is no value for the upn claim, it will fall back to the value of the name claim. Unless you have removed it, by default ADFS has an Acceptance Transform Rule on the “Active Directory” CP trust for the upn claim type. And if you look carefully, the text also changed (compare figure 1 and figure 3).

As you can see in figure 3, it now really shows my upn (jorge@iamtec.net) whereas mail e-mail address uses a different suffix (jorge@iamtec.nl). With the use of Azure AD, the federated/managed domain in AAD is iamtec.nl and not iamtec.net.

Figure 3: MFA Page In ADFS 2016 With The Default Value For The UPN Claim Type

–

To be able to logon with the mail address I have 2 options, either update the userPrincipalName value to match the mail address value in AD or keep it as is and use the alternate logon ID feature in ADFS to target the mail address field in AD. If you choose the first option the value in the MFA page is also updated automatically and you do not need to update Acceptance Transform Rules. If you choose the second option you may need to delete the default Acceptance Transform Rule for the upn claim type and replace it with the following Acceptance Transform Rule:

@RuleTemplate = "MapClaims"
@RuleName = "E-Mail Address To UPN"

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"%5D
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

This new Acceptance Transform Rule for the upn claim type would result in the following for on the MFA page in ADFS 2016

Figure 4: MFA Page In ADFS 2016 With The Custom Value For The UPN Claim Type

–

Is there a catch to the catch? Unfortunately there is! As mentioned earlier for the name claim type, the same would apply to the upn clam type. Some applications connected to ADFS may expect to receive a upn claim value that looks like UPN@ADDRESS.COM instead of MAIL@ADDRESS.COM. By implementing a new Acceptance Transform Rule for the upn claim type you will impact those applications.

To mitigate that impact before making those changes, you would need reconfigure the “Active Directory” CP trust and implement an Acceptance Transform Rule that is similar to or looks like:

@RuleTemplate = "MapClaims"
@RuleName = "Original UPN To Custom UPN Claim"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"%5D
=> issue(Type = "http://temp.org/identity/claims/orgUPN&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

…and you would need reconfigure the RP trust of the application that needs the original upn claim value. If RP trust has an Issuance Transform Rule that is similar to or looks like:

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"%5D
=> issue(claim = c);

….you would need to delete that Issuance Transform Rule and replace it with:

@RuleTemplate = "MapClaims"
@RuleName = "Custom UPN Claim To Original UPN"
c:[Type == "http://temp.org/identity/claims/orgUPN""http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname"%5D
=> issue(Type = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn&quot;, Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

–

–

Cheers,
Jorge

 

————————————————————————————————————————————————————-
This posting is provided "AS IS" with no warranties and confers no rights!
Always evaluate/test everything yourself first before using/implementing this in production!
This is today’s opinion/technology, it might be different tomorrow and will definitely be different in 10 years!
DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
————————————————————————————————————————————————————-
########################### Jorge’s Quest For Knowledge ##########################
#################### http://JorgeQuestForKnowledge.wordpress.com/ ###################
————————————————————————————————————————————————————-

(2011-10-24) Configuring The New Five Claim Types In ADFS After Installing Rollup Package 1 For ADFS v2.0

As I mentioned in this blog post, Microsoft has released a rollup package 1 for ADFS v2.0 which introduces 5 new claim types. However, right after installing the rollup package, rebooting the servers (ADFS STS(s) and ADFS PRX(s), if applicable) and opening the ADFS v2.0 MMC you do not see the new claim types as you might expect. Below you see the result on my ADFS v2.0 STS box after installing the rollup package 1. And as you can see the 5 new claim types are not available.

–

REMARK: All the other claim types you do not recognize, were created by me as custom claim types.

–

Figure 1: Claim Types (a.k.a. Claim Descriptions) In ADFS v2.0 (Default And Custom)

–

It turns out the new Claim Types are not created automatically. Therefore YOU must create them within ADFS v2.0.

For every new Claim Type you must specify the following information:

• Display Name (mandatory)
• Claim Identifier(mandatory)
• Description(optional)
• Selection Of “Publish this claim description in federation metadata as a claim type that this Federation Service can accept” (optional)
• Selection Of “Publish this claim description in federation metadata as a claim type that this Federation Service can send” (optional)

–

Figure 2: Creating A New Claim Type/Description Within ADFS v2.0

–

In the end my the new Claim Types/Descriptions look like as shown below:

–

Figure 3: Claim Types (a.k.a. Claim Descriptions) In ADFS v2.0 (Default And Custom) Now Including The New Claim Types/Descriptions

–

In a Sharepoint 2010 webpart that lists all the claims issued you can see the user passed through the ADFS Proxy and is therefore external to the company network. The value shows the NetBIOS name of the ADFS Proxy Server and just by the presence of the claim you can make additional decisions in for example the Issuance Authorization Rules.

Figure 4: Issued Claim Types Listed By A Sharepoint 2010 WebPart – Showing The ID Passed Through An ADFS Proxy Server

–

Remember that because this claim is included it does not mean it is an external user, it could be though! However, an internal user outside of the internal network that also passes through the ADFS Proxy Server also gets this claim!

–

REMARK: also check out the following post “Limiting Access to Office 365 Services Based on the Location of the Client”

–

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: https://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————