Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

In this part of the series, we’ll look at the required Hybrid Identity URLs that you want to add to the Intranet Sites list in Internet Explorer.

Note:
This is the first part for adding Microsoft Cloud URLs to Internet Explorer’s zone. In this part we look at the Local Intranet zone. In the next part we look at the Trusted Sites zone.

Note:
Adding URLs to the Local Intranet zone for Internet Explorer, also applies to Microsoft Edge.

Why look at the Intranet Sites?

Active Directory Federation Services (AD FS), and certain functionality in Azure Active Directory leverage Windows Integrated Authentication to allow for Single Sign-on. (SSO).

Single Sign-on reduces prompt fatigue in people and thus makes them more aware of the moments when password prompts happen and (and this is the theory…) paying more attention to what they are doing with their passwords.

I’m not a psychologist, but I do know how to make Windows Integrated Authentication work with Internet Explorer.

Intranet Sites vs. Trusted Sites (with Default settings)

Internet Explorer offers built-in zones:

• Local intranet
• Trusted sites
• Internet
• Restricted sites

Per zone, Internet Explorer is allowed specific functionality. Restricted Sites is the most restricted zone and Internet Explorer deploys the maximum safeguards and fewer secure features (like Windows Integrated Authentication) are enabled.

The Local intranet zone, by default, offers a medium-low level of security, where Trusted sites allows for medium-level security. By default, the Local intranet zone allows for the following functionality beyond the Trusted sites zone:

• Local intranet does not allow ActiveX Filtering
• Local intranet allows Scriptlets
• Local intranet allows accessing data sources across domains (Trusted sites prompt)
• Local intranet allows scripting of Microsoft web browser control
• Sites in the Local intranet zone don’t prompt for client certificate selection when only one certificate exists
• Sites in the Local intranet zone may launch applications and unsafe files
• Sites in the Local intranet zone may navigate windows and frames across different domains
• Local intranet sites do not use the Pop-up Blocker feature
• Local intranet sites do not use the Defender SmartScreen feature
• Local intranet sites allow programmatic clipboard access
• Local intranet sites do not use the XSS Filter feature
• Local intranet sites allow user authentication

Possible negative impact (What could go wrong?)

Internet Explorer’s zones are defined with specific default settings to lower the security features for websites added to these zones.

When you use a Group Policy object to add websites that don’t need the functionality of the Local intranet zone to the zone, the systems in scope for the Group Policy object are opened up to these websites. This may result in unwanted behavior of the browser such as browser hijacks, identity theft and remote code executions.

While this does not represent a clear and immediate danger, it is a situation to avoid.

Getting ready

The best way to manage Internet Explorer zones is to use Group Policy.

To create a Group Policy object, manage settings for the Group Policy object and link it to an Organizational Unit, Active Directory site and/or Active Directory domain, log into a system with the Group Policy Management Console (GPMC) installed with an account that is either:

• A member of the Domain Admins group, or;
• The current owner of the Group Policy Object, and have the Link GPOs permission on the Organizational Unit(s), Site(s) and/or Domain(s) where the Group Policy Object is to be linked, or;
• Delegated the Edit Settings or Edit settings, delete and modify security permission on the GPO, and have the Link GPOs permission on the Organizational Unit(s), Site(s) and/or Domain(s) where the Group Policy Object is to be linked.

The URLs to add

You’ll want to add the following URLs to the Local intranet zone, depending on the way you’ve setup your Hybrid Identity implementation:

https://<YourADFSFarmName>

When you use federation with Active Directory Federation Services (AD FS), the URL for the AD FS Farm needs to be added to the Local Intranet zone. As AD FS is authenticated against, it need to be added to the Local intranet zone as, by default, this is the only zone for websites to allow for user authentication.

https://login.microsoftonline.com

https://secure.aadcdn.microsoftonline-p.com

The https://login.microsoftonline.com and https://secure.aadcdn.microsoftonline-p.com URLs are the main URLs for authenticating to Microsoft cloud services. As these URLs are used to authenticate against, they need to be added to the Local intranet zone as, by default, this is the only zone for websites to allow for user authentication.

