# RADIUSaaS Documentation Certificate-Based Authentication for Wi‑Fi, VPN, and Wired Networks RADIUSaaS offers easy and secure authentication for accessing network resources. It delivers the comfort, reliability, and scalability of a native cloud SaaS. Supported protocols are RADIUS as well as RadSec. Authentication is based on certificates. RADIUSaaS is generally capable of validating every certificate that can be used for client authentication. However, to be able to lock someone with a revoked certificate out of your network, choose a CA which provides a publicly accessible OCSP or CRL endpoint. ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/p3Z2iZSGtK7QmoSnV2VV/radius-aas-flow.png) These docs cover technical aspects of RADIUSaaS. All other information can be found on the [RADIUSaaS website](https://radius-as-a-service.com/). # Overview ## What is RADIUS? Whenever large companies need network authentication, [RADIUS (RFC 2865)](https://tools.ietf.org/html/rfc2865) is the protocol of choice. RADIUS is a AAA protocol which stands for **authentication, authorization and accounting**. It is therefore best suited for controlling access to networks like WiFi, Wired (802.1X, EAP) or VPN. The protocol was developed by Livingston Enterprises, Inc. in 1991 and is now part of the IETF standards. ## What is RadSec? RADIUS is an efficient protocol for authentication purposes that uses the UDP transport protocol. Nonetheless, some traffic will not be encrypted during transport. This can be avoided by using [RadSec (RFC 6614)](https://tools.ietf.org/html/rfc6614) which is transported over TCP and completely encapsulated within a TLS tunnel. ## Authentication Certificates The easiest way to push device or user certificates to your clients is [SCEPman](https://www.scepman.com/), as it is super-easy to deploy and integrates seamlessly with Intune and other MDM systems.\ \ You can also use the [Microsoft Cloud PKI](/configuration/get-started/scenario-based-guides/microsoft-cloud-pki), your own on-premise PKI or other compatible CAs. RADIUSaaS supports multiple CAs in parallel. #### Online Certificate Verification To check if a certificate is considered valid by your Certificate Authority (CA) **at authentication time**, RADIUSaaS leverages the Online Certificate Status Protocol (OCSP) or Certificate Revocation Lists (CRLs). {% hint style="info" %} To reduce the amount of requests sent to an OCSP responder some certificates states will be [temporarily cached](/other/faqs/log-and-common-errors#certificate-status-was-revoked-previously). {% endhint %} ## Our Service ### RADIUS #### Admin Portal Each customer has access to their own personal instance through their own RADIUSaaS Admin Portal, which can be used for tasks such as [creating users](/admin-portal/users/users#add), changing [allowed certificates](/admin-portal/settings/trusted-roots), [adding proxies](/admin-portal/settings/settings-proxy), creating [rules](/admin-portal/access-and-rules/rules) or performing troubleshooting using RADIUSaaS Insights. #### RADIUS to RadSec Proxy The service's internal RADIUS server only allows [RadSec](/overview#what-is-radsec) connections. If your WiFi infrastructure does not support RadSec, RADIUSaaS features a [proxy](/admin-portal/settings/settings-proxy) functionality, which will establish a secure tunnel allowing you to use the service with traditional UDP-based RADIUS. #### Guests, BYOD and IOT Devices Some of your devices may not be able to receive certificates. Reasons could be that they are not managed by any policy provider/MDM system, or they are simply technically not able to work with certificates. \ In those cases, BYOD or guests scenarios, you can [add users](/admin-portal/users/users#add) to your instance and restrict the access to a specific time frame, if needed. This allows you to authenticate printers, TVs or other devices with a single instance of the service while using the same SSID. ### Regions RADIUSaaS can be used globally. **RADIUSaaS' core service** can be deployed into datacenters in the following regions and countries: * Australia * European Union * United Kingdom * United States of America **RADIUS proxies** can be deployed into datacenters on [all continents](/admin-portal/settings/settings-proxy#regions). ## Getting Started Please follow the steps on the following page to get your clients ready authenticating with RADIUS-as-a-Service! {% content-ref url="/pages/-Mczun9TRZ6NaGIkRq66" %} [Getting Started](/configuration/get-started) {% endcontent-ref %} # SCEPman Integration RADIUSaaS integrates with [SCEPman](https://docs.scepman.com/?_gl=1*89r1op*_ga*MTQyOTEzMDY4MS4xNzgzNDA2ODA1*_ga_BRDGXLVK3H*czE3ODM0MDY4MDQkbzEkZzAkdDE3ODM0MDY4MDQkajYwJGwwJGgw) to deliver end-to-end certificate-based network authentication. While SCEPman automates certificate issuance and lifecycle management, RADIUSaaS validates certificates and controls access to Wi‑Fi, VPN, and wired networks. Customers can choose between a self-managed Enterprise Bundle and a fully managed SaaS Bundle based on their deployment and operational needs. **The following bundle options are available:** ## **RADIUSaaS + SCEPman Enterprise Bundle** The RADIUSaaS + SCEPman Enterprise Bundle combines the full Enterprise Editions of RADIUSaaS and SCEPman into one integrated solution for certificate-based network access. The bundle includes all enterprise features, product support, and advanced authentication capabilities required for productive environments. It is designed for organizations that want to secure Wi-Fi, VPN, and wired network access using certificates without relying on traditional passwords. **We recommend the Enterprise Bundle for:** * Productive environments * Enterprise-grade network security * Certificate-based Wi-Fi, VPN, and LAN authentication * Scalability and high availability * Organizations requiring support and enterprise features ## **RADIUSaaS + SCEPman SaaS Bundle** The RADIUSaaS + SCEPman SaaS Bundle provides a fully managed cloud-based solution for certificate issuance and network authentication. By combining RADIUSaaS and SCEPman in a SaaS offering, organizations can deploy secure network access without managing their own PKI or RADIUS infrastructure. The solution integrates with Microsoft Intune and Microsoft Entra ID to enable modern, passwordless network authentication. **We recommend the SaaS Bundle for:** * Organizations looking for a fully managed service * Simplified deployment and operations * Cloud-first environments * Certificate-based Wi-Fi and VPN authentication * Reduced infrastructure and maintenance effort For both options the [SCEPman Connection](https://docs.radiusaas.com/admin-portal/settings/settings-server#scepman-connection) feature enables automatic issuance and renewal of RADIUSaaS server certificates through SCEPman. ## **RADIUSaaS + SCEPman Bundle Edition Comparison**
CapabilityRADIUSaaS + SCEPman Enterprise BundleRADIUSaaS + SCEPman SaaS Bundle
HostingCustomer's Azure TenantVendor's Datacenters
Infrastructure CostCustomerVendor
MaintenanceCustomer / AzureVendor
ConfigurationCustomerCustomer
Geo-RedundancyYesPlanned
Certificate Master RBACYesNo
AD EnrollmentYesYes
Enrollment REST APIYesYes
LoggingAzure Monitor /
Log Analytics		WebConsole
CA hierarchyYesBring your own Key Vault (BYOK)
Machine certificatesYesYes
User certificatesYesYes
AD Device CertificatesYesYes
Certificate ManagementYesYes
Kerberos CertificatesYesYes
Other MDM IntegrationYesYes
Device Compliance CheckYesYes
SupportYesYes
Licensing Subscription-fee Subscription-fee
# Getting Started Our Getting Started Guides provide step-by-step instructions on how to configure RADIUSaaS for your environment. ## Checklist Let's start with some essential questions: * [ ] What PKI(s) are you using to issue the client authentication certificates? * [ ] Shall device- or user-type client authentication certificates be used for authentication? * [ ] Which MDM system are you using (e.g. Intune and/or Jamf Pro) and do you have access and rights to create device configuration profiles? * [ ] Does your networking equipment support RadSec (RADIUS via TCP/TLS) and/or RADIUS (UDP)? * [ ] Do you have access to the management portal of your networking gear? * [ ] Do you have permissions in your Azure tenant to consent the Basic User Profile Read Access? This is needed to access your RADIUSaaS Portal. ## General Structure Below diagram details the generic setup procedure as explained in our guides below. The linear procedure forks depending on whether your network equipment supports **RadSec** natively **or** **RADIUS** only. Thus, in case you have requirements for both (e.g. due to a heterogeneous AP and/or switch fleet), both configurations must be completed. Besides our [Generic Guide](/configuration/get-started/generic-guide), we have prepared [Scenario-based Guides](/configuration/get-started/scenario-based-guides) describing how RADIUSaaS can be configured for certificate-based WiFi authentication together with popular Cloud PKI solutions: * RADIUSaaS with Microsoft Cloud PKI * RADIUSaaS with SCEPman ## Generic Guide {% content-ref url="/pages/0MMZ0wJtvDGDEMj8ImYb" %} [Generic Guide](/configuration/get-started/generic-guide) {% endcontent-ref %} ## Scenario-based Guides {% content-ref url="/pages/fTVIdkrigRdMevtt8ck0" %} [Microsoft Cloud PKI](/configuration/get-started/scenario-based-guides/microsoft-cloud-pki) {% endcontent-ref %} {% content-ref url="/pages/BwPUbviKnJuM9kP4ImWe" %} [SCEPman Enterprise](/configuration/get-started/scenario-based-guides/scepman-enterprise) {% endcontent-ref %} # Generic Guide {% stepper %} {% step %} ### PKI Setup {% hint style="warning" %} This is a **mandatory** step. May be omitted if you are using RADIUSaaS with [username/password-based authentication](/admin-portal/users/users) only. {% endhint %} Set up your PKI so that the necessary client authentication certificates are automatically pushed to your endpoint devices. If you are using any of the below PKIs, please follow the relevant guides instead: {% content-ref url="/pages/fTVIdkrigRdMevtt8ck0" %} [Microsoft Cloud PKI](/configuration/get-started/scenario-based-guides/microsoft-cloud-pki) {% endcontent-ref %} {% endstep %} {% step %} ### Trusted CA(s) Setup {% hint style="warning" %} This is a **mandatory** step. {% endhint %} Tell your RADIUSaaS instance which client authentication certificates will be allowed to authenticate and how to check if those certificates are still valid: {% content-ref url="/pages/-MYxhI9AbkDJoF5kYBBV" %} [Trusted Certificates](/admin-portal/settings/trusted-roots) {% endcontent-ref %} {% endstep %} {% step %} ### RADIUS Server Certificate Configuration {% hint style="warning" %} This is a **mandatory** step. {% endhint %} {% hint style="info" %} For customers that use **SCEPman** as PKI, we recommend to leverage the [SCEPman integration](/admin-portal/settings/settings-server#scepman-connection) to fully automate the **RADIUS Server Certificate** lifecycle. {% endhint %} Since endpoint devices will establish a TLS connection to RADIUSaaS during network authentication, RADIUSaaS must present a server certificate to the client (the **RADIUS Server Certificate**). This certificate can be generated directly from the **RADIUSaaS Admin Portal** or imported if you already own a suitable certificate (**BYO**). The same server certificate is also used to secure the RadSec connection to your authenticator devices (WiFi access points, switches, VPN gateways), if applicable. In case you are happy to use the **built-in** [**Customer CA**](/admin-portal/settings/settings-server#customer-ca), whose sole purpose it is to issue the **RADIUS Server Certificate**, no further action is required as part of this step. In case you'd prefer to bring your own TLS server certificate, issued by your preferred CA, please follow [these steps](/admin-portal/settings/settings-server#bring-your-own-certificate). {% endstep %} {% step %} ### Network Equipment Configuration {% hint style="warning" %} This is a **mandatory** step. {% endhint %} ### RadSec If your network equipment supports the **RadSec** protocol, follow below steps: #### **WiFi Access Points** For some popular vendors, we have prepared representative step-by-step guides on setting up the RadSec connection [here](/configuration/access-point-setup/radsec-available). While we are not able to provide documentation for every vendor, in general, the following steps apply: 1. Import your active **RADIUS Server Certificate** to your WiFi infrastructure. 2. Add the CA certificate from which your APs have obtained their **RadSec Connection Certificate** to your **Trusted Ceertificates** list as described [here](/admin-portal/settings/trusted-roots#add). 3. Create a new RADIUS profile. 4. Set the IP address and the port of your server in your RADIUS profile. Therefore, use the [public RadSec IP address](/admin-portal/settings/settings-server#properties) and the standard RadSec port (2083). 5. Set the **Shared Secret** to "radsec", if applicable. 6. Assign the created profile to your SSID(s). #### Wired (LAN) Switches Currently, we have not prepared sample guides for networking switches yet. However, the configuration steps are similar to the ones for WiFi Access Points. In case you face difficulties, please [reach out to us](https://www.radius-as-a-service.com/help/). ### RADIUS If your network equipment **does not support RadSec**, you must first deploy proxies that handle the protocol conversion from [RADIUS](/overview#what-is-radius) to [RadSec](/overview#what-is-radsec) : {% content-ref url="/pages/-MYxgLR1E0hnBt5yqLpf" %} [Proxy Settings](/admin-portal/settings/settings-proxy) {% endcontent-ref %} Next, move on to configuring your equipment: #### **WiFi Access Points** For some popular vendors, we have prepared representative step-by-step guides [here](/configuration/access-point-setup/proxy-needed). While we are not able to provide documentation for every vendor, in general, the following steps apply: 1. Create a new RADIUS profile. 2. Configure an external RADIUS server: * As server IP address, configure the IP address of your [**proxy**](/admin-portal/settings/settings-server#properties-1)**.** * Take the shared secret from your [**Server Settings**](/admin-portal/settings/settings-server#radius-udp) page. * Configure the standard ports for RADIUS authentication (1812) and accounting (1813 - optional). 3. Assign the created profile to your SSID(s). #### **Wired (LAN) Switches** Currently, we have not prepared sample guides for switch appliances yet. However, the configuration steps are similar to the ones for WiFi Access Points. In case you face difficulties, please [reach out to us](https://www.radius-as-a-service.com/help/). {% endstep %} {% step %} ### MDM Profiles {% hint style="warning" %} This is a **mandatory** step. {% endhint %} {% hint style="success" %} **For Jamf Pro** We strongly recommend to configure all 802.1X-relevant payloads in a **single** Configuration Profile in Jamf Pro - and one Configuration Profile per assignment type (Computers, Devices, Users). {% endhint %} ### Server Certificate To enable trust between your endpoint devices and the server certificate RADIUSaaS presents upon authentication, configure a trusted certificate profile in your preferred MDM solution. Therefore, first download the Root CA certificate that has issued your currently active **RADIUS Server Certificate** as described [here](/admin-portal/settings/settings-server#download). {% hint style="danger" %} When downloading the relevant certificate, ensure to **only** **download** the **Root CA** certificate of your currently active RADIUS Server Certificate (highlighted in green) - not the entire chain or the RADIUS Server Certificate itself! {% endhint %} Move on to push out this certificate via MDM: #### **Microsoft Intune** {% content-ref url="/pages/-MYxiLd7JIp6ZsqGaDol" %} [Server Trust](/profile-deployment/microsoft-intune/trusted-root) {% endcontent-ref %} #### Jamf Pro {% content-ref url="/pages/qedLmVD2hg2xuGDaUALd" %} [Server Trust](/profile-deployment/jamf-pro/server-trust) {% endcontent-ref %} ### WiFi Profile To configure a WiFi profile in your preferred MDM solution, follow one of these guides: #### **Microsoft Intune** {% content-ref url="/pages/-MYxiZmAIpyMYZXLfOdl" %} [WiFi Profile](/profile-deployment/microsoft-intune/wifi-profile) {% endcontent-ref %} #### **Jamf Pro** {% content-ref url="/pages/JjbQKqgciZW4eAVVBjtC" %} [WiFi Profile](/profile-deployment/jamf-pro/wifi-profile) {% endcontent-ref %} ### Wired (LAN) Profile To configure a wired (LAN) profile for your stationary devices in your preferred MDM solution, follow one of these guides: #### **Microsoft Intune** {% content-ref url="/pages/-MYxvNFJUncToXBdPvsu" %} [Wired Profile](/profile-deployment/microsoft-intune/wired-profile) {% endcontent-ref %} #### **Jamf Pro** {% content-ref url="/pages/R7rgEshgHnAaJ937nOLg" %} [Wired Profile](/profile-deployment/jamf-pro/wired-profile) {% endcontent-ref %} {% endstep %} {% step %} ### Permissions and Technical Contacts {% hint style="warning" %} This is a **mandatory** step. {% endhint %} First, review your [Permissions](/admin-portal/access-and-rules/permissions) to ensure the right persons in your organization have the right level of administrative access to your RADIUSaaS instance. {% hint style="success" %} To **prevent yourself from being locked** out of your RADIUSaaS instance, always ensure that either * at least two user identities or * one service account are configured as [Administrators](/admin-portal/access-and-rules/permissions#administrators). {% endhint %} Next, ensure that we are able to contact you in case we have important technical information to share by reviewing the [Technical Contacts](/admin-portal/access-and-rules/permissions#technical-contacts) section. {% hint style="success" %} For us to **reliably deliver important information** to you via email, always ensure that either * at least two email addresses of individuals or * one shared mailbox / distribution list are configured. {% endhint %} {% endstep %} {% step %} ### Rules {% hint style="info" %} This is an **optional** step. {% endhint %} If you would like to configure additional rules, for example to assign VLAN IDs or limit authentication requests to certain trusted CAs or WiFi access points, please check out the RADIUSaaS Rule Engine. {% content-ref url="/pages/Np05pVHXbtrMwBdTDctJ" %} [Rules](/admin-portal/access-and-rules/rules) {% endcontent-ref %} {% endstep %} {% endstepper %} {% content-ref url="/pages/Np05pVHXbtrMwBdTDctJ" %} [Rules](/admin-portal/access-and-rules/rules) {% endcontent-ref %} # Scenario-based Guides # Microsoft Cloud PKI This document describes the configuration steps necessary to implement certificate-based WiFi authentication using Microsoft Cloud PKI with Intune. {% hint style="info" %} It is assumed that the Microsoft Cloud PKI hosts both the Root and Issuing CA. For scenarios involving BYOCAs please refer to Microsoft's online resources or the web. {% endhint %} {% stepper %} {% step %} ### Deploy a Microsoft Cloud PKI #### Create a Root CA in Intune admin center Before you can issue certificates to managed devices, you need to create a root CA in your tenant to act as the trust anchor. To create a root CA in Intune admin center, please follow [this ](https://learn.microsoft.com/en-gb/mem/intune/protect/microsoft-cloud-pki-configure-ca#:~:text=an%20admin%20user.-,Step%201%3A%20Create%20root%20CA%20in%20admin%20center,-Before%20you%20can)Microsoft guide. {% hint style="info" %} Please take note of the CRL distribution point as you will need this later in [Step 2](#step-1-create-root-ca-in-admin-center-2). {% endhint %} #### Create an Issuing CA in Intune admin center An issuing CA is required to issue certificates for Intune-managed devices. Cloud PKI automatically provides a SCEP service that acts as a certificate registration authority. It requests certificates from the issuing CA on behalf of Intune-managed devices using a SCEP profile. To create an issuing CA, please follow [this ](https://learn.microsoft.com/en-gb/mem/intune/protect/microsoft-cloud-pki-configure-ca#step-2-create-issuing-ca-in-admin-center)Microsoft guide. {% hint style="info" %} Please take note of the CRL distribution point as you will need this later in [Step 2](#step-1-create-root-ca-in-admin-center-2). {% endhint %}

Root and Issuing CAs

{% endstep %} {% step %} ### Establish trust between RADIUSaaS and the Microsoft Cloud PKI Configure RADIUSaaS to trust client authentication certificates issued by the Microsoft Cloud PKI. Since the cloud PKI requires a tiered CA structure, you must upload both, Root CA and Issuing CA (i.e. the complete chain of trust). To achieve this, please follow the steps below: 1. Navigate to [Trusted Certificates](/admin-portal/settings/trusted-roots). 2. [Upload](/admin-portal/settings/trusted-roots#add) the Contoso Cloud PKI **Root CA,** selecting **Client Authentication** in the upload process. 3. As a verification method, select **CRL** along with **DER** encoding. 4. Use the copied CRL distribution point URL of the Root CA in the **CRL Distribution Points** URL input field.\ ![](https://1222554226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSWU1DQ4UGkqER7uGNUOm%2Fuploads%2FBysDSYfb60HoJYZooFO6%2Fimage.png?alt=media\&token=63bd15fc-04f1-4c0e-b89a-404f6f88dbad) 5. Upload the Contoso Cloud PKI **Issuing CA,** selecting **Client Authentication** in the upload process. 6. Again, select **CRL** as verification method along with **DER** encoding. 7. Use the copied CRL distribution point URL of the Issuing CA in the **CRL Distribution Points** URL input field.\ ![](https://1222554226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSWU1DQ4UGkqER7uGNUOm%2Fuploads%2F6VLWwSE1UssDpLpY5A0S%2Fimage.png?alt=media\&token=9ecae690-c5ac-4726-9dee-4ae7aa390d56) {% endstep %} {% step %} ### Configure the RADIUS Server Certificate To establish server trust between your endpoint devices and RADIUSaaS, follow [these instructions](/configuration/get-started/generic-guide#step-3-radius-server-certificate-configuration). {% endstep %} {% step %} ### Configure your Networking Equipment To configure your networking equipment (WiFi access points, switches, or VPN gateways), follow [these steps](/configuration/get-started/generic-guide#step-4-network-equipment-configuration). After successful completion of Steps 2 - 4, the **Trusted Certificates** page of your RADIUSaaS instance will look similar to the one below. Please note that in our example we have used a RadSec-enabled [MikroTik](/configuration/access-point-setup/radsec-available/mikrotik) access point.

Trusted Certificates Overview required for the Microsoft Cloud PKI.

{% endstep %} {% step %} ### Configure Intune Profiles To set up certificate-based WiFi authentication, we need to create a number of profiles and deploy them via Intune. These profiles are: | Profile Type | Purpose | | ------------------- | ----------------------------------------------------------------------------- | | Trusted certificate | Deploy the Root CA certificate. | | Trusted certificate | Deploy the Issuing CA certificate. | | Trusted certificate | Deploy the Root CA certificate that has issued the RADIUS Server Certificate. | | SCEP certificate | Enroll the client authentication certificate. | | Wi-Fi | Deploy the wireless network adapter settings. |

Relevant Intune Profiles

#### Trusted certificate profiles **Microsoft Cloud PKI** Deploy the root CA and issuing CA certificates created in [Step 1](#step-1.-deploy-a-microsoft-cloud-pki) via a **Trusted certificate** profile to your devices by navigating to the **Intune admin center** and then to **Home** > **Devices** > **Windows** > **Configuration profiles > Create** > **New Policy** with the following parameters: * Platform = Windows 10 and later * Profile type = Template * Template name = Trusted certificate. Upload the relevant certificate file (\*.cer) in the respective profile: * Root CA certificate created [here](#step-1-create-root-ca-in-admin-center) * Issuing CA certificate created [here](#step-1-create-root-ca-in-admin-center-1) {% hint style="info" %} Note that you have to use the same group for assigning the Trusted certificate and SCEP profiles. Otherwise, the Intune deployment might fail. {% endhint %} This must be repeated for every device platform that shall be using the service (e.g. Windows, macOS, ...) **RADIUS Server Trust** Next, push the root CA certificate that has issued your RADIUS Server Certificate as described here: {% content-ref url="/pages/-MYxiLd7JIp6ZsqGaDol" %} [Server Trust](/profile-deployment/microsoft-intune/trusted-root) {% endcontent-ref %} #### SCEP Certificate Profile To create a **SCEP certificate** profile in Intune admin center, first take a copy of the SCEP URI from **Home** > **Tenant admin** > **Cloud PKI** > **Contoso Issuing CA** > **Properties** > **SCEP URI.** Next, go to **Home** > **Devices** > **Windows** > **Configuration profiles > Create** > **New Policy** with the following parameters: * Platform = Windows 10 and later * Profile type = Template * Template name = SCEP certificate Next, configure the template according to the screenshot below making sure you attached the **Contoso Root Certificate** created earlier in step 1 and the **SCEP URI** you took a copy of above.

SCEP Device Certificate Configuration

This must be repeated for every device platform that shall be using the service (e.g. Windows, macOS, ...) #### Wi-Fi profile Deploy the WiFi adapter settings to your devices by following this article: {% content-ref url="/pages/-MYxiZmAIpyMYZXLfOdl" %} [WiFi Profile](/profile-deployment/microsoft-intune/wifi-profile) {% endcontent-ref %} {% endstep %} {% step %} ### Permissions and Technical Contacts {% hint style="warning" %} This is a **mandatory** step. {% endhint %} First, review your [Permissions](/admin-portal/access-and-rules/permissions) to ensure the right persons in your organization have the right level of administrative access to your RADIUSaaS instance. {% hint style="success" %} To **prevent yourself from being locked** out of your RADIUSaaS instance, always ensure that either * at least two user identities or * one service account are configured as [Administrators](/admin-portal/access-and-rules/permissions#administrators). {% endhint %} Next, ensure that we are able to contact you in case we have important technical information to share by reviewing the [Technical Contacts](/admin-portal/access-and-rules/permissions#technical-contacts) section. {% hint style="success" %} For us to **reliably deliver important information** to you via email, always ensure that either * at least two email addresses of individuals or * one shared mailbox / distribution list are configured. {% endhint %} {% endstep %} {% step %} ### Rules {% hint style="info" %} This is an **optional** step. {% endhint %} If you would like to configure additional rules, for example to assign VLAN IDs or limit authentication requests to certain trusted CAs or WiFi access points, please check out the RADIUSaaS Rule Engine. {% content-ref url="/pages/Np05pVHXbtrMwBdTDctJ" %} [Rules](/admin-portal/access-and-rules/rules) {% endcontent-ref %} {% endstep %} {% endstepper %} # SCEPman Enterprise This article describes the configuration steps necessary to implement certificate-based WiFi authentication using SCEPman with Intune. For this demonstration, we will use a MikroTik access point. {% stepper %} {% step %} ### Deploy SCEPman Enterprise {% hint style="warning" %} Please note that this scenario requires [SCEPman Enterprise Edition.](https://docs.scepman.com/editions#edition-comparison) {% endhint %} First and foremost, you will need to set up and configure your SCEPman. Please use [documentation](https://docs.scepman.com/scepman-deployment/deployment-guides) relevant to your environment to perform the installation and configuration of SCEPman. Once completed, return to this article. {% endstep %} {% step %} ### Establish trust between RADIUSaaS and SCEPman For RADIUSaaS to trust client authentication certificates issued by SCEPman PKI, you must add SCEPman's root CA certificate to the RADIUSaaS trust store following [these steps](/admin-portal/settings/trusted-roots#add). {% endstep %} {% step %} ### Configure the RADIUS Server Certificate {% embed url="" %} {% endstep %} {% step %} ### Configure your Networking Equipment To configure your networking equipment (WiFi access points, switches, or VPN gateways), follow [these steps](/configuration/get-started/generic-guide#step-4-network-equipment-configuration). After successful completion of Steps 2 - 4, the **Trusted Certificates** page of your RADIUSaaS instance will look similar to the one below. Please note that in our example we have used a RadSec-enabled [MikroTik](/configuration/access-point-setup/radsec-available/mikrotik) access point that leverages a SCEPman-issued RadSec **Client Certificate**.
{% endstep %} {% step %} ### Configure Intune Profiles To set up certificate-based WiFi authentication, you will need to create and deploy a number of policies via Intune. These policies are as follow:
Profile TypePurpose
Trusted certificateDeploy the Root CA certificate that has issued the RADIUS Server Certificate.

In this scenario, the relevant CA corresponds to the SCEPman Root CA.
SCEP certificateDeploy the client authentication certificate.
Wi-FiDeploy the wireless network adapter settings.

Relevant Intune Policies

### Trusted Certificate Profiles This profile was configured as part of the [SCEPman setup](https://docs.scepman.com/certificate-deployment/microsoft-intune). ### SCEP Certificate Profile This profile was configured as part of the [SCEPman setup](https://docs.scepman.com/certificate-deployment/microsoft-intune). ### WiFi Profile Deploy the Wi-Fi adapter settings to your devices by following this article: {% content-ref url="/pages/-MYxiZmAIpyMYZXLfOdl" %} [WiFi Profile](/profile-deployment/microsoft-intune/wifi-profile) {% endcontent-ref %} {% endstep %} {% step %} ### Permissions and Technical Contacts {% hint style="warning" %} This is a **mandatory** step. {% endhint %} First, review your [Permissions](/admin-portal/access-and-rules/permissions) to ensure the right persons in your organization have the right level of administrative access to your RADIUSaaS instance. {% hint style="success" %} To **prevent yourself from being locked** out of your RADIUSaaS instance, always ensure that either * at least two user identities or * one service account are configured as [Administrators](/admin-portal/access-and-rules/permissions#administrators). {% endhint %} Next, ensure that we are able to contact you in case we have important technical information to share by reviewing the [Technical Contacts](/admin-portal/access-and-rules/permissions#technical-contacts) section. {% hint style="success" %} For us to **reliably deliver important information** to you via email, always ensure that either * at least two email addresses of individuals or * one shared mailbox / distribution list are configured. {% endhint %} {% endstep %} {% step %} ### Rules This is an **optional** step. If you would like to configure additional rules, for example to assign VLAN IDs or limit authentication requests to certain trusted CAs or WiFi access points, please check out the RADIUSaaS Rule Engine. {% content-ref url="/pages/Np05pVHXbtrMwBdTDctJ" %} [Rules](/admin-portal/access-and-rules/rules) {% endcontent-ref %} {% endstep %} {% endstepper %} # SCEPman SaaS This article describes the configuration steps necessary to implement certificate-based WiFi authentication using SCEPman SaaS with Intune. {% stepper %} {% step %} ### Configure SCEPman SaaS First and foremost, you will need to set up and configure your SCEPman PKI. Please refer to this guide to complete this step. Once completed, return to this article. {% content-ref url="/pages/tywmYoXQzMpzctQVCWnb" %} [🆕 SCEPman SaaS](/configuration/scepman-saas) {% endcontent-ref %} {% endstep %} {% step %} ### Establish Trust between RADIUSaaS and SCEPman For RADIUSaaS to trust client authentication certificates issued by SCEPman PKI, you must add SCEPman's root CA certificate to the RADIUSaaS trust store following these steps: {% embed url="" %} {% endstep %} {% step %} ### Configure the RADIUS Server Certificate Leverage SCEPman to fully automate the lifecycle of your RADIUSaaS Server Certificate by setting up **SCEPman Connection** as below**:** Navigate to **SCEPman Connection** section under **Settings** > **Server Settings** and click on **Setup Connection**.
Then you will get
Once you click Yes, RADIUSaaS will request a server certificate from SCEPman, activate it, and renew it in time before it expires. Everything happens automatically, without any interaction required from your side. {% endstep %} {% step %} ### Configure your Networking Equipment To configure your networking equipment (WiFi access points, switches, or VPN gateways), follow these steps: {% embed url="" %} After completing the previous steps, the **Trusted Certificates** page of your RADIUSaaS instance will look similar to the one shown below. Please note that in our example we have used a RadSec-enabled [MikroTik](/configuration/access-point-setup/radsec-available/mikrotik) access point that leverages a SCEPman-issued RadSec **Client Certificate**.
{% endstep %} {% step %} ### Configure Intune Profiles To set up certificate-based Wi-Fi authentication, you will need to create and deploy several policies in Intune. These policies are as follows:
Profile TypePurpose
Trusted certificateDeploy the Root CA certificate that has issued the RADIUS Server Certificate.

In this scenario, the relevant CA corresponds to the SCEPman Root CA.
SCEP certificateDeploy the client authentication certificate.
Wi-FiDeploy the wireless network adapter settings.

Relevant Intune Policies

### Trusted Certificate Profiles This profile was configured as part of the [SCEPman setup](https://docs.scepman.com/certificate-deployment/microsoft-intune). ### SCEP Certificate Profile This profile was configured as part of the [SCEPman setup](https://docs.scepman.com/certificate-deployment/microsoft-intune). ### WiFi Profile Deploy the Wi-Fi adapter settings to your devices by following this article: {% content-ref url="/pages/-MYxiZmAIpyMYZXLfOdl" %} [WiFi Profile](/profile-deployment/microsoft-intune/wifi-profile) {% endcontent-ref %} {% endstep %} {% step %} ### Permissions and Technical Contacts {% hint style="warning" %} This is a **mandatory** step. {% endhint %} First, review your [Permissions](/admin-portal/access-and-rules/permissions) to ensure the right persons in your organization have the right level of administrative access to your RADIUSaaS instance. {% hint style="success" %} To **prevent yourself from being locked** out of your RADIUSaaS instance, always ensure that either * at least two user identities or * one service account are configured as [Administrators](/admin-portal/access-and-rules/permissions#administrators). {% endhint %} Next, ensure that we are able to contact you in case we have important technical information to share by reviewing the [Technical Contacts](/admin-portal/access-and-rules/permissions#technical-contacts) section. {% hint style="success" %} For us to **reliably deliver important information** to you via email, always ensure that either * at least two email addresses of individuals or * one shared mailbox / distribution list are configured. {% endhint %} {% endstep %} {% step %} ### Rules This is an **optional** step. If you would like to configure additional rules, for example to assign VLAN IDs or limit authentication requests to certain trusted CAs or WiFi access points, please check out the RADIUSaaS Rule Engine. {% content-ref url="/pages/Np05pVHXbtrMwBdTDctJ" %} [Rules](/admin-portal/access-and-rules/rules) {% endcontent-ref %} {% endstep %} {% endstepper %} # Access Point Setup The pages in this section explain how to setup your network access gear to integrate with your RADIUSaaS instance. We will add more vendors and systems in the future. However, we encourage you to go through the setup wizards of your network gear and try to match them to the manuals already provided here, as they typically work all in the same way. # RadSec

Showing TLS outer tunnel and required certificates

