Jorge's Quest For Knowledge!

About Windows Server, ADDS, ADFS, Azure AD, FIM/MIM & AADSync (Just Like An Addiction, The More You Have, The More You Want To Have!)

(2015-07-04) Displaying The Issued Claims In A Security Token (On Screen)

Posted by Jorge on 2015-07-04


When accessing a federated application, from a troubleshooting perspective, it can be very interesting in knowing/seeing which claims are being send to the application. ADFS itself logs that information in the Security Event Log, assuming auditing has been enabled. However, to know about all the claims send to an application you might need to go through multiple event IDs.

For more information about enabling the auditing of issued claims see:

If you have a farm consisting of multiple ADFS STS servers, you need to understand first which of the ADFS STS servers in the farm serviced the issuance of the security token. In summary, it can be quite a pain to get the required information when needed. Now, wouldn’t it great to have a claims-based application that shows the claims from the security token that was issued by the (last) federation system? Yes it would!

So how would you display the issued claims for a specific claims-based application on another claims-based application? That’s easy!

Let’s say that the "Display The Issued Claims" claims-based application is the application that display all the claims from a security token.

Let’s say that the "Collaboration" claims-based (SharePoint) application is the application for which you want to see the issued claims.

Configure the exact same issuance transform rules in ADFS from the RP trust representing the "Collaboration" claims-based (SharePoint) application on the RP trust representing the "Display The Issued Claims" claims-based application. Now tell the user to navigate to the "Display The Issued Claims" claims-based application and ask the user to e-mail the contents of the website by pressing [CTRL]+[A], followed by [CTRL]+[C] and followed by [CTRL]+[V] in an e-mail to the service desk.

In this blog post, the "Ask PFE Platform" guys explains how to setup the website I’m talking about. However, it requires different manual steps to implement it. I used the exact same website and created a brand new deployment script that helps you setup the website in IIS and the RP trust in ADFS. So, let’s get started and see how you can deploy this.

You can download my version of this from here and unpack it on the Windows Server 2012 (R2) where you want to deploy it.

Before running the script, make sure the following is clear:

After unpacking the ZIP file on the server where you want to deploy website, AND taking care of all the points above, execute the script ‘Deploying-Claims-Based-Application.ps1′ that is also available in the unpacked folder. The script will guide you step by step in deploying the website and creating the RP trust in ADFS. The script always specifies what the next step will be before executing it.

After pressing any key, the script will install all required roles and features…

image

Figure 1: Current Step: Initial Screen Warming About Prerequisites – Next Step: Installing Roles And Features

After pressing any key, the script will check if ‘FedUtil.exe’ is available on the local server. If it is not available, the script will abort. ‘FedUtil.exe’ is required to generate the federation metadata of the application, so that a RP trust can be created by using the federation metadata URL of the application.
image

Figure 2: Current Step: Installing Roles And Features – Next Step: Checking Availability Of ‘FedUtil.exe’

After pressing any key, the script will check if ‘New-SelfSignedCertificateCustom.ps1′ is available on the local server. If it is not available, the script will abort. ‘New-SelfSignedCertificateCustom.ps1′ is required to generate a self-signed certificate as the Token Encryption Certificate for the application.

image

Figure 3: Current Step: Checking Availability Of ‘FedUtil.exe’ – Next Step: Checking Availability Of ‘New-SelfSignedCertificateCustom.ps1′

After pressing any key, the script will create a new application pool or use an existing one, depending on what you specify. When the choice is made to create a new application pool, a name and credentials need to be provided for the new application pool.

image

Figure 4: Current Step: Checking Availability Of ‘New-SelfSignedCertificateCustom.ps1′ – Next Step: Creating The Web Application Pool

After pressing any key, the script will create a new website or you can use an existing website and create a subfolder, depending on what you specify. When the choice is made to create a new website, HTTP binding information needs to be specified. When the choice is made to use an existing website, the virtual folder an its path need to be specified. In both cases the HTTPS URL to access the application, including the custom port if applicable, needs to be specified.

image

Figure 5: Current Step: Creating The Web Application Pool – Next Step: Creating The WebSite

After pressing any key, the script will check if SSL is enabled and enforced. If not, HTTPS binding information needs to be specified, including a certificate for SSL.

image

Figure 6: Current Step: Creating The WebSite – Next Step: Enabling SSL

After pressing any key, the script will retrieve ADFS related information (i.e. identifier, token signing certificate and endpoints) to configure the WEB.CONFIG of the application with.

image

Figure 7: Current Step: Enabling SSL – Next Step: Getting ADFS Information

