SBL-SEC-10006: The authentication system cannot find the user with the specified username.

Applies to:

Siebel Life Sciences CRM - Version: 8.0.0.5 SIA [20420] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Symptoms

Customer found that they are unable to connect to the Siebel applications using Web Client after deploying a new language pack. In the Object Manager log, we found the following errors:
SecAdptLog 3rdpartyTrace 3 000000074cfc0d50:0 2010-12-06 02:38:02 (IDirectorySearch*)182d54->ExecuteSearch() with Filter '(&(objectClass=user)(uid=ANON_WEBUSER))' returns 0.
SecAdptLog 3rdpartyTrace 3 000000074cfc0d50:0 2010-12-06 02:38:04 (IDirectorySearch*)182d54->GetFirstRow(1833c0) returns 5012.
..
GenericLog GenericError 1 000000074cfc0d50:0 2010-12-06 02:38:04 (secmgr.cpp (2538) err=4597526 sys=0) SBL-SEC-10006: The authentication system cannot find the user with the specified username. Please check that you have entered the username correctly or contact your system administrator for assistance.
ObjMgrSessionLog Error 1 000000074cfc0d50:0 2010-12-06 02:38:04 (physmod.cpp (9244)) SBL-DAT-00568: The authentication system cannot find the user with the specified username. Please check that you have entered the username correctly or contact your system administrator for assistance.

Cause

During the investigation, we found that the UsernameAttributeType has been set to uid in the ADSISecAdpt

Solution

As per 'Bookshelf:Siebel Security Guide > Security Adapter Authentication > Configuring LDAP/ADSI Security Adapters'
Siebel Username Attribute: The Siebel user ID attribute used by the directory. An example entry for an LDAP directory is uid. An example entry for ADSI is sAMAccountName (maximum length 20 characters).
If your directory uses a different attribute for the Siebel user ID, enter that attribute instead. Corresponds to the UsernameAttributeType parameter.

The issue is resolved after customer change the UsernameAttributeType to sAMAccountName

Applies to:

Siebel System Software - Version: 7.7.2.6 [18372] and later   [Release: V7 and later ]
Oracle Solaris on SPARC (64-bit)
This document was previously published as Siebel SR 38-3098870703.

Symptoms

SBL-UIF-00272, SBL-DAT-00539, SBL-DAT-00700, SBL-SEC-10018, SBL-SEC-10001, SBL-SEC-10002, SBL-SEC-10006 Hello,

We are using the LDAPSecAdpt to authenticate against an Active Directory server.  When logging in with a wrong password on the Siebel Field Service login page, we discovered that it would kick out users, kill their Siebel sessions and give the following error:

The server you are trying to access is either busy or experiencing difficulties. Please close the Web browser, open a new browser window, and try logging in again.[16:42:21]

Normally when logging in with the wrong password, it would display an error message stating that your User ID or Password is incorrect and allow you to retry.

Thanks!

Solution

Message 1

For the benefit of other readers:

Customer started getting “Server Busy” error after applying 7.7.2.6 Fix Pack on top of 7.7.2.3 whenever users type a wrong password in the login page while using LDAP Security Adapter on Solaris platform to authenticate end users against Microsoft Active Directory.

The following error messages can be found in the Application Object Manager log files:

(secmgr.cpp (2340) err=7010006 sys=0) SBL-SEC-10006: The authentication system cannot find the user with the specified username. Please check that you have entered the username correctly or contact your system administrator for assistance.
Login Status: Failed
(mainlgin.cpp (1436)) SBL-UIF-00272: The user ID or password that you entered is incorrect.
Please check the spelling and try again.
ldap_result(3abd060, 3, ..., 3475fc8) returns 97.
ldap_parse_result(.., 3475fc8, 49, 3512fb0, 80090308: LdapErr: DSID-0C09030B, comment: AcceptSecurityContext error, data 52e, v893, 0, serverctrls, 1) returns 0.


[CONT 1/3...]

Message 2

[... CONT 2/3]


We have configured the Siebel Dedicated Web Client to use ADSI Security Adapter, and we got the following errors in the Dedicated Client log files:

(IADs*)1d41a0->Get('userAccountControl') returns 8000500d.
SBL-DAT-00700: Unable to check flag 'Password never expires'.
User password status is 0.
SecurityLogin() return 3.
(secmgr.cpp (2288) err=7010018 sys=127) SBL-SEC-10018: Unable to check flag 'Password never expires'.(SBL-DAT-00700)
SecurityFreeCredentials(<?INT?>)
(secmgr.cpp (2360) err=7010001 sys=0) SBL-SEC-10001: An internal error has occurred within the authentication subsystem for the Siebel application. Please contact your system administrator for assistance.
(secclnt.cpp (256) err=7010002 sys=0) SBL-SEC-10002: Cannot perform the requested operation due to an invalid security context. If you have already logged in, please try to log in again or contact your system administrator for assistance.

We found that this behavior was occurring because the Application User did not have the required permissions on the directory specified by Base DN parameter, as described in Bookshelf Version 7.7, Rev. A (May 2005) > Security Guide for Siebel eBusiness Applications > Chapter 6 – Security Adapter Authentication > Section Security Adapter Deployment Options > Item Configuring the Application User.


