The “Add identity” window should now list the identity name and the MAC addresses linked to the identity. At this point it is possible to change the identity policy if a policy has already been created, for now, we will use the default policy.

Our identities and authentication page should now list a single identity. This process will be repeated until all devices on the network have been identified.

The default identity will assist in managing unknown devices on the network, typically network administrators will alter the default policy, linked to the default identity, to by default block all internet access. This process ensures that new devices connecting to the network will not be granted internet access by default.

Editing the default identity will enable the network administrator to set the default policy for all unknown devices, it will also allow the network administrator to link network ranges to a particular policy. This Network SRC Policy will be applied across all unidentified devices within a particular network range.

The SRC Network policy feature is useful for large networks where it would typically not be feasible to individually identify all devices, or if there is no specific requirement to manage individual device access.

To add a Network SRC Policy rule click on the “Add Network Src Policy Rule” button.

The default identity will now accept additional parameters to configure the SRC network policy as seen here.

Enter the following information to link a policy to a particular network range.

• SRC Network Range - 192.168.1.0

• Network Mask - 255.255.255.0 / 24

• Policy - defaultpolicy

The SRC network policy can now be added by clicking on the “Add” button.

The default identity should now list the SRC network along with the linked policy as seen here.

Remember to click the “Update Identity” button to save the changes before we apply a reload, committing the changes to the iShield configuration file.

Our default identity should now list the SRC network policy when viewing the “Identities and Authentication” page as seen here.

To begin using the iShield captive portal, first set the captive portal network ranges. To do this click on the “Add Range” button under the “Captive Portal IP Ranges:” options.

The “Add Captive Portal IP Range” dialog box will appear, it will accept two parameters.

• IP Address/Network Range - 192.168.1.0

• Subnet - 255.255.255.0 / 24

Once the network range or IP address and the associated subnet mask have been set, click the “Add IP Range” button to save the changes.

The captive portal page should now list the network ranges and IP addresses that will require device/user authentication. 

Note: Remember to click the “Save changes” button, the changes may not be committed if we navigate away from the page without having clicked this button.

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.