Labels

Windows Autopilot Configuration

Windows Autopilot is a collection of technologies used to set up and pre-configure new devices, getting them ready for productive use. Windows Autopilot can be used to deploy Windows PCs or HoloLens 2 devices. For more information about deploying HoloLens 2 with Windows Autopilot, see Windows Autopilot for HoloLens 2.

Windows Autopilot can also be used to reset, repurpose, and recover devices. This solution enables an IT department to achieve these goals with little to no infrastructure to manage, with a process that's easy and simple.

Windows Autopilot simplifies the Windows device lifecycle, for both IT and end users, from initial deployment to end of life. Using cloud-based services, Windows Autopilot:

  • Reduces the time IT spends on deploying, managing, and retiring devices.
  • Reduces the infrastructure required to maintain the devices.
  • Maximizes ease of use for all types of end users.

1.Autopilot Deployment Process

The swim-lane diagram below illustrates the contributing components and their interactions with one another.

Windows deployment and management using Autopilot and Intune

2.Setting up permissions

It is important to have the proper permissions in place before you can use Intune.  To be sure, follow the instructions laid out here.  To ensure you can get going fast, you will need to assign:
  • Azure AD Global Administrator
  • Intune Administrator
That said, you could avoid requiring Global Administrator but for about 2 tasks, the assignment of the enrollment group and Azure branding.  Once done those tasks, you could be functional with:
  • What:
    • User Administrator
    • Groups Administrator
    • Cloud Device Administrator
    • Azure AD joined device local administrator
    • License Administrator
  • Why: manipulate Azure AD to support custom dynamic groups and assign users, devices and licenses
  • What:
    • Intune Administrator
  • Why: to import devices, and create deployment, compliance and configuration policies and profiles and create and deploy applications.
Also, be sure you have the right licensing:
Set up the appropriate Role Base Access Control (RBAC):
Using Scope tags to provide granular access management

3.Setting up basic connectivity

3.1 What are the connection scenarios?

There are 2 connection (device join) scenarios for devices provisioned with Autopilot and Intune.  These are Azure AD Only (simpler) and Hybrid (more complex).
  • Azure AD join
Azure AD join is where a device is connected to a customer’s Azure Active Directory (AAD), which is Microsoft’s cloud directory service.  Azure AD joined devices are signed into using an organizational Azure AD account, and this account is used to enroll the device into Endpoint Manager, after which policies and profiles (and applications) can be assigned to configure the device to the organization’s needs.   Access to resources in the organization can be further limited based on that Azure AD account.
  • Hybrid Join
Hybrid Join is a term used to indicate that a Windows 10 computer has been joined to both the Azure Active Directory as well as a customer’s on-premises domain.  This can be done with Autopilot while the workstation is physically connected to the on-premises domain, or through recently added functionality that allows a remote connection to the on-premises domain through VPN software (limited support at present), often referred to as Hybrid Join over VPN.   Once connected to the on-premises domain, the device can be managed from both the Azure side (through Intune) and on the domain side (through Group Policy Objects (GPO)) and other methods like domain installed anti-malware solutions).  Just like AAD, hybrid devices are enrolled into Intune, and configured thereafter.

3.2 How do we connect our on-premises domain to Azure?

On-premises domain connection and synchronization to Azure is done by means of installing a connection service called the Azure AD Connector.  The Azure AD Connector is a tool for connecting on premises identity infrastructure to Microsoft Azure AD.  The install wizard deploys and configures pre-requisites and components required for the connection, including sync and sign on.

3.3 How do we create computer objects in our on-premises domain using Intune?

In order for computer objects to be created on-premises when using Autopilot and Intune (called Hybrid Join), another connector service is required between the on-premises domain and Intune.  It is called the Intune Connector for AD.  The Intune Connector for AD pre-creates Autopilot-enrolled computer objects in the on-premises Active Directory domain in one or more specified OUs.  The computer that hosts the Intune Connector must have the delegated permissions to create the computer objects within the domain in the OU containers specified.  Later, a domain join profile (specifying the proper OU) in Intune is passed to the computer being deployed through what’s known as an Offline Domain Join (ODJ) BLOB, and during the build process, the computer attaches itself the pre-created computer object created by the Intune Connector for AD in that particular OU.  The diagram below helps describe this scenario:

  Hybrid Domain Join scenario

It’s worth noting that it is possible to install more than one Intune Connector for AD, and this can be done if scale is a factor. For more information, see MS Reference: Enrollment for hybrid Azure AD-joined devices - Windows Autopilot | Microsoft Docs, where they say:
The Intune Connector for Active Directory must be installed on a computer that's running Windows Server 2016 or later. The computer must also have access to the internet and your Active Directory. To increase scale and availability, you can install multiple connectors in your environment. We recommend installing the Connector on a server that's not running any other Intune connectors. Each connector must be able to create computer objects in any domain that you want to support.

3.4 Basic hybrid connectivity overview

Use the diagram below as a reference to steps outlined in the document.

Basic connectivity setup for Autopilot and Intune

3.5 Connector configuration steps:

1) Configure the Azure AD Connector for hybrid join (requires Global Admin role)

    a. Follow the instructions as laid out by Microsoft here in the Configure hybrid Azure AD join section:

        i. MS Reference:

        Configure hybrid Azure Active Directory join for managed              domains | Microsoft Docs                   

