Allow non case sensitive LDAP search comparrison capabilities

Richard Courtenay 9 years ago updated by anonymous 9 years ago 2

I'm building a Powershell based connector that integrates with a system with a few thousand records. Each record has a User Name which must be unique, however not all users are to be imported into FIM. The IdB Powershell MA has to be provisioned to, so as part of that a unique User Name has to be generated.

This has lead me down the route of developing extension code to perform an LDAP lookup on the Identity Broker 5 LDAP interface to check whether a user name is available or not (as I can't compare with the metaverse since the end system isn't fully represented there). I've found that the string attributes exposed by the Identity Broker 5 LDAP interface have an Equality rule of 'caseExactMatch'. I can't guarantee what the case is of data in that end system unless I manipulate it on import to Identity Broker (have my Powershell MA cast to Upper case for example). As a result, any query against the LDAP interface is going to be complicated by the fact that I can't merely search for objects with (USNAME=Svcfimadmin) since that won't give me a result is the USNAME is 'svcfimadmin'. I would need to use (USNAME=svcfimadmin) to get any result. Instead I'll likely need to do something like get the first character and import all objects with that name, grab all the User Names and manipulate them in code.

That could be avoided if I could set the comparison to be case insensitive. I can't really think of any cases at all where I'd want a comparison to be case sensitive, and indeed on review of the issue it appears that Active Directory and other systems typically have comparisons set as case insensitive (a few attributes are sensitive). Many end systems will ignore the case for attributes like Account Names etc too.

I imagine the case sensitive could make more difficult in other situations where someone wants to make use of the LDAP interfaces to perform searches and the like.

I'm not sure how feasible it would be to add a 'case insensitive' string type, or provide a flag that could be set on an attribute basis to determine how searches via the LDAP interface are handled.