Windows Auto-Pilot + Cloudi-Fi + Zscaler

Back to use cases

Seamless Microsoft Autopilot users onboarding with Cloudi-Fi and Zscaler

While Autopilot is a powerful tool for managing device deployments in an organization, there can be challenges when implementing it with a Bring Your Own Device (BYOD) scenario.

  • Device Heterogeneity: BYOD environments often consist of various device models and configurations. Ensuring a consistent user experience across different devices can be challenging.
  • Network Connectivity: Autopilot relies on a network connection to download configuration profiles and applications. In BYOD scenarios, users may not always have reliable access to the corporate network, leading to deployment delays or failures.
  • User Satisfaction: The user experience during the Autopilot process can impact user satisfaction. Configuring Autopilot to minimize disruptions and provide clear instructions to users is essential, especially when dealing with personal devices.
  • Security Concerns: Internet access may expose employees to inappropriate or offensive content. It increases the risk of unauthorized access attempts and potential breaches by external attackers looking for company network vulnerabilities. Implementing conditional access policies and compliance checks becomes crucial for securing corporate data.
VPN Tunnel set up with Cloudi-Fi and Zscaler ZIA
Set up security profiles with Cloudi-Fi Identity Platform

Cloudi-Fi Enhances Device Onboarding with Autopilot

Cloudi-Fi's in-house developed access control platform offers full flexibility for simplifying the onboarding process, offering seamless integration with Microsoft Autopilot to enhance user experience. This use case illustrates an integration with Zscaler; however, additional integrations are available: List here or link to the Partner ecosystem page.

Cloudi-Fi offers the capability to deactivate captive portals and manage device enrolment within a specific context. This feature can seamlessly integrate into an existing Guest WiFi SSID, either alongside a captive portal or on a dedicated SSID with the captive portal disabled. If integrated within the captive portal, a set of deterministic methods for device safelists must be defined, typically relying on device signatures or MAC addresses, potentially facilitated through scripting for automated enrolment.

Zscaler Admin Logs - Cloudi-Fi seamless Integration

Together Cloudi-Fi and Zscaler Simplifies AutoPilot Deployment with Enhanced Security and Flexibility

In conjunction with our DHCP service, once these parameters are established, Windows devices are effortlessly recognized upon reconnection. Furthermore, for user authentication, Cloudi-Fi supports authentication for large customer systems facilitated by the SAML authentication protocol, enabling device authentication on the network.

Finally, the ongoing maintenance of safe listing safelisting for Microsoft and Apple URLs/IPs is managed by Cloudi-Fi. 

AutoPilot deployment with Cloudi-Fi is flexible and adapted to your security needs. As an illustration, here are some potential scenarios.

Cloudi-Fi and Zscaler Streamline Autopilot Device Provisioning with Enhanced Security and Flexibility

Devices would be registered in bulk or individually with their MAC address as an identifier. When these devices pop up, the Cloudi-Fi DHCP server delivers an IP address belonging to a specific Zscaler sub-location where the security policies allow connection to MS Autopilot servers. That doesn’t require segregation at the SSID level.

all devices from the walled garden can reach MS Autopilot servers. Whether they have identified or not, they can fetch their provisioning information. Still, the traffic to Autopilot servers is logged. You might add an additional barrier with a specific SSID and WPA(n) PSK.

 If the device can be identified via the captive portal and a Company directory (e.g., Azure AD) that confirms an employee’s identity, Cloudi-Fi / Zscaler integration would bind the user into a specific profile where MS autopilot can be reached. Rebooting the device would not alter the connectivity as long as the device keeps the same IP address, which we can guarantee with our cloud DHCP server. No SSID must be dedicated to this scenario.