Here is the filter I am using:
(&(samaccountname=KBOX_USER_NAME)(memberOf=CN=IS Employees,OU=Groups,DC=xxxx,DC=xxxxxxxxxx,DC=com))
 If I replace KBOX_USER_NAME with * and test, I get an accurate count of the members of that group in AD.
If I replace KBOX_USER_NAME with the name of an account that I know is a member of that group and test, it returns a count of 1, and returns a zero if an account is specified that is not in that group in AD.
So.... that leaves me confused at to why even after the user has logged into the portal, the label does not get applied to the user.
Any ideas or suggestions would be greatly appreciated. 

4 Comments   [ + ] Show Comments

Comments

  • Dumb question but it is enabled right? Filter type is User not Machine.
    • Yes... User, not Machine.
  • The variable is KBOX_USER, not KBOX_USER_NAME
  • Nico_K: For LDAP Authentication you are correct. For LDAP Labels, it would be KBOX_USER_NAME for user labels.
  • At this point, is this something I could open a case with Support for?
Please log in to comment

Answers

0

Went and reviewed a couple of my own labels, then reread what I had typed here....

When you test it, the test is taking the "samaccountname" literally.  Since you don't have a user named KBOX_USER_NAME in your AD, that's why you get 0 results.  When you replace it with an * to test it, you see the count of all results that meet the rest of the filter.  From your testing, it looks like everything is set correctly.

Have you enabled the LDAP label?  There's an 'Enabled' checkbox at the top of the LDAP label : edit detail screen.  Very easy to overlook.

If the label is enabled, have you done an LDAP import since enabling it?

Answered 08/07/2013 by: ShawnCarson
White Belt

  • Yes, the label is, and has been enabled. And yes, the fact that it seems to bring back the appropriate results when testing makes it all the more confusing as to why it is not working.
Please log in to comment
Answer this question or Comment on this question for clarity