🌐 Trang này chưa được dịch sang tiếng Việt — đang hiển thị nội dung tiếng Anh.
Module 3 — Device Enrollment (Cloudflare One Client / WARP)
Goal: Install the Cloudflare One Client (the WARP app) on your devices so their traffic can be securely connected to Cloudflare, and so Cloudflare can check each device is healthy before granting access.
| 👤 Who does this | Endpoint / Desktop team |
| ⏱️ Time | ~60 minutes (pilot); MDM rollout varies |
| 🎯 You'll finish with | A pilot device showing Connected, listed in your dashboard, with a posture check passing |
| ✋ Before you begin | Module 2 done (IdP connected + tested), and one test laptop you control |
📖 Naming: The app is officially the Cloudflare One Client. You'll still see "WARP" in menus and the app itself — they're the same thing.
We'll go in this order: (A) decide who can enroll → (B) set how devices behave → (C) install on a pilot device → (D) distribute the certificate → (E) turn on health checks → (F) roll out at scale with MDM.
Part A — Decide who's allowed to enroll (do this first)
If you skip this, the app will refuse to connect with "you are not allowed to enroll."
- 👉 Zero Trust → Settings → WARP Client.
- 👉 Find Device enrollment permissions → click Manage.
- 👉 Click Add a rule.
- ⌨️ Fill in:
Field Value Rule name Company employeesRule action Allow Selector Emails ending in Value @yourcompany.com - 👉 Under login methods / identity providers, select the IdP you connected in Module 2.
- 👉 Click Save.
✅ Checkpoint: A rule appears that allows your company's email domain to enroll, using your IdP.
💡 Tip: For servers or large automated fleets, you can later create a Service Auth rule + service token so devices enroll silently with no login. For your pilot, the Allow rule above is all you need.
Part B — Set how devices behave (device profile)
-
👉 In Settings → WARP Client, scroll to Device settings (or Profile settings).
-
👉 Click the Default profile → Configure.
-
👉 Set these for managed company laptops:
Setting Set to Why Service mode Gateway with WARP Full protection (web + DNS filtering + private access) Switch Locked On Stops users turning the app off Auto connect 1minuteReconnects automatically after brief drops Captive portal detection On Lets users sign in to hotel/airport Wi-Fi -
👉 Click Save profile.
Split Tunnel (what traffic goes through Cloudflare)
- 👉 Still in the profile, find Split Tunnels → click Manage.
- Choose your mode:
- Company-owned laptops → leave it on Exclude mode (the default). Everything goes through Cloudflare except a small built-in exclusion list.
- Personal / BYOD devices → switch to Include mode and list only your company apps/networks, so employees' personal traffic stays private.
⚠️ Watch out: Don't run personal devices in full Exclude mode — it routes the user's personal browsing through your company, which raises privacy concerns. Use Include mode for BYOD.
✅ Checkpoint: Your Default profile shows Gateway with WARP and a split-tunnel mode appropriate for your device type.
💡 Need different settings for different devices (BYOD vs. managed vs. servers vs. contractors)? That's what device profiles are for. The full walkthrough — client modes, match rules/selectors, order of precedence, per-profile split tunnels, and local domain fallback — is in the companion page: Module 3b — Device Profiles Configuration.
Part C — Install on your pilot device (manual)
We'll install on one laptop first and confirm it works before any mass deployment.
Step C1 — Download the client
- 👉 On the test laptop, open
https://one.one.one.one/and choose your platform, or download directly:- Windows: download the Cloudflare WARP installer (
.msi/.exe) - macOS: download the Cloudflare WARP installer (
.pkg) - Linux / iOS / Android: follow the platform instructions on the download page
- Windows: download the Cloudflare WARP installer (
Step C2 — Install it
- 👉 Run the installer and accept the prompts (on macOS you'll Allow a system extension and VPN configuration; on Windows, accept the UAC prompt).
- 📺 What you'll see: A small Cloudflare logo appears in your menu bar (macOS) or system tray (Windows).
Step C3 — Connect it to your organization (not consumer mode)
This is the step that links the app to your Zero Trust org.
- 👉 Click the Cloudflare WARP icon → the gear/cog ⚙️ icon → Preferences → Account.
- 👉 Click Login with Cloudflare Zero Trust.
- ⌨️ When prompted for your team name, enter just the name part (e.g.
acme, not the full URL). - 👉 Click Continue.
- 📺 Your browser opens your company login (the IdP from Module 2). Sign in.
- ✅ You'll see a "You have successfully authenticated" page. Return to the app.
- 👉 Make sure the app's main toggle is switched On / Connected.
✅ Checkpoint — confirm it's really protected:
- 👉 Click the WARP icon — it should say Connected.
- 👉 In a browser on that laptop, visit
https://www.cloudflare.com/cdn-cgi/trace/ - 📺 In the text shown, look for:
warp=ongateway=on
- 👉 Now check the dashboard: Zero Trust → My Team → Devices. Your test device appears in the list. 🎉
⚠️ If it says "not allowed to enroll": revisit Part A — your email domain isn't covered by an enrollment rule, or the wrong IdP is selected.
Part D — Distribute the Cloudflare certificate
This is required before you turn on HTTPS inspection, DLP, or AI prompt scanning in later modules. Without it, secure websites will show certificate errors.
- 👉 Zero Trust → Settings → Resources (older menus: Settings → Devices → Certificate).
- 👉 Find the Cloudflare certificate and Download it.
- Install it into the device's trusted certificate store:
- Pilot (manual): double-click the certificate and add it to the system/keychain "Trusted Root" store.
- At scale: push it through your MDM (covered in Part F).
✅ Checkpoint: The Cloudflare certificate is installed and trusted on your pilot device.
⚠️ Watch out: Do not enable TLS/HTTPS decryption (Module 5) until this certificate is on the device, or HTTPS websites will break.
Part E — Turn on a device health check (posture)
Let's add one simple check so you can require healthy devices in later modules.
- 👉 Zero Trust → Settings → WARP Client → Device posture (or Reusable components → Posture checks).
- 👉 Click Add → choose a simple client check, e.g. Disk encryption.
- ⌨️ Name it
Disk encrypted, choose the platform(s), and save.
📺 What you'll see: The new posture check listed, evaluating your enrolled devices.
✅ Checkpoint: Your pilot device reports compliant for the disk-encryption check (assuming its disk is encrypted).
💡 Tip: For OS-version checks, require the latest version you've already tested, not the absolute newest — otherwise a brand-new OS release could lock everyone out the day it ships. If you use CrowdStrike, SentinelOne, or Intune, you can add those as posture sources here too (Enterprise). Note: Tanium posture works for Access but not Gateway.
🛡️ Posture is a big topic. For the full toolkit — every built-in check, third-party EDR/MDM integrations, using posture in Access & Gateway policies, and continuous re-evaluation — see Module 3c — Device Posture Checks.
Part F — Roll out to everyone (MDM)
Once your pilot device works, deploy to the fleet silently using your MDM (Intune, Jamf, Kandji, Workspace ONE, SCCM…). You push the same app plus a small config so it self-enrolls with no user steps.
Key settings to push
| Setting | Value | Purpose |
|---|---|---|
organization |
your team name | Links the app to your org (required) |
service_mode |
warp |
Gateway with WARP |
onboarding |
false |
Hides the welcome screens (silent) |
auto_connect |
1 |
Connects immediately |
switch_locked |
true |
Users can't disable it |
support_url |
your IT help link | Shown in the app |
For fully silent enrollment (no login prompt), also push a service token:
- 👉 Create a Service Auth enrollment rule (Part A → action Service Auth).
- 👉 Zero Trust → Access → Service Auth → Service Tokens → Create → copy the Client ID and Client Secret.
- Push them as
auth_client_idandauth_client_secretin your MDM config.
⚠️ Watch out: Local MDM settings override dashboard settings. And service tokens require a Service Auth enrollment rule — a plain Allow rule won't work for token enrollment.
Example macOS configuration profile (com.cloudflare.warp):
<dict>
<key>organization</key> <string>acme</string>
<key>service_mode</key> <string>warp</string>
<key>onboarding</key> <false/>
<key>auto_connect</key> <integer>1</integer>
<key>switch_locked</key> <true/>
<key>support_url</key> <string>https://help.acme.com</string>
</dict>
Push the Cloudflare certificate (Part D) through the same MDM profile.
✅ Checkpoint: A second device, enrolled via MDM, appears under My Team → Devices as Connected with no manual login.
✅ Module 3 complete!
You now have:
- ✅ An enrollment rule controlling who can join
- ✅ A device profile (Gateway with WARP + split tunnel)
- ✅ A pilot device Connected and listed in the dashboard
- ✅ The Cloudflare certificate distributed
- ✅ A working device posture check
- ✅ An MDM rollout plan for the rest of the fleet
Quick troubleshooting
| Problem | Fix |
|---|---|
| "You are not allowed to enroll" | Add/repair the enrollment rule (Part A); confirm the email domain + IdP |
| App stuck "Connecting" | Check the device can reach the internet; try toggling off/on; check a firewall isn't blocking WARP |
gateway=on not showing in the trace |
Service mode isn't Gateway with WARP, or a DNS-only mode is set — fix the profile (Part B) |
| HTTPS sites show certificate warnings | The Cloudflare certificate isn't trusted yet — install it (Part D) before any HTTPS inspection |
| Personal device routes personal traffic | Switch that profile to Include split-tunnel mode (Part B) |
👉 Next: Module 4 — ZTNA / Access
You'll publish your first private application and replace VPN access to it.