Before your access points are able to establish a valid **RadSec connection** (which can be considered an mTLS connection), the following requirements must be met regardless of the manufacturer of the access point. * Access Points require a valid **client certificate** (typically referred to as "RadSec Client Certificate" or "RadSec Certificate"). This client certificate must have the **EKU Client Authentication** (1.3.6.1.5.5.7.3.2) and **not Server Authentication**. * Access Points must **trust the CA** that issued the **RADIUS Server Certificate**. * RADIUSaaS must **trust the CA** that issued the **RadSec client certificate** on your access points. {% hint style="info" %} The RadSec protocol requires a shared secret to compute the MD5 integrity checks.\ The [RadSec RFC](https://datatracker.ietf.org/doc/html/rfc6614#:~:text=to%20implement\).%0A%0A%20%20%204.-,start,-exchanging%20RADIUS%20datagrams) defines this shared secret as the literal string "radsec". {% endhint %} {% content-ref url="/pages/866i8vaujnDotY5bMxLh" %} [Aruba](/configuration/access-point-setup/radsec-available/aruba) {% endcontent-ref %} {% content-ref url="/pages/Ov1MkwKbWcsukXtSuDbh" %} [FortiNet](/configuration/access-point-setup/radsec-available/fortinet) {% endcontent-ref %} {% content-ref url="/pages/9CuV5Soe0kztpSCpWVgM" %} [Juniper Mist](/configuration/access-point-setup/radsec-available/juniper-mist) {% endcontent-ref %} {% content-ref url="/pages/TZNh0jkwXn3yAiGLvuSE" %} [Meraki](/configuration/access-point-setup/radsec-available/meraki) {% endcontent-ref %} {% content-ref url="/pages/-MYxptKGaLHkV8klwKqu" %} [MikroTik](/configuration/access-point-setup/radsec-available/mikrotik) {% endcontent-ref %} {% content-ref url="/pages/4JjevW3adMbCnd2bh8y9" %} [Ruckus](/configuration/access-point-setup/radsec-available/ruckus) {% endcontent-ref %} {% content-ref url="/pages/a7o9Xin6spkxl0PrF6Ha" %} [UniFi](/configuration/access-point-setup/radsec-available/unifi) {% endcontent-ref %} # Aruba ## Prepare certificates To establish a valid RadSec connection, your Access Points must trust the **RADIUS Server Certificate** and your RADIUS server must trust your **RadSec Client Certificate**. To achieve this, 1. Download the root certificate of the CA that has issued your active **RADIUS Server Certificate** as described [here](/admin-portal/settings/settings-server#download). 2. Create a **RadSec Client Certificate** for your WAPs (centrally managed via Aruba Central). If you are using **SCEPman Certificate Master**, the process is described [here](https://docs.scepman.com/certificate-deployment/certificate-master/client-certificate-pkcs-12). {% hint style="warning" %} Ensure to monitor the expiry of your **RadSec Client Certificate** and renew it in due time to prevent service interruptions. {% endhint %} 3. Add the root certificate of the CA that has issued the **RadSec Client Certificate** to your RADIUS instance as described [here](/admin-portal/settings/trusted-roots#add) and select **RadSec** under **Use for**.\ In case the **RadSec Client Certificate** has been issued by SCEPman and you already trust the SCEPman Root CA for client authentication, simply edit the trusted SCEPman Root CA certificate and select **Both** under **Use for**. ## Aruba Central configuration {% hint style="info" %} Below settings are the necessary settings to establish a functional RadSec connection with our service. Configure any other settings at your discretion. {% endhint %} For general information on how to import certificates to your Aruba platform, please refer to their documentation: {% embed url="" %} 1. Import the root certificate of the CA that has issued your **RADIUS Server Certificate** with the type **CA certificate**.
2. Import the **RadSec Client Certificate** (created in step 2 under [Prepare Certificates](#prepare-certificates)) with the type **Server certificate**.
3. Under **Access Points >** **Security** select the imported **RadSec Client Certificate** for **RadSec** and the RADIUS root CA certificate for **RadSec Certificate Authority**.
4. For the RADIUS server configuration, enable **RadSec** and choose either the IP address or the DNS name of your [RadSec service endpoint](/admin-portal/settings/settings-server#properties).
# FortiNet {% hint style="info" %} To use the RadSec feature on your FortiGate for WiFi (with FortiAPs), firmware FortiOS **7.6.0** or later is required on the FortiGate. {% endhint %} ## Prepare certificates To establish a valid RadSec connection, your Access Points must trust the **RADIUS Server Certificate** and your RADIUS server must trust your **RadSec Client Certificate**. To achieve this, 1. Download the root certificate of the CA that has issued your active **RADIUS Server Certificate** as described [here](/admin-portal/settings/settings-server#download). 2. Create a **RadSec Client Certificate** for your WAPs (centrally managed via FortiGate). If you are using **SCEPman Certificate Master**, the process is described [here](https://docs.scepman.com/certificate-deployment/certificate-master/client-certificate-pkcs-12). FortiGate accepts the **PKCS#12** format for RadSec client certificates. {% hint style="warning" %} Ensure to monitor the expiry of your **RadSec Client Certificate** and renew it in due time to prevent service interruptions. {% endhint %} 3. Add the root certificate of the CA that has issued the **RadSec Client Certificate** to your RADIUS instance as described [here](/admin-portal/settings/trusted-roots#add) and select **RadSec** under **Use for**.\ In case the **RadSec Client Certificate** has been issued by SCEPman and you already trust the SCEPman Root CA for client authentication, simply edit the trusted SCEPman Root CA certificate and select **Both** under **Use for**. ## FortiGate configuration {% hint style="info" %} Below settings are the necessary settings to establish a functional RadSec connection with our service. Configure any other settings at your discretion. {% endhint %} ### Via UI To configure RadSec on your FortiGate UI please follow the steps: * Create a new **RADIUS Server** and add your [RadSec server IP address](/admin-portal/settings/settings-server#radsec-tcp) under **IP/Name**. For the **Secret**, use "radsec".
* Import the [root CA of your RADIUS Server Certificate](/admin-portal/settings/settings-server#download) to the FortiGate **Certificates** under **System > Certificates > Import > CA Certificate**. The imported root CA will be listed under **Remote CA Certificate**.
* Import the **RadSec Client Certificate** to your FortiGate under\ **System > Certificates > Import > Certificate**.
* Modify the RADIUS server configuration in your FortiGate to use it as RadSec client certificate. * If enabled, please disable the **server-identity-check** in your FortiGate RADIUS server configuration. ### Via command line To configure RadSec on your FortiGate using the command line, please use these below sets of instructions: #### RADIUS server configuration ```python config user radius edit "radiusaas" set server "radsec-CLIENTNAME.radius-as-a-service.com" set secret radsec set acct-interim-interval 600 set radius-port 2083 set transport-protocol tls set ca-cert "CA_Cert" set client-cert "certificate-fortigate" set server-identity-check disable next end # Name the root CA of your RADIUS Server Certificate set ca-cert "CA_Cert" # Name the RadSec client certificate set client-cert "certificate-fortigate" ``` #### WiFi SSID configuration ```python config wireless-controller vap edit "client-wireless" set ssid "client-wireless" set security wpa2-only-enterprise set pmf enable set 80211k disable set 80211v disable set auth radius set radius-server "radiusaas" set local-bridging enable set schedule "always" next end ``` ### References Link to FortiGate's documentation for the RadSec configuration:\ # Juniper Mist ## Prepare certificates To establish a valid RadSec connection, your Access Points must trust the **RADIUS Server Certificate** and your RADIUS server must trust your **RadSec Client Certificate**. To achieve this, 1. Download the root certificate of the CA that has issued your active **RADIUS Server Certificate** as described [here](/admin-portal/settings/settings-server#download). 2. Create a **RadSec Client Certificate** for your Access Points. If you are using **SCEPman Certificate Master**, the process is described [here](https://docs.scepman.com/certificate-deployment/certificate-master/client-certificate-pkcs-12). {% hint style="warning" %} Ensure to monitor the expiry of your **RadSec Client Certificate** and renew it in due time to prevent service interruptions. {% endhint %} 3. Add the root certificate of the CA that has issued the **RadSec Client Certificate** to your RADIUS instance as described [here](/admin-portal/settings/trusted-roots#add) and select **RadSec** under **Use for**.\ In case the **RadSec Client Certificate** has been issued by SCEPman and you already trust the SCEPman Root CA for client authentication, simply edit the trusted SCEPman Root CA certificate and select **Both** under **Use for**. ## Mist configuration {% hint style="info" %} Below settings are the necessary settings to establish a functional RadSec connection with our service. Configure any other settings at your discretion. {% endhint %} 1. Navigate to your Mist configuration plane. 2. To configure the relevant certificates, navigate to **Organization** **>** **Settings**.
3. Add the root certificate of the CA that has issued your **RADIUS Server Certificate** under **RadSec Certificate**.
4. Add your **RadSec Client Certificate** (created in step 2 under [Prepare Certificates](#prepare-certificates)) to **AP RadSec Certificate**.
5. Go to **Site >** **WLANs**.
6. Create a new WLAN if you have not already created one for which you want to leverage RADIUS authentication against our service. 7. Select **Enterprise (802.1X)** as **Security Type**.
8. Under **RadSec**, select **Enabled** and set the **Server Name** to the **SAN** attribute of your **RADIUS Server Certificate**.
9. For **Server Addresses** use either the IP address or the DNS name of your [RadSec service endpoint](/admin-portal/settings/settings-server#properties).
### A complete walk-through
# Meraki {% hint style="info" %} To use the RadSec feature on your Meraki APs, firmware version **MR 30.X** or later is required. {% endhint %} {% hint style="warning" %} Retain the existing Certificate Authority (Cisco Meraki Keeper PKI) for RadSec deployments, rather than migrating to Meraki's newly introduced [PureCA](https://documentation.meraki.com/Wireless/Design_and_Configure/Architecture_and_Best_Practices/Cisco_Keeper_to_PureCA_Migration_Strategy) service.\ \ **Rationale**: Certificates generated by PureCA can only be used by networks running on MR 33.1.2 firmware version or higher. MR 33.1.2 firmware is currently classified as beta. - 08/09/2026. {% endhint %} ## Prepare certificates {% hint style="warning" %} The Meraki platform does not allow you to generate RadSec client certificates from a CA of your choice. Instead, you must use Meraki's built-in **Organization CA** that is unique to your Meraki Organization. {% endhint %} Download the root certificate of the CA that has issued your active **RADIUS Server Certificate** as described [here](/admin-portal/settings/settings-server#download). You will need to upload it to your Meraki console later on. ## Meraki configuration {% hint style="info" %} Below settings are the necessary settings to establish a functional RadSec connection with our service. Configure any other settings at your discretion. {% endhint %} {% hint style="danger" %} Ensure to **disable the OCSP revocation check of the RadSec client certificate** as described in step 7 of this guide. {% endhint %} {% stepper %} {% step %} ### Navigate to your Meraki Dashboard In your Dashboard, select **Wireless > Access Control** and ensure that you have switched to the **new UI version** of the Access control site:
{% endstep %} {% step %} ### Configure the RADIUS server in your SSID Select the **SSID** you wish to configure RADIUS authentication for (or navigate to **Wireless > Configure > SSIDs** to create a new SSID first). In the **Security** section of your SSID, select **Enterprise with** and in the dropdown **my RADIUS server:**
Under **RADIUS**, click **Add server**. Configure the **Host IP or FQDN** to match the IP address or the DNS name of your [RadSec service endpoint](/admin-portal/settings/settings-server#properties), set the **Port** to 2083 and set the **Secret** value to "radsec" and activate the **RadSec** checkbox.
{% endstep %} {% step %} ### Configure EAP Timeouts Configure **EAP parameters and timeouts** according to [this](/other/faqs/general#timers-and-timeouts) reference guide by going to **Wireless** > **Radius** > **Advanced RADIUS settings.** Once configured, it should look similar to the screenshot below. Click **Save** to apply the settings.
{% endstep %} {% step %} ### Add RadSec Server Certificate To upload and generate the required certificates that make the RadSec connection functional, navigate to **Organization > Certificates > RADSEC**.
In the top table, click **Upload certificate** and provide the root certificate of the CA that has signed your [**RADIUS Server Certificate**](/admin-portal/settings/settings-server#server-certificates), which you should have already downloaded in this [step](#prepare-certificates). Your Meraki APs now trust your RADIUS server. {% tabs %} {% tab title="Using RADIUSaaS Customer CA" %}
{% endtab %} {% tab title="Using SCEPman or other CA" %}
{% endtab %} {% endtabs %} {% endstep %} {% step %} ### Create RadSec Client Certificate {% tabs %} {% tab title="Keeper" %} Under **RadSec device certificates**, first create an **Organization CA** by clicking **Generate CA**. This CA is unique to your Meraki Organization.\ The Meraki platform will now automatically generate RadSec client certificates for all your APs signed by this CA. The lifetime of the certificate is very long (> 50 years), i.e. you do not have to worry about renewing them. Download the root CA certificate of your **Organization CA** of your Meraki system by clicking **Download CA**.
{% endtab %} {% tab title="RadSec PureCA certificates" %} {% hint style="info" %} PureCA is currently in beta. {% endhint %}
After downlading the certificate chain, you will have to split it up and upload it separately to RADIUSaaS > Trusted Certificates, starting with the root. You can use PowerShell to split the chain into 5 certificates. For example, the following script will split the downloaded chain and saves each file separately using the certificate's commonName as the file name. {% code overflow="wrap" %} ```powershell $c=[regex]::Matches((Get-Content .\chain.pem -Raw),'(?s)-----BEGIN CERTIFICATE-----.*?-----END CERTIFICATE-----').Value | % { [Security.Cryptography.X509Certificates.X509Certificate2]::new([Text.Encoding]::ASCII.GetBytes($_)) }; $ord=[Collections.ArrayList]@(); $seen=@{}; $cur=$c | ? { $_.Subject -eq $_.Issuer } | Select -First 1; while($cur){ [void]$ord.Add($cur); $seen[$cur.Thumbprint]=1; $cur=$c | ? { $_.Issuer -eq $ord[-1].Subject -and -not $seen[$_.Thumbprint] } | Select -First 1 }; $c | ? { -not $seen[$_.Thumbprint] } | % { [void]$ord.Add($_) }; $i=0; $ord | % { $cn=($_.GetNameInfo('SimpleName',$false) -replace '[\\/:*?"<>|]','_'); $f=".\{0:d2}-{1}.pem" -f $i++,$cn; Set-Content $f ("-----BEGIN CERTIFICATE-----`n"+[Convert]::ToBase64String($_.RawData,'InsertLineBreaks')+"`n-----END CERTIFICATE-----") -Encoding ascii; "$f subject=$($_.Subject) issuer=$($_.Issuer)" } ``` {% endcode %} The above script will produce the following certificate structure. ``` 00-Cisco Meraki Dashboard Root CA.pem └─ 01-Cisco Meraki Dashboard Cluster SubCA.pem └─ 02-Meraki.com Cluster CA.pem └─ 03-1608009.pem (your org CA) └─ 04-radsec-1608009.pem (issues the RadSec client certs) ``` {% endtab %} {% endtabs %} {% hint style="warning" %} You will not be able to upload RadSec client certificates of another CA with Meraki. Instead the Organization CA, which is unique to your organization, will provide all your access points with suitable certificates. {% endhint %} {% endstep %} {% step %} ### Trust Organization CA in RADIUSaaS Now, upload the downloaded CA certificate to your [Trusted Certificates in your RADIUSaaS web console](/admin-portal/settings/trusted-roots#add) and select **RadSec** under **Use for**.
{% hint style="info" %} In case your PKI has a multi-tier hierarchy (Root CA, Intermediate CA, Issuing CA), make sure to upload all of them to the RADIUSaaS Trusted Certificates store. {% endhint %} {% endstep %} {% step %} ### Disable Revocation Check for RadSec Certificates Finally, disable the [revocation check for the RadSec client certificates](/admin-portal/settings/settings-server#verification-check-for-radsec-certificates) on your RADIUSaaS instance (this does not adversely affect security as the Meraki Organization CA does not allow to revoke RadSec client certificates). Therefore, navigating to your RADIUSaaS instance and then **Settings > Server Settings** and disable the checkbox **Verification check for RadSec certificates**.
{% endstep %} {% step %} ### Test Configuration To test that the configuration works, you can add a user in your [Portal](/admin-portal/users/users#add-a-new-user) and use the Meraki test function.
{% endstep %} {% endstepper %} ### References Link to Meraki's documentation for the RadSec configuration: # MikroTik ## Prepare certificates To establish a valid RadSec connection, the MikroTik Access Points must trust the **RADIUS Server Certificate** and your RADIUS server must trust the **RadSec Client Certificate**. To achieve this, follow below steps: ### Option 1: Using the SCEPman PKI 1. Download the root certificate of the CA that has issued your active **RADIUS Server Certificate** as described [here](/admin-portal/settings/settings-server#download). Since you are using SCEPman, that might be your SCEPman Root CA certfiicate. 2. Log on to your MikroTik device, then upload the certificate from step 1 above to the MikroTik device using the **Files** menu on the left. 3. Once uploaded, switch to your **Terminal** tab on the top right and execute the following command to import this certificate to MikroTik's certificate store: ``` /certificate import file-name="scepman-root.cer" ``` 4. Generate a **RadSec Client Certificate** using **SCEPman Certificate Master** by navigating to the [**Client Certificate**](https://docs.scepman.com/certificate-deployment/certificate-master/client-certificate-pkcs-12) menu:
{% hint style="warning" %} Ensure to monitor the expiry of your **RadSec Client Certificate** and renew it in due time to prevent service interruptions. {% endhint %} 5. Once the **RadSec Client Certificate** is downloaded, extract the private key, e.g. using OpenSSL, as this will have to be imported to the access point separately: ``` openssl pkey -in yourfile.pem -out private.key ``` 6. Upload both files, the certificate and the private key via the **Files** menu. Then import the certificate first and then the private key. During the import process the **private key** will merge with the certificate indicated by a letter '**K**' as shown below.
### Option 2: Using other PKIs {% hint style="info" %} Use this section if you want to create a root CA on your Mikrotik AP and generate a **RadSec Client Certificate** from this root. Please note that all of these steps can be completed either in GUI or terminal. {% endhint %} 1. Download the root certificate of the CA that has issued your active **RADIUS Server Certificate** as described [here](/admin-portal/settings/settings-server#download). 2. Log on to your MikroTik device, then upload the certificate from step 1 above to the MikroTik device using the **Files** menu on the left. 3. Once uploaded, switch to your **Terminal** tab on the top right and execute the following command to import this certificate to MikroTik's certificate store: ``` /certificate import file-name="RADIUS Customer CA - Contoso.cer" ``` 4. If you have not already generated **RadSec Client Certificate** for MikroTik AP, generate one as per the below example. For more information about creating certificates, click [here](https://wiki.mikrotik.com/wiki/Manual:Create_Certificates). {% hint style="warning" %} Ensure to monitor the expiry of your **RadSec Client Certificate** and renew it in due time to prevent service interruptions. {% endhint %} Example: ``` /certificate add name=myCa common-name=myCa key-usage=key-cert-sign,crl-sign /certificate add name=mikrotik-client common-name=mikrotik-client /certificate sign mikrotik-client ca=myCa name=mikrotik-client ``` In the above example, the first line creates a root CA called **myCa**. The second line generates a client certificate for the MikroTik device, and the third line uses **myCa** (CA) to sign the **mikrotik-client** certificate generated in step 2. If all went well, you would end up with three certificates as shown below. Please ensure your MikroTik device trusts the relevant certificates (**T** flag in the green section). If that is not the case yet, set the flag using below command: ``` /certificate set myCa trusted=yes set "RADIUS Customer CA - Contoso.cer" trusted=yes ```
5. Export the root CA certificate (`myCa`) that has issued your **RadSec Client Certificate** above: ``` /certificate export-certificate myCa ``` 6. Download it from the **Files** menu and then upload the file to your RADIUSaaS instance as described [here](/admin-portal/settings/trusted-roots#add) and select **RadSec** under **Use for.** Once completed, continue configuring your MikroTik AP as per [below ](#mikrotik-configuration)and use **Option 1** for certificates. ## MikroTik Configuration {% hint style="info" %} Please note that the below configuration was tested with RouterOS 6.47.4 and 6.49.11 {% endhint %} 1. Switch back to your WebFig, add a new RADIUS profile and enter the following information:
ParameterValue
AddressUse the IP address from your Server Settings page.
Protocolradsec
Secret"radsec"
Authentication Port2083
Accounting Port2083
Timeout4000 ms
CertificateOption 1: SCEPman Issued (RadSec) Client Certificate (generated in step 4).
Option 2: RadSec Client Certificate issued by MikroTik's built-in CA (generated in step 4).
![Configuring RADIUS / RadSec profile](https://1222554226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSWU1DQ4UGkqER7uGNUOm%2Fuploads%2FfM6mmWqYWYDXC4rxDrBM%2F2024-09-03_14h43_36.png?alt=media\&token=c1ab1a19-5e32-42d2-9f57-394ffe51ae41) 2. Go to **Wireless,** add a new **Security Profile** and enter the following information:
ParameterValue
NameName of the RADIUS security profile
Modedynamic keys
EAP Methodspassthrough
TLS Modeverify certificate
TLS CertificateOption 1: SCEPman Root CA certificate.
Option 2: RADIUSaaS Customer-CA certificate.
![](https://1222554226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSWU1DQ4UGkqER7uGNUOm%2Fuploads%2F8HFMIdX7JdMxugs31tgO%2F2025-08-28_12h39_32.png?alt=media\&token=acde26c0-eea6-43d7-be3b-725e966f3049) 3. Switch to your **Wi-Fi Interfaces** and assign your **Security Profile** to the interface. ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/0TAA2KG9NUR5tWOtjzdU/image.png) # Ruckus {% hint style="info" %} The following guide was created using Ruckus **Virtual SmartZone Essentials** version **6.1.2.0.441**. {% endhint %} ## Prepare certificates To establish a valid RadSec connection, your Access Points must trust the **RADIUS Server Certificate** and your RADIUS server must trust your **RadSec Client Certificate**. To achieve this, 1. Download the root certificate of the CA that has issued your active **RADIUS Server Certificate** as described [here](/admin-portal/settings/settings-server#download). 2. Create a **RadSec Client Certificate** for your Ruckus SmartZone. If you are using **SCEPman Certificate Master**, the process is described [here](https://docs.scepman.com/certificate-deployment/certificate-master/client-certificate-pkcs-12). 3. **Split the generated certificate** into the private key (named "priv.key" in this example) and the certificate (named "clientcert.cer"). In case the **RadSec Client Certificate** was downloaded in the **PKCS#12/.pfx** format, this can be easily done, e.g. using OpenSSL:\ \ Private Key:\ `openssl pkcs12 -in .pfx -nocerts -nodes -out priv.key`\ \ Certificate without Private Key:\ `openssl pkcs12 -in .pfx -clcerts -nokeys -out clientcert.cer` Depending on your Ruckus firmware version, it might be necessary to remove the bag attributes section from your certificate and private key files. This section looks like the following example: ``` Attributes localKeyID: 52 70 EB 96 89 23 90 F9 D5 0E 06 82 5C EC F7 63 30 44 F1 A9 friendlyName: Certificate from SCEPman Key Attributes: ``` {% hint style="warning" %} Ensure to monitor the expiry of your **RadSec Client Certificate** and renew it in due time to prevent service interruptions. {% endhint %} 3. Add the root certificate of the CA that has issued the **RadSec Client Certificate** to your RADIUS instance as described [here](/admin-portal/settings/trusted-roots#add) and select **RadSec** under **Use for**. \ In case the **RadSec Client Certificate** has been issued by SCEPman and you already trust the SCEPman Root CA for client authentication, simply edit the trusted SCEPman Root CA certificate and select **Both** under **Use for**. ## Ruckus SmartZone (SZ) configuration {% hint style="info" %} In the following, Ruckus SZ is configured as an **authentication proxy**, i.e. RADIUS authentication requests are routed from the WAPs to the Ruckus SZ and centrally forwarded to RADIUSaaS. {% endhint %} For general information on how to import certificates to the Ruckus SmartZone, please refer to their documentation: {% embed url="" %} 1. Import the root certificate of the CA that has issued your **RADIUS Server Certificate** (downloaded during step 1 [here](#prepare-certificates)) by navigating to **Administration >** **System > Certificates > SZ Trusted CA Certificates/Chain (external)**. 2. Click **Import**, provide a **Name** and optional **Description** for your RADIUS CA certificate and upload the certificate file by clicking **Browse** next to **Root CA Certificate**. In case you are bringing your own **RADIUS Server Certificate** and in case it has been issued by an intermediate CA, please also upload all intermediate certificates under **Intermediate CA Certificates**.
3. Next, click **Validate** and **OK**. 4. Import your **RadSec Client Certificate** (obtained from step 3 [here](#prepare-certificates)) by navigating to **Administration >** **System > Certificates > SZ as Client Certificate**. 5. Click **Import** and provide a **Name** and optional **Description** for your **RadSec Client Certificate**. Then upload the public portion of your **RadSec Client Certificate** by clicking **Browse** next to **Client Certificate**. Finally, upload the private key by clicking **Browse** next to **Private Key**.
6. For the RADIUS server configuration, navigate to **Security > Authentication > Proxy (SZ Authenticator)**. 7. Click **Create** and provide a **Name**, optional **Friendly Name** and **Description** for the RADIUS profile. 8. Select **RADIUS** as **Service Protocol**. 9. Under **RADIUS Service Options**, configure the following settings: | **Encryption** | Enable | | ----------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **CN/SAN Idenity** |

Provide the CN/SAN attribute of your RADIUS Server Certificate.

Showing SAN to be used as Certificate server name

| | **OCSP Validation** |

Default: Disabled
In case you are bringing your own RADIUS Server Certificate and the CA that has issued it allows for its revocation, provide the OCSP Responder URL of your CA here.

| | **Client Certificate** | Select the **RadSec Client Certificate** uploaded to Ruckus SZ previously. | | **Server Certificate** | Disable | | **RFC5580 Out of Band Location Delivery** | Disable | 10. Next, under **Primary Server**, for the **IP Address/FQDN** choose either the IP address or the DNS name of your [RadSec service endpoint](/admin-portal/settings/settings-server#properties). For the **Port** select **2083**.
11. Click **OK**. # UniFi {% hint style="info" %} RADIUS over TLS (RADSEC) has been added to **UniFi Network 8.4** and newer versions. Please have your controller and network devices **up-to-date** before following this guide. {% endhint %} {% hint style="warning" %} Customers have reported **delays** between activating the RadSec feature on the Unify Dashboard and becoming functional. {% endhint %} ## Prepare certificates To establish a valid RadSec connection, your Access Points must trust the **RADIUS Server Certificate** and your RADIUS server must trust your **RadSec Client Certificate**. To achieve this, 1. Download the root certificate of the CA that has issued your active **RADIUS Server Certificate** as described [here](/admin-portal/settings/settings-server#download).\ In this example SCEPman is used as Root CA and has issued the RADIUS server certificate. So, we download the root CA certificate from SCEPman portal:\ \ ![](https://1222554226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSWU1DQ4UGkqER7uGNUOm%2Fuploads%2Fqcje6zykfUaJtZ2Mpn2J%2Fimage.png?alt=media\&token=2d4e54d1-79fa-40ff-8886-a3f23fa93eec)\ Afterwards, please convert your certificate to Base-64. This can be easily done via Windows Certificate Export Wizard, OpenSSL or other tools:
2. Create a **RadSec Client Certificate** for your access points. If you are using **SCEPman Certificate Master**, the process is described [here](https://docs.scepman.com/certificate-deployment/certificate-master/client-certificate-pkcs-12).\ In this example we generate a certificate in the format "PEM". Please note down the password, as we need this later.
3. Split the generated certificate into the private key (named "priv.key" in this example) and the certificate (named "clientcert.cer"). This can be easily done via a text editor:
4. Add the root certificate of the CA that has issued the **RadSec Client Certificate** to your RADIUS instance as described [here](/admin-portal/settings/trusted-roots#add) and select **RadSec** under **Use for**.\ In case the **RadSec Client Certificate** has been issued by SCEPman (this example) and you already trust the SCEPman Root CA for client authentication, simply edit the trusted SCEPman Root CA certificate and select **Both** under **Use for**:\
## UniFi configuration {% hint style="info" %} Below settings are the necessary settings to establish a functional RadSec connection with our service. Configure any other settings at your discretion. {% endhint %} 1. Navigate to your Unifi Network controller and open **Settings** **> Profiles > RADIUS**. 2. Create a new profile or update an existing one:
3. Fill in the required information: 1. **RADIUS Assigned VLAN Support**: optional / if needed 2. **RADIUS Settings**: 1. **TLS**: Enable the checkbox. 2. **Authentication Servers**:\ \- **Server IP Address/es**: Provide the IP address of your [RadSec service endpoint](/admin-portal/settings/settings-server#properties).\ \- **Port**: 2083.\ \- **Shared Secret**: `radsec`. 3. **Client Certificate**: Upload the **RadSec Client Certificate** (obtained from step 3 [here](#prepare-certificates)). 4. **Private Key**: Upload the private key of your **RadSec Client Certificate** (obtained from step 3 [here](#prepare-certificates)). 5. **Private Key Password**: as noted down. 6. **CA Certificate**: Upload the Root certificate of the CA that has issued your **RADIUS Server Certificate** (obtained from step 1 [here](#prepare-certificates)). 7. **Accounting**: Enable the checkbox. 8. **RADIUS Accounting Server**:\ \- **Server IP Address/es**: Provide the IP address of your [RadSec service endpoint](/admin-portal/settings/settings-server#properties).\ \- **Port**: 2083\ \- **Shared Secret**: `radsec` 9. **Interim Update Interval**: optional / if needed
4. Assign this profile to the desired WiFi profile:
5. Give your Access Points some time to apply the new configuration:\ \ ![](https://1222554226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSWU1DQ4UGkqER7uGNUOm%2Fuploads%2FgLOTqgYBnWr21PwSxqwx%2Fimage.png?alt=media\&token=6db006ec-38eb-4b04-be4e-cabe263426ea) ### Reference: UniFi Help Center [UniFi Gateway - Configuring a RADIUS Server](https://help.ui.com/hc/en-us/articles/360015268353-UniFi-Gateway-Configuring-a-RADIUS-Server) # RADIUS {% hint style="warning" %} Remember to configure a secondary RADIUS server whenever possible. {% endhint %} {% content-ref url="/pages/dCtvSPjFIKWEaLMZs1zb" %} [ExtremeCloud IQ CoPilot](/configuration/access-point-setup/proxy-needed/extremecloud-iq-copilot) {% endcontent-ref %} {% content-ref url="/pages/XGBwMT56M67sQqWvoBft" %} [Meraki](/configuration/access-point-setup/proxy-needed/meraki) {% endcontent-ref %} {% content-ref url="/pages/-Mkeas9F6QI4QE6FXxZx" %} [Sophos UTM](/configuration/access-point-setup/proxy-needed/sophos-utm) {% endcontent-ref %} {% content-ref url="/pages/-MYxqL8KnpnbFeCQ9VUI" %} [UniFi](/configuration/access-point-setup/proxy-needed/unifi) {% endcontent-ref %} # ExtremeCloud IQ CoPilot Unfortunately only \`ExtremeCloud IQ SiteManager\` is able to speak RadSec(as far we know). This site handles CoPilot ## ExtremeCloud IQ CoPilot configuration 1. Go to **Configure > Common Objects > Authentication > External Radius Servers** and click **Add**
2. Enter the IP Object and give everything a descriptive name
3. Set the **Shared secret** which is displayed on your RaaS website and save the changes
4. Go to **Configure > Network Policies > Add Network Policy**
5. After the policy has been created, you're able to create a **SSID.** Click **Add** on **Wireless Networks** 6. Choose your preferred **SSID** Name and select **Enterprise** for **SSID Authentication**
7. Under **Authentication Settings** add the radius server which we've added in step 3 and save everything
8. Deploy the **Network Policy** to the Access Points
# Meraki {% hint style="warning" %} Starting with firmware version **MR 30.X**, Meraki APs support RadSec. Hence, we recommend to update your firmware version and follow the [RadSec guide for Meraki](/configuration/access-point-setup/radsec-available/meraki) instead. {% endhint %} ## Meraki configuration 1. In your Meraki **Dashboard** go to **Wireless > SSIDs** 2. Enable a new SSID and give it the name you want 1. Save your changes ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/HHH0BV5GfPQKlckfIOUN/image.png) 3. Edit the Settings of your SSID 1. Under **Network access** select **Enterprise with my RADIUS server**![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/7jgPgS9AnRFXvx9OKIMU/image.png) 4. After that, go to **RADIUS servers** and add your RADIUS servers. Use the **IP Address** of your [**Proxy**](/admin-portal/settings/settings-server#properties-1), the **Port** 1812 and the **Shared Secret** from your [**Server Settings**](/admin-portal/settings/settings-server) page![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/FUN8zTvBZAiRhNL4j4uh/image.png) 5. Configure **EAP parameters and timeouts** according to [this ](https://docs.radiusaas.com/other/faqs/general)reference guide by going to **Wireless** > **Radius** > **Advanced RADIUS settings.** Once configured, it should look similar to the screenshot below.

Showing EAP parameters and timeouts

6. To **test** that the configuration works, you can add a user in your [Portal](/admin-portal/users/users#add-a-new-user) and use the Meraki test function ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/vS67zRsPtNO9uDYp8bw2/image.png) 7. **Save** your changes. # Sophos UTM {% hint style="info" %} The Sophos appliance does not allow to assign different RADIUS servers to different SSIDs. So be aware of that if you are migrating from a onPremises RADIUS server to RADIUS-as-a-Service. May talk with our support team to plan your migration. {% endhint %} ## Sophos configuration ### RADIUS profile Please go through the following steps and configurations to create a RADIUS profile: 1. In Sophos navigate to **Definitions & Users** and select **Authentication Services** and select the tab **Servers** 2. Click **New Authentication Server** 3. Fill the forms with all your information ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/nFnzWHsDyhX4NnVh1hUI/sophos_1.png) ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/5VFqrzF1JvHv7lkNntKn/sophos_2.png) ### SSID configuration Perform the following steps and configurations for SSID: 1. Navigate to **Wireless Protection**, select **Global Settings** and go to the tab **Advanced** 2. Select the created RADIUS profile 3. Then navigate to your **SSID** settings which can be found under **Wireless Protection > Wireless Networks** 4. Create a SSID with the **Encryption Mode, WPA2/WPA-Enterprise** ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/oA1rRkoGB33F5dgqBumz/sophos_3.png) ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/aQB3byQRCbYjTSiZG0sB/sophos_4.png) # UniFi {% hint style="warning" %} Starting with **UniFi Network 8.4** RadSec is supported. We recommend to follow the [RadSec guide for UniFi](/configuration/access-point-setup/radsec-available/unifi) instead. {% endhint %} ## UniFi configuration ### RADIUS profile Please go through the following steps and configurations to create a RADIUS profile: 1. In UniFi navigate to **Settings** and select **Profiles** 2. Click **Create a new RADIUS Profile** 3. Fill the forms with all your information ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/qxcXSsUpRMQnNCmjFYA5/image.png) ### SSID Do the following steps and configurations for SSID: 1. In UniFi navigate to **Settings** and select **Wireless Networks** 2. Click **Create new Wireless Network** 3. Enter a name for **Name/SSID** 4. For **Security** choose **WPA Enterprise** 5. Finally as **RADIUS Profile** select the created profile ![](https://gblobscdn.gitbook.com/assets%2F-Lzl3JXanfpvdg6pLlGg%2F-M03hV6tYhKuZqKfxnpF%2F-M03l0lPBQzneR9sw0mC%2Fimage.png?alt=media\&token=162f4892-09ba-448a-8cf7-4e12d6bb614c) # Server Certificate Renewal This page describes the renewal process of the RADIUSaaS server certificate. A server certificate is essential for securing both the EAP-TLS inner tunnel and the RadSec TLS outer tunnel on RADIUSaaS. To prevent authentication failures, ensure to renew your certificate before it expires. ### **Your server certificate can be one of the following two types:** 1. [Customer-CA](https://docs.radiusaas.com/admin-portal/settings/settings-server#customer-ca). This comes with your RADIUSaaS and offers long expiry of 20 years. Currently there is no way to create a new Customer-CA alongside the existing one. This means that the existing expiring Customer-CA will need to be deleted before a new one can be created. Creating a new Customer-CA will also generate a new root certificate that will need to be re-deployed to your clients. Please follow [this ](#deploying-the-new-server-certificate)article to deploy your new Customer-CA and reference it via your MDM's WiFi policy. 2. Bring Your Own (BYO) certificate using your own PKI, e.g. [SCEPman-issued Server Certificate](https://docs.radiusaas.com/admin-portal/settings/settings-server#scepman-issued-server-certificate). SCEPman server certificates expire every two years, so be sure to set a reminder to prevent downtime. When using a BYO certificate, it's assumed that the **CA's root certificate** and the **FQDN (Subject and SAN)** will remain unchanged from the expiring certificate. Therefore, redeployment of the certificate is unnecessary. ## Creating a new certificate ### Built-in Customer-CA This type of certificate is valid for 20 years and cannot be renewed before its expiry. It can, however, be deleted and a new one created by following [this ](https://docs.radiusaas.com/admin-portal/settings/settings-server#customer-ca)guide. ### BYO certificate If you want to use your own certificate e.g.: a SCEPman-issued server certificate, then follow [this ](https://docs.radiusaas.com/admin-portal/settings/settings-server#bring-your-own-certificate)link to create a server certificate before the expiry in SCEPman or your preferred PKI. ## Deploying the new server certificate #### Intune profiles If you are renewing the Customer-CA or a BYO CA with a different root and FQDN from the previous one then please follow the bellow steps to re-deploy this certificate to your clients, otherwise if you are using a BYO certificate with no change to the CA's root certificate and the FQDN (Subject and SAN), you can skip this step! 1. Deploy the new **server certificate/trusted root** to your clients as described [here](https://docs.radiusaas.com/profile-deployment/jamf-pro/server-trust) by creating a **new** profile. 2. Update your **existing** WiFi or wired profile(s) * If you have used the Intune wizard for the creation of your network profiles, edit all relevant profiles by **adding a second trusted server certificate**. Do not forget to add a second server name under **Certificate server names** in case the new certificate has a different domain. * If you have used a custom profile for the creation of your network profiles, re-download the XML generated by RADIUSaaS from [here](https://docs.radiusaas.com/admin-portal/settings/trusted-roots#xml), and replace it in your existing profile. Both server certificate thumbprints are automatically included in the XML. 3. Wait **until all your clients** have received the updated profile(s).

Example: Updated Windows 10 WiFi profile with two trusted RADIUS server certificates and different domains.

## WiFi & LAN infrastructure If you're using [RadSec](https://docs.radiusaas.com/details#what-is-radsec), upload the new **server certificate** to your access points or network switch device. ## Activating the new server certificate Finally, when you are ready to switch over to the new certificate, active it as described [here](/admin-portal/settings/settings-server#certificate-activation). # 🆕 SCEPman SaaS space.vars.SCEPmanSAAS\_ProductName is a fully managed, hosted and maintained SCEPman deployment. It is included with the RADIUSaaS & space.vars.SCEPmanSAAS\_ProductName Bundle, which provides both services under one subscription. Use it to issue certificates for certificate-based authentication with RADIUSaaS, without managing a SCEPman instance. This guide covers the initial configuration for an **Intune** deployment. ## Setup space.vars.SCEPmanSAAS\_ProductName {% hint style="info" %} If you are already using an existing SCEPman Enterprise deployment in your tenant with RADIUSaaS, make sure to have a look at our migration guide: [Migrate from SCEPman Enterprise](/configuration/scepman-saas/migrate-from-scepman-enterprise) {% endhint %} {% stepper %} {% step %} ### Enroll the space.vars.SCEPmanSAAS\_ProductName CA With an enabled space.vars.SCEPmanSAAS\_ProductName license, you will see that the menu section in **SCEPman** > **Settings** contains options to enroll and configure your SCEPman CA. At the top you have the ability to choose the **Common Name** as well as the **Organization** name for your CA.
{% hint style="info" %} The Common Name and Organization will form the subject of the CA certificate during the enrollment. {% endhint %} By clicking **Enroll root CA**, the setup will start and the status is shown above. Once finished, the SCEPman section will contain additional pages. {% tabs %} {% tab title="Status" %} The **Status** page shows the current state of the CA and its integrations as well as the endpoint URLs you need to request certificates.
{% endtab %} {% tab title="Manage Certificates" %} Under **Manage Certificates** you can browse through issued certificates, check their validity, and also have the option to revoke them.
{% endtab %} {% tab title="Request Certificates" %} Under **Request Certificates**, you can request different types of certificates for manual enrollment and installation or sign CSRs. {% hint style="info" %} Have a look at the dedicated [Certificate Master](https://docs.scepman.com/certificate-management/certificate-master) documentation for more information on the different types of certificates you can request here. {% endhint %}
{% endtab %} {% tab title="Tasks" %} The **Tasks** section shows the current status of the Certificate Master and links to sections permitted by your role.
{% endtab %} {% endtabs %} {% hint style="success" %} SCEPman is now deployed and ready to issue certificates! {% endhint %} {% endstep %} {% step %} ### Configure the default Certificate Profile The default settings applied to certificates issued through all certificate endpoints. Each source under Certificate endpoints can override these two values with its own profile. Revocation for every certificate this CA issues is configured here as well.
Default Certificate Profile Settings **Default Extended Key Usage** What the certificate may be used for. Server certificates need `ServerAuthentication`; device certificates for 802.1X need `ClientAuthentication`. This is only the fallback in case the request does not contain an EKU. **Validity Period** The maximum number of days that an issued certificate is valid. [Learn more](https://docs.scepman.com/scepman-configuration/application-settings/certificates#appconfig-validityperioddays). **Certificate Revocation List (CRL)** Publishes a signed list of revoked certificates for clients that don't support OCSP. The distribution point is embedded in every certificate issued from the moment you enable it. [Learn more](https://docs.scepman.com/certificate-management/manage-certificates/enabling-crl). **OCSP Authorised Responder** Answers revocation live over OCSP, signed by a dedicated responder certificate. Always enabled for SCEPman SaaS. [Learn more](https://docs.scepman.com/certificate-management/manage-certificates).
{% endstep %} {% step %} ### Enable Certificate Endpoints Enable the certificate endpoints relevant to your tenant. Switching the endpoints on will reveal additional settings to configure. For more information on each endpoint, see [here](/admin-portal/scepman-saas/settings#certificate-endpoints). {% hint style="warning" %} Microsoft Intune and Static challenge + Entra device check endpoints require Step 4 to be done first. {% endhint %}
{% endstep %} {% step %} ### Connect SCEPman to your Azure Tenant {% hint style="info" %} You will only need to connect SCEPman to your Azure tenant if you plan to deploy certificate through Intune or the Static-AAD endpoint. {% endhint %} In most scenarios you will want SCEPman to be able to issue certificates by using Intune SCEP profiles and also revoke certificates automatically if a device has been wiped for example. For this to work as intended, SCEPman requires specific roles in your tenant. This can either happen by consenting to our multi-tenant enterprise application or by providing an app registration holding the required permissions yourself. #### Confirm Tenant {% hint style="info" %} We recommend the Admin Consent / multi-tenant enterprise application approach to connect to your Azure tenant, since it does not require a client secret that must be monitored for expiration. {% endhint %} The first step of the **Admin Consent** flow is to enter your tenant ID and confirming it.
Upon clicking **Confirm Tenant** you will be redirected to Microsoft's consent page for authentication and to approve this application initially:
Accepting this consent will add the space.vars.SCEPmanSAAS\_ProductName enterprise application to your tenant but does not yet add the required permissions. #### Consent Admin
After you confirm the tenant, select **Consent Admin**. Microsoft's consent page opens again. Confirm that the application can receive the listed permissions. Learn more in the Security & Privacy Q\&As.
{% hint style="success" %} SCEPman is now able to connect to your Azure tenant and retrieve information for certificate binding! {% endhint %} {% endstep %} {% step %} ### Enable the Intune Endpoint In most scenarios, certificates will be deployed by leveraging Intune SCEP certificate profiles to trigger devices to request certificates from SCEPman. To enable this endpoint, navigate to **SCEPman** > **Settings** and enable the **Intune Validation** setting and save the configuration:
#### Compliance Check As with SCEPman Enterprise, SCEPman can evaluate the validity of a certificate by checking the compliance state of a bound device. Please refer to the [SCEPman documentation](https://docs.scepman.com/scepman-configuration/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-compliancecheck) for more information. #### Device Directory Selecting the device directory depends on the specific binding you choose in the SCEP profile: * `{{DeviceId}}` will be looked up in **Intune** * `{{AAD_DeviceID}}` will be looked up in **AAD** (Entra ID) * `{{UserPrincipalName}}` (UPN) will be looked up in **AAD** (Entra ID) Please refer to the [SCEPman documentation](https://docs.scepman.com/scepman-configuration/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-devicedirectory) for more details on the device directories. {% hint style="success" %} The Intune validation is now enabled and its certificate endpoint is available! {% endhint %} {% endstep %} {% step %} ### Deploy Certificates With the Intune validation enabled, you will find that the SCEPman status page now shows an endpoint URL for the Intune MDM:
This URL will be used in the Intune SCEP certificate profile for the **SCEP Server URL**. #### Root Certificate Make sure to create a **Trusted Certificate** profile in Intune before continuing to the **SCEP certificate** profile and deploy the CA certificate of space.vars.SCEPmanSAAS\_ProductName to your clients. [SCEPman documentation: Root Certificate](https://docs.scepman.com/certificate-management/microsoft-intune/windows-10#root-certificate)
#### SCEP Certificate The process of creating the SCEP certificate profile is identical to SCEPman Enterprise. [SCEPman documentation: SCEP - Intune - Windows](https://docs.scepman.com/certificate-management/microsoft-intune/windows-10)
{% hint style="success" %} Your clients should now receive certificates issued by SCEPman! {% endhint %} {% endstep %} {% endstepper %} ## Establish Trust To allow devices to authenticate using certificates from your space.vars.SCEPmanSAAS\_ProductName CA and enabling your access points to establish RadSec connections to your RADIUSaaS instance, you will need to trust its CA certificate. To do this, first download your CA certificate from the **SCEPman** > **Status** page.
Having the CA certificate in place, navigate to **Settings** > **Trusted Certificates** and add a new certificate.
Upload your downloaded certificate file and save:
{% hint style="success" %} RADIUSaaS will now accept accept incoming connections that use certificates issued by SCEPman! {% endhint %} ## Enable Management of the RADIUSaaS Server Certificate After you have enrolled space.vars.SCEPmanSAAS\_ProductName, you will notice that the SCEPman Connection section under **Connectivity** > **SCEPman** allows you to pregenerate a certificate and setup a connection.
A connection to your SCEPman instance has already been established at this point and RADIUSaaS can request server certificates. The correct way of going further now depends on if you already use RADIUSaaS to authenticate clients at this point or if this is a fresh setup. #### Pregenerate Certificate RADIUSaaS will request a server certificate and add it to the list of certificates but **will not activate it or enable the automatic management.** In case you currently have clients authenticating to RADIUSaaS, this allows you to verify that your Wifi profile has the correct names for server validation as well as the correct root certificate for server validation.
#### Setup Connection If this is a fresh setup or after you have verified that your clients use the correct information for validating the server certificate, you can enable the automatic management of the server certificate by clicking **Setup Connection**.
{% hint style="success" %} RADIUSaaS will now request a server certificate from SCEPman, activate it, and renew it in time before it expires! {% endhint %} ## Other Certificate Endpoints Setting up other certificate endpoints is similar to the way they are set up with SCEPman Enterprise. Make sure to take a look at the relevant documentation: #### Jamf {% embed url="" %} #### REST Enrollment API {% hint style="info" %} The SCEPman SaaS variant of the REST Enrollment API uses RADIUSaaS access tokens instead of Entra access tokens. {% endhint %} {% embed url="" %} #### Active Directory Validation {% embed url="" %} #### Static Validation {% embed url="" %} #### Static-AAD Validation {% embed url="" %} #### DC {% embed url="" %} ## Logs You can find all application logs that you would expect in SCEPman Enterprise in the **Logs** section. These include: * Service Health Messages * Issued Certificates * OCSP Responses * Warnings and Errors during Validation and Issuance
# Migrate from SCEPman Enterprise If you are currently using SCEPman Enterprise in your own tenant and want to further reduce your infrastructure footprint you might want to consider moving to space.vars.SCEPmanSAAS\_ProductName, a fully integrated CA solution built into RADIUSaaS. ### What will change?
WhatChangesStays the same
SCEPman hostingManaged by us, no longer in your Azure tenant.
SCEPman URLNew endpoint URLs.
RADIUS server certificateIf you currently use the SCEPman connection or a SCEPman-issued server certificate a new server certificate will be created.No changes if you use the Customer CA.
Certificate functionalityCertificates work the same way as before.
MDM integrationSCEP certificate profile(s) need to point to new URL and reference a new Root CA certificate.Overall integration approach remains the same.
End-user experienceNo impact, transparent to end-users.
Existing certificatesSee migration impact section below.Valid certificates continue to work.
### Pre-Migration Considerations * **Features**: Some features of SCEPman Enterprise are not available in space.vars.SCEPmanSAAS\_ProductName. Please have a look in our [SCEPman Edition Comparison](/overview#scepman-edition-comparison) to ensure, that you have all your use-cases covered, before you start the migration. * **MDM SCEP profiles**: You'll need to update your SCEP profiles to point to the new space.vars.SCEPmanSAAS\_ProductName URL and reference the new Root CA. Plan for how you want to roll this out (all at once vs. phased). * **Network Environment**: If you are using RadSec, migrating to space.vars.SCEPmanSAAS\_ProductName can mean that the server certificate used for the connection might change. * **DNS or firewall rules**: If you have any network rules tied to your current SCEPman endpoint, these will need to be updated. ## Migration Path {% stepper %} {% step %} ### Setup space.vars.SCEPmanSAAS\_ProductName Follow our dedicated guide on how to enroll: {% content-ref url="/pages/tywmYoXQzMpzctQVCWnb" %} [🆕 SCEPman SaaS](/configuration/scepman-saas) {% endcontent-ref %} You should be in the following situation after this step: * space.vars.SCEPmanSAAS\_ProductName is enrolled and your devices have received suitable certificates for client authentication to be used with RADIUSaaS (besides the ones issued by your current SCEPman Enterprise deployment). * space.vars.SCEPmanSAAS\_ProductName' CA certificate is trusted by your devices and added to the RADIUSaaS trust store. {% endstep %} {% step %} ### Verify Client Configuration Clients already using RADIUSaaS will require the following adjustments if you want to migrate to space.vars.SCEPmanSAAS\_ProductName : * Ensure they are trusting the space.vars.SCEPmanSAAS\_ProductName Root CA certificate * Adjust the WiFi profile to include (additive to the current SCEPman Enterprise root) the space.vars.SCEPmanSAAS\_ProductName CA certificate for server validation {% hint style="danger" %} **Caution if you have an existing** [**SCEPman Connection**](https://docs.radiusaas.com/admin-portal/settings/settings-server#scepman-connection) If you have already setup the SCEPman connection for automatic server certificate management, space.vars.SCEPmanSAAS\_ProductName will take over the connection after the enrollment. This means the server certificate will be from a different issuer **after the next certificate rotation**. Ensure that your clients have the space.vars.SCEPmanSAAS\_ProductName CA certificate installed and trust the new CA for server validation in the WiFi profile. {% endhint %} {% endstep %} {% step %} ### Verify Authenticator Configuration If you are using RadSec, your RADIUS authenticators (access points, switches, and VPN gateways) will also have to trust the new Root CA certificate to establish a connection to RADIUSaaS. Ensure that the space.vars.SCEPmanSAAS\_ProductName Root CA has been added here to prevent impact during the cutover of the server certificate. {% hint style="danger" %} **Please check if your network equipment handles multiple CAs** If your authenticators are not able to trust multiple CAs for the RadSec server validation, changing the server certificate to one issued by space.vars.SCEPmanSAAS\_ProductName will need to happen at the same time as changing the CA trusted for the RadSec authentication as connections will be failing otherwise. {% endhint %} {% endstep %} {% step %} ### Check for Rules matching Issuer(s) If you are using rules to filter for specific certificate authorities, client authentications might be rejected when using certificates from space.vars.SCEPmanSAAS\_ProductName if the **Any authentication allowed** rule is disabled. Add new rules for the added CA certificate or make sure to modify existing rules to include it:
{% endstep %} {% endstepper %} ## Frequently Asked Questions ### Can I run SCEPman Enterprise and space.vars.SCEPmanSAAS\_ProductName in parallel during the migration phase? Yes. As long as you have trusted both Root CA certificates for client connection in RADIUSaaS, client certificates from both certification authorities can be used for authentication. ### Can I use my existing SCEPman Enterprise Root Certificate for space.vars.SCEPmanSAAS\_ProductName? While technically possible through [Bring your own Key Vault](broken://pages/7X1Zb4WB9Xmw7gDVwJNo#scepman-identity-and-keys), reusing your existing Root CA certificate is not recommended for the following reasons: * Already issued certificates are only stored in the tenant of the existing SCEPman Enterprise deployment while newly created certificates will be stored within space.vars.SCEPmanSAAS\_ProductName. This can lead to failing validations if components are not able to figure out which CA should be considered for validation * Depending on the deployment location of your Key Vault and your RADIUSaaS instance, added latency is expected during cryptographic operations that require the Root CA certificate ### When can I decommission my old SCEPman instance? Once all certificate use cases of the SCEPman Enterprise instance have been migrated to space.vars.SCEPmanSAAS\_ProductName, you can safely stop the app service. These use cases include but are not limited to: * Client Certificates * Server Certificates * DC Certificates * Certificates for TLS inspection * Code Signing Certificates * S/MIME Certificates Make sure to monitor the Log Analytics Workspace long enough to verify that no certificate validation or issuance is happening anymore. {% embed url="" %} # Dashboard ## Login Screen You are presented with the login screen when you open your RADIUSaaS Admin Portal for the first time or when your access token has expired. The login screen provides an easily accessible option to download the CA certificate that has signed your [RADIUS Server Certificate](/admin-portal/settings/settings-server#server-certificates). This feature is particularly useful for bring-your-own-device (BYOD) setups and administrators who need to create network profiles on their devices.
## Service State The RADIUSaaS homepage presents you with an interactive service state that is **updated in** **real-time**. ### Infrastructure When you access the homepage of your RADIUSaaS instance, the Infrastructure tab displays the RADIUSaaS instance's key components, including the RadSec Server and RADIUS proxies. The availability of the individual components is monitored in **real-time** and realized through **actual authentications** (PAP-based) that are periodically performed. By hovering over individual nodes, additional information such as the public IP address and the data center location is shown.
In case, a node is detected to be malfunctioning, the corresponding node along with the unavailable authentication and communication path is highlighted in red:
**Important:** As long as there is at least one green path leading to **Authentications**, the service is generally available. In case you are using RADIUS proxies, ensure that you have followed our architectural [recommendations](/admin-portal/settings/settings-proxy) to decrease the likelihood that a proxy failure leads to an overall outage of the service. The **Service State** icon in addition to a healthy (green) state can indicate one of three error conditions. | Disabled | Removed | Expired / Not Yet Valid | | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | | | | ### Health The Health tab displays the health status of all components relevant to your RADIUSaaS instance, including certificates and the optional SCEPman-aaS module.
## Other controls The RADIUSaaS homepage gives you easy access to frequently used controls and information.
### Notifications You can find notifications (alerts, configuration improvement notifications, important announcements) regarding your service in here.
### Help Click on the life saver button to lodge a support request.
### Dark Mode Click on the User Account button, followed by "Switch to dark/light theme" to toggle between dark and light mode.
### Language The RADIUSaaS Portal is available in German, English, Spanish, French, Japanese and Portuguese.
### Service Documentation A direct link to the RADIUSaaS documentation.
### API Documentation A direct link the RADIUSaaS REST API Swagger documentation.
{% content-ref url="/pages/mXZUFCBt7eW9P2U71bTS" %} [REST API](/other/rest-api) {% endcontent-ref %} # Insights Under the insights group Dashboards and Log views can be found ### Dashboards In your Overview you have a short overview about the status for the logged in users over the day. ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/eHfAMTO6MpuLz3x2SSFI/test.png) ### Authentications Under Authentications you have tables to get an overview on how many times someone has been logged in and an overview about why authentications are failing. ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/9XD2QHcQPs6yvnu0p9NF/image.png) ### Creating Custom Visualisation The clip below shows how you can modify or replace a widget to better suit your needs. For example, the current IPs widget can only display 30 IPs, whereas your environment requires 100. {% hint style="info" %} Please note that the default dashboards (Overview, Authentications, Rule Engine, and Logs) will be reset due to instance maintenance. Therefore, we recommend creating an additional dashboard for your purposes. {% endhint %}
# Rule Engine The rule engine log-interface was made to get easy access to what decisions were made by your Rule Engine with an interactive graph. ## Filter the graph for a certain period ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/eZPY2DY1LBKklt5MAdSO/rule-engine-timeFilter.gif) ## Filter by Rules ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/ccqQMnJDB558VtezmcFG/rule-engine-ruleFilter.gif) ## Filter for everything you can see in the table ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/oRs878w0iplUOSUtcycL/rule-engine-anyFilter.gif) # Logs You can access basically every log that the platform generates. Naturally, this means that you may not be able to understand everything which you can read. You don't have to. If you have any questions, [drop a message](https://www.radius-as-a-service.com/drop-a-question) and we're happy to answer them.
## Log types Log types **not** mentioned in below table are less relevant for common trouble shooting scenarios. | Log Type | Summary | Useful for ... | | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `engine` |

Aggregated and correlated logs that provide key information on every authentication, e.g.

  • Timestamp
  • Authentication duration
  • Identity of the supplicant
  • Credentials used (username/password, certificate)
  • Client authentication certificate used incl. verification type (ocsp or crl) and verification result (valid or revoked)
  • Authentication decision (Accept or Reject)
  • Error message (Rejects only)
  • Applied rule
  • MAC addresses (authenticator / supplicant)
  • Network type (WiFi, LAN, VPN)
  • SSID (for WiFi only)
  • AAA protocol used (radius or radsec)
|

Most troubleshooting scenarios, e.g. debugging

| | `proxy` | Generated by the [RADIUS Proxies](/admin-portal/settings/settings-proxy) (in case at least one is configured) | | | `detail` | Comprehensive (raw) logs generated by the RadSec server(s). They include most EAP messages exchanged between supplicant and RADIUSaaS during authentication ("inner tunnel" messages). |
  • Debugging of issues that go beyond what can be debugged with the engine logs, e.g. checking if authentications are incomplete (Acess-Reject or Access-Accept missing for a particular authentication)

  • Troubleshooting issues with the RadSec connection - if used by your infrastructure

    • Accessing the entire error message stack (found in Access-Reject messages) in case the error message parsed in the engine logs is ambiguous.
| | `radsec` | Comprehensive (raw) logs generated by the RadSec server(s) related to the RadSec connection. |
  • Troubleshooting RadSec connections issues, e.g. trust issues.
  • Identifying certificates presented by the authenticators when establishing RadSec connections.
| # SCEPman SaaS # Status {% hint style="info" %} To use space.vars.SCEPmanSAAS\_ProductName, please ensure to configure it first under **Settings** > [**SCEPman**](broken://pages/7X1Zb4WB9Xmw7gDVwJNo). {% endhint %} The **SCEPman** menu hive gives you access to your SCEPman SaaS instance built right into RADIUSaaS (requires a separate license). The submenus allow you to perform manual certificate tasks leveraging the Certificate Master component. More information on how to **Manage Certificates**, **Request Certificates**, and **Tasks**, can be found in the corresponding SCEPman documentation: {% embed url="" %} ## Status The status page of your space.vars.SCEPmanSAAS\_ProductName instance provides you with the most relevant information that you require when configuring the service for your environment. It allows you to * review the connectivity status to dependencies, such as the Key Vault, Graph API (Intune), or Jamf Pro, * download the public portion of the CA certificate, or * access the SCEP enrolment endpoint(s) that are required for configuration in your MDM system(s).
# Manage Certificates For more information about certificate management in SCEPman Certificate Master, please refer to the SCEPman [Manage Certificates](https://docs.scepman.com/certificate-management/certificate-master/manage-certificates) documentation.
# Request Certificates On this page, you can request and download certificates directly from SCEPman, either by submitting your own CSR or by using one of the predefined certificate types (server, TLS inspection, code signing, device, user). For more details, please refer to [Certificate Master](https://docs.scepman.com/certificate-management/certificate-master)
# Tasks This is a central starting point for manual certificate operations in SCEPman Certificate Master. From here, you can browse issued certificates via Jamf and Intune, as well as revoked certificates, and download or revoke individual ones. You can also jump directly to a certificate request type: Generic CSR, (Web) Server, TLS Inspection, Code Signing, Device, or User.
# Settings The entries below provide a brief overview of the settings available for SCEPman SaaS. They are intentionally kept concise. For full details, refer to the corresponding sections of the [SCEPman documentation](https://docs.scepman.com/)
### Certificate Authority The root certificate for your tenant. Every certificate SCEPman issues chains up to it. It is created once and its subject name cannot be changed afterwards. The root CA itself is valid for 7300 days (20 years).
### Default Certificate Profile The default settings applied to certificates issued through all certificate endpoints. Each source under Certificate endpoints can override these two values with its own profile. Revocation for every certificate this CA issues is configured here as well.
Default Certificate Profile Settings **Default Extended Key Usage** What the certificate may be used for. Server certificates need `ServerAuthentication`; device certificates for 802.1X need `ClientAuthentication`. This is only the fallback in case the request does not contain an EKU. **Validity Period** The maximum number of days that an issued certificate is valid. [Learn more](https://docs.scepman.com/scepman-configuration/application-settings/certificates#appconfig-validityperioddays). **Certificate Revocation List (CRL)** Publishes a signed list of revoked certificates for clients that don't support OCSP. The distribution point is embedded in every certificate issued from the moment you enable it. [Learn more](https://docs.scepman.com/certificate-management/manage-certificates/enabling-crl). **OCSP Authorised Responder** Answers revocation live over OCSP, signed by a dedicated responder certificate. Always enabled for SCEPman SaaS. [Learn more](https://docs.scepman.com/certificate-management/manage-certificates).
### Certificate endpoints Every endpoint is a route a device can request a certificate through. Each one brings its own certificate profile and its own credentials. Switch one on to configure it. {% hint style="warning" %} Enable only the endpoints you actually use. Each enabled endpoint is an additional way to obtain a certificate from your CA. {% endhint %}
#### Microsoft Intune {% hint style="info" %} This endpoint requires the Entra tenant connection to be configured {% endhint %} Checks the device against Intune before issuing. Use this for Intune-managed Windows, iOS, Android and macOS devices. Requires the Entra tenant connection. [Learn more](https://docs.scepman.com/scepman-configuration/application-settings/scep-endpoints/intune-validation).
Microsoft Intune Settings **Validity Period** Overrides the default profile for every certificate issued to an Intune-managed device. **Require the device to be compliant** * Off: any enrolled device gets a certificate. * On: the device must report as compliant in Intune. [Learn more](https://docs.scepman.com/scepman-configuration/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-compliancecheck). **Compliance Grace Period** Shown when the compliance check is on. A window in minutes during which a device counts as compliant even if it has not reported yet. [Learn more](https://docs.scepman.com/scepman-configuration/application-settings/scep-endpoints/intune-validation#appconfig-intunevalidation-compliancegraceperiodminutes). **Where to look the device up** Which directories SCEPman queries to validate the device. [Learn more](https://docs.scepman.com/scepman-configuration/device-directories). Lookup sources, selectable in combination: | Source | Behaviour | | --------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Entra ID device objects** | Matches the request against the device object in Entra ID. Covers Entra-joined devices even when Intune hasn't checked in yet. | | **Intune managed devices** | Matches against the Intune device record. The usual choice for MDM-enrolled devices. | | **Endpoint list** | Matches against Intune's list of issued certificates. | | **Opportunistic match** | Issues the certificate if none of the directories above can be reached or return a result. Keeps enrolment working during an outage — at the cost of the check itself. |
#### Jamf Pro Checks Apple devices against your Jamf Pro inventory before issuing. Needs Jamf API credentials. Make sure to check out the SCEPman Enterprise guide on how to setup SCEPman SaaS with Jamf Pro: {% embed url="" %}
Jamf Pro Settings **Default Extended Key Usage** EKU fallback for certificates issued to Jamf devices. **Validity period** Overrides the default profile for this endpoint. **Jamf API Credentials** Client ID and secret of the Jamf Pro API role. [Learn more](https://docs.scepman.com/certificate-management/jamf/general).
#### Active Directory Kerberos-authenticated enrolment for domain-joined Windows clients, driven entirely by Group Policy. Requires a service principal and keytab in your on-premises domain. [Learn more](https://docs.scepman.com/certificate-management/active-directory). Four certificate templates can be enabled independently, each with its own tab: | Template | Purpose | | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **User** | User certificates for domain users. [Learn more](https://docs.scepman.com/scepman-configuration/application-settings/active-directory/user-template). | | **Computer** | Machine certificates for domain-joined devices, e.g. for 802.1X. [Learn more](https://docs.scepman.com/scepman-configuration/application-settings/active-directory/computer-template). | | **Domain controller** | LDAPS and Kerberos PKINIT certificates for DCs. [Learn more](https://docs.scepman.com/scepman-configuration/application-settings/active-directory/dc-template). | | **RDP** | Certificates for RDP server authentication. [Learn more](https://docs.scepman.com/scepman-configuration/application-settings/active-directory/rdp-template). | Per template:
Template Settings **Default Extended Key Usage** EKU fallback for this template. **Validity Period** Certificate lifetime for this template, in days. **Group Filter (SIDs)** Limits enrolment to members of the given Active Directory groups, specified by SID. Empty means every domain member may enrol. **KSPs** Key storage providers the private key may be created in, e.g. *Microsoft Platform Crypto Provider* (TPM) or *Microsoft Smart Card Key Storage Provider*. Empty means the client chooses.
{% hint style="info" %} Deploying the matching group policy is described in [Group Policy](https://docs.scepman.com/certificate-management/active-directory/group-policy). {% endhint %} #### Domain controller certificates Issues the certificates domain controllers need for LDAPS and Kerberos PKINIT, authenticated with a challenge password instead of Active Directory. Enable only if SCEPman serves your DCs. [Learn more](https://docs.scepman.com/certificate-management/domain-controller-certificates).
Domain Controller Settings **Validity Period** Certificate lifetime in days. **Challenge Password** Used on the domain controller when it requests its certificate.
#### Enrollment REST API Lets your own tooling request certificates over HTTPS instead of SCEP, using Microsoft identities rather than a challenge password. Leave off unless a script or service of yours uses it. [Learn more](https://docs.scepman.com/certificate-management/api-certificates). Requests authenticate with an API token. Manage tokens under **Access & rules → Permissions**. Example: {% code overflow="wrap" %} ```powershell New-SCEPmanCertificate -Url 'contoso.scepman-as-a-service.com' -AccessToken 'IyBJJ2FtIGFuIGFjY2VzcyB0b2tlbi4gIw==' -Subject 'CN=Certificate' ``` {% endcode %}
Enrolment REST API Settings **Default Extended Key Usage** EKU fallback for API-issued certificates. **Validity Period** Certificate lifetime in days.
#### Static Challenge Accepts any request presenting a shared challenge password. Convenient for appliances no MDM can enrol. [Learn more](https://docs.scepman.com/scepman-configuration/application-settings/scep-endpoints/static-validation).
Static Challenge Settings **Default Extended Key Usage** EKU fallback for this endpoint. **Validity Period** Certificate lifetime in days. **Challenge Password** Anyone holding this value can obtain a certificate. Rotate it when someone with access leaves. **Renewals without Challenge** * Off: every renewal must present the challenge password again. * On: a client holding a valid certificate can renew without it.
#### Static challenge + Entra device check (Static-AAD) {% hint style="info" %} This endpoint requires the Entra tenant connection to be configured {% endhint %} As above, but the device must also exist in Entra ID. Prefer this over a plain static challenge whenever the device is Entra-joined. Requires the Entra tenant connection. [Learn more](https://docs.scepman.com/scepman-configuration/application-settings/scep-endpoints/staticaad-validation). Same settings as **Static Challenge**. ### Entra tenant connection {% hint style="info" %} Optional but required for **Intune Validation** and **Static AAD Validation** endpoints. {% endhint %} Controls how SCEPman reads device and user objects from your Entra ID tenant. This is what makes the Intune and Entra validation sources available. While it is disabled, those sources cannot be switched on.
{% tabs %} {% tab title="Admin consent (recommended)" %} Grants our multi-tenant app read access in one consent flow. Fastest path, and we keep the permission set current as SCEPman evolves. Needs a Global Administrator to approve once. Three steps complete the connection: {% stepper %} {% step %} ### **Confirm the tenant** Sign in to Entra ID. We take the tenant from that sign-in and show you which directory it is, so you don't consent in the wrong one. You do not need to consent on behalf of your organization. This consent will add the **SCEPman as a Service (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)** Enterprise Application to your Entra environment. {% endstep %} {% step %} ### **Grant admin consent** Opens the Microsoft consent screen. A Global Administrator must approve; if that isn't you, send them the consent link from this page. This will grant the **SCEPman as a Service** Enterprise Application the required permissions. {% endstep %} {% step %} ### **Test the connection** Reads one device object to prove the permissions work before you rely on them. {% endstep %} {% endstepper %} {% endtab %} {% tab title="Your own app registration" %} Use an app registration you create and control. Choose this when policy forbids third-party multi-tenant apps. Needs tenant ID, client ID and a client secret. Grant the following **application** permissions and admin-consent them: | API | Permission | Purpose | | -------------------- | ----------------------------------------- | -------------------------------- | | Microsoft Graph | `Directory.Read.All` | Read directory data | | Microsoft Graph | `DeviceManagementManagedDevices.Read.All` | Read Intune devices | | Microsoft Graph | `DeviceManagementConfiguration.Read.All` | Read Intune device configuration | | Microsoft Intune API | `scep_challenge_provider` | SCEP challenge validation | | {% endtab %} | | | | {% endtabs %} | | | ### Remote debug Enables detailed request tracing for our support team. It is disabled by default. Because traces may contain device identifiers, tracing automatically switches off on the specified date.
# Connectivity # Server Settings Server settings are available under https\://YOURNAME.radius-as-a-service.com/settings/server ## Ports & IP Addresses ### Overview RADIUSaaS operates a RadSec service to provide secure cloud-based authentication for its users. In addition, for those customers who are unable to utilise RadSec in their network environment, e.g. due to hardware and software limitations, RADIUSaaS provides RADIUS Proxies, that handle the protocol conversion from RADIUS to RadSec. Both RadSec and RADIUS service offer public IP address that enable your network appliances and services to communicate with our service from anywhere via the internet. These services operate on their unique registered ports. ## RadSec / TCP
#### **RadSec DNS** The DNS entry through which the RadSec service can be reached. #### **Server IP Addresses** This is the public IP address of the RadSec service. #### **RadSec Ports** This is the registered port for RadSec: 2083 ### Failover & Redundancy In cases where customers require higher levels of redundancy, multiple RadSec endpoints can be configured for your instance providing an additional IP addresses. Please note that there is an additional cost for this service.
{% hint style="info" %} It is important to note that RADIUSaaS **does NOT provide failover** between RadSec endpoints. Instead, this failover is typically implemented on your network equipment as shown in below example using Meraki. It is recommended to configure your failover scenario using IP addresses rather than DNS for better visibility and less reliance on an additional service (DNS). {% endhint %} In this configuration, the two RadSec IP addresses are listed in order of preference. When Meraki is unable to reach one of the IP addresses, it will typically try two more times and moves on to the next one. For more information regarding the failover capability of your Meraki (or other) system, please consult your own resources.

Showing multiple RadSec servers in order of priority (Meraki).

## RadSec Settings ### Maximum TLS Version This setting controls the maximum TLS version for your **RadSec interface**. The minimum version is fixed at 1.2, the default maximum is set to 1.3. TLS 1.3 offers several advantages over 1.2, including the post-handshake authentication mechanism, which allows requesting additional credentials before completing the handshake. This is important for the verification checks for RadSec certificates setting discussed next. ### Maximum EAP TLS Version This setting controls the maximum TLS version used with EAP when your endpoints authenticate against your RADIUSaaS instance using a certificate (EAP-TLS) or [username/password credentials](/admin-portal/users/users#protocols). For all modern operating systems, **TLS 1.3 is the recommended default**. However, certain (older) Windows 10/11 builds advertised TLS 1.3 support for EAP-TLS with a non-conformant implementation. If Windows clients on affected builds exhibit connectivity issues, cap the negotiated protocol version at TLS 1.2 for broader compatibility. ### Revocation Check for RadSec Certificates {% hint style="info" %} This setting determines whether a revocation check should be performed for all RadSec connections. The method for verifying the revocation check differs slightly from that used for client authentication certificates. {% endhint %} For proper RadSec operation, network devices such as Access Points, Switches, and VPN Servers establish a TLS-protected connection to the RadSec server. RadSec deployments typically use mutual TLS (mTLS), where both peers authenticate each other using X.509 certificates during the TLS handshake. RADIUSaaS implementation enforces mTLS. To determine the validity and revocation status of a RadSec client certificate, the certificate must be presented by the client as part of the TLS authentication process. Only after the certificate is received can revocation checks (for example, via CRL or OCSP) be performed. #### **TLS 1.2** TLS 1.2 supports mutual TLS authentication during the initial handshake using the `CertificateRequest`, `Certificate`, and `CertificateVerify` messages. When client authentication is required and correctly enforced, the RadSec client certificate is presented, validated, and checked for revocation before the TLS session is established and before any RADIUS traffic is exchanged. \ However, TLS 1.2 also permits optional client authentication and supports renegotiation. As a result, some RadSec client implementations may complete the initial handshake without presenting a client certificate. This behavior is implementation-specific and not a limitation of the TLS 1.2 protocol. {% hint style="info" %} To mitigate the above behaviour, the **Revocation Check for RadSec Certificates** setting is deactivated when the maximum TLS version is set to 1.2. Please note you can manually reactive it later. {% endhint %} #### **TLS 1.3** TLS 1.3 provides a more deterministic and streamlined model for mutual TLS authentication. When client authentication is requested, the RadSec client certificate is exchanged as part of the initial handshake and validated before the TLS connection is established.\ This allows the RadSec server to immediately verify the client certificate, including its revocation status, and to fail the handshake if the certificate is invalid or revoked. As a result, TLS 1.3 enables stricter and more predictable enforcement of mutual TLS authentication for RadSec connections. {% hint style="info" %} The **Revocation Check for RadSec Certificates** setting is automatically enabled when the maximum TLS version is set to 1.3. {% endhint %}
## RADIUS / UDP This section is available when you have configured at least on [RADIUS Proxy](/admin-portal/settings/settings-proxy). For each proxy, a separate public IP address is available. The public IP addresses in this section support the RADIUS protocol only and thus listen on ports 1812/1813.
### **Server IP Addresses and Location** {% hint style="warning" %} These IP addresses only listen on [RADIUS](/overview#what-is-radius) over UDP ports 1812/1813. {% endhint %} Geo-location of the RADIUS Proxy/Proxies as well as the respective public IP address(es). ### **Shared Secrets** The shared secret for the respective RADIUS Proxy. By default, all RADIUS Proxies are initialized with the same shared secret.

Showing changing of shared secrets per proxy

### **Ports** This section displays the standard ports for the RADIUS authentication (1812) and RADIUS accounting (1813) services. ### **Failover & Redundancy** #### Proxy Redundancy Note that a single RADIUSaaS Proxy does not provide redundancy. To ensure redundancy, set up multiple RADIUSaaS Proxies as described [here](/admin-portal/settings/settings-proxy#load-balancing). #### RadSec Service Redundancy for Proxies When using RADIUSaaS with multiple RadSec instances, Proxies are automatically configured to connect to all available RadSec instances. A RADIUSaaS Proxy will prioritize connecting to the nearest regional RadSec Service. If that service is unavailable, it will switch to another available RadSec Service. ## Server Certificates ### Customer-CA By default, RADIUSaaS generates a **RADIUS Server Certificate** signed by a Certificate Authority (CA) that is available on our service solely for this very purpose. We refer to it as the **Customer-CA**. The Customer-CA is unique for each customer. To create your Customer-CA, follow these simple steps: 1. Navigate to **Settings** > **Server Settings** 2. Click **Add** 3. Choose **Let RaaS create a CA for you** 4. Click on **Save** 5. After the creation, you will see a new certificate available under Server Certificates
### Bring your own certificate In case you do not want to use the **Customer CA**, you can upload up to two of your own certificates. #### SCEPman-issued server certificate Please follow these steps to leverage SCEPman Certificate Master to generate a new server certificate: 1. Navigate to your SCEPman Certificate Master web portal. 2. Select Request Certificate on the left 3. Select **(Web) Server** at the top 4. Select **Form** 5. Enter all Subject Alternative Names (SANs) that the certificate shall be valid for, separated by commas, semicolons, or line breaks. Generate a server certificate as described [here](https://docs.scepman.com/certificate-deployment/certificate-master/tls-server-certificate-pkcs-12) and provide any FQDN you want. We recommend adapting the SAN of the default server certificate, e.g. `radsec-.radius-as-a-service.com`. 6. Set the **Download file format** to **PEM** 7. Select **Include Certificate Chain** and download the certificate. 8. Make sure to include **both Server and Client Authentication** for the EKU. 9. **Submit** the request to download the new server certificate. {% hint style="warning" %} **Important**: Take temporary note of the password since it cannot be recovered from Certificate Master. {% endhint %}
### Upload the new server certificate to **RADIUSaaS** To add your server certificate created in the above steps, navigate to **RADIUSaaS instance** > **Settings** > **Server Settings** > **Add,** then 1. Choose **PEM or PKCS#12 encoded Certificate** (If you selected PKCS#12 in step 5, this contains both public and private key) 2. Drag & drop your certificate file or click to browse for it 3. Enter the password of your **Private Key** 4. Click **Save**
{% hint style="info" %} Please note: By default, SCEPman Certificate Master issues certificates that are valid for 730 days. If you'd like to change this, please refer to SCEPman's [documentation](https://docs.scepman.com/advanced-configuration/application-settings/certificates#appconfig-validityperioddays). {% endhint %} ### Certificate activation {% hint style="warning" %} Ensure to monitor the expiry of your server certificate and renew it in due time to prevent service interruptions. {% endhint %} As certificates expire from time to time or your preference on which certificates you would like to use change, it is important that you can control the certificate that your server is using. The **Active** column shows you the certificate your server is currently using. To change the certificate your server is using, expand the row of the certificate you would like to choose and click **Activate**. ### Download To download your **Server Certificate,** you have two options: 1. Click **Download CA Certificate** on the top. This will directly download the **trusted root CA** of the currently **active** server certificate. 2. Click the **download** icon in the corresponding row.
**Option 2** will open a dialog showing the complete certificate path. The **root certificate** will always be marked in green.

Showing the root certificate in green

For both options, the downloaded root certificate is encoded in base64 (PEM). In case your device (e.g. WiFi controller) needs a binary coding (DER), you can convert it using [OpenSSL](https://openssl.org/): ```sh openssl x509 -inform pem -in -outform der -out ``` ### Delete To delete a certificate, expand the corresponding row, click **Delete** and confirm your choice. ### Certificate Expiration {% hint style="danger" %} Do not let the RADIUS Server Certificate expire. It will break the authentication. {% endhint %} Certificates expire from time to time. Five months before your certificate is going to expire, your dashboard will give you a hint by displaying a warning sign next to it. ![Screenshot showing certificate expiration](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/vyZwJeKE1HD6XpnxGymy/image.png) If the triangle is displayed next to the active RADIUS Server Certificate, follow this guide to update it: {% content-ref url="/pages/-Me\_4gkoPSj70sBbkQ0G" %} [Server Certificate Renewal](/configuration/renew-certificate) {% endcontent-ref %} # Trusted Certificates ## Types of Trusted Certificates ### Trusted CAs for Client Authentication Trusted CAs for client authentication establish the trust between the CAs that issue client authentication certificates to your endpoint devices and RADIUSaaS. ### Trusted RadSec Connection Certificates RadSec itself works with mutual certificate authentication (mTLS). This means, on the one hand your authenticators must [trust RADIUSaaS](/admin-portal/settings/settings-server#server-certificates) and on the other hand RADIUSaaS must know which authenticators to trust so that a valid RadSec connection can be established. The trusted RadSec connection certificates ensure RADIUSaaS only trusts those authenticators that you specify. ## **Pre-installed trusted RadSec certificate** Due to the [above](/admin-portal/settings/trusted-roots#trusted-radsec-connection-certificates), you will always see at least one RadSec trusted certificate that establishes the trust with your [RADIUS proxies](https://docs-preview.radiusaas.com/admin-portal/settings/settings-proxy) (effectively acting as RadSec clients). To ensure that your proxies are able to start up properly and are able to establish a connection to your instance, you cannot delete it. ## Add {% hint style="warning" %} If you have a tiered PKI infrastructure (e.g. a **Microsoft legacy PKI**), please consider [this](#tiered-pki-hierarchy). {% endhint %} To add a new trusted certificate, follow these steps: 1. Click **Add** 2. Select if you want to import to trusted certificate * from SCEPman (by providing the URL to your SCEPman instance), or * from any other CA (by uploading a PEM or DER-encoded certificate file) 3. Select the [type](#types-of-trusted-certificates) of trusted certificate under **Use for**: * [**Client authentication**](#trusted-cas-for-client-authentication) * [**RadSec**](#trusted-radsec-connection-certificates) * **Both** (helpful if the same CA is issuing your client authentication certificates as well as your RadSec client certificates) 4. Upload the certificate file by drag & drop (alternatively you can click in the blue area and select your file) 5. Select the certificate verification option: * **OCSP Autodetect**: RADIUSaaS will try to infer the OCSP responder URL from the client certificate's Authority Information Access (AIA) extension that is used for the network authentication. In case no OCSP responder URL is found or the OCSP responder is unavailable, RADIUSaaS will consider the [**Soft fail** ](#ocsp-soft-fail)configuration. * **OCSP**: Manually specify which OCSP responder URL will be used for any certificate that was issued by the trusted CA. If the OCSP responder is unavailable, RADIUSaaS will consider the [**Soft fail** ](#ocsp-soft-fail)configuration. * **CRL**: If selected, RADIUSaaS will use a CRL instead of OCSP to verify certificate issued by the CA. Specify the CRL encoding (**DER** or **PEM**) and the **CRL distribution points**. * **None:** If your CA supports neither OCSP nor CRL, select **None** to skip the verification. 6. Click **Save** {% hint style="info" %} In case your PKI has a multi-tier hierarchy (Root CA, Intermediate CA, Issuing CA), make sure to upload all of them to the RADIUSaaS Trusted Certificates store. {% endhint %} ## Delete To delete a certificate, expand the corresponding row, click **Delete** and confirm your choice.

Showing deletion of a trusted certificate

## OCSP Soft-fail This setting determines how RADIUSaaS behaves, when the OCSP responder of your trusted CA cannot be reached. {% hint style="danger" %} If you **disable** this setting, authentication requests will be **rejected** when your CA's OCSP responder cannot be reached. Please check [OCSP Soft-fail Consequences](/other/faqs/ocsp-soft-fail-consequences) to make sure you understand the implications of this setting. {% endhint %} {% hint style="info" %} Note that this setting is only available when **OCSP Autodetect** or **OCSP** is selected for certificate verification. {% endhint %} By default, we **recommend enabling OCSP Soft fail** to increase the availability of the service by allowing authentication requests to be accepted even if the OCSP responder cannot be reached. With this **soft fail** mechanism, and in case OCSP is not reachable, RADIUSaaS will only check if the incoming certificate was signed by one of the [trusted CAs](/admin-portal/settings/trusted-roots) and processes any optional [Rules](/admin-portal/access-and-rules/rules).
## Tiered PKI hierarchy In a tiered CA environment with multiple issuing CAs configured, certificates issued from the root CA or any issuing CA will get access regardless of whether the certificate was issued from the root or issuing CA. This means that trusting the root will automatically trust certificates issued by any of the issuing CAs. \ \ If access needs to be controlled based on the issuing CAs, this can be achieved by configuring [respective rules](/admin-portal/access-and-rules/rules#certificate-based-authentication). ### Considerations When uploading root and issuing CAs of a tiered PKI, please consider the following: * The **root CA must be uploaded first**, before uploading any issuing CAs derived from this root CA. * Root and issuing CAs must be uploaded in separate files. Uploading certificate chains from a single file may result in unexpected behaviour. ## Optional settings ### Intune ID It is possible to use the certificate which every Windows 10 machine receives from Intune when joining Microsoft Entra ID (Azure AD). {% hint style="danger" %} This setting is optional. In case you are not familiar with Intune Certificates, please do not configure them! {% endhint %} #### Why are we not recommending using Intune certificates for authentication purposes? * Intune certificates are not supported by Microsoft for other purposes than management with Intune. * Validity time for the Intune certificates is 1 year. * There is no mechanism to revoke certificates (like OCSP). Instead of using Intune certificates, we recommend using certificates from a PKI like [SCEPman](https://scepman.com/). #### Configure Intune IDs {% hint style="danger" %} Use this setting with care. One of the following IDs **must** exist in the certificate extension 1.2.840.113556.5.14. All other certificates will **be rejected**. {% endhint %} To get your Intune Tenant ID, follow these steps: * Press **Windows + R** and enter **certlm.msc** * Go to your personal certificates. There will be a certificate from one of the following issuers * SC Online Issuing * MDM Device Authority * Open this certificate, go to **Details** and search for the extension 1.2.840.113556.5.14 * The printed HEX value is your Intune Tenant ID. **Example:** The Tenant ID of the following certificate is: **bb4397cb6891c64db17f766487518a6a** ![Showing Certificate](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/idPvrWmWOtjQuz2my7Yj/image.png) ## XML {% hint style="info" %} The XML profile generated by RADIUSaaS will enable [PMK caching](/profile-deployment/microsoft-intune/wifi-profile/windows#fast-roaming). {% endhint %} Today, most MDM platforms provide a wizard-based method to deploy networking profiles (WiFi and LAN). If this is not possible, or if the wizard provides only limited configuration options, you may generate a raw-XML profile directly on the RADIUSaaS platform. * To generate your **WiFi** XML profile: 1. Expand the **XML** menu, 2. select the desired security protocol (WPA2 or WPA3), 3. enter your **SSID,** 4. and click **Download**. * To generate your **Wired** XML profile, click **Download**.
# Proxy Settings Proxy settings are available under https\://YOURNAME.radius-as-a-service.com/settings/proxy Proxies are required when your authenticators (e.g., access points, switches) support only traditional RADIUS over UDP for AAA. The proxies handle protocol conversion from RADIUS to RadSec, enabling your equipment to communicate securely with the RADIUSaaS core servers, which support only RadSec (RADIUS over TCP) for AAA. ## Architecture {% hint style="warning" %} Your subscription includes at least two public IP addresses capable of communicating via RADIUS. We strongly recommend configuring these IP addresses as the primary and secondary RADIUS servers on your network devices and appliances. For optimal redundancy, the secondary IP should be located in a different geographic region from the primary. {% endhint %} ### Performance Each proxy can handle up to **1,500** **concurrent** connections flawlessly. This corresponds to a time-based performance of **10,000 authentications per minute per proxy**. ### Scaling To ensure smooth operation, consider the following number of proxies based on the number of users you have licensed (your needs may change if your offices are more globally distributed): | User | Proxy Count | | :--------------: | :---------: | | 50 - 2,500 | 2 | | 2,501 - 10,000 | 3 | | 10,001 - 25,000 | 4 | | 25,001 - 50,000 | 6 | | 50,001 - 100,000 | 10 | ### Regions You can deploy the proxy servers in the following regions: | Continent | Region | | ------------- | ------------------------------------------------------------------- | | Africa | Johannesburg | | Asia |

Bangalore
Singapore
TelAviv
Tokio
Seoul
Osaka

| | Australia |

Sydney
Melbourne

| | Europe |

Frankfurt
London
Madrid
Stockholm

| | North America |

Dallas
New York
Seattle
Toronto

| | South America |

Santiago
São Paulo

| ### Load Balancing If you have a setup with more than 1,000 users, we highly recommend ensuring, that your network equipment will send equal amounts of authentications to each proxy. For network equipment, where you can define the priority of the RADIUS servers, you can ensure load-balancing by defining different priority orders for your different network equipment instances. **Example:** You have 5 WiFi controllers and 3 RADIUS Proxies. You may then configure the following priority orders in your WiFi controllers:
WiFi Controller #RADIUS Priority Order
1 and 41, 2, 3
2 and 52, 3, 1
33, 1, 2
### Failover When [multiple RadSec endpoints](/admin-portal/settings/settings-server#failover-and-redundancy) are configured, RADIUSaaS provides an automatic failover mechanism for your RADIUS proxies. In the unlikely event that one or more RadSec endpoints fail, the available proxies will detect the failed state and redirect requests to the (geographically) closest active RadSec endpoint. {% hint style="info" %} Please note that this failover does not apply if the RadSec protocol is being used by the Authenticators rather than RADIUS. In that case, failover is provided by the Authenticator as described [here](https://docs.radiusaas.com/admin-portal/settings/settings-server#failover-and-redundancy). {% endhint %} ### Properties The IP address, ports and shared secret of the RADIUS Proxies will be displayed under [**Server Settings**](/admin-portal/settings/settings-server) **>** [**Ports and IP Addresses**](/admin-portal/settings/settings-server#properties-1). ## Add To Add a new proxy, simply click **Add**, choose your **Region** and click **Create.**

Showing how to create a proxy

\ After the installation has finished, it can take up to 15 minutes until your proxy has established a connection to your RADIUS server.

Showing proxy servers

## Delete To **Delete** a proxy, simply click **Delete** of corresponding table row and confirm your choice.

Showing deletion of a proxy server

# SCEPman Connection ### SCEPman Connection {% hint style="warning" %} SCEPman Enterprise Edition only Applicable to version 3.0 and above {% endhint %} The **SCEPman Connection** setting connects your RADIUSaaS instance directly to your SCEPman instance so that the RADIUS Server Certificate is issued and renewed automatically. Once the connection is established, RADIUSaaS will: 1. Create and activate a new Server Certificate issued by SCEPman. 2. Manage the lifecycle of that certificate, including its renewal. This setting is **optional**. If you do not connect a SCEPman instance, you can continue to use the Customer-CA or upload your own certificate as described [here](/admin-portal/settings/settings-server#server-certificates). The status badge next to the section title shows the current state of the integration: **NOT CONNECTED** until the setup is completed, **CONNECTED** afterwards. If you do not have a SCEPman instance yet, use the **Set up SCEPman** link to open the SCEPman deployment documentation.
#### Overview of the setup The setup consists of three steps, summarized at the top of the section: | # | Step | Description | | - | -------------------------------- | ------------------------------------------------------------------------------- | | 1 | **Copy this token into SCEPman** | Trust this token by adding it to SCEPman's environment variables. | | 2 | **Enter your SCEPman URL** | The base URL of your SCEPman instance. | | 3 | **Pregenerate a certificate** | Optional: verify that SCEPman issues a certificate before you finish the setup. | #### 1. Token The **Token** field contains the API token that RADIUSaaS uses to authenticate against your SCEPman instance. The token is generated by RADIUSaaS and shown masked by default. * Click the **eye** icon to reveal the token. * Click the **copy** icon to copy it to your clipboard. {% hint style="info" %} The token is read-only. It cannot be set or changed in the RADIUSaaS Admin Portal — you only enter it on the SCEPman side. {% endhint %} Transfer the token to SCEPman by creating the application setting [AppConfig:RADIUSaaSValidation:Token](https://docs.scepman.com/scepman-configuration/application-settings/scep-endpoints/radiusaas) in your SCEPman App Service, as described in [this guide](https://docs.scepman.com/scepman-configuration/application-settings#convenient-configuration-in-the-app-service-configuration). We recommend storing the value as a secret in Azure Key Vault using the name `AppConfig--RADIUSaaSValidation--Token`. Apply the settings and restart your App Service afterwards. #### 2. SCEPman URL Enter the base URL of your SCEPman instance, for example `https://.azurewebsites.net`. The **Connect** button stays disabled until a URL has been entered. #### 3. Pregenerate a certificate (optional) Before finishing the setup, you can let RADIUSaaS request a test certificate from SCEPman. This confirms that the token and the URL are correct and that SCEPman is able to issue a certificate. The pregenerated certificate is added to your Server Certificates but is **not activated**.
#### Connect Click **Connect** to establish the connection. {% hint style="warning" %} This action deactivates the currently active server certificate so that the newly issued certificate can be managed by RADIUSaaS. Ensure that your clients and RadSec-enabled authenticators trust the SCEPman Root CA before you connect, otherwise authentication will fail. {% endhint %} After a successful setup, the status changes to **CONNECTED,** and two additional actions become available: * **Rotate Certificate:** rotates and activates your server certificate. * **Delete Connection:** removes the configured connection. This also deletes the token and cannot be undone. To set up the connection again later, you must repeat the steps above. **Note:** A new token will be automatically created after deleting the connection. # Log Exporter The Log Exporter allows you to push RADIUSaaS Logs to an external Security information and event management (SIEM) system for monitoring and alerting. ## General Logs will be **fetched every 60 seconds** and sent to your configured **Export Target(s)**. Currently, the Log Exporter can connect to the following target systems: * [Microsoft Teams Channel](/admin-portal/settings/log-exporter/teams) * [Azure Log Analytics Workspace](/admin-portal/settings/log-exporter/log-analytics) * [Generic Webhook (JSON)](/admin-portal/settings/log-exporter/generic-webhook) The Log Exporter allows you to configure a specific **Message Filter** for each target. For example: * Send every entry where a user was not able to login to a **Log Analytics Workspace** * Send every failed TCP connection to a **Microsoft Teams Channel** ## Message Filter The **Message Filter** that can be configured for each target helps you to only receive those logs, that are really relevant for your monitoring and alerting system.
The filter can be configured to only consider logs from certain sources/sub-system from the RADIUSaaS platform: * Rule Engine * Authorization System * Proxy Authentication Furthermore, the log level can be configured for each of those sub-systems. If you are familiar with reading the RADIUSaaS' [raw log data](/admin-portal/insights/log) and have already identified a set of messages that are of interest for you, you can very easily derive from those messages the suitable filter settings for export. Therefore, below table provides a mapping from the log message origin (sub-system) to the `tags` property as well as from the log level to the `level` property of each log message. | Filter | Tag | Level | | -------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------- | | Rule Engine | `engine` |

Success = INFO
Failed = WARNING
Error = ERROR

| | Authorization System | `detail` |

Requests = debug
Success = info
Failed = warning
Error = error

| | Proxy Authentication | `proxy` |

Connections = debug
Success = info
Failed = warning
Error = error

|
## Message No matter which target type(s) you have selected, you will have to edit the data template describing how the export message should be structured using **Jinja2** as template engine:\ The Log Exporter has access to every field in a log message that is hierarchically located under the`_source` property. It is made available through the `data` object in the **Message** editor.
# Teams ## Prerequisites To ingest RADIUSaaS logs into a **Microsoft Teams Channel**, only Microsoft Teams itself as well as privileges to add **connectors** to the relevant **channel** are required. ## Configuration steps Follow those steps to push RADIUSaaS logs to a **Microsoft Teams Channel**: 1. Navigate to **Microsoft Teams** 2. Click on the **Channel** > **More options** > **Manage team**
3. Go to **Apps** 4. Click **+ Get more apps**
5. Search for "**Incoming Webhook**" 6. Click **Add** then **Add to a team**
7. Select your team 8. Click **Set up a connector**
9. Provide a **Name** for the connector 10. Upload a logo 11. Click **Create** to generate the **Webhook Connector URL**
{% hint style="warning" %} Make sure you copy the Url. {% endhint %} Now it is time to configure the export target in the Log Exporter. * Navigate to your **RADIUSaaS Admin Portal > Log Exporter** * Click **+ Add** > **Teams** * Provide a **Name** and **Description** * Configure the **Message Filters** to your needs * Paste the **Webhook Connector URL** in the field **Teams channel Webhook URL** * Configure the **Message** to be sent to your Microsoft Teams Channel
# Log Analytics ## Prerequisites To ingest RADIUSaaS logs into an **Azure Log Analytics Workspace**, please make sure that a workspace was already created and that you have the following **required values** available: * Customer ID * Shared Key * Event Name ## Configuration steps Follow these steps to add a **Log Analytics** export target: * Navigate to your **RADIUSaaS Admin Portal** * Click **+ Export Target** * Select **Azure Loganalytics Exporter** * Provide a **Name** and **Description** * Configure the **Message Filters** to your needs * Structure the **Data** to be ingested into your Log Analytics Workspace {% hint style="warning" %} Some data which you might send to your Log Analytics workspace will include new line characters. \ To get a valid JSON for every entry, the template engine has a global **tojson** **parser** which will apply for all variables you access. Therefore, **do not quote any jinja variable**. {% endhint %} **Correct** ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/uq6Vayq4Wd4RpxGmp27v/image.png) **Wrong** ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/5Ls36VIs0q8sUjHGDyra/image.png) # Generic Webhook ## Prerequisites To ingest RADIUSaaS logs into a generic **webhook** that accepts **JSON-structured HTTP bodies**, a suitable webhook including a **publicly available URL** are required as well as **authentication credentials,** if applicable. The RADIUSaaS Log Exporter allows authentication via a **static API key** (URL-, header-, or body-encoded). ## Configuration steps Follow these steps to add a **Generic Webhook** export target: * Navigate to your **RADIUSaaS Admin Portal** * Click **+ Export Target** * Select **Generic Webhook** * Provide a **Name** and **Description** * Configure the **Message Filters** to your needs * Paste your webhook URL in the field **Webhook URL** * Specify the **HTTP method** that shall be used for transmitting the data (POST, GET, PUT) * Add relevant **HTTP headers**, e.g. for authentication purposes * Configure the message **Body** to be sent to your webhook
# Examples This page provides some real world scenarios giving you guidance on how to configure the Log Exporter for your scenario. ## Example 1: General authentication information ### Scope and assumptions The scope of the query provided below is as follows: * the admin is interested in understanding which users/devices are authenticating (accepted or rejected) and to built frequency statistics based on that * no VLAN tagging is used * only certificate-based authentication is used (no username-password-based authentication) ### Target [Log Analytics](/admin-portal/settings/log-exporter/log-analytics) or [General Webhook](/admin-portal/settings/log-exporter/generic-webhook) ### Message Filter configuration #### Rule Engine | Log Level | Enabled | | --------- | ------------------------------------- | | Success | False | | Failed | False | | Error | False | #### Authorization System | Log Level | Enabled | | --------- | -------------------------------------- | | Requests | False | | Success | True | | Failed | True | | Error | False | #### Proxy Authentication | Log Level | Enabled | | ----------- | ------------------------------------- | | Connections | False | | Success | False | | Failed | False | | Error | False | ### Data Configuration {% code lineNumbers="true" %} ```json { "Decision": {{ data.get("Packet-Type") }}, "Level": {{ data.level }}, "IP": {{ data.get("Packet-Dst-Address") }}, "Username": {{ data.get("User-Name") }}, {% if data.get("TLS-OCSP-Cert-Valid") != None %} "OCSPStatus": {{ data.get("TLS-OCSP-Cert-Valid") }}, {% endif %} {% if data.level == "warning" %} "FailReason": {{ data.get("Module-Failure-Message") }}, {% endif %} "Datetime" : {{ data.Datetime }} } ``` {% endcode %} ## Example 2: Detailed authentication information ### Scope and assumptions The scope of the query provided below is as follows: * the admin is interested in understanding which users/devices are authenticating via certificate or username & password (accepted or rejected) * username and certificate details with OCSP response * SSID and used Access Point (MAC address) * RADIUSaaS [Rule](/admin-portal/access-and-rules/rules) that was triggered, if applicable: assigned VLAN * correlation ID for further investigation ### Target [Log Analytics](/admin-portal/settings/log-exporter/log-analytics) or [General Webhook](/admin-portal/settings/log-exporter/generic-webhook) ### Message Filter Configuration #### Rule Engine | Log Level | Enabled | | --------- | -------------------------------------- | | Success | True | | Failed | True | | Error | False | #### Authorization System | Log Level | Enabled | | --------- | ------------------------------------- | | Requests | False | | Success | False | | Failed | False | | Error | False | #### Proxy Authentication | Log Level | Enabled | | ----------- | ------------------------------------- | | Connections | False | | Success | False | | Failed | False | | Error | False | ### Data configuration {% code lineNumbers="true" %} ```json { "Decision": {{ data.get("Engine-Decision") }}, "Datetime" : {{ data.Datetime }}, "Level": {{ data.level }}, "Authtype": {{ data.get("Authtype") }}, "Client-MAC": {{ data.get("Client-MAC") }}, "Username": {{ data.get("User-Name") }}, "Applied-Rule": {{ data.get("Applied-Rule") }}, "VLAN": {{ data.get("Assigned-VLAN", "No VLAN assigned") }}, "Auth-Source-Type": {{ data.get("Auth-Source-Type") }}, {% if data.get("Auth-Source-Type") == "WiFi" %} "SSID": {{ data.get("SSID") }}, "AP-MAC": {{ data.get("AP-MAC") }}, {% endif %} {% if data.get("Authtype") == "Certificate" %} "Certificate-CommonName": {{ data.get("Certificate-Details", {}).get("TLS-Cert-Common-Name") }}, "Certificate-Serial": {{ data.get("Certificate-Details", {}).get("TLS-Client-Cert-Serial") }}, {% endif %} {% if data.get("Verify-Result") != None %} "Verify-Result": {{ data.get("Verify-Result") }}, "Verify-Status": {{ data.get("Verify-Status") }}, "Verify-Type": {{ data.get("Verify-Type") }}, "Verify-Description": {{ data.get("Verify-Description") }}, {% endif %} {% if data.get("Reject-Description") != None %} "Reject-Description": {{ data.get("Reject-Description") }}, {% endif %} "GKG-Correlation-Id": {{ data.get("GKG-Correlation-Id") }} } ``` {% endcode %} ## Example 3: General error notifications ### Scope and assumptions The scope of the query provided below is as follows: * the admin is interested in receiving pro-active notifications about errors on the RADIUSaaS platform for the operations team. ### Target [Teams](/admin-portal/settings/log-exporter/teams), or [Log Analytics](/admin-portal/settings/log-exporter/log-analytics) or [General Webhook](/admin-portal/settings/log-exporter/generic-webhook) ### Message Filter Configuration #### Rule Engine | Log Level | Enabled | | --------- | ------------------------------------- | | Success | False | | Failed | False | | Error | False | #### Authorization System | Log Level | Enabled | | --------- | -------------------------------------- | | Requests | False | | Success | False | | Failed | False | | Error | True | #### Proxy Authentication | Log Level | Enabled | | ----------- | -------------------------------------- | | Connections | False | | Success | False | | Failed | False | | Error | True | ### Data configuration #### Teams {% code lineNumbers="true" %} ``` The RADIUS system has issues! Message: {{ data.get('message') }} Raw data: {{ data }} ``` {% endcode %} #### Log Analytics or General Webhook {% code lineNumbers="true" %} ``` { "Message": {{ data.get("message") }}, "Datetime" : {{ data.get("Datetime") }}, "Level": {{ data.get("level") }}, "Type": {{ data.get("type", "not applicable") }} } ``` {% endcode %} # Access & Rules # Permissions Permissions and RADIUSaaS REST API access tokens can be managed under https\://YOURNAME.radius-as-a-service.com/settings/permissions ## Overview The **Permissions** menu allows you to control access to the RADIUSaaS Admin Portal and the RADIUSaaS REST API. {% hint style="success" %} RADIUSaaS supports multiple IDPs for the authentication when logging on to the RADIUSaaS Admin Portal. RADIUSaaS does not store or manage its own administrator identities. Therefore, administrators enjoy the comfort of working with their own identities and do not have to setup additional accounts. {% endhint %}
{% hint style="info" %} Changes to the role assignments and invalidating user tokens only become effective after clicking on **Save**. {% endhint %} ## Supported IDPs Under **Allowed Authentication Providers** any (including multiple) of the IDPs RADIUSaaS supports can be enabled: * Apple (Apple ID) * DigitalOcean (User Email Address) * Entra ID (User Principal Name) * Google (Primary Email Address) Furthermore, under **Custom OICD Provider** you may configure your own OpenID Connect providers to leverage other IDPs, e.g. Okta or sovereign Azure clouds (GCC, GCC High, ...). ## Roles ### Administrators Identities or accounts entered here can access the RADIUSaaS Admin Portal with **full read and write permissions** on the service. These permissions include: * View [dashboards and Logs](/admin-portal/insights) * View, add, change, delete [Users](/admin-portal/users/users) * View, add, change, delete [RADIUS server certificates](/admin-portal/settings/settings-server#server-certificates) and [trusted certificates](/admin-portal/settings/trusted-roots) for client authentication and RadSec * View, add, delete [Proxies](/admin-portal/settings/settings-proxy) * View and change others settings including permissions * Manage [RADIUSaaS REST API Access Token](#access-tokens) * Access to all [API endpoints](/other/rest-api) and CRUD operations ### Viewers Identities or accounts entered here can access the RADIUSaaS Admin Portal with **full read permissions** on the service. These permissions include: * View [dashboards and Logs](/admin-portal/insights) * View [Users](/admin-portal/users/users) * View, add, change, delete [RADIUS server certificates](/admin-portal/settings/settings-server#server-certificates) and [trusted certificates](/admin-portal/settings/trusted-roots) for client authentication and RadSec * View [Proxies](/admin-portal/settings/settings-proxy) * View others settings (permission cannot be viewed) * Access to all [API endpoints](/other/rest-api) - **limited to read operations** ### Users Identities or accounts entered here **cannot** access the RADIUSaaS Admin Portal, however, they can access the [**My Invited Users**](/admin-portal/my-invited-users) portal, where they are able to create [Users](/admin-portal/users/users) for BYOD or guest access. ### Invalidate user tokens During authentication to the RADIUSaaS Admin Portal, each permitted identity obtains an access (bearer) token that is cached in the browser's cookie store. The lifetime of the token is 30 days. Furthermore, RADIUSaaS has permission to refresh these access tokens. In a security event, RADIUSaaS Administrators can **invalidate all previously issued access tokens** by setting the minimum issuance date to now.
## Technical Contacts {% hint style="info" %} Please note that this feature is in preparation for a notification feature in a future release of RADIUSaaS. {% endhint %} Add up to 5 technical contacts to receive e-mail notifications related to your instance. You can select the event level for each contact.
Event levelExample events
InfoScheduled updates to your instance.
WarningA certificate is about to expire, or an ISP is experiencing issues that could impact your instance.
CriticalInterruption to your instance.
## Access Tokens Access tokens are required to authenticate calls to the [RADIUSaaS REST API](/other/rest-api).
### Add Follow these steps to create a new access token: 1. Click on **Add** 2. Provide a meaningful **Name** for the access token 3. Set the permission level by selecting a [**Role**](#roles) 4. Select the lifetime of the access token 5. Click on **Create**\ ![](https://1222554226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSWU1DQ4UGkqER7uGNUOm%2Fuploads%2Fs4fakstavtZVWVgMVH1K%2Fimage.png?alt=media\&token=5877ff38-7f1c-474a-bdf9-aeab763b49c7)
6. Copy the access token to the clipboard and store it at a secure location.\ ![](https://1222554226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSWU1DQ4UGkqER7uGNUOm%2Fuploads%2F42kTjdesW5amEcScFa7C%2FScreenshot_2024-05-23_at_18_46_08.jpg?alt=media\&token=d7c71247-eccb-47f1-821f-0ccb1bde55ec) 7. Click on **Close** ### **Delete** To delete an access token, locate it in the table and click on the bin icon:
## Permissions consent Choose from different identity providers to be able to log into your portal. {% tabs %} {% tab title="Entra ID" %} Microsoft Entra ID (Azure AD) accounts that log on to the RADIUSaaS Admin Portal for the first time must grant RADIUSaaS a limited set of [permissions in their Azure tenant](https://docs.radiusaas.com/admin-portal/access-and-rules/pages/xWuAAd4GID6bXIOu9mQw#id-5.-which-tenant-permissions-do-users-accessing-the-radiusaas-web-portal-have-to-consent-to). There are two alternative ways to provide consent: * **User Consent**\ Each user accepts the consent upon first login to the portal. * **Admin Consent**\ An administrator can consent on behalf of the organization for all users. ### User consent If no consent has been given on behalf of the organization before by an admin, a user will see a permission request dialogue:
Users can review or revoke this consent in Microsoft [My Apps](< https://myapps.microsoft.com>).
Administrators can review & revoke user consents in the Azure Portal (**Microsoft Entra ID** > **Enterprise Applications** > **RADIUS as a Service**):
### Admin consent Rather than requiring consent from each user, administrators can grant consent for all users on behalf of the organization, when logging in the RADIUSaaS web portal for the first time:
Alternatively, administrators can grant the consent on behalf of the organization in the Azure portal (**Microsoft Entra ID** > **Enterprise Applications** > **RADIUS as a Service**). In Azure Portal, administrators can also review or revoke the consent:
{% endtab %} {% tab title="Apple" %} When using an Apple ID to log into RADIUSaaS, make sure to **not hide** your email address.
{% hint style="warning" %} If you chose to hide your email in this dialog you will not be able to log into your portal. You will then need to remove the RADIUSaaS app on **account.apple.com** in the **Sign in with Apple** section {% endhint %} {% endtab %} {% tab title="Digital Ocean" %} Digital Ocean will require you to authorize the application on a team to be able to login:
{% endtab %} {% tab title="Google" %} Google will require you to allow the application to access limited data on your account.
{% endtab %} {% tab title="Custom OIDC Provider (Okta)" %} The specific information you need to provide for the custom OIDC provider depends on the identity provider you choose. The following **example** is based on **Okta**.
In the Okta admin console, you will need to create a new app integration with the following details: | Sign-in method | OIDC - OpenID Connect | | -------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Application Type | Web Application | | Sign-in redirect URI |

Provided in RADIUSaaS dialogue above
Example:

| Make sure to assign the integration to the intended user group and save. You can now retrieve the required information from this application to enter in RADIUSaaS: The **Display Name** can be chosen freely and will be shown during login. With Okta, the **Authentication URL** is in the following form: `https://`**`{YourOrga}`**`.okta.com/oauth2/v1/authorize` The Token URL is also constructed and looks like this: `https://`**`{YourOrga}`**`.okta.com/oauth2/v1/token` The **Client ID** and **Client Secret** can be copied and created in the application itself:
For the **Client Scope** `openid email` is required. This will tell Okta that we are using an OpenID authentication and need to read the logged in users email address. After saving and allowing this provider, you should be able to use it to authenticate from the login page:
{% endtab %} {% tab title="Custom OIDC Provider (Entra ID)" %} If required in certain scenarios (e.g. **GCC High** tenants), you can also use a self-created Entra ID app registration to authenticate to your RADIUSaaS portal. #### Preparation Before creating the app registration, make sure to copy the redirect URL from the **Permissions** section of your RADIUSaaS portal. You can find the URL in the top of the **Custom OIDC Provider** editing dialogue:
Click on the Edit button to find the redirect URL
Copy the redirect URL from the dialogues header
### Create App Registration In Entra ID, navigate to **App Registrations** and create a new registration:
Select a descriptive **Name** for the registration and add the redirect URI that you have copied from the previous step as **Web** type. #### Add API Permissions In the created registration, navigate to **API permissions** and add `email` and `openid` from Microsoft Graph as **Delegated** permissions. Also make sure to grant admin consent for your tenant:
#### Add Client Secret To allow RADIUSaaS to use this registration, create a client secret in the **Certificates & Secrets** section of the registration. Copy the value of the secret for later.
#### Note Registration Details You will later need the registrations **Client ID** and some URLs specific to your tenant. You can find these in the Overview page of the registration:
#### Assign Users For anyone to be able to use this app registration for sign-ins, make sure to add them in the managed enterprise application. You can find this in Entra ID in **Enterprise Applications** having the same name as your app registration. There is also a link to this in the overview of the app registration.
Assign users to allow them to use the application
### Configure the OIDC Provider in RADIUSaaS Back in the RADIUSaaS portal, navigate to the Permissions section and edit the custom OIDC provider and fill in the required information:
| Field | Explanation | | ------------------ | --------------------------------------------------------------------------------------- | | Display Name | This name will be shown on the login page | | Authentication URL | `OAuth 2.0 authorization endpoint (v2)` from the registrations endpoints | | Token URL | `OAuth 2.0 token endpoint (v2)` from the registrations endpoints | | Client ID | The client ID of the app registration. Can be found on its overview page | | Client Secret | The previously created client secret | | Client Scope | Defines the information requested during the authentication. Enter `openid email` here. | After saving the configuration make sure to allow the custom provider and add some users for this provider. You should now be able to use the provider to log into your RADIUSaaS portal:
{% hint style="warning" %} It might be necessary for an Entra administrator to initially use this login to consent again for their tenant. This only needs to be done once. {% endhint %} {% endtab %} {% endtabs %} # Rules This is the documentation of the RADIUSaaS Rule Engine, which allows you to add another layer of security by defining rules that further restrict network access requests or by assigning VLAN IDs. ## General The Rule Engine is a second layer of security that sits behind credential authentication. Once a device or user presents a valid **certificate** (checked against your **Trusted Roots**) or a valid **Username/Password** pair, the Rule Engine decides whether that specific request is actually allowed onto the network, and what it receives in return, such as a VLAN ID or additional RADIUS attributes. ### Default rule To avoid disruption of any existing instance or in case you do not want to use the Rule Engine at all, any authentication is allowed if no rule is defined by default. This is realized through our default rule **Any authentication allowed**. {% hint style="warning" %} The default rule **Any authentication allowed** still requires the presence of valid authentication credentials for a successful network authentication. {% endhint %} ### Order of rule execution Every incoming request is checked against your enabled rules from top to bottom. The first rule whose **medium**, **authentication method** and **filters** all match the request wins, and decides the outcome. Rules positioned below that match are never evaluated for that request. If you have multiple rules configured, they will be applied in the order you see in your web portal - from top to bottom. The only exception is the **Any authentication allowed** rule, that will be handled as last step in case it is configured. This is especially helpful during a ramp-in scenario, where you might not be certain that your rules cover all use-cases or locations. All authentication request rejected by the prior rules will then still be accepted by the default rule. In the dashboard you are then able to observe the devices/users failing for all other rules and correct/extend the rules accordingly. In case you end up having a large number of rules, we recommend - for the sake of maintaining high performance - to order the rules in a way that the most likely rules are hit first. ## More Information Find more details on the rules and how to use them in the following pages: {% content-ref url="/pages/c4M1f9uiuAyD5RqWmtnG" %} [General Structure](/admin-portal/access-and-rules/rules/general-structure) {% endcontent-ref %} {% content-ref url="/pages/Z7cPtVJJOK1Xtn9V5Pqk" %} [Groups](/admin-portal/access-and-rules/rules/groups) {% endcontent-ref %} {% content-ref url="/pages/fCFu0Mb5hbAe21eqB7p6" %} [Certificate Extensions](/admin-portal/access-and-rules/rules/certificate-extensions) {% endcontent-ref %} {% content-ref url="/pages/nr8htn2giI38d0uKa82w" %} [Attribute Catalogue](/admin-portal/access-and-rules/rules/attribute-catalogue) {% endcontent-ref %} # General Structure Rules allow further restrictions
## Rule Collection {% hint style="info" %} We recommend providing descriptive names for your rules, as this will allow them to be clearly identifiable in the Insight [Logs](/admin-portal/insights/log). {% endhint %} Every Rule can have a **Name, Description** and is specified for a specific authentication type.\ Currently you can define a rule for **Wi-Fi**, **LAN** and **VPN**. Furthermore, you can **Enable** or **Disable** each rule. The Rules tab lists every configured rule, its position, its type (Wi-Fi, LAN, VPN or Generic Allow), its **name** and **description**, the **authentication method** it accepts, the **filters** it applies to, what it **grants**, and whether it is enabled. ## Creating a Rule Clicking **Add rule** lets you pick a medium: Generic Allow, Wi-Fi, LAN, or VPN. Choosing **Wi-Fi**, **LAN** or **VPN** opens a guided four-step wizard. A live "in plain words" summary at the bottom of the dialog rephrases the rule in plain language as it is built, for example: > **IN PLAIN WORDS** > > A Wi-Fi request authenticating with certificate only from CN=SCEPman-SaaS-CA,O=Contoso matching Cert Subject (DN) matches OU=Printers is granted VLAN 16 (static). The following steps show the rule editor with a simple example of the above description: {% stepper %} {% step %} ### Identity Just a **Name**, an optional **Description**, and an enable/disable toggle. The medium and authentication method are configured in later steps, so the name only needs to describe intent, e.g. "Corporate Wi-Fi Access" rather than encoding the SSID or VLAN into the name.
{% endstep %} {% step %} ### Who may authenticate (Authentication Methods) Turn on Certificate-based and/or Username/Password-based authentication; at least one must be enabled. Enabling certificates reveals an optional **Restrict root certificates** toggle, which narrows the rule down to specific Trusted Roots instead of accepting any certificate trusted by the platform.
{% endstep %} {% step %} ### Where it applies (Filters) Filters narrow the rule down and are combined with AND, meaning a request must satisfy every filter listed; leaving this step empty means the rule applies everywhere. The filters on offer depend on the medium, and each filter can take individual values or reference a reusable Group. See the Wi-Fi, LAN and VPN sections below for the specific filters each medium offers and a worked example.
{% endstep %} {% step %} ### What it grants (Assignments) Defines the access returned when the rule matches: a VLAN and/or additional RADIUS attributes, each either **Static** (a fixed value) or **Dynamic**. Dynamic assignment reads a value out of the certificate, from its Issuer, SAN, DN, or a custom Extension, applies a regex pattern to it, and maps the result to the value that gets granted. This same regex mechanism is also used for Certificate Attribute filters in Step 3. You can also define what happens if no pattern matches: reject the request, or fall back to a default value.
{% endstep %} {% endstepper %} *** ## Authentication Methods The authentication methods you can define in "Who may authenticate" restricts the technical medium an authentication needs to use to be accepted. #### Certificate-based authentication You can either enable CBA alone to match all such authentications or further limit authentications for certificates signed by specific CAs.
{% hint style="info" %} You can further restrict CBA using filters to match on the issuer, SAN, DN or extensions of the certificate used. {% endhint %} #### Username/Password-based authentication Enable this method to allow authentications that do not use certificate-based authentication.
{% hint style="info" %} You can further restrict username/password-based authentication using filters to match on usernames or owners. {% endhint %} *** ## Filters Filters can be used to build granular rules that match only under certain circumstances. There are multiple available filters that can be used in different situations: #### Available for all Rules * Client IPs * Certificate Attributes * Username/Password * Intune IDs #### Available for specific Rules * SSIDs (Wi-Fi Rules) * Switch MACs (LAN Rules) * NAS Identitfiers (VPN Rules) * NAS IPs (VPN Rules) ### Client IPs Use the Client IPs filter to match a rule on the WAN-IP address of the authentications. You can use single addresses, CIDRs or a defined group.
### Certificate Attributes Use this filter type to match a rule only if a presented client certificate contains the required information. You can filter for the following attributes: * Issuer * SAN (Subject Alternative Name) * DN (Distinguished Name) * Extension
#### Examples: * Use a SAN filter `.*-ext@contoso\.com$` to match `john.smith-ext@contoso.com` → contractor identity cert, VLAN 10. * Use a DN `OU=Printers` to match the subject `CN=PRINTER07,OU=Printers,O=Contoso` → assign VLAN 16 (printers). * Use a DN `OU=Finance` to match the subject `CN=jdoe,OU=Finance,O=Contoso` → VLAN 30 (Finance). * Use a SAN filter `^platform:windows$` to match specific platforms. Use an URI SAN with value of `platform:windows` to match this. {% hint style="info" %} Note: The rule engine matches values case-sensitively. `OU=Printers` will not match `OU=printers` {% endhint %} ### Username/Password
#### Examples: * Username `^ext-.*` matches `ext-jsmith` → VLAN 50 (contractor) * Owner `IT-AssetPool` matches shared/kiosk device tag → Filter-Id `kiosk-acl` ### SSIDs {% hint style="info" %} This filter type is only available on Wi-Fi rules {% endhint %} To filter for SSIDs, you can choose to match single SSIDs per entry or add a defined group of SSIDs.
### Switch MACs {% hint style="info" %} This filter type is only available on LAN rules {% endhint %} To filter for Switch MACs, you can choose to match single address per entry or add a defined group of Switch MACs.
### NAS-Identifiers {% hint style="info" %} This filter type is only available on VPN rules {% endhint %} Similar to other filters, you can choose to match single NAS-Identifiers per entry or add a defined group of NAS-Identifiers. ### NAS IPs {% hint style="info" %} This filter type is only available on VPN rules {% endhint %} Similar to other filters, you can choose to match single NAS-IPs per entry or add a defined group of NAS-IPs. ### Intune IDs This is a historical filter. If your clients are authenticating with certificates that your clients received during the AAD-Join, you want to filter for your Intune Tenant ID. In case you have entered your Tenant IDs as described [here](https://docs.radiusaas.com/admin-portal/settings/trusted-roots#intune-id), the default behaviour of RADIUSaaS is that only machines presenting a certificate with extension OID **1.2.840.113556.5.14** and a whitelisted value for the Tenant ID will get access to the network. With the rule engine, you now have the option to further restrict the access to specific Intune IDs for a specific rule or to ignore the certificate extension. This allows you to have a multi-deployment setup, where some clients come with certificates providing the respective OID and some do not.
*** ## Assignments If an authentication is valid and matches a rule, the returned Access-Accept packet can contain specific information to give further instructions to the authenticator. ### VLAN A VLAN ID can be assigned statically, meaning that all matching authentications will receive this VLAN ID, or dynamically by extracting the desired value from either a certificate attribute or the username/owner. #### By Certificate Subject (DN) * You can also assign VLAN IDs based on properties in the Subject Name of your certificate * Therefore, specify in which property the VLAN ID is stored * Then, configure which string the VLAN ID is prefixed with * The VLAN ID is not required to have a prefix. However, it can be required to use a prefix in case your Subject Name carries the same attribute more than once (e.g. several CN's are quite common). As an example, the following assignment will match the DN attribute of the client certificate using the regex pattern `OU=vlan-(\d+)` and use the first matching group as resulting value. For a certificate subject (DN) of `CN=CLIENT01,OU=vlan-15` this result in a VLAN assignment of **15**.
#### By Certificate Extension {% hint style="info" %} Currently it is not supported to add custom certificate extensions to SCEP profiles in many MDM systems, including Microsoft Intune and JAMF. We therefore recommend to use the subject of the certificate instead to add a VLAN assignment. {% endhint %} * Select one of your created Certificate Extensions * Choose a regex pattern to get the desired value
### Attributes RADIUS return attributes allow network administrators to define specific settings for individual users or groups. For example, * For User Profile Configuration, an attribute can specify the maximum session duration, allowed services (such as VPN or Wi-Fi), and IP address assignment method. * For Dynamic IP Address Assignment, an attribute might specify that the user should receive a static IP address or use DHCP for dynamic assignment. * For Access Control and Authorization, an attribute determines the user’s access level (e.g., guest, employee, administrator) and any restrictions (e.g., time limits). * For Session Management, an attribute can specify session timeout (how long the user can stay connected), idle timeout (disconnect after inactivity), and maximum simultaneous logins. * For Quality of Service (QoS), an attribute might prioritize voice traffic over data traffic for a specific user. Vendors can create their own custom attributes (vendor-specific attributes or VSAs). These allow for additional functionality beyond the standard IETF attributes. VSAs are encapsulated within the standard attribute 26. In the same manner of VLAN assignments, attributes can be returned either statically or dynamically. You can choose from different return attributes and extend them in the attribute catalogue: {% content-ref url="/pages/nr8htn2giI38d0uKa82w" %} [Attribute Catalogue](/admin-portal/access-and-rules/rules/attribute-catalogue) {% endcontent-ref %} #### Example: Dynamically assign the value of the certificates RDN L to the the return attribute Filter-Id
# Groups The Groups tab centralizes reusable named sets of values, so a rule references the group instead of listing raw values directly. RADIUSaaS offers six kinds: * SSID groups * Access-point MAC groups * Switch groups * NAS identifier groups * NAS IP address groups * Client IP groups Members can be added or removed from a group later without touching any rule that references it.
### Creating a Group Creating a group asks for a name and an optional description, plus the members themselves, which can be added one at a time or pasted in bulk.
### Paste a List To enter group members in bulk, you use the "Paste a list..." option to then paste your desired entries. The entries can be either one per line or comma separated.
Clicking Add to list will then deduplicate the entries and add them to the list of members. ### Prefixes Some of the groups support prefixing to wild-card match multiple values. These are SSIDs, NAS-Identifiers and all MAC-based groups. Such prefixed members will be shown with the "PREFIX" tag:
### MAC Addresses For MAC address-based groups, different formats are supported and will be normalised on save. Any separator, or none at all, will work as well as prefixing the addresses.
### IP Addresses For IP address-based groups, a single address (10.20.0.11) or a CIDR range (10.30.0.0/16). IPv4 and IPv6 both work.
# Certificate Extensions
Certificate extensions let you register a field carried by your certificates so a rule can read it directly, either a private custom OID issued by your own PKI, or a standard field such as the subject, SAN or an issuer attribute. Once registered, the extension appears as a source in any rule's Certificate Attribute filters or Dynamic assignments. {% hint style="info" %} Currently it is not supported to add custom certificate extensions to SCEP profiles in many MDM systems, including Microsoft Intune and Jamf Pro. We therefore recommend using the Certificate Subject Name instead to [dynamically assign VLANs](https://docs.radiusaas.com/admin-portal/settings/rules#vlan-assignment). {% endhint %} # Attribute Catalogue
The Attribute catalogue is a picker list of the RADIUS attributes your rules are allowed to return: standard VLAN/tunnel attributes (DHCP-IEEE-802.1Q-VLAN-ID, SN-Assigned-VLAN-ID, Egress-VLANID and vendor-specific equivalents) plus other RADIUS attributes such as Filter-Id, Class, Framed-MTU, Tunnel-Password, or vendor-specific ones like Cisco-AVPair and Fortinet-Group-Name. Adding an attribute here only makes it selectable in a rule's assignments; it does not apply it anywhere by itself. Attributes not already listed can be added by searching the RADIUS dictionary. # User Settings ## Overview With the User Settings page, you are able to configure how your website will handle User creation/deletions. Because there are two ways to create users, some settings only affect the **My Users** portal.

Showing user settings

### System Upload your business' logo to show users upon sign in. These settings affect all users on the platform. ### My Users Portal These settings only affect the **My Users** portal. ### Passwords These settings are used to configure password complexity. # Users # All Users User management is available under https\://YOURNAME.radius-as-a-service.com/users ## General {% hint style="info" %} RADIUSaaS **does not provide** any **integration** with Identity Providers (IDPs) for username/password-based network authentication. All username/password accounts used for network authentication with RADIUSaaS must be managed on the RADIUSaaS Admin Portal. {% endhint %} RADIUSaaS offers username/password-based authentication as an **alternative** to certificate-based authentication whenever the usage of certificates is technically hard to reach or not feasible. Such scenarios may include: * Bring your own Device (BYOD) * [Guest Access ](/admin-portal/my-invited-users) * Devices lacking EAP-TLS support for 802.1X (e.g. printers, TVs, ...) ## Protocols Devices that use username and password for network authentication have to speak one of the following Protocols: * EAP-TTLS-PAP * EAP-TTLS-MSCHAPv2 * PEAP-MSCHAPv2 ## Add To **Add** a new User, click **Add** and provide **Username** and **Password** and choose your **Validity**. After entering all details, click **Create**. {% hint style="info" %} A username can be just a simple name such as "jack" or as complex as your UPN, however, be sure not to use your actual Entra ID UPN **and** the password associated with it for RADIUS authentication. While you may use the UPN or email address, please choose a different password. {% endhint %} ## Bulk User Import To import your users from a supported file format (.xlsx, .xls or .csv file), click **Import** and follow the steps as shows below. {% hint style="info" %} The required columns are **Username, Password** and **Owner**. {% endhint %}
## Delete To **Delete** users, select all users which should be deleted in the list, click **Delete and** confirm your choice. ## Update To change a user's password, disable/re-enable a user or select a new validity period, simply click on the **eye** symbol next to the user entry, change all needed entries and save them.

Showing update of a user

# My Invited Users Any identity or accounts that has been assigned the [**Users**](/admin-portal/access-and-rules/permissions#users) role, is able to create [username/password accounts](/admin-portal/users/users) with [certain constraints](/admin-portal/access-and-rules/user-settings). Those accounts are typically used for BYOD or guest access scenarios, enabling a self-sponsored access approach not requiring any administrator interaction. The [Rule Engine](/admin-portal/insights/rule-engine) can be leveraged to segregate such devices from more privileged network segments, e.g. using VLAN tagging. UPNs that have only been assigned the Users role have access to the **My Invited Users** only and thus have below RADIUSaaS Admin Portal experience:
# Microsoft Intune {% content-ref url="/pages/-MYxiLd7JIp6ZsqGaDol" %} [Server Trust](/profile-deployment/microsoft-intune/trusted-root) {% endcontent-ref %} {% content-ref url="/pages/-MYxiZmAIpyMYZXLfOdl" %} [WiFi Profile](/profile-deployment/microsoft-intune/wifi-profile) {% endcontent-ref %} {% content-ref url="/pages/-MYxvNFJUncToXBdPvsu" %} [Wired Profile](/profile-deployment/microsoft-intune/wired-profile) {% endcontent-ref %} # Server Trust {% hint style="info" %} This is only required if you are using a RADIUS server certificate that was issued by a CA that your clients do not already trust. For example, this is not needed if you are bringing your own server certificate issued by SCEPman. {% endhint %} ### Part 1: Download the RADIUS Server Certificate When [downloading](/admin-portal/settings/settings-server#download) the Server certificate, use only the green-marked certificate. This will download the root CA certificate of the issuing CA.
### Part 2: Adding a Trusted certificate profile for your endpoint devices {% hint style="warning" %} Ensure, you have reviewed [Part 1](#edit-your-downloaded-certificate). {% endhint %} 1. Log in to [Microsoft Intune](https://intune.microsoft.com/) 2. Navigate to **Devices** and subsequently **Configuration profiles** 3. Then click **Create > New policy** 4. Select the correct **Platform** for your device 5. Search the **Profile type** templates for **Trusted certificate** and select it 6. Click **Create** and provide a descriptive name and optional **Description** 7. In the second step, upload the \*.cer file containing the RADIUS server certificate/trusted root the server certificate was signed with. ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/brqevWf8XzBgPh5fhlAj/image.png) # WiFi Profile Please follow below guides to configure WiFi profiles in Intune for different endpoint device types. {% hint style="warning" %} We strongly recommend to **not use any spaces** or **special characters** in your **SSID**. {% endhint %} ## Windows {% content-ref url="/pages/-MYxico0PQd5\_S4AzQW6" %} [Windows](/profile-deployment/microsoft-intune/wifi-profile/windows) {% endcontent-ref %} ## Apple {% content-ref url="/pages/-MYxkE0cj6JDXvxkscEi" %} [iOS/iPadOS & macOS](/profile-deployment/microsoft-intune/wifi-profile/apple-devices) {% endcontent-ref %} ## Android {% content-ref url="/pages/-MYxkT9LzlFSIDjxhMwZ" %} [Android](/profile-deployment/microsoft-intune/wifi-profile/android) {% endcontent-ref %} # Windows This guide is applicable for both scenarios: using user- or device-type certificates for WiFi authentication. ## Configuration steps 1. Log in to [Microsoft Intune](https://intune.microsoft.com/) 2. Navigate to **Devices** and subsequently **Configuration profiles** 3. Then click **Create > New policy** 4. As **Platform** select **Windows 10 and later** 5. Search the **Profile type** templates for **Wi-Fi** and select it 6. Click **Create** and provide a descriptive name and optional **Description** 7. As **Wi-Fi type** select **Enterprise** 8. Enter your **SSID**. The **Connection Name** can assume the same name. 9. Configure the **Authentication Method** to **User** if you want to use user-type certificates for authentication or **Machine** if you would like to use device-type certificates for authentication. 10. Then for **EAP type** choose **EAP - TLS** 11. Next, as **Certificate server names** add the **Subject Alternative Name (SAN)** of your *active* RADIUS [**Server Certificate**](/admin-portal/settings/settings-server#server-certificates). This property can be found by expanding the active server certificate and copying the relevant value.
{% hint style="warning" %} The Subject Alternative Name (SAN) is **case-insensitive** when used for hostname verification. {% endhint %} 12. For the **Root certificates for server validation** select the Trusted certificate profile you have previously created for the RADIUS Server Certificate. 13. Under **Client Authentication** select **SCEP certificate as** **Authentication method** 14. Finally for **Client certificate for client authentication (Identity certificate),** select the SCEP profile you would like to use for authentication. All other settings can be configured according to your own needs and preferences.

Showing Wi-Fi profile configuration 1/2

### Fast roaming {% hint style="info" %} These are **optional** settings. {% endhint %} For a (usually) better experience when roaming between access points, we recommend enabling the following **Fast roaming settings** in the WiFi profile: | **Enable pairwise master key (PMK) caching** | Yes | Defines whether Pairwise Master Key (PMK) caching is to be used by this profile to connect to a WLAN. | | -------------------------------------------- | --- | ----------------------------------------------------------------------------------------------------- | | **Maximum time a PMK is stored in cach** | 720 | Defines the length of time, in minutes, that a Pairwise Master Key (PMK) cache will be kept. | | **Maximum number of PMK's stored in cache** | 128 | Defines the number of entries in the Pairwise Master Key (PMK) cache on the client. | | **Enable pre-authentication** | Yes | Defines whether pre-authentication will be used by the client | | **Maximum pre-authentication attempts** | 3 | Defines the number of pre-authentication attempts to try on neighboring access points (AP) | For further details on Pairwise Master Key caching, please refer to its specification in [IEEE 802.11i](https://standards.ieee.org/getieee802/download/802.11i-2004.pdf). **Important**: The reliability and effectiveness of this feature may also depend on the specific implementation by the WAP vendor. In the same cases, customers with PMK caching enabled, have reported frequent access-point toggling although the device's location was static. ## Common configuration issues See [Troubleshooting](/other/troubleshooting#intune-configuration-issues). # iOS/iPadOS & macOS This guide is applicable for both scenarios: using user- or device-type certificates for WiFi authentication. ## Configuration steps 1. Log in to [Microsoft Intune](https://intune.microsoft.com/) 2. Navigate to **Devices** and subsequently **Configuration profiles** 3. Then click **Create > New policy** 4. As **Platform** select **iOS/iPadOS** or **macOS** 5. Search the **Profile type** templates for **Wi-Fi** and select it 6. As **Profile type** select **Wi-Fi** 7. Click **Create** and provide a descriptive name and optional **Description** 8. As **Wi-Fi type** select **Enterprise** 9. Enter your **SSID**. The **Network name** can assume the same name. 10. Select the applicable **Security type** (iOS/iPadOS only) 11. Then for **EAP type** choose **EAP - TLS** 12. Next, as **Certificate server names** add the **Subject Alternative Name (SAN)** of your *active* RADIUS [**Server Certificate.**](/admin-portal/settings/settings-server#server-certificates) This property can be found by expanding the active server certificate and copying the relevant value.
13. For the **Root certificates for server validation** select the Trusted certificate profile you have previously created for the RADIUS Server Certificate. 14. Under **Client Authentication** select **Certificates** as **Authentication method** 15. Finally, under **Certificates** select the SCEP profile you would like to use for authentication. All other settings can be configured according to your own needs and preferences.

Showing iOS/iPad Wi-Fi Profile

## Common configuration issues See [Troubleshooting](/other/troubleshooting#intune-configuration-issues). # Android ## Configuration steps 1. Log in to [Microsoft Intune](https://intune.microsoft.com/) 2. Navigate to **Devices** and subsequently **Configuration profiles** 3. Then click **Create > New policy** 4. As **Platform** select your Android device type 5. Search the **Profile type** templates for **Wi-Fi** and select it 6. Click **Create** and provide a descriptive name and optional **Description** 7. As **Wi-Fi type** select **Enterprise** 8. Enter your **SSID** 9. As **EAP type** choose **EAP - TLS** 10. Next, as **Radius server name** add the * **Subject Alternative Name (SAN)** of your *active* RADIUS [**Server Certificate**](/admin-portal/settings/settings-server#server-certificates) . This property can be found by expanding the active server certificate and copying the relevant value.

Showing certificate details

11\. For the **Root certificates for server validation** select the Trusted certificate profile you have previously created for the RADIUS Server Certificate. 12\. Under **Client Authentication** select **Certificates** as **Authentication method** 13\. Finally, under **Certificates** select the SCEP profile you would like to use for authentication. All other settings can be configured according to your own needs and preferences. {% hint style="info" %} Some Android kiosk devices require a value for **Identity privacy (outer identity)**. Please consider this when you are having issues authenticating against the WiFi network with such devices. {% endhint %} ![](https://1222554226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSWU1DQ4UGkqER7uGNUOm%2Fuploads%2FTilY5Sqamt8u8GhSb8Sv%2F2024-06-03_21h31_46.png?alt=media\&token=df601531-cdaa-44a1-982a-4384b20e004b) ## Common configuration issues See [Troubleshooting](/other/troubleshooting#intune-configuration-issues). # Wired Profile Please follow below guides to configure profiles for your wired access policies in Intune and different endpoint device types. ## Windows {% content-ref url="/pages/-MYxvXQ\_1DsFMZk16xGd" %} [Windows](/profile-deployment/microsoft-intune/wired-profile/windows) {% endcontent-ref %} ## Apple {% content-ref url="/pages/-MYxw0VIvq4euyEYpTKl" %} [macOS](/profile-deployment/microsoft-intune/wired-profile/mac) {% endcontent-ref %} # Windows ## Configurations steps 1. Log in to [Microsoft Intune](https://intune.microsoft.com/) 2. Navigate to **Devices** and subsequently **Configuration profiles** 3. Then click **Create > New policy** 4. As **Platform** select **Windows 10 and later** 5. Search the **Profile type** templates for **Wired network** and select it 6. Click **Create** and provide a descriptive name and optional **Description** 7. fill out the **Configuration settings** as it suits your environment 8. Configure the **Authentication Method** to **User** if you want to use user-type certificates for authentication or **Machine** if you would like to use device-type certificates for authentication. 9. Under **802.1X** make sure, that **Do not enforce** is selected. This way your network adapter will continue to work in environments (e.g. home office), where 802.1X is not available. 10. For **EAP Type** choose **EAP-TLS** 11. Next, as **Certificate server names** add the **Subject Alternative Name (SAN)** of your *active* RADIUS [**Server Certificate.**](/admin-portal/settings/settings-server#server-certificates) This can be found by expanding the active server certificate and copying the value for SAN.
12. For the **Root certificates for server validation** select the Trusted certificate profile you have previously created for the RADIUS Server Certificate. 13. Under **Client Authentication** select **SCEP certificate** as **Authentication method** 14. Finally, for **Client certificate for client authentication (Identity certificate),** select the SCEP profile you would like to use for authentication. All other settings can be configured according to your own needs and preferences. ![Showing wired profile](https://1222554226-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FSWU1DQ4UGkqER7uGNUOm%2Fuploads%2FsPcGYRlydnwopP88aq12%2F2024-05-13_15h48_55.png?alt=media\&token=11358487-b38e-4cd2-b78c-b4cf1eb65cf0) # macOS ## Configuration steps 1. Log in to [Microsoft Intune](https://intune.microsoft.com/) 2. Navigate to **Devices** and subsequently **Configuration profiles** 3. Then click **Create > New policy** 4. As **Platform** select **macOS** 5. Search the **Profile type** templates for **Wired network** and select it 6. Click **Create** and provide a descriptive name and optional **Description** 7. Choose your **Network Interface** 8. As **EAP type** choose **EAP - TLS** 9. Next, as **Certificate server names** add the **Subject Alternative Name (SAN)** of your *active* RADIUS [**Server Certificate.**](/admin-portal/settings/settings-server#server-certificates) This property can be found by expanding the active server certificate and copying the relevant values.
1. For the **Root certificates for server validation** select the Trusted certificate profile you have previously created for the RADIUS Server Certificate. 2. Finally, under **Client Authentication** select **Certificates as** **Authentication method**

Showing wired network profile for macOS

# Jamf Pro ## General {% hint style="success" %} We strongly recommend to configure all 802.1X-relevant payloads in a **single** Configuration Profile in Jamf - and one Configuration Profile per assignment type (Computers, Devices, Users). {% endhint %} To fully configure 802.1X, this typically means you require the following payloads: * Network payload(s) (WiFi and/or LAN) * Certificate payload(s) * Root CA certificate of the SCEP-issuing CA * Root CA certificate of the RADIUS server certificate issuing CA (can be the same as the SCEP issuing CA) * SCEP payload (client authentication certificate)
## Payloads {% content-ref url="/pages/qedLmVD2hg2xuGDaUALd" %} [Server Trust](/profile-deployment/jamf-pro/server-trust) {% endcontent-ref %} {% content-ref url="/pages/JjbQKqgciZW4eAVVBjtC" %} [WiFi Profile](/profile-deployment/jamf-pro/wifi-profile) {% endcontent-ref %} {% content-ref url="/pages/R7rgEshgHnAaJ937nOLg" %} [Wired Profile](/profile-deployment/jamf-pro/wired-profile) {% endcontent-ref %} # Server Trust {% hint style="info" %} This is only required if you are using a RADIUS server certificate that was issued by a CA that your clients do not already trust. For example, this is not needed if you are bringing your own server certificate issued by SCEPman. {% endhint %} ### Part 1: Download the RADIUS Server Certificate When [downloading](/admin-portal/settings/settings-server#download) the Server certificate, use only the green-marked certificate. This will download the root CA certificate of the issuing CA.

Showing download of root CA

### Part 2: Trust the Server Certificate 1. Log in to your Jamf Pro instance. 2. Choose your correct deployment scope (Computers, Devices or Users). In this example, we have chosen a macOS device (Computers). 3. Navigate to an existing Configuration Profile or create a new one and give the profile a meaningful name, e.g. "Corp-WiFi-802.1X". 4. Add a **Certificate** payload 5. Provide a meaningful **Certificate Name**, e.g. "RADIUSaaS Server Root CA" 6. Under **Select Certificate Option** select **Upload** 7. Upload the \*.cer file containing the certificate you have downloaded in Part 1. A password is not required, since it is only the public key part that is contained in the file and that needs to be uploaded. 8. Select **Allow all apps access** 9. Unselect **Allow export from keychain** 10. Click **Save** 11. Under **Scope** assign the profile to the relevant audience
# WiFi Profile {% hint style="warning" %} We strongly recommend to **not use any spaces** or **special characters** in your **SSID**. {% endhint %} To configure a WiFi profile in Jamf, please follow these instructions: 1. Log in to your Jamf Pro instance 2. Choose your correct deployment scope (Computers, Devices or Users). In this example, we have chosen a macOS device (Computers). 3. Navigate to the existing Configuration Profile from the previous step ([Trusted Root](/profile-deployment/jamf-pro/server-trust)) 4. Add a **Network** payload 5. As **Network Interface** select **Wi-Fi** 6. Provide your **Service Set Identifier (SSID)** 7. As **Security Type** select **Any (Enterprise)**
8. Under **Network Security Settings** and **Protocols** select **TLS**
9. Navigate to **Network Security Settings** **>** **Trust** 10. As **Identity Certificate** select the client authentication certificate you have configured in your SCEP payload of this Configuration Profile before. In case you are using SCEPman as CA, please select the SCEP Proxy you have previously set up during the [configuration](https://docs.scepman.com/certificate-deployment/jamf/general) of SCEPman. 11. Under **Trusted Certificates** all certificates you have configured as **Certificate** payloads, will appear here. Check them all. 12. Next, under **Trusted Server Certificate Names** add the * **Subject Alternative Name (SAN)** * and **Common Name (CN)** \ \ of your *active* RADIUS [**Server Certificate.**](/admin-portal/settings/settings-server#server-certificates) Those properties can be found by expanding the active server certificate and copying the relevant values. {% hint style="warning" %} Note that the Common Name is case-sensitive. Please make sure there are no spaces or hidden characters at the beginning or end of the Trusted Server Certificate Names input field in the JAMF interface. {% endhint %}
13. Unselect **Allow Trust Exceptions** 14. Configure all other options as per your requirements. 15. Click **Save** 16. Under **Scope** assign the profile to the relevant audience
# Wired Profile To configure a Wired network profile in Jamf, please follow these instructions: configure all other options as per your requirements. 1. Log in to your Jamf Pro instance 2. Choose your correct deployment scope (Computers, Devices or Users). In this example, we have chosen a macOS device (Computers). 3. Navigate to the existing Configuration Profile from the previous step ([Trusted Root](/profile-deployment/jamf-pro/server-trust)). 4. As **Network Interface** select the relevant ethernet, e.g. **First Active Ethernet** 5. Under **Network Security Settings** and **Protocols** select **TLS**
6. Navigate to **Network Security Settings** **> Trust** 7. As **Identity Certificate** select the client authentication certificate you have configured in your SCEP payload of this Configuration Profile before. In case you are using SCEPman as CA, please select the SCEP Proxy you have previously set up during the [configuration](https://docs.scepman.com/certificate-deployment/jamf/general) of SCEPman. 8. Under **Trusted Certificates** all certificates you have configured as **Certificate** payloads, will appear here. Check them all. 9. Next, under **Trusted Server Certificate Names** add the * **Subject Alternative Name (SAN)** * and **Common Name (CN)** \ \ of your *active* RADIUS [**Server Certificate**](/admin-portal/settings/settings-server#server-certificates). Those properties can be found by expanding the active server certificate and copying the relevant values. **Please consider, that the common name is case-sensitive.**
10. Unselect **Allow Trust Exceptions** 11. Configure all other options as per your requirements. 12. Click **Save** 13. Under **Scope** assign the profile to the relevant audience
# Google Workspace # Server Trust {% hint style="info" %} This is only required if you are using a RADIUS server certificate that was issued by a CA that your clients do not already trust. For example, this is not needed if you are bringing your own server certificate issued by SCEPman. {% endhint %} ## Part 1: Download the RADIUS Server Certificate When [downloading](/admin-portal/settings/settings-server#download) the Server certificate, use only the green-marked certificate. This will download the root CA certificate of the issuing CA.
## Part 2: Adding a Trusted certificate profile for your endpoint devices {% hint style="warning" %} Ensure, you have reviewed [Part 1](#part-1-download-the-radius-server-certificate). {% endhint %} In your Google **Admin console** (admin.google.com) navigate to **Menu** > **Devices** > **Network** > **Certificates** > **ADD CERTIFICATE**
# WiFi Profile {% hint style="warning" %} We strongly recommend to **not use any spaces** or **special characters** in your **SSID**. {% endhint %} To configure a WiFi profile in Google Workspaces for your Chromebooks, please follow these instructions: 1. In your Google **Admin console** (at admin.google.com) > Go to **Menu** > **Devices** > **Network** > **Create a Wi-Fi network**. 2. In the **Platform access** section, check the box for **Enabled for Chromebooks (by device)**. 3. In the **Details** section, set the following: | Details | Value | | ------------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Name** | Your WiFi name (we recommend to match it with the SSID). | | **SSID** | Your SSID. | | **Automatically connect** | Enable the checkbox. | | **Security Type** | **WPA/WPA2/WPA3 Enterprise (802.1X)** | | **Extensible Authentication Protocol** | **EAP-TLS** | | **Maximum TLS Version** | **1.2** | | **Username** | Anonymous | | **Server Certificate Authority** | Reference the certificate profile containing your [RADIUS server certificate root CA](/profile-deployment/google-workspace/server-trust). | | **Server Certificate Domain Suffix Match** |

Add the

  • Subject Alternative Name (SAN)
  • and Common Name (CN)

of your active RADIUS Server Certificate. These properties can be found by expanding the active server certificate and copying the relevant values. See screenshot below.

| | **SCEP profile** | Reference your [SCEP certificate profile](https://docs.scepman.com/certificate-deployment/static-certificates/google-workspace/chromeos#add-a-scep-profile). |

Showing Subject Alternative Name (SAN) and Common Name (CN)

4. Click **Save**.
# Troubleshooting ## Connection Issues ### Client view #### Wrong XML {% hint style="warning" %} Can't connect because you need a certificate to sign in. Contact your IT support person. {% endhint %} ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/k8FhkMHpqVOne7UXpLzC/image.png) Check that your client has a certificate to authenticate and that you are using the correct [WiFi configuration profile](/profile-deployment/microsoft-intune/wifi-profile) or [XML](/admin-portal/settings/trusted-roots#xml). #### Trusted root issues {% hint style="warning" %} Can't connect to this network. {% endhint %} ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/g3XbpcPNSLDJPrr96nYr/image.png) Check that you've done the following: * Told your RADIUS Server which certificates are allowed to connect as described [here](/admin-portal/settings/trusted-roots#add) * Imported the active RADIUS Server certificate as trusted root on your client as described [here](/profile-deployment/microsoft-intune/trusted-root#to-add-a-trusted-root-profile-for-your-clients) * Check your [Logs](/admin-portal/insights/log#logs). There is a detailed description of the error. Maybe it's [this](/other/troubleshooting#fatal-decrypt-error) issue. #### Continue connecting? {% hint style="warning" %} Continue connecting? \ If you expect to find Corporate WiFi in this location, go ahead and connect. Otherwise, it may be a different network with the same name. Show certificate details. {% endhint %} If your clients need to verify on connecting the first time, and you're seeing this dialog: ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/8uYG1oXtvKS2IJkLbQyL/image.png) Make sure that you have referenced the RADIUS server certificate in your WiFi profile and provided the server certificate's SAN attribute (FQDN) and common name (CN):

Showing server certificate's SAN attribute (FQDN) and common name (CN)

### Server view #### Unknown CA If your [Logs](/admin-portal/insights/log#logs) contain error messages similar to the ones shown below ``` ERROR: (14872) eap_tls: ERROR: SSL says error 20 : unable to get local issuer certificate ERROR: (14872) eap_tls: ERROR: TLS Alert write:fatal:unknown CA Error: tls: TLS_accept: Error in error Auth: (14872) Login incorrect (eap_tls: SSL says error 20 : unable to get local issuer certificate): [host/8dc38402-20fb-41db-a8f3-4e4e95637173/] (from client contoso port 1 cli 18-9K-EA-0H-7F-C5) ``` it can have the following root causes: * Client throws error `TLS Alert read:fatal:unknown CA` * Your Client doesn't know the **Server certificate** and rejects the connection. Check that you've added your **Server certificate** as described [here](/profile-deployment/microsoft-intune/trusted-root#adding-a-trusted-root-profile-for-your-clients). * You've changed/added a new **Server certificate** and your XML profile on the client is using the old one. In that case, please double-check that you've either updated your WiFi/Wired profile or re-generated your [XML](/admin-portal/settings/trusted-roots#xml) after adding the certificates and pushed that to your clients. * Server throws error `TLS Alert write:fatal:unknown CA` * Your RADIUS server doesn't know the issuer of the certificate which was used for authentication. Add your CA as described [here](/admin-portal/settings/trusted-roots#add). #### Certificate unknown If you use macOS (and possibly other Apple platforms) and if your [Logs](/admin-portal/insights/log#logs) contain error messages similar to the one shown below ``` eap_tls: (TLS) TLS - Alert read:fatal:certificate unknown ``` it can have the following root causes: * There is a space character somewhere in the **Certificate server name** in your [WiFi](/profile-deployment/microsoft-intune/wifi-profile/apple-devices) or [Wired](/profile-deployment/microsoft-intune/wired-profile/mac) configuration profile. #### Decrypt error | Access denied If your [Logs](/admin-portal/insights/log#logs) contain error messages similar to the ones shown below ``` Auth: (312) Login incorrect (eap_tls: TLS Alert write:fatal:decrypt error): [host/00128t09-cbna-469c-9768-2783d28eikl9/] (from client contoso port 1 cli 84-FD-D1-8C-0E-33) ERROR: (320) eap_tls: ERROR: TLS Alert write:fatal:decrypt error Error: tls: TLS_accept: Error in error ``` ... then it is probably a bug of the TPM software on your Windows machines. More information on that can be found in the [SCEPman documentation](https://docs.scepman.com/certificate-deployment/microsoft-intune/windows-10#key-storage-provider-ksp-enroll-to-trusted-platform-module-tpm-ksp-otherwise-fail). If you see something like this in your [Logs](/admin-portal/insights/log#logs) ``` ERROR: (95878) eap_tls: ERROR: (TLS) Alert read:fatal:access denied Auth: (95878) Login incorrect (eap_tls: (TLS) Alert read:fatal:access denied): [host/kad933-161d-4aa8-aeaa-b5a4d3d53b12] ERROR: (95717) eap_tls: ERROR: (TLS) Alert read:fatal:access denied ``` ... there can be two reasons. One is that your WiFi profile is referencing the wrong root certificate for server validation. Please make sure that your profile is setup correctly. If it is and you are still facing this issue, try to set your KSP to [**Software KSP**](https://docs.scepman.com/certificate-deployment/microsoft-intune/windows-10#key-storage-provider-ksp-enroll-to-trusted-platform-module-tpm-ksp-otherwise-fail). {% hint style="warning" %} The setting Key Storage Provider (KSP) determines the storage location of the private key for the end-user certificates. Storage in the TPM is more secure than software storage, because the TPM provides an additional layer of security to prevent key theft. However, there is **a bug in some older TPM firmware versions** that invalidates some signatures created with a TPM-backed private key. In such cases, the certificate cannot be used for EAP authentication as it is common for Wi-Fi and VPN connections. Affected TPM firmware versions include: * STMicroelectronics: 71.12, 73.4.17568.4452, 71.12.17568.4100 * Intel: 11.8.50.3399, 2.0.0.2060 * Infineon: 7.63.3353.0 * IFX: Version 3.19 / Specification 1.2 If you use TPM with this firmware, either update your firmware to a newer version or select "Software KSP" as key storage provider. {% endhint %} #### Cannot continue, as the peer is misbehaving If your Logs contain rejections with the error *"Cannot continue, as the peer is misbehaving"* this indicates that the client stopped communicating with the RADIUS service, mostly because the trust settings are incorrect. In this case, please verify the certificates on the affected devices. #### Wrong Shared RADIUS Secret If your (proxy) [Logs](/admin-portal/insights/log#logs) contain error messages similar to the ones shown below ``` - message authenticator, wrong value - buf2radmsg: message authentication failed - radsrv: ignoring request from default (8.222.246.231), validation failed ``` then one of your access points or switches that is trying to connect to your RADIUSaaS instance via a [RADIUS Proxy](/admin-portal/settings/settings-proxy) is using a mismatched [Shared Secret](/admin-portal/settings/settings-server#properties-1). To identify the affected access point or switch, first determine the RADIUS proxy by expanding the error message and searching for the `proxyip` property. Now that you know the proxy, use your inventory and knowledge of specific locations or groups of devices that cannot connect to your network to identify the misconfigured network device. Finally, update the shared secret to match the value configured in your RADIUSaaS instance for that proxy. ### Troubleshooting Connection Issues with CAPI2 Logs Windows clients use the **Cryptographic API (CAPI2)** subsystem to handle certificate operations during EAP-TLS authentication. When a connection fails and neither the client UI nor the RADIUSaaS server logs provide a clear indication of the root cause, enabling CAPI2 logging on the affected device can reveal certificate validation failures, chain-building errors, or private-key access issues that would otherwise be invisible. *** #### **Step 1: Enable CAPI2 Logging** CAPI2 logging is disabled by default. To turn it on: 1. Open **Event Viewer**: press **Win + R**, type `eventvwr.exe`, and press **Enter**. 2. In the left-hand tree, expand **Applications and Services Logs**. 3. Expand **Microsoft → Windows → CAPI2**. 4. Right-click **Operational** and select **Enable Log**. Once enabled, Windows will start recording all CAPI2 events. Reproduce the connection failure. Now try to connect to the Wi-Fi or wired network, then move on to the next step. > **Tip:** Disable the log again after collecting the data (**right-click Operational → Disable Log**) to avoid unnecessary disk usage. *** #### **Step 2: Locate the Relevant Events** After reproducing the issue, look for events in the following log sources: | Log source | Path in Event Viewer | | ------------------- | ------------------------------------------------------------------------------------ | | **CAPI2** | Applications and Services Logs → Microsoft → Windows → CAPI2 → Operational | | **WLAN AutoConfig** | Applications and Services Logs → Microsoft → Windows → WLAN-AutoConfig → Operational | Focus on events that were recorded **at the time of the failed connection attempt**. Useful indicators include: * **CAPI2** — errors related to certificate chain building, revocation checks, or private-key access (e.g., Event IDs 11, 70, 90). * **WLAN-AutoConfig** — events describing the 802.1X negotiation outcome (e.g., Event IDs 8001, 8002, 12013). *** #### **Step 3: Export and Send the Logs** To send us the logs for review: 1. In Event Viewer, right-click the **Operational** log under **CAPI2** and select **Save All Events As…** 2. Save the file as an **Event Log (\*.evtx)** file and name it something descriptive, e.g. `CAPI2__.evtx`. 3. Repeat the same steps for the **WLAN-AutoConfig → Operational** log. 4. Send both `.evtx` files to our support team at along with a brief description of the affected device, OS version, and when the issue occurs. ## Certificate issues ### Certificate chain could not be verified
When you want to use your own server certificate, your RADIUS server requires the complete certificate chain in order to let other participants (Proxy, RadSec clients, endpoints that try to connect) verify the server's identity. \ If you see this message, either copy & paste the CA certificate below the server certificate in the textfield or create a PCKS8 certificate bundle which includes all certificates from the lead to the root. ## Admin Portal issues ### Login In order to log in to the RADIUSaaS web portal ("RADIUSaas Admin Portal"), the following requirements have to be met: * The UPN/email address you provided as technical admin has to be authenticatable against **some** Microsoft Entra ID (Azure AD) (it does not have to be an identity from the tenant whose users will leverage RADIUSaaS for network authentication). * The UPN/email address you provided as technical admin must have been registered on your RADIUSaaS instance as described [here](/admin-portal/access-and-rules/permissions). In case it is the initial admin, please [contact us](https://www.radius-as-a-service.com/help/) if you believe we registered the wrong user. * The Microsoft Entra ID (Azure AD) user object behind the UPN/email address has to be entitled to grant the RADIUSaaS Enterprise Application the following permissions (see screenshot below): * **Read** the Basic User Profile * **Maintain** access to data you have given it access to (allow request of refresh token)\ ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/zBRh87CJ75R1N8hz7mZF/Screenshot_2022-04-11_at_09_31_26.png) * In case your Microsoft Entra ID (Azure AD) user has no rights to grant the required permissions, no corresponding **Enterprise Application** will be auto-created in your Microsoft Entra ID (Azure AD). To circumvent this, ask your IT department to grant your user the needed permissions. ## Intune configuration issues ### Profile assignment Wi-Fi configuration does not get deployed if Wi-Fi, SCEP and Trusted certificate profiles are assigned to different groups. They might show up as "Pending" or there is no status at all. Please use the **same group or "All devices" resp. "All users"** for **all linked profiles**. You can assign the SCEP Root certificate profile to both "All users" and "All devices" if you have a device (assigned to "All devices)" and user certificate (assigned to "All users") in use. ### SCEP certificate #### Android Android seems to require an UPN in Subject alternative name in newer versions (even for device certificates). Please add this in your SCEP profile (e.g. {{DeviceId}}@contoso.com):
### Wi-Fi profile #### Android Common error codes: 0xc7d24fc5 or -942518331 Key points are: * select the **Root CA certificate** for **server validation** (important: do not upload the server certificate of the RADIUSaaS)\ **- and -** * define a **radius server name** * Note: There seems to be a character limit for this field. To solve possible issues, you might just use the domain part without subdomain like "radius-as-a-service.com" (instead of "contoso.radius-as-a-service.com"). * [Android developers](https://developer.android.com/guide/topics/connectivity/wifi-enterprise) states: "\[...] must configure **both a Root CA certificate**, and either a **domain suffix match** or an alternate subject match". So, the MDM can use "setAltSubjectMatch" or "setDomainSuffixMatch" after adding a root certificate to the Wi-Fi configuration. Intune seems to use "setDomainSuffixMatch" as just "radius-as-a-service.com" is sufficient. * sometimes **identity privacy** is needed (e.g. seen on Android kiosk devices / Android Enterprise dedicated) # Solving EAP Fragmentation: The Key to Reliable RADIUS Authentication In network security, the **Maximum Transmission Unit (MTU)** is a critical networking parameter that defines the largest packet size that can be transmitted over a network link without being fragmented. While most users don't need to think about MTU, it becomes an important troubleshooting factor in specific scenarios, particularly with RADIUS and EAP-TLS authentication. This article explores how MTU affects the RADIUS protocol, especially when dealing with large payloads like the certificates used in EAP-TLS, and why this can lead to authentication failures. *** ## Introduction to MTU and Fragmentation The **MTU** is the largest packet size that a network can handle without breaking it into smaller pieces. The standard MTU for most Ethernet networks is 1500 bytes. When a packet is too large for a network link, it must be either dropped or broken into smaller, acceptable pieces, a process called **IP fragmentation**. The destination host is responsible for reassembling all the fragments back into the original packet. *** ## EAP vs. IP Fragmentation: Why This Distinction Matters The distinction between EAP and IP fragmentation is crucial for understanding authentication issues. * **IP Fragmentation (Network Layer)**: This is where a router breaks a single UDP datagram into multiple, smaller IP packets. This happens below the RADIUS application, which is unaware that its packet was fragmented. * **EAP Fragmentation (Application Layer)**: The EAP protocol itself does not support fragmentation, but it provides a framework where individual EAP methods, such as EAP-TLS, can implement their own fragmentation mechanisms. When a large EAP-TLS message (e.g., a certificate) is too large for the MTU, it can be broken into multiple EAP fragments. Each fragment is then encapsulated within its own RADIUS packet and sent individually. The key difference is that **IP fragmentation** relies on the network to reassemble packets, a process that often fails. **EAP fragmentation** relies on the client and server to handle reassembly, which is a more robust process that avoids network-level issues. *** ## The Authenticator's Role in Fragmentation The RADIUS client, or Authenticator, is a key player in this process. While it acts as a proxy, it can be configured to fragment EAP messages to avoid IP fragmentation. This is the preferred method for handling large payloads. For example, an Authenticator can be configured to break down a large EAP message received from a supplicant before encapsulating it in a RADIUS packet and sending it to the server. This ensures the packet is properly sized for the network path. *** ## Framed-MTU vs. EAP Fragmentation Size The Framed-MTU is often confused with EAP fragmentation. The Framed-MTU is an attribute usually sent in an `Access-Accept` message from the RADIUS server to the RADIUS client. Its purpose is to set the IP MTU for the user's data session after they have been successfully authenticated. It cannot solve fragmentation issues that occur during the authentication handshake itself, which is when EAP fragmentation is needed. In a less common scenario, the Framed-MTU attribute can also be sent from the RADIUS client to the server in an `Access-Request` message to signal the MTU that the client is capable of supporting or would prefer to use. It's a hint or a suggestion, not a command. The RADIUS server is free to ignore this value or use it as a factor when deciding on the MTU for the session, however, this is not a standard mechanism for negotiating EAP fragment size. *** ## Why EAP Fragmentation is the Better Solution EAP fragmentation must be configured on both the Authenticator and the RADIUS server to ensure a reliable and successful EAP-TLS authentication. Since the EAP-TLS process is a two-way conversation, both sides must be capable of fragmenting large payloads. It is also a best practice to configure both sides with the same EAP fragment size to ensure consistency and prevent authentication failures. Given this necessity, when a large certificate causes authentication to fail, it's often due to IP fragmentation. Firewalls or CGNAT devices may drop fragmented packets, causing the authentication to time out. Instead of a blanket reduction of the MTU for all network traffic, the best practice is to configure **EAP fragmentation on the authenticator and RADIUS server.** This approach offers several key advantages: * **Targeted Fix**: Configuring a specific EAP fragment size on the authenticator or RADIUS server directly solves the problem at its source. It ensures that the large authentication packets are broken into smaller, acceptable pieces before being sent over the network, preventing IP fragmentation without affecting other traffic. * **No Significant Performance Impact on the Overall Network**: Reducing the global MTU for an interface affects all network traffic, which can lead to increased overhead and a decrease in network efficiency. By using EAP fragmentation, the rest of the network's traffic continues to use the standard MTU, preserving optimal performance. While EAP fragmentation does create more smaller packets for the same payload and may introduce slight latency due to more roundtrips, this has a negligible performance impact on the overall network and is a necessary trade-off for a successful authentication. * **Protocol-Specific Design**: EAP methods that support fragmentation are designed to handle large payloads. Relying on this built-in feature is a more reliable and standards-based approach than relying on a network-layer workaround. Common appliances with RADIUS client capabilities (like switches and access points from Cisco, Aruba, and Juniper) have a feature to configure EAP fragmentation. Similarly, RADIUS servers like FreeRADIUS have a `fragment_size` setting to control the maximum EAP fragment size. It is important to note that not all vendors provide this functionality. For example, Meraki does not offer a user-configurable EAP fragmentation setting in its dashboard, which can be a significant limitation. *** ## Why Fragmentation Fails with CGNAT IP fragmentation is a common cause of authentication failures, especially on networks using Carrier-Grade NAT (CGNAT), such as Starlink. * **Fragment Dropping**: Many firewalls and CGNAT devices are not designed to handle fragmented packets efficiently. For security or performance reasons, they may drop the fragments or fail to reassemble them correctly. * **Packet Loss**: If even one fragment is lost during transit, the entire original UDP datagram cannot be reassembled by the server. Since UDP is connectionless and has no retransmission mechanism, the RADIUS server never receives a complete `Access-Request`, and the authentication fails. The lack of a retransmission mechanism for fragmented UDP traffic is the core reason IP fragmentation is an unreliable solution for authentication. This is why configuring EAP fragmentation is the correct solution. It ensures that the EAP messages are already in small pieces, preventing them from being fragmented at the IP layer. This bypasses the fragmentation issues caused by firewalls or CGNAT devices that drop fragmented traffic. *** ## Conclusion The interaction between large EAP-TLS certificate payloads and a network's MTU can be a hidden cause of authentication failures. While the RADIUS protocol relies on the network to handle fragmentation, firewalls and CGNAT devices often drop fragmented packets. By understanding the distinction between EAP and IP fragmentation, and by implementing the best practice of configuring EAP fragmentation on the authenticator and RADIUS server, you can ensure that authentication packets traverse the network intact. This deliberate, application-layer approach provides a robust and reliable solution, preventing common and frustrating connectivity issues. # FAQs # General ## Authentication #### How often is a device typically authenticating against RADIUSaaS? This is difficult to answer as it depends on the behavior of your users, clients, and networking gear (APs, NACs, switches). Additionally, it is **important** to note that RADIUSaaS will neither * trigger an authentication nor * send a termination request via its accounting port to the client, potentially triggering a re-authentication. If you feel your devices are authenticating very frequently (multiple times an hour) without the user constantly restarting the client, then this could be for the following reasons: * The network controller doesn't authenticate the client fast enough for the client to join the network, so the client attempts to authenticate again. Check the network controller to see if/when it is receiving an answer from RaaS. * The network controller is re-initiating authentication. Check the network controller for what might be causing this. ## RADIUSaaS Admin Portal #### How can I add the RADIUSaaS Admin Portal to My Apps? **Create the App** First, you have to create an Enterprise app. To do this via the Azure portal, follow these steps: 1. Login to your [Azure](https://portal.azure.com/) account 2. Go to **Microsoft Entra ID** 3. Select **Enterprise applications** 4. Click **+ New Application**

Showing creation of a new application

5. Click **+ Create your own application** 6. Give a name for the app (e.g. RADIUSaaS Portal) 7. Choose **Integrate any other application you don’t find in the gallery** and 8. Click **Create**
After that the app is set up, we now need to add users to it and configure the logo and link **Add Users and a Logo** 1. Under **Manage** go to **User and groups** - Add all users/groups who should be able to view/use your new URL tile and save

Click "User and groups"

2. Click **Properties** - Upload an image logo of your choice and save

Click "Properties"

3. Click **Single Sign-on** - Select **Linked** mode - Then enter the URL you want and save.

Click Single Sign-on - Select "Linked" mode

Enter your RADIUSaaS instance URL

Enter your RADIUSaaS instance URL

**Access My Apps** Your users should now be able to access the newly created link tile via [My Apps](https://myapps.microsoft.com/). ## RADIUS Return Attributes #### Which VLAN-related attributes does RADIUSaaS return by default? {% hint style="info" %} In case you require other VLAN attributes than returned by default, please [contact our support](https://www.radius-as-a-service.com/help/). {% endhint %} If VLAN tagging is enabled by configuring and enabling a relevant [Rule](/admin-portal/access-and-rules/rules#vlan-assignment), RADIUSaaS returns the following generic VLAN attributes `"Tunnel-Type": "VLAN"` `"Tunnel-Medium-Type": "802"` `"Tunnel-Private-Group-ID"` along with the other commonly used vendor-specific VLAN attributes: `"WiMAX-VLAN-ID"` `"Nexans-Port-Default-VLAN-ID"` `"Dlink-VLAN-ID"` `"UTStarcom-VLAN-ID"` `"DHCP-IEEE-802.1Q-VLAN-ID"` `"Motorola-WiMAX-VLAN-ID"` `"Telrad-C-VLAN-ID"` `"Telrad-S-VLAN-ID"` `"SN-Assigned-VLAN-ID"` `"Extreme-VM-VLAN-ID"` `"Ruckus-VLAN-ID"` `"Mikrotik-Wireless-VLANID"` `"Egress-VLANID"` `"HP-Egress-VLANID"` ## Secondary Instance and Failover #### How does a secondary instance behave in terms of failover? A secondary instance means that you have at least a secondary RadSec server that works independently of your main instance but has the same configuration. If you have one, you can see multiple IP Addresses under [RadSec IP Addresses](/admin-portal/settings/settings-server#properties). **RadSec Connection** Since the RadSec servers are independent of each other, they will not handle any kind of failover. You should add both IP addresses/DNS entries to your Network controller which decides to which server the authentication requests are forwarded. **RADIUS Connection** With your RADIUS proxies, it's a little different: Your proxies are aware of each of your RadSec instances and their health states and thus will handle failover if the primary server fails. ## Timers & Timeouts #### What EAP parameters and timeouts should be configured? Not every access point or switch (authenticator) provides you with the same amount of configuration options for EAP and general (RADIUS server) timeout parameters. Below overview presents the maximum set of parameters known to us and how they should be configured to allow for maximum reliability of the connection between the authenticator and RADIUSaaS. **RADIUS Server Timeout** 5 seconds **EAP Parameters**
EAP timeout15 s
EAP max retries5
EAP identity timeout10 s
EAP identity retries5
EAPOL key timeout2000 ms
EAPOL key retries4
## Logs #### How can I identify the public IP address of the site from which an authentication originates? To identify the public IP of the authenticating site for a particular authentication, the approach depends on whether you are using a RADIUS connection (via the RADIUS proxies) or a direct RadSec connection: **RadSec Connection** * Navigate to **Insights > Logs**. * Configure the relevant timerange / search window. * Set the **Logtype** filter to **details**. * Identify the relevant authentication (by correlating the timestamp and username). * Identify an `Access-Request` message (**message > Packet-Type** = **Acess-Request**) that belongs to the authentication under investigation. * Expand the respective log entry. * The public IP can be extracted from the **message > Packet-Src-IP-Address** property of the log entry.
**RADIUS Connection** * Navigate to **Insights > Logs**. * Configure the relevant time range / search window. * Set the **Log-type** filter to the **proxy**. * Identify the relevant authentication (by correlating the timestamp and username). * The public IP can be extracted from the **message** property of the log entry:
## Does RADIUSaaS support WPA3 Enterprise? Yes, RADIUSaaS supports WPA3 Enterprise. It also supports WPA3 Enterprise 192-bit mode with the following limitation: **Windows 11 24H2** introduced stricter certificate requirements for WPA3-Enterprise 192-bit encryption, leading to authentication failures if the entire certificate chain does not meet specific cryptographic strength standards. This update mandates RSA key lengths of at least 3072-bits or ECDSA with the P-384 curve for all certificates involved in the authentication process. Organizations using certificates with weaker parameters, such as RSA 2048-bit, may encounter issues. While SCEPman supports 4096-bit RSA keys for Windows, this is limited to the Software Key Storage Provider (KSP), as the hardware TPM does not support this key size. If after upgrading to Windows 11 24H2 you experience authentication issues, look for "SEC\_E\_ALGORITHM\_MISMATCH" errors in the Event Viewer (System Logs and CAPI2) as an indicator for incompatibility in the cryptographic algorithms between the client and the server. ### What can I do if I want to use WPA3-Enterprise authentication on Windows? Your current option moving forward is to address the certificate requirements for WPA3-Enterprise 192-bit on your Windows 11 24H2 clients. This includes updating the Leaf Certificate to meet the new minimum requirements. Please note that Intune does not currently include an option in its SCEP profile to specify a key size of 3072-bits which could be stored in the Trusted Platform Module (TPM) of the receiving computer. Due to this limitation, currently the only feasible solution for Windows clients is to use 4096-bit RSA key enrolled in Software Key Storage Provider (KSP). {% hint style="success" %} As Intune's WiFi profile only provides WPA2-Enterprise you will need to use an external tool to create a WPA3-Enterprise WiFi profile. For convenience, RADIUSaaS includes this tool [here](https://docs.radiusaas.com/admin-portal/settings/trusted-roots#xml). {% endhint %} ## Identity Providers ### **Does RADIUSaaS support Okta as an identity provider?** * **Yes** for admin & users login to the web-console * **No** for authentication via the RADIUS protocol #### **User and admin Portal (web-console) login** Okta is fully supported as an identity provider for signing in to the RADIUSaaS Web Portal. RADIUSaaS does not maintain its own administrator identities and instead delegates authentication to your existing identity provider, so administrators, viewers, and invited users can log in with their Okta accounts. Okta is integrated through the **Custom OIDC Provider** option in the [Permissions](/admin-portal/access-and-rules/permissions#custom-oidc-provider-okta) section. Step-by-step setup instructions, including the required redirect URI, authentication and token URLs, client ID, client secret, and `openid email` scope, are documented in the [Permissions](/admin-portal/access-and-rules/permissions#overview) article. #### **RADIUS protocol authentication (Wi-Fi, wired 802.1X, VPN)** Okta is **not** supported as an identity provider for authentication that takes place over the RADIUS protocol. As described in the [Users](/admin-portal/users/users) section, RADIUSaaS does not integrate with any external IDP for username/password-based network authentication. All username/password accounts used for RADIUS authentication must be created and managed directly in the RADIUSaaS Admin Portal. {% hint style="info" %} For RADIUS-based network authentication, we generally recommend **against** username/password approaches that rely on an external identity provider. Such setups require credentials to be transmitted or relayed during the network authentication and broaden the attack surface in ways we consider a relevant security risk. Wherever possible, use **certificate-based authentication** (EAP-TLS) instead. For background and a detailed explanation of the risks of password-based network authentication, see [Certificate-Based Network Authentication](https://www.scepman.com/certificate-network-authentication/). {% endhint %} # Log & Common Errors This page gives you guidance on how to interpret one of the below error messages. ## No EAP session matching state {% hint style="info" %} Severity: Low / No Impact {% endhint %}
Corresponding error messages: * "No EAP session matching state" * "Unable to set parent list" The RADIUS protocol is stateless and since it is normally transmitted over UDP, it has to validate if all packages have arrived, if their integrity persists, if they can be correctly assembled in the correct order, etc., essentially mitigating the flaws of the UDP protocol. Each authentication request goes through a process of steps that must be performed (e.g. association, request, challenge, challenge-response). For these steps, both sides (client and server) have a state that is included in the packet sent and a state that is stored locally. These states must match the step that client and server are currently in, respectively. The error message indicates that one of the actors (client, server) has sent or received a packet that does not match the expected state. These errors happen from time to time as UDP cannot guarantee that packets are always delivered (correctly or at all). In most cases this is not a problem because the RADIUS protocol handles these errors and re-initiates the connection without the computer that is trying to log in noticing. If the devices are able to connect eventually without noticeable delays, such errors can be ignored. If this is not the case, try [increasing your EAP timeouts](/other/faqs/general#what-eap-parameters-and-timeouts-should-be-configured). ## Proxy Session Resumption {% hint style="info" %} Severity: Low / No Impact {% endhint %}

tlsclientrd: connection to server server-tls-secondary3 lost

Your proxies will create a TCP session with your RadSec server(s). These sessions have to be reinitiated every 30 seconds. As long as there is no error within those messages, these log entries are expected. ## Error in error {% hint style="info" %} Severity: Low / No Impact {% endhint %}
Since your RadSec server(s) are globally available, anyone on the Internet can try to connect to them, e.g. using a TCP handshake. If no valid (mututal) TLS connection can be established (which only works if the connecting entity presents a trusted RadSec client certificate), this error message is generated and expcted. Since RADIUSaaS cannot distinguish between someone crawling/port-scanning servers on the internet and a legit authenticator that is simply misconfigured, RADIUSaaS does not suppress these log entries. This means, if your infrastructure is working fine, you may ignore these log entries. ## Certificate status was revoked previously {% hint style="info" %} Severity: Low / No Impact {% endhint %}
If a certificate is found to be revoked, this status will be cached for 2 minutes. Additional attempts to authenticate this certificate will directly be rejected without performing another OCSP request. This is done to reduce the load on the OCSP responder. The `Verify-Description` field will contain the correlation ID of the initial rejected request.
# MAC Authentication Bypass This article aims to clarify what MAC Authentication Bypass is, how it differs from MAB-to-EAP, and which one works with RADIUSaaS. {% hint style="danger" %} Since **MAC addresses can be easily spoofed**, implementing a MAC authentication bypass is **strongly discouraged** unless absolutely necessary and the administrator has weighed the risk associated with implementing such a bypass against the convenience and budgetary constraints of upgrading outdated hardware. {% endhint %} ## Overview **MAC Authentication Bypass (MAB)** is a feature that enables devices unable to perform standard 802.1X enterprise authentication (such as legacy printers, simple sensors, or embedded systems) to connect to an otherwise secure network. MAB grants access by using a device's unique MAC address as its sole identifier against an authorised list maintained by a RADIUS server. The legacy implementation of MAB is **vulnerable to MAC address spoofing both on** the connection between the authenticating and the network device and on the connection between the network device and the RADIUS server. To eliminate the second attack vector, a stronger implementation of MAB, called **MAB-to-EAP**, can be used, which effectively ensures the integrity of the MAC address transmitted to the RADIUS server (the MAC address can still be spoofed on the link between the authenticating and network device). This guide details the differences between the insecure legacy method **Pure MAB** and the modern, transport-secured workaround. ## MAB Terminology and Implementations **MAB:** MAC Authentication Bypass **EAP:** Extensible Authentication Protocol **Supplicant:** The entity (such as a laptop, phone, or network interface) that initiates the authentication process with an Authenticator to gain access to a network. **Authenticator:** A network entity (such as a switch, wireless access point, or VPN gateway) that enforces authentication before granting a Supplicant access to the network. **Authentication Server:** A trusted network entity (such as RADIUS server) responsible for verifying the identity of Supplicants by checking their credentials (such as usernames, passwords, or digital certificates) and determining whether they are authorised to access the network. **Pure MAB** (Legacy Implementation): This method involves the Authenticator sending the client's MAC address to a RADIUS server, usually in the `Calling-Station-Id` RADIUS attribute. The RADIUS server performs a simple lookup and returns an `Access-Accept` or `Access-Reject`. The MAC address acts as the identifier, not a true credential. **MAB-to-EAP** (Secured Implementation): Because Pure MAB lacks cryptographically secure transport, many modern services (like RADIUSaaS) require a stronger approach. In this method, the Authenticator uses the client's MAC address as both the username and password and then attempts to authenticate to the RADIUS server using a secure EAP protocol (e.g., EAP-TTLS-PAP, PEAP-MSCHAPv2). The client device remains oblivious that any authentication has occurred. ## How Pure MAB Works (External RADIUS Database) When the MAC address database is maintained by an external RADIUS server (the common enterprise setup), the following sequence applies for Pure MAB: 1. A non-802.1X client connects and requests network access. 2. The Authenticator detects the connection and, seeing no 802.1X negotiation, initiates an MAB attempt. 3. The Authenticator takes the client's MAC address (e.g., `00:11:22:33:44:55`) and forwards it to the RADIUS server in an `Access-Request` message. The MAC address is typically parsed into the `Calling-Station-Id` RADIUS attribute. 4. The RADIUS server checks its configured database for the presence of the MAC address. 5. It returns an `Access-Accept` message if the MAC is found (Match) or an `Access-Reject` if it is not found (No Match). 6. If `Access-Accept` is received, the Authenticator authorises the port and allows the client to join the network. ### Security Considerations In general, **MAB provides little to no security** and should be used with extreme caution. * **MAC Spoofing:** MAC addresses are easily changed (spoofed) on most modern computers and network cards. A malicious actor can observe the MAC address of an authorised device and configure their own device to use it, thereby gaining unauthorised access. * **Identification, Not Authentication:** MAB is merely a form of device identification. It only confirms which device is connecting, not who owns it or if it is cryptographically secure. Because of these weaknesses, most modern cloud-based authentication services (like RADIUSaaS) do not support Pure MAB or legacy protocols like PAP or CHAP. Instead, they require the MAB-to-EAP method where the MAC address is used as credentials within a cryptographically strong EAP tunnel. ## MAB Implementation with EAP (a RADIUSaaS Approach to MAB) When MAB is configured on an Authenticator and a legacy device that does not support 802.1X tries to request network access, the switch or AP will pretend to be that device and takes over the authentication on behalf of the client by authenticating to RADIUSaaS using one of the supported EAP [protocols](https://docs.radiusaas.com/admin-portal/users#protocols): EAP-TTLS-PAP or PEAP-MSCHAPv2. As part of this process, RADIUSaaS will check if the MAC address is listed in the RADIUSaaS database in the form of a manually added [User](/admin-portal/users/users). (username = password = MAC address), If so, then an `Access-Accept` message is returned, and the EAP-based authentication completes giving the legacy device network access. Since the Authenticator is establishing a TLS connection to RADIUSaaS, it must trust the [Server Certificate](/admin-portal/settings/settings-server#server-certificates) RADIUSaaS uses. The use of the MAC address as username/password to trigger EAP is a specific workaround implemented by the Authenticator to simulate MAB while utilising stronger EAP protocols. ### Does MAB work with RADIUSaaS? MAB in its original implementation using PAP or CHAP does not work with RADIUSaaS. With the above definitions in mind, the current implementation of RADIUSaaS can support MAB as long as your Authenticator can authenticate via one of the aforementioned protocols. Keep in mind that as soon as these supported protocols are used in the authentication, we no longer bypass authentication, and this is when the more specific term of MAB-to-EAP is used. ### Configuration **MAB** requires configuration on both the Authenticator and the Authentication Server. **Authenticator:** * Enable 802.1X and MAC Authentication Bypass (MAB) on the specific access ports/SSIDs meant for non-802.1X devices. * Trust the [RADIUS server certificate](/admin-portal/settings/settings-server#download). * *Note: Configuration steps are vendor-specific; refer to your device documentation.* **Authentication Server:** * When implementing MAB-to-EAP, you must create an explicit authorisation rule on RADIUSaaS to assign all devices authenticating via this method to a fallback VLAN with minimal network access. This is essential to enforce the principle of least privilege, preventing a bad actor who has spoofed a valid MAC address from accessing critical network resources. The rule should be configured based on your environment's authentication policies: * If MAB-to-EAP is the only use for username/password-based authentication: Create a broad authorisation rule (LAN/Wi-Fi) that assigns any device using this credentials type to the fallback VLAN. * If username/password is used for other clients (e.g., users): This rule must be carefully tuned using regular expressions to specifically match the pattern of a MAC address in the username field (e.g., `00:11:22:33:44:55`). This ensures only MAB-to-EAP traffic is isolated to the fallback VLAN. * To support MAB-to-EAP, you must [add](/admin-portal/users/users#add) users formatted as: Username = Password = MAC address. Example: `00:11:22:33:44:55` = `00:11:22:33:44:55`. * The MAC address format (colon, hyphen, or none) must exactly match the format your Authenticator sends in the EAP credentials. We recommend using colon notation (e.g., `00:11:22:33:44:55`) for consistency. * If you have multiple users, you can import them in bulk using a [CSV](/admin-portal/users/users#csv-import) file.
# Blast-RADIUS Vulnerability ## What is this about? Earlier this year, a group of RADIUS experts identified a vulnerability in the RADIUS protocol. Hackers can exploit this vulnerability to gain access to networks protected by RADIUS systems. For more information about this vulnerability, visit . This site also contains a comprehensive paper on the background called "RADIUS/UDP Considered Harmful". The vulnerability is also documented as [CVE-2024-3596](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-3596): > RADIUS Protocol under RFC 2865 is susceptible to forgery attacks by a local attacker who can modify any valid Response (Access-Accept, Access-Reject, or Access-Challenge) to any other response using a chosen-prefix collision attack against MD5 Response Authenticator signature. ## Is RADIUSaaS affected? {% hint style="success" %} RADIUSaaS is not affected by the Blast-RADIUS vulnerability. {% endhint %} RADIUSaaS only supports EAP-based authentication protocols. If EAP is properly implemented in all components of your infrastructure, the mechanism described in this vulnerability will not be effective. ## Since RADIUSaaS is not affected, is my whole environment OK? It is important that all components in your environment have proper implementations. We recommend that you check with your network equipment vendor to ensure that they have updated their systems, if needed. # OCSP Soft-fail Consequences This page provides an overview on the pros and cons in the terms of OCSP Soft-fail mechanism. Before we dive into the pros and cons let's start by quickly recapping what the setting means: Please note: All of those examples describe the behaviour of an authentication where the supplicant has a valid certificate (not expired, issued by a trusted CA). #### Soft-fail = Enabled If a problem occurs when querying the OCSP responder such as a timeout or incorrect data, the application treats the certificate revocation status as '**good**'. #### Soft-fail = Disabled If a problem occurs when querying the OCSP responder such as a timeout or incorrect data, the application treats the certificate revocation status as '**revoked**'. If you use **OCSP-Autodetect** and the client certificate does not include an OCSP responder URL, the application treats the certificate revocation status as '**revoked**'. ## Pros and Cons ### Soft-fail Enabled #### Pros 1. **Higher Availability & Fewer Disruptions** * Users are less likely to experience sudden authentication failures due to transient network issues or temporary OCSP responder outages. * Improves user experience and reduces support calls related to “can’t connect” issues caused solely by OCSP connectivity or service problems. 2. **Better Tolerance of OCSP Service Outages** * If the OCSP hosting provider experiences downtime or certificate-related issues, authentications will still succeed. 3. **Minimal Impact on Business Continuity** * Especially important in environments where downtime has a high cost (e.g., critical infrastructure, emergency services, or 24/7 businesses). #### Cons 1. **Security Risk: Revoked Certificates May Be Accepted** * A failure in the RADIUS server's revocation status verification, due to OCSP unavailability or other issues, will result in the acceptance of a revoked certificate. * This undermines the trust model of certificate-based authentication and can be exploited if an attacker deliberately forces OCSP failures. 2. **Lack of Visibility Into System-wide Issues** * If the system silently bypasses revocation checks, administrators might not immediately notice that an OCSP responder is down or misconfigured, prolonging the vulnerability window. ### Soft-fail Disabled #### Pros 1. **Higher Security Assurance** * Ensures that any certificate that cannot be positively validated against the OCSP responder is rejected. * Protects against usage of revoked, or otherwise compromised certificates. 2. **Clear Operational Signals** * If authentication suddenly starts failing, it forces quick attention to OCSP availability or configuration problems. * Administrators become immediately aware of any connectivity or trust chain issues because no user can authenticate unless the OCSP check is successful. #### Cons 1. **Single Point of Failure** * If the OCSP responder is down, DDOS attacked, unreachable, or misconfigured, **all** valid certificate authentications fail. * Can cause significant business disruption and a flood of support calls. 2. **Reliance on OCSP Service Uptime** * Implies your OCSP service must be highly available and robustly monitored. * Requires thorough failover planning (e.g., multiple OCSP responders, load balancing, or redundancy) to prevent massive outages. * Requires planning for updating the responder 3. **Possible Frustration for Users** * Users can’t connect even when they have perfectly valid certificates, simply because the OCSP check can’t complete. # Security & Privacy This chapter provides an overview on frequently asked questions surrounding information security, privacy and quality assurance. ## Data Processing and Permissions ### 1. From what data center is RADIUSaaS operating? RADIUSaaS' core service can currently be deployed in the following regions: * Australia * Europe * United Kingdom * United States of America In case RADIUS proxies are required, they can be deployed in the following countries/regions: | Continent | Region | | ------------- | ------------------------------------------------------------------- | | Africa | Johannesburg | | Asia |

Bangalore
Singapore
TelAviv
Tokio
Seoul
Osaka

| | Australia |

Sydney
Melbourne

| | Europe |

Frankfurt
London
Madrid
Stockholm

| | North America |

Dallas
New York
Seattle
Toronto

| | South America |

Santiago
São Paulo

| ### 2. Which data is processed by RADIUSaaS? #### **Certificates** RADIUSaaS processes X.509 user or device certificates to validate the authenticity of the authentication request. As part of the certificate, every attribute can be processed, potentially containing information such as: * Username * Email * UPN #### **RADIUS Protocol** RADIUSaaS relies on the RADIUS protocol, e.g. the following data is visible to RADIUSaaS: * Client MAC address * NAS (e.g. access point, switch, ...) MAC address * WiFi SSID * Vendor-specific data (e.g. VLAN, tunneling-group, ...) * NAS IP address * ISP-assigned public IP address * RADIUS Shared Secret (only relevant if RadSec is not natively supported) * Private key of the RADIUS server certificate #### **Miscellaneous** RADIUSaaS (optionally) provides functionality to generate username + password pairs for network access. Those credentials are stored and processed by the service as well. ### 3. Which data is persistently stored by/on behalf of RADIUSaaS and how? 1. Permissions The RADIUSaaS platform stores UPN/email information on the users that are allowed to access the platform. **No passwords are stored or processed by RADIUSaaS.** 2. Logging For troubleshooting and analysis purposes, the RADIUSaaS platform logs all relevant data it processes (see [Question 2](#2.-which-data-is-processed-by-radiusaas) except for the RADIUS Shared Secret and the private key of the server certificate). The logs are stored directly on the RADIUSaaS platform within an *Elasticsearch* database and segregated for every client via a dedicated space.\ \ **Log retention time: 75 days.** 3. Certificates RADIUSaaS requires several server certificates as well as root certificates to facilitate proper operation. All those certificates are securely **stored in an Azure KeyVault**. 4. The optional username + password credentials mentioned in [Question 2](#2.-which-data-is-processed-by-radiusaas) are **stored in an Azure KeyVault**. 5. Other secrets and configuration data Other secret data, e.g. the RADIUS Shared Secret as well as the service's configuration are securely **stored in an Azure KeyVault**. ### 4. Is there an archiving mechanism for logs? There is no built-in log archiving mechanism. However, the [Log Exporter](/admin-portal/settings/log-exporter) feature can be used to ingest RADIUS logs into your own logging and archiving services. ### 5. Which tenant permissions do users accessing the RADIUSaaS web portal have to consent to? 1. `Basic User Profile`: With this permission RADIUSaaS retrieves the user's UPN that tries to log on to the RADIUSaaS Admin Portal. 2. `Maintain access to data you have given it access to` With this permission RADIUSaaS receives the right to request a refresh token so that the user can stay logged-on. Please see [here](/admin-portal/access-and-rules/permissions#permissions-consent) for details. ### 6. What data is made available by granting the consent(s) from 5.? 1. `Basic User Profile`: For details on what data can be retrieved, please refer to this article: 2. `Maintain access to data you have given it access to` No specific data is made available by granting consent to this permission. ### 7. Which externally accessible endpoints does RADIUSaaS expose? 1. RADIUS Server Backend API * Provides configuration information to the RadSec proxy. 2. RADIUS and RadSec Server Ports * To facilitate network authentication from anywhere on the internet, these authentication interfaces have to be publicly exposed. 3. RADIUSaaS Admin Portal * A web portal which facilitates the administration of the service. 4. Kubernetes Cluster Management API * Required to operate the service. ### 8. How are the endpoints from Question 7 protected? 1. RADIUS Server Backend API * Secured via JWT access tokens that can be managed (issued, deleted, revoked) by the customer. 2. RADIUS Proxy and RadSec Server Ports * RadSec server ports: TLS-secured (>= version 1.2). * RADIUS proxy server ports: Protected via the RADIUS Shared Secret. 3. RADIUSaaS Admin Portal * Secured via OAuth 2.0 authentication against one of our [supported IDPs](/admin-portal/access-and-rules/permissions#supported-idps). 4. Kubernetes Cluster Management API * TLS-secured (>= version 1.2). ### 9. What ports and protocols are used by the endpoints from Question 7? * RADIUS Server Backend API * HTTPS (TCP / 443) * RADIUS Proxy and RadSec Server Ports * RadSec server ports: RadSec (TCP / 2083) * RADIUS proxy server ports: RADIUS (UDP / 1812, 1813) * RADIUSaaS Admin Portal * HTTPS (TCP / 443) * Kubernetes Cluster Management API * HTTPS (TCP / 443) ## Identity ### 1. What authorization schemes are used to gain access to RADIUSaaS? * Administrative access is realized through OAuth 2.0 authentication against an [IDP](/admin-portal/access-and-rules/permissions#supported-idps) for identities or accounts that are registered on the platform. ### 2. Are there conditional access / role-based access controls in place to protect RADIUSaaS? * Yes. The RADIUSaaS Admin portal provides features to assign roles to every user (available roles: administrator, viewer, guest). * In order to properly operate and maintain the service, there are super-admin accounts for a limited circle of glueckkanja AG employees, that have full access to all client instances of the RADIUSaaS service. ### 3. Can access credentials be recovered? If yes, how? * Login credentials: Depends on the configured Microsoft Entra ID (Azure AD) policies in the customer tenant. * Username + password credentials as well as all certificates for network access can be recovered from Azure KeyVault with a retention policy of 90 days after they have been deleted. ### 4. What to do to recover lost access to the RADIUSaaS instance? * If your business lost access to RADIUSaaS instance because the previous administrator(s) left or the UPN / domain has changed, the easiest way to recover access is to re-create a user account that matches the existing UPN at RADIUSaaS > Permissions > Administrators. This is by far the fastest approach, since it does not require any actions on our side. * If the above is not feasible, recovering access to the portal will be subject to a rigorous identity verification process that is not only time-consuming but will require significant effort from both sides. There is a one-time fee of 420.00 EUR (excl. VAT) for this process. To start the process, please create a technical support ticket. * To prevent loss of access to your RADIUSaaS tenant, please follow our best practices by carefully working through each step of our [Getting Started Guides](/configuration/get-started). ## Data Protection ### 1. How is *data at-rest* protected against unauthorized access? #### **Configuration Data and Secrets** * Configuration data is stored in Azure KeyVault and protected via access credentials that are in turn stored as *Kubernetes Secrets*. #### **Kubernetes Service** * The volumes and disks used to host our service are [encrypted](https://learn.microsoft.com/en-us/azure/aks/enable-host-encryption). #### **Logs** * The Elasticsearch Database is hosted on the encrypted Kubernetes Service disks. * The logs are stored in an Elasticsearch Database and segregated via dedicated spaces. * Access to those spaces is given via username + password credentials that are in turn stored as *Kubernetes Secrets*. * The Elasticsearch Database itself is not encrypted. ### 2. How is *data in transit* protected against unauthorized access? * The authentication flows of the device trying to access the network are wrapped into a TLS-tunnel (>= TLS 1.2). * The association between NAS and the RADIUS server is obfuscated via the RADIUS Shared Secret (MD5 hash algorithm). ### 3. How are customer tenants separated from each other? #### Backend RADIUSaaS backend services run on multiple Kubernetes clusters that are distributed worldwide. Every customer's RADIUSaaS instance has their own K8s namespace, logging space and dedicated public IP. There is an Elasticsearch instance with dedicated customer accounts for logging and reading per cluster. #### RADIUS proxies Every RADIUSaaS proxy runs on its own VM with dedicated public IP. ## Security by Design ### 1. Does RADIUSaaS employ a defense in depth strategy? RADIUSaaS relies on well-established protocols to handle network authentication flows (RADIUS, RadSec, EAP-TLS, EAP-TTLS-X). Due to the strong focus on certificate-based authentication, capturing the traffic is meaningless as long as the eavesdropper does not have access to a trusted certificate. ### 2. Is the UDP-based RADIUS protocol secure? We are recommending to use the modern [RadSec](/overview#what-is-radsec) protocol to authentication against RADIUSaaS. However, there are many network infrastructure components still out there, which do not support RadSec. The following diagram shows the RADIUS authentication flow: ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/byiGM49uzq0vRK6ny2KM/radius-authentication-sequence.png) In the first part of the authentication sequence, the communication is secured by an MD5-based hashing algorithm (partially encrypted with the shared secret). **No secrets** are transported in this phase. In the second part of the authentication sequence, a TLS-based EAP (e.g. EAP-TLS) encrypts the traffic. The EAP-TLS traffic is then transported via UDP to the RADIUS proxy. This is the phase when credentials such as the certificate or the password is exchanged with RADIUSaaS. If you use certificate-based authentication, no secrets are transported in this phase as only the public key is exchanged. The private key remains on the client device at all times. A comprehensive comparison between RADIUS and RadSec in terms of transport security is provided [here](/other/faqs/security-and-privacy/transport-security-in-radius-vs.-radsec). {% hint style="success" %} Conclusion: UDP-based RADIUS authentication with RADIUSaaS is secure, since * the relevant traffic is encrypted\ and * additionally there are no secrets transported, if certificate-based authentication is used. {% endhint %} ### 3. What technologies, stacks, platforms were used to design RADIUSaaS? * `Kubernetes` * `EFK Stack (Elasticsearch, Filebeats, Kibana)` * `Python` * `Azure (KeyVault)` * `TerraForm` * `Git CI` ## GDPR and Data-residency ### 1. Is data leaving Europe? * Core Services: Depends on configuration * RADIUSaaS's core services can be hosted in the data centers described in [Question 1](#1.-from-what-data-center-is-radiusaas-operating). * If the service is hosted in a European data center, then no data leaves the European Union. * RadSec Proxy: Depends on configuration * If you require a RadSec proxy due to limitations of the network gear in regards to native RadSec support, you may select a proxy from various regions, Europe amongst others. In that case, your data stays within the borders of the European Union. ### 2. What 3rd-Party cloud-providers does RADIUSaaS rely on and why? | Company | Services | Contact | Purpose | | ---------------------------------------------- | ---------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | --------------------------------------------------------------- | | Microsoft Corporation | Cloud Services (Azure) |

Building 3, Carmanhall Road Sandyford,
Industrial Estate 18, Dublin,
Ireland

| Kubernetes Service, networking, storage | | Digital Ocean, Inc. | Cloud Services |

Y101 6th Ave,
New York City,
NY 10013,
United States

| Kubernetes Service, networking, storage, VMs for RADIUS proxies | | Vultr (trademark of The Constant Company, LLC) | Cloud Services |

319 Clematis Street - Suite 900
West Palm Beach, FL 33401,
United States

| VMs for RADIUS proxies | | GitLab, Inc. | git code repository, integration, testing and release automation |

268 Bush Street #350,

San Francisco,

CA 94104-3503, United States

| Code repository, CI/CD pipeline. | ## Miscellaneous ### 1. Is RADIUSaaS part of a bug-bounty program? No ### 2. What QA measures are in place? * There are dedicated RADIUSaaS labs for development purposes * The deployment and installation of the service is realized through TerraForm, ensuring consistency and idempotence of each instance deployment * Kibana APM is used for service health measurement and alert management * Digital Ocean monitoring supervising the RadSec proxies * Each production release must go through the internal channel first, passing the relevant QA hurdles as part of our CI process * Unit tests * Peer review (six-eye-principle) * Integration tests * Stress tests * Experience-based testing ### 3. Do you regularly perform penetration tests? No. As part of our Secure Development Practices, we employ tools (e.g. static code analysis) that scan the code base for CVEs and other common exploits (including dependencies such as 3rd party libraries) that could impact the security of the endpoints RADIUSaaS exposes. Before any release, any relevant findings are assessed and remediated, to ensure RADIUSaaS remains free from any known vulnerabilities. We neither perform penetration tests ourselves, nor do we use 3rd party "Penetration Test-as-a-Service" tools. For the former, we see an inherent conflict of interest. For the latter, since typical penetration test services often simply check the exposed endpoints against CVEs and other known exploits, we do not see any added value to the checks we already perform using static code analysis. If you wish to perform your own penetration tests, please [reach out to us](https://support.radiusaas.com/support/tickets/new?ticket_form=technical_support_request_%28radiusaas%29) and tell us about your requirements. ### 4. Is there a patching process in place? Yes. Patches, hot-fixes, bugfixes and feature updates are introduced using our CI/CD process that leverages different testing pipelines to ensure that only code that satisfies our QA hurdles gets released. Newly released code is automatically made available to all our customers. Using Infrastructure as Code (Terraform) enables us to deliver consistent, reproducible and high-quality updates to our customers. The Kubernetes-based architecture of our service ensures that code updates are seamless for our customers and do not lead to any service outages. ### 5. What are the SLAs for patches? * Patches for CVEs / security vulnerabilities: Once the vulnerability becomes public knowledge or as soon as we identify a vulnerability within our own code, a hot-fix will be provided no longer than 24 hours after we have become aware of the vulnerability. * Other patches: No SLA. ### 6. Does RADIUSaaS perform backups? #### Secrets and configuration data We leverage Azure KeyVault to securely store secrets (e.g. certificates) and all other configuration data of the service. Azure KeyVault is a highly-available [geo-redundant service](https://learn.microsoft.com/en-us/azure/key-vault/general/disaster-recovery-guidance) that replicates all of its content in a second datacenter, thus providing implicit back-up services. #### RADIUS and RadSec servers Stateless. No back-up required. #### Logs Currently not backed-up. ### 7. Are there backup restore tests? Yes. The restoration from back-ups is tested with every update/release of the service. There are approximately 4 - 8 releases per year. # Transport Security in RADIUS vs. RadSec When deploying secure authentication using Extensible Authentication Protocol (EAP), the choice of transport protocol - RADIUS over UDP vs. RADIUS over TLS (RadSec) - plays a critical role in determining how securely metadata and protocol elements are transmitted across the network. Both RADIUS and RadSec can carry EAP messages including those used in common methods like EAP-TLS, PEAP, and EAP-TTLS. While the inner workings of the EAP method remain the same, the transport protocol impacts visibility, integrity, confidentiality of metadata, and operational behaviour. This document compares how RADIUS and RadSec affect EAP transport - focusing on encryption, shared secret usage, attribute exposure, logging implications, and deployment considerations. *** ### Transport Security: Core Differences EAP methods such as EAP-TLS, PEAP, and EAP-TTLS provide authentication mechanisms between clients (supplicants) and authentication servers. However, these methods do not inherently encrypt the transport of metadata between intermediate nodes. This role falls to the transport layer protocol: * RADIUS (UDP) transmits EAP messages and RADIUS attributes in plaintext. * RadSec (TLS) encrypts the entire RADIUS packet, securing all attributes and protocol headers during transit. The table below summarises these differences which affects confidentiality of attributes such as outer identity, NAS IP, calling station ID, and more. While EAP methods may encrypt user credentials (e.g., certificates or passwords), metadata remains exposed over standard RADIUS unless RadSec is used. | Protocol | RADIUS | RadSec | | ------------------------ | ---------------------------------------- | ------------------------------------- | | Transport Layer Protocol | UDP (typically) | TLS over TCP | | Encryption | No transport encryption | Full transport encryption | | Default Port\* | UDP 1812 | TCP 2083 | | Notes | Stateless; may be filtered by firewalls. | Stateful; establishes secure tunnels. | \*While these ports are the recognised standards, some deployments may customise them for local policy or infrastructure reasons. *** ### The Role of the RADIUS Shared Secret in Both Protocols The RADIUS shared secret is used for packet integrity and legacy encryption behaviours. This applies regardless of whether the transport is standard RADIUS or RadSec. **Key uses:** * **Message-Authenticator AVP**: Ensures packet integrity using HMAC-MD5. * **User-Password AVP (legacy methods)**: Encrypts credentials using the shared secret. * **RadSec compatibility**: Even in RadSec, the shared secret is maintained for compatibility with RADIUS semantics and intermediate systems. {% hint style="info" %} **Note:** The shared secret is never transmitted over the network - it is used locally for HMAC operations and AVP validation. {% endhint %} *** ### Data Element Visibility: RADIUS vs. RadSec This table compares key data elements when using EAP-TLS over RADIUS (UDP) and RadSec (TLS), grouped by visibility risk during transmission.
Data ElementRADIUS (UDP)RadSec (RADIUS over TLS)Example / Notes
Outer RADIUS packetClear text (over UDP or TCP).Encrypted (over TLS).Includes both headers and AVPs. E.g., packet visible in Wireshark or tcpdump.
User identity (outer identity)Sent in clear text.Encrypted (over TLS).anonymous@organisation.com used for realm routing.
RADIUS AVPs (Attributes)Some in clear text (e.g., NAS-IP, User-Name).Fully encrypted in TLS.

NAS-IP-Address,

Calling-Station-Id

RADIUS headersClear textEncrypted in TLS

Code (Access-Request), Identifier,

Length,

Authenticator

RADIUS shared secretNot transmitted (used internally)Not transmitted (used internally)Used for AVP encryption and Message-Authenticator validation.
EAP payload Encrypted between client and serverEncrypted in TLSIncludes TLS handshake, certificate validation, etc.
User credentials (certificates/keys)Encrypted in EAP tunnelEncrypted in EAP-tunnel + TLSApplies to certificate-based (EAP-TLS) and password-based (PEAP) methods. Client certificate with subject CN=jsmith, OU=IT
Password (e.g., PEAP or MSCHAPv2)Encrypted in tunnelled method (e.g., PEAP)Encrypted in EAP tunnel + TLSApplies to password-based methods.
*** ### Identity Privacy: Outer vs. Inner Identity EAP methods that use tunnelling or certificates (e.g., PEAP, EAP-TTLS, EAP-TLS) support outer and inner identities: * **Outer Identity**: Sent in the clear in the User-Name AVP to facilitate realm routing. Often anonymised (e.g., `anonymous@domain.com`). * **Inner Identity**: Carried securely inside the encrypted EAP tunnel (e.g., username/password, certificate CN). #### Behaviour across transports: * In **RADIUS**, the outer identity is sent in plaintext and is visible on the wire. * In **RadSec**, the entire packet including the outer identity is encrypted. Privacy concerns related to the Outer Identity being transmitted in plaintext with RADIUS can be mitigated by configuring identity privacy or leveraging device certificates that do not contain PII data in the common name attribute {% hint style="info" %} **Note**: Some platforms, like Windows’ native EAP client, may not support identity privacy by default in methods like EAP-TLS, potentially exposing the real identity in the outer layer. {% endhint %} #### Outer Identity The table below provides an overview on the typical values various OS platforms populate the Outer Identity with. | Credential Type | Outer Idenity | Applicable OS | | ------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Username/Password |



Typically:
- UPN
- Email Address

|
  • Windows
    (can be anonymised)
  • iOS, iPadOS, macOS
    (can be anonymised)
  • Android
    (can be anonymised)
| | Device Certificate |

Common name (CN) property of the client certificate's subject name.

Typically:
- DeviceName
- Intune Device ID (GUID)
- AAD Device ID (GUID)

|

  • Windows
    (cannot be anonymised) \*
  • iOS, iPadOS, macOS
    (can be anonymised)
  • Android
    (can be anonymised)
| | User Certificate |

Common name (CN) property of the client certificate's subject name.

Typically:
- UPN
- Email Address

|

  • Windows
    (cannot be anonymised)\*
  • iOS, iPadOS, macOS
    (can be anonymised)
  • Android
    (can be anonymised)
| \*The EAP client used in Windows does not support identity privacy for EAP-TLS. *** ### Logging and Deployment Considerations #### RadSec (TLS) RadSec encrypts the entire RADIUS packet, which prevents passive eavesdropping. This shifts logging and diagnostics from network inspection to the application or RADIUS server level, as these are the endpoints that terminate the TLS session. Organizations transitioning to RadSec should evaluate monitoring workflows to accommodate encrypted traffic. #### RADIUS (UDP) The plaintext transmission of attributes (User-Name, NAS-IP-Address, etc.) simplifies troubleshooting and live diagnostics, enabling packet capture with minimal tooling. However, this increases the exposure risk of sensitive metadata during transit. #### Network Support Support for RadSec is not universal across all network devices and infrastructure. Many network switches, wireless access points, and firewalls support only traditional RADIUS. In mixed environments, a RadSec-to-RADIUS proxy may be needed to bridge modern and legacy components. Infrastructure assessments are recommended before deploying RadSec in production. *** ### Conclusion and Key Takeaways Transporting EAP methods over either RADIUS or RadSec offers the same strong end-to-end protection for user credentials but differs significantly in how metadata and protocol elements are exposed during transit. * **EAP End-to-End Protection**: EAP provides strong protection for user credentials over both RADIUS and RadSec. * **Primary Difference**: RADIUS uses UDP and does not encrypt the RADIUS packet itself, while RadSec wraps the entire packet in TLS, hiding all attributes and headers from the wire. * **Metadata Confidentiality**: RadSec encrypts all metadata (headers, attributes, and Outer Identity), preventing network-level exposure. * **Shared Secret**: The Shared Secret is never transmitted. It is only used locally to compute message integrity checks and verify authenticity. * **Trade-Offs**: RadSec provides enhanced confidentiality but complicates diagnostics due to encryption, and its support is not universal across all network equipment. *** ### Standards and RFC References For further detail on protocols and specifications: * EAP (Extensible Authentication Protocol): RFC 3748 * EAP-TLS: RFC 5216 * RADIUS (Remote Authentication Dial-In User Service): RFC 2865 * RadSec (RADIUS over TLS): RFC 6614 # REST API The REST API documentation is available under https\://YOURNAME.radius-as-a-service.com/docs/api RADIUSaaS exposes a REST API that allows you to automate most actions that would otherwise have to be performed through the RADIUSaaS Admin Portal UI. {% hint style="warning" %} Before executing any API call that leads to a configuration change, ensure you fully understand the implications. Incorrect use of the API may break the configuration of your service. {% endhint %} ## Authentication To authenticate a call to the REST API, populate an HTTP `Authorization` header with each request. This header must contain a valid [access token](/admin-portal/access-and-rules/permissions#access-tokens): ``` Authorization: Bearer ``` ## API Reference The API documentation contains a complete Swagger-based API reference for each API endpoint including * available HTTP methods, * HTTP response codes, * JSON schemas / form data for request (bodies), * JSON schemas of response bodies, and * Request-response examples for some endpoints. {% hint style="info" %} It is not possible to trigger API calls directly through the API Reference. {% endhint %}
## Scenarios ### Manage Username/Password Accounts for BYOD or Guest Access The REST API can be used to automate the management of username/password accounts for BYOD or guest access scenarios. This may include the automatic provisioning of (WiFi) credentials during on-boarding of new students, tenants in a co-working space, ... as well as the automatic retirement of those accounts. An example on how to use the REST API to provision a username/password account can be found in your API Reference under the **User** endpoints. ### Implement External Monitoring To monitor the service availability and uptime of your RADIUSaaS instance with an external system, or to monitor expiry of your RADIUS Server Certificate, please refer to the following guide: {% content-ref url="/pages/GXG4KTUIewEO2czvRIBs" %} [External Monitoring](/other/rest-api/external-monitoring) {% endcontent-ref %} ## cURL Examples In general, there are two different content types for the REST API, either form data or JSON. You can find out which media type is required in the API documentation. If you are not familiar with the curl syntax, you can find two examples here: #### JSON ```bash curl -X "METHOD" "https://YOURNAME.radius-as-a-service.com/api/ROUTE/PATH" \ -H 'Authorization: Bearer ACCESS_TOKEN' \ -H 'Content-Type: application/json' \ -d $'{ NEEDED JSON DATA. Have a look at the documentation }' ``` #### Form Data ```bash curl -X "METHOD" "https://YOURNAME.radius-as-a-service.com/api/ROUTE/PATH" \ -H 'Authorization: Bearer ACCESS_TOKEN' \ -F 'KEY=VALUE'\ -F 'KEY=VALUE' ``` # External Monitoring This article demonstrates how to use the provided API for external monitoring of your RADIUSaaS instance. ## Overview The monitoring endpoint of your RADIUSaaS instance allows you to perform the following tasks in your own 3rd party monitoring solution: * Monitor uptime of your RadSec endpoints. * Monitor uptime of your RADIUS proxies. * Monitor expiry of your RADIUS Server Certificate and its issuing CA. If feasible in your monitoring solution, aggregation and metrics can be built around those monitors to trigger automated alerts. ## API Schema Defition Please refer to the [API documentation](/other/rest-api#api-reference) in your RADIUSaaS Admin Portal for detailed information on the schema of the `/status` endpoint. ## API Examples {% hint style="info" %} Please note that we are unable to provide support for 3rd party monitoring solutions and you will need to bring your own expertise beyond the scope of this article. {% endhint %} {% stepper %} {% step %} ### Create an Access Token as described [here](/admin-portal/access-and-rules/permissions#access-tokens). {% endstep %} {% step %} ### Retrieve Data To retrieve data from the API endpoint, authenticate your requests using the access token created previously: {% tabs %} {% tab title="PowerShell" %} 1. **Store the Access Token** Store the access token in a PowerShell variable for easy reference. Replace `your_access_token` with the actual token. ```powershell $accessToken = "your_access_token" ``` 2. **Make the API Request** Use PowerShell's `Invoke-RestMethod` to send a request to the desired API. Ensure to include the access token in the request header. ```powershell $url = "https://contoso.radius-as-a-service.com/api/status" $headers = @{ Authorization = "Bearer $accessToken" } $response = Invoke-RestMethod -Uri $url -Headers $headers -Method Get ``` {% endtab %} {% tab title="cURL" %} ``` curl -i https://contoso.radius-as-a-service.com/api/status \ -H "Authorization: Bearer [your_access_token]" ``` {% endtab %} {% tab title="Python" %} ``` import requests url = "https://contoso.radius-as-a-service.com/api/status" headers = { "Authorization": "Bearer your_access_token" } response = requests.get(url, headers=headers) print(response.status_code) print(response.text) ``` {% endtab %} {% endtabs %} {% endstep %} {% step %} ### Process the data according to your needs #### Example 1 - Show information about the RadSec servers: ``` $response.radsecservers cluster_name : eu1 ip : 20.113.8.151 name : radius-server-contoso-main radius-server-contoso-main-state : True state : True ``` #### Example 2 - Show information about the RADIUS proxies: ``` $response.proxies ip : 142.93.161.44 location : Europe (Frankfurt) name : radius-proxy-contoso-142.93.161.44 radius-proxy-contoso-142.93.161.44-state : True state : True ip : 209.38.81.0 location : Australia (Sydney) name : radius-proxy-contoso-209.38.81.0 radius-proxy-contoso-209.38.81.0-state : True state : True ``` #### Example 3 - Show certificate information: ``` $response.certificates | Format-List contoso-certificate--Proxycertificate-state : True name : contoso-certificate--Proxycertificate state : True validity_days_left : 2570 contoso-certificate-Customer-CA-state : True name : contoso-certificate-Customer-CA state : True validity_days_left : 6900 ``` {% hint style="info" %} Please consider that the **certificates** will be **checked every 10 hours,** and the **data** is **cached for 60 seconds**. Consequently, after renewing an expired certificate, it may take several hours for the status to be updated. {% endhint %} {% endstep %} {% endstepper %} # Changelog {% hint style="success" %} If you'd like to **stay up to date on the latest changes and news in the RADIUSaaS changelog**, you can subscribe to our email update service. Subscribers will receive **email notifications** when there are new updates to the changelog. [**Please click here to sign up for email notifications.**](https://feedback.radiusaas.com) {% endhint %} ## Versions ### August 2026 Release #### **Schedule** * Roll-out start: 2026-08-13 * Roll-out end: 2026-08-20 #### **Fixes** * Fixed CA certificate download under Server Certificates returning the server certificate instead * Fixed MAC groups not being updatable * Reduced noisy client error entries in RADIUS server logs * Bug fixes in SCEPman SaaS Jamf Pro integration #### **New Features** * Reworked Admin Portal UI/UX * Comprehensive Rule Engine update: * Match on client certificate attributes * Match on Client (WAN) IP addresses * Flexible assignment of VLAN IDs and attributes using regular expressions incl. fallback values * Backup and restore of rule sets * Support for RSASSA-PSS-signed CRLs * SCEPman SaaS: * Active Directory Enrollment * REST Enrollment API * RADIUS Proxy: real Client (WAN) IP address is forwarded to the RADIUS server (available for Rule Engine matching) ### April 2026 Release #### Schedule * Roll-out start: 2026-03-26 * Roll-out end: 2026-04-01 #### Fixes * Stability update #### New Features * [SCEPman-as-a-Service](/admin-portal/scepman-saas/status) GA ### March 2026 Release {% hint style="info" %} **Action required** (for customers using RADIUSaaS Proxies)**:**\ The current release includes an update to the RADIUSaaS proxies that must be initiated by customers **before the end of April**. This is the final step of the proxy IP address migration announced last year.\ Before starting, make sure your network equipment is prepared for the new proxy IP addresses.\ Then run the Proxy Update. **After the update, legacy proxy IPs will stop working.**\ For details, please see [here](/other/changelog/final-notice-radius-proxy-ip-migration-required-before-10-july-2026). {% endhint %} #### Schedule * Roll-out start: 2026-02-26 * Roll-out end: 2026-03-05 #### Fixes * Fixed VLAN-related attributes not being populated in an RFC-compliant way * Fixed incorrect expiration date in access token table * Several bug fixes in configuring the [SCEPman Connection](/admin-portal/settings/settings-server#scepman-connection) #### New Features * [VLAN](/admin-portal/access-and-rules/rules/general-structure#vlan-attributes) and [additional return attributes (VSAs)](/admin-portal/access-and-rules/rules/general-structure#radius-attributes) can now be managed directly via the RADIUSaaS Admin Portal * Removed RADIUS server certificate slot limitation * Popup Notifications: * Added certificate expiry and other important alerts * Added configuration improvement recommendations ### January 2026 Release #### Schedule * Roll-out start: 2026-01-21 * Roll-out end: 2026-01-28 #### Fixes * RADIUS Server: Remove all attributes from Access-Reject to ensure RFC compliance * RADIUS Server: Set Framed-MTU to value of last request * Allow CSV import of AP and switch groups * Fix issue when launching RaaS from MyApps #### New Features * SCEPman-as-a-Service (Public beta). Please [contact us](https://support.scepman.com/support/tickets/new?ticket_form=drop_a_question_%28scepman%29&_gl=1*1ufiojk*_ga*MTEzNjMwODM1MC4xNzY5MDUyMzAy*_ga_BRDGXLVK3H*czE3NjkwNTIzMDEkbzEkZzAkdDE3NjkwNTIzMDEkajYwJGwwJGgw) to get access. * Automatic server certificate management using [SCEPman](/admin-portal/settings/settings-server#scepman-connection) * Allow adding multiple instances of the same return attribute ### July 2025 Release #### Schedule * Roll-out start: 2025-07-14 * Roll-out end: 2025-07-17 #### New Features * More [IDP options](/admin-portal/access-and-rules/permissions#supported-idps) for administrative SSO * [Revoked certificate cache](/other/faqs/log-and-common-errors#certificate-status-was-revoked-previously) * Directly [create tickets or report incidents](/admin-portal/home#help) from the RADIUSaaS Admin Portal * Improved [notification system](/admin-portal/home#notifications) #### Upcoming Service Updates * Preparation for [upcoming IP address change of RADIUS Proxies](/other/changelog/final-notice-radius-proxy-ip-migration-required-before-10-july-2026) ### February 2025 Release #### Schedule * Roll-out start: 2025-02-27 * Roll-out end: 2025-03-06 #### Fixes * RADIUS Server: Incoming traffic is not processed in some rare scenarios * RADIUS Proxy: Version update / increased stability #### New Features * Status endpoint that enables the usage of external monitoring systems (certificates, proxies and RadSec servers) * Optimized handling of invalid OCSP responses * Support for [Authorized Responders](https://docs.scepman.com/advanced-configuration/application-settings/ocsp#appconfig-ocsp-useauthorizedresponder) in OCSP * Display CRL download issues * WPA2/WPA3 selector for XML generator ### December 2024 Release * Custom logo experience for invited users in web UI * Technical contacts can be configured per RADIUSaaS tenant. This is a preparation for a notification feature in a future release of RADIUSaaS. * Support for FreshestCRL (DeltaCRL) in Trusted Certificates * Support for parentheses in CRL URL * Updated default templates for LogExporter * Fixed: On rare occasions, the RADIUSaaS instances may be affected by a performance bottleneck for authentications. ### June 2024 Release * Updated UI (reactive design, improved [Rule Engine](/admin-portal/access-and-rules/rules) structure, separation of [RADIUS server certificates](/admin-portal/settings/settings-server#server-certificates) from [Trusted Certificates](/admin-portal/settings/trusted-roots) for client authentication and RadSec) * Certificate verification can now be configured individually for each trusted CA (client authentication, RadSec) using OCSP, **CRL** or OCSP auto-detect (based on the certificate's AIA extension) * OCSP Soft-Fail / Hard-Fail is now configurable on a per trusted CA basis. * Introduction of [RADIUSaaS REST API documentation](/other/rest-api) and [API access tokens](/admin-portal/access-and-rules/permissions#access-tokens). * Improved logging: * Added Accounting and [RadSec connection logs](/admin-portal/insights/log#log-types). # FINAL NOTICE: RADIUS Proxy IP Migration Required Before 10 July 2026 As part of the ongoing RADIUSaaS Proxy IP address migration, all customers using RADIUSaaS Proxies are required to complete the proxy update before **10 July 2026.** This is a **mandatory change**. Customers who have not completed the migration by this date will no longer be able to use the existing (legacy) RADIUS Proxy IP addresses. ## Required action Before 10 July 2026: 1. Review your network configuration and ensure your network equipment is prepared for the new RADIUS Proxy IP addresses. 2. Complete the Proxy Update from the RADIUSaaS Admin Portal. 3. Verify that your network devices are configured to communicate with the new proxy IP addresses. ## Important notice The previous proxy IP addresses will be retired after **10 July 2026**. After this date, they will no longer be supported and authentication traffic using the legacy addresses may fail. No further extensions or exceptions to this deadline will be provided. Customers who do not complete the migration before the deadline will need to update their configuration before RADIUS authentication can resume. We recommend completing this change as soon as possible to avoid any potential service disruption. *** ## Proxy Update As part of the [**March 2026 Release**](/other/changelog#march-2026-release), we are finalizing the migration of our managed **RADIUSaaS proxies**. Administrators using RADIUSaaS proxies will see a pop-up window titled **“Proxy Infrastructure Update”** with three options: ***Postpone***, ***Go To Proxies***, and ***Update***.
If you haven’t already, ensure your network equipment is configured for the new proxy IP addresses (see [How to check if you are affected](#how-to-check-if-you-are-affected) for details). When you click ***Update***, your tenant’s proxies will be updated. **Once the update completes, the legacy proxy IP addresses will no longer work**. ***Go To Proxies*** open the **Proxy Settings** page to review your configuration. ## What You Need to Do If your configuration uses one of the affected RADIUS proxies, you must: 1. **Update your network equipment** to use the new RADIUS proxy IP address. 2. **Run the** [**Proxy Update**](#proxy-update) (latest by **10 July 2026**). ## How to check if you are affected {% hint style="info" %} In general, only customers using the **RADIUS protocol** may be affected. If you are using **RadSec only**, no action is required, since you are not using the RADIUSaaS Proxy services. Note that not every proxy server requires an IP address change. {% endhint %} You can verify whether your proxy configuration is impacted by logging into the **RADIUSaaS Admin Web Portal**: * Navigate to your **proxy configuration**. * If your proxy is affected, you will see: * A **new IP address** is listed. * A **legacy IP address** is shown in parentheses, labeled with the word **"legacy"**. In the following example, the proxy with the region "Europe (London)" is affected, while the proxy with the region "North America (Dallas)" is not affected. The customer is required to change the IP address for the Europe (London) proxy in their network equipment, while 165.227.229.49 is the old IP address and 139.59.200.190 is the new address:
## Need Help? If you have any questions or need assistance updating your configuration, please contact our support team via the [RADIUSaaS Support Portal](https://support.radiusaas.com/support/tickets/new?ticket_form=technical_support_request_%28radiusaas%29). # Licensing {% hint style="success" %} The subscription for RADIUSaaS is **user-based**. {% endhint %} {% hint style="info" %} RADIUSaaS does not display your license consumption. Please ensure compliance with the licensing terms below by monitoring the profile assignments in your MDM solution on a regular basis. {% endhint %} ## User definition The subscription of a "user" is required for each user, who is enabled to authenticate against RADIUSaaS on at least one device. "Enabled" refers to the devices ability to authenticate against the network using RADIUSaaS, regardless if the device is currently being used or switched off. {% hint style="info" %} In many cases the required number of RADIUSaaS users equals the amount of users, who are assigned to the corresponding network profile (e.g. WIFI profile) in the management system (e.g. Microsoft Endpoint Manager). {% endhint %} The minimum amount of users that can be subscribed for one organization is 50. A user subscription is bound to a single user for at least one calendar month and cannot be shared with other users. ## Device limits per user One single *User* may be assigned to up to * five stationary devices (PC, laptop)\ and * five mobile devices (mobile phone, tablet). ## Subscription scope A RADIUSaaS subscription may be used for the clients and users of **one** organization. It is **not** allowed to * Use one RADIUSaaS subscription for multiple organizations * Split one RADIUSaaS subscription and/or re-sell it to multiple organizations # Microsoft Marketplace ## Prerequisites In order to purchase solutions from independent software vendors (ISV) you must fulfil the following requirements: 1. You have an active Azure subscription in one of the following countries: Armenia, Australia, Austria, Bulgaria, Belgium, Canada, Chile, Colombia, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, India, Indonesia, Ireland, Italy, Kenya, Latvia, Liechtenstein, Lithuania, Luxembourg, Malaysia, Malta, Monaco, Netherlands, New Zealand, Nigeria, Norway, Poland, Portugal, Puerto Rico, Romania, Saudi Arabia, Serbia, Singapore, Slovakia, Slovenia, South Africa, South Korea, Spain, Sweden, Switzerland, Taiwan, Thailand, Türkiye, United Arab Emirates, United Kingdom, United States, Vietnam. 2. The account you want to purchase our solution with must have the **Owner** or **Contributor** role assigned on the Azure subscription you are going to pay with. 3. The billing account linked to your Azure subscription is properly set up. Depending on your billing account type (Microsoft Customer Agreement or Enterprise Agreement), you might need to enable marketplace purchases in the Azure portal first. ## How to purchase RADIUSaaS or a Solution Bundle? {% hint style="info" %} Deploying a RADIUSaaS or [Solution Bundle](#solution-bundles) subscription via Microsoft Marketplace **will not result** **in a re-deployment of RADIUSaaS (or SCEPman) if you already have an active trial or production deployment**. Instead, we will assign the license obtained as part of this subscription to your existing deployments. For **new customers**, we will provision a new instance of RADIUSaaS once below steps are completed. Please allow up to 1 business day for us to complete the provisioning. {% endhint %} To get started with your RADIUSaaS or Solution Bundle subscription, follow below steps: {% stepper %} {% step %} ### Locate the product version on the Microsoft Marketplace Choose between the following: * [RADIUSaaS](https://portal.azure.com/#view/Microsoft_Azure_Marketplace/GalleryItemDetailsBladeNopdl/id/glueckkanja-gabag.radiusaas-transactable-prod) * [RADIUSaaS & SCEPman Enterprise Bundle](https://portal.azure.com/#view/Microsoft_Azure_Marketplace/GalleryItemDetailsBladeNopdl/id/glueckkanja-gabag.radiusaas-scepman-bundle-prod) * [RADIUSaaS & SCEPman SaaS Bundle](https://portal.azure.com/#view/Microsoft_Azure_Marketplace/GalleryItemDetailsBladeNopdl/id/glueckkanja-gabag.radiusaas-scepman-saas-bundle-prod) In case we have extended a **Private Offer** to you or your MSP/distribution has extended a **Multiparty Offer (MPO)** to you, navigate to **Marketplace** in your **Azure Portal** and then to **Private Offer Management** to locate the Private Offer. * More details on Private Offers and MPOs can be found in Microsoft's documentation. * [Private Offer](https://learn.microsoft.com/en-us/marketplace/private-offers-purchase) * [Multiparty Offer](https://www.youtube.com/watch?v=TANUlgLuVqI) * Select the **Subscription** where RADIUSaaS should be billed to * Select the **Plan** (monthly or yearly) based on your preferred renewal interval * Click **Subscribe**.
{% endstep %} {% step %} ### Subscribe to RADIUSaaS / bundle version * Create or select the **Resource group** you would like to deploy the subscription to. * Assign a descriptive **Name** to later identify your subscription. * We recommend to keep **Recurring billing** **On** so that you do not have to worry about an automatic termination of your subscription. * Click **Review + subscribe** and then **Subscribe** to deploy the **SaaS** resource to your **Resource group**.
{% hint style="info" %} The random order of **Base Fees** und **Additional Users** under the **Price** information is attributed to limitations of the Microsoft Marketplace. Later during the the enrolment process, we will provide you with transparent information on the expected licensing fees. {% endhint %} {% endstep %} {% step %} ### Configure your account Once the deployment is complete, please navigate to our platform to complete the checkout. Therefore click **Configure account now**.
{% endstep %} {% step %} ### Add additional information After authenticating on our platform using your Microsoft credentials, you will be prompted for additional information, such as the desired total **User** amount and a **Technical contact**. {% hint style="info" %} The **Technical contact** must have a mailbox connected to it, so we are able to notify you in case there are relevant issues with RADIUSaaS. By default, we also configure the **Technical contact** as initial administrator on your RADIUSaaS instance. In case you'd like to change that, please [let us know](https://www.radius-as-a-service.com/help/). {% endhint %} {% hint style="success" %} If the plan contains chargeable add-ons, you can select them under **Extras**. For example, the RADIUSaaS & SCEPman Enterprise Bundle plans allow you to purchase the optional [SCEPman Setup Support](https://docs.scepman.com/support#scepman-setup-support) package. {% endhint %}
Based on the amount of users provided, we will charge the relevant base fee for your user segment as well as additional users, in case you require more than the included amount in your base fee. **The platform automatically selects the best price / tier**. The platform will show you the licensing fees you have to expect under **Cost Projection**. If you are happy with it, please click **Review & Submit** for a final review and a fee summary. Complete the checkout by confirming your choice and clicking **Submit**. This triggers us to deploy your RADIUSaaS instance (and issue a SCEPman Enterprise Edition license key if the RADIUSaaS and SCEPman Bundle is purchased). We will inform you via email with all relevant information on the next steps once the instance (and license key) is available for you. This won't take any longer than one business day. {% hint style="info" %} You will only be charged by Microsoft, once you have completed the enrolment on our platform and received our welcome email. {% endhint %} {% endstep %} {% endstepper %} ## Pricing Model * RADIUSaaS is offered as a **monthly or** **annual subscription plan** with different [User Segments](#user-segments). The correct **user segment** is automatically selected by our platform based on the amount of desired users. * All subscription plans consist of a **base fee** which includes a certain amount of users per subscription cycle - depending on the **user segment**. For example, the **base fee** for the user segment *RADIUSaaS (M) 50* includes 50 users per month. * If more than the included amount of users is required, **additional users** can be added to the plan. For each additional user, we charge an additional per-user fee. ## Invoicing * During the first subscription interval, your subscription fees are not immediately due after completing the subscription enrolment. Instead we will start billing once your cancellation grace period has expired. * Upon every renewal date, you will be billed immediately. * You will always be billed for the entire subscription cycle in advance. * The related items should appear on your Microsoft Azure invoice (Pay-As-You-Go or Enterprise Agreement) the month after we have reported your fees to Microsoft. * In the PDF invoice you will receive from Microsoft, all RADIUSaaS fees are lumped into an item called "SaaS". The related Publisher is "glueckkanja".
{% hint style="info" %} For a more detailed cost breakdown of your base and additional user fees, please refer to the invoice in your Azure portal. {% endhint %} ## Plan Overview Subscriptions for RADIUSaaS are available based on a **monthly** or **annual** renewal interval. {% hint style="info" %} The annual plan is discounted by 10% in comparison to the monthly plan (calculated over the period of 12 months). {% endhint %} | **Plan** | **Renewal Interval** | | ------------- | -------------------- | | RADIUSaaS (M) | Monthly | | RADIUSaaS (Y) | Annually | ### User Segments The following user segments are available for both, monthly and annual plans:
PlanIncluded Users
User SegmentIncluded Users in Base FeeMaximum Total Users
RADIUSaaS (M/Y) 5050249
RADIUSaaS (M/Y) 250250999
RADIUSaaS (M/Y) 10001,0004,999
RADIUSaaS (M/Y) 50005,0009,999
RADIUSaaS (M/Y) 1000010,000unlimited
For prices in Euro (EUR), please check out our [website](https://www.radius-as-a-service.com/pricing/). For prices in *your* currency, please directly refer to the **Marketplace** in the [Azure Portal](https://portal.azure.com/). ## Solution Bundles {% hint style="info" %} The information provided throughout this article is analogously applicable for solution bundle subscriptions. {% endhint %} {% hint style="success" %} Please refer to our [SCEPman Edition Comparison](/overview#scepman-edition-comparison) for details on the differences between SCEPman Enterprise and SCEPman SaaS. {% endhint %} #### RADIUSaaS & SCEPman Enterprise Bundle We offer RADIUSaaS as well as our cloud-CA solution **for** **in-customer tenant deployment** [SCEPman Enterprise](https://www.scepman.com/) in a subscription bundle that is discounted by 25% in comparison to the individual solutions. The bundle plans are available with monthly or annual renewal as well as the same [User Segments](#user-segments). Furthermore, the plans allow the **one-time** purchase of the [SCEPman Setup Support](https://docs.scepman.com/licensing#optional-scepman-setup-support). #### RADIUSaaS & SCEPman SaaS Bundle If you'd prefer to use our cloud-based PKI SCEPman **without having to deploy infrastructure in your Azure tenant**, you can opt for the RADIUSaaS & SCEPman SaaS Bundle, that allows you to leverage SCEPman SaaS, built righ into your RADIUSaaS instance. The bundle plans are available with monthly or annual renewal as well as the same [User Segments](#user-segments). ## Subscription Management ### User Upgrades * If you would like to upgrade your user count, you can do that any time during the current subscription cycle by navigating to your **RADIUSaaS subscription** in the [Azure SaaS portal](https://portal.azure.com/#blade/HubsExtension/BrowseResourceBlade/resourceType/Microsoft.SaaS%2Fresources) and by clicking "Open SaaS Account on publisher's site" (see screenshot below). This will re-direct you to our platform where the amount of users can be upgraded. ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/501YsNPIaZTyXtp029CM/Screenshot%202022-02-18%20at%2012.32.27%202.png) * Our platform will inform you about the new fees you to expect for a **complete** subscription cycle. * For the current cycle, we will bill the additional users for remaining days only. * After confirming your choice and once we have updated the license in our backend, you will receive a confirmation email from us. ### User Downgrades * You can **pre-register a reduction** of your licensed users for the **next renewal**, by navigating to your **RADIUSaaS subscription** in the [Azure SaaS portal](https://portal.azure.com/#blade/HubsExtension/BrowseResourceBlade/resourceType/Microsoft.SaaS%2Fresources) and by clicking "Open SaaS Account on publisher's site" (see screenshot below). This will re-direct you to our platform where the amount of users can be downgraded. ![](https://content.gitbook.com/content/SWU1DQ4UGkqER7uGNUOm/blobs/501YsNPIaZTyXtp029CM/Screenshot%202022-02-18%20at%2012.32.27%202.png) * The downgrade will become effective upon the next regular renewal of your subscription. * In case you change your mind and would like to change the user quantity or cancel the downgrade altogether, navigate back to your **RADIUSaaS subscription** and click **Cancel downgrade**.
### Change Plan If available on Azure Portal, the **Change Plan** action allows you to change your current outdated plan to the most recent version of the plan with the same subscription cycle (annually or monthly). ### **Recurring Billing** If you decide to disable **Recurring billing**, your subscription will not renew automatically. Instead, Microsoft will (irreversibly) cancel the subscription towards the end of the current subscription cycle. This means, the service will be terminated automatically on that date as well. While the subscription has not expired yet, you can opt to enable **Recurring billing** at any time. ### Cancellation * If you would like to (irreversibly) cancel your subscription, navigate to your **RADIUSaaS subscription** in the [Azure SaaS portal](https://portal.azure.com/#blade/HubsExtension/BrowseResourceBlade/resourceType/Microsoft.SaaS%2Fresources) and click **Cancel subscription**.
* If you cancel within the grace period, the service will be stopped immediately. * If you cancel after the grace period, the service will remain active until the end of the current subscription cycle. ## **Trials** In case you would like to test RADIUSaaS, please [request a trial via our website](https://support.radiusaas.com/support/tickets/new?ticket_form=trial_request_%28radiusaas%29) or send us an email to . ## FAQs ### Why is my "Plan no longer available for purchase"? In case you see hint in your subscription as shown in below screenshot, **there is no need to worry**!
The reasons for this hint is that - from time to time - we might have to deprecate plans for technical reasons. **Important:** * As an existing customer, you may continue to use the deprecated plan indefinitely (until the subscription is cancelled). * In case a newer plan gives you better pricing or other advantages, we will inform you about this. * You can change to the most recent version of the plan by leveraging the [Change Plan](#change-plan) action. ### Why is my Microsoft Marketplace purchase not working? You may encounter problems when purchasing through Microsoft Marketplace. Here is a list of reasons, why buying through Microsoft Marketplace may fail: 1. You do not have permissions in your Azure tenant to purchase through Microsoft Marketplace. You must be assigned the role of Owner or Contributor in the Azure subscription you want to pay with. 2. The subscription belongs to an Enterprise Agreement (EA) and the EA admin disabled Microsoft Marketplace purchases. Or the EA admin has enabled purchases only for free offers and the offer is a paid offer. Please see [here](https://learn.microsoft.com/en-us/marketplace/purchase-control-options) for details. 3. The subscription you're using belongs to a billing account in a region where the offer isn't available.\ Our Marketplace offers are available in the following countries/regions: Armenia, Australia, Austria, Bulgaria, Belgium, Canada, Chile, Colombia, Croatia, Cyprus, Czechia, Denmark, Estonia, Finland, France, Germany, Greece, Hungary, Iceland, India, Indonesia, Ireland, Italy, Kenya, Latvia, Liechtenstein, Lithuania, Luxembourg, Malaysia, Malta, Monaco, Netherlands, New Zealand, Nigeria, Norway, Poland, Portugal, Puerto Rico, Romania, Saudi Arabia, Serbia, Singapore, Slovakia, Slovenia, South Africa, South Korea, Spain, Sweden, Switzerland, Taiwan, Thailand, Türkiye, United Arab Emirates, United Kingdom, United States, Vietnam 4. The subscription/billing account isn't associated with a valid payment instrument (such as a valid credit card). 5. Private Marketplace is enabled for the subscription and the offer isn't in the list of allowed offers. 6. Purchases are not permitted for subscriptions with a spending cap, including Free subscriptions, Sponsorships, and similar types. ### Does RADIUSaaS or the Solution Bundles count towards my Microsoft Azure Consumption Commitment (MACC)? Currently (March 2025), this is the case. Since Microsoft may change their policy on what counts towards MACC in the future, please always [confirm](https://learn.microsoft.com/en-us/marketplace/azure-consumption-commitment-benefit#find-and-purchase-azure-benefit-eligible-offers-in-azure-marketplace) eligibility first. # cleverbridge ## Prerequisites & Vendor Onboarding In order to purchase RADIUSaaS from our merchant of record, cleverbride GmbH (headquartered in Germany), no special prerequisites have to be met, except for accepting their terms and conditions. Depending on your sourcing and purchasing requirements, you might have to set up cleverbridge as a vendor in your system. cleverbridge provides all relevant onboarding information [via their website](https://support.cleverbridge.com/hc/en-us/articles/4405420244243-How-do-I-register-Cleverbridge-as-a-vendor). Should you have any questions during the onboarding process, especially in regards to legal or taxation aspects, please [contact cleverbridge directly](#for-what-inquiries-should-i-contact-cleverbridge-directly). {% hint style="info" %} **For US-based customers only**. Since cleverbridge operates a local entity in the US, cleverbridge Inc., certain tax implications may arise from this. As part of their vendor [onboarding information](https://support.cleverbridge.com/hc/en-us/articles/4405449389587-I-m-a-vendor-looking-to-place-an-order-from-the-U-S-What-documents-do-I-need), they also provide a W-9 form. {% endhint %} ## Pricing Model RADIUSaaS is offered as a **monthly or** **annual subscription plan** with different [User Segments](#user-segments). The correct **user segment** is either * pre-selected in case we provide a quotation or order link to you, or * must be manually selected during checkout:
## Payment Options cleverbridge provides a range of payment options (credit card, PayPal, Wire Transfer), where availability might depend on the country you are ordering from. ### Invoice-based Payments If you require invoice-based payments, please [contact us](mailto:sales@radiusaas.com) so we can provide you with a quotation or order link that provides invoice-based payments. The payment term is **30 days** **net**. ### Currencies cleverbridge allows you to transact in a variety of currencies. The currency is automatically selected based on the location of your browser's IP address. If you would like to transact in a different currency, you can do so by selecting your preferred currency in the top right corner of the quotation or checkout site. {% hint style="info" %} The reference currency for RADIUSaaS is Euro (EUR). The forex rate cleverbridge applies when converting to other currencies is not in our control. Please note, that once an order for a subscription is placed **and** as long as **automatic renewal** is **enabled**, the forex rate is guaranteed for future renewals, i.e. cleverbridge absorbs the forex risk. {% endhint %} ## Plan Overview Subscriptions for RADIUSaaS are available based on a **monthly** or **annual** renewal interval. {% hint style="info" %} The annual plan is discounted by 10% in comparison to the monthly plan (calculated over the period of 12 months). {% endhint %} | **Plan** | **Renewal Interval** | | ------------- | -------------------- | | RADIUSaaS (M) | Monthly | | RADIUSaaS (Y) | Annually | ### User Segments The following user segments are available for both, monthly and annual plans.
User SegmentMinimum Total UsersMaximum Total Users
RADIUSaaS 50 (M/Y)50249
RADIUSaaS 250 (M/Y)250999
RADIUSaaS 1000 (M/Y)1,0004,999
RADIUSaaS 5000 (M/Y)5,0009,999
RADIUSaaS 10000 (M/Y)10,000unlimited
### Solution Bundles {% hint style="info" %} The information provided throughout this article is analogously applicable for solution bundle subscriptions. {% endhint %} {% hint style="success" %} Please refer to our [SCEPman Edition Comparison](/overview#scepman-edition-comparison) for details on the differences between SCEPman Enterprise and SCEPman SaaS. {% endhint %} #### RADIUSaaS & SCEPman Enterprise Bundle We offer RADIUSaaS as well as our cloud-CA solution **for** **in-customer tenant deployment** [SCEPman Enterprise](https://www.scepman.com/) in a subscription bundle that is discounted by 25% in comparison to the individual solutions. The bundle plans are available with monthly or annual renewal as well as the same [User Segments](#user-segments). #### RADIUSaaS & SCEPman SaaS Bundle If you'd prefer to use our cloud-based PKI SCEPman **without having to deploy infrastructure in your Azure tenant**, you can opt for the RADIUSaaS & SCEPman SaaS Bundle, that allows you to leverage SCEPman SaaS, built righ into your RADIUSaaS instance. The bundle plans are available with monthly or annual renewal as well as the same [User Segments](#user-segments).
## Subscription Management ### Self-management Portal Cleverbridge allows you to manage any aspect of your subscription via their self-management portal, including but not limited to: * Contact data changes * Payment method changes * Downloading previous invoices * Performing user upgrades and downgrades * Cancelling your subscription To access the self management portal, please refer to the initial delivery / order confirmation email that was sent to you by cleverbridge at the time your order was placed. Within that email, locate the button saying **Manage Your Subscription For "\"** and click it.
This will either navigate you to the self-management portal directly or you might have to re-generate the link (they might expire after a while) first. {% hint style="info" %} In case you are having difficulties accessing the self-management portal as described above, feel free to [contact cleverbridge directly](#for-what-inquiries-should-i-contact-cleverbridge-directly) for assistance by referencing your **Cleverbridge reference number**. {% endhint %} ### User Upgrades {% hint style="info" %} User upgrades are only available if all previous amounts / invoices have been paid. In case you cannot pay a previous invoice before performing the upgrade, please [contact us](mailto:sales@radiusaas.com). {% endhint %} #### Mid-term Upgrade {% hint style="info" %} The Mid-term Upgrade option is **available until 15 days before** your subscription is set to renew. Afterwards it will be replace by the [Early Renewal Upgrade](#early-renewal-upgrade). {% endhint %} If you would like to upgrade your user count, you can do so any time during the current subscription cycle by navigating to the subscription's [self-management portal](#self-management-portal) leveraging the mid-term upgrade option. With the mid-term upgrade, additional users will be * billed **Pro Rata Temporis**, and * **co-termed** with the existing users, which means you only pay for the delta in users pro-rated for the remaining subscription cycle. To perform a mid-term upgrade, * Navigate to the subscription's [self-management portal](#self-management-portal). * Click **Manage products**.
* Select the correct [user segment](#user-segments), and provide the new **total** number of users. The website will display the * upgrade price (**Upgrade price today**), and * the next regular renewal price assuming the new total user count (**Renewal price on ...**) both **including VAT**.
* Click **Next**, review your **Payment method** and confirm the purchase by clicking **Buy now**.
* The additional users will be added to your **existing RADIUSaaS instance** automatically. #### Early Renewal Upgrade {% hint style="info" %} The Early Renewal Upgrade flow is **available from 15 days before** your subscription is set to renew. {% endhint %} If you would like to upgrade your user count as part of the next regular renewal, you can do so by navigating to the subscription's [self-management portal](#self-management-portal) leveraging the early renewal upgrade flow. With the early renewal upgrade flow, additional users are **pre-registered** for the next regular renewal. However, you may start using the additional users immediately. To perform an early renewal upgrade, * Navigate to the subscription's [self-management portal](#self-management-portal). * Click **Renew subscription**.
* Select the correct [user segment](#user-segments), and provide the new **total** number of users. The website will display the renewal price considering the additional users.
* Click **Next**, review your **Payment method** and confirm the purchase by clicking **Buy now**.
* The additional users will be added to your **existing RADIUSaaS instance** automatically. ### User Downgrades You can pre-register a reduction of your user count for the next regular renewal by leveraging the [early renewal upgrade](#early-renewal-upgrade), too. However instead of adding users, you may reduce the number of users. ### **Automatic Renewal** {% hint style="warning" %} Only relevant for customers buying in non-Euro currency. By disabling Automatic Renewal you **are opting out of the perpetual forex rate** guarantee. This means the forex risk is transferred from cleverbridge to the customer. {% endhint %} If you decide to disable **Automatic Renewal**, your subscription will not renew automatically. Instead, cleverbridge will (irreversibly) cancel the subscription towards the end of the current subscription cycle. This means, the service will be terminated automatically on that date as well. While the subscription has not expired yet, you can opt to enable **Automatic Renewal** at any time by navigating to your subscription's [self-management portal](#self-management-portal).
### Cancellation * If you would like to (irreversibly) cancel your subscription, navigate to your subscription's [self-management portal](#self-management-portal) and disable **Automatic Renewal**. * You subscription will expire towards the end of the current cycle. * There is **no cancellation notice period**. ## **For Partners** Partners can leverage the same tools to manage subscriptions on behalf of their customers. To access a subscription self-management portal for a particular subscription, follow these steps: * Sign-on to the [Partner Portal](https://www.cleverbridge.com/306/?scope=pplogin) using your partner account credentials. * Click **History**, select **All transactions** and locate the relevant customer. * Click the icon highlighted in below screenshot, which will re-direct you to the initial confirmation / order confirmation page:
* On that page, locate the button saying **Manage Your Subscription For "\"** and click it.
* This will either navigate you to the self-management portal directly or you might have to re-generate the link (they might expire after a while) first. {% hint style="info" %} In case you are having difficulties accessing the self-management portal as described above, feel free to [contact cleverbridge directly](#for-what-inquiries-should-i-contact-cleverbridge-directly) for assistance by referencing your **Cleverbridge reference number**. {% endhint %} ## **Trials** In case you would like to test RADIUSaaS, please [request a trial via our website](https://support.radiusaas.com/support/tickets/new?ticket_form=trial_request_%28radiusaas%29) or send us an email to . ## FAQs ### How to request a quote for RADIUSaaS or a Solution Bundle? {% hint style="info" %} Quotes are valid for 14 days. {% endhint %} To request a quote for RADIUSaaS, * Get in [contact with us](mailto:sales@radiusaas.com) and request a quote link. * Once we have sent the quote link to you, * Click it. * Select the correct user segment, user quantity and fill our your company information. * Click **Next**, review your data and click **Request price quote**. ### Why is the VAT not removed from my quote? Cleverbridge will automatically remove the VAT if you provide a valid European VAT ID (and are not located in Germany) or a valid business registration number in countries where a VAT exemption applies (e.g. ABN in Australia). If the VAT is not removed but you believe that you are entitled to a VAT exemption, please [contact cleverbridge directly](#for-which-inquiries-should-i-contact-cleverbridge-directly). ### How do I convert a quote into an order? {% hint style="info" %} Cleverbridge does not require a Purchase Order (PO) to be provided when converting a quote into an order. {% endhint %} To convert a quote into an order * Locate the email that was sent you when requesting a quote * Scroll down and locate the **Place order** button. Click it. * Choose your preferred payment method amongst the available **Payment Options**. * Click **Next**, review your data and confirm the purchase by clicking **Buy now**. * We will contact you afterwards to query additional information that is required for the provision of your RADIUSaaS instance. ### For what inquiries should I contact cleverbridge directly? You should contact cleverbridge customer support directly, for the following inquiries: * Taxation / VAT * Correction of an invoice * Issues with your payment method * Change your contact details in the cleverbridge system {% embed url="" %} # Support & Service Level ## Support ### Eligibility Customers, who have an active subscription of RADIUSaaS are eligible for our support services. The support is included in the subscription fee of RADIUSaaS. ### Scope Our support services cover technical assistance for administrators: * Technical questions about features of RADIUSaaS * Support for incidents regarding RADIUSaaS ### Access You can access our support in the tab "Help" on our main product web-site (). Using the support website will generate a ticket in our ticket system, which will be the basis for the support process. Communication will happen in written form via e-mail or web-interface of our ticket-system. Depending on the support case, our support-engineers may decide to offer Microsoft Teams meetings to work on issues together with customers. Alternatively, raise a support ticket by clicking on the help button in [your RADIUSaaS portal](/admin-portal/home#help). ### Language Our engineers are happy to support you in these languages: * English * German ### Support hours * Monday-Friday * 08:00-18:00 CET / CEST * Except from public holidays for Hesse / Germany, Christmas Eve and New Year's Eve ### Support response time Typical < 4 hours for incidents Response time is defined as the duration between the report of the incident and the start of incident or problem handling through one of our support engineers. The response time is to be calculated within the support hours. ## Service level ### Services in scope The services in scope for the service level are: * RADIUSaaS * SCEPman SaaS ### Service hours Our service is operated 24x7 ### Service availability The service availability goal is 99,5%. It is calculated by using the following formula: `service availability` = (`service period` - `downtime`) / `service period` where * `Service period` is the corresponding calendar month\ and * `Downtime` is the accumulated amount of time where the service is unavailable. The service is considered unavailable, when there is no connectivity between the service and the internet. Service outages must be reported by customers to our support as soon as possible and at the latest within 24 hours after occurrence. In the event of a reported service outage, affected customers are entitled to apply within one week for the following credits for the affected calendar month: * service availability < 99.5% => 10% * service availability < 99.0% => 25% ### Data loss #### Scope This section applies to all services operated by glueckkanja on behalf of the customer, including RADIUSaaS and SCEPman SaaS. #### Risk of data loss Despite careful operation and maintenance of our services, the possibility of customer data loss cannot be fully excluded. This includes, but is not limited to, the potential loss of the private key of the Certificate Authority (CA) managed by glueckkanja as part of the SCEPman SaaS service. #### Compensation for data loss Customers affected by the loss of the CA private key are entitled to apply within one week after occurrence of the loss for a credit of six (6) months of their subscription. Beyond the credit described above, glueckkanja accepts no further liability and is under no obligation to pay any additional compensation for damages arising from data loss. This exclusion applies to all forms of damage, including but not limited to: * Loss of business or revenue * Operational disruption or downtime * Cost of rebuilding the PKI environment and redistributing certificates * Indirect, incidental, or consequential damages of any kind ### Credits Credits are appended as additional free months as an extension to the current subscription term.