After pressing any key, the script will use ‘New-SelfSignedCertificateCustom.ps1′ to generate a self-signed certificate with the subject you specify. Additional characteristics of the certificate are:

  • EnhancedKeyUsage "Server Authentication"
  • KeyUsage "KeyEncipherment","DigitalSignature"
  • StoreLocation "LocalMachine"
  • ProviderName "Microsoft Enhanced Cryptographic Provider v1.0"
  • AlgorithmName RSA
  • KeyLength 2048
  • SignatureAlgorithm SHA256
  • NotBefore $([datetime]::now.AddDays(-1))
  • NotAfter $([datetime]::now.AddDays(3650))
  • FriendlyName "Show My Claims ASPNET TOKEN" -exportable

image

Figure 8: Current Step: Getting ADFS Information – Next Step: Generating The Self-Signed Certificate

After pressing any key, the script will assign the account used in the application pool Allow:Read permissions in the private key of the certificate.

image

Figure 9: Current Step: Generating The Self-Signed Certificate – Next Step: Assigning The Application Pool Account Permissions On The Private Key Of The Self-Signed Certificate

After pressing any key, the script will copy the website from the specified source folder to the specified target folder of the website of the virtual folder.

image

Figure 10: Current Step: Assigning The Application Pool Account Permissions On The Private Key Of The Self-Signed Certificate – Next Step: Copy The Website Files To The Target Folder

After pressing any key, the script will configure the WEB.CONFIG of the application with the gathered information.

image

Figure 11: Current Step: Copy The Website Files To The Target Folder – Next Step: Confguring The Web.Config Of The Application

After pressing any key, the script will generate the federation metadata for the application based upon the WEB.CONFIG.

image

Figure 12: Current Step: Confguring The Web.Config Of The Application – Next Step: Generate The Federation Metadata For The Application

After pressing any key, the script will try to create the RP trust within ADFS using the federation metadata URL of the application. The issuance authorization rules will allow access for everyone (permit all). The issuance transform rules will send the userPrincipalName (UPN) as nameIdentifier to the application including any other issued claim.

image

Figure 13: Current Step: Generate The Federation Metadata For The Application – Next Step: Create The Relying Party Trust Within ADFS

The script will display all the RP trusts in ADFS and you need to decide if the name you specified for the RP trust is now included in the list of RP trusts. If it is in the list you are done and can specify Y or Yes. If it is not in the list you may need to solve why it did not create the RP trust by checking for example the Event Logs and fix what needs to be fixed. Then you can retry the creation by specifying N or No.

image

Figure 14: Current Step: Create The Relying Party Trust Within ADFS – Next Step: Confirm Creating Of The Relying Party Trust Within ADFS

Assuming you specified Y or Yes, the script ends and displays both the application URL as the federation metadata URL of the application. You can copy the that into a browser and try the application.

image

Figure 15: Script Finished Succesfully

If the federation metadata URL was specified in the browser you would see something similar.

image

Figure 16: Federation Metadata Of The Application

If the application URL was specified in the browser, the application should redirect you to ADFS and possibly ask you to perform Home Realm Discovery (HRD) by telling ADFS from which IdP you are coming from.

image

Figure 17: Home Realm Discovery Within ADFS v3.0 and Higher

Assuming WIA is enabled, the logged on credentials will be used. To configure and support WIA for different browsers, see:

The application now display the issued claims from the security token send to the application (begin of the list)

image

Figure 18: The List Of Issued Claims Within The Security Token

The application now display the issued claims from the security token send to the application (end of the list)

image

Figure 19: The List Of Issued Claims Within The Security Token

Enjoy!

PS: Mylo from the Access Onion has written a blog post about SimpleSAMLphp which is the similar PHP version of an application like this

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, Claims Based Apps, Security Tokens | Leave a Comment »

(2015-07-01) New Azure Authenticator Phone App Supports Multiple Account Providers

Posted by Jorge on 2015-07-01


Microsoft has released a new MFA Phone App supports any account provider supporting the Open Authentication Initiative (OATH). Examples of supported account providers are: Azure AD, Microsoft Account and Google.

For more information please read:

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 Multi-Factor AuthN, Windows Azure Active Directory | Leave a Comment »

(2015-06-29) Azure AD Connect Has RTM’ed

Posted by Jorge on 2015-06-29


Azure AD Connect allows you to quickly onboard to Azure AD and Office 365. The Azure AD Connect wizard is the single tool and guided experience for connecting your on premises identity infrastructure to the cloud.  Choose your topology and needs (single or multiple directories, password sync or federation), and the wizard will deploy and configure all components required to get your connection up and running including sync services, AD FS, and the Azure AD PowerShell module.

Azure AD Connect encompasses functionality that was previously released as Dirsync and AAD Sync.  These tools will no longer be released individually.  All future improvements will be included in updates to Azure AD Connect, so that you always know where to get the most current functionality.

Download it from here

