07/13/2012 5951 views

Is anyone successfully using group membership (memberof) in their search filters on the 2000? I've been banging my head against the wall. I know I have the right syntax because the filter I want works on the 1000.

Finally got this to work on the 2000:


(&(samaccountname=KBOX_USER)(|(cn=admin1)(cn= admin2)(cn= admin3)(cn= admin4)))

Accomplishes the same thing, but the group membership would be cleaner.


1 Comment   [ + ] Show comment


  • All,

    Did anyone find anything on this? I have the same problem with my K2000. It will no longer import users using ldap. It tests successfully but pulls zero users even though there are users in that OU. Any help would be appreciated.

    Service account has access to the OUs

    OK: LDAP Search successful with 0 entries found.
    OK: Secondary bind using [] successful
    OK: LDAP Test Successful. Closing connection.
    • I just had this same issue. I got it to work by what Corey said below. Do this:


      samaccountname is on top on the K1000. It needs to be on the bottom on the K2000. Doing this fixed my issue.

All Answers


Are you trying to import them as users or admin users? 

Answered 07/13/2012 by: dugullett
Red Belt


Try this:



Lead L3 Enterprise Solutions Engineer, K2000
If my response was helpful, please rate it!

Answered 07/13/2012 by: cserrins
Red Belt



  I do have this specific thing working, though my syntax is slightly different.  It shouldn't make a difference, but may be worth a try:

(&(samaccountname=KBOX_USER)(memberof=CN=Group,OU=Organizational Unit,OU=OU2,DC=FDQNP1,DC=fdqnp2,DC=fdqnp3))

  My OUs and FDQN pieces are all capitalized exactly as they are in AD, and I have the samaccountname search first.  My memberof is all lower case.  Should it matter?  Probably not.

  For my LDAP Login, I specifically call out the full path to a privileged account using


  Again, I also duplicate the case.  Should it matter?  The only thing I can say is that the KACE OS is a *nix variant, so perhaps the LDAP implementation cares, even if Windows AD does not.

  Finally, again watching case, I have the Search Base DSN narrow things down to the main OU rather than the KACE default Base DN.


  I also use an IP for the Servername rather than a Hostname.

  Past that, is it possible you might have special characters in an OU or group name?  I know I have gotten away with %, but you may or may not get away with some others like &, which I have definitely seen people use for things like OU=Users & Computers or CN=Sales & Marketing.

Answered 07/13/2012 by: philologist
Red Belt

  • Thanks, phil. I have used the FQDN for testing, but no luck. I thought I had a breakthrough when I used the softerra ldap browser and discovered that the memberof attribute was not being read by my ldap user, but I fixed that and still no luck.

    Maybe the group name is a problem because it has a dash, but since I have it working with a filter that uses the samaccount and any of 4 specified CNs (like in my OP), I'll probably just live with it that way.
  • create a group with a simple name nest the group with the dash in it, ldap query the simple group name, AD should pass the members (users) of the top most group not the nested group name

Thanks for the responses. Sorry, I wasn't clear in my original post. I've already tried the (&(MemberOf=CN=groupname,OU=ouname,OU=ouname,DC=domainname,DC=com)(samaccountname=KBOX_USER)) syntax in my search filter. When I run the test in the ldap config page, I get "successful" messages, but 0 results returned, and I can't actually log in. When I set the filter like in my OP, or drop the memberof requirement altogether, I can log in with the admin account. That's why I was asking specifically if anyone is using memberof in their filter. It sort of looks to me as if ldap is working on my kbox, but memberof is not recognized as a legit parameter. Seems farfetched, but no more so than a few other things I've seen.

Answered 07/13/2012 by: tpr
Black Belt


If could also be the account you ldap attach to the domain with may not have the proper rights to the group attribute.  Try testing with a superuser that has all rights in the domain.   This will help you know if the kbox end or the domain end is the problem.

Answered 07/13/2012 by: SMal.tmcc
Red Belt


I hope the below link should help you..


Answered 07/13/2012 by: jagadeish
Red Belt

  • Thanks, but that link opens up a pdf that says:
    LDAP Integration:
    Last update: Dec 31 1969, 4:00 pm
  • I think something went wrong...

    Here it is..

  • Goes to the same link posted above: http://www.kace.com/support/resources/kb/article/How-to-setup-LDAP-Authentication-Integration#Step_Three_KBOX_Server_setup