15.4  User accounts in Active Directory — domain mapping

In WinRoute, it is possible to directly use user accounts from one or more Active Directory domain(s). This feature is called either transparent support for Active Directory or Active Directory domain(s) mapping. The main benefit of this feature is that the entire administration of all user accounts and groups is maintained in Active Directory only (using standard system tools). In WinRoute, a template can be defined for each domain that will be used to set specific WinRoute parameters for user accounts (access rights, data transfer quotas, content rules — see chapter 15.1  Viewing and definitions of user accounts). If needed, these parameters can also be set individually for any accounts.

Note: The Windows NT domain cannot be mapped as described. In case of the Windows NT domain, it is recommended to import user accounts to the local user database (refer to 15.3  Local user database: external authentication and import of accounts)

Domain mapping requirements

The following conditions must be met to enable smooth functionality of user authentication through Active Directory domains:

  • For mapping of one domain:

    1. The WinRoute host must be a member of the corresponding Active Directory domain.

    2. Hosts in the local network (user workstations) should use the WinRoute's DNS forwarder as the primary DNS server, because it can process queries for Active Directory and forward them to the corresponding domain server. If another DNS server is used, user authentication in the Active Directory may not work correctly.

  • For mapping of multiple domains:

    1. The WinRoute host must be a member of one of the mapped domains. This domain will be set as primary.

    2. It is necessary that the primary domain trusts any other domains mapped in WinRoute (for details, see the documentation regarding the operating system on the corresponding domain server).

    3. For DNS configuration, the same rules as in mapping of a single domain are applied (the WinRoute's DNS forwarder is the best option ).

Domain mapping settings

To set Active Directory domain mapping, go to:

  • the Administration Console, section Users and groups → Users, the Active Directory tab,

  • in the Web Administration interface, section Users and Groups → Domains and authentication, the Active Directory.

Connecting the firewall to a domain (Software Appliance / VMware Virtual Appliance)

The upper section of the Active Directory tab provides information about domain membership of the firewall's host.

In the Software Appliance / VMware Virtual Appliance edition, it is possible to add the firewall to a domain, change domain membership or disconnect the firewall from the domain.

This can be done in the easy-to-use wizard.

Adding firewall to a domain

Figure 15.11. Adding firewall to a domain


The first page of the wizard requires the full name of the Active Directory domain (e.g. company.com) and name and password of a user with rights to add hosts to domains.

If WinRoute cannot find the domain server of the specified domain automatically, it requires specification of its IP address in the next step. Then the user gets informed about the result of the attempt to add the firewall to the domain.

Primary domain mapping

To set mapping of the primary domain (the domain of which the firewall host is a member), use option Use domain user database. For connection to the domain server, it is required to enter username and password of an account with read rights for the user database (any user account of the domain can be used, unless it is blocked).

Primary domain mapping

Figure 15.12. Primary domain mapping


Advanced Options

Method of cooperation between WinRoute and the Active Directory can be customized by some advanced options.

Advanced options for cooperation with the Active Directory.

Figure 15.13. Advanced options for cooperation with the Active Directory.


Domain mapping vs domain user authentication

The recommended method of cooperation with the Active Directory is domain mapping (user accounts are saved and managed only in the Active Directory). However, this can be undesirable under certain circumstances. For example if the Active Directory is implemented in a network where the Windows NT domain or no domain has been used, user accounts are already created in the WinRoute's local database. In such case, the best solution is to keep the local accounts and set only authentication in the Active Directory (so that users can use the same password both for the domain and the firewall).

If WinRoute is installed on Windows, it is possible to allow authentication compatible with older systems (i.e. authentication via the Windows NT domain). This option is required if the domain server uses Windows NT or if any of the clients in the local network uses Windows of older edition than Windows 2000. In Software Appliance / VMware Virtual Appliance, this option is not available (authentication in Windows NT domain is not supported).

Then, the settings include an option of automatic import of user accounts from the Active Directory to the local database (upon the first logon of user to the firewall by their domain name and password, an account with the same name will be created in the local database automatically). This option is available above all to keep the environment compatible with older WinRoute versions. In new installations it is strongly recommended to use domain mapping — administration of users is much more simple and much less time consuming. For details, see the Administrator's Guide for older versions of WinRoute (versions 6.7.0 or lower).

Selection of a domain server

In the default configuration, WinRoute automatically detects domain servers for the specified domain and uses the first detected server for connection to the Active Directory. Automatic detection simplifies configuration significantly (it is not necessary to specify IP addresses of individual domain servers).

If necessary, you can specify name of IP address of a specific domain server. In such case, WinRoute will not perform automatic detection and will always connect to the specified server only.

Secured connection to the domain server

For higher security (to prevent from tapping of traffic and exploiting user passwords), connection to the Active Directory can be encrypted. Enabling of encrypted connection requires corresponding settings on the particular domain server (or on all servers of the particular domain if automatic detection is used).

Mapping of other domains

To map user accounts from multiple Active Directory domains, add domains in advanced settings available on the Other Mapping tab.

Users of other domains must login by username including the domain (e.g. drdolittle@usoffice.company.com). User accounts with no domain specified (e.g. wsmith), will be searched in the primary domain or in the local database.

Adding another Active Directory domain

Figure 15.14. Adding another Active Directory domain


Use buttons Add or Edit to open a dialog for a new domain definition and enter parameters of the mapped domain. For details, see above (Primary domain mapping and Advanced options).

Collision of Active Directory with the local database and conversion of accounts

During Active Directory domain mapping, collision with the local user database may occur if a user account with an identical name exists both in the domain and in the local database. If multiple domains are mapped, a collision may occur only between the local database and the primary domain (accounts from other domains must include domain names which make the name unique).

If a collision occurs, a warning is displayed at the bottom of the User Accounts tab. Click on the link in the warning to convert selected user accounts (to replace local accounts by corresponding Active Directory accounts).

Conversion of user accounts

Figure 15.15. Conversion of user accounts


The following operations will be performed automatically within each conversion:

  • substitution of any appearance of the local account in the WinRoute configuration (in traffic rules, URL rules, FTP rules, etc.) by a corresponding account from the Active Directory domain,

  • removal of the account from the local user database.

Accounts not selected for the conversion are kept in the local database (the collision is still reported). Colliding accounts can be used — the accounts are considered as two independent accounts. However, under these circumstances, Active Directory accounts must be always specified including the domain (even though it belongs to the primary domain); username without the domain specified represents an account belonging to the local database. However, as long as possible, it is recommended to remove all collisions by the conversion.

Note: In case of user groups, collisions do not occur as local groups are always independent from the Active Directory (even if the name of the local group is identical with the name of the group in the particular domain).