Active Directory as Identity Source

Overview of Active Directory as Identity Source

Figure 1 illustrates a typical scenario where the Active Directory as identity source is deployed. Users inside and outside the Active Directory domain need to access the Internet through a device.

Benefits
How does Active Directory as Identity Source Work?

Benefits

Simplifies configuration steps and provides best-effort security to access the device.
Ideal for medium businesses and up to medium-scale deployments.
Supports high availability (HA).
Configuration of captive portal is optional for users who do not authenticate.

How does Active Directory as Identity Source Work?

Figure 1: Active Directory as Identity Source Deployment

Table 1: Components of Active Directory as Identity Source
Components	Description
Domain Controller	Domain controller helps to apply security policies for request access to user authentication resources. The domain controller might also act as the LDAP server.
Domain PC	Connected windows computers group that share user account information and a security policy.
Non-domain PC	Users can access Windows desktop enviroment from any location using a device with internet connectivity.
LDAP authentication server for non-domain user	LDAP protocol helps identify the groups to which users belong. The username and group information are queried from the LDAP service in the Active Directory controller.

The device reads and analyzes the Windows event log of the active directory controller and generates an authentication table.
The Active Directory as identity source is aware of any domain user via the authentication table.
The device configures a policy that enforces the required user-based or group-based access control.
For any non-domain user or domain user on a non-domain machine, the administrator specifies a captive portal to force the user to authenticate (if the device supports captive portal for the traffic type).
After users enter their names and passwords and authenticate, the device gets user/group information and enforces the policy.
In addition to captive portal, if the IP address or user information is not available from the event log, users can again log in to the Windows PC to generate an event log entry. Then, the system generates the user authentication entry.

Windows Management Instrumentation Client (WMIC)

What is Windows Management Instrumentation Client (WMIC)?
How WMIC reads the Event Log on the Domain Controller?
Specify IP Filters to Limit IP-to-User Mapping
Windows Event Log Verification and Statistics
Firewall Authentication as backup to WMIC

What is Windows Management Instrumentation Client (WMIC)?

When you configure the Active Directory as identity source, the device establishes a Windows Management Instrumentation (WMI)/Distributed Component Object Module (DCOM) connection with the domain controller. The device acts as a WMI client (WMIC). The device reads and monitors the security event log on the domain controller. The device analyzes the event messages to generate IP address-to-user mapping information.

How WMIC reads the Event Log on the Domain Controller?

WMIC reads the event log on the domain controller in following manner:

The device monitors the event log at a configurable interval, which defaults to 10 seconds.
The device reads the event log for a certain timespan, which you can configure. The default timespan is one hour.
Each time at WMIC starts up, the device checks the last timestamp and the current timespan. If the last timestamp is older than the current timespan, then the current timespan takes effect.
The device can read the event log to obtain both IPv4 and IPv6 addresses.
When WMIC starts up, the device has a maximum count of events that it can read from the event log. You cannot configure the maximum count of events.
- On the SRX300, Juniper Networks® SRX320 Firewall, Juniper Networks® SRX340 Firewall, Juniper Networks® SRX345 Firewall, and Juniper Networks® SRX380 Firewall, the maximum count is 100,000.
- On the Juniper Networks® SRX5400 Firewall, Juniper Networks® SRX5600 Firewall, and Juniper Networks® SRX5800 Firewall, the maximum count is 200,000.
When WMIC starts up, the WMIC uses the maximum count with the timespan setting. When the limit is reached, the WMIC stops reading the event log.
After a failover, the device reads the event log from the latest event log timestamp.

Specify IP Filters to Limit IP-to-User Mapping

You can specify the IP filters to limit the IP address-to-user mapping information that the device generates from the event log.

To understand when a filter is useful for such mapping, consider the following scenario. A customer deploys 10 devices in one domain, and each device controls a branch. All 10 devices read all 10 branch user login event logs in the domain controller. However, the device is configured to detect only whether the user is authenticated on the branch it controls. By configuring an IP filter on the device, the device reads only the IP event log under its control.

You can configure a filter to include or exclude IP addresses or prefixes. You can specify a maximum of 20 addresses for each filter.

Windows Event Log Verification and Statistics

You can verify that the authentication table is getting IP address and user information by issuing the show services user-identification active-directory-access active-directory-authentication-table all command. A list of IP address-to-user mappings is displayed for each domain. The table contains no group information until LDAP is running.

You can see statistics about reading the event log by issuing the show services user-identification active-directory-access ip-user-mapping statistics domain command.

Firewall Authentication as backup to WMIC

The primary method for the Active Directory as identity source to get IP address-to-user mapping information is for the device to act as a WMI client (WMIC). However, the event-log-reading and PC probe functions both use WMI, and using a global policy to disable the WMI-to-PC probe affects event log reading. These might result in the failure of the PC probe, and a backup method for getting IP address-to-user mappings is needed. That method is to use firewall authentication to identify users.

