Authentication Methods
MS Active Directory Service
Microsoft Active Directory (AD) Pass-through Authentication allows user authentication sessions to be created automatically for Microsoft Windows client devices. The Active Directory service works by running a service on a domain controller or a member server. When a user attempts to access the internet, the CyberEdge queries the Pass-through authentication service to request the logged on user at that IP address. The Pass-through service connects to the Remote Registry Service on the client machine and returns the logged on user. There are 3 steps involved in configuring the Active Directory Pass-through Authentication setup. This includes:
- Configure an Active Directory Service on the CyberEdge
- Install the Pass-through service on a domain controller or member server
- Configure the client device to accept requests from the Pass-through service
To setup Active Directory Service, complete the following:
- Navigate to Authentication > Zone Access > Pass-through Authentication
- Click "Add"
- Select "Active Directory Service" and add the following details:
- Name: Provide a name for the Pass-through service.
- Authentication Timeout: Set a timeout for the service to return a username (Recommended 7 seconds). After the specified timeout elapses, the client device will be served the captive portal as the fallback method of authentication.
- Session Timeout: The inactivity timeout for authentication sessions created using the Active Directory service. If no network.traffic for the client IP is detected for the specified period, the authentication session will be removed.
- Authentication Providers: The authentication provider to be used by the Active Directory service. This may be different to other Pass-through methods.
- Customer Host: Specify the hostname of a member server if the domain controller is not being used. If left blank, the domain controller will be used by default.
- Click "Save"
- Click "Download Passthrough Service" to download the service to be installed on the domain controller or member server. Information on how to install the service is outlined below
- To test the passthrough service is working correctly click "Verify Passthrough" and add a test IP. The check will perform a query on the specified device and return the last logged on SAM username
- Click "Save" and apply all changes
Installing the Pass-through Service
An administrator will need to install the pass through authentication service on the Active Directory server or a member server. You can check which Active Directory server that is by going to Configuration > Authentication > Active Directory Plugin on the CyberEdge. If a member server is used instead of the Active Directory server, the hostname or IP address of the member server must be specified in the Pass-through authentication options page.
Follow the steps below to install the service:
- Log on to the Active Directory server or a member server
- Run the
nbpassthroughservice.msi
file to install the required software - Go to Start > Programs > Administrative Tools > Services
- Scroll down to CyberEdge Pass Through Authentication and double-click to open
- Configure the Service Account that will be used. This must be a domain administrator account.
- Ensure the CyberEdge Pass Through Authentication service is selected and click the Restart Service button.
- The service status should now be running
- Ensure that the CyberEdge can connect to port 60333 on the AD server. This may require adding a rule on any firewall between the CyberEdge and the Pass-through service
Info
A reboot of the Windows server hosting the pass-through service is NOT necessary after the service installation
Configuring Windows Client Device
The Pass-through service utilizes the Microsoft Remote Registry Service (RRS) to obtain the username from the client devices registry. As such, the Remote Registry Service (RRS) is required to be active on the client machine for the pass through authentication service to determine which user is logged in. This service is installed in all versions of Windows, but is disabled by default. To enable the service, create a new group policy by going to Windows Settings > Security Settings > System Services > Remote Registry service and set Startup mode to Automatic. It is strongly recommended this configuration be applied to all devices requiring Active Directory Pass-through authentication.
Tip
- On some devices, the Microsoft Remote Registry Service (RRS) may automatically disable itself as part of Microsoft's power saving configuration or due to low memory. In these cases, the remote registry service can be kept active continuously by setting this registry key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\RemoteRegistry\DisableIdleStop to the value 1. The type must remain REG_DWORD.
- Verify the client device firewall will accept connections from the Pass-through service IP addresses
Disable Fast User Switching
Fast user switching allows multiple users to log in to a Windows device simultaneously. As a result, multiple usernames are stored in the registry with no way to accurately distinguish the active user. As a result, fast user switching is not supported. To disable fast user switching, create a new group policy object or modify an existing one to set Computer Configuration > Administrative Templates > System > Logon > Hide entry points for Fast User Switching to Enabled.
Last Logon Configuration
In some situations there may appear to be more than one user logged in to a device even when only one user is active. This can happen for example when a program or service is running as a different user than the user who is logged in. In these situations, the Pass-through Authentication service may be configured to report only the last user who logged in, rather than all users. This has the drawback that if more than one user is logged in simultaneously, the wrong user may be authenticated.To enable this option, open regedit, and navigate to the registry key:
- HKEY_LOCAL_MACHINE\SOFTWARE\NBB\PassThroughAuth, change the value UseLastLogon to 1, and restart the NBBPassThroughService
- The type of the registry value must remain as a REG_SZ.##
Multi CyberEdge Configuration (Not in HA Cluster)
The Pass-through Authentication service will only accept connections from the CyberEdge. To do this, the service does a DNS lookup for www.localnetwork.zone and only accepts connections from that IP Address when not in HA configuration. If the domain controller or member server is used by multiple CyberEdge devices, this will not work. Instead, manually add trusted IP addresses by navigating to
- Open Regedit
- Go to HKEY_LOCAL_MACHINE\SOFTWARE\NBB\PassThroughAuth
- Edit the value ValidIPs and enter the IP addresses of the CyberEdge Appliances, one per line
Note
The type of the registry value must remain as REG_MULTI_SZ.
Troubleshooting
If the user authentication sessions are not being created successfully, the following troubleshooting steps should be undertaken:
- Verify if the Active Directory service is working correctly. Go to Authentication > Zone Access > Pass-through Authentication > Edit > Verify Passthrough. Add a client IP address and click test. If no username is returned, try an alternate test device to see if the issue is device specific
- If the issue is device specific, refer to the client device setup documentation for information on how to correctly configure a client device
- Verify the Pass-through service on the domain controller or a member server is running. If not, start the service and retest
- Verify if the CyberEdge can connect to the Pass-through service installed in the domain controller or a member server on port 60333. To test, access the CyberEdge CLI and run ncat ip address 60333. The connection is made using Telnet
If the CyberEdge is unable to establish a connection on port 60333, check networking and firewalls between the CyberEdge and the Pass-through service host device To view additional logs, navigate to the authentication log viewer via Status > Log Viewer > Authentication
SSH Pass-through Authentication
SSH Pass-through Authentication enables automatic creation of user authentication sessions. When CyberEdge detects traffic from an unauthenticated device, the SSH pass-through authentication service initiates an SSH connection to the device's client IP address using the credentials specified in the SSH pass-through configuration. If the connection is successful, the service retrieves the currently logged-in user. On macOS, which is the most common platform requiring SSH Pass-through authentication, this will typically be the user at the console. Upon successful retrieval, an authentication session is established using the returned username and IP address with the configured authentication provider.
Configure SSH Pass-through Authentication
To configure SSH Pass-through Authentication:
- Navigate to Authentication > Zone Access > Pass-through Authentication
- Click "Add"
- Select "SSH Authentication" and add the SSH authentication details as follows:
- Name: Provide a name for the Pass-through service
- Authentication Timeout: Set a timeout for the SSH connection (Recommended 7 seconds). After the specified timeout elapses, the client device will be served the captive portal as the fallback method of authentication
- Session Timeout: The inactivity timeout for authentication sessions created using the SSH Pass-through method. If no network traffic for the client IP is detected for the specified period, the authentication session will be removed
- Authentication Providers: The authentication provider to be used by the SSH Pass-through authentication service. This may be different to other Pass-through methods
- Username: The username to be used by the SSH Pass-through service to connect to the remote device
- Click "Save"
- Setup the preferred authentication method for the SSH Pass-through service. To access client devices from the CyberEdge, two authentication options are available. These include username/password or key based authentication. For username/password based authentication, create a new secure password. For key based authentication, an SSH key pair was automatically generated for use by the SSH Pass-through service. The public key is available within the UI and will be used on the client device to allow secure SSH connections from the CyberEdge.
- Click "Save" and apply changes
- You must add the user account and public key (if selected) to the client machine. Please refer to your device operating system documentation on how to add the required user accounts and/or the public SSH key.
- To Verify that your SSH Pass-through service is working correctly click "Verify Pass-through" and provide the IP address of a test device.
- Click "Check IP". You will be notified of a successful or failed authentication attempt.
To view a successful authentication session navigate to:
- Status > Sessions
- View authentication sessions. The creation method of the authentication session will be SSH Pass-through
Note
- Live authentication logs can be viewed at Status > Log Viewer > Authentication
- SSH connections are made on Port 22 from the CyberEdge to the client device. Verify the client device firewall allows inbound SSH access on port 22 from the CyberEdge IP address/s
- The private SSH key is never disclosed. If for any reason a new SSH key pair is required, delete the existing SSH Pass-through service and create a new one
- The SSH Pass-through service only support CyberEdge generated SSH keys generated during the setup process
- If both username/password AND key based authentication is configured, it will try both methods of authentication. It is recommended to use only a single method of authentication
Troubleshooting SSH Pass-through Authentication
If the CyberEdge is unable to create authentication sessions using the SSH Pass-through authentication service, please check the following:
- Verify if the Pass-through service is able to connect to client devices. Go to Authentication > Zone Access > Edit SSH auth service > Verify Pass-through service. The test will create an SSH connection to the client IP
- If you cannot create a successful SSH connection to the client device, verify the CyberEdge can access the client. To ping the client from the CyberEdge go to Status > Network tools > Ping and test the client IP
- Ensure that the client device's firewall is allowing inbound SSH access on port 22 from the CyberEdge's IP
- Verify that no ACL's between the CyberEdge and the client device are blocking SSH connection attempts
- Ensure the username/password provided is correct and a user account has been created correctly on the client machine. You can test this from a device other than the CyberEdge if required
- When using key based authentication, ensure the public key is correctly installed in the client device
Captive Portal
The Captive Portal is the default method of authentication on the CyberEdge when authentication is enabled, and no automated Pass-through options have been configured. CyberEdge will automatically re-direct traffic on ports 80/443 to the Captive Portal page and require the user to provide valid credentials to create an authentication session. Until a user authentication session is created, all traffic from the source IP requiring authentication will be dropped by the firewall. The CyberEdge Captive Portal is served via https://login.localnetwork.zone
If one or more Pass-through Authentication methods are configured, the captive portal will be used as a fallback method of authentication where automated authentication attempts are unsuccessful.
Note
Automated pass-through authentication methods are significantly more efficient and offer a better overall user experience.
Captive Portal Providers
Some networks utilize multiple authentication providers such as MS Active Directory, OpenLDAP, Local users and groups and more. If required, a system administrator can specify which authentication providers may be used by the Captive Portal to create authentication sessions. To configure Captive Portal providers, go to Authentication > Zone Access > Captive Portal Enabled Providers. The network administrator must specify at least one provider to be used by the Captive Portal.
Captive Portal SSO
The CyberEdge Captive Portal offers support for Microsoft and Google Single Sign-On (SSO) options, minimizing the need for users to enter credentials each time the Captive Portal is accessed. For detailed instructions on setting up this option, please refer to the Single Sign-On configuration guide. Network administrators have the flexibility to enable both username/password authentication and Single Sign-On, or they can opt to restrict access solely to Single Sign-On. To ensure successful authentication, Microsoft and Google Single Sign-On providers must be accessible from the network. To support Single Sign-On, a CyberEdge service automatically maintains an authentication exclusion list for both Microsoft and Google.
Note
CyberEdge leverages the inbuilt Captive Portal framework for Apple MacOS/iPadOS/iOS and Microsoft Windows. In the event the Captive Portal is not loading on a device, ensure the following domains are not listed in the authentication exclusion:
- captive.apple.com
- www.msftconnecttest.com
- www.msftncsi.com
Tip
The following outlines steps that should be undertaken when investigating Captive Portal authentication issues.
- To view the CyberEdge authentication logs go to Status > Log Viewer > Authentication.
- If automated Pass-through Authentication methods have been configured and users are receiving the Captive Portal, it infers that one or more Pass-through methods are configured incorrectly, Pass-through methods are timing out or an authentication provider is not accessible
- If Single Sign On is not correctly authenticating a user, it is possible the Single Sign On authentication host is not in the authentication exclusion list. If this occurs, users should simply retry the authentication request by which time the exclusion list should be updated
Customise Captive Portal
System administrators have the ability to design and implement customized captive portal login pages, providing a tailored and branded user experience for network access. These portals can be configured to align with the organization's aesthetic and functional requirements, including custom logos, backgrounds, CSS and messaging. This allows organizations to control network access effectively while delivering a cohesive and professional impression to users. To create a custom captive portal page go to Authentication > Captive Portal.
Upload Images
To add a custom logo to the captive portal, go to Authentication > Captive Portal > Captive Portal Customisation:
- Upload a portal logo image
- Upload a background image
- If required, add a custom message to be displayed on the portal page
- Click "Save"
- To preview the portal page in the browser, click "Preview". Note, you are not required to save and apply configuration changes whilst previewing.
- To publish the new captive portal page, click "Save" and "Apply Changes"
Portal Preview
Tip
You can preview the captive portal page without having to Apply Changes
Note
- Zone Access must been enabled to preview the custom captive portal page. Without zone access enables, trying to preview the customer portal page will result in an error
- Supported file formats include .jpg, .jpeg, .png
- The maximum supported image size is 2MB.
Custom CSS
To create a more personalized captive portal, you can incorporate your own CSS. To do this, navigate to Authentication > Captive Portal > Captive Portal Customization > CSS Override:
- Click "Edit"
- Add the new CSS
- Click "Ok"
- Click "Save"
- To preview the portal page in the browser, click "Preview". Note, you are not required to save and apply configuration changes whilst previewing
- To publish the new captive portal page, click "Save" and "Apply Changes"
Restore Default
To revert to the default CyberEdge captive portal page, delete the uploaded images and CSS Overrides, then click "Save" and "Apply Changes".
RADIUS 802.1x Authentication
RADIUS 802.1x authentication is a commonly used network access control method that enhances security by requiring devices to authenticate before gaining network access. When a device attempts to connect to a wired or wireless network with 802.1x enabled, it must complete an authentication process overseen by a RADIUS server. This server checks the device's credentials against a centralised directory, such as Active Directory, and authenticates both the user and the device to the network. Upon successful authentication, the RADIUS server generates and sends accounting records to monitor the session, enabling CyberEdge to create a user authentication session. Key RADIUS accounting records include the START record, which is generated when a session begins, and the Interim update record, which provides regular status updates throughout the session. CyberEdge processes these RADIUS accounting START
and Interim update
records to create and manage user authentication sessions.
RADIUS Configuration
Below is the configuration guide for enabling RADIUS authentication, along with recommended best practice settings. To enable RADIUS 802.1x authentication go to:
- Authentication > Zone Access > Passthrough Authentication > Add RADIUS 802.1x
- Name: Enter a name for the passthrough service
- Authentication Timeout: The configured period (in seconds) specifies how long the CyberEdge will wait for an 802.1x RADIUS accounting START record before redirecting to the captive portal. The recommended default value is 7 seconds, but this may vary based on your networking vendor.
- Session Timeout: The duration after which an authentication session will be terminated if CyberEdge does not detect any traffic from the authenticated device. The recommended default value is 8 hours.
- Authentication provider: The provider hosting the users and groups required by the RADIUS authentication service
- Click "Save"
- Click "Save and Apply Changes"
After enabling, proceed to configure a RADIUS client as follows:
- Click “Add” to add a new RADIUS client
- Set the RADIUS client to "enabled" and add a description
- Add the RADIUS Client IPs to the ACL list, which should include the IP address of any systems sending RADIUS accounting records to CyberEdge. Depending on your network vendor, this may encompass WLAN Controllers, WAPs, or RADIUS servers. RADIUS accounting records sent from IP addresses not included in the ACL list will be discarded, causing the affected users to be redirected to the captive portal as the fallback authentication method.
- Add the shared secret for your networking RADIUS device
- Click "Save"
- Click "Save and Apply Changes"
Important Information
- RADIUS accounting
INTERIM updates
are processed asSTART
records to create or extend user authentication sessions. The following attributes and values are required by CyberEdge to establish an authentication session:User-Name
=example.user
andFramed-IP-Address
=10.10.33.104
. - RADIUS accounting
STOP
records are disregarded by the CyberEdge and will not end a user authentication session - If a CyberEdge RADIUS client is disabled, RADIUS accounting records will be dropped by the firewall
- RADIUS accounting utilizes the UDP protocol on port 1813
- CyberEdge accepts 802.1x RADIUS accounting records only from client IPs listed in the Client IPs list. 802.1x accounting records from other sources will be dropped by the firewall, and no authentication session will be created for the user. It is important to ensure the ACL list is always updated with any changes to the network to avoid authentication issues
- Some network vendors do not enable RADIUS interim updates by default, even though they are often necessary to create authentication sessions. Please consult your network vendor to ensure that interim updates are enabled
Troubleshooting
- Depending on your wireless vendor, 802.1x RADIUS accounting records may be sent directly from the Wireless Access Point (WAP). If so, all WAP IP addresses must be added to the Client IP list to avoid situational authentication issues resulting in users redirecting to the captive portal. Always verify the WAP, WAP Controller or RADIUS server IPs are in the list.
- In certain situations, network vendors may send RADIUS accounting START records before the DHCP process is complete. When this happens, the Framed-IP-Address value in the accounting record may be empty, display placeholder IPs like 0.0.0.0, or show the device's last-used IP address, which might not correspond to the current network. In any of these cases, 802.1x authentication will fail, and the user will be redirected to the captive portal unless an INTERIM update is received promptly to start a session. To diagnose this issue, a packet capture of the RADIUS accounting record on the CyberEdge should be conducted. Please consult your network vendor for details on how to prevent this occurring.
- Some network vendors might use the device's MAC address as the value in the
User-Name
RADIUS attribute. It's advisable to consult your network vendor to address and resolve this configuration issue - RADIUS accounting utilizes the UDP protocol on port 1813. You should verify if network devices may be blocking UDP traffic on Port 1813 between your networking equipment and CyberEdge
- Verify the shared secret is correct
- To view RADIUS 802.1x authentication logs to go Status > Log Viewer > Authentication
RADIUS Accounting Log Examples. note: Log formats may vary between network vendors
Radius Accounting START Record: (In this example, an authentication session will be created for User-Name=test.user on Framed-IP-Address=10.10.33.104)
Aug 14 12:56:31 EG-03 RADIUS_Accounting 0002002492 3 0 2024-08-14 12:56:31.077 +10:00 0033232823 3000 NOTICE
Radius-Accounting: RADIUS Accounting start request, ConfigVersionId=24, User-Name=test.user,
NetworkDevice=Radius-test,
NAS-IP-Address=10.10.252.71, NAS-Port=50102, Framed-IP-Address=10.10.33.104,
Called-Station-ID=C0-5C-19-GD-FB-12, Calling-Station-ID=99-FC-55-E0-35-77, Acct-Status-Type=Start,
Acct-Delay-Time=0, Acct-Session-Id=000001c7, Acct-Authentic=Remote, Event-Timestamp=1723604191,
NAS-Port-Type=Ethernet
Radius Accounting Interim Update Record: (In this example, an authentication session will be created for User-Name=test.user2 on Framed-IP-Address=10.10.33.200)
Aug 14 12:56:31 EG-03 RADIUS_Accounting 0002002492 3 0 2024-08-14 12:56:31.077 +10:00 0033232823 3000 NOTICE
Radius-Accounting: RADIUS Accounting update request, ConfigVersionId=24, User-Name=test.user2,
NetworkDevice=Radius-test, NAS-IP-Address=10.10.252.71, NAS-Port=50102, Framed-IP-Address=10.10.33.200,
Called-Station-ID=C0-5C-19-GD-FB-12, Calling-Station-ID=99-FC-55-E0-35-77, Acct-Status-Type=Interim-Update,
Acct-Delay-Time=0, Acct-Session-Id=000001c7, Acct-Authentic=Remote, Event-Timestamp=1723604191,
NAS-Port-Type=Ethernet
FortiGate Authentication Service
In networks where both a FortiGate and CyberEdge device are installed, user authentication sessions on the CyberEdge can be automatically created from the FortiGate by forwarding authentication events via syslog. This eliminates the need for users to authenticate twice on the network. This approach is commonly used in deployments where policy-based routing is configured on the FortiGate, with 80/443 traffic being forwarded to the CyberEdge.
To create a FortiGate Authentication service on the CyberEdge navigate to;
- Authentication > Zone Access > Pass-through Authentication
- Click "Add"
- Select "FortiGate Service" and add the FortiGate Service details;
- Name: Provide a name for the Pass-through service
- Authentication timeout: Set a timeout for receiving authentication events (Recommended 7 seconds). After the specified timeout elapses, the client device will be served the captive portal as the fallback method of authentication
- Session Timeout: The inactivity timeout for authentication sessions created using the FortiGate service. If no network traffic for the client IP is detected for the specified period, the authentication session will be removed
- Authentication Providers: The authentication provider to be used by the FortiGate authentication service. This may be different to other Pass-through methods
- FortiGate IP's: The client IP's (ACL) that the CyberEdge will accept authentication logs from.
- Click "Save"
- Click "Save and Apply Changes"
Important information
- Live authentication logs can be viewed at Status > Log Viewer > Authentication
- The CyberEdge is configured to receive FortiGate SYSLOG events using TCP on Port 30514. This is not configurable
- SYSLOG data from the FortiGate to the CyberEdge is not encrypted in transit and should be done over a secure network connection
- For information in how to configure FortiGate authentication syslog forwarding, please consult the FortiGate documentation
Cisco ISE Authentication
Networks utilizing Cisco Identity Service Engine (Cisco ISE) can create a Cisco ISE Pass-through service allowing authentication sessions to be created on the CyberEdge when a user successfully authenticates to the network. Cisco ISE forwards RADIUS accounting data, including the username and IP address, via SYSLOG. When received, the SYSLOG authentication message is translated internally and processed as a RADIUS accounting record.
To create a Cisco ISE authentication service:
- Navigate to Authentication > Zone Access > Pass-through Authentication > Add
- Click "Cisco ISE Service" and add the following configuration;
- Name: Add a name for the Pass-through service
- Authentication Timeout: Set a timeout to wait for the SYSLOG event from the Cisco ISE server (Recommended 7 seconds). After the specified timeout elapses, the client device will be served the captive portal as the fallback method of authentication
- Session Timeout: The inactivity timeout for authentication sessions created using the Cisco ISE Pass-through method. If no network traffic for the client IP is detected for the specified period, the authentication session will be removed
- Authentication Providers: The authentication provider to be used by the Cisco ISE Pass-through authentication service. This may be different to other Pass-through methods
- Cisco ISE IP's: Specify the IP address/s of the Cisco ISE servers that will be forwarding authentication data via SYSLOG
- Click "Save"
- Click "Save" and "Apply Changes"
Important
- The
User-Name
andFramed-IP-Address
attributes MUST be identical as documented in the accounting record. They must contain a valid username from your directory service, such as user.test, and the device's IP address, e.g., 10.10.14.100, before an authentication session can be established on the CyberEdge - Accounting records with invalid attributes will be discarded, causing users to be redirected to the captive portal
- In certain instances, Cisco ISE may forward START records before DHCP has completed, leading to invalid values being sent for the
Framed-IP-Address
. To prevent this, it is recommended to introduce a delay of approximately 2-3 seconds before sending the accounting records. For more details, please consult the Cisco ISE documentation - Depending on the Cisco RADIUS/ISE configuration, the client MAC address might be sent as the value for the
User-Name
attribute in the START accounting record. Such records will be discarded by CyberEdge. To avoid issues, always ensure thatInterim update
is enabled - 802.1r is not supported by the CyberEdge
Note
- The CyberEdge listens for Cisco ISE SYSLOG messages via TCP on port 30513. This setting is not configurable
- Cisco ISE servers can be deployed in a high availability (HA) configuration. If multiple Cisco ISE servers are present, make sure that all server IP addresses are added to the Client IP address list (ACL) to prevent authentication failures. SYSLOG messages from IP addresses not included in this list will be dropped
- For guidance on configuring Cisco ISE RADIUS syslog forwarding, please refer to the Cisco ISE documentation. CyberEdge does not offer technical support for third-party network vendors.