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-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 »

(2015-05-05) Make Sure To Patch Your ADFS Infrastructure, If You Have Not Done It Already

Posted by Jorge on 2015-05-05


Last month Microsoft disclosed a serious vulnerability (MS15-034) that exists in the HTTP protocol stack (HTTP.sys) that allows for remote code execution. This is caused when HTTP.sys improperly parses specially crafted HTTP requests. An attacker who successfully exploited this vulnerability could execute arbitrary code in the context of the System account. Microsoft also released a security update to patch Windows systems.

Now you may thing that you only need to patch Windows systems with IIS installed. That is not accurate. You also need to patch any system, even is IIS is not installed, that is built on top of HTTP.SYS. An example is ADFS v3.0 and higher.

This means that any system protected through ADFS is vulnerable if the ADFS infrastructure is compromised! If ADFS is compromised by someone, then that person is able to generate any security token with any claims in it, and gain access to claims-aware applications.

Therefore make sure to patch any Windows system with IIS or that is built on top of just HTTP.SYS!

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: