Archive for the ‘Federation Trusts’ Category

(2020-04-19) It’s That Time Again, You Need To Roll-Over The Certificates In ADFS

Posted by Jorge on 2020-04-19

This weekend I was involved in rolling over the ADFS Token Signing and Token Encryption certificates while a huge amount of application were connected using WS-Federation, SAML or OAuth. With regards to rolling over the certificates, only the WS-Federation and SAML based apps are impacted, not the OAuth apps.

Short answer: preparation, communication and automation are KEY!

–

This ADFS system was designed and implemented by me years ago. In the beginning, there were just a few apps and it grew gradually. After a moment it was starting to grow like crazy. More and more app devs smelled the federated SSO cool stuff and wanted that for their app(s). Why? Default globally supported protocols between organizations, apps, etc, and all based on federation. Supported by ADFS, many other on-premises federation systems and cloud based systems, such as e.g. Azure AD. The focus of this blog post is apps connected to ADFS as the federation provider, for both downstream identity providers and upstream service providers.

–

When I design this system, after the technology, I also designed the required processes to make sure the technology was used in the correct way. If you do not design the processes in addition to the technology, it becomes a mess and because certificates are used it will drop dead, exactly 1 year after installing/configuring it. Why will it drop dead after 1 year? The default Token Signing and Token Encryption certificates are ADFS managed and expire after 1 year. All apps not (being) able to consume to the federation metadata URL automatically will drop dead if no action is taken in time! And rushing with no process in place is a good cocktail for possible failure. If you have a handful of apps, you should be OK, but if you have 100+, or 200+ or even more apps connected to ADFS, you seriously need a process to get this done in time and correctly. Regarding the process, that ADFS has internally, please see: (2013-05-14) ADFS Managed Certificates Supporting Auto Certificate Rollover

–

Processes:

Backup/Export of the complete ADFS configuration
Provisioning of applications onto ADFS
Recertification of any connected application, keep or deprovision
Notification of expiring certificates in ADFS (about 3 months ahead of time)
Certificate change in ADFS
Validation of specified e-mail addresses against AD

–

During the onboarding of ANY application the following was recorded:

Does an application support automatic consumption of the federation metadata URL or does it support its consumption manually through an XML file?
Does an application support just 1 or 2 Token Signing certificates from an identity provider?
When an application supports the consumption of the federation metadata file, AND it supports only 1 Token Signing certificate, which certificate will it consume when it reads the federation metadata file as it contains multiple Token Signing certificates from the identity provider
E-mail addresses from at least 3 “owners”
E-mail address of either a functional mailbox or distribution list with a support team behind

–

[AD.1]

