Common User Access Provisioning Problems

Novell Cool Solutions: Tip

Digg This - Slashdot This Posted: 19 Mar 2004

Common User Access Provisioning Problems

User Access Provisioning with Nterprise Branch Office^TM (NBO) is one of NBO's coolest features. Generally, setting up user provisioning is a difficult process, and troubleshooting can become a frustration if a step is missed. The purpose of this document is to eliminate that frustration and make the process as painless as possible. Here are some common errors that users have experienced setting up User Provisioning in the central office eDirectory^TM tree.

	Simple Password

Simple Password and Universal Password are the mechanisms that allow auto-provisioning. They need to be set up correctly for all protocols, except HTTP, in order to authenticate. If you don't plan on using the Universal Password for your corporate tree, you will need to make sure that the Simple Password is set up correctly.

An important and often forgotten step in this process is to give the users the rights to change or set their own Simple Password. This setting is done with the [This] flag. Steps can be found at http://www.novell.com/documentation/lg/nbo/index.html?page=/documentation/lg/nbo/setupguide/data/aiqs3yu.html

The symptoms you will see if this is not set up correctly is that a user can only provision through HTTP. What sets HTTP apart from other protocols is that the HTTP portal page can use the NDS password to authenticate. It will check the Simple Password first, and if that is not set, it will check the NDS password. If that is correct, it will then set the Simple Password to the NDS password, and all other protocols will be able to authenticate the user from then on. If the [This] flag is not set, the portal will try to set the Simple Password. It will fail, and no other protocols can authenticate after a two-minute timeout, during which NBO will not validate against the corporate tree.

If the Administrator sets Simple Password for each user and the [This] flag is not set, then when the user changes his/her eDirectory password, the Simple Password will not change. That causes their passwords to be out of synch. Universal Password was developed to fix this problem, and it's suggested users incorporate this into their trees.

	Universal Password

If you enable Universal Password on a existing corporate tree for the first time, a user's corporate password needs to be set after the Universal Password has been enabled. Or, you need to make sure that the Simple Password is set before the Universal Password is enabled. That enables eDirectory to synch all the password methods to the Universal Password for the first time. Then Universal Password will be the only method for authentication.

	Useful Troubleshooting Tools

The best tools for troubleshooting auto-provisioning issues are dstrace on NetWare and ndstrace on Linux. You will want to disable the trace of everything execpt LDAP and NMAS. (On NetWare the command is dstrace -all and then dstrace +ldap nmas. On Linux the command is ndstrace -<service> -<service> +ldap +nmas -<service> etc.)

Common errors:

• 669 -- failed authentication
• 49 -- invalid password
• 81 -- no connection or invalid certificate

Important: Just because you see an error does not mean that auto-provisioning will fail. NBO is set up to try many different methods to provision the user, and not all will be applicable to your corporate tree structure.

	ExteNd NMAS Methods

One of the most commonly overlooked problems is that the NMAS^TM methods were not extended in the corporate tree. The symptom of this is that you can provision with HTTP but not with NCP and/or CIFS clients. There are two ways to install the required extended NMAS methods, and both can be found on the NBO installation CD.

If you have a NetWare server as your central office LDAP server, you will need to run \Central_Office\NetWare\install.exe from a Windows client.

If you are installing to eDirectory on a Linux server or you don't have a Windows client, the methods are located in a .zip file at \Central_Office\NMASMethods.zip or extracted to \Central_Office\NMASMethods.

1. Mount the CD-ROM or copy the files to the local NetWare or Linux server.
2. For NetWare enter the command: nmasinst -addmethod <adminFDN> <Password> <configFilePath>

For Linux enter the command: nmasinst -addmethod <adminFDN> <TreeName> <ConfigFilePath> -w <Password>

Example on NetWare: nmasinst -addmethod .admin.users mypassword

sys:\tmp\nmasmethods\SimplePassword\config.txt



3. Restart the server when any NMAS changes are set. This is a very important step that is easy to forget.

This installation is required if you are using Simple Password or Universal Password in your tree.

	Corporate LDAP Server with eDirectory Replica

The corporate LDAP server needs to have a replica of the users container. There is a problem with dClient and auto-provisioning: the corporate server needs to have an eDirectory replica on the server.

	Corporate Server had eDirectory Removed Earlier

If you remove eDirectory from a test-environment server and then join that server into your production tree, NMAS will not have the correct keys/extensions. This needs to be fixed, and it can be done at your server console:

• On NetWare enter: nmasinst -m <adminFDN>
• On Linux enter: nmasinst -m <adminFDN> <TreeName> -w <Password>

You must then reinstall the NMAS methods. The steps for this are found in the ExteNd NMAS Methods section of this document.

	Certificate Errors

On the dstrace/ndstrace screen you will see an error with a line like this:

TLS accept failure 1 on connection 0x92c1e700, setting err = -5875. Error stack:?error:14094412:SSL routines:SSL3_READ_BYTES:sslv3 alert bad certificate - SSL alert number 42

When this happens, users may not be able to provision, or they may be able to provision through HTTP depending on the certificate error. If they are able to provision through HTTP, after a two-minute time period they will not be able to login with any other protocol. This may occur because the LDAP server object is pointing to the wrong certificate, or because the certificate was extracted with the private key.

Follow these steps to correct the problem:

1. In ConsoleOne or iManager edit the properties of the object ?LDAP-Server-<ServerName>.?
2. On the SSL Configuration tab make sure that the SSL Certificate is pointing to SSL CertificateIP and apply changes.
3. Edit the properties of the object ?SSL CertificateIP-<ServerName>.?
4. Select export Certificate and make sure that export private key with the certificate is set to ?No.?

	Common Symptoms

Occasionally HTTP authentication works fine but other authentication protocols only work for a two-minute time period following a successful HTTP authentication. Here are several reasons that this condition may be seen:

1. There is no Simple Password method object in the Central Office Tree.
2. The Simple and NDS passwords don't match or a simple password has not been set.
3. The Simple password method object has not been updated with the NBO Simple Password config.txt.
4. The correct NMAS objects don't exist in the tree.

Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com