ON THIS PAGE
Testing Junos OS Enforcer Policy Access Decisions Using Test-Only Mode
Configure Endpoint Security Using Infranet Agent with Junos OS Enforcer
Example: Creating a Captive Portal Policy on Junos OS Enforcer
Classify Traffic Based on User Roles from an Active Directory Server
Classify Traffic Based on User Roles through SRX Firewall Users
Configure Unified Access Control (UAC)
SUMMARY Learn how to configure an SRX Series Firewall to act as a Junos OS Enforcer in a UAC deployment.
Configure Junos OS Enforcer with IC Series UAC appliance
Before you begin:
Enable UAC through the relevant Junos OS security policies. See Enabling UAC in a Junos OS Environment (CLI Procedure).
-
(Optional) Create a profile for the certificate authority (CA) that signed the IC Series appliance’s server certificate, and import the CA certificate onto the SRX Series Firewall. See Example: Loading CA and Local Certificates Manually.
Configure user authentication and authorization by setting up user roles, authentication and authorization servers, and authentication realms on the IC Series appliance.
Configure resource access policies on the IC Series appliance to specify which endpoints are allowed or denied access to protected resources.
To configure an SRX Series Firewall to act as a Junos OS Enforcer in a UAC deployment, and therefore to enforce IC Series UAC Appliance policies, you must specify an IC Series appliance to which the SRX Series Firewall should connect.
To configure an SRX Series Firewall to act as a Junos OS Enforcer:
-
Specify the IC Series appliance(s) to which the SRX Series Firewall should connect.
-
To specify the IC Series appliance hostname:
user@host# set services unified-access-control infranet-controller hostname
-
To specify the IC Series appliance IP address:
user@host# set services unified-access-control infranet-controller hostname address ip-address
Note:When configuring access to multiple IC Series appliances, you must define each separately. For example:
user@host# set services unified-access-control infranet-controller IC1 user@host# set services unified-access-control infranet-controller IC2 user@host# set services unified-access-control infranet-controller IC3
user@host# set services unified-access-control infranet-controller IC1 address 10.10.10.1 user@host# set services unified-access-control infranet-controller IC2 address 10.10.10.2 user@host# set services unified-access-control infranet-controller IC3 address 10.10.10.3
Make sure that all of the IC Series appliances are members of the same cluster.
Note:By default, the IC Series appliance should select port 11123.
-
Specify the Junos OS interface to which the IC Series appliance should connect:
user@host# set services unified-access-control infranet-controller hostname interface interface-name
-
Specify the password that the SRX Series Firewall should use to initiate secure communications with the IC Series appliance:
Note:Any change in the Unified Access Control’s (UAC) contact interval and timeout values in the SRX Series Firewall will be effective only after the next reconnection of the SRX Series Firewall with the IC Series appliance.
user@host# set services unified-access-control infranet-controller hostname password password
-
(Optional) Specify information about the IC Series appliance’s server certificate that the SRX Series Firewall needs to verify the certificate.
-
To specify the server certificate subject that the SRX Series Firewall checks:
user@host# set services unified-access-control infranet-controller hostname server-certificate-subject certificate-name
-
To specify the CA profile associated with the certificate:
user@host# set services unified-access-control infranet-controller hostname ca-profile ca-profile
-
An IC Series appliance server certificate can be issued by an intermediate CA. There are two types of CAs—root CAs and intermediate CAs. An intermediate CA is secondary to a root CA and issues certificates to other CAs in the public key infrastructure (PKI) hierarchy. Therefore, if a certificate is issued by an intermediate CA, you need to specify the complete list of CA profiles in the certification chain.
Configure Junos OS Enforcer with IPsec
To configure an SRX Series Firewall to act as a Junos OS Enforcer using IPsec:
Set system and syslog information using the following configuration statements:
system { host-name test_host; domain-name test.mycompany.com; host-name test_host; root-authentication { encrypted-password "$ABC123"; } services { ftp; ssh; telnet; web-management { http { interface ge-0/0/0.0; } } } syslog { user * { any emergency; } file messages { any critical; authorization info; } file interactive-commands { interactive-commands error; } } max-configurations-on-flash 5; max-configuration-rollbacks 5; license { autoupdate { url https://ae1.mycompany.com/junos/key_retrieval; } } ntp { boot-server 1.2.3.4; server 1.2.3.4; } }
Note:On SRX Series Firewalls, the factory default for the maximum number of backup configurations allowed is five. Therefore, you can have one active configuration and a maximum of five rollback configurations. Increasing this backup configuration number will result in increased memory usage on disk and increased commit time.
To modify the factory defaults, use the following commands:
root@host# set system max-configurations-on-flash number root@host# set system max-configuration-rollbacks number
where max-configurations-on-flash indicates backup configurations to be stored in the configuration partition and max-configuration-rollbacks indicates the maximum number of backup configurations.
Configure the interfaces using the following configuration statements:
interfaces { ge-0/0/0 { unit 0 { family inet { address 10.64.75.135/16; } } } ge-0/0/1 { unit 0 { family inet { address 10.100.54.1/16; } } } ge-0/0/2 { unit 0 { family inet { 10.101.54.1/16; } } }
Configure routing options using the following configuration statements:
routing-options { static { route 0.0.0.0/0 next-hop 10.64.0.1; route 10.11.0.0/16 next-hop 10.64.0.1; route 172.0.0.0/8 next-hop 10.64.0.1; route 10.64.0.0/16 next-hop 10.64.0.1; } }
Configure security options using the following configuration statements:
security { ike { traceoptions { file ike; flag all; } proposal prop1 { authentication-method pre-shared-keys; dh-group group2; authentication-algorithm sha1; encryption-algorithm 3des-cbc; } policy pol1 { mode aggressive; proposals prop1; pre-shared-key ascii-text "$ABC123"; } gateway gateway1 { ike-policy pol1; dynamic { hostname gateway1.mycompany.com; connections-limit 1000; ike-user-type group-ike-id; } external-interface ge-0/0/0; xauth access-profile infranet; } gateway gateway2 { ike-policy pol1; dynamic { hostname gateway2.mycompany.com; connections-limit 1000; ike-user-type group-ike-id; } external-interface ge-0/0/0; xauth access-profile infranet; } }
Configure IPsec parameters using the following configuration statements:
ipsec { proposal prop1 { protocol esp; authentication-algorithm hmac-sha1-96; encryption-algorithm 3des-cbc; lifetime-seconds 86400; } policy pol1 { proposals prop1; } vpn vpn1 { ike { gateway gateway1; ipsec-policy pol1; } } vpn vpn2 { ike { gateway gateway2; ipsec-policy pol1; } } }
Configure screen options using the following configuration statements:
screen { ids-option untrust-screen { icmp { ping-death; } ip { source-route-option; tear-drop; } tcp { syn-flood { alarm-threshold 1024; attack-threshold 200; source-threshold 1024; destination-threshold 2048; queue-size 2000; timeout 20; } land; } } }
Configure zones using the following configuration statements:
zones { security-zone trust { tcp-rst; host-inbound-traffic { system-services { all; } protocols { all; } } interfaces { ge-0/0/0.0; } } security-zone untrust { host-inbound-traffic { system-services { all; } protocols { all; } } interfaces { ge-0/0/1.0; } } security-zone zone101 { host-inbound-traffic { system-services { all; } protocols { all; } } interfaces { ge-0/0/2.0; } } }
Configure policies for UAC using the following configuration statements:
policies { from-zone trust to-zone trust { policy default-permit { match { source-address any; destination-address any; application any; } then { permit; } } } from-zone trust to-zone untrust { policy default-permit { match { source-address any; destination-address any; application any; } then { permit; } } policy default-deny { match { source-address any; destination-address any; application any; } then { permit; } } policy pol1 { match { source-address any; destination-address any; application any; } then { permit { tunnel { ipsec-vpn vpn1; } application-services { uac-policy; } } log { session-init; session-close; } } } } from-zone untrust to-zone trust { policy pol1 { match { source-address any; destination-address any; application any; } then { permit; log { session-init; session-close; } } } } from-zone trust to-zone zone101 { policy pol1 { match { source-address any; destination-address any; application any; } then { permit { tunnel { ipsec-vpn vpn2; } application-services { uac-policy; } } log { session-init; session-close; } } } policy test { match { source-address any; destination-address any; application any; } then { permit; } } } default-policy { deny-all; } } }
Configure RADIUS server authentication access using the following configuration statements:
access { profile infranet { authentication-order radius; radius-server { 10.64.160.120 secret "$ABC123"; } } }
Configure services for UAC using the following configuration statements:
services { unified-access-control { infranet-controller IC27 { address 3.23.1.2; interface ge-0/0/0.0; password "$ABC123"; } infranet-controller prabaIC { address 10.64.160.120; interface ge-0/0/0.0; password "$ABC123"; } certificate-verification optional; traceoptions { flag all; } } }
Configure Junos OS Enforcer Failover Options
Before you begin:
Enable UAC through the relevant Junos OS security policies.
-
Configure the SRX Series Firewall as a Junos OS Enforcer. During the configuration, define a cluster of IC Series appliances to which the Junos OS Enforcer should connect. See Enabling UAC in a Junos OS Environment (CLI Procedure).
To configure IC Series UAC Appliance failover processing, you must configure the Junos OS Enforcer to connect to a cluster of IC Series appliances. The Junos OS Enforcer communicates with one of these IC Series appliances at a time and uses the others for failover processing.
To configure failover processing:
Specify how often (in seconds) the Junos OS Enforcer should expect a heartbeat signal from the IC Series appliance indicating an active connection:
user@host# set services unified-access-control interval seconds
Specify the interval (in seconds) at which the Junos OS Enforcer should consider the current connection timed out:
Note:Any change in the Unified Access Control’s (UAC) contact interval and timeout values in the SRX Series Firewall will be effective only after the next reconnection of the SRX Series Firewall with the IC Series appliance.
user@host# set services unified-access-control timeout seconds
Specify how the Junos OS Enforcer should handle all current and subsequent traffic sessions when its connection to an IC Series appliance cluster times out:
user@host# set services unified-access-control timeout-action (close | no-change | open)
Testing Junos OS Enforcer Policy Access Decisions Using Test-Only Mode
Before you begin:
Enable UAC through the relevant Junos OS security policies. See Enabling UAC in a Junos OS Environment (CLI Procedure)
-
Configure the SRX Series Firewalls as a Junos OS Enforcer. See Configuring Communications Between the Junos OS Enforcer and the IC Series UAC Appliance (CLI Procedure).
If you are connecting to a cluster of IC Series UAC Appliances, enable failover options. See Configuring Junos OS Enforcer Failover Options (CLI Procedure).
When configured in test-only mode, the SRX Series Firewall enables all UAC traffic to go through regardless of the UAC policy settings. The device logs the UAC policy’s access decisions without enforcing them so you can test the implementation without impeding traffic.
To activate or deactivate test-only mode, enter the following configuration statement:
user@host# set services unified-access-control test-only-mode (true | false)
Verify Junos OS Enforcer Policy Enforcement
- Displaying IC Series UAC Appliance Authentication Table Entries from the Junos OS Enforcer
- Displaying IC Series UAC Appliance Resource Access Policies from the Junos OS Enforcer
Displaying IC Series UAC Appliance Authentication Table Entries from the Junos OS Enforcer
Configure Endpoint Security Using Infranet Agent with Junos OS Enforcer
To integrate the Infranet agent into a Junos OS-UAC deployment, no special configuration is required on the Junos OS Enforcer. You simply need to create security policies enabling access to the appropriate endpoints as you would for any other Junos OS-UAC deployment.
Example: Creating a Captive Portal Policy on Junos OS Enforcer
This example shows how to create a captive portal policy on the Junos OS Enforcer. In this example, you deploy a Junos OS Enforcer in front of the data center resources you want to protect and configure the captive portal feature on the Junos OS Enforcer. The Junos OS Enforcer then automatically redirects HTTP traffic destined for the protected resource to the IC Series UAC Appliance for authentication.
Requirements
Before you begin:
Deploy the IC Series appliance in the network so that users can access the device. Use the internal port on the IC Series appliance to connect users, the Junos OS Enforcer, and authentication servers. See Configuring Communications Between the Junos OS Enforcer and the IC Series UAC Appliance (CLI Procedure).
Set up security zones and interfaces on the Junos OS Enforcer. Make sure that end users are in a different security zone than protected resources. For example, protected resources in the data center are configured in the trusted zone and users in an untrusted zone. See Example: Creating Security Zones.
Add individual users to either an external authentication server or the local authentication server. Set up roles and realms for individual users. You can provision access to protected resources based on your network security needs.
Overview
In this example, you want to protect the trusted zone from users on the LAN by making sure that only compliant and authenticated users are granted access. New users join your network every month. You want to configure the captive portal feature on your system so that unauthenticated users are redirected to the IC Series appliance automatically without requiring new users to remember to log in to the IC Series appliance.
The configuration instructions in this topic describe how to
create a security policy called my-policy
, specify a match
condition for this policy, specify the captive portal policy as a
part of the UAC policy, and set criteria for redirecting traffic to
the IC Series appliance. In this example, the policy my-policy
:
Specifies the match condition to include any traffic from a previously configured zone called
trust
to another previously configured zone calleduntrust
.Specifies the captive portal policy called
my-captive-portal-policy
as part of the UAC policy.Specifies the redirect-traffic criteria as
unauthenticated
.
Topology
Configuration
Procedure
CLI Quick Configuration
To quickly configure this example, copy the following commands to a text file, remove any line breaks, change any details necessary to match your network configuration, copy and paste the commands into the CLI at the [edit] hierarchy level, and then enter commit from configuration mode.
set security policies from-zone untrust to-zone trust policy my-policy match destination-address any source-address any application junos-http set security policies from-zone untrust to-zone trust policy my-policy then permit application-services uac-policy captive-portal my-captive-portal-policy set services unified-access-control captive-portal my-captive-portal-policy redirect-traffic unauthenticated
Step-by-Step Procedure
The following example requires you to navigate various levels in the configuration hierarchy. For information about navigating the CLI, see Using the CLI Editor in Configuration Mode.
To create a captive portal policy on the Junos OS Enforcer:
Specify the match condition for the policy.
[edit security policies from-zone untrust to-zone trust policy my-policy] user@host# set match destination-address any source-address any application junos-http
Specify the captive portal policy as part of the UAC policy to be applied on the traffic that matches the conditions specified in the security policy.
[edit security policies from-zone untrust to-zone trust policy my-policy] user@host# set then permit application-services uac-policy captive-portal my-captive-portal-policy
Redirect all unauthenticated traffic to the IC Series appliance.
[edit services unified-access-control] user@host# set captive-portal my-captive-portal-policy redirect-traffic unauthenticated
Results
Confirm your configuration by entering the show
services
and show security policies
command from
configuration mode. If the output does not display the intended configuration,
repeat the configuration instructions in this example to correct it.
For brevity, this show
command output includes only
the configuration that is relevant to this example. Any other configuration
on the system has been replaced with ellipses (...).
[edit] user@host# show services unified-access-control { captive-portal my-captive-portal-policy { redirect-traffic unauthenticated; } }
[edit] user@host# show security policies ... from-zone untrust to-zone trust { policy my-policy { match { source-address any; destination-address any; application junos-http; } then { permit { application-services { uac-policy { captive-portal my-captive-portal-policy; } } } } } }
If you are done configuring the device, enter commit
from configuration mode.
Classify Traffic Based on User Roles from an Active Directory Server
SUMMARY Learn how to acquire username and 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 Firewall. 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 Firewall, 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 Firewall.
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 Firewall 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 Firewall 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 Firewall 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 Firewall.
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 Firewall 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 Firewall 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 Firewall 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 Firewall, 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.
![Single Sign-On Support Topology](../example/../../images/g036953.gif)
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 Firewall 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 Firewall.
Configuration
Configure the devices for this solution by performing the following tasks.
Connect the SRX Series Firewall 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 Firewall 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 Firewall.
Configure endpoint browsers for the SPNEGO protocol
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 Firewall.
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 Firewall to the Access Control Service
- Configuring the Access Control Service for Local User Authentication
- Configuring Redirection from the SRX Series Firewall to the Access Control Service
- Configuring Active Directory Settings
- Reconfiguring Remote Authentication on the Access Control Service
- Configuring Endpoint Browsers for the SPNEGO
Connecting the SRX Series Firewall 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 Firewall communicate over a secure channel. When the SRX Series Firewall 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 Firewall and the Access Control Service.
To connect the SRX Series Firewall and the Access Control Service on the MAG Series device:
-
Configure the SRX Series Firewall.
Step-by-Step Procedure
-
Configure the zones and interfaces of the devices.
user@host# set security zones security-zone user interfaces ge-0/0/0 user@host# set security zones security-zone infrastructure interfaces ge-0/0/1 user@host# set security zones security-zone untrust interfaces ge-0/0/2
-
Configure the IP addresses of the interfaces.
user@host# set interfaces ge-0/0/0 unit 0 family inet address 10.12.12.1/8 user@host# set interfaces ge-0/0/1 unit 0 family inet address 10.0.0.22/24 user@host# set interfaces ge-0/0/2 unit 0 family inet address 203.0.113.19/24
-
Identify the Access Control Service as a new Infranet Controller, and configure the interface for the connection to it.
[edit] user@host# set services unified-access-control infranet-controller mag123 address 10.0.0.22 user@host# set services unified-access-control infranet-controller mag123 interface fxp0.0
-
Specify the password for securing interactions between the Access Control Service and the SRX Series Firewall.
[edit] user@host# set services unified-access-control infranet-controller mag123 password pwd
Note:The same password must be configured on both devices.
-
(Optional) Specify the full name of the Access Control Service certificate that the SRX Series Firewall must match during connection.
user@host# set services unified-access-control infranet-controller mag123 ca-profile ca-mag123-enforcer
-
If you are done configuring the SRX Series Firewall, enter commit from configuration mode.
-
Configure the Access Control Service from the administrator console on the MAG Series device.
Step-by-Step Procedure
Navigate to the Infranet Enforcer page, and click New Enforcer.
-
Select Junos, enter the password set previously on the SRX Series Firewall (InSub321), and enter the serial number of the SRX Series Firewall.
Click Save Changes.
Results
When both devices are configured, the SRX Series Firewall 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 Firewall. 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 Firewall, 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.user@host> show services unified-access-control status
Host Address Port Interface State mag123 10.0.0.22 11123 fxp0.0 connected
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 Firewall. 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 Firewall.
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 Firewall without affecting other network operations. A later task modifies this configuration to provide user role retrieval from the remote Active Directory server.
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:
Define roles on the Access Control Service.
Step-by-Step Procedure
From the administrator console of the Access Control Service, select Users>User Roles>New User Role.
Enter dev as the role name.
In this solution, use the default values for other role settings.
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.
Configure the default authentication server.
Step-by-Step Procedure
Select Authentication>Auth. Servers.
Select System Local. This establishes the MAG Series device as the default authentication server.
Create users.
Step-by-Step Procedure
Select the Users tab, and click New.
Create user-a by entering the following details.
Username
User’s full name
Password
Password confirmation
Repeat the previous step to create user-b.
Click Save Changes.
Create a realm.
Step-by-Step Procedure
Select Users>User Realms>New User Realm.
Enter REALM6 as the realm name.
Select System Local in the Authentication box.
Click Save Changes.
From the same page, create role mapping rules.
Step-by-Step Procedure
Select the Role Mapping tab, and click New Rule.
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.
Click Save Changes.
Set up the default sign-in page.
Step-by-Step Procedure
Select Authentication>Signing In>Sign-in Policies.
Click the default Sign-in policy (*/).
In the Sign-in URL box, enter the IP address of this device.
In Authentication realm, Available realms, select REALM6.
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.
Step-by-Step Procedure
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.
-
From operational mode on the SRX Series Firewall:
Step-by-Step Procedure
-
Confirm that the authentication table on the SRX Series Firewall was updated with user-a.
user@host> show services unified-access-control authentication-table
Id Source IP Username Age Role identifier 1 203.0.113.102 user-a 0 0000000001.000005.0 Total: 1
-
Confirm that the correct role has been associated with the role identifier.
user@host> show services unified-access-control roles
Name Identifier dev 0000000001.000005.0
-
List all roles associated with user-a.
user@host> show services unified-access-control authentication-table detail
Identifier: 1 Source IP: 203.0.113.102 Username: user-a Age: 0 Role identifier Role name 0000000001.000005.0 dev
-
Configuring Redirection from the SRX Series Firewall 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 Firewall 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.
Other services, such as IDP, Content Security, 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 Firewall to the Access Control Service:
-
From configuration mode on the SRX Series Firewall, configure the profile for the captive portal acs-device.
[edit] user@host# set services unified-access-control captive-portal acs-device redirect-traffic unauthenticated
-
Add either the redirection URL for the Access Control Service or a default URL.
[edit] user@host# set services unified-access-control captive-portal acs-device redirect-url “https://%ic-url%/?target=%dest-url%&enforcer=%enforcer-id%”
This command specifies the default target and enforcer variables so that the browser is returned to the SRX Series Firewall after authentication.
Allow traffic to the Acitve Directory (AD) server, the Access Control Service, and the other infrastructure servers.
[edit] user@host# set security policies from-zone user to-zone infrastructure policy Allow-AD-UAC match source-address any user@host# set security policies from-zone user to-zone infrastructure policy Allow-AD-UAC match destination-address any user@host# set security policies from-zone user to-zone infrastructure policy Allow-AD-UAC application any user@host# set security policies from-zone user to-zone infrastructure policy Allow-AD-UAC then permit
Configure a security policy that redirects HTTP traffic from zone user to zone untrust if the source-identity is unauthenticated-user.
[edit] user@host# set security policies from-zone user to-zone untrust policy user-role-fw1 match source-address any user@host# set security policies from-zone user to-zone untrust policy user-role-fw1 match destination-address any user@host# set security policies from-zone user to-zone untrust policy user-role-fw1 match application http user@host# set security policies from-zone user to-zone untrust policy user-role-fw1 match source-identity unauthenticated-user
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.
user@host# set security policies from-zone user to-zone untrust policy user-role-fw1 then permit application-services uac-policy captive-portal acs-device
Configure a security policy allowing access to any HTTP traffic from zone user to zone untrust.
[edit] user@host# set security policies from-zone user to-zone untrust policy user-role-fw2 match source-address any user@host# set security policies from-zone user to-zone untrust policy user-role-fw2 match destination-address any user@host# set security policies from-zone user to-zone untrust policy user-role-fw2 match application http user@host# set security policies from-zone user to-zone untrust policy user-role-fw2 match source-identity any user@host# set security policies from-zone user to-zone untrust policy user-role-fw2 then permit
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.
If you are done configuring the policies, commit the changes.
[edit] user@host# commit
Results
Step-by-Step Procedure
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.
From configuration mode, confirm your captive portal profile configuration by entering the
show services
command.[edit] user@host# show services
... unified-access-control { captive-portal acs-device { redirect-traffic unauthenticated; redirect-url “https://%ic-url%/?target=%dest-url%&enforcer=%enforcer-id%” ...
From configuration mode, confirm your policy configuration by entering the
show security policies
command.user@host# show security policies
... from-zone user to-zone infrastructure { policy Allow-AD-UAC { match { source-address any; destination-address any; application any; } then { permit } } } from-zone user to-zone untrust { policy user-role-fw1 { match { source-address any; destination-address any; application http; source-identity unauthenticated-user } then { permit { application-services { uac-policy { captive-portal acs-device; } } } } } } from-zone user to-zone untrust { policy user-role-fw2 { match { source-address any; destination-address any; application http; source-identity any } then { permit } } } ...
Verify that the redirection policy is functioning correctly.
Step-by-Step Procedure
Open a browser window from a second endpoint in the network.
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.
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.
-
From operational mode on the SRX Series Firewall, verify that the authentication data and roles from the Access Control Service were pushed to the SRX Series Firewall successfully.
user@host> show services unified-access-control authentication-table
Id Source IP Username Age Role identifier 1 203.0.113.112 user-a 0 0000000001.000005.0 2 203.0.113.15 user-b 0 0000000001.000005.0 Total: 2
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:
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.
Single sign-on authentication requires that the UAC service account password never expires. To modify user settings:
Step-by-Step Procedure
From the Active Directory Users and Computers application in DNS, select Users>New>User and select the UAC service account created in step 1.
Select the Account tab.
In user settings, click Password Never Expires.
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.
ktpass -out output-file-name -mapuser uac-service-acccount-name -prin service://fqdn@REALM
ktpass Third-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-name The name for the SPNEGO keytab file you are creating.
-mapuser uac-service-acccount-name The name of the UAC service account created in step 1.
-prin service://fqdn@REALM The service principal name. The Kerberos authentication uses the SPN in its communication. It does not use an IP address.
service The HTTP service.
fqdn The 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.
REALM The 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.
ktpass -out ic.ktpass -mapuser icuser@UCDC.COM -princ HTTP/mag123.ucdc.com@UCDC.COM -pass Doj73096
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 Firewall 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:
From the administrator console of the Access Control Service on the MAG Series device, select Authentication>Auth. Servers.
Choose the Active Directory/Windows NT server type, and click Add New Server.
Enter the profile of the new authentication server.
Step-by-Step Procedure
Name the Active Directory server.
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.
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.
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.
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.
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.
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
Select Kerberos and NTLM v2 as the authentication protocols.
In the Trusts section, select the Allow trusted domains box.
Select Enable SPNEGO.
Use the Browse button to upload the keytab file that you created in the previous section.
Click Save Changes and Test Configuration.
Ensure that SSO is enabled.
Step-by-Step Procedure
Select Users>User Realms and the realm name.
Select the Active Directory server name from the Auth Server list.
Select the Authentication Policy tab.
Verify that the SSO option is selected.
Click Save Changes.
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.
Step-by-Step Procedure
Select the Role Mapping tab.
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.
Click Groups, and select Search to list the groups defined in the domain controller.
Select the group names that you want to map to the new role.
Repeat steps b through d to create and map other groups.
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.
Classify Traffic Based on User Roles through SRX Firewall Users
SUMMARY Learn how to obtain username and role information through SRX firewall users.
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.