https://aadg.windows.net.nsatc.net

https://autologon.microsoftazuread-sso.com

If you use the Seamless Single Sign-On (3SO) feature in Azure AD Connect, then you’ll want to add the following URLS to the Local intranet zone:

1. https://aadg.windows.net.nsatc.net and
2. https://autologon.microsoftazuread-sso.com

These URLs need to be added to the Local intranet zone on all devices where people in the organization use the 3SO feature, as these are the URLs where they will authenticate against. Trusted sites, by default, do not allow this functionality.

If you don’t use the 3SO functionality, don’t add the above URLs.

https://account.activedirectory.windowsazure.com

It is still one of Microsoft’s recommendation to add the https://account.activedirectory.windowsazure.com URL to the Local intranet zone. However, an enhanced experience is available that no longer points employees to this URL, but instead to the https://myprofile.microsoft.com URL, that uses the normal authentication URLs.

The new enhanced experience is available in the Azure portal, under User settings, Manage user feature preview settings (in the User feature previews area) named Users can use preview features for registering and managing security info – enhanced.

If you’ve enabled the enhanced preview, don’t add the above URL.

How to add the URLs to the Local Intranet zone

To add the URLs to the Local Intranet zone, perform these steps:

• Log into a system with the Group Policy Management Console (GPMC) installed.
• Open the Group Policy Management Console (gpmc.msc)
• In the left pane, navigate to the Group Policy objects node.
• Locate the Group Policy Object that you want to use and select it, or right-click the Group Policy Objects node and select New from the menu.
• Right-click the Group Policy object and select Edit… from the menu.
  The Group Policy Management Editor window appears.
• In the main pane of the Group Policy Management Editor window, expand the Computer Configuration node, then Policies, Administrative Templates, Windows Components, Internet Explorer, Internet Control Panel and then the Security Page node.

• In the main pane, double-click the Sites to Zone Assignment List setting.
• Enable the Group Policy setting by selecting the Enabled option in the top pane.
• Click the Show… button in the left pane.
  The Show Contents window appears.

• Add the above URLs to the Local Intranet zone by entering the URL in the Value name column and the number 1 in the Value column for each of the URLs.
• Click OK when done.
• Close the Group Policy Editor window.
• In the left navigation pane of the Group Policy Management Console, navigate to the Organization Unit (OU) where you want to link the Group Policy object.
• Right-click the OU and select Link an existing GPO… from the menu.
• In the Select GPO window, select the GPO.
• Click OK to link the GPO.

Repeat the last three steps to link the GPO to all OUs that require it. Take Block Inheritance into account for OUs by linking the GPO specifically to include all people in scope.

Concluding

To enable functionality in a Hybrid Identity implementation, we need to open up the web browser to allow functionality for specific web addresses. By enabling the right URLs we minimize our efforts in enabling the functionality and also minimize the negative effect on browser security.

There is no need to add all the URLs to specific Internet Explorer zones, when you don’t need to functionality. However, do not forget to add the specific URLs when you enable specific functionality like Seamless Single Sign-on and remove specific URLs when you move away from specific functionality.

Further reading

Office 365 URLs and IP address ranges
Group Policy – Internet Explorer Security Zones
Add Site to Local Intranet Zone Group Policy

Most Microsoft-based Hybrid Identity implementations use Active Directory Federation Services (AD FS) Servers, Web Application Proxies and Azure AD Connect installations. In this series, labeled Hardening Hybrid Identity, we’re looking at hardening these implementations, using recommended practices.

In this part of the series, we’ll look at properly securing relying party trusts on AD FS servers in terms of the signature hash algorithm.

Note:
This blogpost assumes you’re running AD FS Servers as domain-joined Server Core Windows Server 2016 installations.

Why look at the signature hash algorithm for AD FS Relying Party Trusts

Active Directory Federation Services (AD FS) signs its tokens to relying party trusts, like Azure Active Directory to ensure that they cannot be tampered with.

This signature can be based on SHA1 or SHA256. Azure Active Directory supports tokens signed with an SHA256 algorithm since October 2016, and recommends setting the token-signing algorithm to SHA256 for the highest level of security.

