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.
I take that back. It's been a while since I hacked on this part of NAV,
and last time it was refactored, this was made easily possible. I filed
a report at [1], and have committed a fix.
The downside to this fix is that all NAV login names will now be case
insensitive. Hopefully, people using NAV aren't in the habit of creating
separate users with the same name using different casing.
The fallback to cached password when the user wasn't found was in
reality a different problem, but I fixed it as part of [1] anyway.
--
Morten Brekkevold
UNINETT