Integrating your on-premises directories with Azure AD makes your users more productive by providing a common identity for accessing both cloud and on-premises resources. With this integration users and organizations can take advantage of the following:

  • Organizations can provide users with a common hybrid identity across on-premises or cloud-based services leveraging Windows Server Active Directory and then connecting to Azure Active Directory.
  • Administrators can provide conditional access based on application resource, device and user identity, network location and multifactor authentication.
  • Users can leverage their common identity through accounts in Azure AD to Office 365, Intune, SaaS apps and third-party applications.
  • Developers can build applications that leverage the common identity model, integrating applications into Active Directory on-premises or Azure for cloud-based applications

Azure AD Connect makes this integration easy and simplifies the management of your on-premises and cloud identity infrastructure.

More information:

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 Azure AD Connect, Windows Azure Active Directory | Leave a Comment »

(2015-06-28) A Hotfix Rollup Package (Build 4.1.3646.0) Is Available for Forefront Identity Manager 2010 R2 SP1

Posted by Jorge on 2015-06-28


Microsoft released a new hotfix for FIM 2010 R2 SP1 with build 4.1.3646.0. What it fixes can be found in this blog post. For additional or detailed info see MS-KBQ3054196

Download link

Issues that are fixed or features that are added in this update

This update also fixes the following issues or adds the following features that were not previously documented in the Microsoft Knowledge Base.

FIM Service

Issue 1

When you update the criteria of a group or set, you receive a SQL error if negative conditions exceed 7 in the filter when you click View members. After you apply this update, the View Members button works as expected.

FIM service portals, add-ins and extensions

Issue 1

When you use the FIM Credential Provider Extension for Self-Service Password Reset (SSPR), you cannot answer by using double-byte characters through the Windows Input Method Editor (IME) in the "Question and Answer" gate. After you apply this update double-byte characters are not permitted when you are first creating answers.

Issue 2

In the FIM Password Registration Portal, auto-focus on the first text box can cause the first registration question to be hidden from view. After you apply this update, the text box and its caption now act as a single control when they receive the focus, and the question is no longer hidden from view.

Issue 3

On the FIM Password Registration and Password Reset websites, autocomplete was not disabled for the logon forms. After you apply this update, autocomplete is disabled for all logon forms.

Issue 4

After you apply this update, the Object Picker control in the FIM Identity Management Portal returns invalid results if there were special characters in the search string. After you apply this update, the Object Picker control parses the HTML strings correctly so that the Object Picker control returns the correct results.

Certificate management

Issue 1

The revocation settings in a profile template can only be configured for all certificates together and not for each certificate separately. After you apply this update, the administrator can configure the following settings from the Revocation Settings page for each certificate in the policy:

  • RevokeThisCertificate
  • PublishBaseCRL
  • PublishDeltaCRL

Related changes in the FIM CM API –> Changes in the FIM CM API were also made to accommodate this change.

  • Properties of Microsoft.Clm.Shared.ProfileTemplates.RevocationOptions that were changed or added.

PublishBaseCrl
This property is obsolete. Use the PublishBaseCRL property from CertificateTemplateRevocationOptions instead.

PublishDeltaCrl
This property is obsolete. Use the PublishDeltaCRL property from CertificateTemplateRevocationOptions instead.

RevokeOldCertificates
This property is obsolete. Use the RevokeThisCertificate property from CertificateTemplateRevocationOptions instead.

CertificateTemplateRevocationSettings
Collection with configuration for each certificate template in the profile template
CertificateTemplateRevocationSettings is ReadOnlyCollection of Microsoft.Clm.Shared.ProfileTemplates.CertificateTemplateRevocationOptions type:

public ReadOnlyCollection<CertificateTemplateRevocationOptions> CertificateTemplateRevocationSettings { get; }
  • New object Microsoft.Clm.Shared.ProfileTemplates.CertificateTemplateRevocationOptions has the following properties.

CertificateTemplateCommonName

Obtains the string value together with the common name of the current certificate

RevokeThisCertificate

Obtains a Boolean value that indicates whether the current certificate that is associated with the smart card or the software profile that is to be operated on during a revoke operation will also be revoked.

PublishBaseCRL

Obtains a Boolean value that indicates whether a revocation operation causes the base certificate revocation list (CRL) to be published.

PublishDeltaCRL

Obtains a Boolean value that indicates whether a revocation operation causes a delta CRL to be published.

FIM synchronization service

Issue 1

The management agent for Active Directory receives a "Replication Access Denied" error when you run a Delta Import run profile step on domains that contain a read-only domain controller (RODC).

The documentation currently indicates that the account that is used in the management agent for Active Directory should have replicating directory changes. This is insufficient for domains that have the RODC feature enabled. The account that is used in the management agent for Active Directory should also be granted the replication directory changes in filter set permission to run Delta Import in such domains.

Issue 2

