Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

Classify Traffic Based on User Roles

 

A user is allowed or denied access based on the security policies. User role firewall security policies let you classify traffic based on the roles to which a user is assigned. The user role information can be collected from Junos Pulse server or third-party authentication server.

Understanding Unified Access Control

In Junos OS Release 12.1 and later, user role firewall security policies let you classify traffic based on the roles to which a user is assigned. Based on match criteria, which includes the user’s role, you create policies to apply services that allow or block access to resources. The user role firewall is similar to the identity-based network access control (NAC) solution available with UAC on the SRX Series device. A user role firewall, however, does not require the Junos Pulse/Odyssey installation, and it supports agentless transparent authentication.

User role information can be collected in several ways: locally on the SRX Series device, from a Junos Pulse Access Control Service device, or by relaying authentication data from a third-party authentication server through a Junos Pulse Access Control Service device to the SRX Series device.

Acquiring User Role Information from an Active Directory Authentication Server

Networks have used the IP address as a way of identifying users and servers. The strategy is based on the assumption that users or groups of users connect to the network from fixed locations and use one device at a time.

Wireless networking and mobile devices require a different strategy. Individuals can connect to the network using multiple devices simultaneously. The way in which devices connect to the network changes rapidly. It is no longer possible to identify a user with a group of statically allocated IP addresses.

In Junos OS Release 12.1 and later, user role firewall security policies let you classify traffic based on the roles to which a user is assigned. Based on match criteria, which includes the user’s role, you create policies to apply services that allow or block access to resources. The user role firewall is similar to the identity-based network access control (NAC) solution available with UAC on the SRX Series device. A user role firewall, however, does not require the Junos Pulse/Odyssey installation, and it supports agentless transparent authentication.

User role information can be collected in several ways: locally on the SRX Series device, from a Junos Pulse Access Control Service device, or by relaying authentication data from a third-party authentication server through a Junos Pulse Access Control Service device to the SRX Series device.

Incorporating a third-party authentication server into a user role firewall configuration can also provide single sign-on (SSO) support. This allows a browser-based user to authenticate once and have that authentication communicated to other trusted servers in the domain as needed.

Requirements

This solution uses the following hardware and software components:

  • One MAG Series Junos Pulse Gateway device with software release 4.2 or later

  • The MAGx600-UAC-SRX license installed on the MAG Series device

  • One SRX Series device with Junos OS Release 12.1 or later

  • One Microsoft Active Directory server using version 2008

    Note

    Microsoft Windows 2003 is also compatible with this functionality, but terminology, pathways, and settings might differ from what is presented in this document.

Before you begin:

  • Ensure that the MAG Series device is configured as an Access Control Service and is accessible to the network. See the MAG Series Junos Pulse Gateway Hardware Guide for configuration details.

  • Ensure that the MAGx600-UAC-SRX license is installed on the MAG Series device.

  • Ensure that the SRX Series device is configured and initialized with Junos OS version 12.1 or later.

  • Ensure that the Active Directory authentication server is configured for standard Junos Pulse Access Control Service authentication. See your third-party documentation.

  • Ensure that the administrator has the appropriate capabilities for configuring the roles, users, and device interactions.

Overview

In this solution an SRX Series device obtains user role information dynamically from a Microsoft Active Directory authentication server. Authentication verification and user role information from the Active Directory server is relayed by the Access Control Service on the MAG Series device to the SRX Series device.

Users within the same domain are connected to a LAN segment. They are associated with user role groups, such as developer or manager, depending on their work in the organization. When a user authenticates to the AD authentication server, the user should be able to access protected resources without having to authenticate a second time.

The SRX Series device is configured as an enforcer for the MAG Series device. It receives user role information from the MAG Series device and applies user role firewall policies accordingly to incoming and outgoing traffic.