See Domain PC Probing.

If a domain is configured in that statement, fwauth recognizes that the domain is for a domain authentication entry, and will send the domain name to the fwauth process along with the authentication request. After it receives the authentication response, fwauth deletes that domain authentication entry. The fwauth process sends the source IP address, username, domain, and other information to the UserID process, which verifies that it is a valid domain user entry. The subsequent traffic will hit this user firewall entry.

What is Domain PC Probing?

Domain PC probing acts as a supplement of event log reading. When a user logs in to the domain, the event log contains that information. The PC probe is triggered only when there is no IP-to-address mapping from the event log.

Domain information constantly changes as users log in and out of domain PCs. The Active Directory as identity source probe functionality provides a mechanism for tracking and verifying information in the authentication tables by directly probing domain PCs for IP address-to-user mapping information. New and changed information identified by the probe serves to update Active Directory authentication table entries, which is critical to maintaining firewall integrity.

The IP address filter also impacts the PC probe. Once you configure the IP address filter, only the IP address specified in the filter is probed.

Domain PC Probing User Information

The Active Directory as identity source tracks the online status of users by probing domain PCs. If a user is not online or is not an expected user, the Active Directory authentication table is updated as appropriate. The following probe behaviors apply:

On-demand probing

On-demand probing occurs when a packet is dropped due to a missing entry in the Active Directory authentication table. In this case, an entry is added in pending state to the authentication table, and the domain PC identified by the source IP field of the dropped packet is probed for IP address and user information. The entry remains in pending state until a response is received from the probe.

Manual probing

Manual probing is used to verify and troubleshoot the online status of a user or a range of users, and is at the discretion of the system administrator.

Note:

Manual probing can cause entries to be removed from the Active Directory authentication table. For example, if there is no response from your PC due to a network issue, such as when the PC is too busy, the IP address entry of the PC is marked as invalid and your access is blocked.

Based on the domain PC probe response, updates are made to the Active Directory authentication table, and associated firewall policies take effect. If no response is received from the probe after 90 seconds, the authentication entry times out. The timed-out authentication entry is the pending state authentication entry, which is generated when you start the PC probe.

If the probe is successful, the state of the authentication entry is updated from pending to valid. If the probe is unsuccessful, the state of the authentication entry is marked as invalid. The invalid entry has the same lifetime as a valid entry and is overwritten by upcoming fwauth (firewall authentication process) authentication results or by the event log.

If the device cannot access a domain PC for some reason, such as a network configuration or Windows firewall issue, the probe fails.

For more probe responses and corresponding authentication table actions, see Table 2.

Table 2: Probe Responses and Associated Active Directory Authentication Table Actions
Probe Response from Domain PC	Active Directory Authentication Table Action
Valid IP address and username	Add IP-related entry.
Logged on user changed	Update IP-related entry.
Connection timeout	Update IP-related entry as invalid.
Access denied	Update IP-related entry as invalid.
Connection refused	Update IP-related entry as invalid.
Authentication failed (The configured username and password have no privilege to probe the domain PC.)	Update IP-related entry as invalid.

How to Configure Probe?

On-demand probing is enabled by default. To disable on-demand probing, you can use the set services user-identification active-directory-access no-on-demand-probe statement. Delete this statement to reenable probing. When on-demand probing is disabled, manual probing is available.

To initiate a manual probe, you can use the request services user-identification active-directory-access ip-user-probe address ip-address address domain domain-name command. If a domain name is not specified, the probe looks at the first configured domain for the IP address. To specify a range, use the appropriate network address.

The probe timeout value is configurable. If no response is received from the domain PC within the wmi-timeout interval, the probe fails and the system either creates an invalid authentication entry or updates the existing authentication entry as invalid. If an authentication table entry already exists for the probed IP address, and no response is received from the domain PC within the wmi-timeout interval, the probe fails and that entry is deleted from the table.

See Configure Active Directory as Identity Source on SRX Series Firewall.

Probe Rate and Statistics

The maximum probe rate for the Active Directory as identity source is set by default and cannot be changed. For SRX 5400, SRX 5600, and SRX 5800 Series Firewalls, the probe rate is 600 times per minute. For branch SRX Series Firewalls, the probe rate is 100 times per minute. Probe functionality supports 5000 users, or up to 10 percent of the total supported authentication entries, whichever is smaller. Supporting 10 percent means that at any time, the number of IP addresses waiting to be probed cannot exceed 10 percent.

LDAP for Active Directory as Identity Source

What is the use of LDAP for Active Directory as Identity Source?
How LDAP for Active Directory as Identity Source Work?

What is the use of LDAP for Active Directory as Identity Source?

The use of LDAP in this section applies specifically to LDAP functionality within the Active Directory as identity source.