If it supports automatic consumption of federation metadata through a URL (for ADFS: /federationmetadata/2007-06/federationmetadata.xml">https://<federation service FQDN>/federationmetadata/2007-06/federationmetadata.xml) it processes the information automatically. If it does not, you may need to first export the federation metadata to an XML file to be able to import it into the application. Even though the federation metadata URL is used, it does not mean an application uses it automatically on a regular basis (e.g. every day). It is possible that a admin need to run a script, or push some button or whatever

–

[AD.2]

If an application supports 2 Token Signing certificates from an identity provider, a smooth certificate rollover is supported without ANY pain. If only 1 Token Signing certificate is supported it means, the certificate must be replaced at (nearly) the same time as the ADFS admin switches the primary and secondary Token Signing certificate

–

[AD.3]

This scenario should be very rare, but unfortunately some apps do it incorrectly. When the federation metadata from the identity provider is imported, and only 1 Token Signing certificate is used, and the federation metadata from the identity provider contains multiple Token Signing certificates, which is consumed (used) by the application? The first Token Signing certificate occurrence, or the last occurrence? If it is the last occurrence, then that is good, but the federation metadata XML file must only be imported at the same time when the switch is made in ADFS. If it is the first occurrence, then the app is not following best practice and it will break as soon as the switch in ADFS is done.

ADFS by default:

Publishes ALL Token Signing certificates in the federation metadata
The oldest Token Signing certificate is published first and the newest Token Signing certificate is published last
Switching Token Signing certificates in ADFS DOES NOT change the order of the Token Signing certificates in the federation metadata

Publishes only the primary (active) Token Encryption certificate in the federation metadata

Switching Token Encryption certificates in ADFS removes the old Token Encryption certificate from the federation metadata, and adds the new Token Encryption certificate to the federation metadata
ADFS signs the federation metadata with the primary (active) Token Signing certificate

So if the first occurrence of the Token Signing certificate is consumed, after the switch in ADFS, the only way to solve this is:

Edit the federation metadata XML file and remove the first occurrence of the Token Signing certificate (old Token Signing certificate, marked as “use=’signing’”, appears 3 times in the federation metadata XML), and keep the last occurrence (the newest) Token Signing certificate
OR
Remove the oldest Token Signing certificate as a secondary from ADFS, export the federation metadata to an XML file and import it into the application

Which option you use depends on whether or not an application checks for the signing of the federation metadata. If it does not, you can use either option, but it is easier to edit and you can keep the old Token Signing certificate as secondary if for whatever unlikely reason want to rollback (not recommended when having many applications (define “many”!) as it may turn out in a logistics nightmare

–

[AD.4]

A minimum of three e-mail addresses are required to support the yearly recertification process where a decision is made to either keep or deprovision the federation trust in ADFS. A minimum of three mail addresses as people come and people go (internally or externally), and chances are very low that all three people move at the same time (unless there is a reorganization, sigh!). If any of the listed people changes roles

–

[AD.5]

The e-mail address of a functional mailbox or distribution list with people from a (technical) support team behind it. This is mainly used by the “Certificate Change in ADFS” process. The chance of failure must be brought to a minimum by not having dependency of e-mail addresses from people, but rather have e-mail address of a functional mailbox or distribution list with people behind it. The people from a (technical) support team are responsible to updating the application with the new Token Signing when ADFS changes the certificate.

–

Now having all this information, you need to be able to store it somewhere that makes it easily manageable and provides the ability to process it through scripting (automation). Within ADFS, every single trust has a notes or description field, and the field can perfectly be used to store this information. However it is a string formatted field with a maximum of 3000 characters. I thought of the idea to implement an XML structure to be able to read from and write to it as needed. Works like magic as we can script against it too. But how about using CMDB? Well, we wanted to be certain of the up-to-date-ness of the information, we wanted to be able to script against it and we wanted it as close as possible to the trust configuration in ADFS.

–

Now, the whole certificate change in ADFS looks like something similar to:

Define "Product Backlog Items (PBI)" on the backlog, plan into sprints and assign to people
Organize initial meeting with colleagues to explain process, answer any questions and discuss PBIs
Plan meeting with (higher) management and deliver a presentation about the certificate change, discussing what, when, why, how, current state (number of trusts), risks, impact, rollback (none!), etc.
Raise an RFC to change certificates in ADFS and push to achieve the highest risk/impact category possible
Check and fix if needed e-mail addresses from application owners and support teams
Request new certificates for ADFS (SSL, Token Signing and Token Encryption)
Install all new certificates in the personal certificate store of all ADFS servers
Install the new SSL certificate in the personal certificate store of all WAP servers
Configure the new Token Signing certificate as a secondary Token Signing certificate
Configure the new Token Encryption certificate as a secondary Token Encryption certificate
Configure the new Svc Comm/SSL Certificate on all ADFS servers and WAP servers
Recheck and fix if needed e-mail addresses from application owners and support teams
Send the "First Notification" to all support teams and application owners
Notify the global service committee about the upcoming change, provide information and request to chase teams/owners
Send the "Reminder Notification" to all support teams and application owners
Switch the Token Signing/Encryption Certificate in ADFS
Send the "Switch Executed Notification" to all support teams and application owners
Guide and support support teams and application owners that request or needed guidance
Organize a closure meeting with colleagues to discuss any feedback from support teams and application owners, colleagues involved, and if applicable possible improvements for the process
Process the feedback and improvements from the closure meeting for the next time

–

End Result: SUCCESS! Oops I did it again!

–

I have done this multiple times now, and even though there is nothing to it (that’s what I think!) it is always exciting due to the huge amount of applications involved! The most difficult part is explaining this to non-technical people where you have to say things like: “there is no rollback”, “there will be issues with apps”, “fix forward only”, etc. It just scare the crap out of them and I understand that. Another one not to forget is, the support team, and sometimes even the vendor or service provideers, managing the application do not have the technical knowledge regarding federation and SSO

–

But, been there, done that, got the t-shirt, all sizes and all colours! Smile

–

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/ ###################
————————————————————————————————————————————————————-

Posted in Active Directory Federation Services (ADFS), Auto Certificate Rollover, Certificates, Export/Import, Federation Metadata, Federation Trusts | Leave a Comment »

(2018-10-09) Changing AD CP Trust Display Name And Order In ADFS 2016 Farm Level And Higher

Posted by Jorge on 2018-10-09

You are currently running ADFS 2012 R2 and you are planning on upgrading (yes, you can upgrade!) to ADFS 2016. Your Home Realm Discovery (HRD) page is looking similar to the one in figure 1, meaning that the AD CP trust is listed at the top and that it inherits the Display Name of the federation service. So far so good , right?

Figure 1: A Home Realm Discovery Web Page In ADFS 2012 R2 Or ADFS 2016 When At ADFS 2012 R2 Farm Level

–

After adding ADFS 2016 servers and removing the ADFS 2012 R2 servers, it is time to increase the farm level to the highest farm level possible.

–

You “throw the switch” and suddenly your HRD page looks similar to the one as displayed in figure 2. Damn!

Figure 2: A Home Realm Discovery Web Page In ADFS 2016 When At, At Least ADFS 2016 Farm Level

–

From a user perspective, that can be quite some impact as user to not expect “their default selection” to have moved to the bottom. Worse yet, the users might not even recognize it because the trust display name does not inherit the display name of the federation service anymore. It just shows as “Active Directory”, which is a technical name. You might think in changing the display name of the “Active Directory” CP trust to match whatever you need. Let me save you the trouble of trying that, because, it is not allowed to change much including the display name.

So, one simple change (farm level increase) results in an unfortunate functional impact for users.

What can you do about this? The solution to this problem is to implement some extra javascript code in the ONLOAD.JS.

To make sure your current web theme is not broken while making this change, make sure to first create a new web theme and implement the changes in that new web theme. So let’s get started!

–

Retrieve the name of your CURRENT web theme

Get-AdfsWebConfig

In the property called “ActiveThemeName” you will find the name of the current theme that is active and in use by everyone.

–

Make a copy of that theme and give the copy a new name:

New-AdfsWebTheme -Name <New WebTheme Name> -SourceName <Current Active WebTheme Name>

–

Export the new web theme to be able to edit it:

MD <Path To Export The Theme To>

Export-AdfsWebTheme -Name <New WebTheme Name> -DirectoryPath <Path To Export The Theme To>

–

Open the ONLOAD.JS file

NOTEPAD "<Path To Export The Theme To>\script\onload.js"

–

Edit the ONLOAD.JS file by adding a piece of javascript code at the end of it. It will put the AD CP trust at the top again and it will rename it to the display name of your choosing. It has been tested with the following browsers: IE, Edge, Chrome, Firefox, Safari.
REMARK: Make sure to follow guidelines as available in https://docs.microsoft.com/en-us/windows-server/identity/ad-fs/operations/advanced-customization-of-ad-fs-sign-in-pages

The javascript code is available at: https://github.com/microsoft/adfsWebCustomization/tree/master/communityCustomizations/RenameAndReorderADCPTrust

–

Save the ONLOAD.JS file

–

Import the new ONLOAD.JS into the new web theme

Set-AdfsWebTheme -TargetName <New WebTheme Name> -AdditionalFileResource @{Uri=’/adfs/portal/script/onload.js’;path="<Path To Export The Theme To>\script\onload.js"}

–

Now it is time to activate the new web theme and check it has been activated

Set-AdfsWebConfig -ActiveThemeName <New WebTheme Name>

Get-AdfsWebConfig

–

Now make sure to clear your cookies, and navigate to an application connected to ADFS for which more than one CP trust is allowed to use. In that case, assuming you have cleared your cookies, the HRD page should appear and it should again be similar to what you see in figure 1.

–

If you need to revert back to your previous current web theme, you new to activate it as such and check it has been activated

Set-AdfsWebConfig -ActiveThemeName <Current Active WebTheme Name>

Get-AdfsWebConfig

–

PS: make sure to test this first in a test environment!

–

Cheers,
Jorge

Posted in Active Directory Federation Services (ADFS), Configuration, Federation Trusts, Home Realm Discovery (HRD), Migration, onload.js | Leave a Comment »

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

Posted by Jorge on 2017-06-12

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", 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", 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", Issuer == "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress"), 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", 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", 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", 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", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

–

Cheers,
Jorge

Posted in Active Directory Federation Services (ADFS), Azure AD MFA Adapter, Claim Types, Claims, Claims Rule Language, Federation Trusts | Leave a Comment »

(2016-12-03) Adding Or Updating An RP Trust Through The GUI in Windows Server 2016 Fails When Using A Federation Metadata URL

Posted by Jorge on 2016-12-03

UPDATE 2016-12-16: It looks as the latest updates for Windows Server 2016 have fixed this issue!

–

You just upgraded your ADFS farm to ADFS v4.0 (ADFS in Windows Server 2016). After that you experience either one or all of the following:

Adding a CP or RP Trust Through The GUI leveraging a metadata URL fails
Adding a CP or RP Trust Through The GUI that leverages a metadata URL fails
The automatic trust monitoring cycle that runs every day produces red crosses for every CP or RP trust that is configured with a metadata URL and also configured to monitor and update

–

In the ADFS GUI you will most likely see the following error…

Figure 1: Error When Adding Or Updating A CP/RP Trust Through The GUI In Windows Server 2016

–

Error Message: Method not found: ‘Microsoft.IdentityModel.Protocols.WSFederation.Metadata.MetadataBase Microsoft.IdentityModel.Protocols.WSFederation.Metadata.MetadataSerializer.ReadMetadata(System.IO.Stream)’

–

In the ADFS Admin Event Log you will most likely see the following error for every CP/RP trust that is configured with a metadata URL and also configured to monitor and update…

Figure 2: Error In The Event Log When The Trust Monitoring Cycle Runs In Windows Server 2016

–

The Federation Service encountered an error while retrieving the federation metadata document from ‘https://signin.aws.amazon.com/static/saml-metadata.xml’. The monitoring for the following trusts failed:

Claims providers:

Relying parties:
Amazon Federation Web Services (UNUSED)

Additional Data

Exception details:
Method not found: ‘Microsoft.IdentityModel.Protocols.WSFederation.Metadata.MetadataBase Microsoft.IdentityModel.Protocols.WSFederation.Metadata.MetadataSerializer.ReadMetadata(System.Xml.XmlReader)’.

Additional details:

User Action
Make sure federation metadata URL is accessible.
Verify your proxy server setting. For more information about how to verify your proxy server setting, see the AD FS Troubleshooting Guide (http://go.microsoft.com/fwlink/?LinkId=182180).

–

In the ADFS GUI you will most likely see a lot of red crosses for all those CP and RP trusts that are configured with a metadata URL and are also configured to monitor and update. Opening the properties of one of the federation trusts reveals the following message at the bottom:

The relying party is out of date due to monitoring errors. Please check the event log for details

–

So how the solve this? Apparently something is broken and Microsoft will most likely fix it in a next update. But until that update you have the following solution: Use PowerShell!

–

To add a Claims Aware RP Trust through PowerShell that leverages a metadata URL

$metadataURL = "<REPLACE THIS WITH THE ACTUAL METADATA URL>"

Add-AdfsRelyingPartyTrust -Name $rpTrustName -MetadataUrl $metadataURL -AutoUpdateEnabled $true -MonitoringEnabled $true -Enabled $true

….then use “Set-AdfsRelyingPartyTrust” with any parameter to configure whatever you need to configure

–

To update a Claims Aware RP Trust through PowerShell that leverages a metadata URL

Get-AdfsRelyingPartyTrust | ?{$_.Enabled -eq "True" -And $_.MetadataUrl} | %{
    Write-Host ""
    Write-Host "Updating The Metadata For….: $($_.Name)"
    Write-Host ""
    Update-AdfsRelyingPartyTrust -TargetName $($_.Name)
}

–

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/ ########
———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Federation Metadata, Federation Trusts | Leave a Comment »

(2015-10-12) Configuring System Wide Proxy Settings For ADFS To Use

Posted by Jorge on 2015-10-12

So your ADFS server requires access to the internet, what do you do? In general there are 2 options to get this done, being either directly bypassing any proxy or strait through the proxy. However, how do you tell ADFS to use a proxy?

–

Let’s first think why you would have your ADFS servers accessing the internet.

First of all, when you have a federation trust setup with a cloud-based system/application (e.g. Azure AD, Amazon Federation Web Services, etc.) that supports and publishes federation metadata, you of course want your ADFS servers to consume that federation metadata automatically, saving you manual work. This really helps you when a federation partner updates it’s Token Signing certificates when the old certificates are due to expire.

Figure 1: The Federation Metadata URL For “Microsoft Azure Active Directory”

–

Figure 2: The Federation Metadata URL For “Amazon Federation Web Services”

–

The second and last reason is to be able to perform certificate chain validation and checking the revocation status of the certificate. This of course applies to any certificate issued by a certificate authority. More information about this can be found in (2015-10-10) Certificate Chain Validation And Revocation Status Checking In ADFS.

When performing certificate chain validation of an external third-party certificate, access to the internet is required if the certificates of the root and/or the intermediate CA are not installed in the LocalMachine store.

To be able to check for the revocation status of an external third-party certificate, access to the CRL distribution points is required.

–

So you know understand why you need internet access, but the question still remains: “How will you achieve this?”

–

Achieving this by allowing the ADFS servers to bypass any proxy is the easiest way as you do not have to configure anything on the ADFS servers and you do not need to configure anything network related in addition. A huge downside is that there is no control who is accessing what on the internet. An ADFS server, which can be compared to a writeable domain controller, might misused to access compromsied web sites.

A better way is to allow access to the internet through a proxy server. This helps you to tailor what you allow to be accessed and what you do not allow to be accessed on the internet from the ADFS servers. With the knowledge of what needs to be accessible by the ADFS servers you can now configure the proxy server to only allow that. Adjustments are needed if you are federating with a new partner that publishes federation metadata or a federation partner uses a third-party certificate from a third-party CA you do not yet trust. Of course cleanup is also required if for example a federation trust is decommissioned. When configuring the proxy server prevent configuring proxy server rules through the IPs of the targeted servers on the internet. As you do not have control on what a federation partner or a certificate issuer does, which regards to IP addressing, it is not recommended to use that. I prefer to allow access based upon the hostnames, or even just domains, used in the federation metadata URL, the AIA extension URLs and the CDP extension URLs, as that is most likely not to change.

The information below applies to ADFS v2.x and higher!

–

To check the current status of the system wide proxy settings execute the following command:

NETSH WINHTTP SHOW PROXY

If you had not configured any proxy server, the output is shown below

Figure 3: No Proxy Server Defined On The System Wide Proxy Settings

–

In my test environment:

Proxy Server FQDN = GATEWAY.IAMTEC.NET
Proxy Server Port = 3128
Do not use the proxy server for the following addresses that are also available internally:

*.IAMTEC.NET <== FQDN of the internal AD domain
*.IAMTEC.NL <== FQDN of the internet domain, that’s also available internally (split DNS)
*.PARTNER.LAN <== FQDN of the internal AD domain of a sister company for which a direct connection exists
<Local Addresses> <== This only applies to NetBIOS name style addresses, and not (local) FQDNs!

–

To configure this you the following command as specified:

NETSH WINHTTP SET PROXY PROXY-SERVER="GATEWAY.IAMTEC.NET:3128" BYPASS-LIST="*.iamtec.net;*.iamtec.nl;*.partner.lan;<local>"

REMARK: “<local>” only covers NetBIOS name style addresses, and NOT FQDNs. Therefore, any FQDN needs to be explicitly specified or be covered by some wildcard FQDN. (see: MS-KBQ262981)

Figure 4: Setting Proxy Server FQDN, Port and Bypass List

–

If you ever need to remove the configured proxy settings, execute the following command:

NETSH WINHTTP RESET PROXY

Figure 5: Clearing/Removing Any Configured Proxy Settings

–

So, after configuring the proxy settings as shown in figure 4, you need to make ADFS aware of those new settings. The configuration needs to be done on every ADFS STS server, and it is activated by just restarting the ADFS service:

NET STOP ADFSSRV

NET START ADFSSRV

or if you are a PowerShell geek

Restart-Service ADFSSRV

Now, when you have a look in the ADFS Admins Event Log you will find the following event ID, which tells you that ADFS has picked up the new proxy settings

Figure 6: ADFS Loading The HTTP Proxy Configuration From WinHTTP

–

By default, ADFS starts the trust monitoring cycle every 24 hours (1440 minutes). When you check the ADFS Properties (Get-ADFSProperties), you will most likely see (if you did not change it!) that the “MonitoringInterval” property is configured with the value 1440. If you temporarily lower that value to, let’s say, 1 minute, you can actively see if the configured proxy settings are working and if ADFS is able to pass through the proxy.

To lower the Trust Monitoring Cycle to 1 minute, execute the following command on the (primary) ADFS server:

Set-AdfsProperties -MonitoringInterval 1

When ADFS initiates the trust monitoring cycle, you will see the following event ID.

Figure 7: ADFS Initiated The Trust Monitoring Cycle

–

When ADFS completes the trust monitoring cycle, you will see the following event ID.

Figure 8: ADFS Completed The Trust Monitoring Cycle

–

Somewhere between those 2 event IDs you may find event IDs, but that depends if it was successful or not. If a specific federation trust is configured with a federation metadata URL and at least monitoring is enabled, you will not find any event ID if the monitoring was successful for that federation trust. However, if for some reason the monitoring was not successful for a specific federation trust, you will find the following event ID stating that monitoring failed.

Figure 9: Failed Trust Monitoring For A Federation Trust

–

Of course you want to confirm it is actually been monitored successful. Therefore, to figure out, if monitoring is successful or not, you can use the following PowerShell command:

For CP Trusts: Get-AdfsClaimsProviderTrust | ?{$_.Enabled -eq $true -And $_.MetadataUrl -ne $null -And $_.MonitoringEnabled -eq $true} | %{"`nName………………: "+$_.Name+"`nLastMonitoredTime…..: "+$_.LastMonitoredTime+"`nLastUpdateTime……..: "+$_.LastUpdateTime}

For RP Trusts: Get-ADFSRelyingPartyTrust | ?{$_.Enabled -eq $true -And $_.MetadataUrl -ne $null -And $_.MonitoringEnabled -eq $true} | %{"`nName………………: "+$_.Name+"`nLastMonitoredTime…..: "+$_.LastMonitoredTime+"`nLastUpdateTime……..: "+$_.LastUpdateTime}

Figure 9: Retrieving ‘Last Monitored Time’ And ‘Last Update Time’ For Every Applicable Federation Trust

–

Be aware, that the ‘LastMonitoredTime’ is updated, whether or not the monitoring was successful. Therefore, if you see an updated ‘LastMonitoredTime’ and no event ID exist for that specific federation trust (as shown in picture 9), you can be sure that access through the proxy using the configured proxy settings is successful!

Remember that the ‘LastUpdateTime’ will only be updated, if there is something new to update!

–

Now, when you have finished testing, make sure to reconfigure the monitoring interval back to its original value (or the value you had configured)

Set-AdfsProperties -MonitoringInterval 1440

–

Posted in Active Directory Federation Services (ADFS), Certificates, Federation Metadata, Federation Trusts, System Wide Proxy Settings | 1 Comment »

(2014-10-01) TroubleShooting Federation/SSO To Windows Azure AD And Office 365

Posted by Jorge on 2014-10-01

When setting up DirSync And Federation between your on-premise AD and Windows Azure AD to support identity sync and SSO, the most important attribute to make sure everything works are the immutableID and the userPrincipalName.

–

Paul Williams from msresource.net has written a great number of blog posts about this, touching all kinds of related stuff. See the following blog posts:

–

With regards to the implementation I used the string version of the objectGUID (AD) as the immutableID (sourceAnchor in AAD)) and the UPN as the userPrincipalName (AAD). I achieved that by leveraging FIM with the AAD connector. Because of that I also had to implement slighty different claims rules in ADFS for Azure AD/Office 365. The rules in my ADFS v2.0 looked like:

@RuleName = "Identity Claims – objectGUID (Base64) To objectGUID (String)"
c:[Type == "http://temp.org/identity/claims/adObjectGuidBase64org"]
=> add(store = "String Processing Store", types = ("http://temp.org/identity/claims/adObjectGuidString"), query = "fromBase64GuidtoStringGuid", param = c.Value);

@RuleName = "Identity Claims – upn To UPN"
c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
=> issue(Type = "http://schemas.xmlsoap.org/claims/UPN", Value = c.Value);

@RuleName = "Identity Claims – objectGUID (String) To ImmutableID"
c:[Type == "http://temp.org/identity/claims/adObjectGuidString"]
=> issue(Type = "http://schemas.microsoft.com/LiveID/Federation/2008/05/ImmutableID", Issuer = c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType = c.ValueType);

@RuleName = "Identity Claims – ImmutableID To Name ID"
c:[Type == "http://schemas.xmlsoap.org/claims/UPN"]
=> 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:1.1:nameid-format:unspecified");

–

I swear everything was working, until some day I started to get the following errors:

….when navigating to: https://outlook.office365.com/owa/

Figure 1: Error When Using Federated Logon And Navigating To Office 365 Portal

–

….when navigating to: https://manage.windowsazure.com/default.aspx

Figure 2: Error When Using Federated Logon And Navigating To Azure AD Management Portal

–

….when navigating to: https://portal.office.com/

Figure 3: Error When Using Federated Logon And Navigating To Office 365 Management Portal

–

By giving the correlation ID to someone at Microsoft that is able to check it in the system logs, they most likely will be able to tell you what would be wrong. In this case unfortunately I as not able to do that. The logs on my system did not given me any clue!

As I have another ADFS v3.0 system in my environment, I therefore decided to configure that ADFS instance with all default values for DirSync and federation. After configuring all this, I was able to access Azure AD and Office 365 through federated logon on my ADFS v3.0 box, but still not on my ADFS v2.0.

–

After comparing the federation trusts between ADFS v2.0 and Azure AD, and between ADFS v3.0 and Azure AD I saw the following difference:

Figure 4: Signature Hash Algorithm On The RP Trust On ADFS v3.0 For Azure AD/Office 365 (Default Config) – WORKING

–

Figure 5: Signature Hash Algorithm On The RP Trust On ADFS v2.0 For Azure AD/Office 365 (Custom Config) – NOT WORKING

–

For whatever reason, in the past I had changed the signature hash algorithm on the RP Trust On ADFS v2.0 For Azure AD/Office 365 AND I had forgotten about it. It took me some time to find this one, but by just changing the signature hash algorithm on the RP Trust On ADFS v2.0 For Azure AD/Office 365 from SHA-256 to SHA-1, everything started to work again! Yiiihhaaaaaa!

–

PS: this has NOTHING to do between the usage of ADFS v2.0 and ADFS v3.0. This was a configuration mistaken I made when playing around in the test/demo environment

–

Posted in Active Directory Federation Services (ADFS), Azure AD Sync, DirSync, DirSync, Federation Trusts, Office 365, SSO, Transform Rules, Windows Azure Active Directory | 1 Comment »

(2014-03-12) Additional PowerShell Scripts For Migrating ADFS v2.x To ADFS v3.0

Posted by Jorge on 2014-03-12

In this article Microsoft explains how to migrate from ADFS v2.x to ADFS v3.0. In this blog post I have added multiple PowerShell scripts to help you migrate as automated as possible.

–

!!! DISCLAIMER/REMARKS !!!

These scripts are freeware, you are free to distribute it, but always refer to this website (https://jorgequestforknowledge.wordpress.com/) as the location where you got it
These scripts are furnished "AS IS". No warranty is expressed or implied!
Always test first in lab environment to see if it meets your needs!
Use these scripts at your own risk!
I do not warrant these scripts to be fit for any purpose, use or environment
I have tried to check everything that needed to be checked, but I do not guarantee these scripts do not have bugs.
I do not guarantee these scripts will not damage or destroy your system(s), environment or whatever.
I do not accept any liability in any way if you screw up, use the scripts wrong or in any other way where damage is caused to your environment/systems!
If you do not accept these terms do not use the scripts and delete it immediately!

!!! DISCLAIMER/REMARKS !!!

–

All scripts can also be downloaded from here.

+++++++++++++++++++++++++++++++++
++++++++++++++ PREPARE ++++++++++
+++++++++++++++++++++++++++++++++

# +++[P1]+++ Create Migration Folders
#SCRIPT NAME --> "C:\TEMP\Create-Folders.ps1"
New-Item "C:\ADFS-MIG" -ItemType Directory
New-Item "C:\ADFS-MIG\Config" -ItemType Directory
New-Item "C:\ADFS-MIG\Export" -ItemType Directory
New-Item "C:\ADFS-MIG\Service" -ItemType Directory
New-Item "C:\ADFS-MIG\Web" -ItemType Directory

–

++++++++++++++++++++++++++++++++

++++++++++++ EXPORT ++++++++++++

++++++++++++++++++++++++++++++++

# +++[E1]+++ Output Federation Service Properties (On ADFS STS Only!)
#SCRIPT NAME --> "C:\ADFS-MIG\Output-Federation-Service-Properties.ps1"
If (Test-Path -Path "C:\Program Files\Active Directory Federation Services 2.0\Microsoft.IdentityServer.Servicehost.exe.config") {
    Add-PSSnapIn Microsoft.ADFS.PowerShell
}
If (Test-Path -Path "C:\Windows\ADFS\Microsoft.IdentityServer.Servicehost.exe.config") {
    Import-Module ADFS
}
# Record ADFS Service Properties
Get-Service -Name ADFSSRV | Select * | Out-File C:\ADFS-MIG\Config\ADFSService.txt
Get-WmiObject win32_service | ?{$_.name -eq "ADFSSRV"} | Select * | Out-File C:\ADFS-MIG\Config\ADFSService.txt -Append
# Record All ADFS Properties
Get-ADFSProperties | Out-File C:\ADFS-MIG\Config\ADFSProperties.txt
# Record All ADFS Endpoints
Get-ADFSEndpoint | Out-File C:\ADFS-MIG\Config\ADFSEndpoint.txt
# Record All ADFS Claim Descriptions
Get-ADFSClaimDescription | Out-File C:\ADFS-MIG\Config\ADFSClaimDescription.txt
# Record All ADFS Certificates
Get-ADFSCertificate | Out-File C:\ADFS-MIG\Config\ADFSCertificate.txt
# Record All ADFS Claims Provider Trusts
Get-ADFSClaimsProviderTrust | Out-File C:\ADFS-MIG\Config\ADFSClaimsProviderTrust.txt
# Record All ADFS Relying Party Trusts
Get-ADFSRelyingPartyTrust | Out-File C:\ADFS-MIG\Config\ADFSRelyingPartyTrust.txt
# Record All ADFS Attribute Stores
Get-ADFSAttributeStore | %{
    "##########" | Out-File C:\ADFS-MIG\Config\ADFSAttributeStore.txt -Append
    "Store Name. = " + $_.Name | Out-File C:\ADFS-MIG\Config\ADFSAttributeStore.txt -Append
    "Store Class = " + $_.StoreTypeQualifiedName | Out-File C:\ADFS-MIG\Config\ADFSAttributeStore.txt -Append
    "Store Config:" | Out-File C:\ADFS-MIG\Config\ADFSAttributeStore.txt -Append
    $_.Configuration.GetEnumerator() | %{
        "  * " + $_.Name + " = " + $_.Value | Out-File C:\ADFS-MIG\Config\ADFSAttributeStore.txt -Append
    }
    "" | Out-File C:\ADFS-MIG\Config\ADFSAttributeStore.txt -Append
}

–

# +++[E2]+++ Export ANY CA Issued Certificate In Use By ADFS (On ADFS STS Only!)
#SCRIPT NAME --> "C:\ADFS-MIG\Export-CA-Issued-Certificates-To-CER-And-PFX-From-ADFS-STS.ps1"
$privateKeyProtectionPWD1 = Read-Host "Please Specify The Password To Protect The Private Keys..."
$privateKeyProtectionPWD2 = Read-Host "Please Re-Type The Password To Protect The Private Keys..."
If ($privateKeyProtectionPWD1 -ne $privateKeyProtectionPWD2) {
    Write-Host "Passwords DO NOT Match..."
    Write-Host "Aborting..."
    BREAK
} Else {
    $certype = [System.Security.Cryptography.X509Certificates.X509ContentType]::pfx
    $ADFSCertificates = Get-ADFSCertificate
    $adfsSvcCommCert = $ADFSCertificates | ?{$_.CertificateType -eq "Service-Communications" -And $_.StoreLocation -eq "LocalMachine"}
    If (($adfsSvcCommCert | Measure-Object).Count -eq 1) {
        $adfsSvcCommCertThumbprint = $adfsSvcCommCert.Certificate.Thumbprint
        $adfsSvcCommCertName = "ADFS Service Communication Cert (STS)"

        $adfsSvcCommCertInLocalStore = Get-ChildItem -path cert:\LocalMachine\My | ?{$_.Thumbprint -eq $adfsSvcCommCertThumbprint}
        If ($adfsSvcCommCertInLocalStore.HasPrivateKey -eq $true -And $adfsSvcCommCertInLocalStore.PrivateKey.CspKeyContainerInfo.Exportable -eq $true) {
            $adfsSvcCommCertBytesCER = $adfsSvcCommCertInLocalStore.export("Cert")
            [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsSvcCommCertName + ".cer"), $adfsSvcCommCertBytesCER)
            $adfsSvcCommCertBytesPFX = $adfsSvcCommCertInLocalStore.export($certype, $privateKeyProtectionPWD1)
            [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsSvcCommCertName + ".pfx"), $adfsSvcCommCertBytesPFX)
        }
    }
    
    $adfsTokenSignCert = $ADFSCertificates | ?{$_.CertificateType -eq "Token-Signing" -And $_.StoreLocation -eq "LocalMachine"}
    If (($adfsTokenSignCert | Measure-Object).Count -ge 1) {
        $i = 1
        $adfsTokenSignCert | %{
            $adfsTokenSignCertThumbprint = $_.Certificate.Thumbprint
            $adfsTokenSignCertName = "ADFS Token Signing Cert (STS) (" + $i + ")"

            $adfsTokenSignCertInLocalStore = Get-ChildItem -path cert:\LocalMachine\My | ?{$_.Thumbprint -eq $adfsTokenSignCertThumbprint}
            If ($adfsTokenSignCertInLocalStore.HasPrivateKey -eq $true -And $adfsTokenSignCertInLocalStore.PrivateKey.CspKeyContainerInfo.Exportable -eq $true) {
                $adfsTokenSignCertBytesCER = $adfsTokenSignCertInLocalStore.export("Cert")
                [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsTokenSignCertName + ".cer"), $adfsTokenSignCertBytesCER)
                $adfsTokenSignCertBytesPFX = $adfsTokenSignCertInLocalStore.export($certype, $privateKeyProtectionPWD1)
                [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsTokenSignCertName + ".pfx"), $adfsTokenSignCertBytesPFX)
            }
            $i += 1
        }
    }

    $adfsTokenEncryptCert = $ADFSCertificates | ?{$_.CertificateType -eq "Token-Decrypting" -And $_.StoreLocation -eq "LocalMachine"}
    If (($adfsTokenEncryptCert | Measure-Object).Count -ge 1) {
        $j = 1
        $adfsTokenEncryptCert | %{
            $adfsTokenEncryptCertThumbprint = $_.Certificate.Thumbprint
            $adfsTokenEncryptCertName = "ADFS Token Encryption Cert (STS) (" + $j + ")"

            $adfsTokenEncryptCertInLocalStore = Get-ChildItem -path cert:\LocalMachine\My | ?{$_.Thumbprint -eq $adfsTokenEncryptCertThumbprint}
            If ($adfsTokenEncryptCertInLocalStore.HasPrivateKey -eq $true -And $adfsTokenEncryptCertInLocalStore.PrivateKey.CspKeyContainerInfo.Exportable -eq $true) {
                $adfsTokenEncryptCertBytesCER = $adfsTokenEncryptCertInLocalStore.export("Cert")
                [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsTokenEncryptCertName + ".cer"), $adfsTokenEncryptCertBytesCER)
                $adfsTokenEncryptCertBytesPFX = $adfsTokenEncryptCertInLocalStore.export($certype, $privateKeyProtectionPWD1)
                [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsTokenEncryptCertName + ".pfx"), $adfsTokenEncryptCertBytesPFX)
            }
            $j += 1
        }
    }
}

