I am trying to start my domain in Weblogic 12.1. It was working fine. today when i tried to restart the domain it gave the following error
Security Services Not Found. Falied to load Myreal
i have not created a database.
thanks
That error indicates a security subsystem could not initialize correclty. Have you setup a security provider (like ldap, opensso etc) recently ?
Related
Setup:
MobileFirst server 8.0 on Liberty Farm 8.5.5
IBM DB2
IBM MF Analytics
The MF server is configured as MobileFirst_Server_Config using server configuration tool. and when i see in server.xml, it creates some inbuilt users automatically with their password like Admin_MobileFirst_Server_Config or Push_MobileFirst_Server_Config.
i get below error more frequently in the websphere logs. we never changed anything related to this inbuilt users.
y.authentication.jaas.modules.UsernameAndPasswordLoginModule A CWWKS1100A: Authentication did not succeed for user ID Admin_MobileFirst_Server_Config. An invalid user ID or password was specified.
Can anyone help me to understand what causes this error and resolution if any.
This maybe because of the hostname specified in the server.xml for authorization URL and push URLs. If the URL consists of localhost change that value to the machine IP address and restart the server.
I am hoping someone can help me out with a frustrating configuration problem I'm having with IBM FileNet Content Manager 5.2.1 (aka P8 5.2.1).
We have an existing system setup that uses Microsoft Active Directory as our LDAP directory service for P8 and that has worked fine to date. That said, we are now wanting our .NET apps to talk to P8 (via the Content Platform Engine .NET API) using WCF instead of legacy (and now deprecated) WSE but we have run into a problem. WCF requires that all communication occur over SSL - on the surface, not a problem. If you want to talk to the IBM Content Platform Engine (CPE) over SSL however, according to IBM's documentation, you must also change the underlying default LDAP connection from unsecured to SSL as well (in the process, changing LDAP to use port 636 instead of 389).
Following both Microsoft's and IBM's docs, I first enabled LDAP over SSL on Active Directory and tested accordingly. Using Microsoft's LDAP utility, ldp.exe, I can successfully connect and bind to Active Directory on port 636 over SSL.
The next step however is where I hit a wall - Enabling SSL for Content Platform Engine. I followed all the steps involving adding the Active Directory Server's CA certificate to the CPE's application server keystore - no problem. The next step in the configuration instructions however asks you to start the Administration Console for CPE (ACCE) and reconfigure the directory configuration properties - telling it to use SSL on port 636 and... KABOOM! When I attempt to save the configuration, the save fails, stating
An unexpected exception occurred. Message was: Failed connecting to ldap://ad1.domain.com:636
Unfortunately, I can't find any additional info as to why it failed to connect - I assumed it was due to something minor, such as a port conflict. To test that theory, I installed Microsoft's LDAP test utility on the CPE server and attempted to connect to the Active Directory Server over SSL on port 636. Much to my surprise, that worked just fine - grrrr...
I am now at something of a loss as to what to look at next. Anybody out there with experience configuring CPE to use SSL in an Active Directory environment?
Thanks in advance for any-and-all assistance.
WCF requires that all communication occur over SSL - on the surface, not a problem. If you want to talk to the IBM Content Platform Engine (CPE) over SSL however, according to IBM's documentation, you must also change the underlying default LDAP connection from unsecured to SSL as well
This is not true. FileNet can work with non-secure LDAP, while at the same time working with WCF.
Now, if you would like to solve why FileNet will not connect to a secure LDAP, then you should start with your WebSphere
Check WebSphere's Keystores to ensure that the AD's key is contained. Follow #M.Tamboli's advice and restart WebSphere.
Also make sure that you check WebSphere's SystemOut.log logs, as you may find more info in there.
I'm not sure if it is necessary, but you may also want to add/change the LDAP config that is setup within WebSphere itself.
We are running WebSphere Application Server v8.5 on AIX 7, which we configured to use ldap security. Everything is working fine, but project went halt for some time and our WAS was down. Now we see that ldap cerficates were expired, hence we are unable to connect to dmgr & admin console. Can somebody help to resolve it?
We know how to configure ldap on WAS, but dont no how to change expired ldap cerficate with new cerficates. (We received new non-expiry certificates from ldap team but dont no how to configure it on WAS).
You need to disable security, restart dmgr, replace certificates and reenable security.
To disable security:
stop/kill the dmgr
run the following from the dmgr\bin folder:
wsadmin -conntype NONE
At the wsadmin prompt, type securityoff and then type exit.
Restart your dmgr.
UPDATE
Do you have Federated or Standalone Ldap configured? You should have in LDAP configuration link to SSL configuration. There you will need to add your new certificate to the Signers store (this is very simplified description as I'm not sure which repository you are using).
I have installed Worklight 6.2 on Linux, using Liberty 8.5.5 and DB2 10.5. Created the DB2 databases for WRKLGHT and WLREPORT. Have executed the Server Configuration Tool and successfully created a Worklight Server configuration (did not have any errors in the Console view when running the Ant tasks, tables were created successfully in the database, and configuration shows deployed status in the SCT). Created a runtime environment in the SCT, also seemed to succeed (no errors in Console view, tables created/updated, runtime environment shows deployed in the SCT). Stopped and restarted the Liberty server.
Can hit Worklight admin at (/worklightconsole) and log in successfully using my demo user, however it then indicates there are no runtime environments. When trying to access runtime environment at /worklight/console (which should be the correct URL given how I created the runtime config in SCT using my Worklight project WAR), I get various errors: first "Service unavailable since initialization is not yet complete." then after retrying for about a minute or two I get "javax.servlet.ServletException: java.lang.RuntimeException: Timeout while waiting for the management service to start up at com.worklight.core.auth.impl.AuthenticationFilter.isWaitingForInitialization(AuthenticationFilter.java:561)".
Seems the management service is not starting up successfully. Upon reviewing the messages.log I see the following error precede it: "FWLSE0242E: Failed to synchronize application runtime information. The servlet initialization failed and the servlet will deny serve. The most common reason is a failure in JMX communication with the ''worklightadmin'' service. You need to restart the web application after fixing the problem. [project worklight]" and this creates an FFDC log.
I know this is a lot of information but trying to be complete. Anything I should check to fix the JMX communication issue and get the management service starting?
Thank you for the replies back. Turns out there is an issue with Liberty (I was on 8.5.5.0) and the IBM JDK I was using (1.7_64). Swapped out to the Oracle JRE (1.7.0_60-b19), pointed Liberty to use it, and the problem was solved. I am pursuing a fix with the Liberty team through IBM Support for this issue.
I cannot give a unique solution, but I can explain the situation and this may lead to a solution.
The runtime servlet initialization tries to contact the Worklight Admin service. The Worklight Admin service is a web application that must be running when the runtime starts. The runtime was not able to find the Worklight Admin service. It waited a while, in case that the Worklight Admin service is just starting up, but then gave up due to a timeout because within a given time, it could not find the Worklight Admin service.
Possible reasons:
the web server is not at all configured to run the Worklight Admin service. In your case, this seems not the problem, since you can access the Worklight Console. You should also see in the log file whether the Worklight Admin service did start.
the worklightadmin service might never start up ... this could be a configuration problem, e.g. with the WLADMIN data base. This could also be detected from the server logs.
when the runtimes and the Worklight Admin service start up together, it might be that the Worklight Admin service simply takes too long to start. Let's say you have 100 webapps, and the runtime starts first and the Worklight Admin service starts last, it could be that the 98 other webapps take too much time to start. In that case, make your web server lighter ... run only Worklight on that webserver, nothing else.
the Worklight Admin service starts, but the runtime cannot communicate with it. This indicates that the JMX communication is misconfigured. Follow the documentation of the webserver how to configure JMX. For liberty, see http://www-01.ibm.com/support/knowledgecenter/SSD28V_8.5.5/com.ibm.websphere.wlp.core.doc/ae/twlp_admin_restconnector.html?cp=SSD28V_8.5.5%2F1-5-2-10-1&lang=en
I have web service deployed in my system under Glassfish server. When I try to access it from another system using my IP and port number it shows an access control origin error.
I tried to solve this by putting a accesscrossdomain.xml file in my Glassfish docroot folder, but the error still continues.
What can be done to solve this issue?
You are likely running into the default configuration, which disables remote administration by default for security reasons. This means no SSL while logging into the administration console, no admin password, etc.
GlassFish Server has excellent documentation. For this particular issue, this section of the Security Guide should help. Basically, you'll want to run "asadmin enable-secure-admin". To learn more about secure admin, read this section of the Security Guide.