Attribute Mapping for Password Self-Service
Novell Cool Solutions: Feature
By Gordon Mathis
Digg This -
Posted: 19 Oct 2005
This article is an in-depth look at the components that make up the Novell Password Self-Service product, and how you can map eDirectory attributes to the responses.
The focus of this article is not so much on the Password Self-Service product since it is well documented by Novell's Nsure Identity Manager 2.0 product at http://www.novell.com/products/nsureidentitymanager/.
Instead, I will introduce a sample application that maps eDirectory attributes to the responses so that users don't have to answer a set of challenge/response questions the first time they login to the network. Also, I will give a functional overview of the Novell Modular Authentication Services (NMAS) and the Challenge/Response method which is the framework for the Password Self-Service product. Novell customers have expressed an interest in using the NMAS Challenge/Response method outside the framework of the Novell Password Self-Service product.
iManager 2.0.2 includes Novell's Portal Services, which is necessary to test the Password Self-Service product. Both can be downloaded from http://download.novell.com and installed on eDirectory.
In addition, all the components of the Password Self-Service product have been ported to the Novell Extend portal framework and come pre-installed on Novell's Open Enterprise Server (OES). Virtual Office, which is only included with OES, can be used to test the Password Self-Service product. I am using OES for the examples in this article.
Installing Novell Open Enterprise Server (OES)
OES can either be installed on Linux or NetWare. See the following link for more details: http://www.novell.com/documentation/oes/index.html?page=/documentation/oes/oes_home/data/front.html
1. Using a Web Browser, launch iManager by going to https://<host address>/iManager.html.
2. Log in as the admin user.
3. Create a new Challenge Set and select only admin-defined questions (uncheck User Defined). Create questions that correspond to LDAP attributes like telephoneNumber, title, user id (uid), department (ou), location (l), zipcode (postalCode) etc.
4. Before creating a Password Policy, create an Organizational Unit by selecting the Create Object task from the eDirectory Administration role. Create an Organizational Unit named users in the context of novell. The Password Policy will be assigned to this container so that only the users in this container will be affected by the Password Policy. (You probably don't want the Password Policy applied to all users, including admin).
5. From the Passwords role, select Password Policies and create a new Password Policy that uses the new Challenge Set, enables the Forgotten Password option, and allows users to reset their password. Otherwise, take the defaults.
6. When asked to assign the Policy to an object, assign it to the users.novell container.
7. From the Users role, select Create User and create a new user in the users.novell container. Be sure to fill in any attributes you plan on using for responses. It may be necessary to use the Modify User task and assign additional attributes by selecting different categories from the combo box at the top of the screen.
At this point the Password Self-Service product is configured and ready to test. If this is all you are attempting to do, and you don't mind entering the responses to the challenge questions the first time you log in, you can skip the section on mapping attributes to responses and proceed to test your setup.
NMAS Functional Overview
Up to this point everything has just been simple configuration using iManager. Because this challenge/response functionality is so dependent on NMAS, it might be good to give a brief explanation of NMAS at this time.
How does Novell's Challenge/Response work?
To understand how Novell's Challenge/Response works, we need to understand how NMAS functions, because the Password Self-Service uses the Universal Password and the NMAS Challenge/Response method. All NMAS methods consist of a Login Server Module (LSM) that runs on the server where eDirectory is located, and a Login Client Module (LCM) that can be run from a number of different locations. LCM's communicate with eDirectory via its corresponding LSM. The Challenge/Response LCM is written in Java so that it can be accessed by a servlet or a portlet. The Challenge/Response LSM accesses eDirectory and determines which set of challenges a user will have to answer. Then it determines whether the user will be authenticated to the network, based on the answers given. When you installed OES, the NMAS Challenge/Response method was also installed.
Where are the Challenges and Responses Stored?
Challenges and responses are stored in the NMAS config and secret stores. NMAS provides client management APIs to read and write from the config store, but they only write to the secret store. Only LSM's can read from the secret store. Also everything that is stored to these stores has an associated tag name. When storing the challenges and responses the challenges are stored in the config store as an XML string. This XML string has the following format:
<Challenges RandomQuestions="2" GUID="123456"> <Challenge Define="Admin" Type="Required" MinLength="2" MaxLength="20"> What is your ssn? </Challenge> <Challenge Define="User" Type="Required" MinLength="2" MaxLength="20"> My favorite cereal? </Challenge> <Challenge Define="Admin" Type="Random" MinLength="2" MaxLength="20"> What is your cost code number? </Challenge> </Challenges>
The responses are stored in the secret store as individual strings with the challenge text as the tag name.
Because the challenge and responses are stored in two different areas, and we can only write to the secret store, managing the challenges and responses and ensuring that we don't have orphaned responses becomes an important issue.
Fortunately, you can delete data from the secret store - so whenever a user modifies or removes a challenge it is necessary to remove the response and add it again. Because the challenges are added as a single string, it might be a good idea to simply remove all responses and add them again.
In Java there is an NMASChallengeResponseMgr class in the NMASToolKit.jar that simplifies this process by calling the appropriate functions to read and write to the config and secret stores. This class is used by the mapping application that I will have you download later.
Modifying the ChallengeSet
In order for the mapping application to know which attributes are associated with responses, it is necessary to modify the ChallengeSet object in eDirectory. Here are the steps to follow:
1. In iManager, select the Modify Object task from the eDirectory Administration role.
2. Browse to and select the ChallengeSet object. The ChallengeSet object is located under the Password Policies.Security container.
3. Select Other from the combo box at the top of the window to see the attributes. There are two attributes on the ChallengeSet object that contain XML data that need to be modified:
4. Edit the nsimRandomQuestions and nsimRequiredQuestions attributes, adding an AttributeMapping=<LDAP attribute name> to each Admin-defined question (see the example below). Make sure your changes include double-quotes around the attribute values, or exceptions will be thrown by the mapping application.
<RandomQuestions> <AdminDefined> <Question MaxLength="255" MinLength="2" AttributeMapping="uid"> <![CDATA[What is your User ID?]]> </Question> <Question MaxLength="255" MinLength="2" AttributeMapping="ou"> <![CDATA[What is your department name]]> </Question> <Question MaxLength="255" MinLength="2" AttributeMapping="postalCode"> <![CDATA[What is your zip code]]> </Question> <Question MaxLength="255" MinLength="2" AttributeMapping="street"> <![CDATA[What is your street address]]> </Question> </AdminDefined> </RandomQuestions> <RequiredQuestions> <AdminDefined> <Question MaxLength="255" MinLength="2" AttributeMapping="title"> <![CDATA[What is your job title]]> </Question> </AdminDefined> </RequiredQuestions>
Mapping eDirectory Attributes to Responses
All NMAS management APIs require you to establish an SSL connection with the server. To do this, it is necessary to export the servers Trusted Root certificate.
1. Using iManager, select the Modify Object task under eDirectory Administration.
2. Browse and select the SSL CertificateDNS – linux.novell object.
3. Select Trusted Root certificate from the combo box and click Export.
4. Select No to export the private key and click Next.
5. Click Next to accept the default of a binary DER format file.
6. Click the "Save the exported certificate to a file" link to save the file to disk.
7. Add the Trusted Root Certificate to a Sun Keystore.
8. Create a certs directory in your user's home directory.
9. In a shell console, execute the following:
java sun.security.tools.KeyTool -import -alias TrustedCert -file ~/TrustedRootCert.der -keystore ~/certs/sslkey.keystore
Downloading the Attribute Mapping Application
1. Download the MappedChallengePusher.zip sample application from http://forge.novell.com/modules/xfref_library/detail.php?reference_id=2493.
2. Unzip the MappedChallengePusher.zip to a directory on your system and execute the build.sh. At this point you can either use the allusers.sh to map all the users in the tree or oneuser.sh to map one user.
3. View the .sh files and make sure javax.net.ssl.trustStore is pointing to your sslkey.keystore location.
Note: These sample applications throw exceptions for a number of different reasons. If you choose the allusers.sh, you will more than likely get exceptions thrown for all users that don't have required attributes set.
Virtual Office provides a way for us to test our Password Management configuration. However, we first have to log in as admin and enable the Universal Password option.
1. Open a browser and browse to https://<host address>/vo/servlet/portal
2. Log in as admin.
3. On the home page, select the Services link from the Administration menu on the left.
4. Click the Change Password tab.
5. Select the Change Universal Password Link option and click OK.
6. Click the logout link on the menu bar at the top of the page.
At this point you will be back at the login screen, but notice that the "Forgot your password?" link is available now.
7. Enter the credentials of the new user that you mapped attributes for and login.
If you mapped attributes for this user, note that you logged in without having to answer a set of challenge/response questions.
If you did not map attributes for this user you are forced to answer a set of challenge/response question before you are allowed to login.
8. Log out and click the "Forgot your password?" link.
9. Enter the username and click Submit.
10. Answer the challenge questions and click Submit.
If you answered correctly, and if you permit users to reset their passwords in the Password Policy configuration, you can reset your password now.
At this point you have successfully reset your password yourself and saved yourself a call to the help desk.
What we have seen here is an easy way to setup and administrate a password self-service environment. Mapping eDirectory attributes this way is easy for both the Network Administrator and Users.
In today's world where we have so many passwords to manage, it is almost a given that we will forget a password at some point in time. Companies can not only reduce costs by allowing users to reset their own passwords, but at the same time can maintain a level of security required in an enterprise network environment.
Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com