Intune integration

Arbiter calls Microsoft on your behalf in two places: it pulls device compliance from Microsoft Graph, and it validates SCEP challenges via the Intune SCEP validation API. Both calls use the same Azure AD application identity, so we only need to register it once.

In the Microsoft Entra admin centre go to Applications -> App registrations -> New registration.

• Name: Arbiter NAC (Intune sync + SCEP)
• Supported account types: Accounts in this organisational directory only
• Redirect URI: leave blank (this is a confidential client, not an interactive sign-in app)

Click Register. You will land on the app's Overview page. Copy these two values somewhere safe, you will paste them into Arbiter in step 3:

• Application (client) ID
• Directory (tenant) ID

On the app's left nav choose API permissions -> Add a permission. Add all three of the following as Application permissions (not Delegated):

Once all three are listed, click Grant admin consent for [your tenant] at the top of the permissions table. Every row should flip to a green tick under Status.

Still inside the app, choose Certificates & secrets -> Client secrets -> New client secret.

• Description: Arbiter NAC
• Expires: 24 months (or per your secret rotation policy)

Click Add. Copy the Value column immediately, before you navigate away. Microsoft only shows it once. If you lose it, create another secret, you cannot recover the original.

Now in Arbiter go to Settings -> MDM Integrations -> Intune. Tick Enable intune and fill in:

• Sync every: 60 minutes (the default is fine, anything from 5 to 1440 works)
• Azure AD tenant ID: the Directory (tenant) ID from step 1
• App client ID: the Application (client) ID from step 1
• App client secret: the secret Value you just copied

Click Test connection. A green "Connection OK: fetched N managed endpoints" banner means the MDM sync half is working. Click Save.

The first full sync runs in the background within a couple of minutes. The Sync log on the same page shows progress. From this point on you can already write auth policies that key on mdm_compliant or mdm_managed. The SCEP half needs the next few steps before it is usable.

Intune-managed devices need to trust the RADIUS server certificate that FreeRADIUS presents during EAP-TLS. That certificate is signed by your per-tenant Arbiter root, so we need a copy of the root in a format Intune will accept.

In the portal open Certificate Management (under Administration in the sidebar), find the Arbiter root certificate card and click Download root.pem. Rename the downloaded file from root.pem to root.cer. Intune accepts both PEM and DER encoding, it only cares that the extension is .cer or .crt, not .pem. Hang on to this file, you will upload it in the next step.

If you would rather verify the fingerprint end to end, or you are working from a headless box, pull the same root over SCEP with curl and OpenSSL:

curl -s 'https://scep.arbiter.ie/scep/<your-tenant-shortname>?operation=GetCACert' \
     -o arbiter-root.cer

openssl x509 -inform DER -in arbiter-root.cer -noout -subject -fingerprint -sha256

The subject should look like CN=<shortname>-root, O=Arbiter Tenant N, OU=Arbiter PKI. The SHA-256 fingerprint OpenSSL prints should match the one shown on the Arbiter root certificate card in the portal, confirming the root you are about to trust is the one your RADIUS server actually presents.

In the Intune admin centre go to Devices -> Configuration -> + Create -> + New policy:

• Platform: Windows 10 and later
• Profile type: Templates
• Choose Trusted certificate -> Create

Fill in:

On the Assignments tab, target a test group that contains your test device. All devices works for the initial rollout. Skip Applicability rules, review and create.

This is the profile that does the actual cert issuance. It tells every assigned device to generate a keypair locally, send a CSR to Arbiter, then install the signed certificate. Same Configuration page, + Create -> + New policy, Windows 10 and later, Templates, this time SCEP certificate.

Assign to the same test group as the Trusted Cert profile and create.

The third profile points devices at your SSID and tells them to authenticate with the certificate the SCEP profile just installed. Same wizard, Templates, this time Wi-Fi.

Assign to the same test group and create.

Only relevant if you have 802.1X switched ports for laptops. Same wizard, Templates, this time Wired networks. The fields mirror the Wi-Fi profile minus the SSID:

Fix it with a one-shot Platform Script. In Intune go to Devices -> Scripts and remediations -> Platform scripts -> + Add -> Windows. Save the following as enable-dot3svc.ps1 and upload it:

# Enable Wired AutoConfig (dot3svc) for Intune wired EAP-TLS profiles.
# Idempotent. Safe to run on every device.
try {
    $svc = Get-Service -Name dot3svc -ErrorAction Stop
    if ($svc.StartType -ne 'Automatic') {
        Set-Service -Name dot3svc -StartupType Automatic
    }
    if ($svc.Status -ne 'Running') {
        Start-Service -Name dot3svc
    }
    Write-Output "dot3svc OK"
    exit 0
} catch {
    Write-Error "Failed to configure dot3svc: $_"
    exit 1
}

• Run script using logged on credentials: No (the script needs SYSTEM context to change a service start type)
• Enforce script signature check: No
• Run script in 64-bit PowerShell host: Yes

Assign to the same group as the four profiles.

Pick one Intune-managed Windows device. In the Intune admin centre go to Devices -> All devices, click the device, then Sync at the top of its detail page. That tells the device to check in immediately instead of waiting for its next scheduled poll, which can be up to eight hours away.

You can also force the check-in from the device itself, which is handy whenever you change a profile and want it applied now rather than waiting on the portal Sync to propagate. In an elevated PowerShell:

# Force an immediate MDM check-in: pull policy changes now,
# instead of waiting for the scheduled poll (up to 8 hours away).
Get-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" -TaskName "Schedule to run OMADMClient by client","Schedule to run OMADMClient by server" |
  Start-ScheduledTask

# Confirm the check-in: want LastTaskResult 0 and a LastRunTime of just now.
Get-ScheduledTask -TaskPath "\Microsoft\Windows\EnterpriseMgmt\*" -TaskName "Schedule to run OMADMClient by client" |
  Get-ScheduledTaskInfo |
  Select-Object TaskName, LastRunTime, LastTaskResult

A LastTaskResult of 0 with a LastRunTime of just now means the device checked in. If two rows come back, a device that was enrolled before will carry an orphaned task that returns a non-zero error (2147942402 is "file not found"), the row returning 0 is the live enrolment.

Give it three to five minutes. Then on the device, open PowerShell and run the following, replacing <shortname> with your tenant shortname:

# On a freshly synced laptop, confirm the cert and provider.
$t = (Get-ChildItem Cert:\LocalMachine\My |
       Where-Object { $_.Issuer -match '<shortname>-root' }).Thumbprint
certutil -store My $t | findstr /C:"Provider"
# Expect: Provider = Microsoft Software Key Storage Provider

You should see a single certificate in Cert:\LocalMachine\My with an issuer matching your tenant root, and the Provider line should read Microsoft Software Key Storage Provider. If Provider says Microsoft Platform Crypto Provider instead, the SCEP profile is still set to TPM. Go back to step 6, change to Software KSP, delete the existing cert and trigger another sync.

The device should now auto-connect to the corporate SSID and, if plugged into an 802.1X port, auto-authenticate on wired too. In the Arbiter portal go to Auth Log and you should see a Permit with:

• Method: DOT1X
• EAP Type: TLS
• Common Name: the device's AAD Device ID (a GUID, matching {{AAD_Device_ID}} from the SCEP profile's Subject name format)
• Issuer: your tenant root