• 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. (Dell 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 check box for three ADS realms, but clear it for a fourth, the functionality would be disabled for all four realms.

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.

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

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

Here are a few LDAP configuration examples.

Example 1—Active Directory

Example 2—Active Directory

Example 3—LDAP with Domino Server

Configuring LDAP and LDAPS Authentication

The E-Class SRA appliance supports authentication using the LDAP or LDAPS (LDAP over SSL) protocols. Either protocol can be used to validate username and password credentials. The following illustration shows typical LDAP 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.

• 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.

Related Topics

• Configuring LDAP with Username and Password

• Configuring a PKI Authentication Server

• Importing CA Certificates

• About Intermediate Certificates

Configuring LDAP with Username and Password

Perform the following steps to configure an LDAP authentication server with username and password validation.

To configure LDAP for username/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 box, type a name for the authentication server.

5. Complete the information listed under General:

– In the Primary LDAP server box, 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 box.

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 box, type the distinguished name (DN) used to establish a connection with the LDAP server.

– In the Password box, type the password used to establish a connection with the LDAP server.

– In the Search base box, 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 box, 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 check box. When this box is unchecked, the nested controls are disabled because they apply only to group checking behavior. This check box, 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 check box and then type the Group attribute. This attribute is most often memberOf. Do not select this check box 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 check box; to specify the depth of the search (how many sub-groups to include in the search), enter a number in the Nested group lookup check box. 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 check box 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 check box.

– 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 check box. Typically, your server name will match the name specified in its digital certificate. If this is the case with your server, Dell 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 check box. 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 box, 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 check box. 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 check box. To also permit them to change their passwords when prompted by the LDAP server, select the Allow user to change password when notified check box. The password prompt users see is controlled by the LDAP server.

– To enable NTLM authentication forwarding, click one of the NTLM 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.

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 check box 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.

Configuring RADIUS Authentication

The appliance can validate username/password or token-based credentials against a RADIUS database. The following illustration shows typical RADIUS 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.

Related Topics

• Configuring RADIUS with User or Token-Based Credentials

• Configuring Advanced RADIUS Settings

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.

3. Under Credential type, click Username/Password or Token/SecurID, and then click Continue. For PhoneFactor, select Token/SecurID.

In the Name box, type a name for the authentication server.

5. In the Primary RADIUS server box, 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.

6. In the Secondary RADIUS server box, type the host name or IP address of your secondary RADIUS server. You can also add a port number (:<port number>) if necessary.

7. In the Shared secret box, 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:

9. In the Connection timeout box, 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

For further customizing and configuring, use these advanced RADIUS settings.

To configure additional (optional) RADIUS settings

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

In the Service type box, type a RADIUS Service-Type integer indicating the type of service being requested. For most RADIUS servers, type 1 (for Login) 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 check box.

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 box. 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.

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 E-Class SRA appliance, which are outlined below. For step-by-step instructions for RSA Authentication Manager 7.1, see Knowledge Base article 6571:

http://www.E-Class SRA.com/us/support/kb.asp

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 E-Class SRA appliance.

2. Make the configuration changes necessary to resolve the names of both the RSA server and the E-Class SRA 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 E-Class SRA 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.

If the appliance is part of an HA pair, generate a single sdconf.rec for both servers. When you generate the configuration file you are prompted to specify the agent host: choose all or range (range should contain both of the HA appliances). Choose individual only if you are setting up a single appliance.

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. Click Continue.

In the Name box, type a name for the authentication server.

8. Specify the location of your RSA Authentication Manager server SecurID configuration file, sdconf.rec, and then click Save to upload it to the appliance.

This configuration file is in binary format and contains the ports and processes associated with the RSA authentication service. Once in place, this file is used by the RSA libraries to communicate over the network to an RSA server.

9. 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.

To configure a PKI authentication server

1. From the main navigation menu in AMC, click Authentication Servers, and then click New.

2. Under Authentication directory, click Public key infrastructure (PKI). The only possible Credential type is Digital certificate.

3. Click Continue. The Configure Authentication Server page appears.

In the Name box, type a name for the authentication server.

5. Under Trusted CA certificates, optionally select the Trust intermediate CAs without verifying the entire chain check box. 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.

6. On the left you’ll see 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 check box 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.

7. Under Advanced, in the Username attribute box, type the attribute used for single sign-on (for example, cn or uid).

8. To use an OCSP responder to determine client certificate status, select the Use OCSP to verify client certificates check box. If selected, a user may use any access method (ExtraWeb or Connect Tunnel) to authenticate to a realm that uses this PKI authentication method.

9. 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.

10. Select the Allow certificate if responder is unavailable check box if the authentication should succeed in cases where an error occurs, an “unknown” status is returned, or the OCSP responder is not available.

11. Select the Trust signing certificates in response check box 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.

12. Select the Send nonce in request check box and Require nonce in response check box to guard against malicious replay attacks, in which a successful response is replayed to the client after the subject certificate is revoked.

13. Click Save.

Note•: If the CA certificate that you trust for this method of user authentication is not shown in the list, you may need to add it. See Importing CA Certificates.

• 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.

• 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.

 

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. Once 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 a SAML IDP, such as a CA SiteMinder IDP, 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 CA SiteMinder Authentication Server

CA SiteMinder 12.0 is supported in conjunction with SAML 2.0. CA SiteMinder 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.

To configure a CA SiteMinder authentication server

1. From the main navigation menu in AMC, click Authentication Servers, and then click New.

2. Under Authentication directory, click CA SiteMinder.

Username/Password is automatically selected; it is the only option under Credential type.

3. Click Continue. The Configure Authentication Server page appears.

In the Name field, type a name for the authentication server.

5. 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.

6. In the Server ID field, enter the SAML entity ID of the SiteMinder server. This is used by the appliance to determine the SiteMinder authentication server identity. This is a URI of not more than 1024 characters in length.

7. In Authentication Service URL, enter the URL where SiteMinder hosts the SAML SSO service.

8. In Logout service URL, enter the URL where SiteMinder hosts the SAML Single Logout (SLO) service.

9. Select the CA certificate for the SiteMinder server from the Trust the following certificate drop-down list. 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.

10. Select the Sign AuthnRequest message using this certificate check box and then select the signing certificate from the drop-down list. The appliance uses this certificate to sign authentication request messages before sending them to the SiteMinder 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 onto the appliance if it is not there.

11. Click Save.

Note•: The CA SiteMinder Authentication Server is supported for Web-based access. Tunnel agents are not supported.

• The CA SiteMinder Authentication Server cannot be used for chained authentication.

 

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.

 

Related Topics

• Forms-Based Single Sign-On

• Basic Authentication Forwarding

• NTLM Authentication Forwarding

• Using RSA ClearTrust Authentication

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.

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. Specify the domain name you want to forward in the NTLM authentication forwarding area:

You can type a custom name in the Domain name box, 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 box at the top of the page) along with the user credentials, click Forward the authentication server name as domain name.

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.

 

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.

