Search This Blog

SBL-DAT-00342: User %1 does not exist. %2

Applies to:

Product Release: V7 (Enterprise)
Version: 7.5.3 [16157]
Database: Oracle
Application Server OS: Microsoft Windows 2000 Server SP 2
Database Server OS: Sun Solaris 8

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


SBL-DAT-00254, SBL-DAT-00342

We recently are in process of moving from test to prod for the AD authentication on Siebel Application.
The authentication or the login is just not working for 3 users out of the 25 users we tested.

Please help knowing that I checked to see
the basics logins like match in AD and password case sensitivity is taken care of.
There is nothing on the Active Directory section when i verified to see with the administrators if
something are special policies for them.
I have attached the log files from eapps.



Message 1

Two of the users are not able to log in when trying to use an Active Directory authentication. The error message they receive in the Siebel Web Server Extension log file is:
    [SWSE] callback reimpersonate failed. User %1 does not exist. %2
and in the related Object Manager log file:
    SBL-DAT-00342) User xxxxxx does not exist

After some testing to know what the situations that return this error message are, the possible errors that you can receive are:
a- User does not exist in ADSI:
    (SBL-DAT-00342) User xxxxxx does not exist.
b- User does not exist in Siebel but exists in ADSI:
    (SBL-DAT-00254) The User Name you have entered is invalid or your user position is not defined.
c- User is in a branch of the ADSI that cannot be reached by the setting of the BaseDn:
    (SBL-DAT-00342) User administrator does not exist.
d- Application user is not in the same branch as all the users and the BaseDN is pointing to the branch where all the users are:
    No error.

From this testing, the only 2 relevant options are (a) and (c). As it was not case (a) because users were able to connect to the domain, it means that it was case (c).

Using the Microsoft Active Directory Browser tool, it has been confirmed that the users where in another branch than what is pointed by the BaseDN. In fact all their users are grouped by a certain criteria meaning that a sub tree exists where all the users are dispatched in specific branches based on the criteria.

Message 2

The structure is like:
The parameters that were set in the application configuration file for the ADSI section were:
    SharedCredentialsDN = "CN=APPUSER,OU=Users,OU=Criteria1,DC=Company,DC=com"
    ApplicationUser = "CN=APPUSER,OU=Users,OU=Criteria1,DC=Company,DC=com"
    BaseDN = "OU=Users,OU=Criteria1,DC=Company,DC=com"
With these settings, only users belonging to the sub tree Criteria 1 can log in.

After changing the parameter BaseDN to "DC=Company,DC=com", all the users were able to connect.

It is important to note that with this setting:
1- If you create your users through the Siebel interface and then propagating the creation to the Active Directory, all the new users will be created at the BaseDN level.
2- We will always find the application user (ApplicationUser), as this parameter should be the full distinguished name. But you should ensure that this user has sufficient rights to do action like: browsing, modifying users (especially the password), creation of users (if you create users in the Siebel application and propagating to the ADSI).
3- We will always find the entry for the shared database credentials (SharedCredentialsDn), as thus parameter should be the full distinguished name.

Thank you.

Siebel Technical Support

Applies to:

Product Release: V7 (Enterprise)
Version: [16168]
Database: Oracle
Application Server OS: Microsoft Windows 2000 Advanced Server SP 2
Database Server OS: Microsoft Windows 2000 Advanced Server SP 2

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




Coming Monday we have planned to enable LDAP on our production environment. Before this I have enabled LDAP on a test environment and that works fine.

To make sure everything works fine Monday, I enabled LDAP temporarily on production and this failed. Here are the steps I take and the error I receive:

1) Modified the uagent.cfg file (see attachment)
2) Modified the eapps.cfg file (see attachment)
3) Changed the Call Center Object Manager (ENU) parameter Security Adapter Name = LDAP Like on the test environment I only want to enable LDAP on the Object Manager level. On the test environment this works fine.
4) Changed the System Preference SecThickClientExtAuthent = TRUE
5) Restarted the Application and web server


Message 1

For the benefits of other users:

Customer intended to setup LDAP authentication and encounter Login Failed and User %1 does not exist %2 (SBL-DAT-00342) errors for the anonymous user. It was found that the reported anonymous user in the log is the one used before switching to LDAP authentication. Eapps.cfg file had been verified that the new anonymous user for LDAP authentication had been defined but it does not seem to take effective.


After further investigation, it was found that the customer has the SWSE and web services setup in cluster environment and after changes of the AnonUser in eapps.cfg, they have restarted web service using cluster administration tool. The issue resolved when restarting the web services directly/manually without using the Cluster Administration tool.

Thank you,
Siebel Technical Support

Applies to:

Product Release: V7 (Enterprise)
Version: [16168]
Database: Oracle
Application Server OS: Microsoft Windows 2000 Server SP 3
Database Server OS: Microsoft Windows 2000 Server SP 3

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



