Escaping principalName in LDAP filters

[Elliot Kendall]

We migrated our staging IdP to a new deployment managed by Chef last
weekend. Things have gone generally well, but the sheer number of
variables that changed at the same time have made it difficult to track
down a few issues.

One of these is a user who can no longer log in with the "domain\"
variation of her AD credentials. Using aacli, cranking up the Shib
debug logging, and capturing LDAP traffic, I think I can see why. I
run:

$ /opt/shibboleth-idp/bin/aacli.sh --configDir /opt/shibboleth-idp/conf --principal 'somedomain\someuser' --requester "https://some.sp"

In the debug output I see:

19:05:02.649 - DEBUG [edu.internet2.middleware.shibboleth.common.attribute.resolver.provider.dataConnector.LdapDataConnector:308] - Search filter: (|(ucsfEduLabeledAccountName=somedomain\someuser activedirectory)(ucsfEduSFID=somedomain\someuser))

And in the actual LDAP packets, I see:

(|(ucsfEduLabeledAccountName=somedomainsomeuser activedirectory)(ucsfEduSFID=somedomainsomeuser))

So evidently the principalName is not being escaped correctly.

As far as I can tell, LDAP escaping is being attempted in the
LDAPValueEscapingStrategy class in LdapDataConnector.java in
java-shib-common. Here's the line"

return value.replace("*", "\\*").replace("(", "\\(").replace(")", "\\)").replace("\\", "\\");

But that's not the proper way to escape LDAP. The RFC says that *, (,
), backslash, and ASCII 0x00 should be escaped, by replacing them with
a backslash followed by their two-digit hex value. And anyway, the code
above is replacing a backslash ...with a backslash. So I swapped in a
new version that should do the right thing:

return value.replace("*", "\\2a").replace("(", "\\28").replace(")", "\\29").replace("\\", "\\5c").replace("\0", "\\00");

But I keep seeing the same thing. Is the LDAPValueEscapingStrategy
class actually being used? I don't pretend to understand the code to
any reasonable extent.

What's strangest of all is that in production, I see the same behavior
with aacli, but it *works* using the IdP itself. Maybe just aacli is
missing the filtering somehow? But in that case, why would it be
failing for the IdP itself in stage?

Sorry for the long message, and thanks in advance for any suggestions.

-- 
Elliot Kendall
IAM Support Engineer - Single Sign On
Information Technology Services
University of California, San Francisco