When a new synchronization rule is created and is projected into the metaverse, the following situation occurs whenever a synchronization rule does not project because of a synchronization error:

  • The synchronization exception causes the synchronization engine to remove the newly projected metaverse object because the synchronization failed.
  • The synchronization engine does not remove the import attribute flow rules that were added in the server configuration during the synchronization of the metaverse object.

Effect

  • Changes to the existing synchronization rule that failed initial sync do no resolve the problem.
  • The replacement of that synchronization rule does not resolve the problem.

After you apply this update, synchronization rule fragments will not be left in the server configuration when an attempt at failed projection or synchronization is made.

BHOLD and Access Management Connector

Issue 1

When you create delta-attestation campaign in BHOLD Analytics, an error message is displayed regardless of whether the campaign was created. After you apply this update, the error message is displayed only if there were errors when the campaign was created.

Issue 2

In BHOLD Attestation, user interface elements may not be available with new versions of Internet Explorer. After you apply this update, web forms work and are displayed as expected.

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 Forefront Identity Manager (FIM) bHold, Forefront Identity Manager (FIM) Certificate Management, Forefront Identity Manager (FIM) Portal, Forefront Identity Manager (FIM) Sync, Updates, Updates, Updates, Updates | Leave a Comment »

(2015-05-23) Generating Self-Signed Certificates (For Testing Purposes)

Posted by Jorge on 2015-05-23


With MAKECERT you could create/generate self-signed certificates that you could use for testing purposes or in your test environmnt. MAKECERT has been deprecated for reasons described here. In Windows 8.1, Windows PowerShell 4.0, Windows Server 2012 R2 you can use the New-SelfSignedCertificate CMDlet. However, that CMDlet has its own limitations. By default it uses the following hardcoded limitations, which unfortunately cannot be changed:

  • Subject: Empty
  • Key: RSA 2048
  • EKUs: Client Authentication and Server Authentication
  • Key Usage: Digital Signature, Key Encipherment (a0)
  • Validity Period: One year

One of the best PKI guys I know about, is Vadims Podāns, and he wrote is own New-SelfSignedCertificateEx CMDlet a few years ago which quite some flexibility. For example, you can specify the "Not Before" and "Not After" date, and therefore determine the lifetime of the self-signed certificate. It is included in a PowerShell script, which can be downloaded from here.

Unfortunately I could not get it to work. I got the PowerShell script working by doing the following:

  • Downloading the PowerShell script
  • Replace the line "function New-SelfSignedCertificateEx {" with "#function New-SelfSignedCertificateEx {"
  • Replace the last line with a "}" with "#}" (line number 392)
  • Remove the certificate block
  • Change the execution policy in PowerShell

For my testing purposes I used the following PowerShell command (make sure to replace some parameter values with the values you need)

.\New-SelfsignedCertificateEx.ps1 -Subject "CN=TESTTOKEN.IAMTEC.NL" -EnhancedKeyUsage "Server Authentication","Client authentication" -KeyUsage "KeyEncipherment","DigitalSignature" -SubjectAlternativeName "DNS Name=TESTTOKEN.IAMTEC.NL" -StoreLocation "LocalMachine" -ProviderName "Microsoft Enhanced Cryptographic Provider v1.0" -AlgorithmName RSA -KeyLength 2048 -SignatureAlgorithm SHA256 -NotBefore $([datetime]::now.AddDays(-345)) -NotAfter $([datetime]::now.AddDays(15)) -FriendlyName "My Test Self-Signed Certificate" -exportable

image

Figure 1: Generating A Self-Signed Certificate With The Custom PoSH Script

My version of the PowerShell script with the changes mentioned above can be downloaded from here. All credits for this script go to the original writer of it, Vadims Podāns.

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 Certificates, PowerShell, Tooling/Scripting | Leave a Comment »

(2015-05-19) Configuring Windows Integrated AuthN For Chrome Against ADFS v3.0 And Higher

Posted by Jorge on 2015-05-19


ADFS by default supports multiple authentication mechanisms, being certificate authentication, forms based authentication (FBA) and Windows Integrated Authentication (WIA). For non-domain joined clients or clients on the extranet, FBA is the best option. For domain-joined client on the intranet, WIA is the best option to use. In the last scenario WIA delivers the best SSO experience for the user. To support WIA, the backend, the client and the ADFS server(s) must be configured to support WIA.

[1] To support WIA on the backend the following must be true:

  • The ADFS service account must be configured with a service principal name "HOST/<Federation Service FQDN>" (e.g. HOST/FS.COMPANY.COM)