[CONT 2/3...]

Message 3

[... CONT 3/3]


In order to grant the necessary permissions, please have your AD Administrator open Active Directory Users and Computers, right-click the container specified by BaseDN parameter, and choose Delegate Control.
Add the Application User, check name, and delegate at least “Create, delete, and manage user accounts”, “Reset passwords on user accounts” and “Read all user information” tasks.
In fact, if you right-click the container, choose Properties, go to Security tab and click Advanced, you should see the Application User with at least “Read All Properties”, “Write All Properties”, “Create User Objects” and “Delete User Objects” rights applied onto “This object and all its child objects”.
The Security tab is only shown if you enable menu View > Advanced Features.

Application Object Manager crashes have also been observed on other customers using Group Policies on the Active Directory Server, after applying 7.7.2.6 Fix Pack on Solaris platform.
Please note that when running Siebel on Solaris and using the LDAP Security Adapter to authenticate against Microsoft Active Directory, account policies such as password expiration are not supported.
For further details, please refer to Technical Note 596: Configuring Siebel Applications on Solaris Implementations To Authenticate Against Microsoft Active Directory.
In this case, please ensure Password Never Expires is set for all users on ADS.

Thank you,

Applies to:

Siebel System Software - Version 7.8.2.5 [19227] and later
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Enterprise)
Version: 7.8.2.5 [19227]
Database: Oracle 10.1.0.4
Application Server OS: Microsoft Windows 2003 Server SP1
Database Server OS: Sun Solaris 9

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

Symptoms

SBL-UIF-00272, SBL-SEC-10006
Hello,

We have an Active Directory Forest with the parent domain and a child domain.
We have created all Siebel staff users on the parent domain and Siebel service accounts on the child domain and are trying to use them to authenticate.
Any users from the parent domain can log into the child domain.

We can display the Graphical User Interface.
However, if you attempt to log into Siebel while integrated to the child domain, you receive the following error message:

The user ID or password that you entered is incorrect. Please check the spelling and try again.
(SBL-UIF-00272)

If you check the domain controller on the child domain, it shows that same user authenticating successfully.
Why am I not able to log into Siebel?

Thanks!

Cause

Bug 10462680

Solution

Message 1

For the benefit of other readers:

The current ADSI Driver developed by Siebel was not designed to support an ADSI multi-domain environment, which means that the Siebel Security Adapter architecture currently does not allow multi-domain authentication via ADSI.
This functionality is not yet incorporated within the Siebel Application.
Also, please note that the use of Global Catalogs is not supported by Siebel Technical Support, since the ADSI Security Adapter was not designed to work with GC, and has not been tested by Siebel Engineering, or certified by our Quality Assurance Team to work with a Global Catalog.

In this case, we recommend one of the following approaches, which are in agreement with how the ADSI Security Adapter is intended to work:

1. Create all Siebel users under one single domain within Microsoft Active Directory, by moving all Service Accounts from the child domain to the parent domain, for example, and then pointing parameters ServerName and BaseDN to the parent AD Server.

2. If you require to maintain Siebel users spread into two distinct domains, you can create a new Application Object Manager for each domain, through the use of distinct Named Subsystems for each AOM, each one pointing to its specific domain.


[CONT 1/2...]

Message 2

[... CONT 2/2]


For further details on the use of multiple domains on ADSI, please refer to the following SupportWeb postings:

    - Multiple Activer Directory Servers (Doc ID 528364.1)
    - ADSI Authentication Using Global Catalog Port 3268 (Doc ID 517259.1)
  
Bug 10462680 was previously logged to address this Enhancement Request, but they have not been implemented yet.
The information above is still true for Siebel Version 7.8 and 8.x.

Applies to:

Siebel CRM - Version: 8.1.1.1 SIA [21211] and later   [Release: V8 and later ]
Information in this document applies to any platform.

Goal

=== ODM Question ===

When user enters credentials for non-existent user that does not exist in the LDAP directory, following error is reported in the UI:

"SBL-UIF-00272: The user ID or password that you entered is incorrect. Please check the spelling and try again.".

In the object manager log file, you will see errors in following order:

GenericLog GenericError 000000064ce4172c 1: 0 11.17.2010 19:04:51 (secmgr.cpp (2731) err = 4597526 sys = 0) SBL-SEC-10006: The authentication system cannot find the user with the username specified. Make sure you typed the user name correctly, or contact your system administrator for assistance.

ObjMgrLog 000000064ce4172c Error 1: 0 17.11.2010 19:04:51 (mainlgin.cpp (1695)) SBL-UIF-00272: The logon username / password pair entered is incorrect.
Re-enter the logon parameters.

How could we show force LDAP security adapter to display first error message SBL-SEC-10006 on the login page when non-existent user tries to login instead of last error message SBL-UIF-00272?

Solution

=== ODM Answer ===