When the SRX Series device has no user role information for a user, the user’s browser is redirected to the MAG Series device. Transparently to the user, the MAG Series device requests verification from the browser. The browser retrieves a token from the Active Directory server confirming authentication and passes it to the MAG Series device. With the information provided by the token, the MAG Series device retrieves user role information for the user from the Active Directory server and creates an authentication table entry consisting of the current IP address and the user role data. The MAG Series device pushes the updated table to the SRX Series device and redirects the browser back to the SRX to request access again. This time, the table does contain user role information which is then retrieved and used as part of the match criteria for applying user role firewall services.

The user is not aware of the process unless the Active Directory (AD) server has no current authentication for the user. When that is the case, the server prompts the user for name and password. Once authentication occurs, the server returns a token to the browser.

The procedure documented here initially configures the MAG Series device as the authenticator. The configuration is later modified to retrieve authentication information from the AD server. This solution uses SPNEGO negotiation and Kerberos authentication to secure communications among the SRX Series device, the MAG Series device, the browser, and the authentication server.

Topology

Figure 1 shows the topology for this deployment in which the MAG Series device is used initially as the authenticationn source. Later, the AD server is used transparently unless the user is not authenticated, in which case he is prompted for a user name and password.

Figure 1: Single Sign-On Support Topology
Single Sign-On Support Topology

A user’s request to access another resource is controlled by roles and groups associated with the user. For example, a user belonging to a group of developers named Dev might have access to a particular test server. The same user might also be the manager and belong to the Mgr group that can access certain HR resources. A contractor working for this manager might require access to the test server as well but not to the HR resources. In this case, the user would be added to the Dev group and perhaps a Contractor group, but not the Mgr group.

User role firewall policies defined on the SRX Series device control the groups and user roles that can access various resources. In this configuration, if user role data does not exist for a user requesting access, a policy redirects the user’s browser to the MAG Series device to authenticate the user and retrieve any associated user role data.

A token exchange among the Access Control Service, the browser, and the Active Directory server remains transparent to the user while it verifies the user’s authentication. The exchange uses SPNEGO negotiation and Kerberos authentication for encrypting and decrypting messages among the devices.

With information obtained from the response token, the MAG Series device retrieves the user’s roles and groups directly from the Active Directory server. It then creates an authentication table entry and passes it to the SRX Series device.

Configuration

Configure the devices for this solution by performing the following tasks.

  • Connect the SRX Series device and the MAG Series device in an enforcer configuration.

  • Configure the Access Control Service on the MAG Series device for local user authentication and verify that authentication information is transferred between the devices.

  • Configure a captive portal policy on the SRX Series device to redirect any unauthenticated user to the Access Control Service and verify that redirection is functioning properly.

  • Configure the Microsoft Active Directory authentication server to interact with the Access Control Service and the endpoints.

  • Reconfigure the Access Control Service for remote authentication by the Active Directory server and redefine Active Directory groups for the SRX Series device.

  • Configure endpoint browsers for the SPNEGO protocol

Note

Configuring the Access Control Service using local authentication is not necessary for this solution. However, by configuring local authentication first you can verify the captive portal interaction between the MAG Series device and the SRX Series device.

The following example requires you to navigate various levels in the configuration hierarchy. For instructions on how to do that, see Using the CLI Editor in Configuration Mode.

Connecting the SRX Series Device to the Access Control Service

Step-by-Step Procedure

In an enforcer configuration, the Access Control Service on the MAG Series device and the SRX Series device communicate over a secure channel. When the SRX Series device first connects with the Access Control Service, the devices exchange information to ensure secure communication. Optionally, you can use digital security certificates as an enhanced mechanism for establishing trust.

See the Unified Access Control Administration Guide for details about configuring certificate trust between the SRX Series device and the Access Control Service.