Using RSA ClearTrust Authentication

The E-Class SRA 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.

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

 

 

1. The user enters the URL for WorkPlace and picks a ClearTrust realm from the drop-down list. If you’ve configured only one realm for users, it is automatically selected.

2. The E-Class SRA 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.

Related Topics

• RSA ClearTrust Configuration

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.

To configure the RSA ClearTrust authentication

1. From the main navigation menu in AMC, click Authentication Servers, and then click New.

2. 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).

3. Click Continue. The Configure Authentication Server page appears.

In the Name box, type a name for the authentication server.

5. In the ClearTrust server URL box, 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.

6. 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.

7. Click Save.

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.

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, and then click New.

2. Under Local user storage, click Local users (if a local store already exists, this option is dimmed).

3. Click Continue. The Configure Authentication Server page appears.

In the Name box, type a name for the authentication server.

5. In the Password policy area, specify the minimum and maximum number of characters allowed for passwords. The minimum can be as low as 4, and the maximum can be up to 256.

6. Select the Lowercase letters check box to specify that user passwords must contain at least one lowercase character.

7. Select the Uppercase letters check box to specify that user passwords must contain at least one uppercase character.

8. Select the Numeric digits check box to specify that user passwords must contain at least one number (0-9).

9. Select the Symbols check box to specify that user passwords must contain at least one symbolic character ( ~`!@#$%^&*()_-+={}[]|\:;"'<,>.?/ ).

Note UTF-8 characters are supported in the password.

10. In the Password expiration area, select the Passwords expire after check box and enter the number of days after which user passwords will expire. Clear the check box to allow user passwords to never expire. If selected, the default is 60 days, the minimum is 1 day, and the maximum is 365 days.

11. Select the Begin prompting user check box and enter the number of days before expiration that the user will be prompted to change the password. The default is 14 days.

12. To change the prompts and other text that Windows users see when they log in, expand the Advanced section and select the Customize authentication server prompts check box.

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.

13. Enter the password or other proof of identity into the Proof field.

14. In the One-Time Passwords area, to configure two-factor authentication with one-time passwords, select Use one-time passwords with this authentication server.

15. Define the password format by entering the number and type of characters into the Passwords contain field.

16. In the From address field, enter the email address from which one-time passwords will be sent.

17. 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.

18. 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.

19. Click the Send test message button to send a test email message to verify that the message, password, and SMTP settings are correct.

20. In the Subject field, enter the text for the subject line when e-mailing the one-time password.

21. 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.

22. 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 Connection 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 the name of the realm you want to modify, or click New and then select an entry in the Authentication server drop-down list. 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 then 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).

4. The remaining (optional) settings can provide more security, help with troubleshooting, and simplify the login process:

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 for­warded to back-end Web resources. Select this check box to forward the credentials from this (the secondary) authentication server. Usernames must match When this check box 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 meth­ods use either a username/password or a token or cer­tificate. One use case for this option is when the primary authentication server uses a certificate and the second­ary 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/pass­word credentials. Combine authentication prompts on one screen When this check box 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 sys­tem 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 Win­dows 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 configura­tion. If this customization setting is not selected, the user sees the prompts that are configured for the two authentication servers.

Related Topics

• Chained Authentication Login Example

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.

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

 

Because the usernames 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.

• Chained authentication is not supported when connecting to the appliance by launching the Virtual Assist Technician client. When you start the Virtual Assist Technician client and connect to the appliance, a drop-down list of Domains is available when chained authentication is enabled. The Management Console domain (realm) is used for logging in to AMC with chained authentication. (If chained authentication is not enabled, you log in to AMC with an external authentication server.) The other domain is displayed as Management Console - Legacy. The Virtual Assist technician can log in to the legacy admin account. See Adding/Editing Legacy Local Administrator Accounts.

 

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.

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 check box.

in the Server list, 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.

In order 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.

Related Topics

• Configuring SMTP to Deliver One-Time Passwords

• Configuring an Authentication Server for One-Time Passwords

• Configuring the AD or LDAP Directory Server

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 webmail 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 and expand Servers > Protocols > SMTP.

2. Right-click on Default SMTP Virtual Server, or the appropriate SMTP server instance.

3. Click Properties, and then select the Access tab.

4. Click Relay in the Relay Restrictions area.

5. Select Only the list below, and then click Add.

6. Enter the IP address of your SRA E-Class appliance (for example, 10.50.165.5), and then click OK. Your appliance should be listed with a status of Access Granted.

7. 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, and then click Edit next to the AD (Microsoft Active Directory or Microsoft Active Directory Tree), LDAP, or local authentication server you want to reconfigure.

2. Select a Credential type, if applicable, and then click Continue.

3. Expand the Advanced area, and then select Use one-time passwords with this authentication server.

4. 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.

Once 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, the Administrator can monitor usage of personal devices that have accessed the appliance, as explained in Viewing User Access and Policy Details

Perform the following steps to create an Application Zone for Personal Device Authorization:

1. In the Zones section select Application zone from the drop-down list. The Zone Definition - Application Zone page appears.

 

Only those profiles that are Application Access Control aware are included in the profiles.

2. In the All Application Zone Profiles list, select the check box for any profiles that you want to require in the zone, and then 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.

3. If there are no device profiles for this zone, click New to add one. See the Secure Mobile Access Administrator Guide for more information on creating profiles.

4. Check the top check box in the Device Authorization area to require users to authorize their personal device before a VPN connection is established. By default, this check box is checked when EPC is enabled for application zones.

Note Device authorization is not supported by ActiveSync clients. Device authorization should not be enabled in zones that allow ActiveSync clients.

5. 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 check box must be checked to edit the terms.

6. 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 check box or change the number of days before expiration by typing the desired number of days.

7. 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.

8. Add the zone to a community as explained in Using End Point Control Restrictions in a Community.

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.