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.
Related
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.
I have two servers:
1st server: Odoo 9 application hosted in Amazon EC2
2nd server: LDAP server hosted in my Synology NAS which is in a local area network
Right now, I would like to authenticate all the Odoo users by the LDAP server.
Things that I have done
I have installed the Authentication via LDAP (auth_ldap) module in Odoo
Configured LDAP Parameters in Odoo. Note: Actual IP address and domain were altered due to security issue. Need someone to check if the configuration values are entered correctly.
Open the port 389 in my office network to public and forwarded it to the LDAP server.
Tested using ldapsearch command line in Amazon EC2 to ensure that both servers can communicate.
Somehow I am still not able to login using the LDAP user login in Odoo. What did I do wrong? Is there any other way to find out if Odoo is communicating with the LDAP server?
I am using IBM Application Center version Version: 7.0.0.00-20150312-0731 which comes with MobileFirst Platform foundation consumer edition.
Its configured on WAS ND 8.5.5 in a clustered environment and DB2 database.
If i access the App Center console via internal ip and port, it list the application published in the console.
The same is not listing if, i access the console via Public IP / DNS. Getting the error in console - "Server error. Contact the server administrator."
No logs printing on the ApplicationCenterCluster log file for the same request.
But for local ip access i can see all the logs printing.
No clue were is the problem.
Trace and SystemOut log files
1) As it seems you use IHS in front of WAS you must configure the proxy endpoints as documented here : http://www-01.ibm.com/support/knowledgecenter/SSHSCD_7.0.0/com.ibm.worklight.installconfig.doc/appcenter/r_ac_appres_endpoint.html
2) In ApplicationCenterClusterMem02 you have an error HMGR0024W meaning that the WAS high availability manager was unable to resolve the IP address for DNS Name. Either the host is unknown or has mappings to duplicate IP addresses.
I am very new to splunk and trying to set up domain account, but with the custom options the installation rollbacks. I want to receive data from remote system by a universal forwarder. I have provided the same port number as the receiving port which is forward data configurations in remote system. What am I missing here? Can I do so with local system installation?
same question is asked here ...
http://answers.splunk.com/answers/232340/why-am-i-unable-to-set-up-the-domain-account-for-s.html
but there is no answer..
Please help..
The service account must be entered as "domain.name\username" rather than just "username".
I experienced the same problem, having everything configured correctly for running the Universal Forwarder as a service account. However, I failed to enter the service account as "domain.name\username". Just specifying "username" does not work, either when running the installer interactively or silently.
I have created a server in liberty and installed IBM Worklight in it.
Everything was working fine till I protect the console.
After protecting the IBM Worklight console the authentication is asked
twice.
First Login Screen with URL localhost:9080
After Login Successful.Again the login is being asked with the hostmachines URL 192.168.10.16:9080
My questions are
Why login appears twice?
Why my hostmachine ip is being revealed?
You are accessing the console with address localhost, whereas in your code you are either using publicWorklightHosname=192.168.10.16 or while building you are using build for remote machine and then putting in IP of the server.
Here is what you need to do:
Make sure a DNS entry of the hostname is present in the server and client machine
Change the publicWorklightHostname property in worklight.properties file to a proper address eg
mymachine.mydomain.com
while building for Remote Server, use the same address as above i.e. mymachine.mydomain.com
redeploy the new war file
Worked perfectly for me.
P.S> I believe you are using local machine, in this case also you can use the machine name in worklight.properties file and make sure that the address you are using is same as the one you used to build. Nonetheless, it doesn;t matter in production or application deployment.