Hi Steven,
Thank you for the explanation, it is definitely giving me a better understanding.
I did see a post that said the
sAMAccountName and LOGINID fields had to have matching case structure, so I was following that method for troubleshooting for a while. Listed below are some findings:
- For the kseabrook account I mention, it does have a different case structure for its sAMAccountName (KSeabrook) versus it's LOGINID (kseabrook). I know we will have other user accounts with this same scenario.
- There is another account, mmosley that has the same case structure for both the
sAMAccountName (mmosley) and LOGINID (mmosley). This account cannot log into Maximo using it's network password as well.
In LDAPSYNC, we do have the following in the User Mapping property:
type="UPPER">sAMAccountName</keycolumn>
<column name="LOGINID"
Since we have it set to look at the sAMAccountName in upper case, should I also set the property you mentioned, mxe.convertloginid, to 1? From what you were saying, it sounds like this would force both fields to show as uppercase when getting validated. Am I correct in understanding what you are saying and would this make sense to try?
Regarding the CWWIM4537E error, both the kseabrook and mmosley accounts are valid accounts. Both user names show up in the Manage User area within WebSphere. You can also search for both with the LDAP Test Query function.
Out of curiosity, when does the password get changed between AD and Maximo? I see some of the fields were updated in the kseabrook and mmosley user/person accounts in Maximo, so it does seem like the LDAPSYNC is doing at least some of the things it is supposed to do.
Thank you so much for your input, and if you have additional suggestions, I am all ears.
Sincerely,
Kathy
------------------------------
Kathy Seabrook
Jacksonville Port Authority
------------------------------
Original Message:
Sent: 06-22-2022 11:03
From: Steven Shull
Subject: LDAP Integration Not Working
Check the loginid for the users that failed and make sure that matches the sAMAccountName (or other field if you've changed which to utilize) in Active Directory. This must be identical, including same character casing. For example, if my loginid was MAXADMIN then the sAMAccountName must also be MAXADMIN. If it was maxadmin, Maxadmin, etc. the user wouldn't be able to login. There is a system property (mxe.convertloginid) that will convert everything to uppercase for evaluation but you would then need to make sure that you provide it as uppercase in the LOGINID for every user.
This error "CWWIM4537E No principal is found from the 'kseabrook' principal name.." means that a user typed in kseabrook and it wasn't found in the Active Directory configuration in WebSphere. It's possible that it was a typo, at which point that would be expected, or the configuration doesn't have the correct OU filter and it's not capturing this user. This is unrelated to the LDAPSYNC cron task which pulls users from Active Directory to put into Maximo.
------------------------------
Steven Shull
IBM
Original Message:
Sent: 06-21-2022 09:22
From: Kathy Seabrook
Subject: LDAP Integration Not Working
Hi Chavdar,
Thank you for your response.
Yes, I am able to log into the network as svc_maximo, the bind account, from my desktop. I am also able to successfully query ldap using the Test LDAP Query function within WebSphere.
It's really weird to me, that people that did not previously have accounts within Maximo, are getting synced with Maximo just fine, and then you can log into Maximo with the new account. The people I am having issues with are the people who previously had an account with Maximo. For some reason their passwords are not getting synced. I don't know enough about the integration to figure out why these scenarios are occurring.
Thanks,
Kathy
------------------------------
Kathy Seabrook
Jacksonville Port Authority
Original Message:
Sent: 06-18-2022 09:05
From: Chavdar Cholev
Subject: LDAP Integration Not Working
Hi Kathy,
I have seen this error in our test env. The issue was with bind user. Did you check if bind user can access AD. I use LDAP admin toll for test.
SECJ0369E: Authentication failed when using LTPA. The exception is com.ibm.websphere.wim.exception.PasswordCheckFailedException: CWWIM4537E No
principal is found from the 'kseabrook' principal name..
Thank you
Chavdar
------------------------------
Chavdar Cholev
Home
Original Message:
Sent: 06-17-2022 13:46
From: Kathy Seabrook
Subject: LDAP Integration Not Working
Hello All!
I am currently trying to configure AD integration in our test environment.
Our environment is as follows:
- OS RedHat Rhel 8
- WebSphere 9.0.5.6
- Maximo 7.6.1.2
- Using LDAPSYNC crontask which runs every 5 minutes
- Clustered environment with two nodes:
- Node 1 - MXUI1, MXUI2, MXUI3
- Node 2 - MXADMIN, MXMIF, MXREPORT
I am following these instructions - Maximo and LDAP - Configuration from Start to Finish| Ibm | remove preview |
| | Maximo and LDAP - Configuration from Start to Finish | | Maximo and LDAP - Configuration from Start to Finish | | View this on Ibm > |
|
|
Here are the results I am seeing right now and areas I need guidance in to get this thing fully operational.
Listed below are the 7 accounts included in the testmaximousers AD group. I am also documenting which ones I have tried to log in with and what the results were.
- mmosley - attempted to log in and received error that I could not (pre-existing account in Maximo; passwords would differ between AD and Maximo)
- kseabrook - attempted to log in and received error that I could not (pre-existing account in Maximo; passwords would differ between AD and Maximo)
- testmaxadmin - attempted to log in and I was able to (copy of maxadmin and has the same password in Maximo and AD)
- testmxintadm
- testmaxreg
- testksmgr - attempted to log in and I was able to (new account created in AD; synced with Maximo)
- testkstech - attempted to log in and I was able to (new account created in AD; synced with Maximo)
In the MXADMIN SystemOut.log, you will see error -
psdi.util.MXApplicationException: BMXAA4129E - The record for E-mail=Kathy.Seabrook@jaxport.com already exists. Ensure that the key value for the given record is unique.
As part of troubleshooting, I did validate that the email table does contain the attribute emailaddress. When you look at the records for mmosley and kseabrook, both records do contain each person's email address. As mentioned before, both of these accounts were already existing in Maximo prior to building out the AD integration, whereas the other accounts that can log in, are new accounts.
Another thing, this error is not consistent. Sometimes it shows that all of the accounts have synced without errors.
Additionally, I see some of the data is being updated on the kseabrook and mmosley accounts. I am curious why the password is not getting updated, as that appears to be the issue. By the way, when you try to log in with either of these accounts. You cannot use the pre-existing Maximo password, which makes sense, nor can you log in with the current AD password. Instead you receive an error that the password and user account do not match.
In the MXUI3 SystemOut.log, you will see error -
SECJ0369E: Authentication failed when using LTPA. The exception is com.ibm.websphere.wim.exception.PasswordCheckFailedException: CWWIM4537E No principal is found from the 'kseabrook' principal name..
[6/13/22 13:16:16:215 EDT] 00000b34 FormLoginExte E SECJ0118E: Authentication error during authentication for user kseabrook
The principal is set to srv_maximo in LDAPSYNC, so I am not sure what this error is implying.
Hopefully I have given enough information to help me out and I am thinking you in advance for assistance.
Kathy
#Administration
#Integrations
#Security
------------------------------
Kathy Seabrook
Jacksonville Port Authority
------------------------------