This is section 3 of AZ-500 preparation guide and starting with IdP and SSO.
Table of Contents
What is IdP?
Azure AD is also consider as IdP, it can authenticate Your with different cloud services like Google and AWS.
An identity provider (IdP) is a service that stores and manages digital identities. Companies use these services to allow their employees or users to connect with the resources they need. They provide a way to manage access, adding or removing privileges, while security remains tight.
In Single-tenant authentication You can use specific url’s for authentication.
And in Multi-tenant without the tenant part.
OpenID Connect (OIDC) is an authentication protocol built on OAuth 2.0 that you can use to securely sign in a user to an application. When you use the Microsoft identity platform’s implementation of OpenID Connect, you can add sign-in and API access to your apps.
IdP works with Token, here a little brief introduction to Access, ID, and SAML2
What SSO means?
Using SSO means a user doesn’t have to sign in to every application they use. With SSO, users can access all needed applications without being required to authenticate using different credentials.
What options there is?
- Cloud applications can use OpenID Connect, OAuth, SAML, password-based, or linked for SSO. Single sign-on can also be disabled.
- On-premises applications can use password-based, Integrated Windows Authentication, header-based, linked for SSO. The on-premises choices work when applications are configured for Application Proxy.
- OpenID Connect and OAuth – Choose OpenID Connect and OAuth 2.0 if the application you’re connecting to supports it.
- SAML – Choose SAML whenever possible for existing applications that do not use OpenID Connect or OAuth.
- Password-based – Choose password-based when the application has an HTML sign-in page. Password-based SSO is also known as password vaulting. Password-based SSO enables you to manage user access and passwords to web applications that don’t support identity federation. It’s also useful where several users need to share a single account, such as to your organization’s social media app accounts. Password-based SSO supports applications that require multiple sign-in fields for applications that require more than just username and password fields to sign in. You can customize the labels of the username and password fields your users see on My Apps when they enter their credentials.
- Linked – Choose linked when the application is configured for SSO in another identity provider service. The linked option lets you configure the target location when a user selects the application in your organization’s in the portals. You can add a link to a custom web application that currently uses federation, such as Active Directory Federation Services (AD FS).You can also add links to specific web pages that you want to appear on your user’s access panels and to an app that doesn’t require authentication. The Linked option doesn’t provide sign-on functionality through Azure AD credentials.
- Integrated Windows Authentication (IWA) – Choose IWA single sign-on for applications that use IWA, or for claims-aware applications.
- Header-based – Choose header-based single sign-on when the application uses headers for authentication.
Determining the user experience for accessing apps
Azure AD provides several customizable ways to deploy applications to end users in your organization:
- Azure AD My Apps
- Microsoft 365 application launcher
- Direct sign-on to federated apps (service-pr)
- Deep links to federated, password-based, or existing apps
You can determine whether users assigned to an enterprise app can see it in My Apps and Microsoft 365 application launcher.
What You need to get started?
- The user name and password of a Microsoft 365 / Azure Hybrid Identity Administrator or Global Admin but I prefer the first one.
- The user name and password of an AD DS domain administrator
- Which authentication method (PHS, PTA, federated)
- Whether you want to use Azure AD Seamless Single Sign-on (SSO)
If You want to read more on best practices.
Setup from Azure AD
You have the possibility to setup Directory Sync from Microsoft 365 Admin portal or from Azure portal. I will go with Azure but the processes are similar.
Open portal.azure.com and type Azure Active
Then open Custom domain names and Add custom domain.
Select how You want to verify the domain ownership. I will go with TXT.
Add the txt-records to your public DNS.
And hit Verify.
And You will see it verified.
Now You have to domain and You need the users to the cloud.
Azure AD Connect options
There two paths You can follow with Your syncing setup and these are.
Express is the most common option and is used by about 90% of all new installations. It was designed to provide a configuration that works for the most common customer scenarios.
- You have a single Active Directory forest on-premises.
- You have an enterprise administrator account you can use for the installation.
- You have less than 100,000 objects in your on-premises Active Directory.
- Password hash synchronization from on-premises to Azure AD for single sign-on.
- A configuration that synchronizes users, groups, contacts, and Windows 10 computers.
- Synchronization of all eligible objects in all domains and all OUs.
- Automatic upgrade is enabled to make sure you always use the latest available version.
Options where you can still use Express:
- If you do not want to synchronize all OUs, you can still use Express and on the last page, unselect Start the synchronization process…*. Then run the installation wizard again and change the OUs in configuration options and enable scheduled sync.
- You want to enable one of the features in Azure AD Premium, such as Password writeback. First go through express to get the initial installation completed. Then run the installation wizard again and change the configuration options.
The customized path allows many more options than express. It should be used in all cases where the configuration described in previous section for express is not representative for your organization.
- You do not have access to an enterprise admin account in Active Directory.
- You have more than one forest or you plan to synchronize more than one forest in the future.
- You have domains in your forest not reachable from the Connect server.
- You plan to use federation or pass-through authentication for user sign-in.
- You have more than 100,000 objects and need to use a full SQL Server.
- You plan to use group-based filtering and not only domain or OU-based filtering.
How to setup with Custom settings
When You download and install Azure AD Connect, You will see the following login screen.
Enter credentials and hit next.
When You have logged in to Azure tenant. You have to add Your Local AD domain FQDN. For this Your need Enterprise Admin credentials.
|Create new account
|Create the Azure AD DS account that Azure AD Connect needs to connect to the Active Directory forest during directory synchronization. After you select this option, enter the username and password for an enterprise admin account. Azure AD Connect uses the provided enterprise admin account to create the required Azure AD DS account. You can enter the domain part in either NetBIOS format or FQDN format.
|Use existing account
|Provide an existing Azure AD DS account that Azure AD Connect can use to connect to the Active Directory forest during directory synchronization. You can enter the domain part in either NetBIOS format or FQDN format. This account can be a regular user account because it needs only the default read permissions. But depending on your scenario, you might need more permissions.
Once added Your will the domain added.
Different sign-in options
|Single sign-on option
|Password hash synchronization
|Users can sign in to Microsoft cloud services, such as Microsoft 365, by using the same password they use in their on-premises network. User passwords are synchronized to Azure AD as a password hash. Authentication occurs in the cloud. For more information, see Password hash synchronization.
|Users can sign in to Microsoft cloud services, such as Microsoft 365, by using the same password they use in their on-premises network. User passwords are validated by being passed through to the on-premises Active Directory domain controller.
|Federation with AD FS
|Users can sign in to Microsoft cloud services, such as Microsoft 365, by using the same password they use in their on-premises network. Users are redirected to their on-premises Azure Directory Federation Services (AD FS) instance to sign in. Authentication occurs on-premises.
|Federation with PingFederate
|Users can sign in to Microsoft cloud services, such as Microsoft 365, by using the same password they use in their on-premises network. Users are redirected to their on-premises PingFederate instance to sign in. Authentication occurs on-premises.
|Do not configure
|No user sign-in feature is installed or configured. Choose this option if you already have a third-party federation server or another solution in place.
|Enable single sign-on
|This option is available with both password hash sync and pass-through authentication. It provides a single sign-on experience for desktop users on corporate networks. For more information, see Single sign-on.
Note: For AD FS customers, this option is unavailable. AD FS already offers the same level of single sign-on.
During the config You can also choose what OU’s will be synced.
And also options features to be included. The ones that will be covered in this preparation guide are PHS and Password writeback.
If You have multiple Domain connected, You can define how to identify the users.
|Users are represented only once across all forests
|All users are created as individual objects in Azure AD. The objects aren’t joined in the metaverse.
|This option joins users and contacts if the mail attribute has the same value in different forests. Use this option when your contacts were created by using GALSync. If you choose this option, user objects whose mail attribute is unpopulated aren’t synchronized to Azure AD.
|ObjectSID and msExchangeMasterAccountSID/ msRTCSIP-OriginatorSID attributes
|This option joins an enabled user in an account forest with a disabled user in a resource forest. In Exchange, this configuration is known as a linked mailbox. You can use this option if you use only Lync and if Exchange isn’t present in the resource forest.
|SAMAccountName and MailNickName attributes
|This option joins on attributes where the sign-in ID for the user is expected to be found.
|Choose a specific attribute
|This option allows you to select your own attribute. If you choose this option, user objects whose (selected) attribute is unpopulated aren’t synchronized to Azure AD. Limitation: Only attributes that are already in the metaverse are available for this option.
Based on the services you selected in the previous step, this page shows all attributes that are synchronized. This list is a combination of all object types that are being synchronized. If you need some attributes to remain unsynchronized, you can clear the selection from those attributes.
Password Hash Sync is the most common approach for many organizations. You have source authority AD and You will sync user attributes and the password hash.
Pass-through authentication is similar to ADFS authentication. When You enable PTA, you will get the following prompt.
And the wizard will enable PTA with the following.
Ports for PTA
Ensure that Authentication Agents can make outbound requests to Azure AD over the following ports:
|How it’s used
|Downloads the certificate revocation lists (CRLs) while validating the TLS/SSL certificate
|Handles all outbound communication with the service
|Authentication Agents report their status every ten minutes over port 8080, if port 443 is unavailable. This status is displayed on the Azure AD portal. Port 8080 is not used for user sign-ins.
Azure portal for info
Once You have enabled PTA You will the agents from Azure portal.
The notification comes from too less agents installed.
Installing more makes the environment HA but it works with one (at least for the demo)
Microsoft has an excellent article on the supported and unsupported scenarios.
Enabling single sign-on
On the Single sign-on page, you configure single sign-on for use with password synchronization or pass-through authentication. You do this step once for each forest that’s being synchronized to Azure AD. Configuration involves two steps:
- Create the necessary computer account in your on-premises instance of Active Directory.
- Configure the intranet zone of the client machines to support single sign-on.
Azure AD Cloud sync
Microsoft has recently introduced Cloud sync which has the ability to provisions users and groups to On-premises AD. It need a Cloud-based SCIM-interface to do the initial creation.
Cloud sync has a light-weight agent but the features are almost the same than in AAD Connect.
Quick note! Exchange hybrid needs Azure AD Connect, Cloud sync isn’t supported.
How to migrate to PTA from ADFS
Microsoft has made some really detail instructions for this process.
Things to remember
PTA = Pass-Through Authentication. Similar to ADFS and can be used for replacing ADFS completely.
PHS = Password Hash synchronization. Password hash and specified User attributes will be synced to the cloud.
SAML2 = Authentication protocols for ADFS and OpenID Connect.
IdP = Identity provider. This will provide Your identity and Authenticate to access services.
MyApps portal = Portal for storing users application that they can do SSO to. Address https://myapplications.microsoft.com
Rights for AAD Connect = Hybrid Identity Administrator or Global admin and Enterprise Admin in the local AD
That’s it, long posts but there is a lot to explain. In the next part we will cover App registrations and permissions.