–

# +++[E3]+++ Export The ADFS v2.x Configuration To XML Files (On ADFS STS Only!)
#Get PoSH Script From W2K12R2 Media (Folder: <CD>\Support\Adfs) Or Folder C:\Windows\Adfs After Installation ADFS Role
#Copy Script To Folder "C:\ADFS-MIG" On Source ADFS Server
C:\ADFS-MIG\Export-FederationConfiguration.ps1 -Path C:\ADFS-MIG\Export

–

# +++[E4]+++ Copy The ADFS v2.x Web Configuration Files (On ADFS STS And ADFS Proxy!)
#SCRIPT NAME --> "C:\ADFS-MIG\Copy-ADFS-Web-Server-Configuration-Files.ps1"
Import-Module WebAdministration
$adfsWebPath = (Get-WebApplication "adfs/ls").PhysicalPath
Copy-Item $($adfsWebPath + "\*") "C:\ADFS-MIG\Web" -Recurse

–

# +++[E5]+++ Copy The ADFS v2.x Service Configuration Files (On ADFS STS And ADFS Proxy!)
#SCRIPT NAME --> "C:\ADFS-MIG\Copy-ADFS-Web-Service-Configuration-File.ps1"
If (Test-Path -Path "C:\Program Files\Active Directory Federation Services 2.0\Microsoft.IdentityServer.Servicehost.exe.config") {
    Copy-Item "C:\Program Files\Active Directory Federation Services 2.0\*") "C:\ADFS-MIG\Service" -Recurse
}
If (Test-Path -Path "C:\Windows\ADFS\Microsoft.IdentityServer.Servicehost.exe.config") {
    Copy-Item "C:\Windows\ADFS\*") "C:\ADFS-MIG\Service" -Recurse
}

