Potential LDAP injection bug

In: ActiveDirectoryUnixAuthenticationProvider.java

Line 85:
context.search(toDC(domainName),"(&
(userPrincipalName="principalName")(objectClass=user))", controls);

Line 89:
renum = context.search(toDC(domainName),"(&
(sAMAccountName="username")(objectClass=user))", controls);

String appends with no escaping leave the code vulnerable to an (unlikely) LDAP
injection attack.

The Acegi code already has protection against this, you can see how that's
implemented here:
https://src.springframework.org/svn/spring-security/tags/release_1_0_6/core/src/main/java/org/acegisecurity/ldap/search/FilterBasedLdapUserSearch.java

(this eventually ends up using the spring code for encoding, in
org/springframework/ldap/support/LdapEncoder.java)

If you use the LdapTemplate code to do this, as acegi did, see the notes about
referrals at:
http://static.springframework.org/spring-ldap/docs/1.1/api/org/springframework/ldap/LdapTemplate.html

Incidentally, this referrals stuff should be irrelevant for authentication; if
you connect to the Global Catalog Server (port 3268) for your forest, not the AD
server (port 389), you should not be seeing referrals. Hudson is querying
_ldap._tcp.<domain name>, but should probably be querying
_gc._tcp.<DnsForestName>. (equivalent, I think, to COM4J.getObject(IADs.class,
"GC:", null); in the windows version, instead of COM4J.getObject(IADs.class,
"LDAP://RootDSE", null)