Do’s and don’t concerning security for Identity part 1

In simplified terms there is two different ways to build a cloud service.

  • Cloud-based or Cloud native
  • Hybrid

There is also different possibilities to federate Identities between Cloud service providers but also with Federation services through on-premises environment.

Azure AD Connect and Azure AD Cloud Sync

You can sync user with either one, the major difference is that Azure AD Connect has more on-premises services that will be installed and needed.

AAD Connect

Will need the following requirements.

  • Azure AD Connect must be installed on a domain-joined Windows Server 2019 or later – note that Windows Server 2022 is not yet supported. You can deploy Azure AD Connect on Windows Server 2016 but since WS2016 is in extended support, you may require a paid support program if you require support for this configuration.
  • The minimum .Net Framework version required is 4.6.2, and newer versions of .Net are also supported.
  • Azure AD Connect can’t be installed on Small Business Server or Windows Server Essentials before 2019 (Windows Server Essentials 2019 is supported). The server must be using Windows Server standard or better.
  • The Azure AD Connect server must have a full GUI installed. Installing Azure AD Connect on Windows Server Core isn’t supported.
  • The Azure AD Connect server must not have PowerShell Transcription Group Policy enabled if you use the Azure AD Connect wizard to manage Active Directory Federation Services (AD FS) configuration. You can enable PowerShell transcription if you use the Azure AD Connect wizard to manage sync configuration.


And Cloud sync the following.

  • Domain Administrator or Enterprise Administrator credentials to create the Azure AD Connect Cloud Sync gMSA (group Managed Service Account) to run the agent service.
  • A hybrid identity administrator account for your Azure AD tenant that is not a guest user.
  • An on-premises server for the provisioning agent with Windows 2016 or later. Installing the agent on a domain controller is supported.
  • High availability refers to the Azure AD Connect cloud sync’s ability to operate continuously without failure for a long time. By having multiple active agents installed and running, Azure AD Connect cloud sync can continue to function even if one agent should fail. Microsoft recommends having 3 active agents installed for high availability.


FeatureAzure Active Directory Connect syncAzure Active Directory Connect cloud sync
Connect to single on-premises AD forest
Connect to multiple on-premises AD forests
Connect to multiple disconnected on-premises AD forests
Lightweight agent installation model
Multiple active agents for high availability
Connect to LDAP directories
Support for user objects
Support for group objects
Support for contact objects
Support for device objects
Allow basic customization for attribute flows
Synchronize Exchange online attributes
Synchronize extension attributes 1-15
Synchronize customer defined AD attributes (directory extensions)
Support for Password Hash Sync
Support for Pass-Through Authentication
Support for federation
Seamless Single Sign-on
Supports installation on a Domain Controller
Support for Windows Server 2016
Filter on Domains/OUs/groups
Filter on objects’ attribute values
Allow minimal set of attributes to be synchronized (MinSync)
Allow removing attributes from flowing from AD to Azure AD
Allow advanced customization for attribute flows
Support for password writeback
Support for device writeback
Support for group writeback
Support for merging user attributes from multiple domains
Azure AD Domain Services support
Exchange hybrid writeback
Unlimited number of objects per AD domain
Support for up to 150,000 objects per AD domain
Groups with up to 50,000 members
Large groups with up to 250,000 members
Cross domain references
On-demand provisioning
Support for US Government

AD Federation service (ADFS)

How ADFS works?

ADFS will give SSO to services that you will federated to. You can publish the ADFS directly to Internet but it isn’t the best way to go. You can use either Web Application Proxy (Windows Server Feature) or external device in-front of the ADFS-servers to protect the balance the the traffic.

You can have 5 ADFS server in one FARM with dedicated SQL-server, after that the SQL is needed.

All the servers run the same config in the FARM and you switch the primary via PowerShell or route the traffic to any one of them, they are identical after all.

Securing ADFS

For many organization ADFS is still in use and it has to be secured and configured by best practices.

It ain’t no joke, otherwise the information will leak out and it makes bad guys easier to recon the information they need.

And if you’re still not convinced see the attacks that unsecure ADFS could give.

Security models

Tier model

All of these servers / services should be treated as TIER 0 server based on the Active Directory administrative tier model.

Shared Responsible model