In order to get the user and group information necessary to implement the Active Directory as identity source, the device uses the Lightweight Directory Access Protocol (LDAP). The device acts as an LDAP client communicating with an LDAP server. In a common implementation scenario of the Active Directory as identity source, the domain controller acts as the LDAP server. The LDAP module in the device, by default, queries the Active Directory in the domain controller.

The device downloads user and group lists from the LDAP server. The device also queries the LDAP server for user and group updates. The device downloads a first-level, user-to-group mapping relationship and then calculates a full user-to-group mapping.

How LDAP for Active Directory as Identity Source Work?

The LDAP server’s username, password, IP address, and port are all optional, but they can be configured.

If the username and password are not configured, the system uses the configured domain controller’s username and password.
If the LDAP server’s IP address is not configured, the system uses the address of one of the configured Active Directory domain controllers.
If the port is not configured, the system uses port 389 for plaintext or port 636 for encrypted text.

By default, the LDAP authentication method uses simple authentication. The client’s username and password are sent to the LDAP server in plaintext. Keep in mind that the password is clear and can be read from the network.

To avoid exposing the password, you can use simple authentication within an encrypted channel [namely Secure Sockets layer (SSL)], as long as the LDAP server supports LDAP over SSL (LDAPS). After enabling SSL, the data sent from the LDAP server to the device is encrypted. To enable SSL, see the user-group-mapping statement.

Active Directory as Identity Source Authentication Table

The Active Directory as identity source will manage up to 2048 sessions for each user for whom there is a user identity and authentication entry in the authentication table. There might be additional sessions associated with a user beyond the 2048 supported sessions, but they are not managed by Active Directory as identity source. When an authentication entry in an authentication table is deleted, Active Directory as identity source only closes sessions that are associated with that entry. It will not close sessions that it does not manage.

Table 3 lists Active Directory as identity source authentication table device support that depends on the Junos OS release in your installation.

Table 3: Active Directory as Identity Source Authentication Table Device Support
Devices	Identity Source Authentication Table Entries	Domains	Controllers
SRX300, SRX320	500	1	5
SRX340, SRX345, SRX380	1000	1	5
SRX1500, SRX1600, SRX2300	20,000	2	10
SRX4000 line	50,000	2	10
SRX5000 line	The user entries are as follows: 100000—For users without JIMS 256000—For users with JIMS	2	10
vSRX Virtual Firewall (2 vCPUs and 4 GB vRAM, 5 vCPUs and 8 GB vRAM )	5000	2	10
vSRX Virtual Firewall (9 vCPUs and 16 GB vRAM, 17 vCPUs and 32 GB vRAM )	10,000	2	10
NFX150	500	1	5

Active Directory as Identity Source Timeout Setting

Here timeout setting refers to firewall authentication forced timeout as it applies to active directory authentication entries for users who authenticate through captive portal.

When a user authenticates through captive portal, an authentication table entry is generated for that user based on the information that the firewall obtains from the firewall authentication module. At that point, the default traffic-based authentication timeout logic is applied to the entry.

As an administrator, it is important for you to have control over how long non-domain users who authenticate through captive portal remain authenticated. The timeout feature gives you that control. Use of it ensures that non-domain users do not remain authenticated indefinitely. For example, assume that the flow of traffic is continuous to and from the device of a non-domain user authenticated through captive portal. Given the behavior of the default traffic-based authentication timeout, the non-domain user would remain authenticated indefinitely.

When the timeout value is configured, it is used in conjunction with the traffic-based timeout logic. Here is how timeout settings affect active directory authentication entries for users authenticated through captive portal. In all of the following instances, an authentication entry was generated for a user based on firewall authentication information after the user authenticated through captive portal.

The timeout is set for 3 hours.

Traffic continues to be received and generated by a device associated with an authentication entry for a user. After 3 hours the authentication entry expires, although at that time there are sessions anchored in Packet Forwarding Engine for the authentication entry.
If set, the timeout has no effect.

An authentication entry does not have sessions anchored to it. It expires after the time set for the authentication entry timeout, for example, 30 minutes.
The timeout configuration is deleted.

Timeout has no effect on new authentication entries. Timeout remains enforced for existing authentication entries to which it applied before it was deleted. That is, for those authentication entries, the original timeout setting remains in effect.
The timeout configuration setting is changed.

The new time-out setting is applied to new incoming authentication entries. Existing entries keep the original, former setting.
The timeout is set to 0, disabling it.

If the timeout is set to a new value, that value is assigned to all incoming authentication entries. There is no timeout setting for existing authentication entries.
The timeout value is not configured.
- The firewall generates an authentication entry for a user. The default traffic-based timeout logic is applied to the authentication entry.
- The active directory timeout value is configured for 50 minutes. A traffic-based timeout of 50 minutes is applied to an authentication entry.
- The active directory timeout is not configured. The default traffic-based timeout of 30 minutes is applied to an authentication entry.