The Short and Sweet for Remote Work: Cached Passwords and Device Provisioning

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 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 connectivity line of sight to a to use the new password and update cached credentials. This means that devices must either be on the organization's internal or on a VPN with access to an on-premises . 

If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by Azure , you can implement hybrid Azure AD joined devices. These devices are joined to your on-premises and registered with your Azure Active Directory. 


For more Information, please see: 


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 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 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 informationsee theOverview 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 informationseeBulk enrollment for Windows devices. 


Mobile Device Management (example: Microsoft Intune) is recommended. 





This article was originally published by Microsoft's ITOps Talk Blog. You can find the original article here.