Even in cloud, you still have a lot of responsibilities to handle concerning Identity.

Why you ask?

Securing your service will make it harder for the bad guys to infiltrate to your environment (not impossible but at least harder)

Everything can be hacked when you have the rights tools but you just have to make sure it’s hard or too easy and make a trap for attackers. Most of them are bots, not people. People come in to the picture once there’s something they can use.

The Do’s

Use the least privileged accounts

Do use the least privileged accounts like Hybrid identity administrator

If you are using the service account created with AAD Connect, you must note this.

Types of accounts supported

Type of accountInstallation optionDescription
Virtual Service AccountExpress and custom, 2017 April and laterThis is the option used for all express installations, except for installations on a Domain Controller. For custom, it is the default option unless another option is used.
Group Managed Service AccountCustom, 2017 April and laterIf you use a remote SQL server, then we recommend to use a group managed service account.
User accountExpress and custom, 2017 April and laterA user account prefixed with AAD_ is only created during installation when installed on Windows Server 2008 and when installed on a Domain Controller.
User accountExpress and custom, 2017 March and earlierA local account prefixed with AAD_ is created during installation. When using custom installation, another account can be specified.

And again, keep AAD Connect servers safe inside TIER 0

Enable PHS

Do enable Password Hash Synchronization

Implementing PHS also improves your fault tolerance

But also security as the passwords are replicated as hashes to the cloud

And you can initiate Conditional access policies based on the risks

Remove ADFS components

Do remove unnecessary components from ADFS-servers like IdP Initiated Sign-On page (which should be disabled by default on Server 2016 and up)

Most of the pages start the Service-Provider Initiated authentication, the IdP is useless in that sense. Of course there could be use cases to IdP page also but I haven’t seen any.

With the following cmdlet.

And WS-Trust Windows endpoints should only be intranet facing endpoints that employ WIA binding on HTTPS, according to their intended use. By exposing them to the extranet, requests made to these endpoints could be able to avoid lockout safeguards.

Here are the needed proxy’s

/adfs/lsBrowser based authentication flows and current versions of Microsoft Office use this endpoint for Azure AD and Office 365 authentication
/adfs/services/trust/2005/usernamemixedUsed for Exchange Online with Office clients older than Office 2013 May 2015 update. Later clients use the passive \adfs\ls endpoint.
/adfs/services/trust/13/usernamemixedUsed for Exchange Online with Office clients older than Office 2013 May 2015 update. Later clients use the passive \adfs\ls endpoint.
/adfs/oauth2Used for any modern apps (on-prem or in cloud) you have configured to authenticate directly to AD FS (i.e. not through Azure AD)
/adfs/services/trust/mexUsed for Exchange Online with Office clients older than Office 2013 May 2015 update. Later clients use the passive \adfs\ls endpoint.
/adfs/ls/federationmetadata/2007-06/federationmetadata.xmlRequirement for any passive flows; and used by Office 365 / Azure AD to check AD FS certificates.

If you still need the RP’s from ADFS, you could add them directly to and here is the URL https://Your ADFS FQDN/adfs/ls/idpinitiatedsignon.aspx?loginToRp=YourApplicationID

You can add it as Linked but it doesn’t provide SSO and you will be asked credentials by the ADFS server or you can add the application directly to and open the application from there, then it will authenticate you thru ADFS if SSO correctly configured.

Enable Smart lockout for Extranet

Enable MFA for ADFS

Migrate from local federation to cloud

You could also do SSO with Azure directly and put your ADFS of it’s misery for good.

Secure your Exchange Hybrids

Identity is an important part of Exchange services, it’s one of the most complex Hybrid features that your identities will take use of.

There has been a lot vulnerabilities with on-premises Exchange servers, it’s important to secure it even without a Hybrid deployment but when you have it setup, you will have more attack surfaces and possibilities for lateral movement inside your environment.


Always use dedicated workstation’s / VM’s for any admin activities for TIER 0 model services.


Always allow access when you need it and only for period of time you need it for.


Keeping the designs secure will keep your environment less potential for attacks, external or internal.

But what about the don’ts? I will cover these in my next posts, stay tuned!

Hackers don’t break in – they log in.

Author: Harri Jaakkonen

Leave a Reply

Your email address will not be published. Required fields are marked *