Jorge's Quest For Knowledge!

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

Archive for the ‘Windows Integrated AuthN’ Category

(2019-08-01) Moving Towards The Password-Less Concept – One Heck Of Journey And Badly Needed

Posted by Jorge on 2019-08-01


Current passwords are potentially weak and any use of those in general further weakens an infrastructure. Preferably any org needs to move away from using passwords as much as possible. This means for example preventing the usage of passwords, and instead use SSO and/or other more secure authentication mechanisms. In other words, the adoption of the "Password-Less" concept. However, for those scenarios that cannot adopt “Password-Less" (yet), passwords must be strengthened or better secured at rest and in transport. In today’s world “identity” is the key control plane. Therefore protecting the “identity” and everything related is of utmost importance. Usage of weak passwords presents unacceptable security risks to any org. We all know that, don’t we?! Now you need to act to secure yourself as best as possible.

Going password-less is a journey on its own and implementing that concept could mean for example (NOT an exhaustive list and also in random order!):

  • Ban “weak/common” words from being used in weak passwords using Azure AD Password Protection and/or LithNet Password Protection For Active Directory (LPP) (last one is free and the feature set is huge!)
  • Check AD for weak passwords and weak accounts configurations and follow up with risk mitigating actions. Can be done through LPP and DS Internals and generic LDAP queries
  • Help and educate users in terms of using, storing, generating, uniqueness, sharing/distributing, etc. for less frequent (complex and long) and regular used (pass phrases) passwords. Preferably use machine generated passwords as those have no human logic in them, or use (long) passphrases or bang your head against the keyboard multiple times while on and off holding the SHIFT key (last one, kidding!) (people tend to implement logic or sequences somehow in passwords to not forget those long passwords and to make them unique)
  • Move service accounts in AD from regular service accounts to:
    • Group Managed Service Accounts if possible
    • …and if that’s not possible have a password vault store, manage and change passwords on a regular basis
    • …and if that’s not possible keep using regular service accounts with long and unique passwords
  • If possible, increase the password length to a minimum of 15 characters for users
  • Move away from periodic password changes to risk based password changes (e.g. through Azure AD Identity Protection)
  • Using strong and unique passwords for every individual system/site not supporting SSO (the strength of a password is mostly determined by its length, the longer the better!);
  • Securely store passwords in an MFA enabled password manager/vault that is available on both your desktop and mobile device(s)
  • Make Self-Service Password Reset available to users for those occasions where the password is needed but the user has forgotten the password or has locked itself out
  • When using ADFS, implement extranet lockout policy
  • Only use HTTPS connections (at least TLS1.2) in your environment and do not use HTTP
  • Update systems, tools, scripts to NOT set weak/generic/well-known password or account configurations (e.g. LM Hashes, Password Not Required, Password Never Expires, etc)
  • Decrease the use of passwords as much as possible by:
    • Implementing SSO
    • Implement password-less authN for Windows computers (e.g. Windows Hello for Business) and remove password based authN if possible
    • Implement password-less authN for mobile devices (e.g. Azure AD MFA + AuthNtor App Notifications And OTPs) as primary authN, preferably with at least 2 factors during that primary authN, or implement password authN as secondary authN (when using ADFS)

Additional Resources:

Hope this helps you!

Cheers,

Jorge

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

Posted in Active Directory Domain Services (ADDS), Active Directory Federation Services (ADFS), Azure AD MFA Adapter, Azure AD Password Protection, Kerberos AuthN, Microsoft Authenticator App, Multi-Factor AuthN, NTLM AuthN, Password-Less, Security, Self-Service Password Reset, SSO, WH4B, Windows Azure Active Directory, Windows Client, Windows Integrated AuthN | 1 Comment »

(2017-03-28) Why You Should Turn On Forms Based Authentication (FBA) For The Intranet In ADFS!

Posted by Jorge on 2017-03-29


Right after the install, every ADFS farm by default has Windows Integrated Authentication explicitly enabled and Forms Based Authentication disabled on the intranet. Below you see a screenshot from ADFS v4.0, and the settings for ADFS v2.x and ADFS v3.0 are similar.

image

Figure 1: Authentication Methods For The Intranet In ADFS (WIA Enabled And FBA Disabled)

Previously you only had to enable Forms Based Authentication (FBA) for the Intranet in ADFS when you for example used Microsoft CRM Dynamics.