[2] To support WIA on the client/browser the following must be true:

  • The browser must support JavaScript and have it enabled–> For Chrome this is enabled by default. However, if you have disabled it follow the next steps to re-enable it:
    • Enable it globally"
      • Start Chrome
      • Click the "Chrome Menu" button (icon with 3 stacked horizontal lines)
      • Select "Settings"
      • In the "Settings" Window –> Scroll to the bottom of the page and click the link "Show Advanced Settings" –> "Privacy" Section –> Click the "Content Settings" button
      • "Javascript" Section –> Select "Allow all sites to run JavaScript"
      • Click "Done"
    • Enable it specifically for the Federation Service FQDN and any other FQDN requiring it
      • Start Chrome
      • Click the "Chrome Menu" button (icon with 3 stacked horizontal lines)
      • Select "Settings"
      • In the "Settings" Window –> Scroll to the bottom of the page and click the link "Show Advanced Settings" –> "Privacy" Section –> Click the "Content Settings" button
      • "Javascript" Section –> Click the "Manage Exceptions" button
      • Specify the Federation Service FQDN and click "Allow"
      • Click "Done" 2x
  • The browser must support and enable the use of cookies –> For Chrome this is enabled by default. However, if you have disabled the use of cookies, you can follow the next steps to re-enable it:
    • Enable it globally"
      • Start Chrome
      • Click the "Chrome Menu" button (icon with 3 stacked horizontal lines)
      • Select "Settings"
      • In the "Settings" Window –> Scroll to the bottom of the page and click the link "Show Advanced Settings" –> "Privacy" Section –> Click the "Content Settings" button
      • "Cookies" Section –> Select "Allow local data to be set (recommended)"
      • Click "Done"
    • Enable it specifically for the Federation Service FQDN and any other FQDN requiring it
      • Start Chrome
      • Click the "Chrome Menu" button (icon with 3 stacked horizontal lines)
      • Select "Settings"
      • In the "Settings" Window –> Scroll to the bottom of the page and click the link "Show Advanced Settings" –> "Privacy" Section –> Click the "Content Settings" button
      • "Cookies" Section –> Click the "Manage Exceptions" button
      • Specify the Federation Service FQDN and click "Allow"
      • Click "Done" 2
  • WIA is enabled in the browser –> For Chrome this is disabled by default. However, if you have it disabled follow the next steps to enable it:
    • Start Registry Editor
    • Navigate to the key "HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome"
    • If the key "AuthSchemes" does not exist, create it
    • In the key "AuthSchemes" create a string value (REG_SZ) named "AuthSchemes"
    • Assign the string value (REG_SZ) named "AuthSchemes", the values "ntlm,negotiate"
      REMARK: Specifies which HTTP Authentication schemes are supported by Google Chrome. Possible values are ‘basic’, ‘digest’, ‘ntlm’ and ‘negotiate’. Separate multiple values with commas. If this policy is left not set, all four schemes will be use
  • The federation service FQDN must be trusted –> For Firefox this is disabled by default for any FQDN on the internet and enabled for the intranet if detected. However, if you have it disabled follow the next steps to enable it for specific FQDNs (in this case the federation service FQDN must be trusted):
    • Start Registry Editor
    • Navigate to the key "HKEY_LOCAL_MACHINE\SOFTWARE\Google\Chrome"
    • If the key "AuthSchemes" does not exist, create it
    • In the key "AuthServerWhitelist" create a string value (REG_SZ) named "AuthServerWhitelist"
    • Assign the string value (REG_SZ) named "AuthServerWhitelist", the Federation Service FQDN as the value
      REMARK: Specifies which servers should be whitelisted for integrated authentication. Integrated authentication is only enabled when Google Chrome receives an authentication challenge from a proxy or from a server which is in this permitted list. Separate multiple server names with commas. Wildcards (*) are allowed. If you leave this policy not set Chrome will try to detect if a server is on the Intranet and only then will it respond to IWA requests. If a server is detected as Internet then IWA requests from it will be ignored by Chrome

[3] To support WIA against the ADFS STS server(s) the following must be true:

  • WIA must be enabled as an authentication method on the intranet
  • The user agent of the browser must be known to ADFS. By default ADFS v3.0 and higher, the following user agent strings are supported (retrieved through "(Get-AdfsProperties).WIASupportedUserAgents")
    • MSAuthHost/1.0/In-Domain <– ADFS v4.0 and higher
    • MSIE 6.0 <– ADFS v3.0 and higher
    • MSIE 7.0 <– ADFS v3.0 and higher
    • MSIE 8.0 <– ADFS v3.0 and higher
    • MSIE 9.0 <– ADFS v3.0 and higher
    • MSIE 10.0 <– ADFS v3.0 and higher
    • Trident/7.0 <– ADFS v3.0 and higher
    • MSIPC <– ADFS v3.0 and higher
    • Windows Rights Management Client <– ADFS v3.0 and higher
    • MS_WorkFoldersClient <– ADFS v4.0 and higher
  • You may need to disable extended protection in ADFS if you still keep being prompted for credentials while configured all of the above. I was NOT able to use Chrome v42.0.2311.135 and WIA without disabling extended protection
    REMARK: "ExtendedProtectionTokenCheck" –> Specifies the level of extended protection for authentication supported by the federation server. Extended Protection for Authentication helps protect against man-in-the-middle (MITM) attacks, in which an attacker intercepts a client’s credentials and forwards them to a server. Protection against such attacks is made possible through a Channel Binding Token (CBT) which can be either required, allowed or not required by the server when establishing communications with clients.

    Possible values for this setting are: as follows "Require" (server is full hardened, extended protection is enforced), "Allow" (server is partially hardened, extended protection is enforced where systems involved have been patched to support it) and "None" (Server is vulnerable, extended protection is not enforced). The default setting is "Allow". If lowering this protection is not acceptable, then use Forms-Based Authentication!

    • To disable ExtendedProtectionCheck on the ADFS server execute on the (primary) ADFS server: Set-AdfsProperties -ExtendedProtectionTokenCheck None
    • On every ADFS farm member, restart the ADFS service: Restart-Service ADFSSRV