Reasons why

Federation servers require token-signing certificates to prevent attackers from altering or counterfeiting security tokens in an attempt to gain unauthorized access to federated resources.

The private/public key pairing that is used with token-signing certificates is the most important validation mechanism of any federated partnership because these keys verify that a security token was issued by a valid partner federation server and that the token was not modified during transit.

It would be a shame if information could be created that would unlock the information encrypted through a collision attack, but that’s exactly what Google announced on February 2017 for SHA1 certificates after two years of research in collaboration with the CWI Institute in Amsterdam.

This collision attack urges to move from SHA1 to safer alternatives, such as SHA256.

Possible negative impact (What could go wrong?)

If changing the AD FS token-signing hash algorithm for AD FS relying party trusts to SHA256 goes wrong, the functionality of the relying party trust becomes unavailable, in other words; access to the application or all applications connected to the platform on the other side of the relying party trust becomes unavailable.

If the AD FS token-signing hash algorithm for AD FS relying party trusts to SHA256 change goes wrong for the ‘Microsoft Office 365 Identity Platform’ relying party trust, then access to popular functionality like Exchange Online, SharePoint Online, Teams, PowerBI and Dynamics 365 is lost and needs to be rebuild.

Getting Ready

To change the AD FS token-signing hash algorithm for AD FS relying party trusts to SHA256, make sure to meet the following requirements:

System requirements

Make sure the AD FS servers are installed with the latest cumulative Windows Updates.

Privilege requirements

Make sure to sign in with an account that has privileges to create and/or change and link Group Policy objects to the Organizational Unit (OU) in which the AD FS servers reside.

Who to communicate to

As the AD FS servers operate as part of a chain, notify all stakeholders in the chain. This means sending a heads-up to the rest of the Active Directory team and the teams that are responsible for Azure AD, Office 365 and cloud applications. It’s also a good idea to talk to the people responsible for backups, restores and disaster recovery.

Important:
It is especially important to communicate to the teams that are responsible for the functionality connected through AD FS, as you must use the same algorithm for the AD FS RPT as the service provider on the other side of the RPT is expecting, SHA-1 or SHA-256, to generate the hash.

One of the challenges you can easily avoid through communications is that multiple persons and/or teams make changes to the configuration. When it breaks, you don’t want to roll-back a bunch of changes, just the one that broke it. Make sure you have the proper freeze/unfreeze moments to achieve that.

How to do it

To get an overview of the AD FS RPTs that do not use SHA256 as the AD FS token-signing hash algorithm, run the following line of Windows PowerShell when logged on with an account that has local administrative privileges on the Primary AD FS server:

Get-AdfsRelyingPartyTrust | select Name,SignatureAlgorithm

This will provide the names of the RPTs and their SignatureAlgorithm properties.

You can change the AD FS token-signing hash algorithm for an AD FS relying party using the following lines of Windows PowerShell when logged on with an account that has local administrative privileges on the Primary AD FS server:

$RPT = ‘Microsoft Office 365 Identity Platform’

Set-AdfsRelyingPartyTrust -TargetName $RPT –SignatureAlgorithm `
‘http://www.w3.org/2001/04/xmldsig-more#rsa-sha256′

Roll-back

To roll back the change, run the following lines of PowerShell when logged on with an account that has local administrative privileges on the Primary AD FS server:

$RPT = ‘Microsoft Office 365 Identity Platform’

Set-AdfsRelyingPartyTrust -TargetName $RPT –SignatureAlgorithm `
‘http://www.w3.org/2000/09/xmldsig#rsa-sha1‘

Concluding

Changing the AD FS token-signing hash algorithm for AD FS relying party trusts to SHA256 from SHA1 provides a much smaller risk of collisions and therefore increases information security.

Make sure the service providers offering functionality through AD FS relying party trusts support SHA256 as the token-signing hash algorithm before changing it to avoid (temporary) loss of functionality.

Further reading

Change signature hash algorithm for Office 365 relying party trust
Token-Signing Certificates
Configuring the AD FS Token Signing and -Decrypting Certs for a longer lifetime