In simplified terms there is two different ways to build a cloud service.
- Cloud-based or Cloud native
There is also different possibilities to federate Identities between Cloud service providers but also with Federation services through on-premises environment.
Table of Contents
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.
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.
|Feature||Azure Active Directory Connect sync||Azure 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||●||●|
|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.
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.
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.
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 account||Installation option||Description|
|Virtual Service Account||Express and custom, 2017 April and later||This 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 Account||Custom, 2017 April and later||If you use a remote SQL server, then we recommend to use a group managed service account.|
|User account||Express and custom, 2017 April and later||A user account prefixed with AAD_ is only created during installation when installed on Windows Server 2008 and when installed on a Domain Controller.|
|User account||Express and custom, 2017 March and earlier||A 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
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.
Set-AdfsProperties -EnableIdpInitiatedSignonPage $false
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.
Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/2005/windowstransport -Proxy $false
Set-AdfsEndpoint -TargetAddressPath /adfs/services/trust/13/windowstransport -Proxy $false
Here are the needed proxy’s
|/adfs/ls||Browser based authentication flows and current versions of Microsoft Office use this endpoint for Azure AD and Office 365 authentication|
|/adfs/services/trust/2005/usernamemixed||Used 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/usernamemixed||Used for Exchange Online with Office clients older than Office 2013 May 2015 update. Later clients use the passive \adfs\ls endpoint.|
|/adfs/oauth2||Used 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/mex||Used 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.xml||Requirement 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 myapps.microsoft.com 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 myapps.microsoft.com 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.