NAV authentication with LDAP + MS AD

[Mischa Diehm]

Hi,

this bug broke LDAP-Auth for us too but we are using OpenLDAP as a backend.
After applying the patches to our system things work nice again.

Debug output:

put_simple_filter: "uid:caseExactMatch:=foobar"
...
[error] UNAVAILABLE_CRITICAL_EXTENSION: {'info': 'Bad search filter',
'desc': 'Critical extension is unavailable'}

Mischa
--
Mischa Diehm | Network Operations Center (NOC)
UniBasel | UniRechenZentrum (URZ)
Klingebergstr. 70 | CH-4056 Basel
Tel. [phone] | http://urz.unibas.ch

From: Morten Brekkevold <morten.brekkevold-***@public.gmane.org>
Date: Donnerstag, 13. März 2014 14:37
To: Sjøholt Steinar Otto <ssj-***@public.gmane.org>
Cc: "nav-users-***@public.gmane.org" <nav-users-***@public.gmane.org>
Subject: Re: NAV authentication with LDAP + MS AD

On Wed, 12 Mar 2014 16:06:50 +0100 Morten Brekkevold

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.

[1] https://bugs.launchpad.net/nav/+bug/1291956

[Morten Brekkevold]

Post by Mischa Diehm
this bug broke LDAP-Auth for us too but we are using OpenLDAP as a backend.
After applying the patches to our system things work nice again.
put_simple_filter: "uid:caseExactMatch:=foobar"
...
[error] UNAVAILABLE_CRITICAL_EXTENSION: {'info': 'Bad search filter',
'desc': 'Critical extension is unavailable'}

Is this extension maybe version-specific in OpenLDAP? It worked fine on
our OpenLDAP-based catalog when we tested it.

Nevertheless, I'm glad the fix works for you too; we will likely do
another 3.15 release this week, with the fix in it.

[Sjøholt Steinar Otto]

Hi

I'm happy to say the fix works for MOST of our users.

Unfortunately not for me...

I have traced it down to the fact that i have a "ø" in my last name. Users with names not containing "æøå" can log in just fine.
[Tue Apr 01 11:29:17 2014] [error] [Tue Apr 01 11:29:17 2014] [ERROR] [pid=18668 django.request] Internal Server Error: /index/login/
[Tue Apr 01 11:29:17 2014] [error] Traceback (most recent call last):
[Tue Apr 01 11:29:17 2014] [error] File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 111, in get_response
[Tue Apr 01 11:29:17 2014] [error] response = callback(request, *callback_args, **callback_kwargs)
[Tue Apr 01 11:29:17 2014] [error] File "/usr/lib/python2.7/dist-packages/django/views/decorators/debug.py", line 69, in sensitive_post_parameters_wrapper
[Tue Apr 01 11:29:17 2014] [error] return view(request, *args, **kwargs)
[Tue Apr 01 11:29:17 2014] [error] File "/usr/lib/pymodules/python2.7/nav/web/webfront/views.py", line 92, in login
[Tue Apr 01 11:29:17 2014] [error] return do_login(request)
[Tue Apr 01 11:29:17 2014] [error] File "/usr/lib/python2.7/dist-packages/django/views/decorators/debug.py", line 34, in sensitive_variables_wrapper
[Tue Apr 01 11:29:17 2014] [error] return func(*args, **kwargs)
[Tue Apr 01 11:29:17 2014] [error] File "/usr/lib/pymodules/python2.7/nav/web/webfront/views.py", line 127, in do_login
[Tue Apr 01 11:29:17 2014] [error] account = auth.authenticate(username, password)
[Tue Apr 01 11:29:17 2014] [error] File "/usr/lib/pymodules/python2.7/nav/web/auth.py", line 95, in authenticate
[Tue Apr 01 11:29:17 2014] [error] auth = ldapauth.authenticate(username, password)
[Tue Apr 01 11:29:17 2014] [error] File "/usr/lib/pymodules/python2.7/nav/web/ldapauth.py", line 127, in authenticate
[Tue Apr 01 11:29:17 2014] [error] user.bind(password)
[Tue Apr 01 11:29:17 2014] [error] File "/usr/lib/pymodules/python2.7/nav/web/ldapauth.py", line 186, in bind
[Tue Apr 01 11:29:17 2014] [error] self.ldap.simple_bind_s(user_dn.encode(encoding),
[Tue Apr 01 11:29:17 2014] [error] UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 18: ordinal not in range(128)


regards
Steinar Otto Sjøholt
Seniorengineer - IT-Services
Aalesund University College

-----Original Message-----
Sent: 24. mars 2014 09:11
To: Mischa Diehm
Subject: Re: NAV authentication with LDAP + MS AD

Post by Mischa Diehm
this bug broke LDAP-Auth for us too but we are using OpenLDAP as a

backend.

Post by Mischa Diehm
After applying the patches to our system things work nice again.
put_simple_filter: "uid:caseExactMatch:=foobar"
...
[error] UNAVAILABLE_CRITICAL_EXTENSION: {'info': 'Bad search filter',
'desc': 'Critical extension is unavailable'}

Is this extension maybe version-specific in OpenLDAP? It worked fine on
our OpenLDAP-based catalog when we tested it.
Nevertheless, I'm glad the fix works for you too; we will likely do
another 3.15 release this week, with the fix in it.
--
Morten Brekkevold
UNINETT