Microsoft has released update rollup 3 for ADFS v2.0. This rollup contains both bug fixes and additional capabilities. Read all the details by clicking on the following link Description of Update Rollup 3 for Active Directory Federation Services (AD FS) 2.0.
The Update Rollup 3 update is a cumulative update package that contains all the fixes and new features that were contained in Update Rollup 1 and 2.
–
Issue 1
AD FS 2.0 does not issue an ActAs token for a relying party who is using a Security Assertion Markup Language (SAML) 2.0 bootstrap token. When this issue occurs, the following error is generated:
System.IdentityModel.Tokens.SecurityTokenException: ID4154: A Saml2SecurityToken cannot be created from the Saml2Assertion because it contains a SubjectConfirmationData which specifies an InResponseTo value. Enforcement of this value is not supported by default. To customize SubjectConfirmationData processing, extend Saml2SecurityTokenHandler and override ValidateConfirmationData.
After you apply AD FS 2.0 update rollup 3, AD FS 2.0 successfully issues the token in this situation.
–
Issue 2
AD FS 2.0 update rollup 2 introduced strict Uniform Resource Identifier (URI) checking. When AD FS 2.0 acts as a federation provider and trusts an identity provider whose identifier is not an URI, the response that is returned from the identity provider is rejected by AD FS 2.0. The validation fails because AD FS 2.0 tries to validate the value of the identity provider’s identifier. This behavior breaks previously functioning AD FS 2.0 deployments in which identity providers use non-URI identifiers. AD FS 2.0 update rollup 3 removes this URI checking.
–
Issue 3
AD FS 2.0 acts as a federation provider and receives an invalid SAML 2.0 signed request (for example, the signature is not valid or the requestor is unknown). In this situation, AD FS 2.0 rejects the request only after it forwards the request to the downstream identity provider and receives a valid SAML response.
In order to make sure the validity of the requests that are sent to the downstream identity provider, the expected behavior is that AD FS 2.0 validates SAML requests and rejects any requests that have invalid signatures.
–
Issue 4
Relying parties require that signature certificates are applied to the relying party for SAML request. This is because signature certificates provide an important security validation function and are defined in the SAML 2.0 specification. AD FS 2.0 allows unique signature certificates to be applied to a relying party trust. However, it only allows the same certificate to be applied to one relying party trust per AD FS 2.0 farm. This restriction may allow multiple relying parties to use the same signing certificate for SAML requests. AD FS 2.0 update rollup 3 removes this restriction.
UPDATE 2013-05-17: Post-update configuration for issue 4
Note however that simply applying the update rollup doesn’t allow you to implement multiple relying party trusts with the same certificate. After applying the update you have to update the configuration database. The steps differ from when using WID or SQL server.
–
+++ Are you using WID? Then use the following steps! +++
The script “PostReleaseSchemaChanges.ps1” is located under the AD FS binaries directory “C:\Program Files\Active Directory Federation Services 2.0\SQL”.
Manually execute the script first on the secondary federation servers in the farm, and then on the primary federation server!
–
+++ Are you using SQL? Then use the following steps! +++
Download the SQL script “RelaxedRequestSigningCertsv2.sql” and execute it against the configuration database.
To execute this script, run the following command by using the Sqlcmd utility: Sqlcmd -S <ConnectionString for SQL> -i RelaxedRequestSigningCertsv2.sql
OR,
Use SQL Server Management Studio to execute the SQL Query. Connect to the SQL Server database that has the AD FS 2.0 configuration database. Create a new SQL query. Paste the contents of the RelaxedRequestSigningCertsv2.sql file into the query, and then execute the query.
After running the script, you can create RP trusts with the same signing certificate.
–
Issue 5
Consider the following scenario:
- You use a third-party hardware security module (HSM) to speed up the signing processes.
- You use the third-party HSM and to generate and store the private keys.
- The private keys are for AD FS 2.0 signing and for AD FS 2.0 encryption certificates.
In this situation, the performance of AD FS 2.0 is not as good as when you use Microsoft CSP. AD FS 2.0 update rollup 3 significantly improves the performance of AD FS 2.0 when HSM is used.
–
Issue 6
AD FS 2.0 update rollup 1 introduces the Congestion Avoidance Algorithm. If you accidentally disable the Congestion Avoidance Algorithm by changing the configuration, a handle leak occurs on an AD FS 2.0 federation server proxy every time that the federation server proxy processes a request. AD FS 2.0 update rollup 3 removes the setting that enables you to disable Congestion Avoidance Algorithm by changing the configuration. You can fine tune the Congestion Avoidance Algorithm by adjusting the latencyThresholdInMsec and minCongestionWindowSize settings.
–
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/ ########
———————————————————————————————
Like this:
Like Loading...
Jorge's Quest For Knowledge! 