From the menu, select Identities & Authentication.

• Click Add Identity.

• Enter the Identity Name.

• Click Add Device.

In the Select devices allocated to identity window:

• Search for the device by:

  • MAC address, or

  • IP address

• Select the required device(s).

• Click Assign Devices.

• The Add Identity window will now display the identity name and linked MAC addresses.

  • • At this stage, a policy may be selected if one has already been created. For this example, the default policy is used.

  • Click Add Identity to complete the process.

• Repeat this process until all required devices on the network have been identified.

The Default Identity is automatically applied to any device that has not yet been bound to a specific identity.

Managing the default identity is a critical part of network security. Common best practice is to associate a restrictive policy with the default identity—often blocking internet access entirely—so that new or unknown devices are denied access by default.

Editing the default identity allows the administrator to:

• Define the default policy for all unidentified devices

• Apply policies to entire network ranges using SRC Network Policies

This feature is particularly useful in:

• Large networks

• Environments where individual device identification is impractical

• Scenarios where per‑network policy enforcement is sufficient

Adding a Network SRC Policy Rule

• Navigate to the Default Identity.

• Click Add Network Src Policy Rule.

The Edit Default Identity configuration window will expand to include SRC Network Policy options.

Required Parameters:

• Network SRC: 192.168.1.0

• Netmask: 255.255.255.0 / 24

• Policy: select the required policy

3. Click Add.

4. Click Update Identity to save the changes.

Changes will not be committed until a reload is performed.

The default identity will now display the configured SRC network and linked policy on the Identities & Authentication page.

Define the IP ranges that require authentication. 

Click Add Range under Captive Portal IP Ranges. 

Complete the following fields:

• IP Address: 192.168.1.0

• Subnet: 255.255.255.0 / 24

• Click Add IP Range.

• Click Save changes.

Note: Changes will not be committed if you navigate away without saving. 

The next step in configuring the captive portal is to enable or disable Guest logins.

Allowing guest access will offer the user the option to authenticate as a guest user. To ensure that users are not authenticating as guests in an attempt to evade filters, we recommend configuring a strict policy to only allow a specific set of websites that would typically enable the customer or user access to critical business and/or communication resources.

The Local Users external authenticator can be created by clicking on the “Add External Authenticator” button. 

The “Add external authenticator” dialog box will appear. This dialog box will accept two parameters as seen below.

• Authenticator Name - this will be used to reference the local users authenticator in the future.

• Authenticator Type - Azure AD or Local Users.

Your captive portal page should now list the newly created Local Users external authenticator if you selected the "Local Users" authenticator type in the previous step.

To create a user, click on the “Manage Users” button.

A dialog box will appear where new users will be created, these users will authenticate with the defined credentials when connecting to the network.

To create a new user click the “Add User” button.

A new dialog box will appear and accept the following parameters.

• Username - this is the username for the user to authenticate their session. The username can consist of any string of characters. Network admins are typically recommended to use the users email address (this will not send the user an email and will not authenticate with the email provider).

• Friendly Name - the friendly name field will appear in the iShield reports. This friendly name cannot be used to authenticate the users session.

• Policy - the policy can be altered to restrict website access, policies will be created in the next module.

• Enabled - the enabled state determines whether the user is allowed to log in or not. Disabled state prevents the user from authenticating their session and the enabled state will allow the user to authenticate their session.

• Password: The password field is set and managed by the network administrator directly from the iShield. The password can only be changed manually by the network administrator and must be shared with the user for them to authenticate their session. A minimum of six characters is required.

Click the save button to save the user; we will now be redirected to the captive portal user overview page where our new user will now be listed.

The user can be edited at any time to change their friendly name, policy, enabled state, or password.

Our captive portal page should now list a single user under the “local” external authenticator. As more users are added, the number will increment accordingly.

Complete the intial Azure integration by populting the required fields.

• Name: The friendly name field is used to reference this particular external authenticator if future changes are required, assuming that there is more than one Azure AD external authenticator configured.

• Enabled: This field sets the Azure AD integration state, if enabled users will be permitted to authenticate with their Azure credentials. If disabled; this external authenticator will not permit user authentication using Azure AD/Azure Entra ID.

• Type: Azure Active Directory

• Friendly Name: The friendly name field is used to reference this particular external authenticator if future changes are required, assuming that there is more than one Azure AD external authenticator configured.

• TenantID: The tenant ID is found within your Azure portal under the Azure Entra ID app.

• Prompt Mode: 

  • prompt=login forces the user to enter their credentials on that request, negating single-sign on.

  • prompt=none is the opposite. It ensures that the user isn't presented with any interactive prompt. If the request can't be completed silently by using single-sign on, the Microsoft identity platform returns an interaction_required error.

  • prompt=consent triggers the OAuth consent dialog after the user signs in, asking the user to grant permissions to the app.

  • prompt=select_account interrupts single sign-on providing account selection experience listing all the accounts either in session or any remembered account or an option to choose to use a different account altogether.

Once the required information has been entered, click the “Add External Authenticator” button.

Our captive portal page should now list the Azure AD/Azure Entra ID external authenticator.

To finalize the integration, click on the “Test / Connect AD” button to authorize the iShield’s connection to your Azure tenant.

The authorization page will appear denoting the permissions requested by iShield to interact with your Azure tenant, click on the “Accept” button to move to the next step.

Microsoft requires that you authroize the integration using an administrator account.

Once the integration has been completed you will be redirected to a local page confirming the connection after completing an initial test.

Users connecting to a captive portal IP range will be presented with the following Captive Portal login page.

The user must enter their local account, Microsoft Azure AD / Entra ID credentials to authenticate their session. Alternatively, the user can authenticate as a guest should they not have any credentials specifically assigned to them.

On successful login the user will be permitted to connect to the internet and can access any allowed resources based on their linked policy.

Now that we have the captive portal configured, enable the Captive Portal feature and apply the changes by navigating to System Commands > Reload Unit and click the “Soft Reload” button.

This will reload the modules changed and apply the configuration.

Take Note: the “Reload Unit” menu item will display a yellow refresh arrow indicating that there are pending changes that must be applied. Initiating a Soft Reload will reload modules that have been changed. A Full Reload will reload all iShield modules.