Wimconfig.xml
Rodney Liuzzo
I am getting error "CWWIM4538E Multiple principals were found" at server startup. I know the cause as the local WAS admin account has its duplicate in LDAP repository. I simply wants to remove the local WAS user gracefully offline as server won't come up. I tried playing around with changing the user id info in fileregistry.xml and corresponding change in security.xml but to no avail.
Seems that you've added LDAP into "federated repositories" and forgot to remove "internalFileRepository" which contains wasadmin as well. You can do it in profiles/dmgr/config/cells/myCell/wim/config/wimconfig.xml, where you just remove it from the realm.
Editing wimconfig.xml (see the wim/config-subdirectory of the cell configuration directory e.g. c:wasprofilesdmgrconfigcellsLCCell01wimconfigwimconfig.xml) is easy as well. You simply add an additional LDAP server to the config:ldapServers tag as shown below. The parameters in bold can be used to make sure that WAS return to the primary LDAP server (first listed) and optionally what the poll time should be (in minutes).
The ConfigEngine.sh script is used to add, remove and validate entries in the Portal configuration engine. Refer to IBM Portal - Configuring wkplc.properties for the steps on how to configure the workplace properties file (wkplc.properties) so that ConfigEngine.sh can make a connection to Portal.
Before using wp-update-federated-ldap-attribute-config to add or update an LDAP property, you may want to use the wp-validate-federated-ldap-attribute-config option to ensure the attribute has not already been added to the Portal configuration engine. Or, you can review the /opt/WebSphere/AppServer/profiles//config/cells//wim/config/wimconfig.xml and ensure the property is not listed.
The wp-update-federated-ldap-attribute-config option is used to add or update an LDAP property. The ConfigEngine.sh script will get the new property to add from the /opt/WebSphere/AppServer/profiles//ConfigEngine/properties/wkplc.properties file. In this example, the LDAP fullName attribute will be added.
If the update is unsuccessful, BUILD FAILED should be included at the end of the output. In this scenario, review the failureyyyy-mm-dd-hh.mm.ss.log to get an idea behind why the update failed. After resolving the issue identified in failureyyyy-mm-dd-hh.mm.ss.log, run the wp-add-property command again until BUILD SUCCESSFUL is returned.
If you are using a federated ldap setup, edit the corresponding federated properties instead, and then run the following task: ConfigEngine.sh wp-update-federated-ldap-attribute-config . Restart the server and try the form again. It should correctly save the email attribute for the user and you can get on with sending email through Portal. Just for kicks, lets look at what that task did. It just edits the wimconfig file, which defines how VMM interacts . Open wimconfig.xml (wp_profile/config/cells//wim/config/wimconfig.xml) and search for ibm-primaryEmail.
This is an archive of the Maximo Yahoo Community. The content of this pages may be a sometimes obsolete so please check post dates.
Thanks to the community owner Christopher Wanko for providing the content.
I'm getting *only* the logout page. I can't get the login page to come up, but at least Maximo is running. Yesterday was a nightmare.
Any suggestions here? Websphere is definitely talking to my domain controllers, I can query users and groups from there. I'm using FORM authentication right now, going to switch to BASIC to see if I can at least login.
-C
I haven't seen any earlier posts apart from the "I'm getting *only* the logout page" one.
So please excuse if I'm stating the obvious, but have you synchronised any other users yet?
Regards
Jim
From: MAX...@yahoogroups.com [mailto:MAX...@yahoogroups.com]
Sent: 13 June 2017 15:03
To: MAX...@yahoogroups.com
Subject: [MAXIMO List] Re: Maximo 7.6 and LDAP on WebSphere... ugh.
Okay, I actually got it to work with the MAXADMIN user but no other user can log in. What should I be checking here? The AD group maximousers contains more than just MAXADMIN.
-C
Without configuring either an LDAPSYNC or VMMSYNC cron, you will not have users in Maximo other than the standard mxadmin, mxintadm and maxreg.
If user management has not been disabled in Maximo (a system property) you would be able to create a user in Maximo as long as the login id matches whichever AD(?) attribute you are using with the standard being CN.
Best to set up a cron instance but you'll need to decide what the top level is in AD for User and Group searches and any other filter that you may wish to apply to avoid pulling everything into Maximo regardless of what it is.
From: MAX...@yahoogroups.com [mailto:MAX...@yahoogroups.com]
Sent: 13 June 2017 15:55
To: MAX...@yahoogroups.com
Subject: RE: [MAXIMO List] Re: Maximo 7.6 and LDAP on WebSphere... ugh.
I guess not!
They would have been included in the maxinst data file.
From: MAX...@yahoogroups.com [mailto:MAX...@yahoogroups.com]
Sent: 13 June 2017 16:03
To: MAX...@yahoogroups.com
Subject: [MAXIMO List] Re: Maximo 7.6 and LDAP on WebSphere... ugh.
Begs the question, how did maxadmin get synchronized and no one else?
Not in admin mode, and the users already exist in MAXUSER, GROUPUSER, etc. I am converting an existing system to use LDAP for auth and user membership. There is a username to match in MAXUSER, so it must be something else.
I'll try dropping and adding a user manually, and see if it picks up. Thanks everyone, I'll keep at it.
Yes, I do need to configure VMMSYNC. That looks fun.
-C
Can you give us your system information? App server, database, and Maximo version?
I know when we upgraded to 7.5, we had an issue with the case. Might be worth checking out if case sensitivity is an issue:
-01.ibm.com/support/docview.wss?uid=swg21394865 -01.ibm.com/support/docview.wss?uid=swg21394865
WebSphere 8.5.5 on Windows Server 2012, with Oracle 12c and Maximo 7.6
Right now WebSphere is not synchronizing nodes, so I'm stuck until I can fully revert back to scratch. Once I do that, I'll be taking a directory backup and taking another stab at it.
Sending all uppercase would seem like a fix, as my AD sAMAccountName values tend to be mixed case.
-C
Admin mode not on.
I finally got it to work, at least the authentication part. I had to edit a wimconfig.xml file to use sAMAccountName.
Now my next problem, which you only see once you can auth and get in: I can't manage my security group assignments. I *only* want LDAP auth for users, I do NOT want LDAP group assignments.
How do I fix that?
-C
Yeah, your set up is not common. We have the same LDAP setup. I create the Maximo users manually (Security > Users). As long as the userid matches with your LDAP, the password authentication is managed by LDAP.
We did have to manually update via sql all our userid logins to upper case though. We also had to turn on
mxe.convertloginid=1
This way submissions of user logins are always upper case.
Tends to be an issue where LDAP or Maximo runs on a Linux.
One more question: I have a new security group "maximousers" which is apparently synchronizing my users. I didn't create it, so the LDAPSYNC must have done it.
I think I really want my AD group maximousers to synchronize with Maximo group EVERYONE, don't I? How would my groupMapping..xml look for that?
-C
That's because the Group synchronisation filter will pick up any AD group found under the BaseDN, creating in Maximo where necessary and adding the group members.
If you had wished the user synchronisation to be into EVERYONE it may have been best to create the AD group as EVERYONE instead of MAXIMOUSERS.
I still think that there is a benefit to keeping them separate e.g. you may actually end up granting permissions to EVERYONE and then, as soon as you synchronise users they need to be named licensed users. If you are only ever pulling over legitimate users then this isn't necessarily an issue. You could even set up all the Maximo Security Groups in AD and push the responsibility of populating those to Network Admins, but they are unlikely to thank you for it.
Given the possibility of an IBM license audit, I prefer a process whereby a Maximo System Administrator adds new users to whichever Maximo Security Groups that they have entitlement to, including EVERYONE.
From: MAX...@yahoogroups.com [mailto:MAX...@yahoogroups.com]
Sent: 28 June 2017 14:40
To: MAX...@yahoogroups.com
Subject: [MAXIMO List] Re: Maximo 7.6 and LDAP on WebSphere... ugh.
One more question: I have a new security group "maximousers" which is apparently synchronizing my users. I didn't create it, so the LDAPSYNC must have done it.
I think I really want my AD group maximousers to synchronize with Maximo group EVERYONE, don't I? How would my groupMapping..xml look for that?
-C
Next we have to complete the Security section located on the right-hand side of the page. In this section we have two fields to fill in. Bind distinguished name (DN) is the name which WebSphere will use to connect to LDAP for name searches. The Bind password is the password for this user. Fill in these fields with the values below, which we configured in Apache DS earlier.
In the Global security > Standalone LDAP registry > Advanced Lightweight Directory Access Protocol (LDAP) user registry settings page, change the User Filter and Group Member Id Map to fields as per the entries below.
Note: We make these changes because ApacheDS uses slightly different object classes and the default ones are customized for IBM LDAP servers, hence the change. We have only changed the entries required, the other fields are fine as they are.
e59dfda104