Category filter
IdP-to-Local Account Provisioning: Automating the Cloud-to-Desktop Lifecycle
In modern enterprise environments, the greatest security gap often exists at the very first touchpoint: the device login screen. Traditional local accounts are difficult to manage, hard to audit, and prone to password fatigue.
Hexnode Access or IdP-to-Local Account Provisioning resolves this by replacing the native OS login experience with a cloud-connected, identity-first framework. This guide details how to implement Zero Trust login, manage Just-In-Time (JIT) privileges, and secure your fleet using real-time enforcement.
1. Cloud Identity at the Desktop Level
Hexnode Access moves beyond simple password management by bridging your cloud Identity Provider (IdP) directly to the local operating system (Windows & macOS).
How “On-the-Fly” Provisioning Works
Instead of manually creating local user accounts for every employee, Hexnode Access automates the process:
- The Branded Interface: When the device boots, the user sees a login window customized with your corporate branding, completely replacing the default OS screen.
- IdP Authentication: The user enters their corporate credentials (e.g., Google Workspace, Okta, or Entra ID).
- Local Account Creation: Hexnode verifies the token via OIDC or SAML 2.0. If the user is valid, Hexnode automatically creates a local standard user account mapped to that cloud identity.
Multi-Factor Authentication (MFA) Enforcement
Security policies often fail because they are only enforced at the application level (e.g., logging into email). Hexnode Access shifts this perimeter to the device level.
- Offline Capability: For mobile workforces (e.g., users on airplanes), Hexnode utilizes a secure enclave to cache tokens. This allows users to log in without an internet connection for a specific “Expiration Window” defined by your security policy.
2. The Privilege Elevation Framework (JIT)
The standard security practice is to remove local Administrator rights from all users. However, this often hinders productivity for developers and power users who need to install drivers or modify network configurations.
Hexnode Access solves this with Just-In-Time (JIT) Elevation.
The “Standard User” Default
By default, every user on your 500,000-device fleet logs in as a Standard User. They cannot make system-level changes that could introduce malware or vulnerabilities.
The Elevation Workflow
When a valid business need arises, the user can request temporary Admin rights. This process is governed by two modes:
A. Automated Approval (Rule-Based)
Configure the Hexnode’s Self Service policy beforehand. Best for trusted roles (e.g., Developers) or specific tasks.
- Scenario: A developer needs to install a specific IDE.
- Action: If the user falls into a pre-approved “Safe Role” or the application is on the “Allow List,” elevation is granted instantly without IT intervention as soon as the user requests it from the Hexnode UEM agent.
B. Technician Approval (Ticket-Based)
Configure the Hexnode’s Self Service policy for a given user only if there is an internal ticket raised. Best for general staff or high-risk requests.
- Scenario: A sales rep request to change system DNS settings.
- Action: The request is routed to your technician team. They review the justification and grant one-time approval for privilege escalation.
More information about the Self Service policy:
Automatic Revocation
Crucially, admin access is never permanent.
3. Real-Time Security: The MQTT Architecture
Legacy management tools rely on “polling” (checking in every few hours) to apply updates. Hexnode Access uses MQTT (Message Queuing Telemetry Transport) to maintain a persistent, real-time connection.
The “Kill Signal” Protocol
This architecture is vital for offboarding and threat response.
- Trigger: An employee is terminated, or a device is reported stolen, and the account is disabled in your IdP (e.g., Microsoft Entra ID).
- Action: Hexnode sends an immediate command via the MQTT channel.
- Result: The device locks instantly. The active user session is terminated, and the login window is reset to block any further access attempts.
4. Configuring Multi-Tenant Environments
For large enterprises with subsidiaries, Hexnode Access supports complex hierarchy mapping. This ensures that while the central IT team manages the infrastructure, the user experience remains localized.
| Configuration | Description |
|---|---|
| Visual Separation | Sub-Company A and Sub-Company B can have distinct login backgrounds, logos, and EULAs. |
| Identity Routing | Hexnode intelligently routes authentication requests. A user entering @compA.com is sent to Okta, while @compB.com is directed to Google Workspace. |
| Regional Compliance | You can enforce stricter JIT rules for regions with higher compliance needs (e.g., EMEA) while allowing more flexibility for R&D centers in the US. |
5. Deployment Guide: Getting Started
To begin rolling out Hexnode Access, follow this recommended sequence:
Phase 1: Identity Integration
Navigate to the Admin > Integrations tab.
- Select your provider (Entra ID, Okta, Ping, etc.).
- Configure the OIDC/SAML handshake keys.
Phase 2: Setting Up Access
Navigate to Policies > Windows or macOS > Hexnode Access.
- Define the account settings and login settings.
- Upload high-resolution assets for your login background and logo.
- Add your support team’s phone number or email to the login screen footer, so locked-out users know who to contact.
Phase 3: Privilege Policy
Navigate to Policies > New Policy > Windows/macOS > Configurations > Self Service.
- Approvers: Assign specific technician groups to handle manual elevation requests to prevent bottlenecks.
