An unfortunate side effect of the 147750 fix is when users select the Notes Driver's "Migrate into Identity Vault" button (wizard) and then fill in the prompts to migrate for all Notes users with Surname of "A*" (for example) into eDirectory, the initial query fails because the "A*" is interpreted literally instead of as a search for all Surnames that start with the letter 'A'.
The asterisk is no longer considered a wild card because the search-attr value is automatically converted from 'A*' to 'A\\*' before it is submitted to the db.search( @Matches ) function.
Inasmuchthe asterisk character seems to be somewhat of a universalwild cardcharacter at least for Domino and LDAP, it seems fitting that thischaracter beallowed by default to pass through to the Domino system.
As such, with IDM 3.0.1, the NotesDriverShim (v2.2.3) query processorwasadjusted (defect#147750) in an attempt to accommodate all thesespecialcharacters during searches in a 'literal' fashion (by appropriatelyescapingthem automatically). This was done at the request of Notes Driverusersexperiencing 'empty' query results when their searches included thesespecialcharacters. The ability for the NotesDriverShim to detect and utilizean XMLmatch-syntax attribute was also added for obvious backwardcompatibilityreasons needed by the NotesDriverShim.
After a cursory look at the LDAP filter specification, we believe onlyanasterisk '*' can be used as a special wild card character for an LDAPsearch. Assuch, and due to its universal nature, we believe the asterisk shouldprobablybe allowed to pass through the NotesDriverShim as a wild card character.
Currently, the workaround option for the problem would be to insert apolicy inthe Output Transformation policy chain that inserted the'match-syntax="true"'attribute when search-attr values contained asterisks (*).