Authentication Partitioning and Multi LDAP Servers
03/26/2020 54 13607
SonicOS 6.5 introduces support for user authentication partitioning and multiple LDAP servers.
NOTE: Multiple LDAP servers are supported on all platforms.
Authentication partitioning is a high‐end feature that is only relevant for customers whose networks are big enough to encompass multiple Active Directory forests, etc. User authentication partitioning provides a mechanism for LDAP, RADIUS, and/or Single‐Sign On (SSO) authentication in an environment where you manage multiple non‐interconnected domains. Such an environment needs users in a particular domain to be authenticated via the specific:
- LDAP/RADIUS server for that domain.
- SSO agent(s) located in that domain.
What User authentication partitioning means?
- Partitioning your network(s) into separate partitions, each with its own authentication servers/agents/clients.
- Authenticating each user against the relevant servers/agents/clients according to the authentication partition in which the user is located.An authentication partition typically corresponds to one or more domains; for example, in a Windows domain, a partition usually corresponds to an Active Directory forest. Each partition has separate LDAP servers, RADIUS servers, SSO agents, and/or Terminal Service agents (TSAs).
CAUTION: Users authentication Partitioning is available only on NSA 3600 and above, and all SuperMassive platforms.
The partitions configured under Authentication Partitions control which authentication servers are used for which users, where those users are in different network partitions. The policies configured under Partition Selection Policies define the selection of the above partitions based on the physical location of users being authenticated. When authenticating users whose domain names are not available for matching against those in the above partitions, the users’ partitions are selected based on their physical locations as set by these policies. These policies are also used for auto‐assigning authentication devices to partitions based on physical location of the devices. By clicking Add under Authentication Partitions, you can add either a top level partition or a sub‐partition.
- Click Manage in the top navigation menu.
- Click Users | Partitions and enable Authentication partitioning.
- Click add for adding an authentication partition / Partition Selection Policies.
Authentication partitions select the LDAP servers, RADIUS servers, SSO agents, and TSAs used to authenticate particular users. In addition to assigning the servers and agents to a partition, it may be necessary to assign certain of them to different subsets of the users in the partition. Sub‐partitions allow assigning particular agents for certain subsets of a partition’s users if specific ones need to be used for them. If an authentication partition isset as a sub‐partition of another one, then agentsspecific to the top level, or parent, authentication partition’s users can be assigned to the sub‐partition. The sub‐partition’s agents are used when relevant, but the servers and agents of the parent partition can be used as appropriate.
Multiple primary LDAP servers can be configured, one for each authentication partition, plus a list of additional servers for each. More than two RADIUS servers can also be configured. When adding an authentication server or SSO/TS/RADIUS Accounting agent in the Users | Settings page, you must select the authentication partition if more than one partition is configured. Multiple authentication partitions will usually require using different DNS servers to resolve the host names in the different partitions. In SonicOS 6.5, the Split DNS feature is separated from DNS Proxy to accommodate this configuration. The Split DNS configuration is moved from the DNS Proxy page to the main Network | DNS page. DNS servers configured in Split DNS are now used directly for DNS lookups of host names in internal domains.
To configure Split DNS:
- Click Manage in the top navigation menu.
- Click Network | DNS.
NOTE: Sub-partitions allow assigning particular agents etc. for certain subsets of a partition's users if specific ones need to be used for them. If an authentication partition is set as a sub-partition of another one, then agents etc. specific to its users can be assigned to it so that those will be used when relevant, but also allowing the servers and agents of the parent partition to be used, as appropriate (see below).
EXAMPLE: take a scenario where it is necessary to locate SSO agents at each of a number of remote sites in order for those agents to be able to identify the users there, while the LDAP and RADIUS servers are all located at the central site. For this, each of the remote sites can be configured as a sub-partition of the central site, with the SSO agent(s) at a remote site assigned to its sub-partition. Then, after selecting the relevant agent from the sub-partition to identify a user at the remote site, the user's group memberships would subsequently be looked up via the LDAP servers of the parent partition.
Some special cases for sub-partitions are:
- If a sub-partition corresponds to a sub-domain that has its own LDAP servers, then those servers can be assigned either to it or to its parent partition. This is purely a display preference
and makes no difference to their operation (internally the LDAP servers are all linked to the parent partition and the LDAP protocol takes care of referring requests to the sub-domains' servers).
- For RADIUS servers a sub-partition will use either servers assigned to it or those of the parent partition, but not both. If RADIUS servers are assigned to a sub-partition then they will be
used for users located in it, otherwise those of the parent partition will be used.
- With SSO agents using NetAPI or WMI (versus reading from domain controller logs) if there are agents in both a sub-partition and its parent, then for NetAPI/WMI identification of users located
in the sub-partition, only the sub-partition's own SSO agents will be used (since those involve direct access to the user PCs there). But domain controller log reading can be done by SSO agents
in the parent and/or sub-partitions, if they are configured for that.