–

# +++[E6]+++ Export ANY CA Issued Certificate In Use By ADFS (On ADFS Proxy Only!)
#SCRIPT NAME --> "C:\ADFS-MIG\Export-CA-Issued-Certificates-To-CER-And-PFX-From-ADFS-PRX.ps1"
$privateKeyProtectionPWD1 = Read-Host "Please Specify The Password To Protect The Private Keys..."
$privateKeyProtectionPWD2 = Read-Host "Please Re-Type The Password To Protect The Private Keys..."
If ($privateKeyProtectionPWD1 -ne $privateKeyProtectionPWD2) {
    Write-Host "Passwords DO NOT Match..."
    Write-Host "Aborting..."
    BREAK
} Else {
    $certype = [System.Security.Cryptography.X509Certificates.X509ContentType]::pfx
    $adfsSvcCommCertThumbprint = (Get-WebBinding "Default Web Site" -protocol https).certificateHash
    $adfsSvcCommCertName = "ADFS Service Communication Cert (PRX)"
    $adfsSvcCommCertInLocalStore = Get-ChildItem -path cert:\LocalMachine\My | ?{$_.Thumbprint -eq $adfsSvcCommCertThumbprint}
    If ($adfsSvcCommCertInLocalStore.HasPrivateKey -eq $true -And $adfsSvcCommCertInLocalStore.PrivateKey.CspKeyContainerInfo.Exportable -eq $true) {
        $adfsSvcCommCertBytesCER = $adfsSvcCommCertInLocalStore.export("Cert")
        [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsSvcCommCertName + ".cer"), $adfsSvcCommCertBytesCER)
        $adfsSvcCommCertBytesPFX = $adfsSvcCommCertInLocalStore.export($certype, $privateKeyProtectionPWD1)
        [system.IO.file]::WriteAllBytes($("C:\ADFS-MIG\Config\" + $adfsSvcCommCertName + ".pfx"), $adfsSvcCommCertBytesPFX)
    }
}

–

+++++++++++++++++++++++++++++++++++++++++++++++++++

++++++++++++ CREATE/JOIN/CONFIGURE ADFS ++++++++++++

+++++++++++++++++++++++++++++++++++++++++++++++++++

# +++[C1]+++ Create ADFS Farm Using WID And ADFS Managed Self-Signed Certificates
#SCRIPT NAME --> "C:\ADFS-MIG\Create-ADFS-Farm-WID-Self-Signed-Certs.ps1"
$adfsSvcFQDN = Read-Host "Please Specify The FQDN Of The Federation Service..."
$adfsSvcName = Read-Host "Please Specify The Display Name Of The Federation Service..."
$adfsSvcCreds = Get-Credential
Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap
$adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate"
Add-WindowsFeature ADFS-Federation
Install-AdfsFarm -OverwriteConfiguration:$true -FederationServiceName $adfsSvcFQDN -FederationServiceDisplayName $adfsSvcName -ServiceAccountCredential $adfsSvcCreds -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

–

# +++[C2]+++ Create ADFS Farm Using WID And CA Issued Certificates
#SCRIPT NAME --> "C:\ADFS-MIG\Create-ADFS-Farm-WID-CA-Issued-Certs.ps1"
$adfsSvcFQDN = Read-Host "Please Specify The FQDN Of The Federation Service..."
$adfsSvcName = Read-Host "Please Specify The Display Name Of The Federation Service..."
$adfsSvcCreds = Get-Credential
Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap
$adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate"
Add-WindowsFeature ADFS-Federation
Install-AdfsFarm -OverwriteConfiguration:$true -FederationServiceName $adfsSvcFQDN -FederationServiceDisplayName $adfsSvcName -ServiceAccountCredential $adfsSvcCreds -CertificateThumbprint $adfsSvcCommCertThumbprint -SigningCertificateThumbprint $adfsTokenSignCertThumbprint -DecryptionCertificateThumbprint $adfsTokenEncryptCertThumbprint | FL

–

# +++[C3]+++ Create ADFS Farm Using SQL And ADFS Managed Self-Signed Certificates
#SCRIPT NAME --> "C:\ADFS-MIG\Create-ADFS-Farm-SQL-Self-Signed-Certs.ps1"
$adfsSvcFQDN = Read-Host "Please Specify The FQDN Of The Federation Service..."
$adfsSvcName = Read-Host "Please Specify The Display Name Of The Federation Service..."
$adfsSvcCreds = Get-Credential
$sqlServerInstance = Read-Host "Please Specify The FQDN Of The SQL Server And SQL Instance..."
$sqlConnectionString = "Data Source=$sqlServerInstance;Initial Catalog=AdfsConfiguration;Integrated Security=True"
Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap
$adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate"
Add-WindowsFeature ADFS-Federation
Install-AdfsFarm -OverwriteConfiguration:$true -FederationServiceName $adfsSvcFQDN -FederationServiceDisplayName $adfsSvcName -ServiceAccountCredential $adfsSvcCreds -SQLConnectionString $sqlConnectionString -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

–

# +++[C4]+++ Create ADFS Farm Using SQL And CA Issued Certificates
#SCRIPT NAME --> "C:\ADFS-MIG\Create-ADFS-Farm-SQL-CA-Issued-Certs.ps1"
$adfsSvcFQDN = Read-Host "Please Specify The FQDN Of The Federation Service..."
$adfsSvcName = Read-Host "Please Specify The Display Name Of The Federation Service..."
$adfsSvcCreds = Get-Credential
$sqlServerInstance = Read-Host "Please Specify The FQDN Of The SQL Server And SQL Instance..."
$sqlConnectionString = "Data Source=$sqlServerInstance;Initial Catalog=AdfsConfiguration;Integrated Security=True"
Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap
$adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate"
$adfsTokenSignCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Token Signing Certificate"
$adfsTokenEncryptCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Token Encryption Certificate"
Add-WindowsFeature ADFS-Federation
Install-AdfsFarm -OverwriteConfiguration:$true -FederationServiceName $adfsSvcFQDN -FederationServiceDisplayName $adfsSvcName -ServiceAccountCredential $adfsSvcCreds -SQLConnectionString $sqlConnectionString -CertificateThumbprint $adfsSvcCommCertThumbprint -SigningCertificateThumbprint $adfsTokenSignCertThumbprint -DecryptionCertificateThumbprint $adfsTokenEncryptCertThumbprint | FL

–

# +++[C5]+++ Join ADFS Farm Using WID And ADFS Managed Self-Signed Certificates
#SCRIPT NAME --> "C:\ADFS-MIG\Join-ADFS-Farm-WID-Self-Signed-Certs.ps1"
$adfsSvcCreds = Get-Credential
$adfsPrimaryServer = Read-Host "Please Specify The FQDN Of The Primary Server..."
Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap
$adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate"
Add-WindowsFeature ADFS-Federation
Add-AdfsFarmNode -PrimaryComputerName $adfsPrimaryServer -ServiceAccountCredential $adfsSvcCreds -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

–

# +++[C6]+++ Join ADFS Farm Using WID And CA Issued Certificates
#SCRIPT NAME --> "C:\ADFS-MIG\Join-ADFS-Farm-WID-CA-Issued-Certs.ps1"
$adfsSvcCreds = Get-Credential
$adfsPrimaryServer = Read-Host "Please Specify The FQDN Of The Primary Server..."
Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap
$adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate"
Add-WindowsFeature ADFS-Federation
Add-AdfsFarmNode -PrimaryComputerName $adfsPrimaryServer -ServiceAccountCredential $adfsSvcCreds -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

–

# +++[C7]+++ Join ADFS Farm Using SQL And ADFS Managed Self-Signed Certificates
#SCRIPT NAME --> "C:\ADFS-MIG\Join-ADFS-Farm-SQL-Self-Signed-Certs.ps1"
$adfsSvcCreds = Get-Credential
$sqlServerInstance = Read-Host "Please Specify The FQDN Of The SQL Server And SQL Instance..."
$sqlConnectionString = "Data Source=$sqlServerInstance;Initial Catalog=AdfsConfiguration;Integrated Security=True"
Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap
$adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate"
Add-WindowsFeature ADFS-Federation
Add-AdfsFarmNode -SQLConnectionString $sqlConnectionString -ServiceAccountCredential $adfsSvcCreds -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

–

# +++[C8]+++ Join ADFS Farm Using SQL And CA Issued Certificates
#SCRIPT NAME --> "C:\ADFS-MIG\Join-ADFS-Farm-SQL-CA-Issued-Certs.ps1"
$adfsSvcCreds = Get-Credential
$sqlServerInstance = Read-Host "Please Specify The FQDN Of The SQL Server And SQL Instance..."
$sqlConnectionString = "Data Source=$sqlServerInstance;Initial Catalog=AdfsConfiguration;Integrated Security=True"
Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap
$adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate"
Add-WindowsFeature ADFS-Federation
Add-AdfsFarmNode -SQLConnectionString $sqlConnectionString -ServiceAccountCredential $adfsSvcCreds -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

–

# +++[C9]+++ Install And Configure Web Application Proxy
#SCRIPT NAME --> "C:\ADFS-MIG\Install-And-Configure-Web-Application-Proxy.ps1"
Add-WindowsFeature Web-Application-Proxy -IncludeManagementTools
$adfsSvcFQDN = Read-Host "Please Specify The FQDN Of The Federation Service..."
$adfsAdminCreds = Get-Credential
Get-ChildItem -path cert:\LocalMachine\My | FT Thumbprint,Subject,FriendlyName -Autosize -Wrap
$adfsSvcCommCertThumbprint = Read-Host "Please Specify The Thumbprint Of The Service Communication Certificate"
Install-WebApplicationProxy -FederationServiceName $adfsSvcFQDN -FederationServiceTrustCredential $adfsAdminCreds -CertificateThumbprint $adfsSvcCommCertThumbprint | FL

–

# +++[C10]+++ Add/Publish Web Applications Through Web Application Proxy
Get-WebApplicationProxyApplication --> http://technet.microsoft.com/en-us/library/dn283413.aspx
Get-WebApplicationProxyAvailableADFSRelyingParty --> http://technet.microsoft.com/en-us/library/dn283412.aspx
Add-WebApplicationProxyApplication --> http://technet.microsoft.com/en-us/library/dn283409.aspx

–

++++++++++++++++++++++++++++++++

++++++++++++ IMPORT ++++++++++++

++++++++++++++++++++++++++++++++

# +++[I1]+++ Import ANY CA Issued Certificate In Use By ADFS (On ADFS STS Only!) (Only Works On W2K12R2!!!)
#SCRIPT NAME --> "C:\ADFS-MIG\Import-CA-Issued-Certificates-Into-ADFS-STS-Local-Cert-Store.ps1"
$privateKeyProtectionPWD = ConvertTo-SecureString -String $(Read-Host "Please Specify The Password Protecting The Private Keys...") -Force –AsPlainText
$adfsSvcCommCertPFXFile = Get-ChildItem -Path 'C:\ADFS-MIG\Config' -Filter 'ADFS Service Communication Cert (STS).pfx'
If (($adfsSvcCommCertPFXFile | Measure-Object).Count -ge 1) {
    Import-PfxCertificate -FilePath $($adfsSvcCommCertPFXFile.FullName) -CertStoreLocation 'cert:\localMachine\my' –Exportable -Password $privateKeyProtectionPWD
}
$adfsTokenSignCertPFXFile = Get-ChildItem -Path 'C:\ADFS-MIG\Config' -Filter 'ADFS Token Signing Cert (STS)*.pfx'
If (($adfsTokenSignCertPFXFile | Measure-Object).Count -ge 1) {
    $adfsTokenSignCertPFXFile | %{Import-PfxCertificate -FilePath $($_.FullName) -CertStoreLocation 'cert:\localMachine\my' –Exportable -Password $privateKeyProtectionPWD}
}
$adfsTokenEncryptCertPFXFile = Get-ChildItem -Path 'C:\ADFS-MIG\Config' -Filter 'ADFS Token Encryption Cert (STS)*.pfx'
If (($adfsTokenEncryptCertPFXFile | Measure-Object).Count -ge 1) {
    $adfsTokenEncryptCertPFXFile | %{Import-PfxCertificate $($_.FullName) -CertStoreLocation 'cert:\localMachine\my' –Exportable -Password $privateKeyProtectionPWD}
}

–

# +++[I2]+++ Import The ADFS v2.x Configuration From The XML Files Into ADFS v3.0
#Get PoSH Script From W2K12R2 Media (Folder: <CD>\Support\Adfs) Or Folder C:\Windows\Adfs After Installation ADFS Role
#Copy Script To Folder "C:\ADFS-MIG" On Source ADFS Server
C:\ADFS-MIG\Import-FederationConfiguration.ps1 -Path C:\ADFS-MIG\Export

–

# +++[I3]+++ Import ANY CA Issued Certificate In Use By ADFS (On ADFS Proxy/WAP Only!) (Only Works On W2K12R2!!!)
#SCRIPT NAME --> "C:\ADFS-MIG\Import-CA-Issued-Certificates-Into-ADFS-PRX-Local-Cert-Store.ps1"
$privateKeyProtectionPWD = ConvertTo-SecureString -String $(Read-Host "Please Specify The Password Protecting The Private Keys...") -Force –AsPlainText
$adfsSvcCommCertPFXFile = Get-ChildItem -Path 'C:\ADFS-MIG\Config' -Filter 'ADFS Service Communication Cert (PRX).pfx'
If (($adfsSvcCommCertPFXFile | Measure-Object).Count -ge 1) {
    Import-PfxCertificate -FilePath $($adfsSvcCommCertPFXFile.FullName) -CertStoreLocation 'cert:\localMachine\my' –Exportable -Password $privateKeyProtectionPWD
}

–

A while back I also found a blog post with PowerShell script to quickly deploy both ADFS v3.0 and WAP. You can find that blog post here.

–

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/ ########

———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Certificates, Farm, Federation Trusts, Migration, Proxy Service, Security Token Service (STS) | 6 Comments »

(2014-02-10) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v3.0 (Update 1)

Posted by Jorge on 2014-02-10

In this blog post I wrote and concluded about the bare minimum acceptance transform rules for the default claims provider trust (Active Directory) in ADFS v3.0 (or ADFS 2012 R2). What I wrote is still correct, however, unfortunately the final conclusion is inaccurate. I do not understand what went wrong when I tested that. While both ADFS v2.0 and ADFS v2.1, at a minimum require the "Primary SID" claim, ADFS v3.0 does not only require the "Windows Account Name" claim as I stated in the previous post. It requires an additional claim, being the "UPN" claim, at a minimum. Continue reading to understand and see what goes wrong if any of the two required claims is missing.

–

To enable debug tracing, before trying this yourself see: (2014-02-05) Enabling Debug Tracing In ADFS v2.1 and v3.0

–

If you only have the following claims rule in the acceptance transform rules list of the Active Directory CP trust…

Figure 1: Only Using The Claims Rules For The "Windows Account Name" Claim

–

…and you access, for example, https://<FQDN Federation Service>/adfs/ls/IdPInitiatedSignOn, you will an error similar to the one below

Figure 2: The ADFS Error Page

–

Looking at the ADFS Admin Event Log you will something similar to the figure below.. Pay specific attention to the text "ID4250: The ClaimValue cannot be null". That means, the "UPN" claim is missing or does not have a value.

Figure 3: The Error "System.IO.InvalidDataException: ID4250: The ClaimValue Cannot Be Null" In The ADFS Admin Event Log

–

Looking at the ADFS Debug Tracing Event Log you will something similar to the figure below. Now it really tells you what’s wrong! Just like I said earlier.

Figure 4: The Error "Unable To Find Upn Claim In The Incoming Identity Or Claim Value Is Empty" In The ADFS Debug Tracing Event Log

–

Looking at the ADFS Debug Tracing Event Log you will something similar to the figure below, which is almost the same error as mentioned earlier.

Figure 5: The Error "Exception: ID4250: The ClaimValue Cannot Be Null" In The ADFS Debug Tracing Event Log

–

You will also see the following error, which is not really helpful.

Figure 6: The Error "Passive Pipeline Error" In The ADFS Debug Tracing Event Log

–

Now, if you only have the following claims rule in the acceptance transform rules list of the Active Directory CP trust…

Figure 7: Only Using The Claims Rules For The "UPN" Claim

–

…and you access, for example, https://<FQDN Federation Service>/adfs/ls/IdPInitiatedSignOn, you will an error similar to the one below

Figure 8: The ADFS Error Page

–

Looking at the ADFS Admin Event Log you will something similar to the figure below.. Pay specific attention to the text "SessionSecurityToken does not contain a single AnchorID claim". That means, the "Windows Account Name" claim is missing or does not have a value.

Figure 9: The Error "SessionSecurityToken Does Not Contain A Single AnchorID Claim" In The ADFS Admin Event Log

–

Looking at the ADFS Debug Tracing Event Log you will something similar to the figure below. It is telling you the same as before without really telling you what is actually wrong.

Figure 10: The Error "SessionSecurityToken Does Not Contain A Single AnchorID Claim" In The ADFS Debug Tracing Event Log

–

You will also see the following error, which is not really helpful.

Figure 11: The Error "Token Is Invalid" In The ADFS Debug Tracing Event Log

–

You will also see the following error, which is not really helpful.

Figure 12: The Error "Exception: MSIS7012: An Error Occurred While Processing The Request" In The ADFS Debug Tracing Event Log

–

You will also see the following error, which is not really helpful.

Figure 13: The Error "Passive Pipeline Error" In The ADFS Debug Tracing Event Log

–

Now, if you have both the following claims rule in the acceptance transform rules list of the Active Directory CP trust…

Figure 14: Only Using The Claims Rules For The The "Windows Account Name" Claim And The "UPN" Claim

–

…and you access, for example, https://<FQDN Federation Service>/adfs/ls/IdPInitiatedSignOn, you will an error similar to the one below

Figure 15: The ADFS SignIn Page

–

Voila it works! Smile

–

Posted in Active Directory Federation Services (ADFS), Claims Rule Language, Federation Trusts, Transform Rules | 4 Comments »

(2013-10-09) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v3.0

Posted by Jorge on 2013-10-09

UPDATE: See a newer and more up-to-date and accurate version of this blog post here.

–

This post is about the bare minimum acceptance transform rules for the default claims provider trust (Active Directory) in ADFS v3.0. To read about the same topic in ADFS v2.0 see the following blog post: (2011-09-13) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v2.0

–

Right after installing ADFS v3.0, by default it will have ONE Claims Provider Trust configuration for AD as the one and only supported authentication store. ADFS v3.0, like ADFS v2.0, does not support any other authentication store besides AD. That Claims Provider Trust will also be configure with a default set of Acceptance Transform Rules as shown below in the picture.

Figure 1: Default List Of Acceptance Transform Rules For The Default Claims Provider Trust (AD) In ADFS v3.0

–

It is of course possible to adjust the default set of Acceptance Transform Rules by removing existing default rules and/or adding your own required rules. Assuming you would do such a thing, you could for example replace the default set of Acceptance Transform Rules, with the Acceptance Transform Rules as shown below. If you look carefully I removed the default Acceptance Transform Rules and put in my own Acceptance Transform Rules.

Figure 2: Custom List Of Acceptance Transform Rules For The Default Claims Provider Trust (AD) In ADFS v3.0

–

If I now try to access a Claims Based SharePoint site that I created and configured on SharePoint 2010, you would see something similar to what you would see below.

–

The default Home Realm Discovery window with the selection list. The logo you see is something that I configured. I get to this screen because I have multiple Claims Provider Trusts configured, one for the default authentication store being AD and one for an IdP-STS at some other organization.

Figure 3: The Default Home Realm Discovery Page In ADFS v3.0 Using A Selection List Of The Configured Claims Provider Trusts (a.k.a. Identity Providers)

–

After selecting the one you see, which represents in this case the Claims Provider Trust for AD, and clicking “Continue To Sign In”, you will see something similar to the sign-in page for which I already filled in some credentials:

Figure 4: The Default Sign-In Web Page For Forms AuthN In ADFS v3.0 To Collect Credentials For Authentication

–

After clicking “Sign In”, you will see something similar to:

Figure 5: Some Error Stating Something Went Wrong

–

After errors like this, the next step is to check the ADFS Event Logs. Let’s try the Admin log first! Note the detailed information!

You should see something similar like:

Event ID 364…

Figure 6: Event ID 364 In the ADFS v3.0 Admin Event Log Stating The Session Security Token Does Not Contain A Single AnchorID Claim

–

Encountered error during federation passive request.

Additional Data

Protocol Name:
wsfed

Relying Party:
urn:app:sharepointclaimsappwap

Exception details:
Microsoft.IdentityServer.RequestFailedException: MSIS7012: An error occurred while processing the request. Contact your administrator for details. —> Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnIdentityInvalidException: SessionSecurityToken does not contain a single AnchorID claim.
   at Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnTokenHelper.ValidateToken(SessionSecurityToken token, SessionSecurityToken currentToken)
   at Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnTokenHelper.AddToken(SessionSecurityToken newToken)
   at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.UpdateSingleSignOnTokenInContext(ProtocolContext context, SecurityToken ssoToken)
   — End of inner exception stack trace —
   at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.UpdateSingleSignOnTokenInContext(ProtocolContext context, SecurityToken ssoToken)
   at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSsoSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken, SecurityToken& ssoSecurityToken)
   at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponseCoreWithSecurityToken(WSFederationSignInContext context, SecurityToken securityToken, SecurityToken deviceSecurityToken)
   at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.BuildSignInResponse(WSFederationSignInContext federationPassiveContext, SecurityToken securityToken, SecurityToken deviceSecurityToken)
   at Microsoft.IdentityServer.Web.Protocols.WSFederation.WSFederationProtocolHandler.Process(ProtocolContext context)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.ProcessProtocolRequest(ProtocolContext protocolContext, PassiveProtocolHandler protocolHandler)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnIdentityInvalidException: SessionSecurityToken does not contain a single AnchorID claim.
   at Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnTokenHelper.ValidateToken(SessionSecurityToken token, SessionSecurityToken currentToken)
   at Microsoft.IdentityServer.Web.SessionTokenManager.SingleSignOnTokenHelper.AddToken(SessionSecurityToken newToken)
   at Microsoft.IdentityServer.Web.Protocols.PassiveProtocolHandler.UpdateSingleSignOnTokenInContext(ProtocolContext context, SecurityToken ssoToken)