So how do you know the state of your browser? Check it out yourself and just navigate to the website What’s My User Agent?

In my case the browser I was using, Chrome v42.0.2311.135, provided the shown user agent string and the yellow marked part matched what already was configured in ADFS

SNAGHTMLad46631

Figure 1: The User Agent String And Status Of Chrome 42.0.2311.135

The following is an analysis of the provided user agent string

image

Figure 2: Analysis Of The Provided User Agent String

So, for Chrome you need to meet the prerequisites as mentioned in [1], [2] and [3].

To configure a new supported user agent string in ADFS, while taking the existing user agent strings into account, use the following PowerShell commands on (primary) ADFS server:

Import-Module ADFS

Set-ADFSProperties -WIASupportedUserAgents $((Get-ADFSProperties).WIASupportedUserAgents + "<Required User Agent String>")

In this case the command is:

Import-Module ADFS

Set-ADFSProperties -WIASupportedUserAgents $((Get-ADFSProperties).WIASupportedUserAgents + "Mozilla/5.0")

That’s it! You should now be able to use Chrome and experience seamless SSO!

For other user agent strings also see:

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), Windows Integrated AuthN | Leave a Comment »

(2015-05-15) Configuring Windows Integrated AuthN For Firefox Against ADFS v3.0 And Higher

Posted by Jorge on 2015-05-15


ADFS by default supports multiple authentication mechanisms, being certificate authentication, forms based authentication (FBA) and Windows Integrated Authentication (WIA). For non-domain joined clients or clients on the extranet, FBA is the best option. For domain-joined client on the intranet, WIA is the best option to use. In the last scenario WIA delivers the best SSO experience for the user. To support WIA, the backend, the client and the ADFS server(s) must be configured to support WIA.

[1] To support WIA on the backend the following must be true:

  • The ADFS service account must be configured with a service principal name "HOST/<Federation Service FQDN>" (e.g. HOST/FS.COMPANY.COM)

[2] To support WIA on the client/browser the following must be true:

  • The browser must support JavaScript and have it enabled–> For Firefox this is enabled by default. However, if you have installed the privacy extension "NoScript", then you need to either:
    • Enable it globally within the privacy extension "NoScript"
      • Start Firefox
      • Click the "NoScript" button
      • Select "Allow Scripts Globally"
      • Click "OK"
    • Enable it specifically for the Federation Service FQDN and any other FQDN requiring it
      • Start Firefox
      • Click the "NoScript" button
      • Select "Options"
      • Click the "Whitelist" tab
      • Specify the Federation Service FQDN and click "Allow"
      • Click "OK"
  • The browser must support and enable the use of cookies –> For Firefox this is enabled by default. However, if you have disabled the use of cookies, you can follow the next steps to re-enable it:
    • Enable it globally
      • Start Firefox
      • Click the "Firefox Menu" button (icon with 3 stacked horizontal lines)
      • Click the "Options" button
      • Click the "Privacy" panel
      • Check "Accept cookies from sites"
      • Click "OK"
    • Enable it specifically for the Federation Service FQDN and any other FQDN requiring it
      • Start Firefox
      • Click the "Firefox Menu" button (icon with 3 stacked horizontal lines)
      • Click the "Options" button
      • Click the "Privacy" panel
      • Click the "Exceptions" button
      • Specify the Federation Service FQDN and click "Allow"
      • Click "Close"
      • Click "OK"
  • WIA is enabled in the browser for the federation service FQDN –> For Firefox this is disabled by default for any FQDN. However, if you have it disabled follow the next steps to enable it for specific FQDNs (in this case the federation service FQDN must be trusted):
    • Start Firefox
    • As a URL type "about:config"
    • Click the "I’ll be careful, I promise!" button
    • As a Search type "network.negotiate-auth.trusted-uris"
    • Double-click on the line "network.negotiate-auth.trusted-uris"
    • Specify the Federation Service FQDN, or a comma separated list and click "OK"
    • Double-click on the line "network.automatic-ntlm-auth.trusted-uris"
    • Specify the Federation Service FQDN, or a comma separated list and click "OK"

[3] To support WIA against the ADFS STS server(s) the following must be true:

  • WIA must be enabled as an authentication method on the intranet
  • The user agent of the browser must be known to ADFS. By default ADFS v3.0 and higher, the following user agent strings are supported (retrieved through "(Get-AdfsProperties).WIASupportedUserAgents")
    • MSAuthHost/1.0/In-Domain <– ADFS v4.0 and higher
    • MSIE 6.0 <– ADFS v3.0 and higher
    • MSIE 7.0 <– ADFS v3.0 and higher
    • MSIE 8.0 <– ADFS v3.0 and higher
    • MSIE 9.0 <– ADFS v3.0 and higher
    • MSIE 10.0 <– ADFS v3.0 and higher
    • Trident/7.0 <– ADFS v3.0 and higher
    • MSIPC <– ADFS v3.0 and higher
    • Windows Rights Management Client <– ADFS v3.0 and higher
    • MS_WorkFoldersClient <– ADFS v4.0 and higher
  • You may need to disable extended protection in ADFS if you still keep being prompted for credentials while configured all of the above. I was able to use Firefox v37.0 and WIA without disabling extended protection
    REMARK: "ExtendedProtectionTokenCheck" –> Specifies the level of extended protection for authentication supported by the federation server. Extended Protection for Authentication helps protect against man-in-the-middle (MITM) attacks, in which an attacker intercepts a client’s credentials and forwards them to a server. Protection against such attacks is made possible through a Channel Binding Token (CBT) which can be either required, allowed or not required by the server when establishing communications with clients.

    Possible values for this setting are: as follows "Require" (server is full hardened, extended protection is enforced), "Allow" (server is partially hardened, extended protection is enforced where systems involved have been patched to support it) and "None" (Server is vulnerable, extended protection is not enforced). The default setting is "Allow". If lowering this protection is not acceptable, then use Forms-Based Authentication!

    • To disable ExtendedProtectionCheck on the ADFS server execute on the (primary) ADFS server: Set-AdfsProperties -ExtendedProtectionTokenCheck None
    • On every ADFS farm member, restart the ADFS service: Restart-Service ADFSSRV

So how do you know the state of your browser? Check it out yourself and just navigate to the website What’s My User Agent?

In my case the browser I was using, Firefox v37.0, provide the shown user agent string and the yellow marked part did not match what already was configured in ADFS

SNAGHTMLa8467bc

Figure 1: The User Agent String And Status Of Firefox 37.0

The following is an analysis of the provided user agent string

image

Figure 2: Analysis Of The Provided User Agent String

So, for Firefox you need to meet the prerequisites as mentioned in [1], [2] and [3].

To configure a new supported user agent string in ADFS, while taking the existing user agent strings into account, use the following PowerShell commands on (primary) ADFS server:

Import-Module ADFS

Set-ADFSProperties -WIASupportedUserAgents $((Get-ADFSProperties).WIASupportedUserAgents + "<Required User Agent String>")

In this case the command is:

Import-Module ADFS

Set-ADFSProperties -WIASupportedUserAgents $((Get-ADFSProperties).WIASupportedUserAgents + "Mozilla/5.0")

That’s it! You should now be able to use Firefox and experience seamless SSO!

For other user agent strings also see:

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), Windows Integrated AuthN | Leave a Comment »

(2015-05-11) Configuring Windows Integrated AuthN For Internet Explorer Against ADFS v3.0 And Higher

Posted by Jorge on 2015-05-11


ADFS by default supports multiple authentication mechanisms, being certificate authentication, forms based authentication (FBA) and Windows Integrated Authentication (WIA). For non-domain joined clients or clients on the extranet, FBA is the best option. For domain-joined client on the intranet, WIA is the best option to use. In the last scenario WIA delivers the best SSO experience for the user. To support WIA, the backend, the client and the ADFS server(s) must be configured to support WIA.

[1] To support WIA on the backend the following must be true:

  • The ADFS service account must be configured with a service principal name "HOST/<Federation Service FQDN>" (e.g. HOST/FS.COMPANY.COM)