To connect the SRX Series device and the Access Control Service on the MAG Series device:

  1. Configure the SRX Series device.
    1. Configure the zones and interfaces of the devices.
    2. Configure the IP addresses of the interfaces.
    3. Identify the Access Control Service as a new Infranet Controller, and configure the interface for the connection to it.
    4. Specify the password for securing interactions between the Access Control Service and the SRX Series device.
      Note

      The same password must be configured on both devices.

    5. (Optional) Specify the full name of the Access Control Service certificate that the SRX Series device must match during connection.
    6. If you are done configuring the SRX Series device, enter commit from configuration mode.
  2. Configure the Access Control Service from the administrator console on the MAG Series device.

    1. Navigate to the Infranet Enforcer page, and click New Enforcer.
    2. Select Junos, enter the password set previously on the SRX Series device (InSub321), and enter the serial number of the SRX Series device.
    3. Click Save Changes.

Results

When both devices are configured, the SRX Series device connects automatically to the Access Control Service.

  • From the Access Control Service, select System>Status>Overview to view the status of the connection to the SRX Series device. The diode in the display is green if the connection is functioning. To display additional information, click the device name.

  • From operational mode on the SRX Series device, confirm your connection by entering the show services unified-access-control status command. If the output does not display the intended configuration, repeat the instructions in this section to correct the configuration.

Configuring the Access Control Service for Local User Authentication

Step-by-Step Procedure

When a user is authenticated, the Access Control Service on the MAG Series device updates its authentication table with the IP address and associated roles of the user, and pushes the updated table to the SRX Series device. If this user data is deleted or modified, the Access Control Service updates the authentication table with the new information and again pushes it to the SRX Series device.

To test the successful transfer and content of the authentication table, this task configures the Access Control Service on the MAG Series device for local authentication. Within this configuration you can test the user role firewall from the SRX Series device without affecting other network operations. A later task modifies this configuration to provide user role retrieval from the remote Active Directory server.

Note

It is not a requirement to configure the Access Control Service for local user authentication. It is provided so that you can test each task in the configuration.

To configure the Access Control Service for local authentication:

  1. Define roles on the Access Control Service.

    1. From the administrator console of the Access Control Service, select Users>User Roles>New User Role.
    2. Enter dev as the role name.

      In this solution, use the default values for other role settings.

    3. Click Save Changes.
    Note

    This solution assumes that the MAGx600-UAC-SRX license is installed on the Access Control Service. If the full-feature license is installed, you will need to disable OAC Install and enable Agentless Access.

  2. Configure the default authentication server.

    1. Select Authentication>Auth. Servers.
    2. Select System Local. This establishes the MAG Series device as the default authentication server.
  3. Create users.

    1. Select the Users tab, and click New.
    2. Create user-a by entering the following details.
      • Username

      • User’s full name

      • Password

      • Password confirmation

    3. Repeat the previous step to create user-b.
    4. Click Save Changes.
  4. Create a realm.

    1. Select Users>User Realms>New User Realm.
    2. Enter REALM6 as the realm name.
    3. Select System Local in the Authentication box.
    4. Click Save Changes.
  5. From the same page, create role mapping rules.

    1. Select the Role Mapping tab, and click New Rule.
    2. Define two rules with the following details.
      • Enter username user-a, and assign it to role dev.

      • Enter username user-b, and assign it to role dev.

    3. Click Save Changes.
  6. Set up the default sign-in page.

    1. Select Authentication>Signing In>Sign-in Policies.
    2. Click the default Sign-in policy (*/).
    3. In the Sign-in URL box, enter the IP address of this device.
    4. In Authentication realm, Available realms, select REALM6.
    5. Click Save Changes.

Results

Verify the results of the configuration. If the output does not display the intended configuration, repeat the instructions in this section to correct the configuration.

  1. Verify that local authentication on the Access Control Service is functioning properly.
    • Open a browser window from an endpoint in the network.

    • Enter the fully qualified domain name for the Access Control Service.

      The default sign-in page should display.

    • Sign in as user-a, and provide the defined password.

  2. From operational mode on the SRX Series device:

    1. Confirm that the authentication table on the SRX Series device was updated with user-a.
    2. Confirm that the correct role has been associated with the role identifier.
    3. List all roles associated with user-a.

