LDAP auth against MS AD broken since NAV 3.14.1592653
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Network Administration Visualized |
Fix Released
|
High
|
Morten Brekkevold |
Bug Description
It appears that the fix for bug 1207722 introduced a regression that breaks NAV's support for LDAP authenticating against a Microsoft AD server (using `search` as the `lookupmethod` in `webfront.conf`).
The fix introduces the use of the extensible match filter `caseExactMatch`, which is not actually suppported by AD. NAV will not find any users in an AD server.
Also, erroneously, this causes NAV to fall back to authenticating users using their cached password from the NAV database. When an LDAP user can no longer be found in the LDAP catalog, login should be denied.
The original fix should be backed out. The suggested real fix is to not use the username as typed in by the user themself, but use the canonical form of the username found in the matching LDAP record, when creating a new NAV account.
Since NAV always looks up the username from its internal database before contacting the LDAP server, this fix effectively means that NAV must switch from case sensitive usernames to case insensitive ones. This shouldn't be an issue for most users, but it MAY be an issue for someone out there, and a warning about this MUST be put into changelog.
Changed in nav: | |
status: | Confirmed → In Progress |
importance: | Undecided → High |
Changed in nav: | |
status: | Fix Committed → Fix Released |
fix here: https:/ /nav.uninett. no/hg/stable/ rev/beed5187c0a d