Currently, it is not possible to customize or force LDAP to return the second error message to the user.  An enhancement request 12-E29NSZ was logged requesting to customize LDAP messages, however, Siebel Engineering had declined such request and it was recommended that customers write custom security adapter to trap the LDAP messages and customize it.  In the vanilla product, it is not possible to customize messages. Siebel is showing message what comes out of LDAP and this is correct behavior.

In conclusion, it is not possible to modify the error messages or custom configure what comes out of the LDAP security adapter.

Applies to:

Siebel Workflow - Version: 7.7.2 SIA [18325] and later   [Release: V7 and later ]
z*OBSOLETE: Microsoft Windows 2000
Product Release: V7 (Enterprise)
Version: 7.7.2 [18325] Pub Sect
Database: Oracle 9.2.0.4
Application Server OS: Microsoft Windows 2000 Advanced Server SP 2
Database Server OS: Microsoft Windows 2000 Advanced Server SP 2

””Checked for Relevance on 13-01-2012””
This document was previously published as Siebel SR 38-2424118427.

Symptoms

SBL-DAT-00192, SBL-DAT-00227, SBL-DAT-00381, SBL-DBC-00111, SBL-SEC-10006TS,

We are using the OOTB workflows to allow users to register through eService. During self registration, address information is requested. Sometimes this address information is being written to the DB and some times it is not. One user seems to be able to create this at will from his machine as well as other machines. I don't think it has anything to do with a machine but I don't think we can rule anything out.

We have also run into an issue outlined in SR 38-2292561770. The country field that is being populated on the user registration screens is not be captured when the address is written to the DB (when the address is committed to the DB).

The workaround to address the country field not being populated works. However, this is an OOTB workflow and making changes to make it work shouldn't have to be done. From my perspective, this is a product defect.

And now I'm wondering if the country field issue has anything to do with the address not being written sometimes.

Would like your input on how to proceed and trouble shoot this issue.

Cause

Enhancement

Solution

Message 1

For the benefit of the other users:

Scenario:

When using LDAP as a security adapter the S_ADDR_PER_U1 index is being violated with a duplicate key on the User Registration Process (New User link).

This is basically happening because the Anonymous user Id is being used instead of the new user Id. Based on that two different users that are registering themselves thru the eService application with the same address will generate a duplicate key and the address will not be filled.

Workaround:

The field Calculated Address Name should be changed BC "Personal Address" . The [Id] field should be added to the calculated value in order to avoid the duplicate key. Please see bellow:

Left([Street Address],[Street Address Len]) + [Calculated Address Comma1] + [City] + [Calculated Address Comma2] + [State] + [Id]

Change Request:

Bug 10501346 - Duplicate key on S_ADDR_PER table when using LDAP security adapter has been logged to address this behavior

Applies to:

Siebel CRM Service - Version 8.1.1.4 SIA [21225] and later
Information in this document applies to any platform.

Symptoms

Environment:
-------------------
Product Type: Siebel CRM Service
Version: 8.1.1.4 SIA [21225]
OS platform: N/S
DB: Microsoft SQLServer
Env type: Dev

Statement of Issue:
-----------------------------
An inbound web service is called using WS-Security's UserName Token mechanism where the username and password are specified in the SOAP request document. This works with database authentication. The requirement is to use LDAP authentication. The following parameters are set on the EAI OM:

Security Adapter Mode : LDAP
Security Adapter Name : LDAPSecAdpt
User Name : A3N7MZZ

When the web service is called, the EAI OM task is failing with an error.

Error:
-------
14:13:08 (secmgr.cpp (2731) err=4597526 sys=0) SBL-SEC-10006: Das Authentisierungssystem kann den Benutzer mit dem angegebenen Benutzernamen nicht finden. Stellen Sie sicher, dass Sie den Benutzernamen korrekt eingegeben haben, oder wenden Sie sich an den Systemadministrator.
14:13:08 Login failed for Login name : SADMIN

In English:
14:13:08 (secmgr.cpp (2731) err=4597526 sys=0) SBL-SEC-10006: The authentication system cannot find the user with the specified username. Please check that you have entered the username correctly or contact your system administrator for assistance.
14:13:08 Login failed for Login name : SADMIN

Business Impact:
-------------------------
This has to be resolved because the customer uses LDAP to authenticate users.

Cause

SADMIN is not set-up as an LDAP user.

Solution

LDAP authentication was working for the Call Center application object manager. The task log showed that the task authenticated SiebelAnonUser and then authenticated the user that was logging into the application (A3N7MZZ):

Security Adapter Mode : LDAP
Security Adapter Name : LDAPSecAdpt
User Name : SADMIN
14:47:55 LDAP SecurityLogin8 with username=SiebelAnonUser.
14:49:13 LDAP SecurityLogin8 with username=A3N7MZZ.

SiebelAnonUser is set-up as an LDAP user.

Eapps.cfg included the following:

[/callcenter_deu]
AnonUserName = SiebelAnonUser
AnonPassword = xxxxx

AnonUserName was not specified for the subsection [/eai_anon_deu]. As a result, it was using the AnonUserName specified in the [defaults] section, which was SADMIN.

The inbound web service call completed correctly when AnonUserName and AnonPassword were specified in [/eai_anon_deu] and set to a user who was set-up in LDAP.