WFM4 incomplete AD Group import

[Atlas1]

After successfully configuring, testing and connecting my Directory Services connection to AD, I can perform only a partial AD Group import.

For example in the same AD OU , there are 2 Global Security groups.

1 group is called FG_Packagers
the 2nd group is called FG_PKG_LeadPackagers

The 1st group imports ok but the 2nd group doesn't even appear in the list of Groups available to import into WFM4.

There are a number of other groups that also exist in the same OU as the 1st group and other OU's that also are not available in the list to import.

Any ideas why or how to fix this ?

This is needed to setup roles and permissions for the Packaging teams and management.

[Cary_R]

Hello Again, Atlas.

It sounds like you have a peculiar situation going on. Does your AD Environment use multiple domain controllers? If so, it's possible you can't see the other group because it exists on another domain controller, and you're connected to the local catalog port (389). To connect to the Global Catalog, try configuring the connection on port 3268.

[Atlas1]

Hi Cary 🙂 Thanks for your help so far 🙂

I tried changing the port with no success, but some of our AD guru's came and had a look and they had some questions about the LDAP query which WFM4 is doing to return the group names from AD.

It appears it is doing a "recursive" LDAP query and either hitting a timeout or "Page" limit on group numbers.

One indication of this is that if you specify the AD OU which your groups are in (on the WFM4 Directory Services Connection Administration Page in the "Base Distinguished Name" box) then it can find the missing groups which it omitted from the original import when searching AD recursively from the ROOT OU.

Our AD guys might be able to "tweak" the LDAP query used by WFM4 to return all groups if they can gain access to it.

So my question is, where would they find the LDAP query within WFM4 or AStudio v8 ?

Hope this makes sense ...

[Cary_R]

Altas,

This does make sense to me, actually. I do know that some of the views basically only ask for 500 records when searching for a group to import, although I don't know if this is the case for the initial group import. If the issue is that you have thousands of groups, it could be that it just didn't make the list like your AD gurus are saying--I've heard of cases where a domain will have 20,000 groups, and even if all of them made it into the dropdown, it'd be nearly impossible to find the right one.

As far as editing the AD Query, I'm afraid that this is handled in compiled code, and can't be edited. However, if you know the name of the group you'd like to import, you could try using the 'Filter' option on the import screen. This should support AD wildcard syntax, so for your two groups you'd filter for FG_*

[Atlas1]

Hey Cary

The filter doesn't work for me and we certainly don't have 20,000 groups ...

It's a shame that the query is in compiled mode - might I suggest that your developers allow standard LDAP queries to be passed to it as parameters for a future version ?

Having said the above, I feel I might have a work around to import groups which do not appear in the initial drop down list from the compiled query ...

The catch is that the following will break Windows Authentication login to AdminStudio Enterprise but that can be reset afterwards.

The workaround is to enter the OU path in the same box you enter the dc="xyz, dc="abc" info, in the same format as a path to the OU which contains the group(s) you need to import.

when you do a Group query from this point, the group(s) will appear in the drop down list and can be imported.

However, it is vital to remove this info after the group import and before logging out as this breaks Windows Authentication when logging in.

Removing this info will enable Windows Authentication once more.

This seems to work for me for now and I hope this helps anyone in a simillar situation and this info can be passed on.

Thanks for your help so far.

[Cary_R]

Atlas,

Well, if there's an issue, we really should address it. Here's what I'd get and post here, so we can reproduce this and make sure it gets fixed:

1. Post the 'DistinguishedName' for the newly imported group's record. This will be in the AMS_Person table of the database
2. Have your AD gurus capture the query that we send out. I use Ethereal for this, since it's very, very good at diagramming packets, but I'm sure they have their own clever tools.

I expect that there's a visible disconnect between what WFM querys for, and the overall descriptor of where the group lives.