TMS Provisioning AD Sync Issue

[Jason Neurohr]

Hello,

We are running TMS 13.1.1 and have configured the provisioning directory to synchronise with Active Directory. We are using a search filter to limit the users imported to members of a specific AD Group.

The issue we are having is not all members of the group are being imported. Some of the users in the group are imported successfully but others are not. I have run a wireshark to capture the LDAP that is being sent to the domain controller and it appears to be fine, running a custom search on AD using the filter TMS sends results in all users being returned as expected.

If I remove the search filter, all users are imported correctly.

Any help is greatly appreciated!

Regards

Jason

[awinter2]

Jason,

how many users are members of the group in question, and how many are actually imported when you try to import the users?

Could you paste the search filter which you are using when attempting to import? Feel free to obfuscate the 'dc=' portions of the search filter as you shouldn't reveal that on this forum.

- Andreas

[Jason Neurohr]

Hi Andrea,

There are 12 people in the group and 6 of them are being imported.

the search filter is:

(memberOf=cn=movi-users,ou=corpgroups,dc=staff,dc=ad,dc=domain,dc=com,dc=au)

- Jason

[awinter2]

That search filter looks quite alright to me, the only difference from your group and the one I use for my lab is that yours has a dash in it, although I'm not aware of that being a problem (My group name is 'Provisioning').

Also, I'm using 13.1.2.

Perhaps you can try creating a new group, for example called 'Provisioning', add your 12 users to this group, change your search filter to use this group instead and see if that helps?

Edit: Also, in the Wireshark capture, do you see AD returning all 12 users in the search results, or only the 6?

- Andreas

[Jason Neurohr]

Hi Andreas,

I had the same thought regarding the dash so modified it the other day for testing using "MoviUsers" however I encountered the same issue.

In the wireshark trace I only see it return the 6 users which is odd considering if you use the same filter that TMS passes it returns all 12 when querying AD directly.

[awinter2]

Are all of the users located in the same OU, or are they spread out in various places in the domain tree?

Assuming it is the same 6 users which are successfully imported each time, is there anything specific about these 6 users compared to the 6 which don't get imported, in terms of where in the AD tree they are located and so forth?

- Andreas

[Jason Neurohr]

Also had that thought, all user are in the same OU and there is no apparant differnce between them.

[awinter2]

Do any of the 6 non-working accounts have anything ticked in the 'Account options' section of the 'Account' tab in AD U&C?

I can prevent accounts from being imported if they are disabled, so you might want to double check that they are not.

Are you able to log in as any of these users on a domain computer?

-Andreas

[Jason Neurohr]

None of the accounts are disabled, I would have to confirm with the AD admins as to whether any other options are checked. However the filter TMS passes only looks for the user account type and checks if it is disabled so I wouldn't think any of the other options would affect the import process

[Jason Neurohr]

Comparing to a wireshark trace of another environment the only difference that is jumping out on the working env running 12.6 is that after each LDAP searchrequest and response an unbindrequest is sent. And then a new bindrequest is sent for the next search request etc.

where as the environment having the issue running 13.1.1 is not unbinding and rebinding after each searchrequest.

[awinter2]

I'm seeing 9 bind requests in my import (and no unbind requests).

Could you perhaps try creating a 13th user and add this to the same group and check if this newly created account imports OK?

I guess the way forward would be to raise a TAC case so that we can collect some more logs and look more closely at this.

- Andreas

[Jason Neurohr]

Looks to be a security issue. The account used to synchornise appears to not have permissions to read the memberOf AD attribute on the accounts not being synchronised.