On Mon, 10 Mar 2014 15:01:04 +0000 Sjøholt Steinar Otto ssj@hials.no wrote:
This were working fine for a while, but then the issue with case sensitive usernames appeared (Bug#1207722) The fix seems to have broken LDAP authentication with AD completely.
Ouch... I do faintly remember #1207722, and I thought we actually tested it against our own obscure AD server. My memory may be faulty.
As we are a small group of nav-users here, it took a while (and a passwordchange) to discover this.
Then I'm guessing it doesn't work for new user registrations either, or?
What happens now is that authentication works (for existing users) as long as the user doesn't change his password. Any new passwords will not work (as the LDAP-query against AD keeps failing), BUT the old (cached?) password still works(!)
I don't know if this is by design... But it seems a little flawed to me.
It's not by design. Authentication against the cached password hash should only take place when the LDAP server is unreachable.
Since the addition of ":caseExactMatch:" doesn't work with AD, a better solution to Bug#1207722 would be to have NAV check the output of the LDAP-query to get the actual username (with correct casing) and use this to create the user in the database instead of the actual userinput.
You are probably right, but we will have to look into rewriting the way external authentication is invoked.
NAV's login page doesn't concern itself with what any external authentication mechanism actually does, only that it returns a good or bad status. There is currently no mechanism to pass a revised username back to the login page, since it only cares about what the user actually typed into the login form.
Another question to ponder is this: Is it possible, at all, to create two separate AD accounts, one with "foo" as the sAMAccountName, and one with "FOO" as the sAMAccountName? That would really make things ugly...