–

"Does not contain a single AnchorID claim"????? Oh yeah, wait! In ADFS v2.0 you were required to have the objectSID (a.k.a. the PrimarySID) as the minimum claim. So let’s add that!

Figure 7: Custom List Of Acceptance Transform Rules For The Default Claims Provider Trust (AD) In ADFS v3.0, But NOW With The Primary SID Claim

–

So, let’s try again!

No good, as I got the same error as shown in figure 5 and 6. Hey something changed here!

–

In a previous blog post "(2013-10-07) Restoring The Default Acceptance Transform Rules For The AD CP Trust In ADFS v3.0" I explain how to restore the default list of Acceptance Transform Rules for the default Claims Provider Trust (AD) in ADFS v3.0 if it is broken and you cannot get it to work anymore. It is really easy to “restore” the default list of Acceptance Transform Rules.

–

However, after some testing I found out that ADFS v3.0 requires AT LEAST one identifier claim that allows an authenticated user to request a security token. In ADFS v2.0, the identifier (a.k.a. the AnchorID Claim) was the "Primary SID" claim, but in ADFS v3.0 that was changed to the "Windows Account Name" claim!!!

Figure 8: The Bare Minimum Acceptance Transform Rules List Required For ADFS v3.0 To Issue A Security Token

–

AND…. there must be only one "Windows Account Name" claim. There should NOT be multiple values for that claim, either passing through or extracted by an LDAP query as shown below.

