ISW Issues On Solaris 10 - Users Can Not Log Into The Solaris Host, Error Message: "DSA is unwilling to perform" (Doc ID 1296563.1)

Last updated on DECEMBER 08, 2016

Applies to:

Oracle Directory Server Enterprise Edition - Version 6.3 SP1 and later
Information in this document applies to any platform.

Symptoms



The Solaris OS users are unable to log in, the system is presenting a "DSA unwilling to perform" message in /var/adm/messages when attempting to log into the server. The message is referring to an issue with the account at the Directory Server (DS). Below is an example of the message.

Feb 8 11:07:25 [HOSTNAME] sshd[12758]: [ID 293258 auth.error] libsldap: Status: 53 Mesg: openConnection: simple bind failed - DSA is unwilling to perform



In this server environment, user account authentication was based on integrating Solaris OS as a client against the DS for posix account services (Native LDAP).

Even after restart of Message Queue (MQ), Identity Synchronization For Windows (ISW) and Directory services, user login attempts to the Host fail.

There have been no major changes to the server running the services, or the ISW, MQ or DS services.

You can see the errors log from the DS presenting the following messages:

[08/Feb/2011:11:07:24 -0800] - WARNING<38783> - isw - conn=1 op=0 msgId=0 - Plugins authentication cannot be completed, because no domain controller (ldap://ad.example.com]:389 ldap://ad2.example.com:389 ldap://ad3.example.com:389) is available to verify credentials for user uid=sample,ou=people,dc=example,dc=com
[08/Feb/2011:11:07:35 -0800] - WARNING<38783> - isw - conn=1 op=0 msgId=0 - Plugins authentication cannot be completed, because no domain controller (ldap://ad.example.com]:389 ldap://ad2.example.com:389 ldap://ad3.example.com:389) is available to verify credentials for user uid=sample,ou=people,dc=example,dc=com

 

Changes


There have been no major changes to the server running the services, or the ISW, MQ or DS services.

It turned out after investigation, that AD servers within the environment had changed IP address, but kept the same fully qualified domain name (FQDN).  This change however was not visible to the LDAP/Solaris administration teams as they attempted to restore services.

Cause

Sign In with your My Oracle Support account

Don't have a My Oracle Support account? Click to get started

My Oracle Support provides customers with access to over a
Million Knowledge Articles and hundreds of Community platforms