Applies to:
Error Message Area:Data Manager - DATVersion:Siebel 7.5.3
Purpose
This document is intended to provide cause and corrective action information about Siebel Error Message SBL-DAT-00336: An internal error with the Security Adapter DLL has occurred. Please ask your systems administrator to check your security adapter. %1
Scope
This document is informational and intended for any user.
SBL-DAT-00336: An internal error with the Security Adapter DLL has occurred. Please ask your systems administrator to check your security adapter. %1
Explanation
Sometimes the following strings appear in place of %1:Unable to open server using Application User login
Unable to bind to domain
No such object
Bind as ApplicationUser failed
Below are some reported causes:
1. If you are implementing the Siebel LDAP security adapter and you are using the IBM LDAP client and the IBM GSKit that is currently being shipped for Siebel versions 7.5.3.4 or later, you may encounter this error with the value of the %1 being replaced with the string: Bind as ApplicationUser failed. The cause of the error is you are using the wrong version of IBM GSKit.
2. The behavior is caused by incorrect Security Adapter configuration parameters or network failures between the Siebel servers and the directory server. One of the common causes is the SharedCredentialsDB and the ApplicationUser's Distinguished name does not match.
3. A customer received this error when trying to configure their Siebel Object Manager to use Windows Integrated Authentication. The value of the %1 was reported as "The sample Security Adapter did not receive the correct Trust Token".
4. A customer had configured to use a security adapter, in this case ADSI, at the Enterprise level however for the specific Object Manager component configuration (CFG) file, it was not configured to use ADSI. When the Siebel Web clients tried to connect to that particular Object Manager, they encountered this error in the SWSE log files.
Corrective Action
Below are some things to confirm based on the above causes:1. You need to obtain the correct version of the IBM GSKit. For more information about how to obtain the specific versions, refer to Alert 1110.
2. Each string value above is discussed in the Troubleshooting Steps 56 document. Refer to this document for diagnostic steps and corrective actions information.
3. Ensure you follow the instructions in Technical Note 452 to assist with implementing Windows Integrated Authentication for the Siebel clients. Also search on SupportWeb using this specific string value for additional information.
4. For this particular scenario, the customer decided they did not want to use a security adapter in their environment. Therefore they ran the commands below to remove this from the enterprise and the specific Object Manager:
delete enterprise parameter override param SecurityAdapter
delete parameter override for component ePharmaObjMgr_enu param SecurityAdapter
If you are going to use a security adapter, then ensure the Object Manager’s CFG file is correctly configured. Follow the instructions in the Siebel Bookshelf references:
a) Siebel Bookshelf version 7.5.3 > Security Guide for Siebel eBusiness Applications > Security Adapter Authentication > Setting Up Security Adapter Authentication: A Scenario > Editing Parameter Values in the Application Configuration File.
b) Siebel Bookshelf version 7.7 > Security Guide for Siebel eBusiness Applications > Security Adapter Authentication > Setting Up Security Adapter Authentication: A Scenario > Editing Parameters in the Application Configuration File.
Applies to:
Product Release: V7 (Enterprise)Version: 7.5.2 [15051] Life Sci
Database: Oracle 9.2.0.2
Application Server OS: Microsoft Windows 2000 Server
Database Server OS: HP-UX 11i
This document was previously published as Siebel SR 38-1160203251.
Symptoms
SBL-DAT-00336Hi,
We have problems with our newly installed SWE. In the new environment, server is
working but SWE does not work.
Attached are the SWE log files. Please help.
Bill
Gong, Lan Shen
Solution
Message 1
Summary of Resolution:The error found in the SWE log file was:
GenericLog GenericLog 0 2004-01-07 21:19:03 [740] ERROR 740: [SWSE] Set Error Response (User: Session: Error: 00027665 Message: An internal error with the Security Adapter DLL has occurred. Please ask your systems administrator to check your security adapter. Unable to open server using Application User login.(SBL-DAT-00336))
This meant that the Object Manager was using a Security Adapter and this may not be set properly.
A review of siebns.dat file showed that ADSI is being used at the enterprise level as well as by ePharmaObjMgr_enu. A review of the epharma.cfg file showed that ADSI was not being used. The customer confirmed the latter.
The customer was then asked to use srvrmgr command line to remove the ADSI entry in SecurityAdapter. Running srvrmgr resulted in a 'login failed' error.
This was due to not having the datasource Siebsrvr_<enterprise> set correctly in the System DSN. This DSN was different from the one used in epharma.cfg file. It was made sure that both these were able to connect using odbcsql.exe.
Once done, the following srvrmgr commands were run to clean the SecurityAdapter entry in the environment:
delete enterprise parameter override param SecurityAdapter
delete parameter override for component ePharmaObjMgr_enu param SecurityAdapter
After an environment restart, everything was working fine.
Thank you.
Applies to:
Product Release: V7 (Enterprise)Version: 7.5.3.2 [16168]
Database: Microsoft SQL Server 2000
Application Server OS: Microsoft Windows 2000 Advanced Server SP 3
Database Server OS: Microsoft Windows 2000 Advanced Server SP 3
This document was previously published as Siebel SR 38-1227793227.
Symptoms
SBL-UIF-00243, SBL-DAT-00254, SBL-DAT-00336After discussing with our Siebel Tech Arch Team, it is important to note that we are using a
custom Security Adapter DLL which was created from Technote 452 in order to enable Windows
Integrated Authentication.
According to Technote 452, a trust token verification is done,
and when we post via HTTPS to the Siebel URL with the login credentials:
We are posting
to:
https://DCDDIAAPV05/trn_enu/start.swe?SWEExtSource=WFMIIS&SWEExtCmd=Execute&Password=DIATRUSTTOKEN&SWEExt
we
get the following
error:
GenericLog GenericLog 0 2004-03-24
14:06:16 [9788] ERROR 9788: [SWSE] Open
Session failed (0x6c11) after 0.0717 seconds.
GenericLog GenericLog 0 2004-03-24
14:06:16 [9788] ERROR 9788: [SWSE]
Impersonate failed. An internal error with the Security Adapter DLL has occurred. Please ask your
systems administrator to check your security adapter. %1
GenericLog GenericLog 0 2004-03-24
14:06:16 [9788] ERROR 9788: [SWSE] Set Error
Response (User: Session: Error: 00027665 Message: An internal error with the Security Adapter DLL
has occurred. Please ask your systems administrator to check your security adapter. The sample
Security Adapter did not receive the correct Trust Token.(SBL-DAT-00336))
GenericLog GenericLog 0 2004-03-24
14:06:16 [9788] ERROR 9788: [SWSE] Error
Child Messages : <0> An internal error with the Security Adapter DLL has occurred. Please
ask your systems administrator to check your security adapter. The sample Security Adapter did
not receive the correct Trust Token.(SBL-DAT-00336)
GenericLog GenericLog 0 2004-03-24
14:06:16 [9788] ERROR 9788: [SWSE] HTTP
Status 500 : Error The service request could not be processed. Please check that the user name
and password are correct, and that the request format is correct. If the problem persists, please
contact the system administrator to get more detailed information and to check the syst
Solution
Message 1
The customer was implementing EAI HTTP inbound using Microsoft BizTalk to invoke a Work Flow process in the Siebel Application. The customer wanted to use Windows Integrated Authentication for this request to the EAI Object Manager server component. The customer has successfully implemented Windows Integrated Authentication for the ERM Object Manager component using Technical Note 452: “Implementing Windows integrated authentication for Siebel 7 clients” from SupportWeb.When Windows integrated authentication is used, the Microsoft IIS web server authenticates the user that is accessing web server virtual directory against the Microsoft Operating System. This occurs before the HTTP request accesses the Siebel Web Server Extensions (SWSE). When the authentication is successful, a IIS web server environment variable called REMOTE_USER is populated with “<domain>\<User>” of the domain user initiating the request. The UserSpec = REMOTE_USER and UserSpecSource=Server parameters in the eapps.cfg tell the SWSE to read this variable to retrieve the Siebel User ID that is making the HTTP request. The sample security adapter code in Technical Note 452 strips of the “<domain>\” from the REMOTE_USER web server environment variable for the Object Manager to authentication the User ID in the Siebel application. This authentication process was successful when the ERM Object Manager was used.
Message 2
The customer was receiving the following error when making the HTTP inbound requests from BizTalk to the EAI Object Manager :GenericLog GenericLog 0 2004-03-24 14:06:16 [9788] ERROR 9788: [SWSE] Set Error Response (User: Session: Error: 00027665 Message: An internal error with the Security Adapter DLL has occurred. Please ask your systems administrator to check your security adapter. The sample Security Adapter did not receive the correct Trust Token.(SBL-DAT-00336))
GenericLog GenericLog 0 2004-03-24 14:06:16 [9788] ERROR 9788: [SWSE] Error Child Messages : <0> An internal error with the Security Adapter DLL has occurred. Please ask your systems administrator to check your security adapter. The sample Security Adapter did not receive the correct Trust Token.(SBL-DAT-00336)
GenericLog GenericLog 0 2004-03-24 14:06:16 [9788] ERROR 9788: [SWSE] HTTP Status 500 : Error The service request could not be processed. Please check that the user name and password are correct, and that the request format is correct. If the problem persists, please contact the system administrator to get more detailed information and to check the system configuration.
Message 3
We compared the configuration of the EAI Object Manager against the working ERM Object Manager. We noticed that the customer had not configured the EAI Object Manager for Windows integrated Authentication and was using the incorrect virtual directory for the EAI request in the HTTP Post request.We asked the customer to confirm that the EAI Post executed successfully without using Windows Integrated Authentication. We recommended to use Technical Note 498: “Invoking a Workflow using the HTTP Inbound Transport in Siebel version 7.5” as guide. The customer stated that this was successfully working in several other environments and was successful in this one.
Next, we asked the customer to use the same parameters from the ERM Object Manager in the eapps.cfg and Object manager .cfg files to configure the EAI Object Manager to use Windows Integrated Authentication.
Since Microsoft BizTalk runs as a NT service on the machine, we confirmed that the service “Log On” user ID was a Siebel user ID in the Siebel application. The customer confirmed that they could successfully login to the ERM application when logging into a machine as this user.
Message 4
Since Window Integrated Authentication was being used, the HTTP Post was attempted without the UserName or Password in the URL similar to the following for Technical Note 498:http://my_web_server/eai_enu/start.swe?SWEExtSource=<SourceName>&SWEExtCmd=<Execute>&SWEExtData=<Some_Data>
This produced the following error in the SWSE log file:
GenericLog GenericLog 0 2004-03-25 11:17:15 [10536] ERROR 10536: [SWSE] Impersonate failed. The User Name you have entered is invalid or your user position is not defined. Please try to logon again or contact your systems administrator for assistance.
GenericLog GenericLog 0 2004-03-25 11:17:15 [10536] ERROR 10536: [SWSE] Set Error Response (User: Session: Error: 00027574 Message: The User Name you have entered is invalid or your user position is not defined. Please try to logon again or contact your systems administrator for assistance.(SBL-DAT-00254))
Since this User ID was successfully authenticated when accessing the ERM Object Manager, we decided to perform two tests:
1) where the URL included the UserName of the Service user
2) where the URL contained the UserName and Password of the service user.
The HTTP Post URL is similar to the following in Technical Note 498:
http://my_web_server/eai_enu/start.swe?SWEExtSource=<SourceName>&SWEExtCmd=<Execute>&UserName=<UserName>
&Password=<Password>&SWEExtData=<Some_Data>
Message 5
Both of these requests produced the following in the EAI Object Manager Log files :This showed the User was successfully authenticated.
ObjMgrSessionInfo ObjMgrLogin 3 2004-03-25 15:59:42 Login name : <User Id>
ObjMgrSessionInfo ObjMgrAuth 3 2004-03-25 15:59:42 Authentication name : <User Id>
and then
ObjMgrLog Error 4 2004-03-25 15:59:44 (SBL-UIF-00243) Invalid external service source 'WFMIIS'. Check the server configuration or the request.
TaskEvents SessionClose 3 2004-03-25 15:59:44 Client closed session (taskId = 57460)
In summary, this behavior was resolved for the customer’s behavior
1) We ensured that that correct virtual directory was used for the HTTP inbound request.
2) We ensured that the EAI Object Manager was configured to use Windows Integrated Authentication per Technical Note 452.
3) We ensured that the NT service that is running the BizTalk service making the HTTP Post is a valid user in the Siebel application.
4) We ensured the “UserName=” of this service account is included in the HTTP Post.
The customer was able to find what was causing the final EAI error by reviewing TechNote 498 again.
Applies to:
Product Release: V7 (Enterprise)Version: 7.5.3.2 [16168]
Database: Microsoft SQL Server 2000
Application Server OS: Microsoft Windows 2000 Server SP 4
Database Server OS: Microsoft Windows 2000 Server SP 4
This document was previously published as Siebel SR 38-2505965961.
Symptoms
SBL-DAT-00336, SBL-SRM-00016Siebel has stopped working on our test and production servers, but the development server is
still operational.
Last night the 2 domain controllers were upgraded from Windows 2000
Server SP4 to Windows 2003 Enterprise server.
The log files from the Siebsrvr directory
on our production server have been zipped and attached to this service request.
The
following information comes from Mike Springfield, who is one of our domain admins. Please
respond to Mike directly on this issue. His cell phone is (443) 829-7095.
Thank you,
Robert Sklar
**********************************************
On CRMAPPS
server
Under Task manager – Processes
There are over 35 of the same process running on this
server
SIEBNTSHMW.exe
--------------------------------------------------------------------------------
From:
Michael Springfield
Sent: Monday, September 19, 2005 12:36 PM
To: Bob Sklar
Cc: *Lan
Team; Robert Brightful
Subject: Siebel not working
Importance: High
Getting error
message when starting Siebel application
The server you are accessing is either busy or
experiencing difficulties. Please close the web browser, start a new one and try logging in
again. For further support, please copy and send the full message text to your system
administrator.[12:30:45]
Have rebooted all 3 Siebel production servers – CRMAPPS, CRMIIS,
CRMSQL
Checked event logs on all 3 production servers – nothing stands out
Checked event
logs on Domain Controllers – nothing stands out
Siebel Application works on Development
server - CRMDEV
Siebel Application does not work on Test server - CRMTest
Solution
Message 1
Customer description:Siebel has stopped working on our test and production servers, but the development server is still operational.
Last night the 2 domain controllers were upgraded from Windows 2000 Server SP4 to Windows 2003 Enterprise server.
Resolution:
The customer was authenticating via ADSI. Therefore, we used the command in Troubleshooting Steps 56 on SupportWeb to test we could authenticate to ADSI (Microsoft Active Directory Server) without Siebel. It did not work so this helped us understand that no matter what Siebel configuration we put in place, it wouldn't work since their ADSI was not responding. With help of Microsoft we changed some domain permissions and then we could authenticate against ADSI.
This meant the next thing we had to do was configure their application with the correct Active Directory Server parameters. By adding the following parameters in the ADSI section of the sfs.cfg we could get very this working.
ApplicationUser = CN=Appuser,OU=siebel,DC=dbed,DC=state,DC=md,DC=us
Regards
No comments:
Post a Comment