Now with Azure AD playing a very important role in almost every infrastructure, I’m suggesting/recommending to enable FBA by default for the Intranet in ADFS.

Of course you ask: “WHY?”

With Azure AD on the playground you also need FBA for the Intranet in ADFS for the following scenarios:

  1. Azure AD/MSOnline PowerShell Module
  2. Azure AD Self-Service Password Reset

[AD.1]

Every time you connect to Azure AD using a federated account where a browser based window is opened, FBA will be used. If FBA is not enabled, you will get an error

This problem does not occur if you use a native Azure AD Account, or you use a federated account that is specified in the credentials parameter of the PowerShell CMDlet and is also not enforced for MFA!

image

Figure 2: Authentication Screen When Using The Azure AD/MSOnline PowerShell Module

image

Figure 3: Error After Entering Your Federated Account Credentials

[AD.2]

Sometimes with Self-Service Password Reset, Azure AD will ask you to reconfirm your password. You may experience this when:

  • Navigating to https://myapps.microsoft.com/ with a browser, for which WIA is enabled in ADFS. Logon as you normally do with your corporate desktop/laptop
  • Next to your picture, click on “Profile”
  • The click on “Set up self service password reset”
  • It could be the case, the next screen will say “Confirm you current password”
  • Click on “Re-enter my password” and you will be redirected to ADFS and that’s were it will go wrong if FBA is not enabled

In both scenarios you will see the following error in the ADFS Event Log

image

Figure 4: Error In The ADFS Admin Event Log When FBA (In This Case) Is Not Enabled For The Intranet

Encountered error during federation passive request.

Additional Data

Protocol Name:
wsfed

Relying Party:
urn:federation:MicrosoftOnline