Configuring Redirection from the SRX Series Device to the Access Control Service

Step-by-Step Procedure

Local authentication, as configured in the previous task, requires users to log on to the Access Control Service directly to gain access to network resources. The SRX Series device can be configured to automatically redirect the browser of an unauthenticated user to the Access Control Service if a user requests access to a protected resource directly. You can define a user role firewall policy to redirect an unauthenticated user to a captive portal on the Access Control Service for sign-in.

Note

Other services, such as IDP, UTM, AppFW, and AppQoS, can be configured as well as the UAC captive portal implementation. The solution focuses on captive portal for authentication for user role implementation only.

To configure redirection from the SRX Series device to the Access Control Service:

  1. From configuration mode on the SRX Series device, configure the profile for the captive portal acs-device.
  2. Add either the redirection URL for the Access Control Service or a default URL.

    This command specifies the default target and enforcer variables so that the browser is returned to the SRX Series device after authentication.

  3. Allow traffic to the Acitve Directory (AD) server, the Access Control Service, and the other infrastructure servers.
  4. Configure a security policy that redirects HTTP traffic from zone user to zone untrust if the source-identity is unauthenticated-user.
  5. Configure the action to be taken when traffic matches the criteria for user-role-fw1.

    In this case, traffic meeting the specified criteria is allowed access to the UAC captive portal defined by the acs-device profile.

  6. Configure a security policy allowing access to any HTTP traffic from zone user to zone untrust.

    Note

    It is important to position the redirection policy for unauthenticated users before a policy for “any” user so that UAC authentication is not shadowed by a policy intended for authenticated users.

  7. If you are done configuring the policies, commit the changes.

Results

Confirm your configuration with the following procedures. If the output does not display the intended configuration, repeat the instructions in this section to correct the configuration.

  1. From configuration mode, confirm your captive portal profile configuration by entering the show services command.
  2. From configuration mode, confirm your policy configuration by entering the show security policies command.
  3. Verify that the redirection policy is functioning correctly.
    1. Open a browser window from a second endpoint in the network.
    2. Enter a third-party URL, such as www.google.com.

      The default sign-in page from the Access Control Service prompts for a user and password.

    3. Enter the username user-b and its password.

      The browser should display the requested URL.

      Note

      If a pop-up blocker is set on the endpoint, it could interfere with this functionality.

    4. From operational mode on the SRX Series device, verify that the authentication data and roles from the Access Control Service were pushed to the SRX Series device successfully.

Configuring Active Directory Settings

Step-by-Step Procedure

SPNEGO negotiation and Kerberos authentication are transparent to the user and network administrator, but certain configuration options enable the use of these protocols. This section identifies configuration requirements when using Active Directory as the authentication server. To interact in SPNEGO negotiation, the Access Control Service requires a keytab file created by Active Directory. Refer to your third-party documentation for more information about enabling SPNEGO and Kerberos usage.

This section is not intended to be a tutorial for Active Directory. However, there are specific configuration details required for this solution. See your third-party documentation to set up Active Directory as a domain controller.

