Applies to:
Siebel System Software - Version 7.7 [18026] BETA and later
Information in this document applies to any platform.
Reviewed for Currency 13-NOV-2009
***Checked for relevance on 27-SEP-2012***
Symptoms
When attempting a password change from the Siebel application via the
LDAP Security Adapter (LDAPSecAdpt), the user is presented with the
following error:
"SBL-SEC-10018: Insufficient access error"
This occurs if the PropagateChange parameter is set to true and in both administration and customer facing screens.
If security adapter logging is set to 5 for the impacted application
object manager (AOM), the following information will be noted:
EventContext EvtCtxApplet 4 0 2008-01-28 15:19:11 Change Password Applet (SWE) (WritePassword)
SecAdptLog API Trace 4 0 2008-01-28 15:19:11 LDAP SecuritySetUserInfo8,
Security User=116cef88, username=USER1, Security User Info=116785d0.
SecAdptLog API Trace 4 0 2008-01-28 15:19:11 Security Adapter User Set User Info. User name=USER1, User Info=116785d0.
SecAdptLog API Trace 4 0 2008-01-28 15:19:11 Security Adapter User ChangePassword() user=USER1
SecAdptLog API Trace 4 0 2008-01-28 15:19:11 Bind to LDAP server
LDAPServer10 with dn=uid=appuser,ou=people,dc=domain1,dc=intranet.
SecAdptLog API Trace 4 0 2008-01-28 15:19:11 Ldap Utility: GetLdapHandle
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 ldap_init(srvti110, 389) returns c24bf8.
SecAdptLog API Trace 4 0 2008-01-28 15:19:11 Ldap Utility: GetLdapHandle returns 0
SecAdptLog API Trace 4 0 2008-01-28 15:19:11 Ldap Utility: BindAsAppUser
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11
ldap_simple_bind_s(c24bf8, uid=appuser,ou=people,dc=domain1,dc=intranet,
*) returns 0
SecAdptLog API Trace 4 0 2008-01-28 15:19:11 Ldap Utility: BindAsAppUser succeeded,
SecAdptLog API Trace 4 0 2008-01-28 15:19:11 Ldap Utility: GetUserDn.
Username=USER1, Attribute=uid, BaseDN=ou=people,dc=domain1,dc=intranet
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 ldap_search_s(c24bf8,
ou=people,dc=domain1,dc=intranet, LDAP_SCOPE_BASE, (uid=USER1), ...)
returns 0.
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 ldap_count_entries(c24bf8, c27958) returns 1.
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 ldap_first_entry(c24bf8, c27958) returns c27958.
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 ldap_get_dn(c24bf8,
c27958) returns uid=USER1,ou=People,dc=domain1,dc=intranet.
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 ldap_memfree (c27cf8)
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 ldap_msgfree (c27958)
SecAdptLog API Trace 4 0 2008-01-28 15:19:11 Ldap Utility: UpdatePassword
SecAdptLog API Trace 4 0 2008-01-28 15:19:11 Ldap Utility: SetSunOnePassword
SecAdptLog API Trace 4 0 2008-01-28 15:19:11 Ldap Utility: SetUserAttr
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11
ldap_search_ext_s(c24bf8, uid=USER1,ou=People,dc=domain1,dc=intranet,
LDAP_SCOPE_BASE, (objectclass=*), ..., c27920) returns 0.
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11
ldap_modify_ext_s(c24bf8, uid=USER1,ou=People,dc=domain1,dc=intranet,
d4ed0c0, NULL, NULL) returns 50.
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 mods d4ed0c0:
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 mods[0]:
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 type=userPassword
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 op=2
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 values=
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 *
SecAdptLog API Trace 4 0 2008-01-28 15:19:11 Ldap Utility: GetSunOneUpdatePasswordErr
SecAdptLog API Trace 4 0 2008-01-28 15:19:11 Ldap Utility: GetSunOneUserPwdPolicy
SecAdptLog API Trace 4 0 2008-01-28 15:19:11 Ldap Utility: GetUserAttr
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11
ldap_search_ext_s(c24bf8, uid=USER1,ou=People,dc=domain1,dc=intranet,
LDAP_SCOPE_BASE, (objectclass=*), ..., c28570) returns 0.
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 ldap_first_entry(c24bf8, c28570) returns c28570.
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 ldap_get_values(c24bf8, c28570, passwordpolicysubentry) returns 0.
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 ldap_msgfree (c28570)
SecAdptLog API Trace 4 0 2008-01-28 15:19:11 Ldap Utility: GetUserAttr
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11
ldap_search_ext_s(c24bf8, cn=Password Policy,cn=config, LDAP_SCOPE_BASE,
(objectclass=*), ..., c28770) returns 32.
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 ldap_msgfree (c28770)
SecAdptLog API Trace 4 0 2008-01-28 15:19:11 Ldap Utility: GetUserAttr
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11
ldap_search_ext_s(c24bf8, cn=config, LDAP_SCOPE_BASE, (objectclass=*),
..., c28770) returns 0.
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 ldap_first_entry(c24bf8, c28770) returns 0.
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 ldap_msgfree (c28770)
SecAdptLog API Trace 4 0 2008-01-28 15:19:11 Unbind from LDAP server.
SecAdptLog 3rdpartyTrace 3 0 2008-01-28 15:19:11 ldap_unbind(c24bf8) returns 0.
SecAdptLog Memory Mgmt Trace 5 0 2008-01-28 15:19:11 LDAP SecurityFreeErrMessage8, ErrMessage=11677400.
GenericLog GenericError 1 0 2008-01-28 15:19:11 (secmgr.cpp (3825) err=7010018 sys=0) SBL-SEC-10018: Insufficient access
USER1 is the user whose password you are trying to change. The "SBL-SEC-10018: Insufficient access"
message is clearly visible at the end of the log segment.
Cause
As the error indicates, the problem is being caused by a user having
insufficient access rights in the LDAP directory to change a user's
password. The user in question will generally be the ApplicationUser
specified in the LDAPSecAdpt profile, but can be confirmed by scanning
up from the error to the first "ldap_simple_bind" statement you
encounter. This is the userID that is binding to the LDAP directory and
the one which needs the correct privileges to process the password
change. In our example, it is
"uid=appuser,ou=people,dc=domain1,dc=intranet" (the ApplicationUser from
the LDAPSecAdpt profile).
Since insufficient access type errors can have multiple causes, it is
also helpful to note the specific LDAP return code on the following
line:
ldap_modify_ext_s(c24bf8, uid=USER1,ou=People,dc=domain1,dc=intranet, d4ed0c0, NULL, NULL) returns 50.
The "50" is a generic LDAP standard message for insufficient access privileges.
Solution
The solution to this error is to make sure that the bind user
specified (generally the ApplicationUser from the LDAPSecAdpt profile)
has been granted adequate privileges to the specific container or BaseDN
where the user whose password you are changing resides in the LDAP
directory. For specific instructions on how to do this, please consult
the documentation for the LDAP directory server software you are using.
Applies to:
Siebel CRM - Version: 7.8.2.10 SIA [19241] to 8.0.0.2 SIA [20412] - Release: V7 to V8
Siebel Call Center - Version: 7.8.2.10 SIA [19241] to 8.0.0.2 [20412] [Release: V7 to V8]
z*OBSOLETE: Microsoft Windows Server 2003 R2 (32-bit)
Symptoms
Statement of what the issue is
I understand you are having a problem where users accessing the application via the web client can't log in.
Problem was :'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.[05:25:20] '.
We are not having any issue on web server, gateway server and
siebel servers. we bounced all ther servers but despite the application
is not coming up.
customer was using LDAP
Changes
No changes made
Cause
cause determination
cause was determined as directory search from
BaseDN causing the administratie locks on the userid. which caused the
whole production to go down
cause justification
the log file capture ERMAdminObjMgr_enu_14657.log has the folllowing
SecAdptLog Debug 5 0 2008-10-03 11:10:33 LDAP SecurityLogin8 step 1: initialize ldap server connection
SecAdptLog 3rdpartyTrace 3 0 2008-10-03 11:10:33 ldap_init(ldap.cisco.com, 389) returns d24be0
SecAdptLog Debug 5 0 2008-10-03 11:10:33 LDAP SecurityLogin8 step 2: initial bind to ldap server
SecAdptLog
3rdpartyTrace 3 0 2008-10-03 11:10:34 ldap_simple_bind_s(d24be0,
uid=HRSiebelLogin,ou=applications,o=cisco.com, *) returns 0
SecAdptLog Debug 5 0 2008-10-03 11:10:34 LDAP SecurityLogin8 step 3: check for single sign on
SecAdptLog Debug 5 0 2008-10-03 11:10:34 LDAP SecurityLogin8 step 4: check for trust token if SSO is on.
SecAdptLog Debug 5 0 2008-10-03 11:10:34 LDAP SecurityLogin8 step 5: set siebeUsername/siebelUserDn
SecAdptLog
API Trace 4 0 2008-10-03 11:10:34 Ldap Utility: Get User DN.
Username=HRSiebelLogin, Attribute=uid, BaseDN=o=cisco.com
SecAdptLog
3rdpartyTrace 3 0 2008-10-03 11:10:36 ldap_search_s(d24be0, o=cisco.com,
LDAP_SCOPE_SUBTREE, (uid=HRSiebelLogin), 244e080, 1) returns 11.
SecAdptLog Memory Mgmt Trace 5 0 2008-10-03 11:10:36 LDAP SecurityFreeErrMessage8, ErrMessage=6e92fc0.
GenericLog
GenericError 1 0 2008-10-03 11:10:36 (secmgr.cpp (2357) err=7010018
sys=0) SBL-SEC-10018: Administration limit exceeded
GenericLog
GenericError 1 0 2008-10-03 11:10:36 (secmgr.cpp (2429) 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.
ObjMgrCTLog Error 1 0 2008-10-03 11:10:36 (ctxtmgr.cpp (3435)) SBL-SVC-00208: Please login first.
Solution
Solution
our suggestion is not to have any restrictions at BaseDN
level atleast. anything below, you can have the limits based on your
testing and results.
but any specific number or anything related
to limitation, has to be done by you . it is beyond the scope of Siebel
TS to say anyspecific limit or setup because the hit from userbase is
not well known or well defined at one point of time. it will keep
changing
Applies to:
Siebel System Software - Version 8.0 [20405] and later
Information in this document applies to any platform.
***Checked for relevance on 27-SEP-2012***
Symptoms
When using the LDAPSecAdpt to authenticate against an Active
Directory server with the BaseDN set to the root level, the Siebel
application will not come up. Examination of the Security Adapter logs
shows an error pattern similar to the following when trying to search
for the UserDN:
SecAdptLog API Trace 4 000000084a7719a0:0 2009-08-03 16:38:07 Ldap
Utility: GetUserDn. Username=ANONUSER, Attribute=sAMAccountName,
BaseDN=DC=xxxx,DC=xxxx
SecAdptLog 3rdpartyTrace 3 000000084a7719a0:0 2009-08-03 16:38:08
ldap_search_s(1094aa0, DC=thcg,DC=net, LDAP_SCOPE_BASE,
(sAMAccountName=ANONUSER), ...) returns 1.
SecAdptLog 3rdpartyTrace 3 000000084a7719a0:0 2009-08-03 16:38:08 ldap_msgfree (10957f8)
SecAdptLog 3rdpartyTrace 3 000000084a7719a0:0 2009-08-03 16:38:08 ldap_unbind(1094aa0) returns 0.
SecAdptLog Memory Mgmt Trace 5 000000084a7719a0:0 2009-08-03 16:38:08 LDAP SecurityFreeErrMessage8, ErrMessage=c822828.
GenericLog GenericError 1 000000084a7719a0:0 2009-08-03 16:38:08
(secmgr.cpp (2486) err=4597538 sys=0) SBL-SEC-10018: Operations error
GenericLog GenericError 1 000000084a7719a0:0 2009-08-03 16:38:08
(secmgr.cpp (2558) err=4597521 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.
ObjMgrSessionLog Error 1 000000084a7719a0:0 2009-08-03 16:38:08
(physmod.cpp (9244)) SBL-DAT-00565: An internal error has occurred
within the authentication subsystem for the Siebel application. Please
contact your system administrator for assistance.
ObjMgrSessionLog Error 1 000000084a7719a0:0 2009-08-03 16:38:08
(model.cpp (5886)) SBL-DAT-00565: An internal error has occurred within
the authentication subsystem for the Siebel application. Please contact
your system administrator for assistance.
ObjMgrCTLog Error 1 000000084a7719a0:0 2009-08-03 16:38:08 (ctxtmgr.cpp (4493)) SBL-SVC-00208: Please login first.
Cause
This behavior is being caused by how the LDAPSecAdpt, IBM LDAP Client
libraries, and the Windows 2003 based Active Directory are interracting
when the BaseDN is set to the root level. The fundamental issue is that
Windows 2003 introduced stricter authentication/authorization
requirements when attempting to access certain parts of the overall
schema and resources.
When you do an LDAP search from the root of the Active Directory, you
are searching everything under the root. This includes not only things
like Organizational Units, Computers, etc.; but also fundamental
configuration and schema entities such as:
DC=Configuration,DC=domain,DC=net
DC=DomainDnsZones,DC=domain,DC=net
It is the fact that the application user does not have adequate access to these types of entities that is causing the behavior.
Solution
This behavior is due to the fact that the LDAPSecAdpt is attempting
to search hidden/system containers to which it does not have access.
Since you are not using PropagateChange=True to make changes to the AD
from the Siebel application and the Active Directory in question has
Global Catalog functionality enabled, the best workaround at this time
is to point the LDAPSecAdpt to the Global Catalog port of 3268.
1. Login to an employee facing, high interactivity Siebel application (e.g. Sales, Call Center, etc.) as an administrator.
2. Navigate to Site Map > Administration - Server Configuration > Enterprises > Profile Configuration.
3. Make sure the correct Siebel Enterprise is selected in the top applet.
4. In the middle applet query for LDAPSecAdpt (or whatever name you have given your LDAP Security Adapter).
5. In the bottom applet find the Port parameter and change it to 3268.
6. Step off to save the change and logout of the Siebel application.
7. Stop and restart the Siebel Server service(s) and the Siebel Gateway service.
There are limitations when using the Global Catalog with Siebel. In
summary, you have to set the PropagateChange parameter on the
LDAPSecAdpt to False. This means you will not be able to update anything
in the Active Directory (for example passwords) from the Siebel
application. For more in-depth information, please see the following on
My Oracle Support:
"ADSI Authentication Using Global Catalog Port 3268 (Doc ID 517259.1)"
"With Windows Integrated Authentication based SSO, can we have users from multiple domains? (Doc ID 834759.1)"
If you require PropagateChange = True in your implementation, then
the Global Catalog workaround above will not work. There are several
options in this case:
- If your Siebel application servers are running on a Windows operating system, you could switch to the ADSISecAdpt.
- Drop the BaseDN down one level. It is important that all the Siebel
users (including the anonymous user in eapps.cfg) be in or under the
BaseDN your specify. - Make the application user specified in the LDAPSecAdpt's
ApplicationUser parameter a Domain Administrator within the Active
Directory.
Applies to:
Siebel CRM - Version 8.1.1 SIA [21111] and later
Generic Linux
Generic UNIX
Affected Database: Oracle
""Checked for Relevance on 11-09-2012""
Symptoms
start_server script (for staring Siebel Server) or srvrmgr command
may fail and the error message in NameSrvr.log file indicates "
SBL-SEC-10007: The password you have entered is not correct. Please
enter your password again." while the same user/password combination
works on SQLPlus.
Cause
In Siebel 8.1.x, Siebel Gateway Server (GtwySrvr) authenticates the
user who attempts to connect to GtwySrvr. In standard setting, GtwySrvr
performs database authentication against the user. Using Oracle
database, $ORACLE_HOME/lib (or $ORACLE_HOME/lib32 when Oracle Database
Server is 64 bit) must be part of the shared libraries for GtwySrvr
process (siebsvc). If it is not set correctly, starting Siebel Server
(start_server script) or launching srvrmgr will fail with following
errors..
1) start_server
- On terminal window, it does not show any error but list_server scripts reveals it is stopped in a few seconds.
- SiebSrvr.log under siebsrvr/log directory shows following error.
SBL-SCC-00005: Internal:No more items found.
SBL-SVR-01045: No components are configured.
SBL-SVR-00005: Stale or invalid Task handle
scfEventFac::s_pEvtFacLock is NULL and hence SCF event facility cannot be initialised
SBL-SVR-09149: Could not initialize the event facility.
SCFMessageFacility::s_pSCFMsgFacLock is null and hence the SCFMessageFacility cannot be initialized
ipcFacility GetInstance called before initialization - object is null
SBL-SVR-00029: Internal: Shared memory has not been initialized.
- NameSrvr.log under gtwysrvr/log directory shows following error.
SBL-SEC-10018: 523 80
SBL-SEC-10007: The password you have entered is not correct. Please enter your password again.
2) srvrmgr command
- On terminal windows, error message "Fatal error (2555922): Could not
open connection to Siebel Gateway configuration store" is shown.
- srvrmgr.log under siebsrvr/log directory shows following error.
NSS - ErrCode 4597527 SysErr 0
SBL-SCM-00018: Could not open connection to Siebel Gateway configuration store (GATEWAY SERVER HOST:GATEWAY SERVER PORT).
GATEWAY SERVER HOST = Host name for Siebel Gateway Server
GATEWAY SERVER PORT = Port number to connect to Siebel gateway Server
- NameSrvr.log under gtwysrvr/log directory shows following error.
SBL-SEC-10018: 523 80
SBL-SEC-10007: The password you have entered is not correct. Please enter your password again.
** Please note key messages is "SBL-SEC-10018: 523 80" in NameSrvr.log.
If this error is NOT recorded, this is really password problem.
Solution
Please make sure to set $ORACLE_HOME/lib in LIBPATH (AIX), SHLIB_PATH
(HP-UX), or LD_LIBRARY_PATH (Linux, Solaris) variables before start_ns
is run.
Applies to:
Siebel CRM - Version: 8.1.1 [21112] and later [Release: V8 and later ]
Information in this document applies to any platform.
Symptoms
Customer is unable to see the login screen and the following errors are found in the OM log:
SecAdptLog API Trace 4 000000034d3520f3:0 2011-01-18 15:11:32 DB SecurityLogin with username=SADMIN, parameters=3ae0e00.
SecAdptLog Debug 5 000000034d3520f3:0 2011-01-18 15:11:32 DB security adapter: Load data source configuration
ObjMgrDBConnLog
Create 5 000000034d3520f3:0 2011-01-18 15:11:33 DataBase Connection
Object was created at 3cdeb90; DB User: 'SADMIN'
ObjMgrLog Error 1
000000034d3520f3:0 2011-01-18 15:11:33 (oracon.cpp (3122))
SBL-DBC-00107: An Oracle database error has occurred.
Please continue or ask your systems administrator to check your application configuration if the problem persists.
SecAdptLog
API Trace 4 000000034d3520f3:0 2011-01-18 15:11:33 Security DB user
connect to DB CRM with username=SADMIN returns err 65535 and connection
3cdeb90.
SecAdptLog API Trace 4 000000034d3520f3:0 2011-01-18 15:11:33 Security DB user delete DB connectoin 3cdeb90
ObjMgrDBConnLog Delete 5 000000034d3520f3:0 2011-01-18 15:11:33 DataBase Connection was deleted at 3cdeb90
GenericLog
GenericError 1 000000034d3520f3:0 2011-01-18 15:11:33 (secmgr.cpp
(2676) err=4597538 sys=0) SBL-SEC-10018: An Oracle database error has
occurred.
Please continue or ask your systems administrator to check
your application configuration if the problem persists.(SBL-DBC-00107)
SecAdptLog Memory Mgmt Trace 5 000000034d3520f3:0 2011-01-18 15:11:33 DB SecurityFreeErrMessage, message=<?INT?>.
GenericLog
GenericError 1 000000034d3520f3:0 2011-01-18 15:11:33 (secmgr.cpp
(2750) err=4597521 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.
ObjMgrSessionLog
Error 1 000000034d3520f3:0 2011-01-18 15:11:33 (physmod.cpp (9330))
SBL-DAT-00565: An internal error has occurred within the authentication
subsystem for the Siebel application. Please contact your system
administrator for assistance.
ObjMgrSessionLog Error 1
000000034d3520f3:0 2011-01-18 15:11:33 (model.cpp (5890)) SBL-DAT-00565:
An internal error has occurred within the authentication subsystem for
the Siebel application. Please contact your system administrator for
assistance.
ObjMgrSessionLog ObjMgrLogin 3 000000034d3520f3:0 2011-01-18 15:11:33 Login failed for Login name : SADMIN
Cause
During the investigation, the customer confirmed that they are able to
connect using sqlplus and odbcsql with the SADMIN credentials. However,
the login page does not appear.
Subsequent investigation reveals
that customer has installed an Oracle DatavaseInstant Client instead of a
full version of the Oracle database client software.
Solution
1. Request customer to download the 'Oracle Database 11g Release 2 Client (11.2.0.1.0) for HP-UX Itanium
hpia64_11gR2_client32.zip (32-bit)' from
http://www.oracle.com/technetwork/database/enterprise-edition/downloads/112010-hpisoft-097214.html
2. Install the Oracle client package and set the SHLIB_PATH before restarting the Siebel Services
References
NOTE:476703.1
- What Are the Steps To Troubleshoot the Error Message: The Server You
Are Accessing is Either Busy or Experiencing Difficulties...in a Siebel
Web Client User Browser?
NOTE:1085793.1
- Servers won't start; gateway throws error: "Fatal error (2555922):
Could not open connection to Siebel Gateway configuration store"
Applies to:
Siebel System Software - Version 7.7.2.6 [18372] and later
z*OBSOLETE: Microsoft Windows Server 2003
Product Release: V7 (Professional)
Version: 7.7.2.6 [18372]
Database: Microsoft SQL Server 2000 SP4
Application Server OS: Microsoft Windows 2003 Server SP1
Database Server OS: Microsoft Windows 2003 Server SP1
This document was previously published as Siebel SR 38-3402328041.
Symptoms
Inbound HTTP requests are received to create Activities for Service
Requests. This works as expected in test environments, but fails in
production.
The error message received from external application is :-
"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"
The error in the EAIObjMgr log :-
GenericLog GenericError 1 0 2007-07-16 15:59:57 (secmgr.cpp (2288)
err=7010018 sys=0) SBL-SEC-10018: You have entered an invalid set of
logon parameters. Please type in your logon parameters
again.(SBL-DAT-00446)
GenericLog GenericError 1 0 2007-07-16 15:59:57 (secmgr.cpp (2344)
err=7010007 sys=0) SBL-SEC-10007: The password you have entered is not
correct. Please enter your password again.Corresponding error in the SWSE log :-
SisnTcpIp SisnSockError 1 0
2007-07-16 15:59:57 1968: [TCPIP-client] recv() failed for sd=2308
(err=10054 | An existing connection was forcibly closed by the remote
host (peer).)
GenericLog GenericError 1 0 2007-07-16 15:59:57 (smconn.cpp (430) err=1801023 sys=0) SBL-NET-01023: Peer disconnected
ObjMgrSessionLog Error 1 0 2007-07-16 15:59:58 Login failed for Login name : pse
ProcessPluginState ProcessPluginStateError 1 0 2007-07-16 15:59:58 1968:
[SWSE] Open Session failed (0x5a94) after 0.0602 seconds.
ProcessPluginRequest ProcessPluginRequestError 1 0 2007-07-16
15:59:58 1968: [SWSE] Failed to obtain a session ID. The password you
have entered is not correct. Please enter your password again.
ProcessPluginRequest ProcessPluginRequestError 1 0 2007-07-16
15:59:58 1968: [SWSE] Set Error Response (Session: Error: 00023188
Message: The password you have entered is not correct. Please enter your
password again.)
Cause
The issue was with the password. There was a $ sign in the password
and XML was not reading the password correctly (the $ was being
escaped).
Solution
Customer changed the password and the inbound requests worked as expected.
Applies to:
Siebel System Software - Version: 8.1.1.2 and later [Release: V8 and later ]
Information in this document applies to any platform.
Symptoms
Customer has enabled SSL between a LDAPSecAdpt OM and Active Directory
server. However, they encountered the following errors when they perform
a password change and the password contains a special character (e.g.
@) at the end of the new password:
SecAdptLog 3rdpartyTrace 3
000001bb4d0b3e01:0 2010-12-17 21:46:46 ldap_modify_ext_s(a0836c8,
CN=user1,OU=App ID,DC=siebdev,DC=hq, ec4fa88c, NULL, NULL) returns 19.
..
GenericLog
GenericError 1 000001bb4d0b3e01:0 2010-12-17 21:46:46 (secmgr.cpp
(4635) err=4597538 sys=0) SBL-SEC-10018: Constraint violation
GenericLog
GenericError 1 000001bb4d0b3e01:0 2010-12-17 21:46:46 (secmgr.cpp
(4699) err=4597530 sys=0) SBL-SEC-10010: The requested password does not
conform to our password policy. Please review password requirements and
select a new password.
The customer verified that they are able
to change the user's password directly in the Active Directory when
using the same new password.
Cause
Oracle Technical Support is able to reproduce the same behavior in house
when using a LDAPSecAdpt enabled OM. However, if a ADSISecAdpt enabled
OM is used, the password change is successful.
After discussion with internal resources, this is determined to be a limitation on the IBM LDAP Client.
Solution
In this case, the customer is advised to prevent the usage of special characters in their password.
Applies to:
Siebel System Software - Version: 7.7.2.7 SIA [18376] to 8.1.1 [21112] - Release: V7 to V8
Information in this document applies to any platform.
Symptoms
Customer is trying to bind to an Active Directory server using the ADSISecAdpt and is getting the following errors:
SBL-SEC-10018: Unable to bind to the ADSI object 'LDAP://bose.com/DC=bose,DC=com'.(SBL-DAT-00705)
SBL-SEC-10001:
An internal error has occurred within the authentication subsystem for
the Siebel application. Please contact your system administrator for
assistance.
SBL-SVC-00208: Please login first.
Review of the ADSI return code shows a return of 8007052e.
Cause
The application user password specified in the ADSISecAdptADSISecAdpt profile is incorrect.
Specific observations made in this case that support this finding were:
1. The return error code 8007052e is an invalid user DN or password error.
2. All other relevant parameters in the ADSISecAdptADSISecAdpt match between a working environment and the non-working environment.
3.
The encrypted values of the application user password parameter are
different in the two environments. This can be checked by reviewing the
siebns.dat file in a text editor and searching for ADSISecAdptADSISecAdpt and finding the password parameter.
Solution
This behavior can be corrected by fixing the application user password in the ADSISecAdpt profile. To do this:
1. Login to an employee facing application as SADMIN or another user with administrative responsibilities.
2. Navigate to Site Map > Administration - Server Configuration > Enterprises > Profile Configuration
3. Locate the ADSISecAdpt profile.
4. Locate the Application User Password parameter.
5. Carefully re-enter the password for the application user in plain text (the system will automatically encrypt it).
6. Save the record.
Then
close out of all browser windows (to make sure you get a clean object
manager task) and retest the behavior. If it still gives the error, you
may want to stop and restart the Siebel Server and Gateway services to
make sure the new values loaded properly.
Applies to:
Siebel CRM - Version: 8.1.1.4 SIA [21225] and later [Release: V8 and later ]
Information in this document applies to any platform.
Symptoms
Customer is attempting to implement a web single sign-on (SSO) solution
using the standard LDAPSecAdpt in Siebel 8.1.1.4. The SSO system is
providing the Siebel login via an HTTP header variable in a supported
manner. The process is not successful and the following is showing up
in the application object manager log:
SBL-SEC-10018: Trust token mismatch
Customer has verified and re-entered the TrustToken parameter in both
the security adapter profile and the appropriate virtual directory entry
in the eapps.cfg file. Also the EncryptPassword parameter in eapps.cfg
is set to FALSE.
Desired behavior is that the user should successfully authenticate into Siebel via the SSO system.
Cause
Behavior was caused by the presence of multiple
ProtectedVirtualDirectory parameter entries in the eapps.cfg file
pointed to the same location. As a result the process was going to the
wrong location in the eapps.cfg file and pulled back an invalid
TrustToken.
Solution
This issue was resolved by making sure that no more than one
ProtectedVirtualDirectory parameter in the eapps.cfg and/or
eapps_sia.cfg files were pointed to the same virtual directory (for
example: [/sales_enu]).
After making changes to the eapps.cfg or
eapps_sia.cfg file, make sure to stop and restart the web services so
that the changes are fully implemented.
Applies to:
Siebel CRM - Version: 8.1.1.1 [21211] and later [Release: V8 and later ]
Information in this document applies to any platform.
Symptoms
Siebel server is not getting started and gateway server is already
started. While checing the namesrvr.log found the error below.
1
000000024f061e2c:0 2012-01-06 11:24:26 (secmgr.cpp (2679) err=4597538
sys=0) SBL-SEC-10018: data source connect string or table owner is
empty.
GenericLog GenericError 1 000000024f061e2c:0 2012-01-06
11:24:26 (secmgr.cpp (2751) err=4597521 sys=0) SBL-SEC-10001: An
internal error has occurred within the authentication subsystem for the
Siebel application. Please contact yo
Cause
After further investigation found that, gateway service file got
corrupted and below are the entries in svc.gtwyns and here gatewya.cfg
file is missing in below line.
siebsvc -s gtwyns -a "/f /siebel/gtwysrvr/sys/siebns.dat /t 2320 "
Solution
Recreate gateway service file again with the below command.
1. Stop Gateway server.
2.siebctl -S gtwyns -a -g "/f /siebel/gtwysrvr/sys/siebns.dat /t 2320 /c /siebel/gtwysrvr/bin/gateway.cfg"
3. Restart the gateway server and siebel server services.
Applies to:
Siebel Public Sector Service - Version 8.1.1.4 SIA [21225] and later
IBM AIX on POWER Systems (64-bit)
Symptoms
Customer Environment:
8.1.1.4 SIA [21225], IBM AIX on POWER Systems (64-bit) 6.1 and DB on DB2
Unable access URL after completing installation
------------------------------------------------------
1. After successful completion of installation and configuration, user not able to access URL
2. Its throwing error "The server you are trying to access is either busy or experiencing difficulties."
"The server you are trying to access is either busy or experiencing difficulties."
SBL-GEN-02500,SBL-SEC-10018
Cause
===Cause Determination ===
1. Incorrect ODBC Datasource name for server configuration, configured
server host name under datasource parameter in profile configuration
2. Incorrect LIB path version settings ( 64 bit instead of 32- bit ) where siebel supports only 32-bit library paths
===Cause Justification ===
1. Exact error with caused issue:
SecAdptLog Debug 5 000000104dd600f0:0 2011-05-20 11:31:45 DB security
adapter: Could not load or initialize data source ServerDataSrc,
err=65535.
SecAdptLog API Trace 4 000000104dd600f0:0 2011-05-20 11:31:45 Security DB user delete DB connectoin 0
GenericLog GenericError 1 000000104dd600f0:0 2011-05-20 11:31:45
(secmgr.cpp (2679) err=4597538 sys=0) SBL-SEC-10018: Can't load
sscddcli(SBL-GEN-02500)
2. Defined the same LIB support for Siebel application in a 32 Bit
Libraries Are Not Installed With Oracle11g (11.1.0.6) On HP-UX Itanium
(Doc ID 471476.1) , but as verified users environment found few other
configuration issues which need to be corrected
Solution
1. EDIT LIBPATH and add 32-bit LIB path where database client installed
2. login to apps via dedicated client and change Data source Connect
String parameter from server name to real data source under profile
configuration which specified in .odbc.ini file parameter will end with
_DSN.
3. Recycle Siebel enterprise
4. Launch application and check for URL status
Applies to:
Siebel System Software - Version 7.7.2 [18325] to 8.0.0.5 [20420] - DO NOT USE [Release V7 to V8]
All Platforms
This document was previously published as Siebel SR 38-1715068851.
Symptoms
Customer was implementing Password Hashing, and after changing
parameter DSHashUserPwd in Server Data Source named subsystem to “TRUE”
and restarting the Siebel environment, the following components did not
start:
PDbXtract/DbXtract
SSEObjMgr_enu
WfProcBatchMgr
WfProcMgr
WfRecvMgr
WfRecvMgr, WfProcMgr, and WfProcBatchMgr had the following error messages:
SBL-SEC-10007: The password you have entered is not correct. Please enter your password again. (0x5a94))
SBL-SEC-10018: You have entered an invalid set of logon parameters. Please type in your logon parameters again.(SBL-DAT-00446)
SBL-SVR-00040: Internal: Informational, encrypted parameter. (0x5a8f))
SBL-OMS-00107: Object manager error: ([2] SBL-SVR-00040: Internal: Informational, encrypted parameter. (0x5a8f))
SBL-OMS-00107: Object manager error: ([1] SBL-SEC-10018: You have
entered an invalid set of logon parameters. Please type in your logon
parameters again.(SBL-DAT-00446)
ORA-01017: invalid username/password; logon denied
SBL-OMS-00107: Object manager error: ([0] SBL-SEC-10007: The password
you have entered is not correct. Please enter your password again.
(0x5a94))
SBL-OMS-00102: Error 23188 logging in to the application
SSEObjMgr had the following error messages:
SBL-DAT-00446: You have entered an invalid set of logon parameters. Please type in your logon parameters again.
SBL-SEC-10018: You have entered an invalid set of logon parameters. Please type in your logon parameters again.(SBL-DAT-00446)
ORA-01017: invalid username/password; logon denied
Components PDbXtract (during server startup) and DbXtract (at component task start) had the following error message:
SBL-GEN-04031: Internal: Error occurred during base64 decoding.
Cause
1. Password parameter for the above components should be set to
unhashed password as per Siebel Bookshelf > Security Guide >
Security Adapter Authentication > Configuring Password Hashing.
2. Error message SBL-GEN-04031 in PDbXtract and DbXtract log files
occur because the password length is greater than 21 characters. If
SADMIN password has more than 21 characters, PDbXtract and DbXtract
components will fail with the error message.
The SADMIN password was hashed using the RSA SHA-1 encryption algorithm.
When using SADMIN as password in test environment, the hashed password
contained 28 characters. Since "SADMIN" is a fairly simple and short
password, we would expect that most good passwords would result in RSA
SHA-1 values that are too long.
.
Solution
1. Set the Password parameter for each component to the unhashed password for the SADMIN user and restart the environment.
2. The workaround is to change the Hashing algorithm to use Siebel Hash
instead of RSA SHA-1. Siebel Hash will encrypt passwords with a length
smaller than RSA SHA-1 algorithm. Please refer to the Security Guide
for more information about how to change encryption algorithm.
Applies to:
Siebel Server Manager - Version 8.1.1.2 SIA[21215] and later
Information in this document applies to any platform.
Symptoms
EAI OM, Loyalty Engine Component Failure occur multiple times.
(oracon.cpp (3246)) SBL-DBC-00107: An Oracle database error has occurred.
Please continue or ask your systems administrator to check your application configuration if the problem persists.
(secmgr.cpp (2679) err=4597538 sys=0) SBL-SEC-10018: An Oracle database
error has occurred. Please continue or ask your systems administrator to
check your application configuration if the problem persists.
(SBL-DBC-00107)ORA-00257: archiver error. Connect internal only, until freed.
Cause
Siebel component shows error:
(SBL-DBC-00107)ORA-00257: archiver error. Connect internal only, until freed.
The error is caused by the fact that the archiver process is unable to
archive the current online redolog due to lack of space in the
destination for the archivelogs.
Solution
The error is caused by the fact that the archiver process is unable to
archive the current online redolog due to lack of space in the
destination for the archivelogs.
- Best option is to make more space available in the archive log destination (log_archive_dest_n).
- Increased frequency of log purges.
Work with your DBA to address the above.
- Restart Siebel servers.
Applies to:
Siebel Remote - Version: 8.0.0.1 SIA [20408] and later [Release: V8 and later ]
Information in this document applies to any platform.
Symptoms
When they are trying to set up using DBF initialized in other machine, they cannot login. Log files shows the following errors:
"An internal error has occurred within the
authentication subsystem for the Siebel application. Please contact your
system administrator for assistance.(SBL-DAT-00565)"
SBL-DAT-00522: A Siebel local database error has occurred. Possibly the database name is invalid.
SBL-SEC-10018: A Siebel local database error has occurred. Possibly the database name is invalid.
Please
continue or ask your systems administrator to check your application
configuration if the problem persists.(SBL-DAT-00522)
Incorrect or missing encryption key
Cause
First of all you have to ensure you have entered the correct
encryption key, by running the following query against the server
database:
SELECT PREF_CD, VAL, s2.name FROM S_NODE_PREF s1, S_NODE s2 WHERE s1.PREF_CD ='RemLocSec:PlainKey'
AND s1.NODE_ID = s2.ROW_ID AND s2.NAME='<CLIENT NAME>';Once you get the encryption key, you have to set it in the ODBC properties.
If
you still get the "Incorrect or missing encryption key" message after
setting the correct encryption key, then the cause is you're missing the
MWC_STORAGE.CFG file in the BIN directory.
Documentation "How to Backup Tools/Local databases with Siebel 8
(Doc ID 738286.1)" explains that copying mwc_storage.cfg is a required
step to use a database previously initialized.
Solution
Technical Support Response
-------------------------------------
As per our phone conversation, I understand you ran the following query against the server database :
SELECT PREF_CD, VAL, s2.name FROM S_NODE_PREF s1, S_NODE s2 WHERE s1.PREF_CD ='RemLocSec:PlainKey'
AND s1.NODE_ID = s2.ROW_ID AND s2.NAME='';
and it returned the encryption key that you then set in the ODBC properties in the client machine.
Please,
after doing that also copy the mwc_storage.cfg file located in the BIN
folder in the client where you initialized the DB.
Also ensure the following parameters are set in the Tools configuration file ( *.CFG ):
DSDockEncryptDB=TRUE
DSHashUserPwd=TRUE
DSHashAlgorithm=RSASHA1
אין תגובות:
הוסף רשומת תגובה