Author: Gaurav Vaidya
It has become an inevitable need for large enterprises to deploy self service password management solutions for their users, in order to provide convenience for end users and also reduce the helpdesk costs resulting from password related calls. In addition to helping users reset passwords the password management solutions can also enforce secure password policies across the organization. Novell Self Service Password Reset (SSPR) is one such latest offering.
SSPR along with NetIQ Access Manager (NAM) can provide a comprehensive and secure access management solution for your enterprise. This document details possible deployments of SSPR along with NAM to provide self service password management for users.
This document starts with a brief overview of SSPR with respect to integration with eDirectory and Access Manager. The next section lists possible Use Cases while deploying SSPR with NAM. And the last two sections provide detailed configuration options for both NAM and SSPR.
Self Service Password Reset (referred to as SSPR in rest of this document) is a self service password management web application for LDAP directories. It has 100 configuration settings which makes it easy to integrate with existing access management solutions.
SSPR has extensive support for Novell eDirectory with many eDirectory specific configuration parameters. SSPR supports Universal password policies and challenge sets, traditional passwords, handling of intruder lockout, etc. It can also read and write forgotten password responses to NMAS.
When used with eDirectory as LDAP store, SSPR requires schema extension on eDirectory to store data about a user's password management. SSPR can communicate with eDirectory over pure LDAP calls OR it also allows the administrator to enable NMAS for better integration and error reporting with eDirectory.
Like support for eDirectory SSPR has extensive configuration options for web access gateways as well. SSPR has provisions for specific configurations which makes it easy to integrate it with Web Access gateways like NetIQ Access Manager (NAM). Like any other password management application, SSPR is not meant to behave like a standard web application. Instead in most cases a user is redirected to SSPR for a password management need, completes a specific task and then gets redirected back to the original calling application.
As shown in Figure 1, it is likely that end users will be performing one of three operations on SSPR – (1) Configure challenge set (forgotten password responses), (2) Change existing password OR (3) Reset the password (forgotten password).
The following figure details the workflow for the most common SSPR operations.
Figure 1: SSPR Page Flow for Simple Password Management Deployment
There are multiple scenarios possible for password management solutions with NAM and SSPR. Following is the list of most important use cases for NAM and SSPR deployment. Each scenario is given here as the probable sequence of actions for end users. It is assumed that the User has already configured the Challenge Set for forgotten password reset with SSPR.
Scenario A: User wants to proactively change the password
Scenario B: User has forgotten the password OR password is expired with NO Grace logins remaining. Then user directly access the Forgotten Password URL for SSPR (through link on login portal OR through IDM CLE)
Scenario C: User password is expired with 2 Grace login remaining, user authenticates to NAM-IDP (Allow User Interaction Option on NAM is enabled)
Scenario User password is expired with 2 Grace login remaining, user authenticates to NAM-IDP (Allow User Interaction Option on NAM is Disabled)
Note:For Scenarios C & D if less than 2 grace logins are remaining, then the user has to either access the forgotten password feature OR contact the administrator.
Figure 2: NAM message when "Allow User Interaction" is enabled for expired passwords
All the accessible web pages of the SSPR application are neatly organized into "public", "private", "admin" and "config" paths on the web application server. Out of these the end users will mostly access only either "public" or "private" paths. In a typical deployment scenario of password management, based on the various configuration parameters on SSPR, users go through the page flow as shown in Figure 1. This section provides the configuration required on Access Gateway to protect SSPR application.
Configuring Proxy Service for SSPR
SSPR can be configured either as Path based multihoming or Domain based multihoming proxy service on NAM. All the communication to the SSPR is done through "/pwm" path. The following table gives the sample configuration for path-based multi-home setup.
|Proxy service type||path-based multi-home
(example Published DNS Name =. intranet.company.com)
|Ports Configuration||SSL enabled on Public side (Port : 443), non-ssl on private (Port : 8080)|
|Configured Multi-homing Path||/pwm|
|Remove Path on Fill||Disabled|
|Host Header||<SSPR Web Server Hostname>|
Configuring Protected Resource for SSPR
As mentioned above there are 4 subpaths to be protected for SSPR configuration. Assuming that we are configuring path based multihoming, the following paths are configured for SSPR protected resource list.
|URL Path||Protected Resource - Security Level|
|/pwm/*||Public – Authentication is None|
|/pwm/private/*||Restricted – Authentication Configured|
|/pwm/config/*||Restricted – Authentication Configured (Optional Access Policy)|
|/pwm/admin/*||Restricted – Authentication Configured (Optional Access Policy)|
TIP: Though SSPR has inbuild protection for Configuration and Administrative pages, in most cases it is advisable to configure Authorization Policy on NAM to protect /config and /admin paths to allow only administrator roles to access these parts of the SSPR application.
Configuring Single Sign On to SSPR
SSPR is by default configured to perform a HTML form based authentication in case an un-authenticated user tries to access any of the restricted web pages. However if the Basic Auth header is present in the HTTP request, it will always be used. Given this design we can easily configure Identity Injection policy on NAM to perform Single Sign On (SSO) to SSPR application with the authenticated user in NAM - IDP. This will be applicable whenever a user tries to access any of the configured NAM protected resource which requires authentication.
Configure the Identity Injection policy for SSPR as follows and enable this policy for restricted URL paths which are specified in previous section:
|Action for Identity Injection||Inject into Authentication Header|
|Auth Header – User Name||Credential Profile (LDAP Credentials:LDAP User Name)|
|Auth Header – Password||Credential Profile (LDAP Credentials:LDAP Password)|
|DN Format||LDAP format (default)|
Configuring SSPR parameters for NAM
As mentioned previously SSPR provides various options for integration with web access gateways – including configurable redirection URLs, servlet command options, support for HTTP basic authentication etc. Among these configurations the most important ones are the forward and logout URLs settings. These options are available in SSPR general configuration and determines where the users are redirected after any operation completion on SSPR.
TIP: It is always recommended to force the user to logout of SSPR and NAM after a password change operation is completed. Otherwise users may experience authentication failures and intruder lockout if they continue to use same NAM session.
Following SSPR settings shall be configured through Configuration Editor for proper integration with NAM:
|User Interface > Password Change Success Message||Custom Message to notify users about re-login to their portal after password change.|
|General > Forward URL||URL like "/pwm" where the user will be redirected after any operation except password change.|
|General > Logout URL||NAM logout URL like – intranet.company.com/AGLogout|
|General > Logout After Password Change||TRUE (recommended to keep this default setting for avoiding issues as mentioned in above TIP)|
Configuring Password Expiration Servlet on NAM-IDP
NAM provides an option to configure the URL for password service on the Contracts Page. This option is available through NAM configuration (Identity server – Edit > Local > Contracts > [Contract Name] > Password Expiration Servlet). The Administrator may configure this URL option to SSPR Change Password URL.
For example the URL can be: https://intranet.company.com/pwm/private/ChangePassword?passwordExpiration=true&forceAuth=TRUE&logoutURL=<RETURN_URL>
This URL specifies that in case the authenticated User's password is expired and there are grace logins remaining then the user must be redirected to the SSPR change password portal. Since we have already configured SSPR with identity injection, the user is directly redirected to rhw SSPR password change page where the password can be changed. If the "Allow User Interaction" option on NAM is checked then the user will get notification as shown in Figure 2 above.
NOTE: In case you are using Linux Access Gateway (LAG), create a touch file using "touch /var/novell/.PasswordMgmt" command on LAG , and restart proxy service using "/etc/init.d/ novell-vmc restart". This is required so that LAG refresh the password for the session whenever password management service is launched.
Integrating Forgotten Password URL on NAM – IDP Login Page
In case a user forgets the password then the Admin can configure the NAM – IDP login page to include the Forgotten password URL for SSPR. On NAM – IDP machine edit the login jsp file (/opt/novell/nids/lib/webapp/jsp/login.jsp) to add following HTML code just above last two </body></html> tags.
Forgot Password - Self Service Password Reset</a>
SSPR has many options for integrating tightly with products like eDirectory and NetIQ Access Manager. This document specifically discusses the integration options with NAM which is supposed to ease self service password management for end users of NAM. With proper configurations on both NAM and SSPR, forgotten password and change password (both voluntary and expired) can be provided for end users.