To configure the Active Directory authentication server:

  1. Add a DNS entry as the UAC service account in the Forward Lookup Zones. In this way clients can refer to the MAG Series device by name or by IP address.

    This UAC service account name will be used in the next section when reconfiguring the UAC service on the MAG Series device.

  2. Single sign-on authentication requires that the UAC service account password never expires. To modify user settings:

    1. From the Active Directory Users and Computers application in DNS, select Users>New>User and select the UAC service account created in step 1.
    2. Select the Account tab.
    3. In user settings, click Password Never Expires.
  3. On the Domain Controller, open a command line, and enter the ktpass command to create the SPNEGO keytab file.

    The keytab file created on the Active Directory server contains the full service principal name (SPN) and other encryption information from the server. The keytab file is then uploaded to the Access Control Service on the MAG Series device. This shared information identifies one device to the other whenever encrypted messages and responses are sent.

    Use the following syntax.

    ktpassThird-party Kerberos utility that maps an SPN to a user, in this case, to the UAC service account. The executable is available for download. Refer to your third-party documentation for the source for this utility.
    -out output-file-nameThe name for the SPNEGO keytab file you are creating.
    -mapuser uac-service-acccount-nameThe name of the UAC service account created in step 1.
    -prin service://fqdn@REALMThe service principal name. The Kerberos authentication uses the SPN in its communication. It does not use an IP address.

    serviceThe HTTP service.
    fqdnThe hostname of the Junos Pulse Access Control Service. The service://FQDN portion of the name is provided by the Access Control Service when registering with the Active Directory server.
    REALMThe realm of the Active Directory authentication server. It is the same as the domain name. The Kerberos realm name is always in uppercase letters following the recommendation in RFC 1510. This affects interoperability with other Kerberos-based environments.

    The following command creates an SPNEGO keytab file named ic.ktpass.

    This file is copied to the Access Control Service on the MAG Series device in the next section when SPNEGO is configured for remote authentication.

Reconfiguring Remote Authentication on the Access Control Service

Step-by-Step Procedure

This section reconfigures the Access Control Service on the MAG Series device to query the remote Active Directory server instead of the local authentication table when authenticating a user. The following steps add services and authentication options to the Access Control Service on the MAG Series device. The configuration of the SRX Series device remains unchanged.

When you reconfigure the realm’s authentication server, the Access Control Service displays all roles or groups from the configured domain controller and its trusted domains. Establishing role mapping rules equates the authentication server’s roles or groups to those defined on the Access Control Service.

To reconfigure remote authentication on the Access Control Service:

  1. From the administrator console of the Access Control Service on the MAG Series device, select Authentication>Auth. Servers.
  2. Choose the Active Directory/Windows NT server type, and click Add New Server.
  3. Enter the profile of the new authentication server.

    1. Name the Active Directory server.
    2. Enter its NetBIOS domain name in the domain box.Note

      You might receive the following message: “Either the server is not a domain controller of the domain, or the NetBIOS name of the domain is different from the Active Directory (LDAP) name.” This message is informational and does not affect the processing of the authentication.

    3. Enter the Kerberos Realm name.

      The Kerberos realm name is the FQDN of the Active Directory domain. For example, if “mycompany” is the domain or NetBIOS name, mycompany.com is the Kerberos realm name.

    4. In the Domain Join Configuration section, enter the username and password of the UAC services account which has permission to join computers to the Active Directory domain.

      Select the Save credentials box.

    5. Enter the Container name.

      This is the name of the container in Active Directory where you created the UAC services account for the Access Control Service.

    6. Enter the Computer Name.

      Specify the machine ID that the Access Control Service uses to join the specified Active Directory domain as a computer. This name is derived from the licence hardware ID of the Access Control Service in the following format: 0161MT2L00K2C0.

    7. Verify that the join operation has succeeded.

      The Join Status indicator provides a color-coded status for the domain join operation as follows:

      • Gray: Not started

      • Yellow: In progress

      • Red: Failed to join

      • Green: Joined the domain

    8. Select Kerberos and NTLM v2 as the authentication protocols.
    9. In the Trusts section, select the Allow trusted domains box.
    10. Select Enable SPNEGO.
    11. Use the Browse button to upload the keytab file that you created in the previous section.
    12. Click Save Changes and Test Configuration.
  4. Ensure that SSO is enabled.

    1. Select Users>User Realms and the realm name.
    2. Select the Active Directory server name from the Auth Server list.
    3. Select the Authentication Policy tab.
    4. Verify that the SSO option is selected.
    5. Click Save Changes.
  5. Create role-mapping policies for groups acquired from the authentication server.

    Groups from the Active Directory authentication server need to be mapped to roles on the Access Control Service. You first need to create roles, and then map one or more groups to the appropriate role.

    1. Select the Role Mapping tab.
    2. Click New Rule, enter a role name, and click Save Changes.

      You do not need to add users to the role. Create as many roles as needed to map the groups from the Active Directory authentication server.

    3. Click Groups, and select Search to list the groups defined in the domain controller.
    4. Select the group names that you want to map to the new role.
    5. Repeat steps b through d to create and map other groups.
    6. Click Save Changes.

