site to zone assignment list sso

a blog by Sander Berkouwer

The things that are better left unspoken

HOWTO: Add the required Hybrid Identity URLs to the Local Intranet list of Internet Explorer and Edge

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

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

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.

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.

5 Responses to HOWTO: Add the required Hybrid Identity URLs to the Local Intranet list of Internet Explorer and Edge

If you use the GPO methode (S2ZAL) the zone get's 'locked' so the user cannot add url's to the zone himself. If you want them to allow this ( yeah i know this shoudln't be 🙂 ) you can use a reg import with GPO Preferences instead.

Yes, indeed you can.

Very well done and written! I've only just begun writing myself just recently and realized that a lot of blogs merely rework old content but add very little of worth. It's good to see a beneficial post of some true valuue to your readers and I. It is actually going down on the list of things I need to emulate being a nnew blogger. Visitor engagement and content quality are king. Many great ideas; you've unquestionably made it on my list of sites to follow!

Continue the great work!

it's done,work fine,thanks you

Nice detail, well explained. Good work.

leave your comment cancel

This site uses Akismet to reduce spam. Learn how your comment data is processed .

Search this site

Dirteam.com / activedir.org blogs.

Strategy and Stuff
Dave Stork's IMHO
The way I did it
Sergio's Shack
Things I do
Tomek's DS World

Microsoft MVP (2009-2024)

Veeam vanguard (2016-2024), vmware vexpert (2019-2022).

Xcitium Security MVP (2023)

Configure Azure Active Directory Single Sign-On (SSO)

Updated on June 16, 2022
Hybrid , Microsoft 365 , Microsoft Entra

You installed Azure AD Connect and want to configure Azure Active Directory Single Sign-On (SSO). It’s a great feature so that users can get a seamless single sign-on experience when accessing cloud services from their domain-joined desktop machines. In this article, you will learn how to set up Azure Active Directory Single Sign-On.

Install azure ad connect, upgrade azure ad connect to latest version, configure firewall, enable modern authentication, step 1. enable single sign-on in azure active directory connect, step 2. verify single sign-on is active, policy 1: site to zone assignment list, policy 2: allow updates to status bar via script, step 4. sso browsers compatibility, test azure active directory sso, azure active directory single sign-on prerequisites.

Before you start to enable the feature Azure Active Directory Single Sign-On, you have to check that the organization meets the AAD SSO prerequisites.

You need to install and configure Azure AD Connect before you proceed further. If you already have Azure AD Connect in the organization, we recommend you upgrade to the latest Azure AD Connect version. See the next step.

The below articles will help you to upgrade Azure AD Connect to the latest version:

Upgrade Azure AD Connect
Upgrade Azure AD Connect to V2.x
Migrate Azure AD Connect to new server

Add the below URL in the firewall allow list between Azure AD Connect server and Azure AD:

*.msappproxy.net over port 443

Go through the article enable modern authentication in Microsoft 365 :

Enable Modern Authentication in the Microsoft 365 tenant
Configure the registry key on the clients to support modern authentication

How to configure Azure Active Directory Single Sign-On

To configure AAD SSO, follow these steps:

To enable Azure Active Directory Single Sign-On in Azure AD Connect, follow these steps:

Start Azure AD Connect . Click on Configure .

Click on Change user sign-in . Click Next .

Fill in your Azure AD global administrator or hybrid identity administrator credentials . Click Next .

Check the checkbox Enable sign sign-on . Click Next .

Azure Active Directory enable single sign-on

Enter your domain administrator account credentials . Click Next .

Azure Active Directory enable single sign-on enter domain administrator credentials

Check the checkbox Start the synchronization process when configuration completes . Click Configure .

Azure Active Directory ready to configure

Click on Exit .

Azure Active Directory configuration complete

Click on Menu > Azure Active Directory .

Select Azure AD Connect . Verify that the Seamless single sign-on feature appears as Enabled .

Azure AD Connect Seamless Single sign-on

Start Active Directory Users and Computers . Go to the default Computers container. Verify that the computer account AZUREADSSOACC appears.

Note: Seamless SSO creates a computer account named AZUREADSSOACC in your on-premises Active Directory (AD) in each AD forest. The AZUREADSSOACC computer account needs to be strongly protected for security reasons. Only Domain Admins should be able to manage the computer account. Ensure that Kerberos delegation on the computer account is disabled and that no other account in Active Directory has delegation permissions on the AZUREADSSOACC computer account. Store the computer account in an Organization Unit (OU) where they are safe from accidental deletions and where only Domain Admins have access.

Step 3. Configure Group Policy

There are two group policies to configure. Follow the steps below:

Start Group Policy Management .

Create a new group policy or edit an existing policy .

Browse to User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page .

Double-click on Site to Zone Assignment List .

Click on Enabled to enable the policy. Then, click on Show .

Enter the below Azure AD URL in the zone assignments:

https://autologon.microsoftazuread-sso.com with value 1

Browse to User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone .

Double-click on Allow updates to status bar via script .

Click on Enabled to enable the policy. Then, click on Enable .

Allow updates to status bar via script enable

Suppose there are different web browsers in the organization. You need to configure settings for each browser. Read the Microsoft browser considerations section .

Sign in on a domain-joined computer and start the Microsoft Edge browser. Navigate to https://myapps.microsoft.com/tenant.onmicrosoft.com.

In our example, it’s https://myapps.microsoft.com/exoip365.onmicrosoft.com .

You don’t have to add the username or password; it will automatically sign in.

You did successfully configure AAD SSO in the organization.

Read more: Find Azure AD Connect accounts »

You learned how to configure Azure Active Directory Single Sign-On (SSO). Ensure that the organization meets the prerequisites before you set up Azure AD SSO. Always test the configuration when deployed. From now on, the users automatically sign in and don’t have to fill in their credentials whenever they connect to cloud services from their domain-joined machine.

Did you enjoy this article? You may also like Configure Microsoft Entra Password Protection for on-premises . Don’t forget to follow us and share this article.

ALI TAJRAN is a passionate IT Architect, IT Consultant, and Microsoft Certified Trainer. He started Information Technology at a very young age, and his goal is to teach and inspire others. Read more »

What Others Are Reading

How to fix Azure AD Connect Sync Service not running

When we start the Azure AD Connect application, it shows the error: Sync Service is…

You want to enable Azure AD Multi-Factor Authentication. There is a per-user MFA and Conditional…

Create Microsoft Entra ID Users from CSV with PowerShell

We like to create new Microsoft Entra ID users in the company. Going through the…

This Post Has 2 Comments

This is a very informative article.

Can the AZUREADSSOACC computer object be moved from the default OU to another? As what would be the right process and requirements before doing so?

Hello, i have an error “Cannot retrieve single sing-on status”.

Setting up Single Sign On (SSO) with Azure AD Connect

With the new version of Azure AD Connect you can enable the Single Sign-On option in combination with either Password synchronization or Pass-through Authentication. When enabled with Modern Authentication for Office 2016 users only have to type their username and do not need to type their password to sign in to Office applications of other cloud services when their machine is connected to the domain.

Setting up SSO with Password Sync

Download the latest version of Azure Active Directory Connect . If you already have Azure AD Connect installed you can do an in-place upgrade and then reconfigure the settings.
Logon as a domain administrator
Select Custom Installation so that you can enable Single Sign-On on the user sign-in page
Select Password Synchronization and Enable Single Sign on
Click configure to finish the setup

Add endpoints to Intranet Zone

The following URL’s need to be explicitly added to the machine’s Intranet Zone. This settings makes sure that the browser sends the currently logged in user’s credentials in the form of Kerberos ticket to Azure AD.

Best way to do this is to create a GPO:

Create a GPO that’s applied to all users or add it to an existing Internet Explorer settings GPO
Go to User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page and select Site to Zone Assignment List
https://autologon.microsoftazuread-sso.com > 1
https://aadg.windows.net.nsatc.net > 1

Modern Authentication

Modern Authentication in Office 365 is needed for users to experience the single sign-on feature in Outlook (Office 2013 / 2016) and Skype for Business. It also enables features like MFA (Multi Factor Authentication), Smart-Card and Certificate-based Authentication.

By default Modern Authentication is only enabled for Sharepoint-Online, for Exchange Online and Skype for Business it’s turned of.

Enable modern authentication for Exchange Online

Connect to Exchange Online Powershell, you can use this connector script or run the following code:

Run the following command the enable modern authentication

Verify the settings with

Enable modern authentication for Skype for Business

Connect to Skype for Business Online Powershell, or again use one the connector script .

And verify the settings with

References and more informatie

If you want to know more about SSO and Modern Authentication you can check the following pages:

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-sso
https://support.office.com/en-us/article/Enable-Exchange-Online-for-modern-authentication-58018196-f918-49cd-8238-56f57f38d662?ui=en-US&rs=en-US&ad=US&fromAR=1
https://social.technet.microsoft.com/wiki/contents/articles/34339.skype-for-business-online-enable-your-tenant-for-modern-authentication.aspx

How to Turn Off Google AI search

How to Install Active Directory Users and Computers (ADUC)

Manage your Active Directory with ADManager Plus

2 thoughts on “setting up single sign on (sso) with azure ad connect”.

Hallo Ruud,

The domain & tenant I tried your commands on has AAD Connect & password hash sync & single sign-on enabled through the AAD connect wizard. Also 2FA is enabled. Also: I’m a PS newbie. While trying to connect to the O365 services with PS I get errors like: Connect-AzureAD : One or more errors occurred.: AADSTS50076: Due to a configuration change made by your administrator, or because you moved to a new location, you must u se multi-factor authentication to access ‘00000002-0000-0000-c000-000000000000’. Trace ID: 6ab93417-1b1c-436f-8a6c-c3f267311e00 Correlation ID: 5fb369b8-fd18-4032-ab62-57158eb9d6f7 Timestamp: 2019-08-07 13:11:06Z At line:1 char:1 + Connect-AzureAD -Credential $credential + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : AuthenticationError: (:) [Connect-AzureAD], AadAuthenticationFailedException + FullyQualifiedErrorId : Connect-AzureAD,Microsoft.Open.Azure.AD.CommonLibrary.ConnectAzureAD

Connect-AzureAD : One or more errors occurred. At line:1 char:1 + Connect-AzureAD -Credential $credential + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + CategoryInfo : AuthenticationError: (:) [Connect-AzureAD], AggregateException + FullyQualifiedErrorId : Connect-AzureAD,Microsoft.Open.Azure.AD.CommonLibrary.ConnectAzureAD

It seems I need to use other methods to connect to a tenant once it has AAD Connect, SSO and 2FA enabled. Any suggestions?

Thanks for any useful guidance.

Regards, Bavo

Can’t you use the Microsoft app password? I use it a lot with PowerShell scripts if MFA isn’t working / showing the dialog

Configuring Azure Active Directory Single Sign-On (SSO) with Azure AD Connect

If you haven’t synced your local Active Directory to Microsoft 365 via Azure Cloud Connect, you can start here . If you have but haven’t enabled SSO to simplify the process, you are missing out on something big.

With Azure AD SSO, you don’t have to type in your passwords to sign in to Azure AD, and most of the time, you don’t even need to type the username. You log into a domain-joined computer with your own credential and that’s all you need to get all apps ready, including Edge, Office apps, and Teams.

Open Azure AD Connect, click Configure, then Change user sign-in option, and go Next.

You will need to type a Domain Admin credential as well to finish the process.

Once the sync is finished, you can check the Azure AD to make sure if the single sign-on is enabled.

Next step is to add the following URL in the Intranet Zone via Group Policy.

The policy is called Site to Zone Assignment list under

While we are here, let’s also enable Allow updates to status bar via script under Intranet Zone

Finally, if you are using the new Edge browser, add the same Azure AD’s URL to the Specifies a list of servers that Microsoft Edge can delegate user credentials to the following place.

That’s about as simple as I can put out. If all goes well, it does work like a charm.

Azure AD Connect: Seamless Single Sign-On – How it works | Microsoft Docs

Azure AD Connect: Seamless Single Sign-On – quickstart | Microsoft Docs

Microsoft 365 Tech blog

AADC , ADFS , Azure AD , IAM , SSO

Configure SSO with Office 365

In Azure there are a lot of Single Sign-On (SSO) options. Many early adopters in cloud use ADFS based on that SSO was not a part of AD Connect at the beginning. Today we have more than one solution to choose between.

Active Directory Federation Services (ADFS) This is an on-premies solution that is important if you need to move the sign-in to local Active Directory. You can do it with PTA today also witch is a part of AD Connect configuration. Another need to use ADFS today is smartcards but it will come to Azure AD in the future.

Seamless Single-Sign On Works with all Windows 7 and above. The solution is built on local AD joined computers that are signed in to the domain on local network. Some web-sites appear with SSO and Office packages activates with this function.

Azure AD Hybrid Join (PRT token) This is the solution to use today if you run Windows 10. It works with downgrade computers like Windows 7, 8 and 8.1 with a client installed. You can sign-in from the computer everywhere and get SSO. We will cover this setup later.

Workplace Join (AD registration) Primary audience is bring your own device (BYOD). If you not run Azure AD Hybrid Join or sign-in from a computer in workgroup you asked for AD registration. The user store the computer account in Azure to get SSO to Office 365. In enterprise environment this is not a solution you want to use. From Windows 10 1803 you can block this function in enterprise environment and replace with Azure AD Hybrid Join.

Azure AD Joined The computer is connected to Azure AD directly and get SSO to Office 365/Azure.

My personal recommendations today is to configure AD Connect SSO together with Azure AD Hybrid Join. SSO works with all downgrades and Azure AD Hybrid Join with native Windows 10.

Configure Azure AD Seamless Single-Sign On Start to configure Seamless Single sign-on in AD Connect Wizard. Change user sign-in

Enable Single Sign-On, Next, Sign-in with local domain credentials. AD Connect is now ready to enabled computers with SSO but all users need to update intranet zone to get this function to work. The setup create a computer account ( AZUREADSSOACC ) in each AD forest.

Add endpoints to Intranet Zone The following URL need to be explicitly added to the machine’s Intranet Zone. This settings makes sure that the browser sends the currently logged in user’s credentials in the form of Kerberos ticket to Azure AD.

Best way to do this is to create a GPO:

Create a GPO that’s applied to all users or add it to an existing Internet Explorer settings GPO
Go to User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page and select Site to Zone Assignment List
https://autologon.microsoftazuread-sso.com > 1

Read more about the configuration in Microsoft doc. https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso-quick-start Block Workplace Join In 1803 and above releases, the following changes have been made to avoid this dual state. This is very important in all environment. Before any migration between tenants it´s recommended to upgrade Windows 10 to at minimum 1803 to support removal of dual state. HKLM\SOFTWARE\Policies\Microsoft\Windows\WorkplaceJoin, “BlockAADWorkplaceJoin”=dword:00000001 In next blog you can read more about to setup Azure AD Hybrid Join (PRT token ) https://cloudtech.nu/2020/03/09/configure-hybrid-azure-ad-joined-with-ad-connect/

Seamless Single Sign-on in Azure Active Directory

Azure Active Directory ( Azure AD ) Seamless Single Sign-On allows users to log in via SSO on their computers "connected" to the local and Azure Active-Directory to the Microsoft 365 cloud services.

Want to increase your organization's productivity with a very low IT effort. Then this must be one of the Microsoft 365 features you want to turn on!

Technical requirements

If you already have a Office 365 environment today, and you have already synced all AD objects, you can go to the next step.

If you don't have Office 365 yet , but are ready to migrate you can find the 4-step Azure AD connect installation instructions can be found here.

If you do not have a tenant , please create one through this way.

Configure Azure AD for Seamless Single sign-on

Select configure

Click on Change User Sign-in

Change from: Password Hash Synchronization

To: Pass-through Authentication + Single Sign-on.

Select Next

Click Configure

Configure the necessary GPO

Step 1 - Open Group Policy Management and create a new GPO

Call the GPO however you like

Step 2: Create a Site To Zone assignment list

Navigate to user configuration > policies > management templates > Windows Features > Internet Explorer > Internet configuration screen > Security page . Then select the list site to zone assignment .

Or in English according to the screenshot below.

https://docs.microsoft.com/nl-be/azure/active-directory/hybrid/media/how-to-connect-sso-quick-start/sso6.png

Put this value: https://autologon.microsoftazuread-sso.com

Value (data): 1

Step 3: Add the allow updates to status bar via script.

Browse to user configuration > policy > management templates > Windows Features > Internet Explorer > Internet configuration screen > The security page > intranet zone. Then select Allow updates for status bar via script.

Step 4: Set a registry entry for the autologon - HTTPS

Browse to user configuration > for labels > Windows settings > Registry > New > registry entry.

Enter the following values in the appropriate fields and click OK .

Key path: SoftwareMicrosoftWindowsCurrentVersionInternet SettingsMapDomainsMicrosoftazuread-SSO.comautologon

Value name : https .

Value type : REG_DWORD .

Value data : 00000001 .

Test your policy

For Firefox, Safari (MacOS), Chrome etc you also want to make sure you have SSO. Then take a look at this link with more information.

Related tips

📘 tutorial: how to create your own microsoft office 365 tenant , how to reset a windows 11 device in windows autopilot thanks to microsoft intune, this is how to activate and use windows laps in microsoft entra, how to change the language in windows 10 to belgium - dutch, shortcut keys in onenote for windows 10, how to automatically add microsoft 365 licenses to azure ad groups. dynamically, statically or with security groups.

Tu devrais ajouter le chemin complet de la clé de registre -> Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoftazuread-sso.com\autologon

Merci encore tu régales!

Subscribe via email

Enter your email address to subscribe to this blog and receive email notifications of new posts.

Email address

Azure Active Directory
Fun - having fun with Microsoft 365!
Microsoft 365 general
Microsoft Azure
Microsoft Copilot
Microsoft Exchange
Microsoft Intune
Microsoft OneDrive
Microsoft SharePoint
Microsoft Teams
Office 365 Admin
Office 365 Security

What Is Seamless Single Sign On (And How to Set It up in Microsoft 365)

Single sign on (SSO) is an authentication method that lets you use a single username and password to access multiple applications. Seamless SSO occurs when a user is automatically signed into their connected applications when they’re on corporate desktops connected to the corporate network.

The benefits of seamless SSO are many. Not only does seamless SSO limit the number of times your end users need to enter their login credentials, it also helps improve your overall security posture by implementing authentication systems beyond a username and password.

The best use case for seamless SSO is a hybrid environment, where your team is working on applications both in the cloud and on-premises. To establish a trust between the on-premises and cloud environments, you’ll need to use Azure AD Connect.

In this blog, we’ll walk through how to implement SSO in Microsoft 365.

Before You Start

Before you implement SSO in Microsoft 365, ensure your system meets the prerequisites. We recommend reviewing Microsoft’s documentation , but here’s a brief overview of what you’ll need:

An Azure AD tenant, with the domain you plan to use added and verified
On-premises Active Directory (schema version and forest functional level must be Windows Server 2003 or later, and domain controller must be writeable)
PowerShell execution policy must allow running scripts (recommended policy is “RemoteSigned”)
Azure AD Connect must be installed on a domain-joined Windows Server 2016 or later (can’t be installed on Small Business Server, Windows Server Essentials before 2019, or Windows Server core)

Configuring Azure AD Connect

When you have everything on the prerequisites list checked off, its time to spin up Azure AD Connect installation wizard. Select the customize option instead of express settings. Click through the user sign-in step – this step will give you the option to enable SSO, but only if you choose Password Synchronization or pass-through authentication as the sign on method. Choose one of these methods, as the use cases for the other options are relatively specific (for instance, if you’re a large organization with many domain controllers and a requirement for your own federation, you should select Federation with AD FS as a sign on method). Don’t forget to ‘Enable SSO’ before you leave this step!

Next, you’ll connect Azure AD Connect to Azure AD:

Log in with your global or hybrid identity admin credentials
Connect your on-premises directories or forests
Configure Azure AD sign-in (typically use “userPrincipalName”)

Now you need to decide what you want to sync by way of domains and OUs. Its doubtful you’d want to sync everything from on-premises into the cloud, and it can get messy fast if you select items to sync that it turns out later you don’t need.

Select ‘Sync selected domains and OUs’ and check off what you need to sync.
Identifying users, filtering, and optional features can be left for now.

Enabling SSO

Now you’ll need to enable SSO. You’ll need your domain administrator credentials to configure your on-premises forest for use with SSO.

If everything looks good to this point, click “Install”. Note that synchronization has not been enabled here; there’s additional configuration to complete before adding users.

When you receive the “Configuration is complete” message, Azure AD Connect is installed and configured! Take a look within Azure AD:

Editing Your Group Policy

Next, log into the server manager and open the Group Policy Management editor. You’ll need to edit the group policy that’s applied to some or all of your users, which handles where users are sent (Intranet or Internet) when they navigate to URLs from the browsers.

You can find more information about editing your group policy here , but we’ll outline the steps below:

Go to “User Configuration”, then “Policies”, then “Administrative Templates”, “Windows Components”, “Internet Explorer”, “Internal Control Panel”, and finally “Security Page”
Select site to “Zone Assignment List” and enable the policy
Enter the following values:
Value name: https://autologon.microsoftazuread-sso.com
Value (data): 1
Click “OK”, then “OK” again
Go to “User Configuration”, then “Policies”, “Administrative Templates”, “Windows Components”, “Internet Explorer”, “Internet Control Panel”, “Security Pages”, then “Intranet Zone”
Select “Allow updates to status bar via script”
Enable the policy setting
Click “OK”

Go to “User Configuration”, then “Preferences”, “Windows Settings”, “New”, then “Registry item”
Enter the following information:
Key Path: Key Path: Software\Microsoft\Windows\CurrentVersion\Internet\Settings\ZoneMap\Domains\microsoftazuread-sso.com\autologon
Value name: https
Value type: REG_DWORD
Value data: 00000001
Click “OK”

Enabling Sync

Lastly, you’ll need to enable sync by following these steps:

Open PowerShell
Enter “Get-adsyncscheduler”
This should provide text which includes “Syncenabled = false”
Set “adsyncshceduler -syncenabled $true”
You should now see “Syncenabled = true”

Testing the Solution

To check if all your hard work has paid off, go to the sync service manager. Under “Connection Operations”, select your Azure AD name. Under “Statistics”, the number of adds should equal the number of objects synced from Active Directory to Azure AD via Azure AD Connect.

If that didn’t work, try “start-adsynccycle -policytype initial” in PowerShell.

Conclusion

SSO, and seamless SSO in Microsoft 365, have the ability to improve your end user experience, productivity, and security at your organization. We strongly recommend implementing SSO for your business.

Need assistance getting started? We can help! Get in touch with us at regroove.ca.

cloud first
cloud solutions
cybersecurity
Microsoft 365
Microsoft Licensing
Productivity
remote work

Remote work is here to stay: essential hardware for a microsoft 365-powered home office .

Three years into working from home means its likely time to update your home office hardware to help fuel productivity!

Optimizing Your Microsoft 365 Experience: A Guide to Choosing the Right Laptop

In the world of modern work, having the right tools can make all the difference for productivity and efficiency. To unlock Microsoft 365's potential, its important to choose the right laptop.

Microsoft To Do and Planner: Basic Project Management Tools You Can Start Using Right Now

Learn how to use Microsoft To Do and Planner to stay on top of tasks and organized for not only yourself, but your organization as well.

OneNote: The Better Way to Take Meeting Notes

How can Microsoft OneNote be used to collaborate on meeting minutes?

Cyber Security Insurance 101: A Fast-Track Overview and Key Considerations

As cyber threats continue to evolve, more organizes are investing in cyber security insurance (CSI) and security assessments. But what is CSI?

How to Implement a 'Meeting-Free Day' for Your Business

Thinking about implementing a meeting-free day at your organization? Check out how Regroove successfully accomplished it with Microsoft 365!

Navo - The company directory for the connected workplace.

Centrally organize all key company bookmarks to keep your team connected to the right resources, across workspaces and devices.

Newsletter sign-up

Configuring Windows clients for single sign-on (SSO) with Kerberos logins

Starting with UCS 4.3, it’s possible to use Kerberos as authentication for SSO enabled services.

This means that users log in to a Windows machine with their domain account and are automatically signed in to the UMC and other configured service providers. However, there are two settings in Windows that need to be changed for this to work. This can be achieved with a group policy object in Samba. Windows clients must be joined to the domain for this to work.

Note : Single sign-on won’t work if a HTTPS connection to ucs-sso.your-domain.tld is not possible, e.g. if the certificate is not trusted. How to import UCS root CA on Windows clients

Note: We will add the UCS identity provider to Windows’ trusted sites. These trusted sites are used by Chrome and Internet Explorer . The following has no effect on other browsers at the time of this writing, because they don’t utilize Windows trusted sites in the same way. Currently, it’s not possible to configure SSO for Edge.

Note: Make sure that SSO works in your environment before configuring this to avoid debugging in the wrong place.

Configure univention-negotiate

For the following to work, the UCR variable saml/idp/authsource has to be set to “univention-negotiate”:

Chrome, Internet Explorer

Create a group policy.

Creating Windows group policies works the same in Samba as in a Windows AD domain.

Install the Remote Server Administration Tools (RSAT) on a Windows client in the domain and run the “Microsoft Group Policy Management Tool”.

The RSAT Tools are available for Windows 10 and Windows 7 .

After the RSAT tools are installed, you need to activate the Group Policy Management Tools . Click the Start button and run Turn Windows features on or off . Browse to

Remote Server Administration Tools -> Feature Administration Tools -> Group Policy Management Tools

and activate the checkbox. Click OK .

Now, you can run Group Policy Management from the Start button. In the Group Policy Management Tool, expand Forest:YourForestName , expand Domains , expand YourDomainName , and then click Group Policy Objects .

Click Action, and then click New .

Add identity provider to trusted sites

Firstly, the UCS identity provider has to be added to Windows’ trusted sites.

Right click and choose “Edit” on your group policy. A hierachical structure of settings opens. Browse to:

User Settings -> Policies -> Administrative Templates -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page

Double-click on Site to Zone Assignment List , select Enable and click Show to edit the list.

Add the following to your list and click OK . example.intranet is our domain in this example.

This method will grey out the assignment list on the Windows clients, so users can’t remove or add anything themselves.

Allow authentication with trusted sites

Now that we’ve added the UCS identity provider to trusted sites, we need to enable authentication for them. Edit your group policy and browse to:

User Settings -> Administrative Templates -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page -> Trusted sites zone

Double-click on Logon options , select Enable and choose Automatic Logon with current username and password in the drop-down menu in the Options area. Click OK .

Link the GPO to your domain

To make sure that the GPO is applied, you have to link it to your desired domain or OU. Right-click on the domain or OU and select Link an Existing GPO . Choose your newly created GPO and click OK .

As mentioned above, Firefox doesn’t utilize Windows trusted sites as Chrome and IE do. The configuration has to be applied in Firefox’ own configuration.

Open about:config in Firefox. You will be presented with a list of settings parameters and a search mask. Again, dc=example,dc=intranet is our LDAP base in this example. Use the mask to search for the following parameters and apply the accompanying value:

Once the user logs out on a web page configured for SSO (for example the UMC), single sign-on will not be automatically performed using the Kerberos login until the next time the user logs in using Kerberos. Users will simply be prompted for their credentials on e.g. the UMC, if they decide to login again without having logged out and in to Windows before.

an endpoint admin's journal

Recent Posts
Popular Posts
Recent Comments

Deploy Trusted sites zone assignment using Intune

November 6, 2023

Zoom Desktop Client – Download older build versions from Zoom

October 31, 2023

Uninstall Teams chat app using remediation script and a configuration profile in Intune

October 30, 2023

Intune Last Check-in date not updating for Windows device

October 25, 2023

How to use Event Viewer to check cause of Blue screen of Death (BSOD)

October 23, 2023

5 Quick Mac OS Terminal commands to make a Mac user life easier

Powershell : Find disabled users and computers in AD

Active Directory (1)
Windows (7)
November 2023
October 2023

Deploy a set of trusted sites overriding users’ ability to add trusted sites themselves. To acheive this, an Intune configuration profile Trusted site zone assignment can be deployed to devices/users group as required.

Hit the Create button and Select New policy

From the Create a profile menu, select Windows 10 and later for Platform , Templates for Profile type. Select Administrative templates and click Create .

Give the profile desired name and click Next .

In Configurations settings, select Computer Configuration and search for keyword “ Site to Zone “, Site to Zone Assignment List setting will be listed under search results. Go ahead click on it to Select it.

Once selected, a Site to Zone Assignment List page will appear on right side explaining different zones and values required for these zone for setup. Since this profile is being used for trusted sites, we will use the Value “2” . Go ahead and select Enabled button and start entering the trusted sites as required. please ensure to set each value to “2” . See example below:

Once done adding the list of sites, click OK to close it and Hit Next on Configuration settings page.

Add Scope tags if needed.

Under Assignments , Click Add groups to target the policy deployment to specific group of devices/users. You can also select Add all users / All all devices .

Hit Next . Then Hit Review + Save button to save.

Tags: Intune Windows

[Windows 10] How to completely uninstall Flash player

Previous Zoom Desktop Client – Download older build versions from Zoom

thanks! I was just looking for this exact solution!

For users to be transparently authenticated in AD FS SAML Integration, do the following:

Enabling NTLM Authentication (Single Sign-On) in Internet Explorer & Chrome

Option I: Through Group Policy Object

Open the Group Policy Management Console. Create either a new Group Policy Object (GPO) or edit an existing GPO.
Expand Computer Configuration , expand Policies , expand Administrative Templates , expand Windows Components , expand Internet Explorer , expand Internet Control Panel , and then click Security Page .
In the details pane, double-click Site to Zone Assignment List .
In the Site to Zone Assignment List Properties dialog box, click Enabled .
In the Site to Zone Assignment List Properties dialog box, click Show .
In the Show Contents dialog box, click Add .
In the Add Item dialog box, type the ADFS URL of SAML SSO service (for example, https://cwaserver.contoso.com) in the Enter the name of the item to be added box.
Type 1 (indicating the local intranet zone) in the Enter the value of the item to be added box, and then click OK .
In the Show Contents dialog box, click OK .
In the Site to Zone Assignment List dialog box, click OK .
In the Group Policy Management Editor, click Intranet Zone .
In the details pane, double-click Logon options .
In the Logon options Properties dialog box, click Enabled .
In the Logon options list, click Automatic logon only in Intranet zone , and then click OK .
Close the Group Policy Management Editor.

Option II: Through Internet Explorer Browser

Open the Internet Options dialog box by choosing Internet Options either from Control Panel or from the Tools menu in Internet Explorer.
In the Internet Options dialog box, on the Security tab, select Local intranet , and then click Custom Level .
In the Security Settings dialog box, under Logon , select Automatic logon only in Intranet zone , and then click OK .
In the Internet Options dialog box on the Security Settings tab with Local intranet still selected, click Sites .
In the Local intranet dialog box, click Advanced .
In the next dialog box (also titled Local intranet ), type the URL of your Communicator Web Access site (for example, https://cwaserver.contoso.com) in the Add this Web site to the zone box, and then click Add .
In the Local intranet dialog, box click OK .
In the original Local intranet dialog box, click OK .
In the Internet Options dialog box, click OK .

Reference: Configuring Internet Explorer for Automatic Logon

Enabling NTLM Authentication (Single Sign-On) in Firefox

For the complete details, refer to the article Enabling NTLM Authentication (Single Sign-On) in Firefox

Enabling NTLM Authentication for AD FS 3.0 in Windows Server 2012 and 2012 R2

Enable Windows Authentication for AD FS 3.0.

Refer to the following articles:

Configuring authentication policies for AD FS
Enabled Forms Based Authentication in ADFS 3.0

Disable Extended Protection Token Check.

Refer to the Microsoft KB article: Configuring Advanced Options for AD FS 2.0 .

Configure/Set AD FS 3.0 Server as servicePrincipalName (SPN).

Register the AD FS server as a service principal name (SPN)
AD FS 2.0: How to Configure the SPN (servicePrincipalName) for the Service Account

Use A Record for AD FS 3.0 (Optional).

Refer to the Microsoft forum topic: AD FS Windows Authentication Throws 400 Bad Request .

ericlaw talks about security, the web, and software in general

Security Zones in Edge

Last updated: 4 January 2024

Browsers As Decision Makers

As a part of every page load, browsers have to make dozens, hundreds, or even thousands of decisions — should a particular API be available? Should a resource load be permitted? Should script be allowed to run? Should video be allowed to start playing automatically? Should cookies or credentials be sent on network requests? The list is long.

In many cases, decisions are governed by two inputs: a user setting, and the URL of the page for which the decision is being made.

In the old Internet Explorer web platform, each of these decisions was called an URLAction , and the ProcessUrlAction(url, action,…) API allowed the browser or another web client to query its security manager for guidance on how to behave.

To simplify the configuration for the user or their administrator, the legacy platform classified sites into five 1 different Security Zones:

Local Machine
Local Intranet

Users could use the Internet Control Panel to assign specific sites to Zones and to configure the permission results for each zone. When making a decision, the browser would first map the execution context (site) to a Zone, then consult the setting for that URLAction for that Zone to decide what to do.

Reasonable defaults like “ Automatically satisfy authentication challenges from my Intranet ” meant that most users never needed to change any settings away from their defaults.

In corporate or other managed environments, administrators can use Group Policy to assign specific sites to Zones (via “Site to Zone Assignment List” policy) and specify the settings for URLActions on a per-zone basis. This allowed Microsoft IT, for instance, to configure the browser with rules like “ Treat https://mail.microsoft.com as a part of my Intranet and allow popups and file downloads without warning messages. “

Beyond manual administrative or user assignment of sites to Zones, the platform used additional heuristics that could assign sites to the Local Intranet Zone . In particular, the browser would assign dotless hostnames (e.g. https://payroll ) to the Intranet Zone, and if a Proxy Configuration script was used, any sites configured to bypass the proxy would be mapped to the Intranet Zone.

Applications hosting Web Browser Controls, by default, inherit the Windows Zone configuration settings, meaning that changes made for Internet Explorer are inherited by other applications. In relatively rare cases, the host application might supply its own Security Manager and override URL Policy decisions for embedded Web Browser Control instances.

The Trouble with Zones

While powerful and convenient, Zones are simultaneously problematic bug farms :

Users might find that their mission critical corporate sites stopped working if their computer’s Group Policy configuration was outdated.
Users might manually set configuration options to unsafe values without realizing it.
Attempts to automatically provide isolation of cookies and other data by Zone led to unexpected behavior , especially for federated authentication scenarios .

Zone-mapping heuristics are extra problematic

A Web Developer working on a site locally might find that it worked fine (Intranet Zone), but failed spectacularly for their users when deployed to production (Internet Zone).
Users were often completely flummoxed to find that the same page on a single server behaved very differently depending on how they referred to it — e.g. http://localhost/ (Intranet Zone) vs. http://127.0.0.1/ (Internet Zone).

The fact that proxy configuration scripts can push sites into the Intranet zone proves especially challenging, because:

A synchronous API call might need to know what Zone a caller is in, but determining that could, in the worst case, take tens of seconds — the time needed to discover the location of the proxy configuration script, download it, and run the FindProxyForUrl() function within it. This could lead to a hang and unresponsive UI.
A site’s Zone can change at runtime without restarting the browser (say, when moving a laptop between home and work networks, or when connecting or disconnecting from a VPN).
An IT Department might not realize the implications of returning DIRECT from a proxy configuration script and accidentally map the entire untrusted web into the highly-privileged Intranet Zone. (Microsoft IT accidentally did this circa 2011, and Google IT accidentally did it circa 2016).
Some features like AppContainer Network Isolation are based on firewall configuration and have no inherent relationship to the browser’s Zone settings.

Legacy Edge

The legacy Edge browser (aka Spartan, Edge 18 and below) inherited the Zone architecture from its Internet Explorer predecessor with a few simplifying changes:

Windows’ five built-in Zones were collapsed to three: Internet (Internet), the Trusted Zone (Intranet+Trusted), and the Local Computer Zone. The Restricted Zone was removed.
Zone to URLAction mappings were hardcoded into the browser, ignoring group policies and settings in the Internet Control Panel.

Use of Zones in Chromium

Chromium goes further and favors making decisions based on explicitly-configured site lists and/or command-line arguments.

Nevertheless, in the interest of expediency, Chromium today uses Windows’ Security Zones by default in two places:

When deciding how to handle File Downloads, and
When deciding whether or not to release Windows Integrated Authentication (Kerberos/NTLM) credentials automatically.

For the first one, if you’ve configured the setting Launching applications and unsafe files to Disable in your Internet Control Panel’s Security tab, Chromium will block file downloads with a note: Couldn't download - Blocked .

Similarly, because Chrome uses the Windows Attachment Execute Services API to write a Mark-of-the-Web on downloaded files , the Launching applications and unsafe files setting (aka URLACTION_SHELL_EXECUTE_HIGHRISK ) for the download’s originating Zone controls whether the MoTW is written. If this setting is set to Enable (as it is for LMZ and Intranet), no MoTW is written to the file’s Zone.Identifier alternate data stream. If the Zone’s URLAction value is set to Prompt (as it is for Trusted Sites and Internet zones), the Security Zone identifier is written to the ZoneId property in the Zone.Identifier file.

By setting a policy, Administrators can optionally configure Edge or configure Chrome to skip SmartScreen/SafeBrowsing reputation checks for File Downloads that original from the Intranet/Trusted Zone.

For the second use of Zones, Chromium will process URLACTION_CREDENTIALS_USE to decide whether Windows Integrated Authentication is used automatically, or the user should instead see a manual authentication prompt. Aside: the manual authentication prompt is really a bit of a mistake– the browser should instead just show a prompt: “Would you like to [Send Credentials] or [Stay Anonymous]” dialog box, rather than forcing the user to retype credentials that Windows already has.

Even Limited Use is Controversial

Any respect for Zones (or network addresses 2 ) in Chromium remains controversial— the Chrome team has launched and abandoned plans to remove all support a few times, but ultimately given up under the weight of enterprise compat concerns. The arguments for complete removal include:

Zones are poorly documented, and Windows Zone behavior is poorly understood.
The performance/deadlock risks mentioned earlier ( Intranet Zone mappings can come from a WPAD-discovered proxy script).
Zones are Windows-only (meaning they prevent drop-in replacement of Windows by ChromeOS).

A sort of compromise was reached: By configuring an explicit site list policy for Windows Authentication, an administrator disables the browser’s URLACTION_CREDENTIALS_USE check, so Zones Policy is not consulted. A similar option is not presently available for Downloads.

Zones in the New Edge

Beyond the two usages of Zones inherited from upstream (Downloads and Auth), the new Chromium-based Edge browser adds three more:

Administrators can configure Internet Explorer Mode to open all Intranet sites in IEMode . Those IEMode tabs are really running Internet Explorer, and they use Zones for everything that IE did.
Administrators can configure Intranet Zone sites to navigate to file:// URIs which is otherwise forbidden .
Administrators can configure Intranet Zone sites to not be put into Enhanced Security Mode .

Update: This is very much a corner case, but I’ll mention it anyway. On downlevel operating systems (Windows 7/8/8.1), logging into the browser for sync makes use of a Windows dialog box that contains a Web Browser Control (based on MSHTML) that loads the login page. If you adjust your Windows Security Zones settings to block JavaScript from running in the Internet Zone, you will find that you’re unable to log into the new browser .

Downsides/Limitations

While it’s somewhat liberating that we’ve moved away from the bug farm of Security Zones, it also gives us one less tool to make things convenient or compatible for our users and IT admins.

We’ve already heard from some customers that they’d like to have a different security and privacy posture for sites on their “Intranet”, with behaviors like:

Disable the Tracking Prevention , “Block 3rd party cookie”, and other privacy-related controls for the Intranet (like IE/Edge did).
Allow navigation to file:// URIs from the Intranet like IE/Edge did (policy was added to Edge 95).
Disable “ HTTP and mixed content are unsafe ” and “ TLS/1.0 and TLS/1.1 are deprecated ” nags. ( Update: Now pretty obsolete as these no longer exist )
Skip SmartScreen website checks for the Trusted/Intranet zones ( available for Download checks only).
Allow ClickOnce/DirectInvoke / Auto-opening Downloads from the Intranet without a prompt. Previously, Edge (Spartan)/IE respected the FTA_OpenIsSafe bit in the EditFlags for the application.manifest progid if-and-only-if the download source was in the Intranet/Trusted Sites Zone. As of Edge 94, other policies can be used.
Allow launching application protocols from the Intranet without a prompt .
Drop all Referrers when navigating from the Intranet to the Internet; leave Referrers alone when browsing the Intranet. (Update: less relevant now ).
Internet Explorer and legacy Edge automatically send your client certificate to Intranet sites that ask for it. The AutoSelectCertificateForUrls policy permits Edge to send a client certificate to specified sites without a prompt, but this policy requires the administrator to manually specify the site list.
Block all (or most) extensions from touching Intranet pages to reduce the threat of data leaks ( runtime_blocked_hosts policy).
Guide all Intranet navigations into an appropriate profile or container (a la Detangle ).
Upstream , there’s a longstanding desire to help protect intranets/local machine from cross-site-request-forgery attacks; blocking loads and navigations of private resources from the Internet Zone is somewhat simpler than blocking them from Intranet Sites. The current plan is to protect RFC1918-reserved address space .

At present, only AutoSelectCertificateForUrls , AutoOpenFileTypes, AutoLaunchProtocolsFromOrigins . manual cookie controls, and mixed content nags support policy-pushed site lists, but their list syntax doesn’t have any concept of “the entire Intranet” (all dotless hosts, hosts that bypass proxy).

You’ll notice that each of these has potential security impact (e.g. an XSS on a privileged “Intranet” page becomes more dangerous; unqualified hostnames can result in name collisions ), but having the ability to scope some powerful features to only “Intranet” sites might also improve security by reducing attack surface.

As browser designers, we must weigh the enterprise impact of every change we make, and being able to say “ This won’t apply to your intranet if you don’t want it to ” would be very liberating. Unfortunately, building such an escape hatch is also the recipe for accumulating technical debt and permitting the corporate intranets to “rust” to the point that they barely resemble the modern public web.

Best Practices

Throughout Chromium, many features are designed respect an individual policy-pushed list of sites to control their behavior. If you were forward-thinking enough to structure your intranet such that your hostnames are of the form:

https://payroll. contoso-intranet.com
https://timecard. contoso-intranet.com
https://sharepoint. contoso-intranet.com

…Congratulations, you’ve lucked into a best practice. You can configure each desired policy with a *.contoso-intranet.com entry and your entire Intranet will be opted in.

Unfortunately, while wildcards are supported, there’s presently no way to express the concept of “any dotless hostname.”

Why is that unfortunate? For over twenty years, Internet Explorer and legacy Edge mapped domain names like https://payroll , https://timecard , and https://sharepoint/ to the Intranet Zone by default. As a result, many smaller companies have benefitted from this simple heuristic that requires no configuration changes by the user or the IT department.

Opportunity: Maybe such a DOTLESS_HOSTS token should exist in the Chromium policy syntax. This seems unlikely to happen. Edge has been on Chromium for over two years now, and there’s no active plan to introduce such a feature.

Internet Explorer and Legacy Edge use a system of five Zones and 88+ URLActions to make security decisions for web content, based on the host of a target site.
Chromium (New Edge, Chrome) uses a system of Site Lists and permission checks to make security decisions for web content, based on the hostname of a target site.

There does not exist an exact mapping between these two systems, which exist for similar reasons but implemented using very different mechanisms.

In general, users should expect to be able to use the new Edge without configuring anything; many of the URLActions that were exposed by IE/Spartan have no logical equivalent in modern browsers.

If the new Edge browser does not behave in the desired way for some customer scenario, then we must examine the details of what isn’t working as desired to determine whether there exists a setting (e.g. a Group Policy-pushed SiteList) that provides the desired experience.

1 Technically, it was possible for an administrator to create “Custom Security Zones” (with increasing ZoneIds starting at #5), but such a configuration has not been officially supported for at least fifteen years, and it’s been a periodic source of never-will-be-fixed bugs.

2 Beyond those explicit uses of Windows’ Zone Manager, various components in Chromium have special handling for localhost/loopback addresses, and some have special recognition of RFC1918 private IP Address ranges, e.g. SafeBrowsing handling, navigation restrictions, and Network Quality Estimation. As of 2022, Chrome did a big refactor to allow determination of whether or not the target site’s IP address is in the public IP Address space or the private IP address space (e.g. inherently Intranet) as a part of the Private Network Access spec . This check should now be basically free (it’s getting used on every resource load) and it may make sense to start using it in a lot of places to approximate the “ This target is not on the public Internet ” check. Within Edge, the EMIE List is another mechanism by which sites’ hostnames may result in different handling.

Ancient History

Security Zones were introduced with Internet Explorer 4, released back in 1997:

The UI has only changed a little bit since that time, with most of the changes happening in IE5. There were only tiny tweaks in IE6, 7, and 8.

2 thoughts on “ Security Zones in Edge ”

In IE it is possible to see which zone is active on a page you’re currently viewing (alt to show menu bar, -> file -> properties).

Is it possible to see this in the new Edge?

No, although as noted, the Zone isn’t used for very much. To see the Zone, you’d have to reload the same page in IE (or use a command line utility or similar).

Enable single sign-on (SSO) for the RDS web access on Windows Server 2012 / 2012 R2 / 2016

08 February 2019 at 15:57 UTC

4. Configure the Single Sign-On (SSO)

Now that SSO is working for our RDS web access, we will configure the required settings for your user to log in only once on the client. Then, it will be automatically connected to the web access when it tries to access it.

To enable single sign-on (SSO) from Internet Explorer, the domain corresponding to your RDS web access must be part of the list of sites associated with its intranet zone. To do this, you can use the "Site to Zone Assignment List" policy located in : Computer Configuration -> Policies -> Administrative Templates -> Windows Components -> Internet Explorer -> Internet Control Panel -> Security Page.

As you can see in the description of this policy, Internet Explorer manages 4 security zones that you can be targeted with the following numbers :

Intranet zone
Trusted Sites zone
Internet zone
Restricted Sites zone

In the rest of this description, you will also find out how to configure the zone assignments (accessible via the "Show" button) :

value name : the domain of the concerned site (to target all the protocols for a specific domain), a prefix like "https://my.domain.lan" to target only the HTTPS version of a specific domain, ...
value : the number (from 1 to 4) corresponding to the zone in which you want to add it

Select "Enabled" and click Show.

To enable the Single Sign-On (SSO) for your web access, add :

its address in HTTPS version (to avoid the theft of identifiers) as name : https://rds.informatiweb.lan/
the number corresponding to the intranet zone : 1

Finally, click OK.

Close Internet Explorer on your clients PCs, and then force the policy update on them.

Open again Internet Explorer and try to access your web access via the HTTPS version : https://rds.informatiweb.lan/RDWeb/ If SSO is configured correctly, you will see the RemoteApp programs and/or the desktops to which you have access.

If you look at the bottom of the page (if you use Windows Server 2012 and not the 2012 R2 version), you will find a "I am using a private computer that complies with my organization's security policy" box.

This box corresponds to the choice "This is a computer ..." that was present in the login form before. But since we have removed it since Windows authentication was enabled, we can't choose it before logging in to this web access.

However, in the next step of this tutorial, you will see how to change this default.

For those who want to know what has been changed through the group policy previously used, open Internet Explorer's Internet Options and go to the Security tab. In this tab, you will find the 4 zones that we talked about previously.

Select "Local Intranet" and click Sites.

Note : as you can see below, Internet Explorer tells you that some settings are managed by your system administrator. This is due to the application of the group policy mentioned above.

Click Advanced.

In the list, you will find the website or domain added previously via Group Policy.

5. Enable the private mode by default

In order for the "Security" choice (previously accessible from the login form) to be "private" by default, you will need to modify a variable in this file : C:\Windows\Web\RDWeb\Pages\en-US\Default.aspx

Note : to edit this file, you will first need to start the notepad as an administrator.

In this file, locate the "Page Variables" section and change the value of the "bPrivateMode" variable to "true" instead of "false".

Refresh the RDS web access page and you will see that the box is now checked by default.

Share this tutorial

Social media buttons not showing locally or as admin

To see also

Windows Server 6/7/2019

WS 2012 / 2012 R2 - RDS - Set up HA on your RDS infrastructure

Windows Server 3/8/2019

WS 2012 / 2012 R2 / 2016 - RDS - Access RemoteApp via a modern application

Windows Server 4/28/2019

WS 2012 / 2012 R2 / 2016 - RDS - Attempt to unblock the session as a user

Windows Server 3/16/2019

WS 2012 / 2012 R2 / 2016 - RDS - Change the properties of RemoteApps

Pinned content

Software (System admin)
Linux softwares
Our programs
Terms and conditions
Share your opinion
Technical support

Total or partial reproduction of this site is prohibited and constitutes an infringement punishable by articles L.335-2 and following of the intellectual property Code.

techlauve.com – a knowledge base for IT professionals.

Inhale problems, exhale solutions..

Nick’s Blog
Active Directory
Privacy Policy

« Outlook: “Sending and Receiving reported error (OX80040600)”

Terminal Server Does Not Accept Enough Client Connections »

Adding Sites to Internet Security Zones Using Group Policy

Sometimes it is useful to leverage the power of Group Policy in Active Directory to add sites to certain security zones in Internet Explorer. This can save the network admin the trouble of managing the security zone lists for each computer (or user) separately. In the following example, each user on the network needs to have a specific site added to the Trusted Sites list.

This tutorial assumes that group policy is in good working order on the domain and that all client users and computers can access the directory.

Open the Group Policy Management MMC console.
Right-click the organization unit (OU) that the policy should apply to, taking special care to consider whether the policy should apply to computers or users on this particular network.
Select “Create and Link a GPO Here…” to create a new group policy object.
In the “New GPO” window, enter a good, descriptive name for this new policy and click “OK”. (ex. “Trusted Sites Zone – Users” or something even more descriptive)
Locate the newly created GPO in the left-side navigation pane, right-click it and select “Edit…”
Expand “Administrative Templates” under either “Computer Configuration” or “User Configuration” depending on which type of OU the new policy was linked to in step 2.
The path to the settings that this example will be using is: Administrative Templates -- Windows Components -- Internet Explorer -- Internet Control Panel -- Security Page
In the right-hand pane, double-click “Site to Zone Assignment List”.
Enable the policy and click the “Show…” button next to “Enter the zone assignments here.” This will pop up the “Show Contents” window.
Click the “Add…” button. This will pop up the “Add Item” window.
In the first box, labeled “Enter the name of the item to be added:”, enter the URL to the site. (ex. https://secure.ourimportantwebapp.com) . Keep in mind that wildcards can be used. (ex. https://*.ourimportantdomain.com) . Leave off any trailing slashes or sub-folders unless that type of specific control is called for.
1 – Intranet Zone
2 – Trusted Sites Zone
3 – Internet Zone
4 – Restricted Sites Zone
Once the zone assignment has been entered, click “OK”. This will once again show the “Show Contents” window and the new entry should be present.
Click “OK” and “OK” again to get back to the Group Policy Management Console.

The new policy will take effect at the next group policy refresh interval, which is usually 15 minutes. To test immediately, run a gpupdate /force on a user/computer that falls into the scope of the new policy and go to “Tools -> Internet Options -> Security -> Trusted Sites -> Sites”. The site(s) added should be in the list. If the sites do not show up, check the event logs for any group policy processing errors.

No comment yet

Juicer breville says:.

November 26, 2012 at 12:11 am (UTC -5)

Hurrah, that’s what I was looking for, what a information! existing here at this web site, thanks admin of this web page.

Connect With Us

Connect with us.

Social Connect by NewsPress

Not finding the answer that you're looking for? Need more help with a problem that is addressed in one of our articles?

techlauve.com is affiliated with Rent-A-Nerd, Inc. in New Orleans, LA.

DFS Replication (1)
Group Policy (1)
Microsoft Exhange (3)
Microsoft Outlook (11)
Copiers (1)
Multi Function Devices (1)
Printers (2)
Scanners (1)
Blackberry (1)
Firewalls (2)
Wireless (2)
Hard Drives (1)
SAN Systems (1)
Hyper-V (3)
Virtual Server (1)
WordPress (1)
Security (7)
QuickBooks (2)
Quicken (1)
Antivirus/Antimalware (4)
Backup Exec (2)
Internet Explorer (5)
Microsoft SQL (1)
Licensing (2)
Steinberg Nuendo (1)
Mac OS X (1)
Server 2003 (12)
Server 2008 (14)
Small Business Server 2003 (7)
Terminal Server (6)
Updates (2)
Windows 7 (9)
Windows XP (11)
Reviews (1)
Rent-A-Nerd, Inc.

Except where otherwise noted, content on this site is licensed under a Creative Commons Licence .

Valid XHTML 1.0 Strict Valid CSS Level 2.1

techlauve.com - a knowledge base for IT professionals. uses Graphene theme by Syahir Hakim.

Microsoft 365
Citrix Xendesktop
Citrix XenApp
Useful links

Configure Seamless Sign-On for Microsoft 365 Login with Azure AD Connect

When syncing local AD users to Azure AD, you can configure Seamless Sign-On to automatically login to Microsoft 365 Apps like Sharepoint Online, OneDrive, or Exchange Online. This is very easy to do and will make logins for users less painful.

Assuming Azure AD Connect is already set up with Pass-through authentication (see https://www.ajni.it/2021/05/configuring-azure-ad-connect-for-user-synchronization/ ), just open Azure AD Connect and then hit “change user sign-in” and log in with an Azure AD Global admin. After that, select “Enable single sign-on”.

Enter Domain Admin credentials.

When the pre-checks is complete, hit configure and exit.

A Computer Account named AZUREADSSOACC will be created in Active Directory which allows the authentication validation between Azure AD and local Active Directory. The Kerberos decryption key is saved in the cloud and should be changed regularly. You can see that on the Computer account, service principal names are configured

Lastly, you can roll out the feature with Group Policy. The URL https://autologon.microsoftazuread-sso.com must be added to the intranet zone list, which allows the browser to send Kerberos tickets to that site.

The GPO can be found under User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Site to Zone Assignment List .

Status bar updates via script must be also enabled. This GPO is located under User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone > Allow updates to status bar via script .

You can test the feature by opening portal.office.com. After entering the username, login should be done automatically without needing to insert a password.

References:

https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sso-quick-start

Hide microsoft 365 users from gal when synchronized with azure ad connect, how to use a custom azure vm type on citrix mcs (on-prem and citrix cloud), simple fix for microsoft azure ad sync service not starting after a reboot, cancel reply.

Save my name, email, and website in this browser for the next time I comment.

Tip Of the Day

Run msiexec with arguments with powershell, keep in touch, oh hi there it’s nice to meet you..

Check your inbox or spam folder to confirm your subscription.

AI & Deep Learning (1)
Citrix XenApp (19)
Citrix Xendesktop (11)
Cloud Computing (36)
Hyper-V (9)
Microsoft 365 (22)
Powershell (17)
Security (6)
Virtualization (20)
VMware (11)
Windows (21)
Windows Client OS (29)
Windows Server (69)
February 2024
January 2024
December 2023
September 2023
August 2023
January 2023
December 2022
November 2022
October 2022
September 2022
August 2022
February 2022
January 2022
December 2021
November 2021
October 2021
September 2021
August 2021
February 2021
December 2020
November 2020
September 2020
August 2020
February 2020
November 2019
October 2019
September 2019
August 2019

This browser is no longer supported.

Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.

Quickstart: Microsoft Entra seamless single sign-on

5 contributors

Microsoft Entra seamless single sign-on (Seamless SSO) automatically signs in users when they're using their corporate desktops that are connected to your corporate network. Seamless SSO provides your users with easy access to your cloud-based applications without using any other on-premises components.

To deploy Seamless SSO for Microsoft Entra ID by using Microsoft Entra Connect, complete the steps that are described in the following sections.

Check the prerequisites

Ensure that the following prerequisites are in place:

Set up your Microsoft Entra Connect server : If you use pass-through authentication as your sign-in method, no other prerequisite check is required. If you use password hash synchronization as your sign-in method and there's a firewall between Microsoft Entra Connect and Microsoft Entra ID, ensure that:

You use Microsoft Entra Connect version 1.1.644.0 or later.

If your firewall or proxy allows, add the connections to your allowlist for *.msappproxy.net URLs over port 443. If you require a specific URL instead of a wildcard for proxy configuration, you can configure tenantid.registration.msappproxy.net , where tenantid is the GUID of the tenant for which you're configuring the feature. If URL-based proxy exceptions aren't possible in your organization, you can instead allow access to the Azure datacenter IP ranges , which are updated weekly. This prerequisite is applicable only when you enable the Seamless SSO feature. It isn't required for direct user sign-ins.

Microsoft Entra Connect versions 1.1.557.0, 1.1.558.0, 1.1.561.0, and 1.1.614.0 have a problem related to password hash sync. If you don't intend to use password hash sync in conjunction with pass-through authentication, review the Microsoft Entra Connect release notes to learn more.

Use a supported Microsoft Entra Connect topology : Ensure that you're using one of the Microsoft Entra Connect supported topologies .

Seamless SSO supports multiple on-premises Windows Server Active Directory (Windows Server AD) forests, whether or not there are Windows Server AD trusts between them.

Set up domain administrator credentials : You must have domain administrator credentials for each Windows Server AD forest that:

You sync to Microsoft Entra ID through Microsoft Entra Connect.
Contains users you want to enable Seamless SSO for.

Enable modern authentication : To use this feature, you must enable modern authentication on your tenant.

Use the latest versions of Microsoft 365 clients : To get a silent sign-on experience with Microsoft 365 clients (for example, with Outlook, Word, or Excel), your users must use versions 16.0.8730.xxxx or later.

If you have an outgoing HTTP proxy, make sure that the URL autologon.microsoftazuread-sso.com is on your allowlist. You should specify this URL explicitly because the wildcard might not be accepted.

Enable the feature

Steps in this article might vary slightly based on the portal you start from.

Enable Seamless SSO through Microsoft Entra Connect .

If Microsoft Entra Connect doesn't meet your requirements, you can enable Seamless SSO by using PowerShell . Use this option if you have more than one domain per Windows Server AD forest, and you want to target the domain to enable Seamless SSO for.

If you're doing a fresh installation of Microsoft Entra Connect , choose the custom installation path . On the User sign-in page, select the Enable single sign on option.

Screenshot that shows the User sign-in page in Microsoft Entra Connect, with Enable single sign on selected.

The option is available to select only if the sign-on method that's selected is Password Hash Synchronization or Pass-through Authentication .

If you already have an installation of Microsoft Entra Connect , in Additional tasks , select Change user sign-in , and then select Next . If you're using Microsoft Entra Connect versions 1.1.880.0 or later, the Enable single sign on option is selected by default. If you're using an earlier version of Microsoft Entra Connect, select the Enable single sign on option.

Screenshot that shows the Additional tasks page with Change the user sign-in selected.

Continue through the wizard to the Enable single sign on page. Provide Domain Administrator credentials for each Windows Server AD forest that:

When you complete the wizard, Seamless SSO is enabled on your tenant.

The Domain Administrator credentials are not stored in Microsoft Entra Connect or in Microsoft Entra ID. They're used only to enable the feature.

To verify that you have enabled Seamless SSO correctly:

Sign in to the Microsoft Entra admin center as at least a Hybrid Identity Administrator .
Browse to Identity > Hybrid management > Microsoft Entra Connect > Connect sync .
Verify that Seamless single sign-on is set to Enabled .

Screenshot that shows the Microsoft Entra Connect pane in the admin portal.

Seamless SSO creates a computer account named AZUREADSSOACC in each Windows Server AD forest in your on-premises Windows Server AD directory. The AZUREADSSOACC computer account must be strongly protected for security reasons. Only Domain Administrator accounts should be allowed to manage the computer account. Ensure that Kerberos delegation on the computer account is disabled, and that no other account in Windows Server AD has delegation permissions on the AZUREADSSOACC computer account. Store the computer accounts in an organization unit so that they're safe from accidental deletions and only Domain Administrators can access them.

If you're using Pass-the-Hash and Credential Theft Mitigation architectures in your on-premises environment, make appropriate changes to ensure that the AZUREADSSOACC computer account doesn't end up in the Quarantine container.

Roll out the feature

You can gradually roll out Seamless SSO to your users by using the instructions provided in the next sections. You start by adding the following Microsoft Entra URL to all or selected user intranet zone settings through Group Policy in Windows Server AD:

https://autologon.microsoftazuread-sso.com

You also must enable an intranet zone policy setting called Allow updates to status bar via script through Group Policy.

The following instructions work only for Internet Explorer, Microsoft Edge, and Google Chrome on Windows (if Google Chrome shares a set of trusted site URLs with Internet Explorer). Learn how to set up Mozilla Firefox and Google Chrome on macOS .

Why you need to modify user intranet zone settings

By default, a browser automatically calculates the correct zone, either internet or intranet, from a specific URL. For example, http://contoso/ maps to the intranet zone, and http://intranet.contoso.com/ maps to the internet zone (because the URL contains a period). Browsers don't send Kerberos tickets to a cloud endpoint, like to the Microsoft Entra URL, unless you explicitly add the URL to the browser's intranet zone.

There are two ways you can modify user intranet zone settings:

Group policy detailed steps

Open the Group Policy Management Editor tool.

Edit the group policy that's applied to some or all your users. This example uses Default Domain Policy .

Go to User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page . Select Site to Zone Assignment List .

Screenshot that shows the Security Page with Site to Zone Assignment List selected.

Enable the policy, and then enter the following values in the dialog:

Value name : The Microsoft Entra URL where the Kerberos tickets are forwarded.

Value (Data): 1 indicates the intranet zone.

The result looks like this example:

Value name: https://autologon.microsoftazuread-sso.com

Value (Data): 1

If you want to prevent some users from using Seamless SSO (for instance, if these users sign in on shared kiosks), set the preceding values to 4 . This action adds the Microsoft Entra URL to the restricted zone and Seamless SSO fails for the users all the time.

Select OK , and then select OK again.

Screenshot that shows the Show Contents window with a zone assignment selected.

Go to User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone . Select Allow updates to status bar via script .

Screenshot that shows the Intranet Zone page with Allow updates to status bar via script selected.

Enable the policy setting, and then select OK .

Screenshot that shows the Allow updates to status bar via script window with the policy setting enabled.

Group policy preference detailed steps

Go to User Configuration > Preferences > Windows Settings > Registry > New > Registry item .

Screenshot that shows Registry selected and Registry Item selected.

Enter or select the following values as demonstrated, and then select OK .

Key Path : Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoftazuread-sso.com\autologon

Value name : https

Value type : REG_DWORD

Value data : 00000001

Screenshot that shows the New Registry Properties window.

Browser considerations

The next sections have information about Seamless SSO that's specific to different types of browsers.

Mozilla Firefox (all platforms)

If you're using the Authentication policy settings in your environment, ensure that you add the Microsoft Entra URL ( https://autologon.microsoftazuread-sso.com ) to the SPNEGO section. You can also set the PrivateBrowsing option to true to allow Seamless SSO in private browsing mode.

Safari (macOS)

Ensure that the machine running the macOS is joined to Windows Server AD.

Instructions for joining your macOS device to Windows Server AD are outside the scope of this article.

Microsoft Edge based on Chromium (all platforms)

If you've overridden the AuthNegotiateDelegateAllowlist or AuthServerAllowlist policy settings in your environment, ensure that you also add the Microsoft Entra URL ( https://autologon.microsoftazuread-sso.com ) to these policy settings.

Microsoft Edge based on Chromium (macOS and other non-Windows platforms)

For Microsoft Edge based on Chromium on macOS and other non-Windows platforms, see the Microsoft Edge based on Chromium Policy List for information on how to add the Microsoft Entra URL for integrated authentication to your allowlist.

Google Chrome (all platforms)

The use of third-party Active Directory Group Policy extensions to roll out the Microsoft Entra URL to Firefox and Google Chrome for macOS users is outside the scope of this article.

Known browser limitations

Seamless SSO doesn't work on Internet Explorer if the browser is running in Enhanced Protected mode. Seamless SSO supports the next version of Microsoft Edge based on Chromium, and it works in InPrivate and Guest mode by design. Microsoft Edge (legacy) is no longer supported.

You might need to configure AmbientAuthenticationInPrivateModesEnabled for InPrivate or guest users based on the corresponding documentation:

Microsoft Edge Chromium
Google Chrome

Test Seamless SSO

To test the feature for a specific user, ensure that all the following conditions are in place:

The user signs in on a corporate device.
The device is joined to your Windows Server AD domain. The device doesn't need to be Microsoft Entra joined .
The device has a direct connection to your domain controller, either on the corporate wired or wireless network or via a remote access connection, such as a VPN connection.
You've rolled out the feature to this user through Group Policy.

To test a scenario in which the user enters a username, but not a password:

Sign in to https://myapps.microsoft.com . Be sure to either clear the browser cache or use a new private browser session with any of the supported browsers in private mode.

To test a scenario in which the user doesn't have to enter a username or password, use one of these steps:

Sign in to https://myapps.microsoft.com/contoso.onmicrosoft.com . Be sure to either clear the browser cache or use a new private browser session with any of the supported browsers in private mode. Replace contoso with your tenant name.
Sign in to https://myapps.microsoft.com/contoso.com in a new private browser session. Replace contoso.com with a verified domain (not a federated domain) on your tenant.

Roll over keys

In Enable the feature , Microsoft Entra Connect creates computer accounts (representing Microsoft Entra ID) in all the Windows Server AD forests on which you enabled Seamless SSO. To learn more, see Microsoft Entra seamless single sign-on: Technical deep dive .

The Kerberos decryption key on a computer account, if leaked, can be used to generate Kerberos tickets for any user in its Windows Server AD forest. Malicious actors can then impersonate Microsoft Entra sign-ins for compromised users. We highly recommend that you periodically roll over these Kerberos decryption keys, or at least once every 30 days.

For instructions on how to roll over keys, see Microsoft Entra seamless single sign-on: Frequently asked questions .

You don't need to do this step immediately after you have enabled the feature. Roll over the Kerberos decryption keys at least once every 30 days.

Technical deep dive : Understand how the Seamless single sign-on feature works.
Frequently asked questions : Get answers to frequently asked questions about Seamless single sign-on.
Troubleshoot : Learn how to resolve common problems with the Seamless single sign-on feature.
UserVoice : Use the Microsoft Entra Forum to file new feature requests.

Coming soon: Throughout 2024 we will be phasing out GitHub Issues as the feedback mechanism for content and replacing it with a new feedback system. For more information see: https://aka.ms/ContentUserFeedback .

Submit and view feedback for

Additional resources

Open or view cases
Site feedback
My Citrix account
Citrix Cloud
Citrix Cloud Government
My support alerts
Sign out Sign in

Customers who viewed this article also viewed

Identify changes in netscaler build files with, file integrity monitoring, how to add storefront site to client trust site zone, applicable products.

This article explains how to add StoreFront site to client trust site zone, via group policy.

Instructions

To configure via group policy:

Go to Computer Configuration > Administrative Tools > Windows Components > Internet Explorer > Internet Control Panel > Security Page
Double click to the "Site to zone assignment list". Enable it,
Click Show, add website as value name and 1, 2, 3 or 4 as value

Page feedback

IMAGES

Configure Azure Active Directory SSO service and avoid delays
Configuring Windows clients for single sign-on (SSO) with Kerberos
16.site to zone assignment list
How to enable SSO on domain-joined workstations : IAM Cloud Support
SSO Group Policy
Configurando a Autenticação SSO (Single Sign-On) no RDS do Windows

VIDEO

School District Home Interior Design: Maximizing Space for Growing Children
booyah in last zone 🔥🤟 br rank -#shorts
No Love No Loyalty
#3 BR Rank Mode 🔥 1 VS 1 Situation 🥵 Last Zone Healing Battle No Fight Booyah Challenge 😱 #freefire
Tekken 8: Yoshimitsu Moment #26
Rolex Explorer II 42 White Dial Orange Hand Steel Mens Watch 216570 Review

COMMENTS

How to add the URLs to the Local Intranet zone
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. ... In the main pane, double-click the Sites to Zone Assignment List setting. Enable the Group Policy setting by selecting ...
Configure Azure Active Directory Single Sign-On (SSO)
How to configure Azure Active Directory Single Sign-On. Step 1. Enable Single Sign-On in Azure Active Directory Connect. Step 2. Verify Single Sign-On is active. Step 3. Configure Group Policy. Policy 1: Site to Zone Assignment List. Policy 2: Allow updates to status bar via script.
Group Policy Template "Site to Zone Assignment List"
Open Group Policy Management Console. Navigate to the desired GPO or create a new one. Expand User Configuration or Computer Configuration and go to Preferences -> Windows Settings -> Registry. Right-click and select New -> Registry Item. Configure the Registry Item to delete the specified entries under the ZoneMap registry key.
Site to Zone Assignment List
Re: Site to Zone Assignment List - Powershell. # Step 2: Navigate to the Site to Zone Assignment List # This step is manual and requires navigating through the Group Policy Management Editor interface. # Step 3: Enable the Policy and Specify Zone Assignments # Define the list of URLs and their corresponding zone assignments.
Setting up Single Sign On (SSO) with Azure AD Connect
Go to User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page and select Site to Zone Assignment List; Enable to policy and add the following values: https://autologon.microsoftazuread-sso.com > 1; https://aadg.windows.net.nsatc.net > 1
Trusted Sites and Local Intranet Assigment for Office 365
Hi Petr, just a couple of comments: I would mark these URLs as only required if you use Seamless Single Sign-On (S-SSO): autologon.microsoftazuread-sso.com (S-SSO) aadg.windows.net.nsatc.net (S-SSO) And also that AD FS is not necessarily "tenantdomain", it would be the configured Federation Service URL. 0 Likes.
Configuring Azure Active Directory Single Sign-On (SSO) with Azure AD
Once the sync is finished, you can check the Azure AD to make sure if the single sign-on is enabled. Next step is to add the following URL in the Intranet Zone via Group Policy. https://autologon.microsoftazuread-sso.com. The policy is called Site to Zone Assignment list under
Per-site configuration by policy
In managed environments, administrators can use Group Policy to assign specific sites to Zones (via "Site to Zone Assignment List" policy) and specify the settings for URLActions on a per-zone basis. Beyond manual administrative or user assignment of sites to Zones, other heuristics could assign sites to the Local Intranet Zone.
Configure SSO with Office 365
Go to User Configuration\Administrative Templates\Windows Components\Internet Explorer\Internet Control Panel\Security Page and select Site to Zone Assignment List. Enable to policy and add the following values: https://autologon.microsoftazuread-sso.com > 1. Read more about the configuration in Microsoft doc.
Seamless Single Sign-on in Azure Active Directory
Step 2: Create a Site To Zone assignment list. Navigate to user configuration > policies > management templates > Windows Features > Internet Explorer > Internet configuration screen > Security page. Then select the list site to zone assignment. Or in English according to the screenshot below.
How to Set Up Seamless Single Sign On in Microsoft 365
Go to "User Configuration", then "Policies", then "Administrative Templates", "Windows Components", "Internet Explorer", "Internal Control Panel", and finally "Security Page". Select site to "Zone Assignment List" and enable the policy. Enter the following values: Value name: https://autologon.microsoftazuread ...
Azure AD Connect hybrid domain, single server with pass-through
I'm using Azure AD Connect, pass-through authentication with SSO enabled. ... Site to Zone Assignment List https://autologon.microsoftazuread-sso.com - 1 ... /Administrative Templates/Windows Components/Internet Explorer/Internet Control Panel/Security Page/Intranet Zone
How to automatically log into Office 2019/O365 without Seamless SSO
Site to Zone Assignment List - Enabled Set your sites SSO url here. I have ours set with both https://OurSSOSignInPage.org and *.OurSSOSignInPage.org I also have https://autologin.microsoftazuread-sso.com set User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security ...
Configuring Windows clients for single sign-on (SSO) with Kerberos
Note: Single sign-on won't work if a HTTPS connection to ucs-sso.your-domain.tld is not possible, ... Double-click on Site to Zone Assignment List, select Enable and click Show to edit the list. Add the following to your list and click OK. example.intranet is our domain in this example.
Deploy Trusted sites zone assignment using Intune
Deploy a set of trusted sites overriding users' ability to add trusted sites themselves. To acheive this, an Intune configuration profile Trusted site zone assignment can be deployed to devices/users group as required. Login to Intune Portal and navigate to: Devices > Windows > Configuration Profiles. Hit the Create button and Select New policy.
Enabling NTLM Authentication (Automatic Logon) in AD FS and browsers
Type 1 (indicating the local intranet zone) in the Enter the value of the item to be added box, and then click OK. In the Show Contents dialog box, click OK. In the Site to Zone Assignment List dialog box, click OK. In the Group Policy Management Editor, click Intranet Zone. In the details pane, double-click Logon options. In the Logon options ...
Security Zones in Edge
Legacy Edge. The legacy Edge browser (aka Spartan, Edge 18 and below) inherited the Zone architecture from its Internet Explorer predecessor with a few simplifying changes: Windows' five built-in Zones were collapsed to three: Internet (Internet), the Trusted Zone (Intranet+Trusted), and the Local Computer Zone. The Restricted Zone was removed.
Enable single sign-on (SSO) for the RDS web access on Windows Server
To enable single sign-on (SSO) from Internet Explorer, the domain corresponding to your RDS web access must be part of the list of sites associated with its intranet zone. To do this, you can use the "Site to Zone Assignment List" policy located in : Computer Configuration -> Policies -> Administrative Templates -> Windows Components ...
Adding Sites to Internet Security Zones Using Group Policy
In the right-hand pane, double-click "Site to Zone Assignment List". Enable the policy and click the "Show…" button next to "Enter the zone assignments here." This will pop up the "Show Contents" window. Click the "Add…" button. This will pop up the "Add Item" window.
Configure Seamless Sign-On for Microsoft 365 Login with Azure AD
The URL https://autologon.microsoftazuread-sso.com must be added to the intranet zone list, which allows the browser to send Kerberos tickets to that site. The GPO can be found under User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Site to Zone ...
Quickstart: Microsoft Entra seamless single sign-on
Select Site to Zone Assignment List. Enable the policy, and then enter the following values in the dialog: Value name: The Microsoft Entra URL where the Kerberos tickets are forwarded. Value (Data): 1 indicates the intranet zone. The result looks like this example: Value name: https://autologon.microsoftazuread-sso.com. Value (Data): 1
How to Add StoreFront Site to Client Trust Site Zone
To configure via group policy: Go to Computer Configuration > Administrative Tools > Windows Components > Internet Explorer > Internet Control Panel > Security Page. Double click to the "Site to zone assignment list". Enable it, Click Show, add website as value name and 1, 2, 3 or 4 as value. Was this page helpful?