[2] To support WIA on the client/browser the following must be true:

  • The browser must support JavaScript and have it enabled–> For IE this is enabled by default. However, if you have disabled it follow the next steps to re-enable it:
    • Start Internet Explorer
    • "Tools" menu/button
    • Click "Internet Options"
    • Click the "Security" tab
    • Click the "Local Intranet" or "Trusted Sites" zone (assuming Federation Service FQDN is listed in either one!)
    • Click "Custom Level"
    • In the "Security Settings" Window –> "Scripting" Section –> Select "Enable" for Active Scripting
    • Click "OK" 2x
  • The browser must support and enable the use of cookies for sites in the Local Intranet or Trusted Sites zone –> For IE this is enabled by default as all cookies are automatically accepted or replayed from Web sites in both the Local Intranet and the Trusted zones
  • WIA is enabled in the browser –> For IE this is enabled by default. However, if you have disabled it follow the next steps to re-enable it:
    • Start Internet Explorer
    • "Tools" menu/button
    • Click "Internet Options"
    • Click the "Advanced" tab
    • In the "Settings" Window –> "Security" Section –> Check "Enable Integrated Windows Authentication"
    • Click "OK"
  • The federation service FQDN must be trusted –> For IE this federation service FQDN is configured in either the "Local Intranet" zone or the "Trusted Sites" zone. To add the Federation Service FQDN manually to either zone follow the next steps:
    • Start Internet Explorer
    • "Tools" menu/button
    • Click "Internet Options"
    • Click the "Security" tab
    • Click the "Local Intranet" or "Trusted Sites" zone
      • "Local Intranet" –> Click "Sites" –> Click "Advanced" –> Add Federation Service FQDN to the list
      • "Trusted Sites" –> Click "Sites" –> Add Federation Service FQDN to the list
    • Click "OK"

[3] To support WIA against the ADFS STS server(s) the following must be true:

  • WIA must be enabled as an authentication method on the intranet
  • The user agent of the browser must be known to ADFS. By default ADFS v3.0 and higher, the following user agent strings are supported (retrieved through "(Get-AdfsProperties).WIASupportedUserAgents")
    • MSAuthHost/1.0/In-Domain <– ADFS v4.0 and higher
    • MSIE 6.0 <– ADFS v3.0 and higher
    • MSIE 7.0 <– ADFS v3.0 and higher
    • MSIE 8.0 <– ADFS v3.0 and higher
    • MSIE 9.0 <– ADFS v3.0 and higher
    • MSIE 10.0 <– ADFS v3.0 and higher
    • Trident/7.0 <– ADFS v3.0 and higher
    • MSIPC <– ADFS v3.0 and higher
    • Windows Rights Management Client <– ADFS v3.0 and higher
    • MS_WorkFoldersClient <– ADFS v4.0 and higher

So how do you know the state of your browser? Check it out yourself and just navigate to the website What’s My User Agent?

In my case the browser I was using, Internet Explorer v9.0, provided the shown user agent string and the yellow marked part matched what already was configured in ADFS

SNAGHTMLa6c2a2b

Figure 1: The User Agent String And Status Of Internet Explorer 9.0

The following is an analysis of the provided user agent string

image

Figure 2: Analysis Of The Provided User Agent String

So, for Internet Explorer you only need to meet the prerequisites as mentioned in [1] and [2]. For future versions of Internet Explorer you may need to also do [3] and update the user agent strings in ADFS that must support seamless SSO through WIA

To configure a new supported user agent string in ADFS, while taking the existing user agent strings into account, use the following PowerShell commands on (primary) ADFS server:

Import-Module ADFS

Set-ADFSProperties -WIASupportedUserAgents $((Get-ADFSProperties).WIASupportedUserAgents + "<Required User Agent String>")

That’s it! You should now be able to use Internet Explorer and experience seamless SSO!

For other user agent strings also see:

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), Windows Integrated AuthN | Leave a Comment »

(2015-05-07) FIM 2010 R2 Officially Supports W2K12R2 AD

Posted by Jorge on 2015-05-07


FIM 2010 R2, more specifically FIM Sync and PCNS, now officially support targeting a W2K12R2 AD. For that you need to at least install the hotfix (or later) as mention in (2015-05-03) A Hotfix Rollup Package (Build 4.1.3634.0) Is Available for Forefront Identity Manager 2010 R2 SP1

Note: In all supported cases, the FIM Synchronization Service must be installed only on a Windows Server 2008, Windows Server 2008 R2, or Windows Server 2012 member server. It must not be installed on a Windows Server 2012 R2 member server unless the PCNS component is installed on a Windows Server 2012 R2 domain controller.

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 Domain Services (ADDS), Forefront Identity Manager (FIM) PCNS, Forefront Identity Manager (FIM) Sync | Leave a Comment »

(2015-05-06) Make Sure To Patch Your ADFS Infrastructure, Again!

Posted by Jorge on 2015-05-06


A few days ago Microsoft disclosed a serious vulnerability (MS15-040)  in ADFS v3.0 (ADFS in Windows Server 2012 R2). The vulnerability could allow information disclosure if a user leaves their browser open after logging off from an application and an attacker reopens the application in the browser immediately after the user has logged off. This security update is rated Important for AD FS 3.0 when installed on x64-based editions of Windows Server 2012 R2. The security update addresses the vulnerability by ensuring that the logoff process properly logs off the user.

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), Updates | Leave a Comment »

 
%d bloggers like this: