i have found some info, its from another type of device, but can be helpful :
LDAP - Custom Filters
General LDAP filter syntax applies to the Xerox device, so it is useful to know how LDAP filtering works in the general world before trying to build Xerox LDAP custom filters.
Searching the web for “LDAP filters” is a good place to start learning.
Discovery and ConnectKey devices provide 3 contexts in where to apply LDAP custom filters, and I’ll sum up here how/when to use these:
1 – Authentication (Prepend Domain Name)
This “filter” is working in the context of Network Authentication (be it Kerberos, SMB or LDAP authentication) and LDAP bind.
Once activated, this “filter” will append domain info to the Login Name typed by the user during Network Authentication, every time the scanner needs to bind with the LDAP server.
So the filter gives you a way to automatically domain-qualify the Login Name typed by the user during Network Authentication, and is as such useful only when your LDAP server requires domain qualified login names, and in combination with the “Logged-in User” as scheme to access the LDAP Server.
So if you’re using a System User to bind with the LDAP server, this filter is unnecessary, as you would simply set the System User with a domain qualified Login Name in the first place.
2 – Email address book filter
This tool provides a way to build your own address book search filter.
The filter applies to the context when you’re at the device, using the EMAIL service and in the network address book searching for a user’s email address.
It is an extension, or rather a replacement of the Search Criteria function from the main LDAP config page, where you can chose between 3 preset filters to specify what attributes you want to search for; those called “Name” (which refers to “Common Name” or “cn”), “Surname & Given Name”, and “Display Name”. These preset filters would cover most customers’ needs, but there exists situations where a custom filter would be useful.
If we were to convert these presets into filter syntax (that you could use as custom filters) here’s what you’d get:
Name:
(cn=LDAP*)
Surname & Given Name (in reality Surname OR Given Name):
(|(sn=LDAP*)(givenName=LDAP*))
Display Name:
(displayName=LDAP*)
For another example - say in the unlikely event that your employees are better at numbers than names, they might prefer searching the address book by typing telephone extension numbers. To achieve it you could use this filter:
(telephoneNumber=*LDAP*)
In these examples you see the use of the important identifier “LDAP“.
The word “LDAP” in this context, is a dynamic place-holder containing the string that the user typed into the address book.
We can imagine the user typed the telephone extension “7686”, which will be inserted into our filter and replace the word “LDAP”.
So, in this example, before sending the filter to the LDAP server, the scanner will replace the word “LDAP” by “7686”, and we end up with the actual filter:
(telephoneNumber=*7686*)
The asterisks are regular wildcard characters, part of the standard/universal LDAP filter syntax, and how to use wildcards in filters will not be covered in this overview, I’ll just say that it sometimes makes sense to use wildcards before and/or after the search criteria string, depending on the nature of your search.
Keep in mind; once you activate the Email Address Book Filter, it disables whatever preset filter is activated on the main LDAP config page, and only your custom filter will be active.
3 – User ID Query Filter
This filter is used in combination with Network Authentication (Be it Kerberos, SMB or LDAP authentication) and specifically applies to the function “Personalize Touch UI” that automatically retrieves authenticated user data from LDAP, specifically Home directory for “Scan to Home” or email address for the “Email” and “Internet Fax” services (to auto populate the user’s FROM / TO fields).
When “Personalize Touch UI” is enabled, then immediately behind the user’s Network Authentication session, the scanner will use the typed Login Name in an LDAP query and try to fetch the authenticated user’s data.
Let’s imagine a situation where the scanner is set up with "Personlize Touch UI", without any custom filter applied. In our thought experiment, a user, Kirsten Dunst, authenticates with her login name “kdunst”.
Without a custom filter applied, the scanner will by default use the typed Login Name and build a User ID query filter that targets the LDAP attribute “sAMAccountName”, which is in the majority of situations, a Microsoft Active Directory equivalent to an unqualified Login Name.
So if Kirsten Dunst's network was equipped with the fairly standard combo of Microsoft Kerberos and Microsoft Active Directory, then “Personalize Touch UI” would work right out of the box with no use for a custom “User ID Query Filter”.
The filter sent to the LDAP server will in our example end up being (sAMAccountName=kdunst), and a Microsoft Active Directory will easily handle such query and fetch her home address for scan to home, or auto-populate her email address.
But Kirsten Dunst's network might not have a Microsoft Active Directory.
She might find herself on a network where Lotus Domino or openLDAP is used instead, and she notices she can’t scan to home, and her email is not auto-populated.
This is because both Lotus Domino and openLDAP directories do not know the “sAMAccountName” attribute. Instead, these directories use an equivalent attribute called “uid”.
So the filter (sAMAccountName=kdunst) is not relevant in such a situation.
To help Kirsten and make “Personalize Touch UI” work for her, one could then enable the “User ID Query Filter” and this would alter the LDAP query following the Network Authentication session.
In this specific example situation, the filter to use is simply:
(uid=LDAP),
Notice the word “LDAP” is a dynamic place-holder for Login Name, and will be replaced with “kdunst” or whatever Login Name you typed during Network Authentication.
With the custom filter in place, the scanner would construct filter (uid=kdunst) and send it to the Domino or openLDAP server, then Kirsten’s data would successfully be returned to the scanner. She would now be able to Scan to Home, and when using Scan to Email, her own email address would autopopulate her TO and FROM fields.