Hi
We are running NAV with LDAP-authentication against MS ActiveDirectory.
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.
As we are a small group of nav-users here, it took a while (and a passwordchange) to discover this.
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.
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.
Steinar Otto Sjøholt Aalesund University College
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...
Hi
-----Original Message----- From: Morten Brekkevold [mailto:morten.brekkevold@uninett.no] Sent: 12. mars 2014 16:07
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?
Nope, that fails with the following errormessage: "Error while talking to LDAP: User object was not found: (samAccountName:caseExactMatch:=<username>)"
Probably since AD doesn't understand the ":caseExactMatch:" syntax.
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...
No, that isn't possible (just tested). AD uses case insensitive usernames.
Steinar Otto Sjøholt Seniorengineer - IT-Services Aalesund University College
On Wed, 12 Mar 2014 16:06:50 +0100 Morten Brekkevold morten.brekkevold@uninett.no wrote:
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
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
On Fri, 21 Mar 2014 07:34:15 +0000 Mischa Diehm mischa.diehm@unibas.ch wrote:
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'}
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.
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.
From Apache error.log: [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----- From: Morten Brekkevold [mailto:morten.brekkevold@uninett.no] Sent: 24. mars 2014 09:11 To: Mischa Diehm Cc: Sjøholt Steinar Otto; nav-users@uninett.no Subject: Re: NAV authentication with LDAP + MS AD
On Fri, 21 Mar 2014 07:34:15 +0000 Mischa Diehm mischa.diehm@unibas.ch wrote:
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'}
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
On Tue, 1 Apr 2014 11:29:27 +0000 Sjøholt Steinar Otto ssj@hials.no wrote:
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.
[snip]
[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)
Oops. The code does not consider that the user search result from the LDAP server is already encoded as UTF-8. Attempting to encode an already encoded string will cause Python to attempt to decode it from ASCII to unicode, before encoding that as UTF-8 again.
And I'm sorry to say, your name is not ASCII compatible ,)
It's a quick fix; I've taken the liberty of patching your server so you can log in again, Steinar :)
Hi,
I pulled the fix from:
https://nav.uninett.no/hg/stable/rev/23d774154094
this makes the login with wrong credentials work (before we had an error) but in case of good credentials the system still crashes. Debug output below:
read1msg: mark request completed, ld 0x7fdfb4d38300 msgid 4
request done: ld 0x7fdfb4d38300 msgid 4
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 4, msgid 4)
ldap_parse_result
ldap_msgfree
[Wed Apr 02 17:23:22 2014] [error] [Wed Apr 02 17:23:22 2014] [ERROR] [pid=12954 django.request] Internal Server Error: /index/login/
[Wed Apr 02 17:23:22 2014] [error] Traceback (most recent call last):
[Wed Apr 02 17:23:22 2014] [error] File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 111, in get_response
[Wed Apr 02 17:23:22 2014] [error] response = callback(request, *callback_args, **callback_kwargs)
[Wed Apr 02 17:23:22 2014] [error] File "/usr/lib/python2.7/dist-packages/django/views/decorators/debug.py", line 69, in sensitive_post_parameters_wrapper
[Wed Apr 02 17:23:22 2014] [error] return view(request, *args, **kwargs)
[Wed Apr 02 17:23:22 2014] [error] File "/usr/lib/pymodules/python2.7/nav/web/webfront/views.py", line 92, in login
[Wed Apr 02 17:23:22 2014] [error] return do_login(request)
[Wed Apr 02 17:23:22 2014] [error] File "/usr/lib/python2.7/dist-packages/django/views/decorators/debug.py", line 34, in sensitive_variables_wrapper
[Wed Apr 02 17:23:22 2014] [error] return func(*args, **kwargs)
[Wed Apr 02 17:23:22 2014] [error] File "/usr/lib/pymodules/python2.7/nav/web/webfront/views.py", line 127, in do_login
[Wed Apr 02 17:23:22 2014] [error] account = auth.authenticate(username, password)
[Wed Apr 02 17:23:22 2014] [error] File "/usr/lib/pymodules/python2.7/nav/web/auth.py", line 79, in authenticate
[Wed Apr 02 17:23:22 2014] [error] user = ldapauth.authenticate(username, password)
[Wed Apr 02 17:23:22 2014] [error] File "/usr/lib/pymodules/python2.7/nav/web/ldapauth.py", line 151, in authenticate
[Wed Apr 02 17:23:22 2014] [error] if user.is_group_member(group_dn):
[Wed Apr 02 17:23:22 2014] [error] File "/usr/lib/pymodules/python2.7/nav/web/ldapauth.py", line 280, in is_group_member
[Wed Apr 02 17:23:22 2014] [error] result = self.ldap.search_s(group_dn, ldap.SCOPE_BASE, filterstr)
[Wed Apr 02 17:23:22 2014] [error] File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 552, in search_s
[Wed Apr 02 17:23:22 2014] [error] return self.search_ext_s(base,scope,filterstr,attrlist,attrsonly,None,None,timeout= self.timeout)
[Wed Apr 02 17:23:22 2014] [error] File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 545, in search_ext_s
[Wed Apr 02 17:23:22 2014] [error] msgid = self.search_ext(base,scope,filterstr,attrlist,attrsonly,serverctrls,clientct rls,timeout,sizelimit)
[Wed Apr 02 17:23:22 2014] [error] File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 541, in search_ext
[Wed Apr 02 17:23:22 2014] [error] timeout,sizelimit,
[Wed Apr 02 17:23:22 2014] [error] File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 99, in _ldap_call
[Wed Apr 02 17:23:22 2014] [error] result = func(*args,**kwargs)
[Wed Apr 02 17:23:22 2014] [error] UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 26: ordinal not in range(128)
ldap_free_connection 1 1
ldap_send_unbind
ldap_free_connection: actually freed
==== mail received from system ===
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/django/core/handlers/base.py", line 111, in get_response response = callback(request, *callback_args, **callback_kwargs)
File "/usr/lib/python2.7/dist-packages/django/views/decorators/debug.py", line 69, in sensitive_post_parameters_wrapper return view(request, *args, **kwargs)
File "/usr/lib/pymodules/python2.7/nav/web/webfront/views.py", line 92, in login return do_login(request)
File "/usr/lib/python2.7/dist-packages/django/views/decorators/debug.py", line 34, in sensitive_variables_wrapper return func(*args, **kwargs)
File "/usr/lib/pymodules/python2.7/nav/web/webfront/views.py", line 127, in do_login account = auth.authenticate(username, password)
File "/usr/lib/pymodules/python2.7/nav/web/auth.py", line 79, in authenticate user = ldapauth.authenticate(username, password)
File "/usr/lib/pymodules/python2.7/nav/web/ldapauth.py", line 151, in authenticate if user.is_group_member(group_dn):
File "/usr/lib/pymodules/python2.7/nav/web/ldapauth.py", line 280, in is_group_member result = self.ldap.search_s(group_dn, ldap.SCOPE_BASE, filterstr)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 552, in search_s return self.search_ext_s(base,scope,filterstr,attrlist,attrsonly,None,None,timeout= self.timeout)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 545, in search_ext_s msgid = self.search_ext(base,scope,filterstr,attrlist,attrsonly,serverctrls,clientct rls,timeout,sizelimit)
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 541, in search_ext timeout,sizelimit,
File "/usr/lib/python2.7/dist-packages/ldap/ldapobject.py", line 99, in _ldap_call result = func(*args,**kwargs)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 26: ordinal not in range(128)
<WSGIRequest path:/index/login/, GET:<QueryDict: {}>, POST:<QueryDict: {u'origin': [u''], u'username': [u'XXX-adm'], u'password': [u'***********']}>, COOKIES:{'sessionid': '59e85ca4ca567cfd8966ab12'}, META:{'CONTENT_LENGTH': '47', 'CONTENT_TYPE': 'application/x-www-form-urlencoded', 'DOCUMENT_ROOT': '/usr/share/nav/htdocs', 'GATEWAY_INTERFACE': 'CGI/1.1', 'HTTPS': '1', 'HTTP_ACCEPT': 'text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8', 'HTTP_ACCEPT_ENCODING': 'gzip, deflate', 'HTTP_ACCEPT_LANGUAGE': 'de,en-us;q=0.7,en;q=0.3', 'HTTP_CONNECTION': 'keep-alive', 'HTTP_COOKIE': 'sessionid=59e85ca4c39f3dbe7a567cfd8966ab12', 'HTTP_DNT': '1', 'HTTP_HOST': 'urz-nav', 'HTTP_REFERER': 'https://urz-nav-pet.urz.unibas.ch/index/login/', 'HTTP_USER_AGENT': 'Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0', 'PATH_INFO': u'/index/login/', 'PATH_TRANSLATED': '/usr/share/pyshared/nav/wsgi.py/index/login/', 'QUERY_STRING': '', 'REMOTE_ADDR': '1', 'REMOTE_PORT': '64036', 'REQUEST_METHOD': 'POST', 'REQUEST_URI': '/index/login/', 'SCRIPT_FILENAME': '/usr/share/pyshared/nav/wsgi.py', 'SCRIPT_NAME': u'', 'SERVER_ADDR': '1', 'SERVER_ADMIN': 'webmaster@localhost', 'SERVER_NAME': 'urz-nav', 'SERVER_PORT': '443', 'SERVER_PROTOCOL': 'HTTP/1.1', 'SERVER_SIGNATURE': '<address>Apache/2.2.22 (Debian) Server at urz-nav Port 443</address>\n', 'SERVER_SOFTWARE': 'Apache/2.2.22 (Debian)', 'SSL_TLS_SNI': 'urz-nav-pet.urz.unibas.ch', 'mod_wsgi.application_group': 'urz-nav|', 'mod_wsgi.callable_object': 'application', 'mod_wsgi.handler_script': '', 'mod_wsgi.input_chunked': '0', 'mod_wsgi.listener_host': '', 'mod_wsgi.listener_port': '443', 'mod_wsgi.process_group': 'NAV', 'mod_wsgi.request_handler': 'wsgi-script', 'mod_wsgi.script_reloading': '1', 'mod_wsgi.version': (3, 3), 'wsgi.errors': <mod_wsgi.Log object at 0x7fdfb27046f0>, 'wsgi.file_wrapper': <built-in method file_wrapper of mod_wsgi.Adapter object at 0x7fdfb4ca4a08>, 'wsgi.input': <mod_wsgi.Input object at 0x7fdfb34604f0>, 'wsgi.multiprocess': True, 'wsgi.multithread': True, 'wsgi.run_once': False, 'wsgi.url_scheme': 'https', 'wsgi.version': (1, 1)}>
On Wed, 2 Apr 2014 16:12:41 +0000 Mischa Diehm mischa.diehm@unibas.ch wrote:
I pulled the fix from:
https://nav.uninett.no/hg/stable/rev/23d774154094
this makes the login with wrong credentials work (before we had an error) but in case of good credentials the system still crashes. Debug output below:
[snip]
File "/usr/lib/pymodules/python2.7/nav/web/ldapauth.py", line 280, in is_group_member result = self.ldap.search_s(group_dn, ldap.SCOPE_BASE, filterstr)
[snip]
UnicodeEncodeError: 'ascii' codec can't encode character u'\xfc' in position 26: ordinal not in range(128)
This actually looks like the same kind of encoding problem while verifying your group memberships.
Unicode is hard *sigh*.
I posted this as https://bugs.launchpad.net/nav/+bug/1301794 and will be pushing a patch within a few minutes. Attempting, for once, due diligence, I also wrote a regression test for the problem :)
Hi,
the fix works for us and the group gets now verified and checked just fine for members with NON-ASCII Characters in their name.
Thanks again, Mischa
On Thu, 3 Apr 2014 16:23:03 +0000 Mischa Diehm mischa.diehm@unibas.ch wrote:
the fix works for us and the group gets now verified and checked just fine for members with NON-ASCII Characters in their name.
That's great! Thanks for reporting back.
-
Mischa Diehm -
Morten Brekkevold -
Sjøholt Steinar Otto