This article is contributed. See the original author and article here.
In recent months, we have many changes at architecture design and security, with users, services, and devices. This article attempts to describe the scenarios that could be driven by remote work and could identify possible configurations based on the business requirements.
Keep in mind that for these scenarios the users’ accounts must be synchronized with Azure AD.
Scenario 1 (Cached Credentials in Workstations/Laptops):
Users who frequently worked from the office (being able to have weekly home offices), today are working from remote locations. Workstations/Laptops no longer connect to Domain Controllers; therefore, it is not possible to change configurations by GPO and to be impacted. In case the user changes his password (through Cloud or VDI services), the device will keep the old password. The user will have to log in to their computer with an old password and then use the new one to access the services.
This scenario is common in those organizations that do not use VPN services. Where your applications are accessed through Remote Apps, Cloud services or VDIs.
Machines must have network connectivity line of sight to a domain controller to use the new password and update cached credentials. This means that devices must either be on the organization’s internal network or on a VPN with network access to an on-premises domain controller.
If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by Azure Active Directory, you can implement hybrid Azure AD joined devices. These devices are joined to your on-premises Active Directory and registered with your Azure Active Directory.
For more Information, please see: https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-azure-ad-join-hybrid
Scenario 2: (Device Provisioning for Distributed Users – only Win10 devices)
Continuing with the remote work scenarios, maybe, we need to assign new devices (Workstation / Laptops) to users who are outside our offices, therefore, it is not possible to log in for the first time to contact a Domain Controller so that the password is stored (cached) on the device, and then by logging in “offline”.
In this scenario, we can use Azure AD Join. It will allow users to log in with their network account (eg UPN) and offer a single sign-on (SSO) experience for both the cloud and their AD Local based applications. If Azure AD joined machines are not connected to your organization’s network, a VPN or other network infrastructure is required. On-premises SSO requires line-of-sight communication with your on-premises AD DS domain controllers.
You can provision Azure AD join using the following approaches:
- Self-service in OOBE/Settings - In the self-service mode, users go through the Azure AD join process either during Windows Out of Box Experience (OOBE) or from Windows Settings. For more information, see Join your work device to your organization’s network.
- Windows Autopilot - Windows Autopilot enables pre-configuration of devices for a smoother experience in OOBE to perform an Azure AD join. For more information, see the Overview of Windows Autopilot.
- Bulk enrollment - Bulk enrollment enables an administrator driven Azure AD join by using a bulk provisioning tool to configure devices. For more information, see Bulk enrollment for Windows devices.
Mobile Device Management (example: Microsoft Intune) is recommended.
Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.
Recent Comments