Figure 9: Custom List Of Acceptance Transform Rules For The Default Claims Provider Trust (AD) In ADFS v3.0, But NOW With MULTIPLE "Windows Account Name" Claims

–

If you have multiple "Windows Account Name" claims, which resulted from claims rules as shown in figure 9, it will not work and throw similar errors as shown in figure 5 and 6. Read it carefully, It clearly states: "SessionSecurityToken does not contain a single AnchorID claim". SINGLE, not multiple claims for the AnchorID claim, which is the "Windows Account Name" claim!

–

So in my scenario having the following claims rules worked like a charm!

Figure 10: Combination Of Acceptance Transform Rules From Figure 2 And Figure 8

–

Now trying to access my claims based SharePoint web site again will result in the following:

Figure 11: Successful Access To A Claims Based SharePoint Web Site Hosted SharePoint 2010 That Includes A Custom Web Part To Show The Claims Processed By SharePoint 2010

–

So……to summarize

For even ADFS v3.0 to be able to issue a security token, the Acceptance Transform Rule List Must AT LEAST have the claim rule specified as shown in figure 8! The value for the "Windows Account Name" claim must be in the format <NetBIOS Domain Name>\<sAMAccountName> (e.g. ADCORP\ADM.ROOT) as shown in figure 11. When you upgrade, or better migrate from ADFS v2.0 to ADFS v3.0 you need to be aware of this change!

