openIDM 5.5 Connector Problem with filtering incoming LDAP data

This topic has 2 replies, 2 voices, and was last updated 4 years, 3 months ago by lois54.

  • Author
  • #21473

    Hello, Newby question here. I am happy to say that I was able to read in the LDAP data for just user accounts with my LDAP connector. My problem is that I am getting too many. I want to filter out accounts with /bin/false as their login shell.

    In my provisioner file for the LDAP connector I have this:
    "accountSynchronizationFilter" : "(!(loginShell=/bin/false))",

    and also
    "accountSearchFilter" : "(!(loginShell=/bin/false))",

    Any suggestions on what I am doing wrong? Below is the complete configurationProperties section of the provisioner file.

    “configurationProperties” : {
    “filterWithOrInsteadOfAnd” : false,
    “objectClassesToSynchronize” : [
    “attributesToSynchronize” : [
    “uid, cn,sn,givenName,uidNumber,gidNumber,loginShell”
    “passwordDecryptionInitializationVector” : null,
    “synchronizePasswords” : false,
    “changeNumberAttribute” : “changeNumber”,
    “modifiersNamesToFilterOut” : [ ],
    “passwordDecryptionKey” : null,
    “credentials” : {
    “$crypto” : {
    “type” : “x-simple-encryption”,
    “value” : {

    “passwordAttributeToSynchronize” : null,
    “changeLogBlockSize” : “100”,
    “useTimestampsForSync” : true,
    “accountSynchronizationFilter” : “(!(loginShell=/bin/false))”,
    “removeLogEntryObjectClassFromFilter” : true,
    “alternateKeyStorePassword” : null,
    “groupSynchronizationFilter” : null,
    “groupMemberAttribute” : “uniqueMember”,
    “accountSearchFilter” : “(!(loginShell=/bin/false))”,
    “privateKeyAlias” : null,
    “ssl” : true,
    “maintainPosixGroupMembership” : false,
    “groupSearchFilter” : null,
    “referralsHandling” : “follow”,
    “host” : “”,
    “maintainLdapGroupMembership” : false,
    “resetSyncToken” : “never”,
    “vlvSortAttribute” : “uid”,
    “baseContexts” : [
    “blockSize” : “100”,
    “groupObjectClasses” : [
    “accountUserNameAttributes” : [
    “failover” : [ ],
    “port” : “636”,
    “passwordAttribute” : “userPassword”,
    “useDNSSRVRecord” : false,
    “getGroupMemberId” : false,
    “startTLS” : false,
    “allowTreeDelete” : false,
    “respectResourcePasswordPolicyChangeAfterReset” : false,
    “uidAttribute” : “nsuniqueid”,
    “principal” : “cn=pwmadmin,cn=Administrators,cn=config”,
    “accountObjectClasses” : [
    “alternateKeyStoreType” : null,
    “passwordHashAlgorithm” : null,
    “alternateKeyStore” : null,
    “authType” : “simple”,
    “useBlocks” : true,
    “readSchema” : true,
    “usePagedResultControl” : true,
    “sendCAUDTxId” : false,
    “baseContextsToSynchronize” : [

    • This topic was modified 4 years, 4 months ago by lois54.
     Bill Nelson

    Hi @lois54,

    I’m not a big fan of using the accountSearchFilter to “filter out” entries that you don’t want returned (negation). Instead, I would suggest that you create a filter that specifies the universe of entries that you want to “consider” (inclusion), and then filter out unwanted entries in your sync.json mapping using the validSource filter.

    There are a couple of reasons for this. First, later you may decide that you do want these other accounts returned and processed for a different use case (maybe use a different mapping for alternate processing). Second, is that a filter like this would return ALL entries that don’t match this filter – including entries that don’t even have the attribute defined in the entry (i.e. containers). So while this might not bite you now, who knows in the future.

    Now, having said that, I don’t see anything specifically wrong with your filter. In fact, I created a similar scenario to test it out on my local box and it worked fine. Have you looked in your LDAP server’s access log to see how it is processing this filter? Any errors? How many entries did the filter return compared with the number of entries contained in the People container?



    Thank you Bill! I have another question but I will post it in a new message.


Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.

©2022 ForgeRock - we provide an identity and access platform to secure every online relationship for the enterprise market, educational sector and even entire countries. Click to view our privacy policy and terms of use.

Log in with your credentials

Forgot your details?