Background
During an IBM Control Desk (also applies to Maximo) implementation, we found a problem with the VMMSYNC cron task. Specifically, it didn't appear to pull any data from Active Directory. Or if it did, the data wasn't processed.
Symptoms
We had ChangePolling set to 1 in our cron task instance. We enabled DEBUG level logging for the VMMSYNC cron task and saw the following in SystemOut.log:
[3/25/20 19:28:06:374 EDT] 000001ba SystemOut O 25 Mar 2020 19:28:06:374 [DEBUG] [MAXIMO0c1] [CID-CRON-1618] Synchronizing VMM Users: vmmSubject Subject:
Principal: defaultWIMFileBasedRealm/myproduser
Public Credential: com.ibm.ws.security.auth.WSCredentialImpl@16bdee5d
Private Credential: com.ibm.ws.security.token.SingleSignonTokenImpl@e022bcb
Private Credential: com.ibm.ws.security.token.AuthenticationTokenImpl@17329f4d
Private Credential: com.ibm.ws.security.token.AuthorizationTokenImpl@64c05421
[3/25/20 19:28:06:384 EDT] 000001ba SystemOut O 25 Mar 2020 19:28:06:384 [DEBUG] [MAXIMO0c1] [CID-CRON-1618] Synchronizing VMM Users: VMM search results
<?xml version="1.0" encoding="UTF-8"?>
<sdo:datagraph xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:sdo="commonj.sdo" xmlns:wim="http://www.ibm.com/websphere/wim">
<wim:Root>
<wim:entities xsi:type="wim:PersonAccount">
<wim:identifier externalName="CN=myproduser,OU=Admin,o=MYCORP.COM"
repositoryId="MYAD" uniqueId="CN=myproduser,OU=ADMIN,O=MYCORP.COM"
uniqueName="CN=myproduser,OU=Admin,o=MYCORP.COM"/>
</wim:entities>
<wim:controls xsi:type="wim:ChangeResponseControl">
<wim:checkPoint>
<wim:repositoryId>MYAD</wim:repositoryId>
<wim:repositoryCheckPoint>10085177</wim:repositoryCheckPoint>
</wim:checkPoint>
</wim:controls>
</wim:Root>
</sdo:datagraph>
[3/25/20 19:28:06:384 EDT] 000001ba SystemOut O 25 Mar 2020 19:28:06:384 [DEBUG] [MAXIMO0c1] [CID-CRON-1618] syncUser, syncData = <VMMSyncData has no values>
Notice the greenish highlighted text is the entry that should have been seen in the "VMMSyncData", but it says it has no values.
I then looked at the log of a working environment and saw that it was similar, but it actually worked:
[3/25/20 18:57:12:940 EDT] 000001b3 SystemOut O 25 Mar 2020 18:57:12:940 [DEBUG] [MAXIMO0] [CID-CRON-102377] Synchronizing VMM Users: vmmSubject Subject:
Principal: defaultWIMFileBasedRealm/myqauser
Public Credential: com.ibm.ws.security.auth.WSCredentialImpl@ec82289
Private Credential: com.ibm.ws.security.token.SingleSignonTokenImpl@5b17dd0b
Private Credential: com.ibm.ws.security.token.AuthenticationTokenImpl@9348468a
Private Credential: com.ibm.ws.security.token.AuthorizationTokenImpl@447810d4
[3/25/20 18:57:12:944 EDT] 000001b3 SystemOut O 25 Mar 2020 18:57:12:944 [DEBUG] [MAXIMO0] [CID-CRON-102377] Synchronizing VMM Users: VMM search results
<?xml version="1.0" encoding="UTF-8"?>
<sdo:datagraph xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:sdo="commonj.sdo" xmlns:wim="http://www.ibm.com/websphere/wim">
<wim:Root>
<wim:entities xsi:type="wim:PersonAccount">
<wim:identifier externalName="CN=myqauser,OU=Admin,o=MYCORP.COM" repositoryId="MYAD"
uniqueId="CN=myqauser,OU=ADMIN,O=MYCORP.COM" uniqueName="CN=myqauser,OU=Admin,o=MYCORP.COM"/>
<wim:changeType>modify</wim:changeType>
<wim:uid>myqauser</wim:uid>
</wim:entities>
<wim:controls xsi:type="wim:ChangeResponseControl">
<wim:checkPoint>
<wim:repositoryId>MYAD</wim:repositoryId>
<wim:repositoryCheckPoint>670244</wim:repositoryCheckPoint>
</wim:checkPoint>
</wim:controls>
</wim:Root>
</sdo:datagraph>
[3/25/20 18:57:12:944 EDT] 000001b3 SystemOut O 25 Mar 2020 18:57:12:944 [DEBUG] [MAXIMO0] [CID-CRON-102377] syncUser, syncData = uid=myqauser
[3/25/20 18:57:12:956 EDT] 000001b3 SystemOut O 25 Mar 2020 18:57:12:956 [DEBUG] [MAXIMO0] [CID-CRON-102377] insertRecord, columnName = personid
[3/25/20 18:57:12:956 EDT] 000001b3 SystemOut O 25 Mar 2020 18:57:12:956 [DEBUG] [MAXIMO0] [CID-CRON-102377] value, value = myqauser
[3/25/20 18:57:12:956 EDT] 000001b3 SystemOut O 25 Mar 2020 18:57:12:956 [DEBUG] [MAXIMO0] [CID-CRON-102377] insertRecord, columnName = type
[3/25/20 18:57:12:957 EDT] 000001b3 SystemOut O 25 Mar 2020 18:57:12:957 [DEBUG] [MAXIMO0] [CID-CRON-102377] value, value = WORK
[3/25/20 18:57:12:957 EDT] 000001b3 SystemOut O 25 Mar 2020 18:57:12:957 [DEBUG] [MAXIMO0] [CID-CRON-102377] insertRecord, columnName = isprimary
[3/25/20 18:57:12:957 EDT] 000001b3 SystemOut O 25 Mar 2020 18:57:12:957 [DEBUG] [MAXIMO0] [CID-CRON-102377] value, value = 1
[3/25/20 18:57:12:957 EDT] 000001b3 SystemOut O 25 Mar 2020 18:57:12:957 [DEBUG] [MAXIMO0] [CID-CRON-102377] insertRecord, columnName = emailaddress
[3/25/20 18:57:12:958 EDT] 000001b3 SystemOut O 25 Mar 2020 18:57:12:957 [DEBUG] [MAXIMO0] [CID-CRON-102377] value, value = null
Notice the greenish highlighted text again, where it shows that the bind user was modified, and then it pulls in all of the attributes and values for that entity.
I found this link online and tried what it suggested, but this is outdated (I'm on ICD 7.6.1.1):
That "changeType" attribute is absolutely NOT required any more - it's built into the VMMSYNC code.
The Solution
It turns out that the bind DN (user ID) that we were using apparently didn't have some permission or configuration in place. We actually tried with three different users before we found one that had the appropriate access to actually pull the data.
What's really strange is that we could successfully use any of the three users with Apache Directory Studio to connect to Active Directory to see any and all data. But for some reason, only one of the users actually worked through VMMSYNC.
I will update if I find out from the AD team what the specific setting is, but I wanted to document this here for posterity.
4 comments:
Hello Frank,
I am currently facing the same issue you had with VMMSYNC giving the "syncUser, syncData = " error.
It's really strange because the same crontask is working in another Maximo envrionment with another LDAP domain as well.
Did you happen to know what was the problem with your bind account?
Thanks,
Emile
Hi Emile,
I never did find out the issue from the AD team (technical groups at the customer are very segmented and protective of their information), but I am certain that it's *something* on the AD side. Do you have any other bind DN you can try? Your own, or one from another user on your team, or some other service account? The route I would take is to try to find one that works, then have the AD team compare the security configuration between that one and the one that doesn't work.
Frank
Hi Frank,
So, testing with another user as a bind account solved the issue. This is a weird one.
We will let the AD guys verify if there is something wrong about the one we were using.
In any case, thanks a lot!
Emile
You're welcome, and I'm very glad it worked for you. Please let me know if you find out the root cause of the problem, because I absolutely agree that it's a weird one.
Post a Comment