Configuring Endpoint Browsers for the SPNEGO

Step-by-Step Procedure

Ensure that endpoint browsers have SPNEGO enabled. For further information, see your third-party documentation.

  • Internet Explorer

    From Security>Local Intranet>Sites>Advanced add the trusted URL.

    IE performs SPNEGO without any further endpoint configuration but the user is prompted for a username and password. The username and password can be cached.

    To provide single sign-on support, an Internet Explorer configuration can be pushed by configuring a group policy on the Active Directory server. See your third-party documentation for further information.

    Integrated Windows Authentication must be enabled. Use the Tools>Internet Options>Advanced>Security>Enable Integrated Windows Authentication path to verify that IWA is enabled.

  • Firefox (Windows and MacOS)

    The configuration is in a hidden location. For the URL, type about:config and search for the word trusted. The required key is the comma separated parameter named network.negotiate-auth.trusted-uris.

    Note

    You need to specify the URL of the resource (in this solution, the FQDN or domain controller value UCDC.com).

  • Chrome

    Use the Internet Explorer setting. From Security>Local Intranet>Sites>Advanced add the trusted URL.

    An internet Explorer configuration can also be pushed by configuring a group policy on the Active Directory server. This configuration is honored by Chrome.

After successful authentication, the standard agentless page is shown along with a second window with the protected resource (unless a pop-up blocker prevents this).

Obtaining Username and Role Information Through Firewall Authentication

User role firewall policies can be integrated with firewall authentication both to authenticate users and to retrieve username and role information. The information is mapped to the IP address of the traffic, stored in the firewall authentication table, and used for user role firewall policy enforcement.

The following CLI statements configure firewall authentication for user role firewall enforcement.

  1. If not already established, define the access profile to be used for firewall authentication. You can skip this step if an existing access profile provides the client data needed for your implementation.

    The access profile is configured in the [edit access profile] hierarchy as with other firewall authentication types. It defines clients as firewall users and the passwords that provide them access. Use the following command to define a profile and add client names and passwords for firewall authentication.

  2. If HTTPS traffic is expected, define the access profile to be used for SSL termination services. You can skip this step if an existing SSL termination profile provides the services needed for your implementation.

    The SSL termination profile is configured in the [edit services ssl] hierarchy.

  3. Enable the firewall authentication table as an authentication source.

    The priority value determines the sequence in which authentication sources are checked. The default value is 150 for the firewall authentication table. (It is 100 for the local authentication table and 200 for the Unified Access Control (UAC) authentication table.) By default, the local authentication table is checked first, the firewall authentication table is next, and the UAC authentication table is third if it is enabled. You can change this sequence by changing the priority value of one or more of the tables.

  4. Configure policies that permit traffic for user firewall authentication.

    When unauthenticated traffic is permitted for firewall authentication, the user is authenticated based on the access profile configured in this statement. The ssl-termination-profile option is needed only for HTTPS traffic.

    By specifying the authentication type user-firewall, the firewall authentication table is propagated with the IP address, the username, and any group names associated with the authenticated user. (Group names from firewall authentication are interpreted as roles by the user role firewall.) Any further traffic from this IP address will match the IP address in the firewall authentication table, and not require authentication. The associated username and roles are retrieved from the table for use as potential match criteria in subsequent security policies.