Setup Guide for Nile Cloud RADIUS

1\ introduction 1\ introduction 1 1 purpose of this guide this guide provides step by step instructions for deploying the nile radius service to enable secure 802 1x authentication on wired and wireless networks using eap tls this guide covers uploading the server certificate (pkcs#12) and trusted ca certificates into the nile portal creating nile radius policies (segment assignment, palo alto tags, accept/reject) configuring windows, macos, ios, and android supplicants for eap tls please note that eap peap (mschapv2) is on the roadmap of nile cloud radius and is not covered in this guide 1 2 key terminology term definition supplicant endpoint (laptop, phone, iot device) running an 802 1x eap client authenticator / nas nile aps and switches in the nile service block (nsb) the headend (he) relays eap frames as radius to the cloud authentication server nile radius — the cloud service that performs eap authentication and returns authorization attributes eap extensible authentication protocol, used over 802 1x eap tls certificate based eap method providing mutual tls between supplicant and radius server only the eap method is supported by nile radius today segment nile's layer 3 construct that replaces vlans a segment maps to a subnet and a dhcp pool nile radius policy authorization rule inside the nile radius service matches on ssid, scim group, intune compliance, certificate attributes, etc , and returns accept (with segment assignment and/or palo alto tag) or reject scim standard used to sync user identities and group membership from idps (entra id, okta) into nile in real time intune compliance device compliance state pulled from microsoft intune and usable as a match condition in nile radius policies 1 3 prerequisites before enabling nile radius, ensure the following are in place nile access service deployed sites are onboarded, segments are defined, and each segment is mapped to a dhcp pool cloud radius feature enabled on the tenant engage your nile csm/se to enable the cloud radius service on your tenant before you start configuration identity provider integrated saml/oidc idp (entra id, okta, authentik) integrated for user sso, with scim provisioning enabled if you plan to use idp groups in radius policies pki ready for eap tls nile radius expects a server certificate plus its matching private key for the radius server, with the following properties key type rsa, 2048 / 3072 / 4096 bits (wpa3 enterprise mandates ≥ 3072) ecdsa keys are not supported today keyusage digitalsignature and keyencipherment extendedkeyusage (eku) serverauth (tls web server authentication) subject alternative name (san) optional but recommended whatever dns name your supplicants are configured to trust as the radius server name must be present in the san the server certificate, its matching private key, and the issuing ca chain (root + any intermediates) packaged into a single pkcs#12 ( p12 / pfx ) bundle , password protected the ca chain that issued your client certificates as one or more pem files if client certificates chain to the same ca as the server cert, the chain in the pkcs#12 is sufficient; if they chain to a different ca, upload that ca separately as a pem into the trust certificates section nile does not operate a ca and does not generate csrs use your existing pki (ad cs, sectigo, entra certificate service, scepman, etc ) to issue both the radius server certificate and the client certificates, then upload the final artifacts into nile optional — microsoft intune integration required only if you intend to use intune device compliance state as a match condition in nile radius policies review technical documentation read the nile radius documentation https //docs nilesecure com/nile radius to understand key concepts 2\ getting ready identity, certificates, and integrations 2 1 identity providers and scim integrate nile with your idp so the user and group context is available to nile radius for policy evaluation identity sync via scim — automatically sync user identities and group membership from entra id, okta, or any scim capable idp into nile group based policy assignment — reference idp groups (for example, employees, contractors, sales) directly in nile radius policies to drive segment assignment, palo alto tag assignment, or accept/reject decisions real time access revocation — when a user is disabled or removed from a group in the idp, the scim event reaches nile within seconds, and the next authentication attempt is denied existing sessions are terminated via change of authorization (coa) for step by step idp and scim integration instructions, refer to the relevant integration guide on nile docs https //docs nilesecure com/ 2 2 certificate authority and pki (for eap tls) for eap tls, the customer is responsible for the full certificate lifecycle this includes operating (or leveraging) a ca/pki, issuing the nile radius server certificate, and issuing and distributing client certificates to devices — typically via an mdm such as microsoft intune nile does not issue or renew certificates nile only generates expiry alerts at 90, 60, 30, and 10 days before the server cert expires server certificate preparation generate the radius server certificate using one of the following approaches option a — external csr generate a csr on a workstation (openssl, xca) with the required subject, sans, keyusage (digitalsignature, keyencipherment) and eku (serverauth), submit it to your ca, then combine the signed certificate, private key, and ca chain into a single pkcs#12 bundle option b — issue directly from your ca issue the certificate directly from your ca (for example, an ad cs template configured for "server authentication") and export it together with the private key as pkcs#12 either way, the artifact you upload to nile is a single password protected p12 / pfx bundle containing the server certificate it's matching the private key the signing ca chain (root and any intermediates) ca chain for client certificate validation if your client certificates are issued by a different ca than the one that signed the nile radius server certificate, export the root and any intermediates of the client issuing ca and upload them separately as pem into the trust certificates section of nile radius each pem file can contain one ca cert or multiple ca certs as concatenated pem blocks; nile internally chains them in the correct order regardless of upload order multiple client issuing cas are supported — for example, iot devices issued by one ca and laptops/phones issued by another upload each ca's chain, and nile radius will validate any client cert that terminates at one of the uploaded trust anchors client requirements each client device must trust the ca chain (root and intermediates) that signed the nile radius server certificate — install the chain in the device's trust store so the supplicant validates the radius server during the eap tls handshake present a valid client certificate whose chain terminates at one of the cas uploaded to nile radius, with clientauth eku and the identity (typically cn=\<user or device> and/or san email / upn) you plan to match in your policies 2 3 intune integration (optional) to enforce radius authentication decisions based on device compliance — such as restricting corporate ssid access to intune managed or compliant devices only — integrate intune with nile radius by following the steps outlined in the intune integration guide https //docs nilesecure com/nile cloud radius integration with intune 3\ configure the nile radius service this section configures nile radius itself and wires it into your segments, ssids, and policies 3 1 upload the server keystore and trust certificates navigate to the nile radius configuration in the nile portal, go to network setup → authentication → nile radius select the authentication type under auth type , choose eap tls (the only production option today) upload the server keystore (pkcs#12) in the server certificate section, click upload and select your p12 / pfx bundle enter the password that protects the bundle the password may contain letters and digits; some special characters in copy/paste have been observed to fail validation, so re type the password if the first upload returns a "wrong password" error on success, nile parses the bundle and displays the server certificate subject, san list, issuer, and expiration date upload trusted client cas (trust certificates) in the trust certificates section, upload one pem file per client issuing ca (or a single pem containing multiple concatenated ca blocks) repeat for each independent client ca chain this step is required unless your client certificates are issued by the same ca that signed your server certificate (in which case the chain is already present from step 3) (optional) enable demo mode for evaluation only toggle demo mode to have nile auto generate one radius server certificate three client certificates with the fixed identities sales, marketing, and hr (different cn/email so different policies can be matched) the certificates are valid for 7 days and can be regenerated at any time demo mode and production certificates are mutually exclusive — only one mode is active per tenant demo client certs are exported as p12 bundles with no password (you do not set a password on the portal) demo mode is for poc and lab validation only; production deployments must use your own pki wired 802 1x knob (migration scenarios only) if you are co existing with a legacy nac (ise / clearpass) on wired ports, enable the wired dot1x checkbox to have nile radius take over wired 802 1x leave it unchecked to keep wired authentication on your legacy radius while you cut over wireless first wireless authentication always follows the per segment radius server configuration save click save nile radius is now ready to accept eap tls authentications once segments and ssids are pointed at it 3 2 wire radius into segments and ssids nile radius works alongside segments and ssids there is no hard requirement to map an ssid to multiple segments or to slice users across multiple scim groups — a single segment ssid with a single user group is a perfectly valid (and common) starting point use multiple segments or multiple groups only when you actually need differentiated access via radius coa create or verify segments in the nile portal, go to network setup → segments and confirm that the segments you need exist a typical greenfield deployment might start with just one or two a single corporate segment (for example, corp), or a small set such as employee prod, contractor, iot, guest if you already know you want differentiated access each segment must have dhcp configuration (subnet, pool, lease, dns) optional mapping to downstream security constructs such as firewall zones segments replace vlans — each segment is an l3 subnet, and a device's segment assignment determines its ip, default gateway, and which trust engine policies apply point segments at nile radius in each segment that requires 802 1x, set the authentication server to nile radius (segments that should continue to use an external radius — ise / clearpass — keep their existing setting for hybrid migration ) wireless ssids that use these segments will use nile radius automatically once the ssid security type is enterprise (see below) wired 802 1x on nile switches follows the wired dot1x knob in section 3 1 configure ssids and wired access wireless ssids go to network setup → wireless and create or edit your corporate ssid (for example, corp dot1x) set security to wpa2 enterprise (or wpa3 enterprise where supported by your client fleet; wpa3 enterprise requires ≥ 3072 bit rsa on the server cert) map the ssid to at least one segment the segment(s) mapped to an ssid determine the default landing zone for any device that gets an access accept from nile radius single segment ssid — every accepted device lands in that segment no segment assignment is needed in the radius policy; scim groups can still be used as match criteria for accept/reject decisions or palo alto tagging without changing the segment multi segment ssid — devices land in the default segment configured on the ssid unless a nile radius policy explicitly overrides the segment as part of its accept action this is how you steer different scim groups, intune compliance states, or certificate attributes into different segments behind a single ssid wired 802 1x wired 802 1x follows the wired dot1x knob set in section 3 1 — no per ssid configuration is needed each wired port (or port profile) is mapped to a segment that acts as the default for accepted devices a radius policy can override the segment when multiple segments are eligible, exactly as with wireless 3 3 policy groups vs radius policies — understand the distinction this is the most common point of confusion when first configuring nile radius nile has two distinct policy frameworks that operate at different points in the flow framework where it runs what it decides typical match criteria typical actions nile radius policies inside the nile radius service, during the eap tls authentication whether the device is allowed onto the network and which segment / tag it lands in ssid, scim/idp group, intune compliance state, certificate cn/ou/san, mac, "active user" flag accept + segment assignment, accept + palo alto tag, reject nile trust engine policies inside the nile service block, on every packet after the device is on the network whether traffic between two endpoints (east west) or to/from the outside (north south) is allowed, denied, or forwarded to an upstream firewall policy group membership (user / device / app), source, destination, service profile allow, deny, forward to firewall / sse you configure both, but they live in different places in the portal nile radius policies live under network setup → authentication → nile radius → policies trust engine constructs live under security → trust engine for the rest of this guide section 3 4 covers nile radius policies — required for any radius deployment section 3 5 explains how radius assigned segments feed into trust engine policy groups, and points you to the full trust service setup workflow 3 4 create nile radius policies navigate to network setup → authentication → nile radius → policies and create one policy per authorization outcome you need policies are evaluated top down at authentication time; place more specific policies first each policy has name and description match expression — combine one or more of ssid == "\<name>", scim group == "\<group>" or scim group in ( ), active == true, intune compliancestatus == "compliant", certificate cn == "\<value>" or certificate cn contains "\<substring>", certificate ou == "\<value>", calling station id == "\<mac>" conditions can be combined with && / || action — accept (with optional segment assignment, optional palo alto tag) or reject example policies for the use cases in the nile radius docs example a — employees vs contractors on the same corporate ssid policy 1 corp employees match ssid == "corporate" && intune compliancestatus == "compliant" && scim group == "employees" && active == true action accept, segment = employee prod policy 2 corp contractors match ssid == "corporate" && intune compliancestatus == "compliant" && scim group == "contractors" && active == true action accept, segment = contractor policy 3 corp default reject match ssid == "corporate" action reject example b — disabled users are denied immediately because scim updates are pushed in near real time, a single policy that requires active == true is enough — as soon as the user is disabled in the idp, the next authentication fails policy employees only active match scim group == "employees" && active == true action accept example c — iot device segmentation by certificate cn policy cameras match certificate cn contains "camera" action accept, segment = camera policy printers match certificate cn contains "printer" action accept, segment = printer example d — palo alto tag assignment for upstream firewall enforcement policy sales pan tag match scim group == "sales" && active == true action accept, tag = ent sales the tag is delivered to the palo alto firewall via the xml api, so existing firewall policies that key on user id tags work without modification radius derived user/device identity (the certificate cn, scim group, intune state) is available in the nile radius transaction record and on the device's detail page in the portal — useful for validating that a given device matched the policy you expected 3 5 trust engine policy groups for radius authenticated endpoints (optional but recommended) after nile radius authorizes a device and assigns it to a segment, the nile trust engine governs what that device can talk to — both east west inside the nile service block and north south toward the internet, data center, or upstream firewall trust engine policies are an entirely separate workflow from radius policies and live under security → trust engine for most radius driven deployments you will want to create user policy groups matched on the same scim/idp groups you use in radius (for example, employees, contractors, admins) — note that radius derived identity as a direct match criterion is on the roadmap; today the cleanest pattern is to align the segment that radius assigns with a segment based or idp group based policy group device policy groups matched on fingerprint or segment (for example, printers, cameras) for iot devices radius placed into iot segments service profiles defining the protocols and ports each group is allowed to use (for example, "printing" = tcp/9100 only, "internet" = https only) policy sets binding source group → service profile → destination group with an action (allow / deny / forward to firewall) trust engine setup is its own end to end workflow that goes beyond the scope of a radius guide for the full step by step — creating policy groups, service profiles, policy sets, working with the matrix view, and reading policy logs — follow the setup guide for nile trust service 4\ endpoint configuration — eap tls this section covers typical supplicant configuration cross check with os specific docs for ui changes between releases the recommended path for any fleet larger than a few devices is to push the wi fi / wired profile and the client certificate together via mdm 4 1 windows — wireless 802 1x (eap tls) assuming the client certificate is deployed via intune (or gpo / ad cs auto enrollment) confirm the target ssid is configured as wpa2 enterprise (or wpa3 enterprise) in nile on windows ensure the wlan autoconfig service is running add or edit the wireless profile network name match the ssid configured in nile security type wpa2 enterprise eap method microsoft smart card or other certificate (this is windows' name for eap tls) in the eap tls settings, select use a certificate on this computer and ensure the correct client certificate is available (issued by your ca, with clientauth eku) enable verify the server's identity by validating the certificate and select the root/intermediate ca(s) that signed your nile radius server certificate optionally tick connect to these servers and list the san(s) on the nile radius server certificate connect and verify in the nile portal that the device appears under devices with auth method eap tls the nile radius transaction log shows a successful eap tls handshake and the expected policy match 4 2 windows — wired 802 1x (eap tls) wired 802 1x uses the same eap tls method as wireless in the current release eap peap support for wired ad credential authentication is on the roadmap confirm the target switch port is configured for 802 1x in nile (covered by the wired dot1x knob in section 3 1) on windows open network connections , right click the ethernet adapter, and choose properties if the authentication tab is missing, start the wired autoconfig service (services msc) and re open the adapter properties on the authentication tab enable ieee 802 1x authentication set the network authentication method to microsoft smart card or other certificate (eap tls) in settings , select the correct client certificate and configure server validation against the ca that signed your nile radius server certificate in additional settings , choose user authentication (or user or computer authentication depending on your cert template) connect the cable and verify the device shows up under devices in the nile portal with a successful eap tls transaction 4 3 macos, ios, android nile radius terminates eap tls using a standard supplicant flow, so any modern supplicant works general guidance import the client certificate and private key into the system keychain ( p12 import on macos / ios; pfx on android) configure the 802 1x profile to use eap tls and select the imported identity enable server certificate validation against the nile radius server's ca chain for fleets, push the wi fi profile and the certificate together via mdm (intune, jamf, workspace one) — manual configuration does not scale and is error prone 5\ validation and troubleshooting 5 1 verify 802 1x activity in nile in the nile portal, go to devices filter by mac address or username to see authentication method (eap tls) segment assignment (matches the policy that fired) recent events and timestamps for the full radius transaction (eap method, certificate cn, matched policy, policy expression, returned attributes), open the device detail page and switch to the radius tab, or use infrastructure → nile radius → monitoring for a service wide view 5 2 common issues and checks no device entry in nile for the mac address the supplicant is not sending 802 1x at all check supplicant services (wlan autoconfig / wired autoconfig), the wireless/wired profile configuration, and that the ssid or port is 802 1x enabled in nile wired device falls into mab (mac auth) flow this means 802 1x did not start or timed out, so the switch fell back to mab the device appears in the mab pending list — fix the supplicant configuration and retry upload error "server certificate should have key encipherment enabled " the server certificate was issued without keyencipherment in keyusage reissue the certificate with both digitalsignature and keyencipherment (and eku serverauth), rebuild the pkcs#12, and re upload upload error "wrong password " re type the pkcs#12 password rather than copy pasting (some non ascii or whitespace characters break in the upload field) verify the password independently with openssl pkcs12 in \<file> p12 info or certutil p \<password> dump \<file> pfx upload error "this certificate already exists " the same server cert + ca chain has already been uploaded for this tenant (nile deduplicates by sha 256) delete the old keystore before re uploading, or skip the upload could not verify client certificate the client cert chains to a ca that is not in the trust certificates section upload the client issuing ca (root + any intermediates) as pem under trust certificates and retry nak \[25] or nak \[25 21] in logs the supplicant is proposing peap (25) or peap/ttls (25, 21) instead of eap tls (13) re check the supplicant profile and switch the eap method to eap tls failed to verify certificate x509 certificate has expired or is not yet valid the client (or server) certificate has expired or has a notbefore in the future reissue or correct the system clock server certificate validation fails on the client side the supplicant does not trust the ca that issued the nile radius server cert install the ca root (and intermediates) into the device's trust store, and — if you ticked "connect to these servers" — make sure the configured server name matches a san on the nile radius server certificate 5 3 radius alerts nile automatically generates tenant level radius failure alerts when the percentage of clients seeing failures in a rolling 15 minute window crosses defined thresholds 5–10% failure rate low severity alert 10–25% failure rate medium severity alert 25–100% failure rate high severity alert server certificate expiration alerts are raised 90, 60, 30, and 10 days before the cert expires plan renewal accordingly — nile does not renew the cert for you clicking an alert takes you directly to the devices page filtered to the affected clients, simplifying bulk troubleshooting alerts auto close once the failure rate drops below 5% 6\ day 2 operations and monitoring 6 1 continuous monitoring nile radius is probed every minute from every site for availability and round trip latency backed by cloud scale ha and auto scaling infrastructure; failover is automatic and transparent to the nsb use infrastructure → nile radius → monitoring for service health, transaction rates, and latency device detail → radius for per session troubleshooting security → trust engine → policy logs to confirm which trust engine policy is being applied to traffic from a radius authenticated device once it is on the network 6 2 what happens when the internet goes down existing authenticated sessions remain active devices continue roaming seamlessly thanks to locally cached pmk new authentications and re authentications fail until cloud connectivity is restored — plan supplicant session and reauth timers accordingly for sites with unreliable wan 6 3 policy and certificate changes when changing scim mappings, intune integration, certificate cn based policies, or rolling out a new radius server certificate stage changes on a single test segment or a subset of users / devices first use the radius transaction logs to confirm the expected policy fires and the expected segment/tag is assigned for new server certs, upload the new pkcs#12 alongside the existing one (where supported) or schedule the switch during a maintenance window — every active eap tls session will need to reauthenticate against the new server cert chain for new client issuing cas, upload the new ca's chain to the trust certificates section before any client begins presenting certs signed by it 1 1 purpose of this guide this guide provides step by step instructions for deploying the nile radius service to enable secure 802 1x authentication on wired and wireless networks using eap tls this guide covers configuring nile radius for certificate based eap tls authentication uploading the required certificates — radius server certificate, root ca, and optionally the client root ca (when the client and radius server chain to different roots) validating, monitoring, and troubleshooting radius authentication end to end 1 2 key terminology use this section as a quick reference while reading the rest of the guide supplicant – endpoint (e g , laptop, phone, iot device) running an 802 1x eap client authenticator / nas – nile aps and switches (via the nile service block / he) that relay eap to radius radius server – nile radius cloud service performing authentication and returning authorization attributes eap – extensible authentication protocol, used over 802 1x eap‑tls – certificate‑based eap method providing mutual tls between client and radius server; primary method in nile radius segment – nile’s l3 construct replacing vlans; segments map to subnets and define where endpoints land in the network policy group – logical grouping (user, device, app, system) used by trust service to make access decisions service profile – l4 service definition (protocol/ports), defining which traffic is allowed once a policy is “allow” or “forward” policy set – an ordered collection of policies mapping source groups to destination groups with a service profile and action (allow/deny/forward) scim – standard used to sync identities and groups from idps (azure ad/entra id, okta) into nile intune compliance – device compliance state retrieved from microsoft intune and usable in radius policies 1 3 prerequisites before enabling nile radius, ensure the following nile access service deployed sites onboarded, segments defined, and segments mapped to dhcp pools identity provider saml/oidc idp (azure ad, okta) integrated for user sso and scim group sync if needed pki and certificates for eap‑tls nile radius expects a server certificate and corresponding private key for the radius server key properties on that cert keyusage digitalsignature, keyencipherment extendedkeyusage (eku) serverauth sans as required by the customer (optional, but if they want them, they must be in the csr) the cert + private key is packaged into a pkcs#12 ( pfx / p12) file, password protected the issuing ca chain (root + intermediates) is uploaded separately into the nile radius trust certificates section, as pem blocks nile does not operate a ca or handle csr generation customers continue to use their own ca/pki (sectigo, ad cs, intune, etc ), then upload the final artifacts into nile optional microsoft intune integration required if intune compliance state will be part of radius policies review technical documentation read the nile radius documentation https //docs nilesecure com/nile radius to understand key concepts 2\ getting ready identity, certificates, and integrations 3 1 identity providers and scim integrate nile with your idp to sync user and group data into the platform identity sync via scim — automatically sync user identities and group membership from azure ad or okta into nile group based policy assignment — reference idp groups (e g , "employees", "contractors") directly in nile policies for segment assignment and tagging real time access revocation — when a user is disabled in the idp, scim events instantly terminate active sessions and revoke network access for step by step integration instructions, refer to the relevant guide on nile docs 3 2 certificate authority and pki (for eap‑tls) for eap tls authentication, the customer is responsible for managing the full certificate lifecycle this includes operating or leveraging an existing ca/pki infrastructure and issuing client certificates to devices — typically via an mdm such as microsoft intune or equivalent note nile does not manage certificate issuance or renewal server certificate preparation obtain a signed server certificate for the nile radius server using one of the following methods option a generate a csr externally and submit it to your ca for signing option b issue the server certificate directly from your existing ca once signed, export the certificate in one of the following formats a p12 / pfx bundle containing the signed server certificate, its encrypted private key, and the complete ca chain that signed it separately as the server certificate and root/intermediate ca certificates ca chain for client certificate validation if the client certificates are issued by a different ca than the one that signed the nile radius server certificate, export the separate ca chain (root and any intermediates) that issues client certificates this allows nile radius to validate client identity during authentication client requirements each client device must trust the ca chain (root and intermediates) that signed the nile radius server certificate present a valid client certificate whose chain terminates at one of the uploaded trusted cas 3 3 intune integration (if applicable) to enforce radius authentication decisions based on device compliance — such as restricting corporate ssid access to intune managed or compliant devices only — integrate intune with nile radius by following the steps outlined in the intune integration guide https //docs nilesecure com/nile cloud radius integration with intune 4\ step 1 – configure nile radius service this step configures nile radius itself and wires it into your network context 4 1 enable nile radius for eap‑tls navigate to the nile radius configuration in portal, go to network setup → authentication → nile radius select authentication method under auth type, choose eap‑tls (if not already selected) upload certificates fill in the following fields server certificate – upload the x 509 certificate that nile radius will present to clients private key – upload the private key corresponding to the server certificate ca certificate (optional but recommended) – upload the root and intermediate ca certificates used to issue client certificates so that nile can validate client cert chains optionally use demo mode for evaluation use this only for pocs and lab validation; production deployments must use your own pki toggle demo mode to have nile automatically generate one radius server certificate three client certificates (each with unique email identifiers), downloadable for testing demo certificates are valid for 7 days , and you can regenerate them as needed only one mode (demo vs production certificates) can be active at a time please note that password encription is not supported for demo mode client certs save configuration click save nile radius is now ready to accept eap‑tls authentications once wired into segments and ssids 4 2 enable nile radius for eap‑peap with ad integration this section assumes you want to support username/password authentication against ad/ldap using eap‑peap/mschapv2 prepare ad / ldap ensure ad/ldap is reachable from nile radius, and you have ldap uri (e g , ldaps\ //dc1 example com) bind account (username + password) base dn (e g , dc=example,dc=com) configure ad servers in nile define ad server objects in nile (per existing ad integration workflow) and validate connectivity for each site configure eap‑peap in the nile radius in nile control center, navigate to network setup → authentication → nile radius under auth type , select eap‑peap in the select ad servers section choose one or more ad servers to associate with this configuration selected servers appear as tags in the field under the hood, configuration includes ldap uri ldap credentials (username/password) ldap dn for user lookup understand security properties nile supports eap‑peap mschapv2 and integrates with your existing ad infrastructure nile radius does not store passwords ; it proxies authentication to ad save configuration click save ad‑backed eap‑peap is now enabled for 802 1x authentication 4 3 site‑aware ad routing (optional) if you operate per‑site ad servers , enable site‑aware ad when this option is enabled, nile radius routes eap‑peap requests to ad servers bound to the site the request originates from, improving latency and resilience you would typically enable this when large distributed deployment different regions use local ad domain controllers 5\ step 2 – map radius to segments and ssids nile radius works hand‑in‑hand with segments and ssids 5 1 create/verify segments in nile control center, ensure that segments exist for the desired logical zones, e g employee prod contractor camera guest each segment should have dhcp configuration (subnet, pool) optional mapping to downstream security constructs (e g , firewall zones) segments replace vlans—each segment is essentially an l3 subnet 5 2 map segments to nile radius for segments where access is controlled via 802 1x associate the segment with nile radius as the authentication backend ensure any legacy external radius mappings (ise/clearpass) are updated or left in place only where you intentionally keep hybrid mode (see migration section) 5 3 configure ssids and wired access wireless ssids go to network setup → wireless create or edit a corporate ssid (e g , corp dot1x) security wpa2‑enterprise (dot1x) map ssid to one or more segments that will be used for radius users wired 802 1x for wired ports, 802 1x behavior is controlled per port or per policy segment mapping is per port or per access profile; no ssid is needed when multiple segments are associated with a single ssid, segment selection is driven by authorization (scim groups, intune compliance, certificate attributes, etc ) rather than static vlan assignments 6\ step 3 – define identity and device groups for radius this step mirrors the ts guide’s “create policy group definitions”, but focuses on radius‑driven identities 6 1 radius‑relevant user groups navigate to security → trust engine → policy groups → user groups create user groups such as employees (eap‑tls) match criteria scim group = employees ; optionally require intune compliance = compliant contractors (eap‑tls or eap‑peap) match criteria scim group = contractors ; optionally separate segments from employees ad users (eap‑peap) match criteria attributes from ad via scim or mapped attributes once ad integration is in place guests / byod match criteria segment or onboarding method (e g , upsk/self‑registration) for each click + under user groups fill group name , description select match criteria (e g , idp group , segment ) enter one or more values click create 6 2 device and application groups for iot and infrastructure devices authenticated via 802 1x (often using eap‑tls) device groups – e g , printers, cameras, zoom rooms match by fingerprint , segment , or certificate attributes (e g , cn contains “camera”) application groups – e g , dvr, call manager match by ip/subnet the ui workflow is analogous to the ts guide navigation security → trust engine → policy groups → device groups or app groups click + ; fill name/description choose match criteria (fingerprint, segment, ip/subnet, etc ) enter values, then create 7\ step 4 – configure radius‑aware policies policies tie together source groups (users/devices) destination groups (apps/segments) service profiles (allowed protocols) actions (allow / deny / forward) 7 1 create service profiles navigate to security → service profiles create profiles such as employee‑internet‑only allows https (tcp 443) and denies all else camera‑to‑vms allows only necessary protocols/ports between cameras and the vms employee‑full‑corp allows a broader set (e g , https, ssh, rdp, database ports) as appropriate the general workflow click + to create a service profile enter name and description add rules specifying name , protocol , port(s) , and action (allow/deny) end with a deny all rule to enforce least privilege 7 2 create policy sets for radius users navigate to security → trust engine → policy sets you can create policies either via the list view or the global matrix example policy set for eap‑tls users employees (eap‑tls) → intranet apps → employee‑full‑corp → allow employees (eap‑tls) → internet → employee‑internet‑only → allow contractors → intranet apps → deny contractors → internet → employee‑internet‑only → allow each policy is created via a wizard basic information – policy name + description source & destination – select the source group and destination group action & service profile – choose allow/deny/forward , select service profile review & save – confirm and save default‑deny ensure that flows you want to permit are explicitly covered; otherwise, they will be denied 8\ endpoint configuration – eap‑tls and eap‑peap this section covers typical supplicant configuration steps always cross‑check with os‑specific docs for ui changes 8 1 windows – wireless 802 1x (eap‑tls) assuming certificates are deployed via mdm confirm the target ssid is configured as wpa2‑enterprise in nile on windows ensure wlan autoconfig service is running add or edit the wireless profile network name match ssid in nile security type 802 1x / wpa2‑enterprise under security choose an eap method appropriate for eap‑tls (e g , “smart card or other certificate” or “eap‑tls” depending on os version) ensure the correct client certificate is selected configure server validation to trust the ca that issued the nile radius server certificate connect and verify that the device appears under devices in nile with eap‑tls radius logs show a successful eap‑tls handshake 8 2 windows – wireless 802 1x (eap‑peap) based on nile’s troubleshooting docs for wireless 802 1x with peap make sure the ssid is configured as wpa2‑enterprise in nile on the windows client check the wlan autoconfig service is running from control panel → network and sharing center choose set up a new connection or network select manually connect to a wireless network enter network name ssid from nile security type 802 1x after creating the profile, open its properties → security tab choose network authentication method microsoft protected eap (peap) click settings inner method secured password (eap‑mschapv2) click advanced settings authentication mode user authentication attempt connection and verify successful peap authentication in nile devices and radius logs 8 3 windows – wired 802 1x (eap‑peap) from nile’s wired 802 1x troubleshooting guide ensure that the relevant switch port is configured for 802 1x in nile on windows open network connections , right‑click the ethernet adapter, and choose properties if the authentication tab is missing start the wired autoconfig service (services msc) re‑open the adapter properties; the authentication tab should appear on the authentication tab enable ieee 802 1x authentication set the network authentication method to microsoft protected eap (peap) in peap settings, choose secured password (eap‑mschapv2) in advanced settings , select user authentication only connect the cable and verify 802 1x success in nile’s devices view and events 8 4 macos, ios, android nile docs reference macos native supplicants but generally defer to vendor documentation general guidance eap‑tls import the client certificate and private key into the system keychain configure the 802 1x profile to use tls or “certificate” authentication and select the identity enable server certificate validation against your nile radius server ca eap‑peap configure the wi‑fi network with peap and inner mschapv2 ensure server certificate validation is enabled and trusts your nile radius server ca for large fleets, use mdm (e g , intune, jamf) to push wi‑fi profiles 9\ validation and troubleshooting 9 1 verifying 802 1x activity in nile in the nile control center, go to devices filter by mac address or username to see authentication method (eap‑tls vs eap‑peap) segment assignment recent events and timestamps for deeper policy‑layer validation, use security → trust engine → policy logs to see source/destination groups applied service profile action (allow / deny / forward) flow metadata (ips, ports, timestamps) 9 2 common issues and checks no device entry in nile for the mac address indicates the supplicant is not sending 802 1x at all check supplicant services (wlan/wired autoconfig), profile configuration, and that the ssid/port is 802 1x‑enabled wired device falls into mab (mac‑auth) flow mean 802 1x failed to start; the device shows up in the mab pending list fix the wired supplicant configuration and retry certificate‑related failures (eap‑tls) confirm correct ca chain uploaded to nile radius client certs issued by one of these cas clients trust the radius server certificate chain username/password failures (eap‑peap) check nile radius → ad connectivity verify user credentials against ad ensure correct ad servers and site‑aware settings are chosen in nile 9 3 radius alerts nile automatically generates radius failure alerts when a significant percentage of clients see failures in a rolling 15‑minute window 5–10% failures “radius alert 5% ≤ clients < 10% …” 10–25% failures “radius alert 10% ≤ clients < 25% …” 25–100% failures “radius alert 25% ≤ clients ≤ 100% …” clicking an alert takes you directly to the devices page filtered to affected clients, simplifying bulk troubleshooting alerts auto‑close when failures drop below 5% 10\ day‑2 operations and monitoring 10 1 continuous monitoring nile radius is monitored regularly from every site for availability and performance backed by cloud‑scale ha and auto‑scaling infrastructure use radius monitoring pages and device session views to troubleshoot individual logins policy logs to understand segment and policy assignment decisions 10 2 policy changes and audits when changing scim mappings, intune usage, or certificate mappings (cn/ou‑based policies), always stage changes in a limited scope (test site or subset of groups) use logs to verify correct behavior before broad rollout 10 3 handling non‑802 1x or headless devices for devices that cannot run 802 1x use upsk and self‑registration headless devices can be onboarded with per‑device pre‑shared keys upsk can work with external radius (e g , ise/clearpass) or nile cloud radius as a backend this allows nile radius to focus on 802 1x‑capable endpoints while still securing legacy or constrained devices 11\ migration and co‑existence with legacy nac many customers migrate from cisco ise , aruba clearpass , or similar legacy nac solutions 11 1 migration patterns wireless new sites map ssids directly to nile radius from day one existing sites keep ssids mapped to legacy radius until ready; migrate site‑by‑site wired use the “wired dot1x” option (where available) to choose whether legacy nac or nile radius handles wired 802 1x, enabling controlled migration rather than big‑bang cutovers 11 2 reusing legacy policies external integration docs (ise/clearpass) show how legacy nac returns nile vsas like netseg to drive segment assignment byod flows can start with eap‑peap for onboarding and move to eap‑tls once certs are installed when you move to nile radius the same segment semantics are reused; only the control point (who runs radius and where policies are evaluated) changes