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.

Cloud-sync

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.

Differences

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

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

Endpoint	Purpose
/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.

Use PAW

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

Use JIT

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

Closure

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.