Enhancing Your IT Infrastructure with Microsoft Intune #Episode 8A
Richard Rex J
Modern Workplace Engineer | SCCM & Intune Expert | Windows Autopilot | Application Packaging | PowerShell Automation | Endpoint Security | Driving IT Efficiency & Security | Senior Associate/Consultant at PwC
Topics Covered: Device Identity, SSO to On-Premises resources, Azure AD Connect, Primary Refresh Token, Azure AD Registered, Azure AD Join, and Hybrid Azure AD Joined.
In this post, we'll examine device identity and the key ideas behind using Intune to improve the IT infrastructure. The foundational knowledge for all Intune Administrators is this.
Here, we'll discuss several forms of device identity as well as some essential ideas like PRT and SSO.
? Device Identity
A device identifier in Azure Active Directory is an object (Azure AD). Similar to users, groups, or apps, this object. Administrators can utilize the information provided by a device identification to decide on access and configuration.
There are three ways to get a device identity:
Device identities are a prerequisite for scenarios like?device-based Conditional Access policies?and?Mobile Device Management with Microsoft Endpoint Manager.
?SSO to on-premises resources
You can access the cloud apps for your tenant with a single sign-on (SSO) experience if your device is joined to Azure Active Directory (Azure AD). You can also obtain SSO experience on Azure AD linked devices to resources and applications that depend on on-premises AD if your environment has on-premises Active Directory Domain Services (AD DS).
? Prerequisites to get SSO
? How SSO Works?
Your users already have SSO access to the cloud apps in your environment if their device is linked to Azure AD. You might want to extend the reach of your SSO experience to your on-premises Line Of Business (LOB) apps, file sharing, and printers if your environment contains an Azure AD and an on-premises AD.
Since they are not attached to your on-premises AD system, Azure AD joined devices are unaware of it. However, with Azure AD Connect, you may give these devices more details about your on-premises AD.
It's likely that you already have Azure AD Connect or Azure AD Connect cloud sync deployed to synchronize your on-premises identity information to the cloud if you have a hybrid setup with both Azure AD and on-premises AD. On-premises user and domain data is synced to Azure AD as part of the synchronization procedure. When a user logs in to a hybrid environment-joined Azure AD device:
In the user's on-premises environment, when attempting to access a resource that requests NTLM or Kerberos, the device:
?Azure AD Connect:
let’s take a step back and look at the big picture. Many organisations today rely heavily on the Microsoft cloud. For efficient collaboration among globally scattered workforces, products like Microsoft 365, Microsoft Teams, SharePoint Online, and OneDrive for Business have become crucial.
Many businesses, nevertheless, also use an on-premises Microsoft infrastructure for excellent reasons. For instance, companies could need to retain highly sensitive data locally to solve specific security or regulatory compliance issues or they can have old systems that are too challenging to move to the cloud.
But maintaining two distinct identities is simply not feasible for the majority of organisations. It's not a good experience for corporate users, to start. They don't want to be repeatedly reminded to enter their credentials for the "other" environment, nor do they care where a piece of content or an application they require is hosted. Additionally, it would double the provisioning labour and eventually result in errors that put security and productivity at risk. IT teams detest managing two entirely different sets of user IDs.
Microsoft helpfully offers two helpful tools: Azure AD Connect sync and Azure AD Connect Cloud sync. What you need to know about these useful applications is provided here.
?What is Azure AD Connect?
Microsoft has created a service called Azure AD Connect to assist businesses with hybrid IT infrastructures. As part of your Azure membership, it is free. Numerous functions are available, such as federation integration and health monitoring. Today, though, we'll concentrate on its most well-known feature: synchronisation.
In Layman’s term, businesses utilise Azure AD Connect to automatically sync identity information between their on-premises Active Directory infrastructure and Azure AD. Users can then access cloud services like Microsoft 365 as well as on-premises apps using the same login information.
?How does it work?
The application is set up on a domain-joined server in your on-site data centre. Express Settings, the default installation option, is utilised for the most typical scenario: data synchronisation between a single on-premises forest with one or more domains and a single Azure AD tenant. Examine the alternative Microsoft-supported topologies if you have several forests or Azure AD tenants.
Syncing only occurs in one direction by default, from on-premises AD to Azure AD. The writeback method can be set up to sync changes from Azure AD back to your on-premises AD, though. The password will be updated in the on-premises AD, for example, if a user changes their password using the Azure AD self-service password management feature.
?What data can the tool sync?
User accounts, groups, and credential hashes in your on-premises AD can be synchronised with Azure AD Connect. The majority of user account attributes, including the security identifier (SID) and user principal name (UPN), are synced.However, the following objects and attributes are NOT synchronized:
?How often is data synchronized?
A scheduler manages the synchronization. A sync job automatically executes every 30 minutes.
PowerShell enables you to:
?Best Practices:
Any application you use should be used in accordance with best practises, especially those that interact with Active Directory and Azure AD, the lifeblood of your IT ecosystem. The most important ones to remember when utilising Azure AD Connect are listed below.
1.?Just like a domain controller, guard the server
As if it were a domain controller, guard the server that houses Azure AD Connect. Limit who may access the server physically, the accounts that can log in interactively, and who has local administration rights, in particular. Additionally, ensure that the tool's service account has only the permissions it requires, and rigorously abide by industry standards for password complexity and expiration.
2. Pay special attention to who has access to the tool
The person who installed the sync engine and local admins on the computer where it runs are the only individuals who may use and administer it by default. Add additional users to the ADSyncAdmins group on the local server to grant them access to the tool. However, considering the effectiveness of the instrument, it's imperative to use caution when enlarging this group.
3. Select the groups you sync to Azure AD with care
By default, your on-premises AD and Azure AD will sync all user and group objects (apart from those mentioned above). However, not every one of your on-premises groups will be usable in the cloud. (Many of them may even no longer be relevant on-premises; group sprawl is a common issue, and routine group cleanup is essential for both productivity and security reasons.)
The ideal synchronization technique is to carefully review each of your on-premises groups. Remember that there are two primary types of AD groups: distribution groups and security groups. Distribution groups serve as the trustee for safeguarding items like file shares and SharePoint lists (primarily email). After that, use the filtering functionality of the sync engine to remove any groups that are unrelated to your cloud environment.
Remember to momentarily disable the scheduled sync process before you begin modifying the filtering so that your changes don't take effect before you have had a chance to confirm that they are accurate.
4. Avoid syncing on-premises admin groups with Azure AD in particular
The on-premises directory can be managed thanks to admin groups for on-premises systems, including Domain Admins. There is no advantage to synchronising these groups to Azure AD. A user in Azure AD can see the membership of the admin group and know exactly which on-premises accounts to target with phishing or other attacks because those groups will be exposed to more prying eyes. However, this does introduce unnecessary risk because those groups will be exposed to more prying eyes. Use the filtering feature to make sure that all admin groups aren't synced, as a result.
5. Use the capabilities of Azure AD to manage Azure AD instead
Use the predefined roles, such as Global Administrator, Application Administrator, Compliance Administrator, and SharePoint Administrator, to create the appropriate cloud-only administrators for managing Azure AD. Because a Global Administrator has the ability to change any administrative option in your Azure AD organization, Microsoft advises giving this job to no more than five individuals in your business. Utilize Microsoft's capabilities like multifactor authentication (MFA) and privileged identity management to further secure accounts that have been given administrator privileges (PIM).
The hybrid groups from your on-premises AD that you choose to sync up are only the beginning in terms of groups. You can construct Microsoft 365 groups in addition to security and distribution groups as well as other cloud-only groups. A Microsoft 365 group can be used to distribute information like a distribution group, safeguard objects like a security group, and operate as a data repository supported by shared mailboxes and SharePoint. Every team in Microsoft Teams also makes advantage of Microsoft 365 groups. Be careful to prevent (or clean up) group sprawl both on-site and in the cloud.
6.?For your sync schedule, follow Microsoft's advice
A sync takes place every 30 minutes by default. However, Microsoft states that a sync must execute at least once every seven days, as follows:
7. Avoid using Azure AD Connect as your backup and recovery and cloud identity management solution
Managing and safeguarding their on-premises Active Directory has been a top priority for many enterprises. Do not, however, believe that simply synchronising your AD with Azure AD guarantees that your cloud IT system is correctly managed and backed up. One of the main factors is that although while most Azure AD objects are synced from on-premises AD, they frequently have extra features that are unique to the cloud, such the user's Office 365 licences, roles, and conditional access policies.
If a user object with one or more cloud-only attributes is deleted, you can recover the on-premises AD user object and synchronise it back up to Azure AD using Azure AD Connect, but the cloud-only attributes will be lost and the user won't be able to use any Office 365 applications or carry out their role-related responsibilities.
Although the Azure AD Recycle Bin might be able to help you in this situation, it's also feasible to delete a cloud-only attribute from an object rather than the entire object. You cannot undo an incorrect alteration to an object by using the Recycle Bin because it is exclusively for removed objects. Having an enterprise-level backup and recovery solution is therefore crucial for your cloud environment. In this white paper, you can read more about the holes that Azure AD Connect creates in your cloud recovery plan.
?Primary Refresh Token
Before we go to Azure AD and Hybrid Azure AD join methods, we need to know the Primary Refresh Token. This is an SSO Token, which enables the device to get the resources. This is equivalent to your Kerberos token for On-premises AD.
?So, what is a PRT?
A Primary Refresh Token (PRT) is a key artifact of Azure AD authentication.?It is a JSON Web Token (JWT) that Microsoft has issued to first-party token brokers to enable single sign-on (SSO) across the applications used on those devices.
The following Windows components play a key role in requesting and using a PRT:
Cloud Authentication Provider?(CloudAP):
CloudAP is a modern authentication provider for Windows sign-in that validates users who log in using a Windows 10 or newer device. CloudAP provides a plugin framework on identity providers can build to enable Windows authentication using the identity provider's credentials.
Web Account Manager?(WAM):
On Windows 10 or later devices, WAM is the default token broker. WAM also provides a plugin framework on which identity providers can build to enable SSO in their applications that rely on that identity provider.
Azure AD CloudAP plugin:
An Azure AD-specific plugin built on the CloudAP framework that checks user credentials against Azure AD during Windows sign-in.
Azure AD WAM plugin:?
An Azure AD-specific plugin built on the WAM framework that adds SSO support to applications that use Azure AD for authentication.
Dsreg:
An Azure AD-specific component on Windows 10 or newer, that handles the device registration process for all device states.
Trusted Platform Module?(TPM):
A TPM is a device-integrated hardware component that provides hardware-based security functions for user and device secrets.
?What does the PRT Contain?
A PRT contains claims that are common to any Azure AD refresh token. In addition, the PRT includes some device-specific claims. Like
Device ID:
A PRT is given to a user for use on a specific device. The device ID claim deviceID identifies the device on which the PRT was issued. This claim is then applied to tokens obtained through the PRT. The device ID claim is used to determine Conditional Access authorization based on device state or compliance.
Session Key:
The session key is a PRT-generated encrypted symmetric key generated by the Azure AD authentication service. When a PRT is used to obtain tokens for other applications, the session key serves as proof of possession.
? Can I see what’s in a PRT?
A PRT is an opaque blob sent from Azure AD whose contents are not known to any client components. You cannot see what’s inside a PRT.
? How is PRT Issued?
The user logs on to their machine by authenticating using his user id and password and that info will go to your Azure AD
At that point, your Azure AD returns an SSO token known as PRT, which is cached in your Windows 10 device. This corresponds to Kerberos in your on-premises AD.
After that, whenever your Windows devices want to access something, they will go to Azure Active Directory and ask, "Hey, I have my PRT pass with me, can I have an SSO token to access Office 365 Apps?"
Then your AD will check if the PRT is Valid and gives the SSO token to the device
Now, with that SSO token, the device will request permission from the Office M365 Application to access its resources, and it is critical to have PRT to access many other things.
? What is the lifetime of a PRT?
Once issued, a PRT is valid for 14 days and is continuously renewed as long as the user actively uses the device.
? Where to check if the PRT is cached?
Open the command prompt in the device and type the command “dsregcmd /status” and scroll down to SSO state, here you can see the status of AzureAdprt as Yes/no.
Also if you observe the interval between AzureAdPrtUpdateTime and expiry time is 14 days
? How is a PRT used?
A PRT is used by two key components in Windows:
Azure AD CloudAP plugin:
During Windows sign-in, the Azure AD CloudAP plugin requests a PRT from Azure AD using the user-supplied credentials. It also caches the PRT to allow for cached sign-in when the user does not have access to the internet.
Azure AD WAM plugin:
When users attempt to access applications, the Azure AD WAM plugin on Windows 10 or later uses the PRT to enable SSO. For applications that rely on WAM for token requests, the Azure AD WAM plugin uses the PRT to request refresh and access tokens. It also supports browser SSO by inserting the PRT into browser requests. Browser SSO is supported in Windows 10 or later on Microsoft Edge (natively), Chrome (via the Windows 10 Accounts or Office Online extensions), and Mozilla Firefox v91+ (Firefox Windows SSO setting).
So, these are some key concepts which an IT Administrator needs to know before even jumping to Azure AD join Devices. Now, let start to look into these types.
? Azure AD Registered:
On a Windows 10 or newer device, Azure AD registered devices are signed in with a local account, similar to a Microsoft account. These devices have an Azure AD account that allows them to access organizational resources. Access to organizational resources can be restricted based on the Azure AD account and Conditional Access policies applied to the device identity.
Using Mobile Device Management (MDM) tools such as Microsoft Intune, administrators can secure and further control these Azure AD registered devices. MDM allows you to enforce organizational-required configurations such as requiring encrypted storage, password complexity, and security software updates.
When accessing a work application for the first time, or manually using the Windows 10 or Windows 11 Settings menu, Azure AD registration can be completed.
? Scenarios where you use the Azure AD Registered Devices
A user in your organization wishes to use your benefits enrolment tool from their personal computer. Your organization requires access to this tool from an Intune-compliant device. The user registers their home PC with Azure AD, and the necessary Intune policies are implemented, granting the user access to their resources.
领英推荐
Another user wishes to access their organization's email on their rooted personal Android phone. Your company requires a compliant device and has implemented an Intune compliance policy to prevent rooted devices from being used. This device prevents the employee from accessing organizational resources.
? Briefing
Definition: The device can be Registered to Azure AD without requiring an organizational account to sign in.?
Primary Audience:The Devices which are Azure AD registered are typically personal devices or Mobile devices i.e. your BYOD devices that are workplace joined to access company resources.
So, you can log in to the device using your local user id and password without requiring you to enter your organizational credentials.
Device Ownership: The device can be owned by a User or an Organization.?
Operating Systems: The OS that can are eligible for Azure AD Registered are Windows 10 or newer,?iOS, Android, and macOS.
Provisioning Methods:
Device sign-in options:
Device Management: The devices can be managed using Mobile Device Management and Mobile Application Management (example: Microsoft Intune).
Key Capabilities:
? Azure Active Directory Joined?
Any organization, regardless of size or industry, can deploy Azure AD joined devices. Azure AD join works in hybrid environments as well, providing access to both cloud and on-premises apps and resources.
Devices that have been joined to Azure AD are signed in with an organizational Azure AD account. The Azure AD account and Conditional Access policies are applied to the device to have control over resource access.
Administrators can secure and control Azure AD-joined devices using Mobile Device Management (MDM) tools such as Microsoft Intune, or in co-management scenarios using Microsoft Endpoint Configuration Manager (MECM). These tools enable organizations to enforce configurations such as:
Administrators can use Configuration Manager to manage apps from the Microsoft Store for Business and Education to make organization applications available to Azure AD joined devices.
Azure AD join can be accomplished using self-service options like the Out of Box Experience (OOBE), bulk enrolment, or?Windows Autopilot.
When Azure AD joined devices are on the organization's network, they can still maintain single sign-on access to on-premises resources. Devices that have been joined to Azure AD can still authenticate to on-premises servers such as a file, print, and other applications.
? Scenarios where you use the Azure AD Join Devices
Confusing? ?? don't worry! I'll explain you with a short story
Let's imagine that Mike is a businessman who runs a supplier of paints, hardware, and other goods.
Mike makes the decision, Hey! My company needs to be modernised, and I want my staff to use the newest technologies to manage it. He so decides to partner with Microsoft in order to utilise its cloud services, including Dynamics, Office 365, Azure, and One Drive.
Mike employs numerous individuals and has numerous locations across the nation.
The people that worked with Mike had a variety of devices with various platforms and operating systems. Mike fought tooth and nail for a regulated infrastructure because he didn't want his staff to have access to every resource he had available.
So Mike contacted Microsoft to inquire about managing the device.
In accordance with Microsoft's advice, Mike bought their solution and connected the devices to Azure AD.
The device will be added to Intune after Mike enables MDM, and Mike will then have complete control over all the devices in his tenant.
Mike can do this so that his staff members have secure access to various company resources.
? Background process on how a device becomes Azure AD joined in Intune?
Your Windows 10 device, Azure Active Directory, Azure Device Registration Services (ADRS), and your MDM solution are the four elements in this scenario (Intune).
The sign-in information will be delivered to the Azure Active Directory when a user attempts to set up a new device that was provided by the company using the Azure AD credentials (provided by the company) and after the user has been authenticated using MFA.
When Azure AD receives sign-in data, it checks the user against the database and then returns the ADRS SSO (Single Sign-on token), local user account information, and MDM URLs.
The Windows 10 device will now use the SSO offered by Azure AD to register against the ADRS.
The Windows 10 device will now use the SSO offered by Azure AD to register against the ADRS.
The device registration certificate for the client is issued by the Azure AD, and it is given to the client by the ADRS.
The MDM Enrolment is then provided to the MDM Enrolment Agent after it is completed.
To obtain SSO for using the MDM Applications, the MDM Agent connects to Azure AD.
The MDM agent that is installed on the client machine receives SSO when Azure AD has verified the request.
MDM Agent uses the SSO to enroll the device to Intune.
The policies, software, and other settings will be pushed to the client devices by Intune once the device has been enrolled in it.
Briefing:
Definition:Devices that are Azure AD joined requires an organizational account to sign-in
Primary Audience:
Device Ownership: Organization
Operating Systems:
Provisioning Methods:
Device sign-in options
Organizational accounts using:
Device Management:
Key Capabilities:
? Hybrid Azure AD Joined
So, Hybrid Azure AD is the best option for you if your business already has an On-Premises Active Directory and wishes to move it to cloud Azure Active Directory while retaining the device in On-Premises Active Directory.
Both your on-premises Active Directory and Azure Active Directory receive these devices.
Devices that are joined to hybrid Azure AD frequently require network access to your on-premises domain controllers. Without this connection, the devices become non-functional. If you are concerned about this requirement, think about having Azure AD join your devices.
? Scenarios where you use the Hybrid Azure AD Join Devices
? It’s Storytime! ??
We have a user from the sales department by the name of Susan. Susan frequently travels abroad to conduct business and meet with clients.
When she needs access to both on-premises and cloud services, you can use your Azure AD and On-premises AD.
Here, resources will be created for this particular user and a sync between your on-premises and Azure AD will take place using Azure AD Connect. You are now connected to SCCM and Intune Hybrid.
Susan now has access to both your on-site and cloud resources.
Now let’s look at the workflow:
1.?Susan gives her Username and Password and it will be authenticated In the Azure AD
2.?She gets PRT from Azure AD
3.?Now, she will be able to authenticate in the on-prem Active directory
4.?Where she will get her Kerberos token
5. After this is done she will get an SSO token from Azure AD where she can able to access the cloud resources like one drive, office 365, and dynamics
6. Then you will have your Kerberos Token from On-premises AD to access on-premises resources.
? Briefings
Definition: Devices that are Hybrid Azure AD join required to sign in using an organisational account and connected to both on-premises AD and Azure AD
Primary Audience:
Device Ownership: Organization
Operating Systems:
Provisioning:
Device Sign-in Option:
Device Management:
Key-Capabilities:
In My next article, we will be looking at Device Enrollment Blade and explore the options available in this balde. Stay tuned and happy learning ??
Solution Architect bei ACP IT Solutions - not interested in job offers
2 年Richard Rex thank you for this detailled article! Good work. Can I forward htis article to the #conditionalaccess group ? Or will you do this ? https://www.dhirubhai.net/groups/9235288/