Exception details:
Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.InvalidAuthenticationTypePolicyException: MSIS7102: Requested Authentication Method is not supported on the STS.
   at Microsoft.IdentityServer.Web.Authentication.GlobalAuthenticationPolicyEvaluator.ProcessRequestedAuthMethodsV2(IEnumerable`1 requestedAuthMethods, HashSet`1 globalPolicyAuthProviders, String[] authProvidersInToken, Boolean& validAuthProvidersInToken)
   at Microsoft.IdentityServer.Web.Authentication.GlobalAuthenticationPolicyEvaluator.EvaluatePolicyV2(IList`1 mappedRequestedAuthMethods, IList`1 mappedRequestedACRAuthProviders, AccessLocation location, ProtocolContext context, HashSet`1 authProvidersInToken, Boolean isOnWiaEndpoint, Boolean& validAuthProvidersInToken)
   at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.RetrieveFirstStageAuthenticationDomainV2(Boolean& validAuthProvidersInToken)
   at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.EvaluatePolicy(Boolean& isLastStage, AuthenticationStage& currentStage, Boolean& strongAuthRequried)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthMethodsFromAuthPolicyRules(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthenticationMethods(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
   at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

Therefore: enable FBA for the Intranet in ADFS as soon as you install ADFS. If you want to enabled it later on, make sure first no application is impacted when the “Active Directory” IdP is used.

image

Figure 5: Authentication Methods For The Intranet In ADFS (WIA Enabled And FBA Enabled)

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), Forms Based AuthN, Windows Integrated AuthN | 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" for x86
        OR
      • the key "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Google\Chrome" for x64
        OR
      • Use ADM or ADMX templates to deploy the settings through a GPO. Get the templates from here.
    • 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 Chrome 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" for x86
        OR
      • the key "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Google\Chrome" for x64
        OR
      • Use ADM or ADMX templates to deploy the settings through a GPO. Get the templates from here.
    • In the first 2 cases, if the key "AuthServerWhitelist" 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 the following user agent strings are supported (retrieved through "(Get-AdfsProperties).WIASupportedUserAgents") by ADFS v3.0 and/or ADFS v4.0
    • MSAuthHost/1.0/In-Domain
    • MSIE 6.0
    • MSIE 7.0
    • MSIE 8.0
    • MSIE 9.0
    • MSIE 10.0
    • Trident/7.0
    • MSIPC
    • Windows Rights Management Client
    • MS_WorkFoldersClient
    • =~Windows\s*NT.*Edge
  • UPDATE 2016-07-05: You need to disable extended protection in ADFS if you still keep being prompted for credentials while configured all of the above. You are then most likely using a Chrome version lower than v51.*. For any Chrome version lower than v51.* you must disable Extended Protection to get WIA working in Chrome against ADFS!

  • UPDATE 2016-07-05: You do not need to disable extended protection in ADFS if you are using a Chrome version equal to or higher than v51.*. I can confirm that Chrome v51.0.2704.103 and Chrome v51.0.2704.106 supports WIA against ADFS 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 v51.0.2704.106, provided the shown user agent string and the yellow marked part matched what already was configured in ADFS

image

Figure 1: The User Agent String And Status Of Chrome v51.0.2704.106

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

$currentWIAUserAgentStrings = (Get-ADFSProperties).WIASupportedUserAgents

$newWIAUserAgentStrings = $currentWIAUserAgentStrings + "<Required User Agent String>" (e.g. $newWIAUserAgentStrings = $currentWIAUserAgentStrings + "Mozilla/5.0")

Set-ADFSProperties -WIASupportedUserAgents $newWIAUserAgentStrings

To remove any (new) configured user agent string from ADFS, while taking the existing user agent strings into account, use the following PowerShell commands on (primary) ADFS server:

Import-Module ADFS

[System.Collections.ArrayList]$currentWIAUserAgentStrings = (Get-ADFSProperties).WIASupportedUserAgents

$newWIAUserAgentStrings = $currentWIAUserAgentStrings

$newWIAUserAgentStrings.Remove("<Required User Agent String>") (e.g. $newWIAUserAgentStrings.Remove("Mozilla/5.0"))

Set-ADFSProperties -WIASupportedUserAgents $newWIAUserAgentStrings

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 | 1 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 the following user agent strings are supported (retrieved through "(Get-AdfsProperties).WIASupportedUserAgents") by ADFS v3.0 and/or ADFS v4.0
    • MSAuthHost/1.0/In-Domain
    • MSIE 6.0
    • MSIE 7.0
    • MSIE 8.0
    • MSIE 9.0
    • MSIE 10.0
    • Trident/7.0
    • MSIPC
    • Windows Rights Management Client
    • MS_WorkFoldersClient
    • =~Windows\s*NT.*Edge
  • 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 v42.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

$currentWIAUserAgentStrings = (Get-ADFSProperties).WIASupportedUserAgents

$newWIAUserAgentStrings = $currentWIAUserAgentStrings + "<Required User Agent String>" (e.g. $newWIAUserAgentStrings = $currentWIAUserAgentStrings + "Mozilla/5.0")

Set-ADFSProperties -WIASupportedUserAgents $newWIAUserAgentStrings

To remove any (new) configured user agent string from ADFS, while taking the existing user agent strings into account, use the following PowerShell commands on (primary) ADFS server:

Import-Module ADFS

[System.Collections.ArrayList]$currentWIAUserAgentStrings = (Get-ADFSProperties).WIASupportedUserAgents

$newWIAUserAgentStrings = $currentWIAUserAgentStrings

$newWIAUserAgentStrings.Remove("<Required User Agent String>") (e.g. $newWIAUserAgentStrings.Remove("Mozilla/5.0"))

Set-ADFSProperties -WIASupportedUserAgents $newWIAUserAgentStrings

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 | 1 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 the following user agent strings are supported (retrieved through "(Get-AdfsProperties).WIASupportedUserAgents") by ADFS v3.0 and/or ADFS v4.0
    • MSAuthHost/1.0/In-Domain
    • MSIE 6.0
    • MSIE 7.0
    • MSIE 8.0
    • MSIE 9.0
    • MSIE 10.0
    • Trident/7.0
    • MSIPC
    • Windows Rights Management Client
    • MS_WorkFoldersClient
    • =~Windows\s*NT.*Edge

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

$currentWIAUserAgentStrings = (Get-ADFSProperties).WIASupportedUserAgents

$newWIAUserAgentStrings = $currentWIAUserAgentStrings + "<Required User Agent String>"

Set-ADFSProperties -WIASupportedUserAgents $newWIAUserAgentStrings

To remove any (new) configured user agent string from ADFS, while taking the existing user agent strings into account, use the following PowerShell commands on (primary) ADFS server:

Import-Module ADFS

[System.Collections.ArrayList]$currentWIAUserAgentStrings = (Get-ADFSProperties).WIASupportedUserAgents

$newWIAUserAgentStrings = $currentWIAUserAgentStrings

$newWIAUserAgentStrings.Remove("<Required User Agent String>")

Set-ADFSProperties -WIASupportedUserAgents $newWIAUserAgentStrings

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