Understand the authentication pros and cons with Azure AD

When using Azure AD there are two types of authentication available:

  • Cloud authentication where the authentication takes place against Azure AD
  • Federated authentication where the authentication takes place against the federated service, for example using ADFS against Active Directory Domain Services

When using the cloud authentication there are two ways to validate the password:

  • A hash of the password hash from AD is replicated to Azure AD (and no matter which authentication option used this is recommended to enable Azure AD to help detect leaked credentials and give a “break the glass” fallback authentication option if your primage configuration fails) and this is used for the cloud based authentication
  • The password validation is done against Active Directory Domain Services using Passthrough Authentication (PTA) which works by writing the username/password (in an encrypted form for each PTA agent configured) to a service bus instance which are then read by PTA instances deployed to Windows OS instances which take the entry, decrypt, authenticate against ADDS then respond with the result to then complete the authentication request

There are therefore three options for the authentication configuration

  • Password hash
  • PTA
  • Federation

The order I have them is generally the preference but there are some pros and cons of each (in addition to a few considerations) and I wanted to outline them briefly here.

Password Hash

  • Pro – Cloud scale/resilience since this is all native Azure AD with no other reliance during authentication
  • Pro – Provides breach replay protection and reports of leaked credentials since the stored hash can be used to compare against credentials found on dark web (visibility varies depending on Azure AD license, P2 provides best insight). Also enabled the ability to block banned passwords during password change. This benefit is for any configuration providing password hash is replicated and does not have to be used for the authentication
  • Pro – As above even if not using password hash for authentication if its stored and the primary method, e.g. PTA of federation fails (such as loss of connectivity to infrastructure) you can quickly switch to password hash based authentication
  • Con – If the ADDS account has been locked, restricted hours set or password expired it will not impact the ability to logon via Azure AD
  • There is a delay for new accounts or changes to be reflected from AD to Azure AD. This is typically a 30 minute replication window (except for passwords which replicate every 2 minutes). Therefore plan for a delay for new accounts/changes to be reflected in Azure AD
  • You may hear talk of a con is you want the authentication to occur against on-premises DCs however the way tokens and specifically refresh tokens work is only the first authentication would hit AD and after that future access in the same session would not re-authenticate via PTA/federation anyway as the refresh token would be used to acquire additional access tokens. I will cover this in a separate video.

Passthrough-Authentication (PTA)

  • Pro – If a concern with this method you don’t have to store password hashes in Azure AD (however this is a risk vs reward discussion and the benefit of having the hash greatly outweighs any downside IMO)
  • Pro – This is lighter than using federation and establishes an outbound 443 connection to Azure AD not requiring any inbound port exceptions
  • Pro – Any AD account restrictions like hours, account lockout, password expired would be enforced
  • Con – Legacy authentication (pre 2013 Office clients) may not work with PTA
  • This is lighter than federation and easy to deploy multiple PTA instances on-premises for scale and resiliency but does still require deployments
  • When users authenticate, their password is sent to Azure AD (encrypted via HTTPS and then sent via PTA for authentication)

Federation

  • Pro – 3rd party MFA, Azure MFA Server and custom policies/claim rules (outside of the Azure AD 3rd party MFA integration like Duo). It is also possible to create a multi-site ADFS farm, then coupled with some type of geo-DNS solution you can authenticate a user to their closest ADFS “presence
  • Pro – Certificate based authentication
  • Single-sign on if on AD joined machine in corp network. This can be matched with password hash and PTA with seamless-sign on enabled
  • Password never hits the cloud, it is send to federation server. Both others the password is sent to the cloud
  • INITIAL authentication hits federation servers for policy (but subsequent app requests won’t go via ADFS since will use refresh token gained)
  • INITIAL authentication against AD DS domain controllers
  • Con – Large amount of infrastructure required (proxy, adfs servers) especially when other federations moved to Azure AD. The OpEx cost is also a major consideration. Think about the maintenance (managing servers, trusts, certificates) and staff to operate this.
  • Con – With the ADFS proxy it means firewall exceptions to enable inbound traffic
  • Con – Can limit scale/availability

Note that for all scenarios I can still use features like Conditional Access. I try to start at the top of the options and work down if needed. I really consider the federation a legacy option that most organizations are moving away from since Azure AD would be used for the actual application federations moving forward.

Microsoft has a good doc at https://docs.microsoft.com/en-us/azure/security/azure-ad-choose-authn which should also be reviewed.

Any thoughts, please post below!

Add group members to another tenant via Azure AD B2B and PowerShell

I needed to add members of a number of groups from one Azure AD tenant to a group in another Azure AD tenant that would then be given access to a resource. The goal was to not require the users added to have to redeem the invite which is common when adding a B2B user. To do this the first step was a user invited via B2B the normal way, that user redeemed the invite and in this case was then made a global admin (although another option would have been to enable guests to invite guests). The key point was this user had the ability to invite people via B2B and could enumerate users in the invited Azure AD instance which would mean invites would not have to be redeemed.

My first version of the script was very simply however I soon realized I would have to rerun the script to add new users and so I enhanced it to extract the current members of the group, convert to regular email format (since when invite to Azure AD the users have @ replaced with _ and is put in a string with various components separated by a #). The script therefore extracts the first part and converts the _ back to a @. Then looks for only for people who are not already members.

In the script below replace the group names, Azure AD names and IDs to meet your requirements.

 

 

Migrate from ATA to Azure ATP with easy PowerShell

This week Azure Advanced Threat Protection (ATP) was made available as a product that is part of EMS E5 and is essentially ATA in the cloud. ATA is a service that takes a data feed from all domain controllers then uses that data to help identify various types of attack such as pass-the-hash, golden ticket, dumps of DNS and more. Now those capabilities are available using the Azure ATP service removing the need for the on-premises components. Like the lightweight gateway option for ATA where the agent runs on each DC (instead of the full gateway where port forwarding is used), with Azure ATP a sensor is deployed to each DC (however if you don’t want this a standalone sensor can be deployed with port forwarding from DCs just like the regular gateway for ATA) which sends only a fraction of the traffic with minimal overhead.

Head over to https://portal.atp.azure.com, create a new workspace then once you select that workspace, select Configurations – Sensors. From here you can download the sensor setup file and get the access key which will link your DCs to the specific workspace.

I already had ATA deployed in my environment and wanted to simply uninstall the ATA lightweight gateway and silently deploy the Azure ATP sensor on all DCs so I created a simple PowerShell script to do just that. You can pass it a list of DCs, it could read from a file or it can scan the Domain Controllers OU. Of course you could remove the part about uninstalling ATA and just use it to deploy Azure ATP. Note I have saved the agent to a file share so you would want to change the file share I use in this script in addition to adding your access key.

Once deployment is finished complete the configuration via the Azure ATP portal, e.g. enable some sensors as domain synchronizer candidates. Bask in the great monitoring happening for your domain!

Quickly check who are Global Admins in your Azure AD with PowerShell

The code below will list the Global Admins in your Azure AD. Note that if using privileged identity management any users currently elevated would also show.

Also note the PowerShell/Graph API name for Global Admins is Company Administrator.