SBL-DAT-00700: Unable to check flag 'Password never expires'.

Applies to:

Siebel System Software - Version: 7.7.2.6 [18372] - Release: V7
Sun Solaris 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,
Mauricio Buissa
Oracle | Siebel Technical Support

Applies to:

Siebel System Software - Version: 7.7 [18026] BETA to 8.1.1 [21112] - Release: V7 to V8
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Professional)
Version: 7.7.2.2 [18356]
Database: Oracle 9.2.0.6
Application Server OS: Microsoft Windows 2003 Server
Database Server OS: Sun Solaris 8

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

Symptoms

SBL-DAT-00700

All of a sudden this morning users started to get errors when trying to login into the system. They do not get a login page. There were a very few people that logged in and they were fine. System was not giving the users a login page.

Cause

Cause field information not migrated for legacy Siebel SupportWeb content.

Solution

Message 1

For the benefit of other readers:

This user encountered difficulties with logging in via ADSI Security Adapter Authentication. A few users were not impacted, but most were. Also this had been working fine previously. A review of the SWSE logs and object manager logs revealed errors about invalid database credentials for both the user record in question and the shared credential user (although both were populated).

Generally speaking, ADSI directory authentication is fairly stable once it is up and running properly. A sudden loss of functionality is generally due to an environmental issue such as network connectivity or an actual problem on the Active Directory itself. The other possibility is that visibility rights within the directory had been changed. This latter issue was the cause in this case. Somehow the rights on the schema got changed so that users were unable to read their own extended attributes (including the ones storing account information, database credentials, etc.). The application user still had adequate rights to see that the records existed, but no one (with the exception of some domain admins) could actually read the other attributes. As a result they looked blank which caused the process to go to the shared credential user but since they could not read the shared credential user's attributes, the process failed.

(continued)

Message 2

(continuation)

It is important to confirm that the application user and the other users (as necessary) not only can bind to and/or see basic ADSI attributes, but also that they can view the specific attributes needed per your configuration. These are often part of the extended ADSI schema whereas sAMAccountName and CN are generally part of the base schema.

Once the rights were reset to allow adequate visibility into the extended schema, the problem was resolved.

Best regards,
Steve Porter
ORACLE Support Services