–

UPDATE: See a newer and more up-to-date and accurate version of this blog post here.

–

Posted in Active Directory Federation Services (ADFS), Claims Rule Language, Federation Trusts, Transform Rules | 2 Comments »

(2013-10-07) Restoring The Default Acceptance Transform Rules For The AD CP Trust In ADFS v3.0

Posted by Jorge on 2013-10-07

In the following post, you can see how to restore the default acceptance transform rules for Active Directory claims provider trust in either ADFS v2.0 (on W2K8 or W2K8R2) or ADFS v2.1 (on W2K12): AD FS 2.0: How to Restore the Default Acceptance Transform Rules for the Active Directory Claims Provider Trust. The only difference between W2K8(R2) and W2K12 is that in W2K8(R2) you need to load a PowerShell snap-in (Add-PSSnapin Microsoft.Adfs.PowerShell) and in W2K12 (and higher) you need to load a PowerShell module (Import-Module ADFS)

–

In this post you can see how to restore the default acceptance transform rules for Active Directory claims provider trust in ADFS v3.0 (on W2K12R2). Has the procedure changed? No not really. Instead of a snap-in you now need to load a module and the default acceptance transform rules have changed a bit. For completeness I have described the procedure in full in this blog post.

–

So if you have modified the default acceptance transform rules for the Active Directory claims provider trust in ADFS v3.0, and you want to restore the defaults you can use this procedure. You need to perform this procedure on an ADFS STS server with write access to the ADFS configuration database. When using SQL you can use any ADFS STS server, but when using WID you must use the primary ADFS STS server.

