Unable to set password in Active Directory when using Signing and Sealing

  • 7000172
  • 22-Apr-2008
  • 26-Apr-2012

Environment

Novell Identity Manager 3.5
Novell Identity Manager Driver - Active Directory
Microsoft Windows 2000 Server
Microsoft Windows 2000 Advanced Server

Configuration: Remote loader running on a member server and connecting to a Domain Controller using Signing and Sealing

Situation

Every time a password set/modify is sent from eDirectory, the password fails to be set on Active Directory with an error LDAP_UNWILLING_TO_PERFORM.

The complete error to be seen in the trace is:

Message = Password set failed.
Unwilling To Perform
00002077: SvcErr: DSID-031D0AAB, problem 5003 (WILL_NOT_PERFORM), data 0


Resolution

In order for a password to be set in a Domain Controller, an encrypted channel needs to be used in the communication between the driver (loaded by the Remote Loader) and the Domain Controller. When the driver runs on a member server there are typically two options to encrypt this channel
- Use SSL
- Use Signing and Sealing.

Using SSL is the recommended way in most occasions. Setting it up, though, is an involved process. The advantage of using Signing and Sealing is that it doesn't require any additional information.
The behavior of the libraries used to connect via LDAP using Signing and Sealing differ when connecting to a domain controller running Windows 2003 and Windows 2000. If the driver needs to connect to a Domain Controller running WIndows 2000, it will not be able to use Signing and Sealing (whereas Windows 2003 will not have a problem).

In the case that a connection to a Windows 2000 Domain Controller is needed and for some reason the configuration of SSL is not desirable, there is a third alternative to establish an encrypted channel: letting the driver use platform calls instead of LDAP requests to communicate to the Domain Controller. The following configuration adjustments need to be made:
- The parameters Use SSL, Sealing and Signing need all to be set to NO.
- The driver needs to be configured to use a Remote Loader instance.
- The Remote Loader needs to be configured to run as a service
- Go to the Control Panel | Administrative Tools | Services applet and edit the properties of the DirXML Remoteloader service. In the tab "Log on" change the default of using the Local System account for log on and specify a Domain Administrator account instead (it is possible to use the same account the driver uses).

The last step in this list is the key configuration change to get this to work. By default the driver runs as the System Local account, an account that has supervisor rights in the local system but has no rights in the Domain, so if the password operation is attempted with the change, it will fail due to lack of rights. By specifying that the connection can use this credentials, an encrypted channel can be established using Microsoft's native calls (using SMB) which takes care of encrypting the channel to transmit the password.

Additional Information

When the Remote Loader is configured to use an arbitrary account (and not the System Local account) it is not possible to see the live trace anymore. The Remote Loader instance creates a new session with the specified credentials and it is not possible to connect to this session.
The trace can still be captured to file and be seen off line (or by using a third party tool that allows to see the changes in the file as they occur).