LDAP import missing values

[bennyphipps]

Hi,

we've got a LDAP data source setup (using a MID Server) which is only pulling in 6000 out of 7000 records.   I can see AD groups that are virtually identical in name and all other attributes (except the obvious ones like ObjectSID, ObjectGUID samAccountname etc) some which are included and others which are not there's no fields with massive values in either etc.

This is not a problem with Transform map as the data is missing from the import itself.   I've tried clearing down the Filter in the OU Definition and that made no difference either.

I can view the AD Groups from the instance when I use the LDAP Browse functionality ok though.

Can anyone help or suggest anything?   My import table field sizes are all pretty large to account for truncation etc but some of the groups.

Cheers,

Ben

[poyntzj]

Try with my filter that I use and change the name to be CN=Data*

See if that brings them back

Our filter only brings in 325 groups as that is all we need for granting process users, approvals, notifications.

we choose not to bring in all groups.

We do bring in 45000 plus users over 4 regions.   EMEA is the largest with over 20000 users.

Are you going via a MID server or over a VPN ?

[bennyphipps]

Hi,

We're connecting to LDAP through a MID server using LDAPS port 636.

Having NO filter whilst browsing shows me the data but I don't think you can have no filter in your OU Definition

[poyntzj]

At least we now have a difference, we are not going via a   MID server.

what happens with this filter

(&(objectClass=group)((cn=*Data*)))

got to ask, do you need all the groups ?

[bennyphipps]

Hi,

The only real commonality between all the groups in this OU is that they are (objectclass=group) and are all in the same OU (ie all of them)...   there are some groups that do not have DATA in them.

We do need all of the groups really... Mainly because there could be seperate activities to validate the actual AD groups based on OU and this is where all valid ones arise.

There are otehr potential solutions to fix it by setting up seperate OU definitions and data sources transform maps etc etc I guess but I don't think i should have to do that.

I'm trying now the rather pointles looking filter of

(|(sAMAccountName=*)(sAMAccountName=DATA*))

to see if this makes any difference.

Regards,

Ben

[poyntzj]

Hi Ben

I was only asking about the groups- I appreciate every company does things differently which is why I asked.

For us, a lot of our groups are pure security or DL's so we have to filter as it is pointless bringing in so many groups for no reason.

Trying a filter with sAMAccountName=DATA* will be of interest to see if the groups do come back on a specific filter

I do agree that if a group can be imported via sAMAccountName=<group name>, and it is of the objectClass=group

then it should come in regardless of the LDAP query as long as it has matched the filter and FDN

I would suggest this filter just to limit the query to groups where the name contains Data

(&(objectClass=group)((sAMAccountName=*Data*)))

The filter you have will still try to bring in all groups and I would like to know if all the *data* groups can be imported on their own.

The only other thing that is in my head, is that there is a app on the share site that will import a file via the MID server - quite useful.   I have seen that someone on here has amended the code for Eureka as there was a limit to the number of records that could be imported.

This maybe totally unrelated, but it may have a bearing.   afterall, if the LDAP query runs and is then imported back via a similar method before being processed by Servicenow, you may have encountered the same limitation.

on our test instance, I have just enabled and run a test import using the filter of (&(objectClass=group)) from our standard FDN.   It has imported 6991 records

I did wonder if it was a case issue, but both these filters

(&(objectClass=group)(sAMAccountName=*itsm*))

(&(objectClass=group)(sAMAccountName=*ITSM*))

bought back the same number of groups.

I am at the stage where I would be inclined to raise a HI ticket and outline everything that has been tested and tried and see if they can see anything.

Sorry we don't seem to be progressing this and getting it working