–

[1] Copy the following text into a file and save that file as C:\TEMP\CP_ActiveDirectory_AcceptanceTransformRules_Default.txt

@RuleTemplate = "PassThroughClaims" 
@RuleName = "Pass through all Windows account name claims" 
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] 
=> issue(claim = c);

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

@RuleTemplate = "PassThroughClaims" 
@RuleName = "Pass through all Primary SID claims" 
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] 
=> issue(claim = c);

@RuleTemplate = "PassThroughClaims" 
@RuleName = "Pass through all Group SID claims" 
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] 
=> issue(claim = c);

@RuleTemplate = "PassThroughClaims" 
@RuleName = "Pass through all Primary group SID claims" 
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] 
=> issue(claim = c);

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

@RuleTemplate = "PassThroughClaims" 
@RuleName = "Pass through all Deny only primary SID claims" 
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/denyonlyprimarysid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] 
=> issue(claim = c);

@RuleTemplate = "PassThroughClaims" 
@RuleName = "Pass through all Deny only primary group SID claims" 
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/denyonlyprimarygroupsid", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] 
=> issue(claim = c);

@RuleTemplate = "PassThroughClaims" 
@RuleName = "Pass through all Enhanced Key Usage claims" 
c:[Type == "http://schemas.microsoft.com/2012/12/certificatecontext/extension/eku", Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"] 
=> issue(claim = c);

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

[2] Open a PowerShell Command Prompt window

[3] Execute the following commands:

[a] Import-Module ADFS

[b] Set-AdfsClaimsProviderTrust -TargetName "Active Directory" -AcceptanceTransformRulesFile "C:\TEMP\CP_ActiveDirectory_AcceptanceTransformRules_Default.txt"

[4] To verify your changes:

[a] Open the AD FS Management MMC

[b] Navigate to the node called "Trust Relationships" and select the sub-node "Claims Provider Trusts"

[c] Right-click the "Active Directory" CP trust and select "Edit Claim Rules"

You should now see something similar to:

Figure 1: Default List Of Acceptance Transform Rules For The Default Claims Provider Trust (AD) In ADFS v3.0

–

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/ ########

———————————————————————————————

Posted in Active Directory Federation Services (ADFS), Claims Rule Language, Federation Trusts, Transform Rules | 2 Comments »

« Previous Entries

Jorge's Quest For Knowledge!

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

For Ad Free Blog

Social Media

Profiles

Statistics

Other Cool Blogs

Interesting Places To Visit

The Knowledge Archives

RSS Links

Email Subscription

Categories

Archive for the ‘Federation Trusts’ Category

(2020-04-19) It’s That Time Again, You Need To Roll-Over The Certificates In ADFS

(2018-10-09) Changing AD CP Trust Display Name And Order In ADFS 2016 Farm Level And Higher

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

(2016-12-03) Adding Or Updating An RP Trust Through The GUI in Windows Server 2016 Fails When Using A Federation Metadata URL

(2015-10-12) Configuring System Wide Proxy Settings For ADFS To Use

(2014-10-01) TroubleShooting Federation/SSO To Windows Azure AD And Office 365

(2014-03-12) Additional PowerShell Scripts For Migrating ADFS v2.x To ADFS v3.0

(2014-02-10) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v3.0 (Update 1)

(2013-10-09) Bare Minimum Acceptance Transform Rules For The Default Claims Provider Trusts In ADFS v3.0

(2013-10-07) Restoring The Default Acceptance Transform Rules For The AD CP Trust In ADFS v3.0

All About Identity And Security On-Premises And In The Cloud – It's Just Like An Addiction, The More You Have, The More You Want To Have!

For Ad Free Blog

Social Media

Profiles

Statistics

Other Cool Blogs

Interesting Places To Visit

The Knowledge Archives

RSS Links

Email Subscription

Categories

Archive for the ‘Federation Trusts’ Category

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this:

Share this:

Like this: