en-US
search-icon

Secure Mobile Access 12.0 Admin Guide

Authentication

 

Network and Authentication Configuration

About Configuring the Network

This section provides information about essential network configuration tasks, including configuring network interfaces, selecting a routing mode, configuring network gateways, defining static routes, and name resolution. It also explains how to manage SSL and CA certificates, and configure user authentication.

This is the minimal network configuration required to get the appliance up and running. For information on configuring additional services—including NTP, SSH, ICMP, and syslog—see System Administration.

Configuring Basic Network Settings

All basic network settings—including IP interfaces, routing, and name resolution—are configurable in AMC. The starting point in AMC for configuring network options is the Network Settings page.

Topics:  

Specifying System Identity

You must name the appliance and specify the domain name in which it is located.

To specify system identity:
1
From the main navigation menu in AMC, click Network Settings.
2
In the Basic area, click Edit. The Configure Basic Network Settings page appears.

3
The Appliance name helps you differentiate appliances in several contexts (especially if more than one appliance is running):
It sets the command prompt for the SMA appliance.
It is saved to a log file, so you can identify the appliance to which a particular log message applies.
When you export a configuration file for the appliance (on the Maintenance page in AMC), the Appliance name is prepended to the file name.

The name is not visible to users.

4
In the Default Domain field, type the name of the domain in which the appliance is located (for example, yourcompany.com). This name defines the DNS namespace used to identify hosts accessed by the appliance.

Configuring Network Interfaces

To configure the network interfaces, specify the IP address, subnet mask, and interface speed. You can run the appliance using both the internal and the external interfaces (a dual-homed configuration), or optionally just the internal interface (a single-homed configuration). For more information on the interface configuration options, see Network Architecture.

To configure network interfaces:
1
From the main navigation menu in AMC, click Network Settings.
2
In the Basic area, click Edit. The Configure Basic Network Settings page appears.
3
In the Network interfaces area, configure the settings for the internal interface connected to your internal (or private) network.

a
Click Internal. The display becomes editable.

b
Type an Address and Netmask for the interface.
c
Select the appropriate interface Speed from the list (the default is Auto).
d
Click OK.
4
Configure the settings for the interface connected to the external network (or Internet):
a
Click External. The display becomes editable.

b
Type the Address and Netmask settings used to access the SMA appliance from the Internet. The external IPv4 or IPv6 address must be publicly accessible.
c
Select the appropriate interface Speed from the list (the default is Auto).
d
Select the Enabled checkbox.
e
Click OK.
5
Click Save.
6
Click Pending changes.
7
Apply the changes. (For more information, see Applying Configuration Changes.)

If you configure the appliance to use both the internal and external interfaces, verify your routing settings to make sure that you have a network route to the internal interface. If the appliance is on a different network than the computer you’re using to access AMC, you must set up routing (configure an internal default network gateway that will pass traffic to an internal router, or define a static route to the network on which the appliance is installed) to maintain access to AMC after you apply your network configuration changes. For more information, see Configuring Routing.

Configuring ICMP

Enabling ICMP (Internet Control Messaging Protocol) lets you use the ping command to test network connectivity on a IPv4 or IPv6 interface.

To enable pings, select the Enable ICMP pings checkbox. To disable pings, clear the checkbox.

Viewing Fully Qualified Domain Names and Custom Ports

The Fully qualified domain names section of the page provides a table of the IPv4 or IPv6 addresses, FQDNs, and the WorkPlace sites and URL resources they are used by. You can sort the list forward or backward by any column heading by clicking the column heading link.

Under Used by, click a WorkPlace site name or URL resource name that appears as a link to go to that page in AMC where you can edit the settings for it.

The Custom ports section provides a table showing the custom port number and the URL resource that uses that port for all URL resources configured to use custom ports. Under Used by resource, click a URL resource name that appears as a link to go to the Resources > Edit Resource page to edit the resource settings.

Configuring Fallback Servers for Connect Tunnel

You can set up one or more fallback servers for Connect Tunnel users in case their primary appliance becomes unavailable due to a planned outage, for example, or a natural disaster. Users do not need to know the names of the fallback servers you set up: any time a client successfully connects to an appliance that has any fallback servers specified, the list of fallback servers is transmitted to the client and stored there.

To specify a fallback server for Connect Tunnel users:
1
From the main navigation menu, click Network Settings.
2
In the Tunnel service area, click Edit. The Configure Network Tunnel Service page appears.

3
In the Fallback servers area, click New.

4
Specify the fallback Server by host name or IP address.

5
For the Realm field you have two choices:
Leave it blank: Whatever realm the user was logged in to before the primary server became unavailable is the same realm name that will be used on this particular fallback server.
Specify a realm: Force users to log in to a particular realm when they connect to this server.
6
Click OK.
Topics:  

Fallback Servers and the User Experience

If an attempted connection to the primary server fails, the Connect Tunnel client automatically attempts a connection to any fallback servers that are specified. This feature is available to Connect Tunnel clients running on a Windows, Macintosh, or Linux operating system. Users will not be aware that a fallback server is being contacted, except for an initial pause of about 20 seconds as the connection is attempted, and a status message indicating that a backup host is being contacted.

A fallback server is used only when the user manually initiates a new connection to the primary appliance (which is down). If the primary server becomes unavailable during an active session, the session will exit and the user must start a new session.

Session Limits

If the login credentials for users include a PIN or other parameter that is valid for only a limited period of time, you should be aware of what your session limits are. For example, if Credential lifetime is set to only 30 seconds and the client works through several fallback servers while attempting to make a connection, the user’s PIN or other parameter may time out before the list of possible servers is exhausted.

There are a few settings that govern how long a session can be resumed without requiring reauthentication:

Credential lifetime is a global setting that is specified on the Configure General Appliance Options page (click General Settings in the main navigation menu, and then click Edit in the Appliance options area).
Limit session length to credential lifetime is a setting that is configured on a per-community basis. When selected, tunnel client sessions in a given community terminate and require reauthentication after the length of time specified by Credential lifetime.
* 
NOTE:  
If the client connects to a fallback server and the requested realm (as configured in AMC) is unavailable, the connection fails with an authentication error.
Users connecting to a high-availability pair of appliances operate with the same fallback information, regardless of which member of the pair they initially connect to.
Once a server has been contacted, fallback will not continue even if the login attempt fails.
If a user manually changes from one appliance that has a fallback list of servers to another, the second server will display the last known realm the user selected for that host.

Configuring Routing

The SMA appliance can be configured to route traffic using network gateways or static routes. These routing methods can be used separately or in combination with each other.

Topics:  

About Routing

If you configure the appliance to use both the internal and external interfaces, verify the routing settings to make sure that you have a network route to the internal interface. If the appliance is on a different network than the computer you’re using to access AMC, you must set up routing (configure an internal default network gateway that will pass traffic to an internal router, or define a static route to the network on which the appliance is installed) to maintain access to AMC after you apply your network configuration changes. For more information, see Configuring Routing.
The routing information in AMC is sorted as follows:
The primary key is the Netmask, with entries sorted in descending order (from largest to smallest)
The secondary key is IP address, with entries sorted in ascending order (from smallest to largest)
If your internal network has a contiguous address space, you can combine multiple static routes into one entry by specifying the proper subnet mask when you create the static route. Multiple static routes combining provides two examples of using a subnet mask to route internal traffic to multiple networks from a single static route entry:
 

Multiple static routes combining

To route traffic to these networks:

Type this IP address

Type this subnet mask

192.168.0.0
192.168.1.0
192.168.2.0
192.168.3.0
192.168.0.0
255.255.252.0
192.168.*.*

(all networks in 192.168 range)

192.168.0.0
255.255.0.0

If necessary, you can explicitly create additional static routes for other subnets; the routing table searches net masks from most to least specific.

Configuring Network Gateways

A network gateway is the address of a router that serves as point of access to another network. Network gateway options are based on your network architecture and depend on whether you have configured the appliance as dual-homed (both internal and external interfaces are enabled) or single-homed (only the internal interface is enabled). See Network Architecture for more information.

Topics:  

Choosing a Network Gateway Option

When configuring network gateways in a dual-homed environment, you can choose among four routing mode options:

Dual gateway
Single gateway, restricted
Single gateway, unrestricted
No gateway

Use these scenarios to help you decide which option is best for your needs:

Scenario 1: Using an Internal and Internet Router

If you have an internal router as well as an Internet router, use the Dual gateway option. You can leverage your internal router to access your internal resources.

Sample Scenario

Company A has resources and a number of subnets on their internal network, and they already have a robust routing system in place. With the dual gateway routing mode on the appliance, client requests destined for internal resources on the corporate network can be delivered to an internal router. See Internal and internet router usage.

Internal and internet router usage

Scenario 2: Managing Client Requests with Static Routes

If you’re not using an internal router, or prefer managing routing on the appliance, use the Single gateway, restricted option. In this scenario you must define static routes for all of your client requests. Client requests without a static route will be discarded by the appliance. This option requires more effort, but allows greater control over in-bound traffic.

Sample Scenario

Company B does not use a lot of internal resources, and prefers to manage its routing information on the appliance. They create a static route for each resource to which their VPN users should have access. If a VPN user attempts to reach an address that is not defined within the appliance’s routing table, then the traffic is discarded. See Managing client requests with static routes.

Managing client requests with static routes

Scenario 3: Returning Client Requests to a Specified Gateway

With the Single gateway, unrestricted option, the appliance delivers all client requests that do not match a static route to the gateway that you specify (on either the internal or external interface of the appliance). This option is less secure because it could allow traffic to pass to your Internet router and out of your network, depending on the filtering and routing policies of your infrastructure. This configuration is also more difficult to maintain.

Sample scenario

Like company B, company C prefers to manage its routing information on the appliance and has created static routes for each resource to which VPN users need access. However, some users in this organization also need access to Internet resources, and this traffic must be redirected from the appliance. For example, a company’s users might need to access a public Web server that requires pre-registered IP addresses. See Returning client requests to a specified gateway.

A user must first establish a VPN session with the appliance; the request is then redirected to the external gateway of the appliance.

Returning client requests to a specified gateway

Scenario 4: Evaluating the Appliance in a Lab Setting

Use the No gateway option during evaluation if you will have the interfaces connected to your testing networks without the need for routing.

Scenario 5: Deploying Network Tunnel Clients in “Redirect All” Mode

If you are planning to deploy network tunnel clients in “redirect all” mode, you may need to give your network tunnel users access to both your internal network and the Internet (for more information, see Redirection Modes). This can be accomplished by either of these options:

Use the Dual gateway option, and make certain that your internal gateway router has been configured with a route to the Internet. See Deploying network tunnel clients in “Redirect All” mode.
Use the Single gateway, unrestricted option, and then configure the appliance to use a route to the Internet; see Enabling a Route to the Internet.

Deploying network tunnel clients in “Redirect All” mode

Configuring Network Gateways in a Dual-Homed Environment

The following steps guide you through the setup of network gateways in a dual-homed environment, where both the internal and external interfaces are enabled.

To configure network gateways in a dual-homed environment:
1
From the main navigation menu, click Network Settings.
2
In the Routing area, click Edit. The Configure Routing page appears.

3
To route traffic to your network gateways, select a routing mode from the following options:
Dual gateway—Specify an IP address for both the external and the internal gateways. Network traffic generated in response to client requests will be sent to the external gateway. All other traffic that does not have a static route defined will be sent to the internal gateway.
Single gateway, restricted—Specify an IP address for just the external gateway. All other traffic that does not have a static route defined will be discarded.
Single gateway, unrestricted—Specify an IP address to be used as both the external and internal gateway. Network traffic not matching a static route will be sent to the external gateway.
No gateway—Network traffic received by the appliance but not matching a static route is discarded.
4
Click Save.

Configuring Network Gateways in a Single-Homed Environment

The following steps guide you through the setup of network gateways in a single-homed environment, where only the internal interface is enabled. This configuration is less common than one that is dual-homed.

To configure a network gateway in a single-homed environment:
1
From the main navigation menu in AMC, click Network Settings.
2
In the Routing area, click Edit. The Configure Routing page appears.

3
To route traffic to your network gateway, select one of these routing modes:
Default gateway—Specify an IP address for the default gateway. Network traffic received by the appliance, but not matching a static route will be sent to this address.
No gateway—Network traffic received by the appliance, but not matching a static route is discarded.
4
Click Save.

Enabling a Route to the Internet

If Routing mode is set to Single gateway, unrestricted you can still enable a route to the Internet for your network tunnel clients, provided your appliance is dual-homed (both internal and external interfaces are enabled). When Enable route to Internet is set, all tunnel traffic originating from the client and destined for the Internet (running in “redirect all” mode) will be routed to the specified IP address instead of being discarded.

To enable a route to the Internet:
1
From the main navigation menu in AMC, click Network Settings.
2
In the Routing area, click Edit. The Configure Routing page appears.
3
Expand the Advanced area. The Connect Tunnel area appears.

4
Select the Enable route to Internet checkbox, and then type the IP address of your Internet router.
5
Click Save.

Configuring Static Routes

Static routes are added as entries to the routing table for networks reached from the internal interface. Managing static route tables can be cumbersome, especially at a large site: you may want to create and edit the routing information in a comma-separated value (CSV) text file outside of AMC and then import it. Static route information that you import into AMC must be in an ASCII text file, with each entry on a new line (separated from the previous entry by a CR/LF), and three values separated by commas: IP address, netmask, and gateway. When you import a file, its contents entirely replace any static routes currently specified in AMC.

To configure static routing information:
1
From the main navigation menu in AMC, click Network Settings.
2
In the Routing area, click Edit. The Configure Routing page appears.
3
In the Static routes area, you can add or modify list entries one by one or as a group:

Add a single entry by clicking New, and then typing the route information in the IP address, Netmask, and Gateway fields. To modify a list entry, click its link, and then make your changes. After you add or modify an entry, click OK.
Click Import to select the static route table you want to import. The static route information must be in an ASCII text file in CSV format. Each entry must be on a new line (separated from the previous entry by a CR/LF), and must have three values separated by commas: IP address, netmask, and gateway. When you import a file, its contents entirely replace any static routes currently specified in AMC.
To modify an existing list of routes, you must either click the list item that you want to change, or export the entire list, modify its contents, and then import it.
4
Click Save when you are finished making changes.
To delete a static route:
1
On the Configure Routing page, select the checkbox to the left of any static routes you want to remove, and then click Delete.
2
Click Save.

Configuring Name Resolution

The appliance needs access to DNS servers to resolve host names to IP addresses. If you use WorkPlace to browse Windows networks, you also need to specify a WINS (Windows Internet Name Service) server and Windows domain name.

Topics:  

Configuring Domain Name Service

Configuring a DNS server enables the appliance to correctly resolve host names. Properly configuring DNS ensures that the appliance can provide access to your network resources.

To configure DNS name resolution:
1
From the main navigation menu in AMC, click Network Settings.
2
In the Name resolution area, click Edit. The Configure Name Resolution page appears.

3
In the Private search domains field, type one or more DNS domain names for your company with a semicolon (;) separator (such as example.com; sales.example.com). This domain name will be appended to unqualified host names to resolve them. You can enter a maximum of six domain names, separated by semicolons.
4
In the DNS servers fields, type the IP addresses of your primary and (if applicable) backup DNS servers. The backup servers are used if the primary server is unavailable.
5
Click Save.

Configuring Windows Network Name Resolution

If you want to browse files on a Windows network using WorkPlace, you must specify a WINS (Windows Internet Name Service) server and a Windows domain name. WorkPlace uses this information to perform name resolution and build a list of resources for users to browse.

To configure Windows network name resolution:
1
From the main navigation menu in AMC, click Network Settings.
2
In the Name resolution area, click Edit. The Configure Name Resolution page appears.
3
In the Windows networking area, type:

The IP address of your primary and (if applicable) secondary WINS server.
Your Windows domain name using NetBIOS syntax (for example, mycompany).
4
Click Save.

Certificates

The SMA appliance uses SSL certificates to secure information that the client computer sends to the server, and to validate the appliance’s identity to connecting users; see Certificate usage. It requires at least two SSL certificates:

The Secure Mobile Access services use a certificate to secure user traffic from a Web browser to WorkPlace, and from the Connect clients to the appliance. (If you want to provide several WorkPlace sites, you can use a wildcard certificate for multiple sites, or associate a different certificate with each one. In either case, the sites can have different host and domain names; for more information, see Adding WorkPlace Sites.)
AMC uses a separate certificate to secure management traffic. This is usually a self-signed certificate.

Certificate usage

Subject Alternative Name (SAN) certificate support for Workplace, Workplace sites, and Connect Tunnel has been added beginning in version 10.7. These certificates are used to securely encrypt communication channels between a set of clients and multiple distinct SSL or TLS services.

SAN certificates simplify the IP address/hostname/certificate sets needed for a typical deployment. With a single SAN certificate, you can utilize one IP address with multiple distinct SSL or TLS protected web or client/server services, without the need for configuring additional IP addresses. Additionally, SANs can be used for different host names on the same IP address, alleviating the need for a one-to-one mapping of SSL certificate Common Names to FQDN.

* 
NOTE: Only IPv4 addresses are supported in SAN certificates and Certificate Signing Requests (CSR).

Improvements include:

SANs-related features can be generated via the AMC instead of through mechanisms external to the appliance:
CSR with SANs
Self-signed certificates with SAN entries
WorkPlace sites, custom FQDN URL resources, and ActiveSync resources can be created using existing SAN certificates.
The appliance seamlessly handles Web connections to Workplace sites that use a combination of IP address, FQDN, or SSL certificate, regardless of whether that Workplace site has its own dedicated IP address or is sharing one with the Default Workplace site.
When using Connect Tunnel or Mobile Connect connections to Workplace sites, ensure Workplace sites are not defined with a dedicated IP address, but share the Default Workplace site IP address.  For example, if a Default Workplace site of vpn.mycompany.com is bound to 192.168.200.160 with a SSL certificate, *.mycompany.com, and you want to add a new Workplace site for contractors.mycompany.com, simply add the Fully Qualified Domain Name (FQDN) to the New Workplace Site configuration page, and do not specify another IP address. This allows Web or Tunnel connections to connect to either vpn.mycompany.com or contractors.mycompany.com with no further configuration needed on the appliance.

The Administrator can generate, import, process, and otherwise use a SAN certificate for Workplace, ActiveSync, Custom FQDN URL Mapping, or Tunnel-based access services.

CA certificates are also used for securing connections to back-end servers and authentication using client certificates. See Importing CA Certificates for more details.

Topics:  

Server Certificates

To manage the SSL server certificates used to access WorkPlace and AMC, click SSL Settings in the main navigation menu in AMC.

This is where you view, import, and delete SSL and CA certificates.

Certificate Strategy

There are two types of certificates:

A commercial CA verifies your company’s identity, vouching for your identity by providing you with a certificate that the CA signs. A CA need not be commercial or third-party—a company can be its own CA. Commercial certificates are purchased from a CA such as Symantec (http://www.symantec.com/ssl-certificates), and are usually valid for one year.
With a self-signed SSL certificate, you are verifying your own identity. The associated private key data is encrypted using a password. A self-signed certificate can also be a wildcard certificate, allowing it to be used by multiple servers which share the same IP address and certificate, but have different FQDNs.

Although this kind of certificate is secure, a self-signed certificate is not in the browser’s built-in list of CAs, so the user is prompted to accept it before each connection. There are a few ways to avoid this prompting:

Configure the Secure Mobile Access clients to use the certificate root file.
Add the self-signed certificate to the user’s list of Trusted Root Certificate Authorities in the Web browser.
Use a commercial CA, which is widely trusted by default.

When deciding which type of certificate to use for the servers, consider who will be connecting to the appliance and how they will use resources on your network:

If business partners are connecting to Web resources through the appliance, they will likely want some assurance of your identity before performing a transaction or providing confidential information. In this case, you would probably want to obtain a certificate from a commercial CA for the appliance.

On the other hand, employees connecting to Web resources may trust a self-signed certificate. Even then, you may want to obtain a third-party certificate so that users are not prompted to accept a self-signed certificate each time they connect.

To accommodate users who connect to the appliance from small form factor devices, configure the appliance with a certificate from a leading CA (such as VeriSign), or import the root certificate from your CA to your users’ small form factor devices.
* 
CAUTION: When the appliance is configured with a certificate from a CA that is not well known or one that is self-signed, small form factor device users may see an error message and be unable to log in. Windows Mobile-powered devices, for example, are configured with the root files for only VeriSign, CyberTrust, Thawte, and Entrust. For more information on small form factor devices, see WorkPlace and Small Form Factor Devices.

Obtaining a Certificate from a Commercial CA

Obtaining a certificate from a commercial CA provides verification of your identity for people who connect to your network through the appliance. You must perform several steps to obtain and configure a certificate from a commercial CA, as shown in Obtaining a CA certificate.

Obtaining a CA certificate

Step1: Generate a Certificate Signing Request

Using AMC, you can generate a certificate signing request (CSR). This process creates an RSA key pair that is used to secure server information, and a CSR containing your public key and identity information. The information you provide is used by the commercial CA to generate your certificate, and may be visible to users who connect to the appliance.

To generate a CSR:
1
From the main navigation menu in AMC, click SSL Settings.

2
In the SSL certificates area, click Edit. The SSL Certificates page displays.

3
Click the Certificate signing requests tab.

4
In the Certificate signing requests area, click New. The Create Certificate Signing Request page appears.

5
The Certificate information you fill out is stored in the CSR and used by the commercial CA when generating your certificate; it may be visible to users who connect to the appliance.
* 
NOTE: Some commercial CAs may have problems reading CSRs that contain characters produced by pressing the SHIFT key, such as & or !. For example, when specifying your company name or other information, you may want to spell out & (if used) as and.
a
In the Fully qualified domain name field, type the server name as you want it to appear in the certificate. Also known as a common name (or CN), this is usually composed of a host and a domain name; for example, you might type vpn.example.com.

Users with a Web-based client will use this name to access the appliance (in other words, to access WorkPlace), so it’s best to use a name that is easily remembered. You’ll also reference this name when configuring the Connect or OnDemand components to provide access to TCP/IP resources. You must add this name to your external DNS to make the appliance accessible to users.

Certificate Signing Requests can be created with multiple FQDN or IP addresses. On the SSL Settings > SSL Certificate > Create Certificate Signing Request page, simply enter multiple FQDNs and/or IP addresses separated by commas. Any number of SANs can be added to a certificate, but the text input field is 1,000 characters maximum. Wild cards are permitted. The entered FQDNs and IP addresses are encoded in the subject alternative name certificate extension and the certificate FQDN is encoded as an additional SAN entry in the CSR.

b
In the Alternative name field, type any additional FQDNs or IP addresses that should appear in the certificate using the Subject Alternative Name certificate extension. Separate multiple alternative names and IP addresses with a comma.
c
In the Organizational unit field, type your division or department (for example, MIS Dept).
d
In the Organization field, type your company or organization name as you want it to appear in your SSL certificate.
e
In the Locality field, type your city or town. Do not use an abbreviation.
f
In the State field, type the name of your state or province. Do not use an abbreviation.
g
In the Country field, type the two-letter abbreviation for your country. For a list of valid country codes, see the International Organization for Standardization (ISO) Web site at http://www.iso.org and search for ISO 3166-1.
h
In the Key length drop-down menu, select the key length you want to use for the key: 512, 768, 1024, 1280, 1536, 2048 (the default), or 3072. Larger keys increase security, but make the appliance run more slowly. A key length of 2048 is recommended for most installations.
6
Select the key type from the Key type drop-down menu. The default is RSA.
7
In the Signature drop-down menu, select the algorithm used for the certificate.
8
Review the information to verify that you’ve typed it correctly.
9
Click Save to generate the CSR. The Certificate Signing Request page redisplays with the CSR information you entered.

10
Copy the contents of the CSR text from AMC to the clipboard or into a text file.
11
Click OK.
Step2: Submit the CSR to a Commercial CA

The process of submitting a CSR varies, depending on which commercial CA you choose. VeriSign is a popular commercial CA that provides SSL certificates through their Secure Site Services; for information see http://www.symantec.com/ssl-certificates.

To submit a CSR to a commercial CA:
1
Copy the contents of your certificate signing request from the Create Certificate Signing Request page in AMC.
2
Submit it to the CA using the method they request (usually you either copy and paste the CSR text into a form on the CA’s Web site, or attach it to an email message).

Depending on what is specified by the CA, you may need to paste all the text, or only the text between the BEGIN NEW CERTIFICATE REQUEST and END NEW CERTIFICATE REQUEST banners (including the banners themselves). If you’re not sure, contact the CA.

3
Wait for the commercial CA to verify your identity. You may be asked to produce one or more documents attesting to your corporate identity (such as a business license or article of incorporation).
* 
NOTE: Submit your CSR only once; you may otherwise be billed twice by the CA. This would also change the internal private key, making the response from the CA unusable.
Step 3: Review CSR Response and Add CA’s Root Certificate

After you’ve submitted your CSR, you must wait for the CA to verify your identity. After they complete this process, the CA will send you the certificate reply. It is usually in one of two formats:

A file attached to an email message. In this case, you can save the file to your local file system (the one from which you’ll access AMC) and then import it into AMC.
Text embedded within an email message. In this case, you copy the text and paste it into a text box provided in AMC. Be sure to include the BEGIN CERTIFICATE and END CERTIFICATE banners.

If the CA does not provide a full certificate chain in the CSR response (a common practice), AMC will try to complete the certificate chain when you import the CSR response. If it is unable to complete the chain, AMC displays an error message. If this occurs, you must upload the CA’s root certificate or any intermediary public certificates to the appliance. If you are acting as your own CA, you will probably need to perform this step.

To complete a certificate chain:
1
Obtain the trusted root certificate or intermediary public certificate from the CA. Most external commercial CAs provide the certificates on their Web site; if the CA is run by your company, check with the server administrator.
2
From the main navigation menu in AMC, click SSL Settings.
3
In the SSL certificates area, click Edit.
4
In the Certificate signing requests list, click the Process CSR response link for the appropriate certificate. The Import CSR Certificate page appears.
5
Upload the certificate:
If the certificate is in binary format, click Browse and then upload the certificate reply from your local file system (that is, the computer from which you’ve logged in to AMC).
If the certificate is in base-64 encoded (PEM) text format, click Certificate text and then paste the certificate into the field. Be sure to include the BEGIN CERTIFICATE and END CERTIFICATE banners.
6
Click Import to return to the CA Certificates page.
7
To verify that the certificate was properly uploaded, click CA Certificate. The new certificate should appear on the CA Certificates page.
Step 4: Import the CSR Response Into AMC

To create a certificate, import the CSR response into AMC.

To import a certificate reply:
1
From the main navigation menu in AMC, click SSL Settings.
2
In the SSL certificates area, click Edit.
3
In the Certificate signing requests list, click the Process CSR response link for the appropriate certificate.
4
Upload the certificate on the Import CSR Certificate page:
If the certificate is in binary format, click Browse and then upload the certificate reply from your local file system (that is, the computer from which you have logged in to AMC).
If the certificate is in base-64 encoded (PEM) text format, select Certificate text and paste the certificate into the text box. Be sure to include the BEGIN CERTIFICATE and END CERTIFICATE banners.
5
In the Used by drop-down menu, select AMC or WorkPlace/access methods (select None if you want to build a list of certificates from which to choose later). If you defined additional WorkPlace sites (in addition to the default WorkPlace site), their names are included in this list.
6
Click Save.
7
To verify that the certificate was properly uploaded, click the plus sign (+) next to it on the SSL Certificates page.
Step 5: Apply Your Changes

To start using a new certificate, you need to apply your configuration changes. For more information, see Applying Configuration Changes.

After applying the change, the appliance examines the new certificate and begins using it for all new connections. If the appliance fails to correctly process the certificate, you see a failure message and the event log records information about the failure. Typically, this occurs if there is no certificate, the certificate has expired (or is not yet valid), or the cached password in the encrypted password file is incorrect.

* 
NOTE: If your users authenticate using digital certificates, you must configure a trusted root file on the server as well as on the clients. See Configuring Client Certificate Revocation.

Creating a Self-Signed Certificate

If you plan to use a self-signed SSL certificate (instead of obtaining a certificate from a commercial CA), you can create one using AMC. A host is not selected for the certificate, because there is no one to one mapping of certificates to hosts. Wildcard certificates allow one certificate to map to multiple hosts. In addition, a self-signed SSL certificate can be created with multiple FQDN or IP addresses.

To create a self-signed certificate:
1
From the main navigation menu in AMC, click SSL Settings.
2
In the SSL certificates area, click Edit.
3
Click New.
4
Select Create self-signed certificate from the menu.
5
In the Fully qualified domain name field, type a wildcard domain name such as *.domainname.com, or type the individual server name as you want it to appear in the certificate:
The main appliance certificate can be a wildcard certificate, or you might type something like vpn.example.com. You must add this name to your external DNS to make the appliance accessible to users.

This is the name users will enter for access to Web-based resources on your network. For a wildcard certificate, the * matches any string of characters up to the dot, such as specific server names. You also reference this name when configuring the Connect clients to provide access to TCP/IP resources.

If this certificate will be used by AMC (as opposed to WorkPlace), you might type something like amc.example.com. In most cases, you should add this name to your internal DNS to simplify access to AMC.
Any number of SANs can be added to a certificate, but the text input field is 1,000 characters maximum. Simply enter multiple FQDNs and/or IPv4 or IPv6 addresses separated by commas. SANs can contain wildcard entries (*.SonicWall.com, *.access.SonicWall.com), unique FQDNs (access.SonicWall.com, vpn.SonicWall.com), and IP addresses.

The entered FQDNs and IP addresses are encoded in the subject alternative name certificate extension and FQDNs are encoded as an additional SAN name in the certificate. If a SAN is an IP address, it is encoded as an IPAddress in the SAN extension instead of a DNSName.

6
In the Alternative names field, type any additional FQDNs or IP addresses that should appear in the certificate using the Subject Alternative Name certificate extension. Separate multiple alternative names and IP addresses with a comma.
7
In the Organization field, type the company or organization name as you want it to appear in your SSL certificate.
8
In the Country field, type the two-letter abbreviation for your country. For a list of valid country codes, go to the International Organization for Standardization (ISO) Web site at http://www.iso.org and look for information on ISO 3166-1.
9
In the Key size list, select the key length you want to use for the key. Larger keys increase security, but make the appliance run more slowly. A key length of 1024 bits or 1280 bits is recommended for most installations.
10
In the Signature list, select the algorithm used for the certificate.
11
Click Save.
12
Click Pending changes and then apply the changes. (For more information, see Applying Configuration Changes.)
Creating the Trusted Root File for a Self-Signed Certificate

If you use a self-signed certificate, you will probably want to provide your users with a trusted root file (otherwise they will see a security prompt at every login).

* 
NOTE:  
Setup Tool creates a self-signed certificate for AMC. For most deployments, this self-signed certificate is sufficient and there is no need to obtain a certificate from a commercial CA. It is important, however, to use AMC within a trusted network. Self-signed certificates protect against passive eavesdroppers but not against active attackers.
If you’re deploying OnDemand for Microsoft Internet Explorer users on Apple Macintosh systems, you must obtain a commercial SSL certificate. A self-signed certificate will not work because the Macintosh Java Virtual Machine (JVM) won’t accept a certificate signed from an unknown CA.
To create a trusted root file for a self-signed certificate:
1
Log in to the appliance.
2
Make a copy of the server.cert file, which is located in /usr/local/extranet/etc.
3
Open the copied file in a text editor and remove everything except the root certificate. The file will contain one or more certificates as well as the private key. The root certificate is the last certificate block in the file, including the banners. In the following example, you would delete the first certificate block and the private key block:

The resulting file looks like this:

4
Distribute this file to your users. This increases security and prevents users from being prompted to accept the SSL certificate each time they connect. See Importing CA Certificates.

If you want increased security for your Web-based users, this file should be imported into the browsers for these users.

Managing Server Certificates in AMC

Topics:  
Importing an Existing Certificate from Another Computer

If you already have a certificate from a commercial CA, you may want to transfer it and its private key to the appliance. After you import the certificate, it will be used by the servers to secure user traffic on the appliance.

A host is not selected for the certificate, because there is no one to one mapping of certificates to hosts. Wildcard certificates allow one certificate to map to multiple hosts.

The appliance stores certificates in the PKCS #12 format. If your certificate is stored in a different format, convert it to PKCS #12 before importing. After performing the conversion, confirm that the PKCS #12 file contains the complete certificate chain.

To transfer an existing certificate to the appliance:
1
From the main navigation menu in AMC, click SSL Settings.
2
In the SSL certificates area, click Edit.
3
Click New, and then select Import certificate from the menu.
4
On the Import Certificate page, click Browse, and then upload the certificate from your local file system (that is, the computer from which you have logged in to AMC).
5
In the Password file, type the password that was used to encrypt the private key.
6
Click Save.

The appliance uses the previous certificate until you apply your configuration changes.

Exporting an SSL Certificate

You can export the SSL certificate used to secure user traffic on the appliance. The certificate will include the private key and be saved in PKCS #12 format.

To export the SSL certificate from the appliance:
1
From the main navigation menu in AMC, click SSL Settings.
2
In the SSL certificates area, click Edit.
3
Select the checkbox next to the certificate you want to export, and then click Export. The Export Certificate page appears.
4
In the Password field, type the password that you want to use to encrypt the private key.
5
Click Save, and then download the certificate file to your local file system (that is, the computer from which you’ve logged into AMC).
6
Click OK.

CA Certificates

Every CA requires a certificate so that it can be “trusted” by entities that request digital certificates from it. If a client trusts a CA certificate, it automatically trusts any other certificates that are issued by that CA. CA certificates thus form one of the foundations of public key cryptography. The CA certificate is either signed by the CA itself (a “root certificate”), or by a higher authority in a hierarchy of CAs in a public key infrastructure (an “intermediate CA certificate”).

The appliance uses CA certificates to secure the following:

Connections to a back-end LDAP or AD authentication server
Connections to a back-end HTTPS Web server
Device profiling (End Point Control), to verify the validity of certificates submitted by users who connect to the appliance. See Device Profile Attributes: client certificate in Device Profile Attributes for more information.

CA certificates usage

The appliance includes over 100 public root certificates from leading commercial CAs. If you’ve obtained a certificate from a commercial CA, its root certificate or intermediary public certificate is probably already installed on the appliance. However, if you are acting as your own CA you must import a root or intermediary public certificate to the appliance.

To view the list of certificates, click Edit in the CA Certificates area of the SSL Settings page.

This is also where you delete CA certificates.

Topics:  

Importing CA Certificates

If the appliance is not configured with the necessary CA certificate, you must obtain a copy and import it to the appliance using AMC. The procedure is the same, whether the certificate will be used to secure connections to back-end resources, or to authenticate users by means of a client certificate.

The new certificate appears in the alphabetical list on the CA Certificates page. When you upload a CA certificate for use with client certificate authentication (and you apply the change), network services are automatically restarted and user connections are terminated, forcing users to reauthenticate. You may want to schedule the change during off-peak hours.

* 
NOTE:  
If the certificate is being used to secure authentication server connections, check to see that the appropriate LDAP over SSL or Active Directory over SSL settings are enabled on the Configure Authentication Server page in AMC.
By default, the Web proxy service is configured to verify the root certificate presented by back-end HTTPS Web servers. This important security check helps ensure that you can trust the identity of the back-end server. See Configuring the Web Proxy Service.
If you do not want to trust a CA listed on the CA Certificates page, select the checkbox next to it, and then click Delete.
When setting up devices profiles, avoid checking for client certificates within the same zone more than three times. If there are multiple EPC checks for client certificates within the same zone, users may see an error message (An error was encountered encoding data to be sent to the Logon Server).
To import a CA certificate to the appliance:
1
Obtain the trusted root certificate or intermediary public certificate from the CA. Most external commercial CAs provide the certificates on their Web sites; if the CA is run by your company, check with the server administrator.
2
From the main navigation menu in AMC, click SSL Settings.
3
In the CA Certificates area, click Edit on the certificates line.
4
Click New. The Import CA Certificate page appears.
5
Do one of the following:
If the certificate is in binary format, click Choose File and then upload the certificate from your local file system (that is, the computer from which you’ve logged in to AMC).
If the certificate is in base-64 encoded (PEM) text format, click Certificate text and then paste the certificate into the text box. Be sure to include the BEGIN CERTIFICATE and END CERTIFICATE banners.
6
Specify the connection types this certificate will be used to secure:
 

Connection types for certificates

Connection type

Description

Authentication server connections (LDAPS)

Securing your LDAP or Active Directory (AD) connection with SSL enhances security by preventing attempts to impersonate the LDAP or AD server. To configure LDAP or AD over SSL, you must add the root certificate for the CA that granted your LDAP or AD certificate to the SSL trusted roots file.

Web server connections (HTTPS)

If you have a back-end Web resource that is secured with SSL (that is, it uses HTTPS instead of HTTP), configure the Web proxy service to verify the root certificate presented by the back-end server. This important security check will help ensure that you can trust the identity of the back-end server. See Configuring the Web Proxy Service for details.

If the back-end server’s root certificate is not pre-installed on the appliance, you must obtain a copy and import it in AMC.

Device profiling (End Point Control)

EPC can be used to verify the validity of certificates submitted by users who connect to the appliance. If a client certificate is used in a device profile to classify users into an EPC zone, the appliance must be configured with the root or intermediary certificates for the CA that issued the client certificate to your users.

When the appliance interrogates the user’s computer to determine if the specified certificate is present, it can be configured to search just the system store (HKLM\SOFTWARE\Microsoft\SystemCertificates), or also include the user store (HKCU\Software\Microsoft\SystemCertificates).

OCSP response verification

The OCSP response signing certificate is used to verify a response from a configured OCSP responder. When importing the OCSP response signing certificate, enable OCSP response verification. This is a different certificate than the CA certificate for the OCSP responder or server itself, which is used in the PKI Authentication server.

7
Click Import. The CA Certificates page appears and displays a confirmation message.

Configuring Client Certificate Revocation

Certificates installed on client devices can be used to authenticate users or devices, giving them access to a particular realm. A certificate is usually valid until it expires, but it is possible for it to be compromised before it expires. For example, a CA may decide that a certificate was improperly issued, or its private key may have been compromised.

You can consult a certificate revocation list (CRL) to check a certificate’s validity (its location—the CRL distribution point, or CDP—is typically included in the X.509 certificate). If a certificate is no longer valid, the user is denied access. CRLs are published for each authority and can contain status of only the certificates issued by that certificate authority. This requires a separate, hierarchical CRL server for each CA that you want to trust. The client needs to know the public key for each CA in the chain to verify each certificate and CA at each level in the chain.

Online Certificate Status Protocol (OCSP) and an OCSP responder server can be used instead of a CRL server to check the status of a certificate. OCSP responders take the certificate from a client, evaluate it and give back a response to the server as revoked, unrevoked, or unknown. OCSP can save bandwidth in a large organization, as the CRL server list can get very large. OCSPs can be configured to operate for any number of CAs and certificates. A single OCSP server can be configured for the entire PKI infrastructure, irrespective of CA relations.

* 
NOTE:  
If both CRL and OCSP are enabled for a CA certificate, only OCSP will be used.
Fallback from CRL to OCSP or OCSP to CRL is not supported.
Topics:  
Managing Certificates with a CRL

Use the Manage CA Certificate page in AMC to configure certificate revocation checking for individual certificates, and determine the connection types the certificate is used to secure.

To verify the validity of a client certificate and configure certificate revocation:
1
From the main navigation menu in AMC, click SSL Settings.
2
Under CA Certificates, click Edit on the <number> certificates line. All the certificates are displayed.

3
To see details about a certificate, click its plus sign (+) in the second column. To edit a certificate, click its link. For example:
a
Click the plus sign next to Thawte Server CA to see details about this certificate from Thawte Consulting.

b
Click the link to edit it. The Manage CA Certificate page displays.

4
In the Used for area, specify the connection types this certificate is used to secure.
Authentication server connections (LDAPS)—See Configuring a PKI Authentication Server.
Web server connections (HTTPS)—See CA Certificates.
Device profiling (End Point Control)—See Device Profile Attributes: client certificate in Device Profile Attributes.
OCSP response verification – Verifies a response from a configured OCSP responder.
5
To specify CRL settings, check the Use Certificate revocation list in the Certificate revocation checking area.
* 
IMPORTANT: The format for the CRL must be DER-based (.crl); the appliance cannot use a CRL that's been created in PEM format.

6
The appliance retrieves lists of revoked certificates from a CRL distribution point (CDP). Specify the location of this CDP:
The CDP is usually specified in the certificate itself. By default, the appliance uses the CDP from the client certificate.
Alternatively you can specify a URL for it. Check the Use this certificate distribution point (CDP) checkbox. If a login is required for it, type the credentials.
7
If Use this certificate distribution point (CDP) is selected, you can specify how often the CRL should be retrieved using the Download CRL every <n> hours option. If you don’t specify a download interval, a new CRL is retrieved when the old one expires. (CRLs are updated frequently so that when a certificate is revoked, that information is distributed in a timely manner.)
8
The appliance checks client certificates against this list. To perform CRL checking for the entire chain of certificates, starting with the CA root certificate, select the Validate the entire chain checkbox.
9
Specify whether users should be allowed or denied access if the CDP is inaccessible by selecting Allow user access or Block user access. The remote CDP you specified might be offline, or it may not be indicated on the certificate. (It is an optional item for the X.509 standard, not a mandatory one.)
10
Click Save.
Configuring an OCSP Responder

Use the OCSP page in AMC to configure global settings for an OCSP responder. The OCSP responder can be referenced when configuring a PKI authentication server.

* 
NOTE: Just importing a CA certificate and enabling OCSP is not sufficient for OCSP to work. You must import the OCSP response signing certificate for the CA certificate being used and enable OCSP response verification when importing it. See Importing CA Certificates.
To configure an OCSP responder:
1
From the main navigation menu in AMC, click SSL Settings.
2
Under CA Certificates, click Edit on the OCSP line. The OCSP page is displayed.

3
In the Default responder URL field, enter the URL of the OCSP responder server.
4
In the Maximum clock skew field, enter the maximum number of seconds that the OCSP response time can differ from the local time. The default value is 300 seconds, the minimum is 1 second, and the maximum is 3600 seconds.
5
Click Save.

Managing CA Certificates

This section describes tasks related to managing certificates on the appliance; importing certificates is described in Importing CA Certificates.

Topics:  
Viewing CA Certificate Details

You can view the details for the appliance certificate, such as the subject, issuer, start and end time, serial number, and MD5 checksum. Details of a newly imported certificate are not available until you have applied the configuration change.

To view CA certificate details:
1
From the main navigation menu in AMC, click SSL Settings.
2
In the CA Certificates area, click Edit.
3
Click the plus sign (+) to the left of the certificate you want to see details about.
Mapping Certificates to Hosts

As multiple hosts on the appliance may use a single wildcard certificate, the Certificate usages table provides a mapping of a single certificate to multiple sets of hosts. A set of hosts is defined as one or more WorkPlace sites, Exchange sites, or custom FQDN mapped resources that are on the same IP address. Any given set of hosts must use the same wildcard certificate and therefore are treated as a single item for mapping certificates in the Certificate usages table. AMC is treated as a separate host even if it is on the same IP address as other hosts on a single-homed appliance.

To map a new certificate to a host or set of hosts:
1
From the main navigation menu in AMC, click SSL Settings.
2
In the SSL Certificates area, click Edit.
3
In the Certificates column of the Certificate usages table, click on the certificate to activate an in-place editor with a drop-down certificate selector.
4
Select the certificate. For individual hosts, all certificates are available for selection. For a set of multiple hosts, only wildcard certificates are available for selection.
5
Click OK.
Exporting CA Certificates

You can export a CA certificate and its private key to your local computer. The certificate is saved in PKCS #12 format.

To export a CA certificate:
1
From the main navigation menu in AMC, click SSL Settings.
2
In the CA Certificates area, click Edit.
3
Select the checkbox to the left of the certificate you want to export.
4
Click Export.
5
In the Password field, type the password that encrypts the private key.
6
Click Save. The certificate is saved (by default) to a file named server_cert.p12.
Deleting CA Certificates

To make the list of certificates more manageable, you might want to delete those that you know you will never need.

To delete a CA certificate
1
From the main navigation menu in AMC, click SSL Settings.
2
In the CA Certificates area, click Edit.
3
Select the checkbox to the left of any certificates you want to delete.
4
Click Delete.

Working with Certificates FAQs

Topics:  

How do I Obtain a Certificate from a Non-Commercial CA?

The process is identical to the one for obtaining a certificate from a commercial CA, except that you submit the CSR to a non-commercial CA (such as a Microsoft Self-Signed Certificate Authority). This part of the process is outlined in Step2: Submit the CSR to a Commercial CA.

When do Certificates and CRLs Expire?

Self-signed certificates are valid for five years. The expiration date for third-party certificates varies, depending on who issued the certificate; contact the CA for more information. A Certificate Revocation List (CRL) is valid for a much shorter period of time: days, or even hours.

When using certificates and CRLs, it is important for the clock on the appliance to be accurate, since it is used to determine when these items expire.

Does Secure Mobile Access support SAN Certificates?

Subject Alternative Name (SAN) certificate support for Workplace, Workplace sites, and Connect Tunnel has been added beginning in version10.7. Certificates (also called UCC--Unified Communications Certificate) are used to securely encrypt communication channels between a set of clients and multiple distinct SSL or TLS services.

SAN certificates simplify the IP address/hostname/certificate sets needed for a typical deployment. With a single SAN certificate, you can utilize one IP address with multiple distinct SSL or TLS protected web or client/server services, without the need for configuring additional IP addresses. Additionally, SANs can be used for different host names on the same IP address, alleviating the need for a one-to-one mapping of SSL certificate Common Names to FQDN.

* 
NOTE: Only IPv4 addresses are supported in SAN certificates and Certificate Signing Requests (CSR).

Improvements include:

SANs-related features can be generated via the AMC instead of through mechanisms external to the appliance:
CSR with SANs
Self-signed certificates with SAN entries
WorkPlace sites, custom FQDN URL resources, and ActiveSync resources can be created using existing SAN certificates.
Global load balancing uses original web requests to direct traffic to a load balancer instead of the default WorkPlace site.
Connect Tunnel seamlessly handles connections to Workplace sites that use a combination of IP address, FQDN, or SSL certificate, regardless of the number of IP addresses associated with a WorkPlace site.

The Administrator can generate, import, process, and otherwise use a SAN certificate for Workplace, ActiveSync, Custom FQDN URL Mapping, or Tunnel based access services.

Are Intermediate Certificates supported for End-User Certificate Verification?

Yes, intermediate certificates are supported for end user certificate verification. This covers PKI and LDAP certificate methods. This allows an intermediate certifying authority to be imported to validate a certificate chain, without requiring trust of the root certifying authority.

A client machine can use a client certificate that was issued by an intermediate certifying authority. When such a client certificate is imported directly on Windows 7, the client certificate is stored in the personal store, the intermediate certificate is imported to the intermediate CA store, and the root CA certificate is imported to the root CA store. This is the recommended method, and the certificates will work with tunnel clients and ExtraWeb clients using PKI authentication. If all three certificates are stored in the personal store, which can happen if certmgr.msc is used to import the client certificate, then Connect Tunnel may display an error and deny access. This is not a recommended configuration.

What Are the Different CA Certificates on the Appliance and How Are They Used?

To see the list of CA certificates available on the appliance, click SSL Settings on the main navigation menu, and then click Edit in the CA Certificates area. By default, any certificate in the list can be used to secure up to three connection types (authentication server, secure Web server, and client certificate). Click on a certificate to set the connection types you want it to secure.

How many CA Certificates can be Stored on the Appliance?

The roots file can contain as many certificates as you want to trust. For instructions on how to import additional CA certificates, see Importing CA Certificates.

Can Private Keys or CSRs Generated from Other Tools be Imported to the Appliance?

Private keys and CSRs must be generated on the appliance using Setup Tool or the certificate generation tool. However, you can copy private keys and CSRs from one SMA appliance to another using the procedure described in Managing Server Certificates in AMC. Any copied certificates are overwritten if you make changes to them in AMC.

Where Is the AMC Certificate Stored?

AMC’s self-signed certificate is stored on the appliance in /usr/local/app/mgmt-server/sysconf/active/.

For AMC, a self-signed certificate is sufficient for most environments. It is important, however, to use AMC within a trusted network. Self-signed certificates protect against passive eavesdroppers but not against active attackers.

Should I Keep All CA Certificates on the Appliance or Just the Ones I Need?

For the sake of convenience, the appliance includes more than 100 CA certificates. To make your deployment more secure, you may want to pare this list down so that it includes only the CA certificates you need for client certificates, LDAPS, and HTTPS. A shorter list is also easier to manage.

Managing User Authentication

Authentication is the process of verifying a user’s identity to ensure that the individual really is who he or she claims to be. (Authentication differs from authorization: it verifies identity, while authorization specifies access rights.) This section describes how to reference external authentication servers.

To manage user authentication, you must first define one or more external authentication servers in AMC, and then set up realms that reference those authentication servers. These are the realms that users will log in to. For information on realms, see Using Realms and Communities. You can also configure a local authentication repository on the appliance for testing, as described in Configuring Local User Storage.

Topics:  

About Intermediate Certificates

You can configure an authentication server to trust intermediate CAs without verifying the entire chain. This provides benefits, such as distributing certificate management among several signing authorities, several of whom might be remote to the root CA server and therefore would otherwise be unable to issue certificates, and adds security because the compromise of any single signing authority does not compromise the entire network.

To configure trusted intermediate certificates, see Configuring a PKI Authentication Server.

For example, you could create a root certificate signing authority on a system that is not connected to the corporate network. You can then issue a set of trusted intermediate signing authority certificates to be deployed in various sectors of the network (often by department or organizational unit). For the VPN, this is most often done to distribute machine or personal certificates to client systems.

The other alternative is to obtain a signing certificate from a certificate authority such as VeriSign or Thawte. In this case, your main CA is actually an intermediate CA itself.

By SSL rules, the root CA certificate must be accessible in order to validate the entire chain. However, the appliance makes no distinction between importing a CA certificate for trust and importing a CA certificate to validate a certificate chain for the intermediate CA that you want the appliance to trust. If no options are selected when a CA certificate is imported, the CA will only be used to validate certificate chains. (The options are the connection types the certificate is used to secure: Authentication server connections (LDAPS), Web server connections (HTTPS), and Device profiling (End Point Control)). Any CA certificate used only to validate certificate chains is not offered as a trusted signer during client certificate authentication or EPC certificate enforcement.

When an end user presents a client certificate signed by an intermediate CA, assuming the appliance trusts the signing authority, the user is allowed to authenticate and access resources normally.

When an end user presents a client certificate issued by a root CA of the trusted intermediate CA, unless the administrator has also imported the root CA for trust purposes, the end user authentication attempt fails due to lack of valid and trusted certificate.

If a client presents a certificate that is signed by a CA that exists only for chain validation, the certificate will be rejected. This results in an authentication failure or a failure for certificate authentication and in a failure to match the device profile for certificate EPC.

Configuring Authentication Servers

Setting up authentication involves the following: a directory (such as LDAP, Microsoft Active Directory, or the local authentication store on the appliance), an authentication method (username/password, token or smart card, or digital certificate), and other configuration items that make the authentication process unique (for example, an LDAP search base, or adding custom prompts and messages). The SMA appliance supports the leading authentication directories and methods.

After you reference an authentication server in a realm and associate users with the realm, the appliance checks users’ credentials against the credentials stored in the specified authentication repository. You can also set up chained (two-factor) authentication; see Configuring Chained Authentication for details.

To configure an authentication server:
1
From the main navigation menu in AMC, click Authentication Servers, and then click New.

2
In the User store area, specify the directory type or authentication method you want to configure:
 

Directory type or authentication method selection

Authentication directory

Credential type

For more information

Microsoft Active Directory

Microsoft Active Directory Tree

Username/password

Configuring Microsoft Active Directory Servers

LDAP

Username/password
Digital certificate

Configuring LDAP and LDAPS Authentication

RADIUS

Username/password
Token-based authentication (such as SecurID or SoftID)

Configuring RADIUS Authentication

RSA Authentication Manager Server

Token-based authentication (such as SecurID or SoftID)

Configuring RSA Server Authentication

Public key infrastructure (PKI)

Digital certificate (with optional certificate revocation checking)

Configuring a PKI Authentication Server

SAML 2.0 Identity Provider

Username/password

Configuring a SAML-Based Authentication Server

RSA ClearTrust (single sign-on)

N/A

Configuring a Single Sign-On Authentication Server

Local users (local user storage)

Username/password

Configuring Local User Storage

3
Select the Credential type of the authentication server (what types are available depends on the User store you selected).
4
Click Continue. For information about the next step in the configuration process, follow the link for the User store you selected in the previous step.

for further information about tasks after configuring the authentication server, see:

Defining Multiple Authentication Servers

The SMA appliance supports the definition and use of multiple authentication servers. A realm references one or two authentication servers and determines which access agents are provisioned to your users and what End Point Control restrictions (if any) are imposed. See Users, Groups, Communities, and Realms for more about realms.

Following are examples of using multiple authentication servers referenced by realms:

Chained authentication (two authentication servers)

Example: RADIUS with Token/SecurID and LDAP with username/password

Users logging in to a realm are authenticated against two servers. You can configure AMC so that users see only one prompt. See Configuring Chained Authentication for details.

Use different servers to handle authentication and authorization

Example: RADIUS with Token/SecurID and Active Directory (for group information)

The user authenticates against one repository, and then the user’s group information is passed from a second one. For more information, see Enabling Group Affinity Checking in a Realm.

Multiple credential types and a single authentication server

Example: RADIUS with username/password and RADIUS with Token/SecurID

Suppose your company employees log in with usernames and passwords, but the employees of your call-center log in with SecurID tokens. You could create an employee realm and a callcenter realm, each referencing the appropriate credential type and RADIUS server.

Multiple instances of the same directory/authentication method using different back-end servers

Example: Two RADIUS/password instances using different RADIUS servers

In this case you would define two authentication servers, each with the appropriate server information.

Multiple instances of the same directory/authentication method on the same server, configured differently

Example: Two instances of LDAP with username/password on the same server but using different search bases

In this case each realm would search a different subtree within the directory. For example, suppose Partner A is in one LDAP subtree and Partner B is in another. You could define a partnerA realm and a partnerB realm, each configured with the appropriate search base.

Disabling Authorization Checks

You can optionally disable the querying of group information used for authorization when configuring an authentication server. A Use this authentication server to check group membership checkbox is available for each server type that can contain group information used for authorization, including Active Directory, Active Directory Tree, and LDAP servers.

Usually, when you use a directory server as part of authentication, you also want the group information stored there to be used in policy authorization. However, in some cases a directory server is used for secondary authentication and does not contain group information. In other cases, the secondary authentication server does not use the same identifier for the user.

If a group query is made on both a primary and a secondary server, the authentication process takes longer. However, if the user name is different on the two servers, a group query using the name from the primary server will result in an error from the secondary server. Since the appliance policy always defaults to closed, such an error will result in any deny rule being applied to the end user. By disabling group authorization checks on the secondary server, you can avoid these problems.

If group checking is disabled for an authentication server, the server will not be available in the list of available affinity servers on the realm configuration page. Conversely, if an authentication server is in use as an affinity server for any realm, group checking cannot be disabled for that authentication server. See Enabling Group Affinity Checking in a Realm for more information.

Configuring Microsoft Active Directory Servers

The appliance can validate username/password credentials against Microsoft Active Directory (AD) configured with either a single root domain, or one or more subordinate (child) domains. Microsoft Active Directory configuration options shows typical Active Directory configuration options.

Microsoft Active Directory configuration options

You must modify your firewall or router to allow the appliance to communicate with your AD server. The appliance uses standard LDAP and LDAPS ports to communicate with Active Directory:

LDAP (389/tcp)
LDAP over SSL (636/tcp)

With Microsoft Active Directory Tree there are additional ports, which facilitate searches and logons:

Global catalog (3268/tcp)
Global catalog using SSL (3269/tcp)
Kerberos (88/tcp)

After configuring an AD server, you can validate the realm configuration settings by establishing a test connection. For more information, see Testing LDAP and AD Authentication Configurations.

Topics:  

Configuring Active Directory with Username and Password

* 
NOTE:  
If you are using Active Directory with digital certificates, you must configure AD as an LDAP realm. See Configuring LDAP to Authenticate Against Active Directory.
If your AD authentication server has subordinate (child) domains, see Configuring Multiple Active Directory Trees for more information.
To configure an Active Directory authentication server with username/password validation:
1
From the main navigation menu in AMC, click Authentication Servers, and then click New.
2
Under User store, click Microsoft Active Directory.
3
The only Credential type that is available for AD is Username/Password. Click Continue. The Configure Authentication Server page appears.

4
In the Name field, type a name for the authentication server.
5
In the Primary domain controller field, type the IP address or host name of the AD domain controller. If you are using a failover server (optional), specify its address in the Secondary domain controller field.

If the AD server is listening on a something other than the well-known port (389 for unencrypted connections, or 636 for SSL connections), specify a port number as a colon-delimited suffix (for example, ad.example.com:1300).

6
To specify a particular AD domain, type it in the Active Directory domain name field. This should be the domain that you want to use as the search base (in other words, the domain that contains the appropriate cn=users container). For example, if you want to search a single domain such as marketing, type marketing.example.com. If you want to search your entire company’s domain, type example.com. If you do not specify a domain, the appliance searches the first available default naming context on the domain controller.
7
To perform AD searches, the appliance must log in to Active Directory (unless you have configured AD to allow anonymous searches). In the Login name field, type the username or sAMAccountname attribute used to log in to the Windows domain (such as jdoe or jdoe@example.com).

The login should be for a user who has privileges to perform searches and view user records, such as the administrator on that domain controller. You may also specify a non-administrator user who has these privileges.

If you specify an AD domain, the appliance searches that domain for users. If you do not specify a domain, the appliance searches the first available default naming context on the domain controller. If the user information is not stored in either of these locations, you need to configure this realm as an LDAP realm. See Configuring LDAP to Authenticate Against Active Directory.

8
Type the Password that corresponds to the Login name. After you’ve entered credentials, you can click the Test button for each server you specified in order to test the connection.
9
Complete the information listed under Group lookup:
To enable group checking on this server, select the Use this authentication server to check group membership checkbox. When this box is unchecked, the nested controls are disabled because they apply only to group checking behavior. This checkbox, when unselected, allows an authentication server for LDAP, AD, or AD-Tree to be configured without enabling it for authorization checks. This improves efficiency by allowing better stacked/affinity authentication support.
To specify the depth of the search (how many sub-groups to include in it), enter a number in the Nested group lookup checkbox. Be aware that this type of search can take some time because it requires searching the entire Active Directory tree; enabling Cache group checking is highly recommended.
To reduce the load on your directory and get better performance, cache the attribute group or static group search results. Select the Cache group checking checkbox and then specify a Cache lifetime, in seconds. The default value is 1800 seconds (30 minutes).
10
To secure the AD connection with SSL, expand the Active Directory over SSL area, and the configure the following settings:

a
Select the Use SSL to secure Active Directory connection checkbox.
b
To view your certificate details and to verify that the root certificate can be used by the appliance, click the SSL Settings link. This list should show the name of the CA (or CAs) that issued the client certificates and the SSL certificates. If your AD server’s CA is not listed in the file, or if you use a self-signed certificate, you must add your certificate to this file. See Importing CA Certificates for details.
c
To have the appliance verify that the AD domain controller host name is the same as the name in the certificate presented by the Active Directory server, select the Match certificate CN against Active Directory domain controller checkbox. Typically, your server name will match the name specified in its digital certificate. If this is the case with your server, SonicWall recommends enabling this option in a production environment. This makes it more difficult for an unauthorized server to masquerade as your AD server if your digital certificate or DNS server is compromised.
11
In the Advanced area, you can specify a username attribute, set up custom prompts, enable users to be notified of expiring Active Directory passwords, configure NTLM authentication forwarding options, and set up one-time passwords.

12
Type the Username attribute you want to use to match user names. In most AD implementations, sAMAccountName matches the user ID (for example, jdoe). You can use cn instead, but that would require the user to authenticate with his full name (John Doe) instead of his user ID (jdoe).
13
To change the prompts and other text that Windows users see when they log in to the authentication server, select the Customize authentication server prompts checkbox. If users should log in using an employee ID, for example, you could change the text for the Identity prompt from Username: to Employee ID. (If you plan to use chained authentication, customized password prompts are especially useful so that users can differentiate between them.)

14
If the connection between the appliance and the authentication server is secured with SSL (Use SSL to secure Active Directory connection is enabled), you can allow users to change their passwords in WorkPlace by selecting Enable user-initiated password change.
* 
CAUTION: If Active Directory over SSL is not enabled, passwords are transmitted in the clear to the AD server. If the internal network is not trusted, you should enable SSL. Your AD server must also be enabled to use SSL. See the Microsoft AD documentation for details.
* 
NOTE:  
The Login name and Password fields are not always required to connect to an Active Directory server. However, if they are not provided (or you don’t specify a password) the appliance will bind anonymously. In this case, if you have not configured Active Directory to allow anonymous searches, the search will fail.
Users must have permission on the AD server to change their passwords during the password notification period, and the administrator must have permission to change user passwords after they expire. For security reasons, both of these operations replace passwords rather than reset them.
If you define multiple Active Directory with SSL servers, you should specify the same Match certificate CN against Active Directory domain controller setting for each server. (SonicWall recommends enabling this option for a production environment.) Although AMC allows you to configure this setting on a per-realm basis, the appliance actually uses the setting specified in the last loaded ADS realm. For example, if you select this checkbox for three ADS realms, but clear it for a fourth, the functionality would be disabled for all four realms.
15
To allow the Active Directory server to notify users that their passwords are going to expire, select the Notify user before password expires checkbox. Indicate when the advance notice should begin (the default is 14 days, and the maximum is 30 days). The password prompt users see is controlled by the AD server.
16
To allow users to manage their own passwords, select the Allow user to change password when notified checkbox. This setting can be changed only if the Use SSL to secure Active Directory connection checkbox in the Active Directory over SSL area is selected. Password management is available only to users with Web access and those who are using Connect Tunnel.
17
To enable NTLM authentication forwarding, click one of the NTLM authentication forwarding options. For more information, see NTLM Authentication Forwarding.
18
To configure authentication that includes an OTP, enable Use one-time passwords with this authentication server. You must also configure your mail server: if OTPs are going to be delivered to external domains (for example, an SMS address or external webmail address), you may have to configure the SMTP server to allow passwords to be sent from the appliance to the external domain.
Enter the number of characters for the OTP in the Password contains field. The default length is 8, the minimum is 4, and the maximum is 20.
Select the type of characters in the OTP from the drop-down menu. Select Alphabetic, Alphabetic and numeric, or Numeric.
In the From address field, enter the email address from which the OTP will be sent.
In the Primary email address attribute field, enter the directory attribute for the email address to which one-time passwords will be sent. If the primary attribute exists on the authentication server, it is used.
The Secondary email address attribute, if specified, is used in addition to the primary email address. The OTP is sent to both addresses.

To have OTPs sent as a text message (instead of an email message), enter the corresponding attribute name (for example, SMSphone instead of Mail or primaryEmail). See Configuring the AD or LDAP Directory Server for more information.

In the Subject field, customize the subject line of the OTP email. You can use the replacement variable {password} to indicate a position in the subject line where the actual password will display.
In the Body field, customize the body of the OTP message. Use the replacement variable {username} to indicate a position in the message where the user’s account name will display. Use the replacement variable {password} to indicate a position in the message where the actual password will display.
To test delivery of an OTP to a user, enter the email address of the user who will receive the OTP into the Email address field and click the Send test message button. If the appliance is able to send the message, the status Message successfully sent is displayed below the button. Failure messages are also displayed below the button, such as errors connecting to the SMTP server, or errors communicating with the AD/LDAP server or looking up the specified user on the AD/LDAP server.
19
Click Save.

Configuring Multiple Active Directory Trees

This feature expands user authentication and authorization from one Active Directory (AD) tree to multiple AD trees within a trusted forest and AD Federated Forests. Configuring AD multi-forest/multi-realm support consists of the following steps:

1
Configure AD forest authentication server with AD domains from the current AD forest and trusted forests enabled.
2
Configure groups using multiple trees.
3
Configure groups using trees from trusted forests.

Once AD multi-forest/multi-realm support is configured, users from the designated forests can be authenticated and log into WorkPlace and Connect Tunnel.

* 
NOTE: A trusted domain is a domain that authenticates users when they login.
Topics:  
Configure AD Forest Authentication Server

Configure the AD forest authentication server and enable AD domains from the current AD forest and trusted forests:

1
In the main navigation menu, select Authentication Servers, and then click New... in the Authentication servers section.

2
In the User Store section of the New Authentication Server page, select Microsoft Active Directory (Advanced).

3
Select any other applicable options and click Continue... to advance to the Configure Authentication Server page.
4
In the Name field, type the name that will be used to identify the Active Directory tree or forest.
5
In the Root Domain field, type the AD root domain of the forest.
6
Check the Enable cross-forest trust checkbox to enable appliance access to other trusted forests. If not enabled, the appliance can access only the forest in a direct trust relationship with the configured forest.
7
In the Login name and Password fields, type the user name and password for a user who has read access to the entire Forest.
8
In the Active Directory DNS section, configure the DNS and Key Distribution Centers (KDCs) correctly.
Select Use DNS to lookup Active Directory domains to enable DNS lookups for a KDC/Kerberos realm, and then select the domains that will be displayed on WorkPlace. Only domains fetched from the configured forest are listed when Enable cross-forest trust is disabled (checkbox not checked).
Select Use these Active Directory domains and KDCs to also use KDCs and then click New and configure the KDCs.
Configure Groups Using Multiple Trees

Create groups of users and groups imported from the AD domains in the forest. Only users and groups from the configured forest are included when cross-forest trust is disabled.

Configure Groups Using Trees from Trusted Forests

Create groups of users and groups imported from AD Domains in the configured forest and trusted forests. Users and groups from the configured forest and all trusted forests are included when cross-forest trust is enabled.

User Login

Once AD multi-forest/multi-realm support is configured, users from the designated forests can be authenticated and log into WorkPlace and Connect Tunnel.

Users login to WorkPlace or Connect Tunnel using one of the following:

Username in UPN form (for example, <username>@KERBEROS_REALM) and password
Username, Password and Domain - when Domain Selection option is configured)
Username and Password – when a default domain is configured

Configuring LDAP to Authenticate Against Active Directory

If you have customized Active Directory (by, for example, specifying a search base instead of using the AD default), you need to authenticate to Active Directory using LDAP. The procedure for configuring an LDAP server is defined in Configuring LDAP and LDAPS Authentication. When configuring LDAP, you should pay special attention to the attributes you’re using to query the directory. Because every implementation of AD is different, you must know how the object classes and related attributes are configured in your Active Directory schema.

* 
NOTE: When an Active Directory (AD) server is used as an LDAP server, ACL checks cannot be performed. Short names (SN) or common names (CN) are not supported on LDAP servers. They are only supported on AD servers.

The following table describes the key AD attributes used to validate username and password credentials. The attributes are not case-sensitive.

 

AD attributes for credential validation

Field

Description

Login DN

The DN used to establish a connection with your Active Directory server. In a generic AD configuration located in the example.com domain, the DN for a user named John Doe would be:

cn=John Doe,cn=users,dc=example,dc=com

Search base

The point in the AD directory from which you want to search for user information. Usually, this is the lowest point in the directory tree that contains user information. The user binding to AD must have permissions to view the directory at this level.

For a generic installation, a search base of cn=users,dc=example,dc=com will find most users. You may want to search from a higher level (such as dc=example,dc=com) if some users are stored in a different branch.

Username attribute

The attribute used to match usernames. In most AD implementations, sAMAccountName matches the user ID (for example, jdoe). You can use cn instead, but that would require the user to authenticate with his full name (John Doe) instead of his user ID (jdoe).

If you create an access control rule that references a group, a user must be an explicit member of that group for his or her request to match the rule. To include nested groups when evaluating group membership, make sure that Nested group lookup is set accordingly when you configure the authentication server in AMC.

For example, assume that the SeattleCampus group contains a group called Marketing. Employee John Doe is a member of the Marketing group, but is not explicitly a member of SeattleCampus. If Nested group lookup is set to 0, the appliance will not recognize John Doe as a member of the SeattleCampus group; if it is set to 1, he is recognized.

Microsoft provides a graphical tool that makes it easy to perform LDAP operations, including connecting, browsing, and modifying a directory. The tool—called LDP (ldp.exe)—is available with the Support Tools for the Windows Server platform; see the Microsoft Product Support site for more information.

LDAP Examples for Active Directory Authentication

Example 1—Active Directory
 

Active Directory Configuration 1

Login DN

CN=AVtest,CN=Users,DC=testusrs,DC=example,DC=com

Search base

DC=testusrs,DC=example,DC=com

Username attribute

sAMAccountName

Example 2—Active Directory
 

Active Directory Configuration 2

Login DN

CN=johnDoe,CN=Users,DC=na,DC=example,DC=com

Search base

CN=Users,DC=na,DC=example,DC=com

Username attribute

sAMAccountname

Example 3—LDAP with Domino Server
 

LDAP Configuration with Domino Server

Login DN

CN=E-Class SMA,O=peoplesoft

Search base

o=peoplesoft

Username attribute

cn

Configuring LDAP and LDAPS Authentication

The SMA appliance supports authentication using the LDAP or LDAPS (LDAP over SSL) protocols. Either protocol can be used to validate username and password credentials. LDAP and LDAPS authentication configuration options shows typical LDAP configuration options.

LDAP and LDAPS authentication configuration options

Securing your LDAP connection with SSL requires additional configuration. You must add the root certificate of the CA that granted your LDAP certificate to the SSL trusted root file. This enhances security by preventing attempts to impersonate your LDAP server. For more information, see Importing CA Certificates.

After configuring an LDAP or LDAPS server, you can validate the realm configuration settings by establishing a test connection. For more information, see Testing LDAP and AD Authentication Configurations.

Consider the following restrictions when configuring LDAP authentication:

Firewalls and routers - You must configure your firewall or router to allow the appliance to communicate with your LDAP server. Standard LDAP uses port 389/tcp; LDAPS communicates over port 636/tcp.
LDAP Affinity servers - Although it is possible to configure LDAP Affinity servers for all authentication servers, an Affinity server should be used only for an authentication server that does not include full group search capabilities, such as a RADIUS, RSA, and PKI server. In addition, Secure Mobile Access does not support Affinity servers for stacked authentication where any one of the authentication servers has group checking capabilities.
* 
NOTE: When an Active Directory (AD) server is used as an LDAP server, ACL checks cannot be performed. Short names (SN) or common names (CN) are not supported on LDAP servers. They are only supported on AD servers.
Digital certificate validation - Configuring an LDAP authentication server with digital certificate validation is offered for legacy customers. New users should use the standard method described in Configuring a PKI Authentication Server. The Trust intermediate CAs without verifying the entire chain option is offered on the configuration pages for both the LDAP with Digital Certificate option and the Public key infrastructure (PKI) option.
Topics:  

Configuring LDAP with Username and Password

Remember the following when configuring LDAP:

The Notify user before password expires and Allow user to change password when notified settings in the Password management area have some constraints:
They are supported only on IBM Directory Server.
They are available only for users who connect to the appliance using Web access (the Web proxy agent or translated, custom port mapped, or custom FQDN mapped Web access), or using Connect Tunnel.
Users must have permission on the LDAP server to change their passwords.
The Login DN and Password fields are not always required in order to connect to an LDAP server. However, if they are not provided (or you do not specify a password), the appliance binds to LDAP anonymously, which does not usually provide the appropriate permissions for performing user and group information searches.
If you define multiple LDAPS servers, you should also configure the Match certificate CN against LDAP server name setting to be the same for each realm. (Enabling this option is recommended in a production environment.) Although AMC allows you to configure this setting per realm, the appliance actually uses the setting configured in the last loaded LDAPS realm. In other words, if you selected this checkbox for three LDAPS servers, but cleared it for a fourth LDAPS realm, the functionality would be disabled for all four servers.
Configuring an LDAP authentication server with digital certificate validation is offered for legacy customers. New users should use the standard method described in Configuring a PKI Authentication Server.
To configure an LDAP authentication server with username and password validation:
1
From the main navigation menu in AMC, click Authentication Servers, and then click New.
2
Under Authentication directory, click LDAP.
3
Under Credential type, click Username/Password, and then click Continue. The Configure Authentication Server page appears.

4
In the Name field, type a name for the authentication server.
5
Complete the information listed under General:
In the Primary LDAP server field, type the host name or IP address of your LDAP server. If you are using a failover server (optional), specify its address in the Secondary LDAP server field.

If the LDAP server is listening on a something other than the well-known port (389 for unencrypted LDAP connections, or 636 for SSL connections), specify a port number as a colon-delimited suffix (for example, myldap.example.com:1300).

In the Login DN field, type the distinguished name (DN) used to establish a connection with the LDAP server.
In the Password field, type the password used to establish a connection with the LDAP server.
In the Search base field, type the point in the LDAP directory from which you want to begin searching for user information. This will usually be the lowest point in the directory tree that contains user information. For example, you might type ou=Users,o=xyz.com. The user binding to the LDAP directory must have permissions to view the directory at this level.
In the Username attribute field, type the attribute used to match usernames. This is usually cn or uid.
Click the Test button for each server you specified in order to test the connection.
6
Complete the information listed under Group lookup:

To enable group checking on this server, select the Use this authentication server to check group membership checkbox. When this checkbox is unchecked, the nested controls are disabled because they apply only to group checking behavior. This checkbox, when unselected, allows an authentication server for LDAP, AD, or AD-Tree to be configured without enabling it for authorization checks. This improves efficiency by allowing better stacked/affinity authentication support.
If you want the LDAP search to determine a user’s group membership by searching the group attribute in the user container, select the Find groups in which a user is a member checkbox and then type the Group attribute. This attribute is most often memberOf. Do not select this checkbox unless attribute-based groups are supported by and enabled on your LDAP server.
If your LDAP server does not support attribute-based groups or you have not enabled this functionality, you can select the Look in static groups for user members checkbox; to specify the depth of the search (how many sub-groups to include in the search), enter a number in the Nested group lookup checkbox. Be aware that this type of search can take some time because it requires searching the entire LDAP tree; enabling Cache group checking is highly recommended.
To reduce the load on your directory and get better performance, cache the attribute group or static group search results. Select the Cache group checking checkbox and then specify a Cache lifetime, in seconds. The default value is 1800 seconds (30 minutes).
7
To secure the LDAP connection with SSL, complete the information under LDAP over SSL:

To secure the LDAP connection with SSL, select the Use SSL to secure LDAP connection checkbox.
View your certificate details and verify that the root certificate can be used by the appliance. See Importing CA Certificates for details.
To configure the appliance to verify that the LDAP host name is the same as the name in the certificate presented by the LDAP server, select the Match certificate CN against LDAP server name checkbox. Typically, your server name will match the name specified in its digital certificate. If this is the case with your server, SonicWall recommends enabling this option in a production environment. This makes it more difficult for an unauthorized server to masquerade as your LDAP server if your digital certificate or DNS server is compromised.
8
Optionally, complete the information listed under Advanced.

When an LDAP server cannot answer a client’s query, you can refer it to other LDAP servers by selecting the Enable LDAP referrals checkbox. Use caution when enabling this feature because it can slow down the authentication process. If you are configuring LDAP to authenticate against Microsoft Active Directory, you may want to disable this feature.
In the Server timeout field, type the number of seconds to wait for a reply from the LDAP server. The default value is 60 (one minute).
To change the prompts and other text that Windows users see when they log in to the authentication server, select the Customize authentication server prompts checkbox. The page title, message, and login prompts can all be customized. If users log in using a PIN as a password, for example, change the text for the Proof prompt from Password: to PIN: (a customized Message could explain how to retrieve a forgotten PIN).
You can allow users to change their passwords (in WorkPlace only) by selecting Enable user-initiated password change. If a realm is configured with stacked authentication and requires two sets of username/password credentials, a user who changes his or her password will be changing the credentials for just the first of the two authentication servers.

To allow the LDAP server to notify users that their passwords are going to expire, select the Notify user before password expires checkbox. To also permit them to change their passwords when prompted by the LDAP server, select the Allow user to change password when notified checkbox. The password prompt users see is controlled by the LDAP server.
To enable NTLM authentication forwarding, click one of the Domain authentication forwarding options. For more information, see NTLM Authentication Forwarding.

9
To configure authentication that includes an OTP, enable Use one-time passwords with this authentication server. You must also configure your mail server: if OTPs are going to be delivered to external domains (for example, an SMS address or external webmail address), you may have to configure the SMTP server to allow passwords to be sent from the appliance to the external domain.

Enter the number of characters for the OTP in the Password contains field. The default length is 8, the minimum is 4, and the maximum is 20.
Select the type of characters in the OTP from the drop-down list. Select Alphabetic, Alphabetic and numeric, or Numeric.
In the From address field, enter the email address from which the OTP will be sent.
In the Primary email address attribute box, enter the directory attribute for the email address to which one-time passwords will be sent. If the primary attribute exists on the authentication server, it is used.
The Secondary email address attribute, if specified, is used in addition to the primary email address. The OTP is sent to both addresses.

To have OTPs sent as a text message (instead of an email message), enter the corresponding attribute name (for example, SMSphone instead of Mail or primaryEmail). See Configuring the AD or LDAP Directory Server for more information.

In the Subject field, customize the subject line of the OTP email. You can use the replacement variable {password} to indicate a position in the subject line where the actual password will display.
In the Body field, customize the body of the OTP message. Use the replacement variable {username} to indicate a position in the message where the user’s account name will display. Use the replacement variable {password} to indicate a position in the message where the actual password will display.
To test delivery of an OTP to a user, enter the email address of the user who will receive the OTP into the Email address field and click the Send test message button. If the appliance is able to send the message, the status Message successfully sent is displayed below the button. Failure messages are also displayed below the button, such as errors connecting to the SMTP server, or errors communicating with the AD/LDAP server or looking up the specified user on the AD/LDAP server.
10
Click Save.

Configuring RADIUS Authentication

The appliance can validate username/password or token-based credentials against a RADIUS database. RADIUS authentication configuration options shows typical RADIUS configuration options:

RADIUS authentication configuration options

You must modify your firewall or router to allow the appliance to communicate with your RADIUS server. The RADIUS authentication protocol typically uses port 1645/udp. In addition, you must configure your RADIUS server to include the IP address of the appliance as a RADIUS client (most often referred to as a Network Access Server).

* 
NOTE: Affinity servers should be used only for authentication servers that do not include full group search capabilities, such as RADIUS, RSA, and PKI servers.
Topics:  

Configuring RADIUS with User or Token-Based Credentials

The appliance supports two different types of credentials for RADIUS: username and password, and token-based user credentials, such as SecurID or SoftID, which are validated against a database on a RADIUS server. You can configure the RADIUS authentication method to use either type of credential.

You can also deploy PhoneFactor authentication using RADIUS. When a user logs into their company’s VPN, a RADIUS request is made to the PhoneFactor Agent, which acts as a RADIUS proxy server. It first validates the user name and password with the target RADIUS server before initiating a PhoneFactor authentication. There are two methods for two-factor authentication using PhoneFactor:

The user enters his username and password and is then called by PhoneFactor. The user answers his phone and presses # or enters a PIN.
The user enters his username and password and then PhoneFactor sends him a text message containing a one-time passcode. The user replies to the text message with the passcode, or the passcode and his PIN, to authenticate.
To configure RADIUS for user- or token-based credentials:
1
From the main navigation menu in AMC, click Authentication Servers, and then click New.
2
Under Authentication directory, click RADIUS. The Configure Authentication Server displays.

3
Under Credential type, click Username/Password or Token/SecurID, and then click Continue. For PhoneFactor, select Token/SecurID.
4
In the Name field, type a name for the authentication server.
5
In the Primary RADIUS server field, type the host name or IP address of your primary RADIUS server. If your RADIUS server is listening on a port other than 1645 (the well-known port for RADIUS), you can specify a port number as a colon-delimited suffix (:<port number>).
6
In the Secondary RADIUS server field, type the host name or IP address of your secondary RADIUS server. You can also add a port number if necessary.
7
In the Shared secret field, type the password used to secure communication with the RADIUS server. This must be the same secret that is specified on the designated RADIUS server.
8
In the Match RADIUS groups by list, select the attribute containing the groups of which the user is a member. The value returned from RADIUS will be used in the group portion of the appliance access rule. There are three possible values:
 

RADIUS groups matching

Match RADIUS groups by

Description

None

Ignores the group attribute

filterid attribute (11)

Matches against the FilterID attribute

class attribute (25)

Matches against the Class attribute

9
In the Connection timeout field, type the number of seconds to wait for a reply from the RADIUS server before timing out the authentication attempt. The default is 5 seconds, with a range of 5 to 300 seconds. When using PhoneFactor, increase this value to give users time to receive the confirmation call.
10
Expand the Advanced button to see additional, optional settings; these are described in Configuring Advanced RADIUS Settings.
11
Click Save.

Configuring Advanced RADIUS Settings

To configure additional (optional) RADIUS settings
1
Click the Advanced button to display additional (optional) RADIUS settings.

2
In the Service type field, type a RADIUS Service-Type integer indicating the type of service being requested. For most RADIUS servers, type 1 (for Login; default) or 8 (for Authenticate Only).
3
When a user’s credentials are accepted, the RADIUS server normally sends a confirmation message (for example, Passcode accepted). If you do not want this message displayed, select the Suppress RADIUS success message checkbox.
4
The appliance normally identifies itself using its host name. If the RADIUS server is unable to accept that name, specify a NAS-Identifier or NAS-IP-Address (specifying both is allowed but not typically necessary).
5
To change the prompts and other text that Windows users see when they log in to the authentication server, select Customize authentication server prompts. The page title, message, and login prompts can all be customized. For example, if a user logs in using his employee ID, you could change the text for the Identity prompt from Username: to Employee ID:.

6
If the RADIUS server uses an older version of the RADIUS protocol that does not support UTF-8 character encoding, select a Local encoding scheme from the Selected list, or type one in the Other field. For more information, see RADIUS Policy Server Character Sets.
7
(RADIUS with a Credential type of Username/Password only) To enable NTLM authentication forwarding, click one of the NTLM authentication forwarding options. For more information, see NTLM Authentication Forwarding.

User-Mapped Tunnel Addressing

User-Mapped Tunnel Addressing enables network administrators to identify network traffic from a specific user by the source IPv4 address of the traffic.

On an internal network, administrators may sometimes be able to associate specific end users with specific IPv4 addresses, that are assigned to the user by the administrator.

Although assigning IP addresses to specific users is currently supported through the use of external RADIUS servers, User-Mapped Tunnel Addressing enables administrators to specify the assignment from an attribute in the appliance's local authentication server.

Administrators who deploy a RADIUS server as their authentication server can include an IPv4 address in the RADIUS Framed IP Address parameter for a specific user and associate that user's Community with a RADIUS address pool. This type of assignment can be done only if the address is available and no addressing conflicts prohibit it.

* 
NOTE: If an address conflict prevents this type of assignment, the normal tunnel addressing process continues with the next tunnel in the list that is allowed by the Community. If no more pools are available, the tunnel configuration fails.

The RADIUS Pool in the Configure Network Tunnel Service is now called the User-Mapped Pool. When a RADIUS-framed IP address is available from the authentication server, that address is available to the User-Mapped Pool. An IPv4 address that is provided by a user’s local authentication server, is also available to the User-Mapped Pool and is used exactly the same as if it was from the RADIUS Pool. The User-Mapped Tunnel Addressing feature extends user-mapped addresses to the local user’s authentication server. No other address pools may supply addresses.

More than one address may be obtained from the authentication server, enabling a single user to establish more than one tunnel simultaneously, on separate devices. The number of simultaneous tunnel connections that a single user can establish can be configured by specifying the number of addresses for a user in the authentication server. This value can also be configured by setting the Maximum Active Sessions limit for all users of a particular community on the Configure Community page.

The User-Mapped Tunnel Address Pool, like RADIUS, can be used to provide a strict correspondence (or mapping) between virtual IPv4 addresses and tunnel clients. You can specify that a particular client gets a virtual address from a particular pool on the Network Tunnel Client Settings page. The client is assigned to a specific community and that community only gets IPv4 addresses from a particular address pool.

The User-Mapped Tunnel Address Pool attempts to establish an IPv4 address as the tunnel virtual address at tunnel connect time. If the address is available and no client-side conflicts arise, the virtual address is assigned. If the address fails, then the system proceeds to the next address pool in the list allowed by the community. If no other address pools are available, the tunnel connection attempt fails.

The authentication server used to get IPv4 addresses is not limited to its own authentication server. The User-Mapped Tunnel Address Pool may get addresses from its own authentication server or from the client’s local authentication server

The authentication server may supply an ordered list of IPv4 addresses, not just a single address, so that you can assign multiple simultaneous tunnel connections to a single client, on separate devices.

On the Users & Groups page, on the Add/Edit Local User dialog, under the Advanced section, you can configure the following fields:

Email address
Device identifier(s)
IP address(es)

To edit local users information:
1
In the Email Address field, configure an email address for the user. This address is used for sending one-time passwords to the user, and overrides the default username@domain email address. This email address is assigned to the “mail” attribute for the user.
2
In the Device identifier(s) field, enter one or more (comma-delimited) device identifiers for computers or other devices that are associated with this user.
3
In the IP address(es) field, enter either a single IPv4 address or list of IPv4 addresses (comma-delimited). If you enter a:
Single IPv4 address, each IPv4 address should match the network address of the resource interface.
List of IPv4 addresses, these addresses are presented to the User-Mapped Tunnel Address Pool, in the order they appear in the list.

Configuring RSA Server Authentication

The appliance supports SecurID, token-based user credentials that are validated against a database on an RSA Authentication Manager server. Configuring this type of authentication involves changes on both the RSA server and the SMA appliance, which are outlined below. For step-by-step instructions for RSA Authentication Manager 7.1, see the Knowledge Base article, Configuring RSA Authentication For Use With an E-Class Secure Remote Access Appliance (SW6571).

* 
NOTE: Affinity servers should be used only for authentication servers that do not include full group search capabilities, such as RADIUS, RSA, and PKI servers.
To configure RSA Authentication Manager for token-based credentials:
1
Create an agent host on the RSA server with the IP address for the internal interface of the SMA appliance.
2
Make the configuration changes necessary to resolve the names of both the RSA server and the SMA appliance:
DNS must be able to resolve the RSA server’s name; simply adding the appliance and its IP address to your /etc/hosts file will not work.
The appliance’s name (as configured on the RSA server) must resolve to the internal IP address of the appliance.
3
DNS must be able to resolve the RSA server’s name in both directions:
The appliance’s name (as configured on the RSA server) must resolve to the internal IP address of the appliance; simply adding the appliance and its IP address to your /etc/hosts file will not work.
The RSA server requires a reverse DNS entry for the internal interface of the SMA appliance.
4
After adding the agent host on the RSA server, make sure that you generate the configuration file (sdconf.rec) for the correct agent host.
5
From the main navigation menu in AMC, click Authentication Servers, and then click New.
6
Under Authentication directory, choose RSA; the Credential type is automatically set to Token/ SecurID.
7
Click Continue.
8
In the Name field, type a name for the authentication server.
9
Specify the location of your RSA Authentication Manager server SecurID configuration file, sdconf.rec. This configuration file is in binary format and contains the ports and processes associated with the RSA authentication service. When in place, this file is used by the RSA libraries to communicate over the network to an RSA server.
10
Click Save to upload it to the appliance.
11
The node secret is negotiated when the first authentication request is made from the agent host. Make sure that the node secret created flag is cleared on the RSA server.
* 
NOTE:  
If you make any changes to the RSA server (for example, change its IP address, host name, or re-install it), the sdconf.rec file must be uploaded to the appliance again.
After upgrading some older versions, users may not be able to authenticate through the RSA server because the node secret did not migrate properly. In this case, clear the node secret for the authentication agent on the RSA server.

Configuring a PKI Authentication Server

You can set up a certificate server so that a user authenticates using a client certificate on his or her device. Digital certificate authentication can be used alone or in conjunction with another authentication method, such as RADIUS. (If you set up chained authentication and a digital certificate is one of the methods you use, it must be the first method; for more information, see Configuring Chained Authentication.)

* 
NOTE: Affinity servers should be used only for authentication servers that do not include full group search capabilities, such as RADIUS, RSA, and PKI servers.
* 
NOTE:  
If both CRL and OCSP are enabled for a CA certificate, only OCSP is used.
Fallback from CRL to OCSP or OCSP to CRL is not supported.
When using Internet Explorer 8 and higher to authenticate using PKI with X.509 certificates from WorkPlace, if the certificate is not found on the endpoint, it results in an IE error page. The certificate selection dialog appears only if a valid certificate exists in the client end point; otherwise IE does not prompt for certificate selection.
Connect Tunnel Users Only: Authentication using client certificates is not supported on the Windows 2003 operating system or the Windows Server platform.
To configure a PKI authentication server:
1
From the main navigation menu in AMC, click Authentication Servers.
2
Click New.
3
Under Authentication directory, click Public key infrastructure (PKI). The only possible Credential type is Digital certificate.
4
Click Continue. The Configure Authentication Server page appears.

5
In the Name field, type a name for the authentication server.
6
Under Trusted CA certificates, optionally select the Trust intermediate CAs without verifying the entire chain checkbox. This allows a set of trusted intermediate signing authority certificates to be deployed in various sectors of the network (often by department or organizational unit). For more information, see About Intermediate Certificates.
7
On the left is a list of All CA certificates used by the appliance. Specify one or more root certificates for establishing a trust relationship with the client device by selecting the checkbox to the left of a certificate and then clicking the >> button (a root certificate is one where the Subject and Issuer are the same). A client’s certificate will be trusted if it matches a root certificate listed in the Trusted CA certificates list.
8
Under Advanced, in the Username attribute field, type the attribute used for single sign-on (for example, cn or uid).
9
To use an OCSP responder to determine client certificate status, select the Use OCSP to verify client certificates checkbox. If selected, a user may use any access method (ExtraWeb or Connect Tunnel) to authenticate to a realm that uses this PKI authentication method.
10
Select one of the following options for Use this OCSP responder:
System default – A manually configured OCSP responder has priority. The configured OCSP responder URL is shown here if configured. You can configure it by clicking the here link, which takes you to the OCSP page available from SSL Settings.
User certificate’s AIA extension – The user certificate is parsed to extract the URL of the OCSP responder. The Authority Information Access (AIA) certificate extension contains URL locations that provide the issuing CA’s certificate. The AIA extension can contain HTTP, FTP, LDAP, or FILE URLs.
CA certificate’s AIA extension – The CA certificate is parsed to extract the URL of the OCSP responder.
11
Select the Allow certificate if responder is unavailable checkbox if the authentication should succeed in cases where an error occurs, an unknown status is returned, or the OCSP responder is not available.
12
Select the Trust signing certificates in response checkbox to trust certificates in the OCSP response. This is enabled by default.

You must import the OCSP response signing certificate for the CA certificate being used and enable OCSP response verification when importing it. The OCSP response signing certificate can be copied from the OCSP responder or server to a local management machine and then imported from the SSL Settings page while you are logged in to AMC.

13
Select the Send nonce in request checkbox and Require nonce in response checkbox to guard against malicious replay attacks, in which a successful response is replayed to the client after the subject certificate is revoked.
14
Click Save.

Additional Field for Custom Certificates

The custom SSL client certificate has an additional field to contain an employee ID number (a 10-digit number). This employee ID number can be parsed and passed to an Active Directory authentication server, which will use this additional information to determine the authorization and client access privilege of the client and add that client to the authorized group.

To generate and gain access to SMA with a custom certificate:
1
Create a custom certificate; include the Employee ID number in the custom field.
2
Create a user group on the Active Directory authentication server based on the Employee ID number field.
3
Create an SMA access policy for that user group on the Active Directory authentication server.
4
Configure the Employee ID number field as the SSO username on the Active Directory authentication server.
5
Configure Group Affinity Checking on the Active Directory authentication server.
6
Add the appropriate resources and enable SSO for the configured username.

The custom certificate is assigned to the client with that username and is installed on the client’s device. The client can now use that device to access SMA and all resources that are enabled with SSO for that client.

Configuring a SAML-Based Authentication Server

Security Assertion Markup Language (SAML) is an XML-based framework for communicating user authentication, entitlement, and attribute information. SAML provides a foundation for Web based single sign-on (Web SSO) by allowing business entities to make assertions regarding the identity, attributes, and entitlements of a subject (such as a human user) to other entities, such as a partner company or another enterprise application.

In Web SSO, a user either accesses a resource via a service provider (such as the EX Series appliance), or accesses an identity provider (IDP) such that the service provider and desired resource are understood or implicit. The user authenticates to the IDP, which then produces an authentication assertion and the service provider consumes the assertion to establish a security context for the user. When the security context for the user exists, the user can access resources at another site without additional authentication. SAML also provides a Single Logout (SLO) service.

This release supports external IDPs that are deployed in the public Internet. It is assumed that the user uses a standard browser and can authenticate to the IDP by some means outside the scope of SAML. The user accesses the appliance through a SAML Authenticated Realm.

When configuring the EX Series appliance to use an SAML 2.0 Identity Provider, such as CA SiteMinder, refer to the following configuration information:

The appliance hosts the SAML SSO Service at https://<appliance>/saml2ssoconsumer
The appliance hosts the SAML SLO Service at https://<appliance>/saml2sloconsumer
On the IDP:
HTTP-POST and HTTP-Redirect Bindings should be enabled and configured
SAML SSO and SLO services should be enabled and configured
Encryption of nameIDs and Assertions should be disabled

Configuring a SAML 2.0 Identity Provider Authentication Server

* 
NOTE:  
The SAML 2.0 Identity Provider Authentication Server is supported for Web-based access. Tunnel agents are not supported.
The SAML 2.0 Identity Provider Authentication Server cannot be used for chained authentication.
* 
NOTE: For detailed information on how to configure third party SAML Identity Providers (IDPs), see Configuring SAML Identity Providers.

SAML 2.0 Identity Provider (IDP) provides a centralized security management foundation that enables the secure use of the Web to deliver applications and cloud services to customers, partners, and employees.

SMA has replaced CA SiteMinder with SAML 2.0 Identity Provider, which supports CA siteMinder as well as other IDPs. SAML 2.0 Identity Provider supports the following IDPs:

Microsoft Azure IDP
One Identity Cloud Access Manager
Shibboleth IDP
OneLogin
CA Single Sign-On (CA SiteMinder)
PingIdentity PingOne
CA SiteMinder
To configure a SAML 2.0 Identity Provider authentication server:
1
In the AMC, go to the System Configuration > Authentication Servers page.
2
Click New. The New Authentication Server dialog appears.

3
Under Authentication directory, select SAML 2.0 Identity Provider.
4
Under Credential type, select Username/Password.
5
Click Continue. The Configure Authentication Server page appears.

6
In the Name field, type a name for the authentication server.
7
In the Appliance ID field, enter the SAML entity ID of the appliance. This is a URI of not more than 1024 characters in length.
8
In the Server ID field, enter the SAML entity ID of the IDP server. This is used by the appliance to determine the IDP authentication server identity. This is a URI of not more than 1024 characters in length.
9
In Authentication Service URL, enter the URL where IDP hosts the SAML SSO service.
10
In Logout service URL, enter the URL where IDP hosts the SAML Single Logout (SLO) service.
11
Select the CA certificate for the IDP server from the Trust the following certificate drop-down menu. To configure the CA certificate, you can click the here link in the explanatory text at the right. This CA certificate needs to be imported onto the appliance if it is not there.
12
Select the Sign AuthnRequest message using this certificate checkbox and then select the signing certificate from the drop-down menu. The appliance uses this certificate to sign authentication request messages before sending them to the IDP server. To configure the SSL signing certificate, you can click the here link in the explanatory text at the right. The signing certificate needs to be imported into the appliance if it is not there.
13
Click Save.

Configuring a Single Sign-On Authentication Server

Single sign-on (SSO) allows you to configure the appliance to forward user credentials to back-end Web resources. It also means that the user does not need to log in multiple times (once to get to the appliance, and again to access an application resource).

The appliance supports various types of Web SSO (as a security measure, SSO is disabled by default).

* 
NOTE:  
To use SSO functionality when accessing Web applications during tunnel sessions, you can enable Web resource filtering. See Configuring Web Resource Filtering for more information.
The Web proxy agent does not support single sign-on to back-end Web servers secured with SSL. Links to these resources accessed through the Web proxy agent will not provide single sign-on. To provide either basic authentication or NTLM authentication forwarding to an HTTPS resource, create an alias for the Web resource and then add it as a link in WorkPlace. This forces the appliance to provide translated, custom port mapped, or custom FQDN mapped Web access.
By default, Web content is proxied directly through the appliance for users running OnDemand Tunnel. Select Use Web content translation in the Web shortcut access area of the Configure WorkPlace page in AMC.
Topics:  

Forms-Based Single Sign-On

Many Web applications use forms-based authentication, where the user interface for authentication is a Web form. You can use AMC to set up a single sign-on profile that will forward a user's appliance credentials to a Web application that uses forms-based authentication. There are some built-in profiles that you can modify for your environment:

OWA (multiple versions)
Citrix Nfuse 1.7
Citrix XenApp

See Creating Forms-Based Single Sign-On Profiles for more information.

* 
NOTE: Forms-based SSO is supported only with translation. For other access agents (Web proxy and OD Tunnel) access the backend Web application cookies required for translation are not provisioned to the server.

Basic Authentication Forwarding

This form of authentication forwarding is supported on a wide variety of platforms, but is not very secure because it sends passwords in the clear across the network. The appliance can be configured to send each user’s authentication credentials, or “static” credentials (that is, the same credentials for all users).

To configure basic authentication forwarding:
1
Configure a Web application profile to use SSO and specify which user credentials to use.
2
Attach the Web application profile to any Web resources for which you want to use SSO.

Basic authentication forwarding is configured within a Web application profile. For more information, see Adding Web Application Profiles.

NTLM Authentication Forwarding

NTLM (Windows NT LAN Manager) uses a challenge/response mechanism to securely authenticate users without sending passwords in the clear across the network. It provides a secure method for sending Windows network credentials to a Microsoft IIS (Internet Information Services) Web server.

NTLM authentication forwarding passes a Windows domain name along with the user’s authentication credentials. This enables users accessing Web resources on Windows networks to be securely authenticated without sending their passwords in the clear.

* 
NOTE:  
To use NTLM authentication forwarding in situations in which the credentials do not match, users must be running a Web browser that supports NTLM.
When single sign-on is enabled, the Web proxy service and the back-end server determine which authentication method is used. If only one authentication method (basic authentication or NTLM authentication) is enabled in AMC, that method is used. However, if both methods are enabled in AMC, NTLM authentication is used because it is the more secure of the two.
To configure NTLM authentication forwarding:
1
Enable the SSO options in a Web application profile, and then attach the profile to any Web resources to which you want to forward user credentials.
2
From the main navigation menu in AMC, click Authentication Servers.
3
Click the Edit link for the server you want to configure. The Configure Authentication Server page appears.
4
Expand the Advanced settings.
5
Specify the domain name you want to forward in the Domain authentication forwarding area:

You can type a custom name in the Domain name field, but it is not required. If you do not specify a name, an empty (null) domain name is forwarded, along with the user credentials.
To forward the authentication server name (as specified in the Name field at the top of the page) along with the user credentials, click Forward the authentication server name as domain name.

Using RSA ClearTrust

With single sign-on, user authentication credentials are forwarded to the appliance from an RSA ClearTrust server, and the appliance then forwards the credentials to any back-end resource that requires them for authentication. See RSA ClearTrust Configuration for information on setting up the appliance in this authentication environment.

Legacy and Federated Identity SSO Support with CAM

Topics:  

About Legacy and Federated Identity SSO with CAM

Legacy and Federated Identity SSO with CAM provides unified Single Sign-On (SSO) support for legacy and SAML federated Software as a Service (SaaS) applications using Cloud Access Manager (CAM) as an Identity Provider (IDP).

Legacy and Federated Identity SSO with CAM uses the Federated SSO capabilities and enables the SMA appliance to cooperate with the CAM IDP on the internal corporate network. It also provides transparent SSO to internal and cloud based SAML resources.

Federated Identity SSO supports both SaaS and on-premise applications, such as, Office 365, Google Apps, Salesforce, and Citrix XenApp.

Legacy and Federated Identity SSO with CAM provides legacy application SSO. SMA users only need to log in once. SSO provides the credentials to both the on-premise applications and to the cloud SaaS.

The connection to CAM is made by injecting the authentication credentials into the SAML traffic as it flows through the SMA appliance to the CAM IDP. The CAM IDP generates a SAML token and attaches it to the user's web browser, providing SSO to federated services.

All forms of SMA authentication, including chained authentication in conjunction with SAML SSO, are supported with tunnel agents. This feature enables users, including users that require chained authentication, to authenticate to any authentication realm, instead of only being able to authenticate to the SAML authentication realm.

Legacy and Federated Identity SSO with CAM enables SMA to use its existing authentication systems with Active Directory authentication servers. This can be done individually or in chained authentication. To maintain legacy SSO, SMA injects the user’s credentials into the HTTP or HTTPS traffic stream.

Federated Identity SSO is enabled when SMA presents an IDP proxy to the CAM IDP located on the internal network. The IDP proxy receives all traffic from the user's web browser when the traffic is redirected to the IDP to obtain an SAML or WS-FED token. The IDP proxy injects the user credentials into a login request to the IDP. This allows the CAM IDP to generate SAML and WS-FED tokens without user interaction.

This feature enables users to use their SMA credentials for SSO to legacy applications in the corporate network as well for highly integrated hybrid deployments with public cloud and private cloud federated applications.

For this to work, the SMA and CAM IDP must be using the same authentication store as the master user credential repository.

Legacy and Federated Identity SSO with CAM traffic flows shows how traffic flows in a typical deployment.

Legacy and Federated Identity SSO with CAM traffic flows

The SMA appliance is a service that uses its own connection to the internal authentication server for its own users and for legacy SSO. It uses CAM to provide both SAML and WS-FED SSO for SaaS applications.

The SMA appliance is well suited for this purpose because it is designed to provide secure access to services on the corporate network from anywhere on the Internet. It can broker requests to SaaS applications located in the cloud via this same central enforcement point policy, utilizing the same VPN session with the end user.

Users authenticate first to the SMA Appliance through the existing non-SAML realm. An IDP Proxy is then configured to send traffic to the internal CAM IDP. This injects the authentication credentials for the user as needed. Thus SAML and WS-FED tokens can be generated by CAM without user interaction, allowing both legacy SSO and federated SSO access to both internal and external application servers.

Legacy and Federated Identity SSO with CAM user authentication shows how a user is authenticated.

Legacy and Federated Identity SSO with CAM user authentication

Configuring SSO with CAM

You can configure SMA to inject a Cloud Access Manager (CAM) into a VPN session when the Single Sign-On (SSO) service accesses the federated identity resource. Keep these restrictions in mind:

SMA and CAM must both use the same Authentication Server for SSO credentials.
SAML 2.0 federated Single Sign-On does not currently work with the Global Traffic Optimizer (GTO), it is available only for stand-alone single appliances.
To configure SSO with CAM:
1
Go to the Configure Realm > Remote Access > General page.
2
In the Advanced panel, select the checkbox for Enable SAML 2.0 federated single sign on.

3
In the External identity provider name field, enter the FQDN of the CAM IDP proxy service on the SMA appliance. The External identity provider name for:
Non split DNS should be different from the host name of the CAM.
Split DNS should be the same as the host name of the CAM.
4
In the Hostname of the Cloud Access Manager field, enter the FQDN of the name that the CAM is known by on the internal network.

When the checkbox for Enable SAML 2.0 federated single-sign on is selected, the App Configuration link is available. In this case, SMA is a transparent IDP proxy that service providers use for authentication services that are relayed to the CAM.

You can click App Configuration to view these three URLs that are necessary for a SAML Service Provider to authenticate through a SAML IDP:

Server ID: urn:external_idp.example.com/CloudAccessManager/RPSTS
Logon URL: https://external_idp.example.com/CloudAccessManager/RPSTS/Saml2/Default.aspx
Logoff URL: https://external_idp.example.com/CloudAccessManager/RPSTS/Saml2/Logout.aspx

Using RSA ClearTrust Authentication

The SMA appliance supports authentication by accepting credentials in an RSA ClearTrust authentication environment. Users can authenticate through the RSA ClearTrust server only when connecting using a Web browser.

RSA ClearTrust Authentication sequence shows the typical sequence of events as a user logs in to authenticate in an RSA ClearTrust environment:

RSA ClearTrust Authentication sequence

1
The user enters the URL for WorkPlace and picks a ClearTrust realm from the drop-down menu. If you’ve configured only one realm for users, it is automatically selected.
2
The SMA appliance forwards the request to the appropriate Web agent. The ClearTrust Web agent is on a separate ClearTrust-enabled Web server that you specified in AMC.
3
The Web agent checks with the ClearTrust policy server and displays the corresponding authentication page, prompting the user for credentials.
4
The user's credentials are forwarded to the Web agent, which validates them against its policy server.
5
The user is either authenticated or denied access. If authentication is successful, the credentials are saved in a cookie and the user has access to VPN resources during the WorkPlace session.

RSA ClearTrust Configuration

To configure RSA ClearTrust to authenticate users, you must specify the URL of the external server because the appliance does not host the ClearTrust agent. Configuration also requires using AMC to export a .zip file containing a private key and CGI script, both of which must be installed on the ClearTrust-enabled Web server.

* 
NOTE: When installing the CGI script file on an RSA ClearTrust-enabled Web server, you must ensure that the file’s owner, group, and permissions are set appropriately for that server.
To configure the RSA ClearTrust authentication:
1
From the main navigation menu in AMC, click Authentication Servers.
2
Click New.
3
Under Single sign-on server, click RSA ClearTrust (only one ClearTrust server can be specified; if one has already been configured, this option is dimmed).
4
Click Continue. The Configure Authentication Server page appears.
5
In the Name field, type a name for the authentication server.
6
In the ClearTrust server URL field, type the URL of the Web server that hosts the ClearTrust agent. If the ClearTrust-enabled Web server is listening on a port other than the default of 636, you can specify a port number as a colon-delimited suffix. If you want to use a secure SSL connection, include the https:// protocol identifier in this box.
7
A private key and CGI script must be installed on the RSA ClearTrust server, or the computer on which the RSA ClearTrust Web agent is installed. Click Export to save these items in a .zip file (with a default name of ctAgent.zip), then install them as follows:
The private key file (named webagent.key) must be available on the RSA ClearTrust server in the /usr/local/webagent directory. The computer on which the RSA ClearTrust Web agent is installed should have openssl libraries in the /usr/lib directory. Or, at a minimum, the libraries libssl.so.0.9.7 and libcrypto.so.0.9.7 should be available in the same directory.
The CGI script must be placed in the /cgi-bin directory of the RSA ClearTrust server.
8
Click Save.

One Identity Defender

Defender is a product for 2-factor authentication. SMA supports One Identity Defender configuration as a generic RADIUS server.

To configure a new Authentication Server with One Identity Defender:
1
Log in to AMC.
2
Go to System Configuration > Authentication Servers.

3
Click on New. The New Authentication Server dialog appears.

4
Select the One Identity Defender option.
5
Under Credential Type, select either Token/SecurID or Username/Password.
6
Click Continue. The Configure Authentication Server dialog appears.

7
In the Name field, enter a name for the authentication server.
8
In the Primary Defender server field, enter the IP address of the primary defender server.
9
In the Secondary Defender server field, enter the IP address of the secondary defender server.
10
In the Shared Secret field, enter your shared secret.
11
From the Match Defender user groups by drop-down menu, select:
None (default)
filterid attribute (11)
class attribute (25)
12
In the Connection timeout field, enter the connection timeout value, in seconds.
13
Click Save.

Configuring Local User Storage

You can create local user accounts in AMC and then map them to a local authentication repository. For information on creating local user accounts, see Managing Local User Accounts.

Only one local user store can be created on the appliance.

To configure local user authentication:
1
From the main navigation menu in AMC, click Authentication Servers.
2
Click New.
3
Under Local user storage, click Local users (if a local store already exists, this option is dimmed).
4
Click Continue. The Configure Authentication Server page appears.
5
In the Name field, type a name for the authentication server.
6
In the Password policy area, specify the minimum and maximum number of characters allowed for passwords. The minimum can be as few as 4, and the maximum can be as many as 256.
7
Select the Lowercase letters checkbox to specify that user passwords must contain at least one lowercase character.
8
Select the Uppercase letters checkbox to specify that user passwords must contain at least one uppercase character.
9
Select the Numeric digits checkbox to specify that user passwords must contain at least one number (0-9).
10
Select the Symbols checkbox to specify that user passwords must contain at least one symbolic character ( ~`!@#$%^&*()_-+={}[]|\:;"'<,>.?/ ).
* 
NOTE: UTF-8 characters are supported in the password.
11
In the Password expiration area, select the Passwords expire after checkbox. Clear the checkbox to allow user passwords to never expire.
Enter the number of days after which user passwords will expire.he default is 60 days, the minimum is 1 day, and the maximum is 365 days.
12
Select the Begin prompting user checkbox and enter the number of days before expiration that the user will be prompted to change the password. The default is 14 days.
13
To change the prompts and other text that Windows users see when they log in, expand the Advanced section.
14
Select the Customize authentication server prompts checkbox.

The page title, message, and login prompts can all be customized. For example, if an employee ID number is used to identify a user, you could change the text for the Identity prompt from Username: to Employee ID:. If this configuration is being used for testing, a customized Message could point to test procedures or other instructions.

15
Enter the password or other proof of identity into the Proof field.
16
In the One-Time Passwords area, to configure two-factor authentication with one-time passwords, select Use one-time passwords with this authentication server.
17
Define the password format by entering the number and type of characters into the Passwords contain field.
18
In the From address field, enter the email address from which one-time passwords will be sent.
19
In the Default domain field, optionally enter the domain to be appended to each username to create an email address for local users to which one-time passwords will be sent.
20
You can override the default domain by configuring an email address for each local user in the Email Address field. This email address will be available as a User attribute type policy variable named primaryEmail. One email address per user is supported.
21
Click the Send test message button to send a test email message to verify that the message, password, and SMTP settings are correct.
22
In the Subject field, enter the text for the subject line when e-mailing the one-time password.
23
In the Body field, enter the content of the email that will contain the one-time password.

For more information about one-time passwords, see Using One-Time Passwords for Added Security.

24
Click Save.

Testing LDAP and AD Authentication Configurations

To help you validate your authentication configuration settings, the AMC pages used to configure Microsoft Active Directory and LDAP servers include a Test button. Clicking this button establishes a connection with your external user repository and provides status information.

If you have correctly configured the appliance, a message reading Valid connection! appears. If there is an error in the configuration settings, the message provides a description of the problem.

* 
NOTE: The test connection feature is intended only for testing whether the appliance can bind to an external directory. If you enter login credentials, the appliance will use them, but it will otherwise attempt to bind to the directory anonymously. Because it does not actually search the directory, testing a connection will not validate that your login credentials provide access to the configured domain.

Configuring Chained Authentication

For increased security, you can require users to authenticate to a single realm using two different authentication methods. For example, you could set up RADIUS or a digital certificate as the first authentication method, and LDAP or Active Directory as the second one. The local authentication store can be used as either the primary or secondary authentication server. You can require that the user names are the same on the primary and secondary authentication servers. To make the login experience for your users a one-step process you can configure AMC such that users see only one set of prompts.

To configure chained authentication:
1
From the main navigation menu in AMC, click Realms.
2
Click either:
The name of the realm you want to modify.
New and then select an entry in the Authentication server drop-down menu.

This is your primary authentication server.

If one of your credential types for chained authentication is a digital certificate, the corresponding authentication server must be the primary one: you can’t configure a PKI server as your secondary authentication server.

3
Click Advanced and scroll to the Chained authentication section.

4
Select a Secondary authentication server (if none is defined, click New; see Configuring Authentication Servers for the steps involved in setting up an authentication server).
5
The remaining (optional) settings, listed in Authentication settings, can provide more security, help with troubleshooting, and simplify the login process:
 

Authentication settings

Setting

Description

Audit username from this server

Show the username from the secondary server in the audit and accounting logs (instead of the username from the primary authentication server).

Forward credentials from this server

For single sign-on, one set of credentials must be forwarded to back-end Web resources. Select this checkbox to forward the credentials from this (the secondary) authentication server.

Usernames must match

When this checkbox is selected, authentication will fail if the user ID submitted for the first authentication step differs from the user ID submitted in the second step. This option is available when the authentication methods use either a username/password or a token or certificate.

One use case for this option is when the primary authentication server uses a certificate and the secondary uses a username/password. Without this option enabled, an end user could log in with another user's certificate if the first user had valid credentials. When this setting is turned on, that authentication attempt would fail because the username in the certificate would not match the username in the username/password credentials.

Combine authentication prompts on one screen

When this checkbox is selected, the appliance verifies that the username is the same on both authentication servers. If it is, the prompts for a user’s credentials are combined on a single screen; if the usernames differ, the login is rejected and (for security reasons) there is no error message explaining why.

Authentication prompts cannot be combined if user credentials involve a digital certificate, though the system still ensures that the username is the same on both servers.

Customize authentication server prompts

(Available only when Combine authentication prompts on one screen is selected, and only for Windows clients.)

When configuring an authentication server, you have the option of customizing the prompts that users see. When two such servers are chained together, you can present the user with a combined authentication prompt that includes customized Title, Message, and Identity fields. The name for the password fields is picked up from each authentication server configuration.

If this customization setting is not selected, the user sees the prompts that are configured for the two authentication servers.

Chained Authentication Login Example

In this example, the system administrator has set up two authentication methods for a realm named Employees:

The primary authentication server uses RADIUS; the Proof prompt (on the Configure Authentication Server page, under Advanced settings) was customized to read Passcode.

The secondary authentication server uses LDAP; the Proof prompt was customized to read Remote access password.

The Advanced settings on the Configure Realm - Employees page show customized Title, Message, and Identity prompts.

Based on these AMC settings, the login screen that users see would look like this:

Because the user names on both authentication servers are the same, the user types his or her username only once.

* 
NOTE:  
If the user makes an error while entering username or password information, an error message appears (The credentials provided were invalid) and only the prompts for the secondary authentication server are displayed. To re-enter his or her credentials, the user must first go to the original login page by clicking the browser’s Back button.
When a username and password are used for both authentication methods, the usernames do not need to be the same (although they typically are). If the primary username is mapped to a role in AMC, such as the AMC Administrator Role, the secondary username does not need to be assigned to the same role. If authentication succeeds on both servers for both usernames, the user is granted access corresponding to the role of the primary username.

Enabling Group Affinity Checking in a Realm

The appliance supports group affinity checking, a network environment in which a user authenticates against one server, and a second directory provides information on what groups (if any) a user belongs to. This is a common requirement when RADIUS SecurID tokens are used for authentication but the user’s group information comes from an LDAP or Active Directory server. (In contrast, chained authentication requires users to authenticate against two authentication servers. See Configuring Chained Authentication for more information.)

Group membership is an important part of access control: you can set up the appliance to reference user groups stored in your directory, and then reference those groups in access control rules.

* 
NOTE: When an Active Directory (AD) server is used as an LDAP server, ACL checks cannot be performed. Short names (SN) or common names (CN) are not supported on LDAP servers. They are only supported on AD servers.
To enable group affinity checking:
1
From the main navigation menu in AMC, click Realms.
2
Click the name of the realm you want to modify.
3
Click Advanced. In the Group authorization area, select the Enable group affinity checking checkbox.

4
in the Server drop-down menu, select the name of the LDAP or Active Directory server that stores the group information. You can also click New to define a new group affinity server.

If group authorization checking is disabled for an authentication server, the server will not appear in the list of available affinity servers. See Disabling Authorization Checks for more information.

5
Click Save.

If you are enabling group affinity checking during the process of creating the realm, the available buttons are different:

Click Next to display the Communities tab on the Configure Realms page.
Click Finish to return to the Authentication page.

Using One-Time Passwords for Added Security

A one-time password (OTP) is a randomly generated password that is used only once. Using an OTP as the second factor for authentication provides additional security for users: after standard user name and password credentials are submitted, the system generates a one-time password, which is sent to the user at a predefined SMS or email address. The user then logs in to that email account to retrieve the OTP and enters it when prompted. The likelihood of the password being compromised is reduced because a new OTP is generated after each successful, cancelled, or failed login, or when a login attempt has timed out.

To configure authentication that includes an OTP, you must do the following:

Configure your mail server. If one-time passwords are going to be delivered to external domains (for example, an SMS address or external webmail address), you may have to configure the SMTP server to allow passwords to be sent from the appliance to the external domain.
Configure an OTP in the Advanced area of the authentication server configuration. Specify the directory attributes that store the email addresses to which OTPs are sent.
Topics:  

Configuring SMTP to Deliver One-Time Passwords

If the email addresses to which you want to deliver one-time passwords are in an external domain (such as SMS addresses or external web mail addresses), you must configure your SMTP server to allow passwords to be sent from the appliance to the external domain.

To configure Microsoft Exchange to support one-time passwords:
1
Navigate to Exchange System Manager.
2
Expand Servers > Protocols > SMTP.
3
Right-click on either Default SMTP Virtual Server or the appropriate SMTP server instance.
4
Click Properties.
5
Select the Access tab.
6
Click Relay in the Relay Restrictions area.
7
Select Only the list below.
8
Click Add.
9
Enter the IP address of your SMA appliance (for example, 10.50.165.5).
10
Click OK. Your appliance should be listed with a status of Access Granted.
11
Click OK.

Configuring an Authentication Server for One-Time Passwords

If the email addresses to which you want to deliver one-time passwords are in an external domain (such as SMS addresses or external web mail addresses), you must configure your SMTP server to allow passwords to be sent from the appliance to the external domain, as described in Configuring SMTP to Deliver One-Time Passwords.

For each authentication server, you must also specify the directory attribute that stores the email addresses to which OTPs are sent. You must specify a primary attribute; alternatively, you can specify a secondary attribute that is queried when the first one cannot be found.

To configure an authentication server to support one-time passwords:
1
From the main navigation menu in AMC, click Authentication Servers.
2
Click Edit next to the AD (Microsoft Active Directory or Microsoft Active Directory Tree), LDAP, or local authentication server you want to reconfigure.
3
Select a Credential type, if applicable.
4
Click Continue.
5
Expand the Advanced area,
6
Select Use one-time passwords with this authentication server.
7
Enter the directory attribute for the email address to which one-time passwords will be sent. If the primary attribute exists on the authentication server, it is used, otherwise the secondary attribute, if specified, is queried.

Configuring the AD or LDAP Directory Server

The schema for your AD or LDAP directory server must include an attribute that contains the email address to which a one-time password will be sent. The local authentication store uses the primaryEmail attribute, which can be configured per user by editing the local user account. See Managing Local User Accounts.

This address is not necessarily the user’s corporate email address. In order to complete authentication, a user has to be able to open the email containing the OTP; if it is sent to a corporate address the user may not yet have access to the account.

One-time passwords can be configured to be sent in an email message directly to SMS-capable phones. Contact your cell phone service provider for further information about enabling SMS.

The schema for your directory server (AD or LDAP) must be changed to accommodate an attribute (for example, SMSphone) that contains the SMS address for a given user. The address that you use depends on the user’s number and service provider. The attribute value for a Verizon phone with a U.S. domestic number, for example, looks like this: <10-digit number>@vtext.com.

Configuring Personal Device Authorization

With Personal Device Authorization users connecting to the corporate network with a personal device that is not registered with the appliance are prompted to register the device. They must agree to the personal device corporate policies and privacy policies to access corporate resources.

After the user consents to the corporate policies for a device, the device’s unique Device ID is determined and the appliance registers the device to the user. Subsequent connections from this device do not require device authorization.

In addition, you can monitor usage of personal devices that have accessed the appliance, as explained in Viewing User Access and Policy Details

To create an Application Zone for Personal Device Authorization:
1
In the Zones page, select Application zone from the Filters Type drop-down menu, and then click Refresh. All application zones display.

2
Click on any application zone to display Device profiles. Only those profiles that are Application Access Control aware are included in the profiles.

3
In the All Application Zone Profiles list, select the checkbox for any profiles that you want to require in the zone.
4
Click the right arrow (>>) button. Only one of the profiles in the In Use list needs to match for the application to be placed in the zone you are creating.

If there are no device profiles for this zone, click New to add one.

5
Expand Device authorization.

6
Check the top checkbox in the Device Authorization area to require users to authorize their personal device before a VPN connection is established. By default, this checkbox is checked when EPC is enabled for application zones.
7
To change the authorization terms that users must agree to, type the desired authorization terms in the Terms section of the Device Authorization area. The Device Authorization checkbox must be checked to edit the terms.
8
By default, a user authorization expires 180 days after the device was last used. When device authorization is enabled, you can disable zone authorization expiration by unchecking the expiration checkbox or change the number of days before expiration by typing the desired number of days.
9
By default, user connections to a zone are not dropped when the connection is inactive. However, a inactivity timer can be set In the Inactivity timer area to end the connection after a set period of inactivity. The inactivity timer interval can be set from 3 minutes to 10 hours.
10
Add the zone to a community as explained in Using End Point Control Restrictions in a Community.

Biometric Identification

Topics:  

About Biometric Identification

This feature provides the option to use biometric identification to unlock cached credentials on Mobile Connect devices.

Credential caching allows the user to establish a connection to the SMA appliance without having to reenter authentication credentials. Credential caching provides convenience, but it could allow an unauthorized user to access a corporate network if the user device is used by someone other than the owner. Biometric identification can be used to control who can access these cached credentials.

With biometric identification, a user can use a face or fingerprint to unlock their cached credentials.

Administrators can enable biometric identification on iOS devices and Android devices. End users can choose to require biometric identification in addition to their cached credentials for authentication.

Administrators can:

Choose to enable credential caching.
Choose to allow certain types of clients (iOS, Android, or both) to use credential caching.
Choose to allow credential caching only in conjunction with biometric identification.

You can prevent any user from using another person’s biometric identification to access a corporate network by disabling biometric identification for that user in their configuration settings. We recommend that you include a Terms-of-Use statement that states that a device using biometrics to unlock cached credentials only contains biometric signatures for the individual whose credentials are cached. With this feature, you can only use biometric identification to unlock cached credentials, and then use the cached credentials for authentication.

Configuring Biometric Identification

You can configure biometric identification using the SMA user interface (UI).

To enable Allow Biometric ID:
1
On the SMA appliance, go to Realms > Configure Community > Access Methods > Network Tunnel Client Configure > Connect Tunnel > User interface > Use cached credentials page.
2
Select one of the following options:
a
Always - Always use cached credentials
b
At user's discretion - choose no caching, biometric unlock required, or auto login from cache.
c
Only with biometric verification - Only use credential caching when biometric verification is supported and enabled. Cached credentials are only used after biometric identification verification.
3
If you selected Only with biometric verification, choose at least one of the following options:
a
Touch ID - on iOS devices
b
Fingerprint authentication - on Android devices
c
Never - Never use cached credentials
 

Using APIs in the Command Line Interface (CLI)

You can get the current state of the biometric identification, and enable and configure biometric identification in the Command Line Interface (CLI) using the following APIs.

Attribute(s): autoCredentialLogon: require_biometrics
Attribute(s): clientSettings

Refer to these SMA 12.0.1 API guides:

Secure Mobile Access Authentication API
Secure Mobile Access Appliance Management Console Setup API
Secure Mobile Access Appliance Management Console API

Next Steps

After you have performed the basic network setup, obtained an SSL certificate for the appliance, and configured authentication settings, you are ready to start managing users and user groups, defining resources, and configuring access control rules.