SBL-DAT-00350: SetUserInfo failed for user %1. This may be due to a problem with the external authentication system.....

Applies to:

Product Release: V7 (Enterprise)
Version: 7.5.3.5 [16183]
Database: Oracle 9.2.0.2
Application Server OS: Microsoft Windows 2000 Server SP 3
Database Server OS: Sun Solaris 5.8

This document was previously published as Siebel SR 38-1492603261.

Symptoms

SBL-DAT-00350

Dear Siebel,

For our UAT environment, we have setup LDAP as a Security adapter for one of our Object managers.
Directory server was already installed earlier and was used for authentication for the production system.
I am facing a issue where I am not able to add a new contact(or Employee or User) from Siebel.
When I try to add it I get the message saying that
SETUSERINFO failed for user <User Name>. This may be due to a problem....................
Object Class Violation (SBL-DAT-00350). Please see the attached screen shot for the reference.

If I try to add an existing user (on LDAP), I get a proper message saying that the userid already exisitng.

I am attaching the siebns.dat, scomm.cfg file along with this.

I understand that the user id SADMIN which which I am logging into the Siebel application should have access to add the user but not sure where I can set it.
Before this Object class violation, I was getting the Access related error.

Thanks

Solution

Message 1

For the benefits of other users:

Customers are not able to add a new contact (or Employee or User) from Siebel Application with LDAP Security adapter setup. When trying to add a contact, message saying that
“SETUSERINFO failed for user <User Name>. This may be due to a problem..... Object Class Violation (SBL-DAT-00350). Please see the attached screen shot for the reference.” returned.

Solution:

A check on the following item done:
- Customer on supported LDAP and Siebel Application platform.
- Verified “SecExternalUserAdministration”, “SecThickClientExtAuthent”, and “Security Adapter CRC” in Site Map > Application Administration > System Preferences
- Verified Security Adapter configuration for Object Manager
- Verified LDAP directory data (DN) setup (.ldif)
- Verified access permission for Application User
- Verified all the parameters set in LDAP section in OM configuration file

The LDAP access log has the following error when adding a user:

[27/Sep/2004:13:49:22 +1000] conn=784 op=3 ADD dn="=,ou=def,o=abc.com"
[27/Sep/2004:13:49:22 +1000] conn=784 op=3 RESULT err=65 tag=105 nentries=0 etime=0
[27/Sep/2004:13:49:22 +1000] conn=784 op=4 UNBIND
[27/Sep/2004:13:49:22 +1000] conn=784 op=4 fd=39 closed - U1

And the error log has the following:
[27/Sep/2004:13:49:22 +1000] - Entry "=,ou=def,o=abc.com" -- attribute "uid" not allowed

Message 2

LDAP error code 65 means “Object class violation” and the correspondence error log shown attribute “uid” not allowed; this seems to be an issue with the LDAP server. The uid attribute was not being propagated. Issue resolved after reinstall the LDAP server.

Thank you,
Siebel Technical Support

Keywords: SBL-DAT-00350, SETUSERINFO failed

Applies to:

Product Release: V7 (Enterprise)
Version: 7.5.3 [16157]
Database: Microsoft SQL Server 2000 SP3
Application Server OS: Microsoft Windows 2000 Advanced Server SP 3
Database Server OS: Microsoft Windows 2000 Server SP 3

This document was previously published as Siebel SR 38-1202785131.

Symptoms

SBL-DAT-00350

When attempting to enable Password Syntax or minimum length checking on our ADSI integration, the New User Registration process appears to be failing to complete successfully when the password is rejected by ADSI. However, it is not returning any error directly. This is somewhat similar to SR 38-980959751, but without any error message.

Specifically, follow along the USER REGISTRATION PROCESS workflow. If I intentionally create a user with an invalid password (say, too few characters), I still get the "Thank you for registering. Please click Finish to continue." view. Clicking FINISH appears to execute the "Insert New User" step, as the user is created in the User Administration screens. However, it fails at "Set New Login Info" with a generic: "We detected an Error which may have occurred for one or more of the following reasons:" (with no reasons listed). An entry is created in the ADSI directory, but with no password; however, no Challenge/Response information is created for the user (which is the other function of "Set Login Info"), so it appears to be failing midway through.

Is there any way to see log information (the eService ObjMgr log file and SWE log files show nothing) which may help here? There does not appear to be an error branch off of Set Login Info which would capture ADSI password rejection; how does Siebel handle this?

Solution

Message 1

For the benefit of other users:

Customer had implemented ADSI authentication and had enabled minimum password length policy in ADSI. The reported behavior was that the New User Registration would fail when the password is rejected by ADSI. However, it was not returning any error directly. Clicking FINISH would fail with a generic error: "We detected an Error which may have occurred for one or more of the following reasons:" (with no reasons listed). An entry was created in the ADSI directory, but with no password; however, no Challenge/Response information is created for the user.

Technical Support reproduced this behavior and logged Change Request#12-K5DHTL for this behavior. A Change Request#12-FIF77M was already logged to improve the error message returned when ADSI password policy fails.

To get around the behavior Technical Support suggested to modify the Standard User Registration Workflow Process to call a custom business service to insert the challenge question/answer inspite of the failure.

Applies to:

Product Release: V7 (Enterprise)
Version: 7.5.2.215 [16069] HH
Database: Oracle 9.2.0.2
Application Server OS: Microsoft Windows 2000 Advanced Server SP 2
Database Server OS: Sun Solaris 2.7

This document was previously published as Siebel SR 38-1018615031.

Symptoms

SBL-DAT-00350

We are using Siebel eChannel with ADSL authentication.

From the moment we set ADSL in our Development environment we cannot change the user's password in Partner Personal Profile or generate a new password using the Forgot Password link in the Home page. The error message is: “SetUserInfo failed for user XXXXX. This may be due to a problem with the external authentication system, or attempting to enter user name and password that contains non-ASCII characters.” The change/generate password was working before the ADSL was set in DEV.

We have studied Service Requests 38-937920551, 38-821359193, 38-805263251, 38-685367951 and so far we set the user with Change Password and Reset Password privileges, but that did not help

The password change works thru ADSL on our TST environment, the config of both TST and DEV environments are the same, so we do not know why we are not able to change passwords in DEV. The same ADSL is used for both environments and the user for TST and DEV is the same.

Solution

Message 1

For the benefit of other readers, after enabling ADSI Authentication for Siebel eChannel in a development environment, the customer encountered the following error message when attempting to change a user’s password:

“SetUserInfo failed for user XXXXX. This may be due to a problem with the external authentication system, or attempting to enter user name and password that contains non-ASCII characters.”

This behavior did not occur in the customer’s test environment, which was using the same Active Directory Server.

After further research it was discovered that the test environment was communicating with the Active Directory Server over SSL. Since the appropriate Certificate was not installed on the development server SSL communications was failing.

Once the appropriate certificate was installed on the development environment, the customer was then able to change user passwords.

Note: The ADSI Adapter Requirements section of the Security Adapter Authentication chapter in the 7.5.2 Security Guide states “To perform user management in the ADS directory through the Siebel client, it is strongly recommended that you configure ADS at the server level for SSL communications between the Active Directory client and server.”