Robin Shen [05/Jan/07 05:55 PM] Matt, Thanks for this comment. In version 1.2, a separate LDAP authenticator will be added to provide the self-binding functionality. So it should not hurt the existing functionality connecting to AD. Thanks. Robin

Matthew Inger [05/Jan/07 10:13 AM] I've looked at the code for this, and there is some reasoning behind why there is a specific bind user. Specifically, Active Directory typically requires a user@domain style login to bind to the server, so just inputting a username like "foo" will not get you logged in (even with the correct password). In this case, you need to bind to the directory, and search for a user with a given sAMAccountName:    (&(sAMAccountName={0})(objectclass=user)) Once you have the LDAP entry, you can use it's context name and rebind using that. With active directory, this seems to be the only way to properly check the password. So, if your windows name in the domain "foo.com" is "foo", we would first bind to the controller, and lookup the entry with the following filter:      (&(sAMAccountName=foo)(objectclass=user)) It would return an LDAP entry whose context name is "[email protected]". Then it can bind using that name and the entered password. Binding as "foo" does not work. That being said, the real solution is to have a specific ActiveDirectory authenticator which would have a setting which indicated the domain, and this could be tacked onto the end of the user name. This would eliminate the need for all the search conditions as needed a central bind user. I could write this authenticator rather easily, but how to plug it into the UI would be another story (tapestry has always kind of baffled me, and last i looked at the qb source code, it's not easy to add an authenticator).