2) Prepare for and install the Intune Connector for AD (requires Global Admin role)

    a. Decide what computer(s) will host the Intune Connector

        i. Can be installed on computer hosting AD Connector

    b. Delegate Authority to that computer(s) to create computer objects

         i. MS Reference:
         autopilot-hybrid 

        ii. Repeat the delegation process for each OU container you would like to have Autopilot objects created in.

    c. Download the Intune Connector for AD

         i. MS Reference:

    d. Install the Intune Connector for AD on the server(s)

        i. Enter appropriate credentials (on-premise domain and cloud)

    e. Validate Connector(s) connection

        i. Open endpoint.microsoft.com

        ii. Navigate to Devices/Enroll Devices

        iii. Select Intune Connector for Active Directory button

        iv. Confirm computer(s) set up in steps a-d is visible

As you might notice, you can have multiple Intune Connectors installed.

Note: The Intune Connector for Active Directory must be installed on a computer that's running Windows Server 2016 or later.  The computer must also have access to the internet and your Active Directory. To increase scale and availability, you can install multiple connectors in your environment. We recommend installing the Connector on a server that's not running any other Intune connectors.  Each connector must be able to create computer objects in any domain that you want to support.

At this point, Autopilot and Intune are ready to be set up.

4. Enhanced hybrid connectivity overview

Enhanced connectivity in Intune refers to the addition of on-premises to Azure connectors to support remote domain join (Hybrid Join over VPN), increase security (Certificate Connectors) and optionally support endpoint management from SCCM and Intune (Co-management).  This diagram below shows this.  Contoso is using enhanced connectivity (no SCCM).  The illustration below shows this configuration

                        Figure 4 – Enhanced (Contoso) connectivity setup for Autopilot and Intune

4.1 Hybrid join over VPN

In order to deliver Hybrid join functionality to devices outside the corporate network (i.e. remote workers), it is necessary to establish a secure VPN (Virtual Private Network) from the endpoint device through the Internet back to the corporate network.

This secure tunnel is created through a combination of device and user certificates and VPN software which must be sent to the machine as part of the deployment process.

This secure tunnel implements pre-login authentication to establish that the endpoint device is a secured corporate entity.

Contoso is using Palo Alto product to support VPN pre-login authentication. For more information about configuring Palo Alto Global Protect in a pre-login scenario, see the link below:

4.2 Connector for Microsoft Intune (Certificate Connector)

With some VPN products, you might want to enhance security at the endpoints for others (i.e. zero-trust networks), this might not be required.

With Microsoft Intune, you can easily give your users access to corporate resources through VPN, Wi-Fi or email profiles, and by authenticating these connections with certificates your end users don't have to enter their usernames and passwords when making a connection. You can use Intune to assign these certificates to devices you manage.

PFX is a file format used for storing encrypted objects in a single file. Typically, you will see a private key and its X.509 certificate stored together (this could include the certificate chain). PKCS stands for “Public Key Cryptography Standards” and it was created by RSA Security LLC in the 1990s.

4.2.1 How does it work

The diagram below shows the information flow from certificate profile creation to endpoint device:

Figure 5 – Intune Certificate Connector

Process Flow:
    1) An Admin creates a PKCS certificate profile in Intune.
    2) The Intune service requests that the on-premises Intune Certificate Connector create a new certificate for the user.
    3) The Intune Certificate Connector sends a PFX Blob and Request to your Microsoft Certification Authority.
    4) The Certification Authority issues and sends the PFX User Certificate back to the Intune Certificate Connector.
    5) The Intune Certificate Connector uploads the encrypted PFX User Certificate to Intune.
    6) Intune decrypts the PFX User Certificate and re-encrypts for the device using the Device Management Certificate. Intune then sends the PFX User Certificate to the Device.
    7) The device reports the certificate status to Intune.

So, as you can see, we need to have an Intune Certificate Connector installed to broker the certificate requests on behalf of the on-premises infrastructure to the endpoint devices.

Note similarity (Blob) between this connector and the Intune Connector for AD, which also uses the concept of encapsulating and passing information from the cloud to the on-premise domain.

Note also that the Certificate Connector for Microsoft Intune update functionality requires connectivity as follows:
• Port: 443
• Endpoint: autoupdate.msappproxy.net

4.2.2 Setting Up a certificate connector

In order to complete the PKCS connector setup (as part of our hybrid join over VPN), we need to complete some steps as outlined here (MS guidance):
  • Look for a message CertUtil: -ca.cert command completed successfully. That confirms the Root CA has been exported successfully.
  • Go to the root drive and you should find the Root Certificate where and as you named it.
Don’t know where your root CA server is?
  • Option 1: Open an admin command prompt on a domain connected device and type: certutil -config - -ping
  • Option 2:
    • Sign in by using domain administrator to computer that connects to the domain.
    • Install Windows Support Tools.
    • Go to Start -> Run -> Write adsiedit.msc and press on Enter button.
    • Navigate to: 
      • CN=Certification Authorities,CN=Public Key
      • Services,CN=Services,CN=Configuration,DC=ntdomain,DC=com
      • Under Certification Authorities, you'll find your Enterprise Root Certificate Authority server. 
        • Rename DC=ntdomain and DC.com accordingly
  • Step 5: Suggested template name: Win-Autopilot
  • Steps 10a/13b: use the computer name where Certificate connector is installed
4)Validate that the Connector is installed
Sign into Intune (intune.microsoft.com)
Go to Tenant administration > Connectors and tokens > Certificate connectors.
Select a connector to view its status.

5)Create a trusted (root) certificate profile and assign to target device group

6)Create PKCS certificate profile and assign to target device group
  • Sample PKCS configuration profile settings:


Labels:

Comments

Post a Comment

Popular Posts

Disclaimer

This blog is not intended to be advice on how to manage your environment. these accounts are based on experiences of my own lab. Always approach information you find outside official documentation with skepticism and follow the golden rule: Never test in production.