I am trying to setup our test environment with LDAP authentication, below are the steps I did:

- Installed the IBM LDAP client on the server
- setup the LDAP user in the Siebel database (this LDAP users already existed in Active Directory)
- Changed the Server parameter: Security Adapter Name = LDAP
- Changed the Application parameter: SecThickClientExtAuthent = TRUE
- modified the epharma.cfg (see attachment)
- Stopped the Siebel Webserver, Siebel Server and the Siebel Gateway
- Started the Siebel Gateway, Siebel Server and the Siebel Webserver

After this the webclient didn't work (see the attached logfiles ePharmaObjMgr_enu_17446.log and ES_EU_A75.SS_EU_A1.log (Siebel Server) and ss050823.log (Web server)). I see messages like "(SBL-DAT-00342) User sadmin does not exist."

I also added the siebns.dat file to this SR

Can you please advize what do/check.


Message 1

For the benefit of other users, the customer was having difficulties configuring Siebel to work with LDAP. The following error message was received when attempting to logon via the Siebel Web Client:

(SBL-DAT-00336) An internal error with the Security Adapter DLL has occurred.
Please ask your systems administrator to check your security adapter.


Installing the IBM LDAP Client became mandatory with as per Alert 943: IBM LDAP Client 5.1 required with Siebel eBusiness Applications Fix Pack on SupportWeb. However, as the customer was on, they were asked to uninstall the IBM LDAP Client 5.1 software.

We verified and modified the parameters in the [LDAP] section of the Siebel Web Client’s ePharma.cfg until we could successfully connect by following the instructions in Troubleshooting Steps 56 on SupportWeb.

Further research found the LDAP administrator had specified the credentials to include “type=ServerDataSrc” however, the [ServerDataSrc] section in the Siebel Web Client’s ePharma.cfg file was renamed to [UAT]. We renamed the [UAT] section to [ServerDataSrc] and were able to logon.


Applies to:

Product Release: V7 (Enterprise)
Version: [16161]
Database: Oracle
Application Server OS: Microsoft Windows 2000 Advanced Server SP 3
Database Server OS: Sun Solaris 2.7

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


SBL-UIF-00293, SBL-DAT-00170, SBL-DAT-00342


We are still experiencing an error during the registration process of our Partner Portal.

During the full registration process by our partners the Company information is occasionally lost, also the Registration Type is also not set. This happens around once in every twenty or so registrations.

Any attempts to recreate this error with logging set to a higher level have so far failed.

I have also enclosed the workflows that run along with some notes on where I think it may be failing (Highlighted in red). The Lost Company Information.doc shows the error on the screen.

Do you have any ideas of why this might be happening?

Best regards,



Message 1

For the benefit of other readers, the customer reported that users experienced an error during the registration process of our Partner Portal. This error was apparently random and the way it was detected was that after the full registration process the Company information was occasionally lost and the Registration Type was not set.

After detailed investigation a testcase was identified as follows:

1. User connects to the eChannel Portal and clicks on the 'Register' button.
2. User fills in the entire registration process and chooses to register his partner company.
3. At the 'User Registration Legal Confirmation Applet' the user stops the process and does not accept the terms of agreement(Closes browser) or there is a system failure at this point (Could be many reasons for this i.e. Timeout, Server failure, local P.C. failure etc) The registration process is now stopped at this point.
4. The user then tries to re-register in the same way as before. (Using exactly the same first name, surname and email address.)
5. This time they are able to get past the Legal confirmation applet and the user is registered.

Just the user details are registered as follows, the system stores this user with the unique key:

First Name,
Email Address.

When the user tries to re-register a conflict occurs because the user is already in the system.

Review of the user registration workflows shows that the user action to close the browser is not supported and so if this

Message 2

happens the normal processing path to remove a temporary user record if it has not been confirmed does not get executed.

It is possible to include additional processing in the Workflow Process to deal with this which entails setting up a runtime event to take account of when the browser is closed.

Any time there is a User interact Steps showing views to the user the user could close the browser.

To take account of this in each case it is necessary to trap the runtime event of the user closing the browser and then goto the step:
Remove Declined Record
to ensure that the previously entered data is deleted.

For example with the User Interact Step "Confirmation Message View"

In the Next Steps applet there is one record:

Event Object Type: Applet
Event Object: User Registration Confirmation Msg Applet
SubEvent: FrameEventMethodContinue

An additional record can be added like:

Event Object Type: Application
Event: ** choose something suitable ** WebSessionEnd
Event Object: Siebel eChannel
Next Step: Remove Declined Record

This is for example purposes only and all code must be thoroughly tested before being deployed.

The following Change Request has been raised as a product defect to address this behavior:

12-O4N7F0 Include runtime event to trap user closing browser in User Registration Workflow

All change requests are reviewed and prioritized by Siebel for possible inclusion in a future release.

No comments:

Post a Comment