NAV does not follow LDAP referrals during authentication

[Galindro]

When I configure NAV to search my entire AD domain, it reports the attached error (error.log and error.pcap) and the user can't login.

But, if I change the config to use a specific OU as base DN, the user can login successful, as you can see in the attached files (ok.log and ok.pcap).

Morten, I've sent to you by mail the password of attached file.

[Morten Brekkevold (mbrekkevold)]

NAV doesn't handle referrals, see bug 1207737.

The attached logs contain only OpenLDAP debug logging, not NAV debug logging, so I can't say for sure what NAV is doing. You would have to make sure `/etc/nav/logging.conf` exists, and contains:

[levels]
nav.web.auth = DEBUG
nav.web.ldapauth = DEBUG

Also, would you please post your `webfront.conf`, stripped of passwords?

[Galindro (bruno-galindro)]

Sent apache's debug log to you by mail.

Here is my ldap config:

[ldap]
enabled = yes
server = xxxxx
port = 389
uid_attr = sAMAccountName
name_attr = givenName
basedn = dc=xxx,dc=xx
lookupmethod=search
manager=CN=xxx,OU=xxxx,OU=xxxx,DC=xxx,DC=xx
manager_password=pass
require_group = CN=xxxx,OU=xxx,OU=xxxx,OU=xxxx,OU=xxxx,DC=xxx,DC=xx
debug = yes

[Morten Brekkevold (mbrekkevold)]

I think the python-ldap FAQ, entry no. 12 explains quite well what is happening here: http://www.python-ldap.org/faq.shtml.

I'm looking into it further, but I'm not sure there's anything we can do except disable referral chasing in libldap.

[Morten Brekkevold (mbrekkevold)]

It appears that one solution may be to write code to automatically chase referrals using the same credentials as used on the originating server. The problem is that we have no practical way of testing this without our own referral-producing AD server, which we don't have.

[Galindro (bruno-galindro)]

It appears that one solution may be to write code to automatically chase referrals using the same credentials as used on the originating server.

Yes! This is exactly what I'm thinking too, based on pcap files sent. If you see, in the first communication, the correct bind user is sent to my AD DC. So, when it tells to NAV that exists 3 more DCs (referrals), NAV is trying to do a bind on these servers without the correct bind user. It seems that it sent a '<ROOT>' user to the referrals instead of the correct bind user.

You can send to me an updated code to do a simple test. What do you think?

[Morten Brekkevold (mbrekkevold)]

See the attached patch. The referral chasing part is completely untested and unverified, but I tested searching against a server that doesn't respond with referrals, and it seems ok.

[Galindro (bruno-galindro)]

For apply the patch, I've executed this command:

root@nav:~# patch /usr/share/pyshared/nav/web/ldapauth.py naive-untested-ldap-referral-chasing.patch
patching file /usr/share/pyshared/nav/web/ldapauth.py
Hunk #4 succeeded at 274 (offset -1 lines).

But an error was displayed in web browser:

Something went wrong
Something went wrong while processing your request. Please try again later.
If the problems persists, contact your system administrator and/or report a bug on NAV bugtracker.

I've sent to you by mail the apache's log.

[Morten Brekkevold (mbrekkevold)]

There are no errors in the file you sent me. The full error traceback was sent by e-mail to the address you configured as ADMIN_MAIL in `nav.conf`. Other than that, you can enable DJANGO_DEBUG in `nav.conf` and restart Apache to have full debug-level traceback displayed in the browser on a crash (but I don't recommend running in debug mode during normal production)

[Galindro (bruno-galindro)]

Morten, this is the Django's traceback:

Environment:

Request Method: POST
Request URL: https://xxx.xxx.ufsc.br/index/login/
Django Version: 1.2.3
Python Version: 2.6.6
Installed Applications:
['nav.django']
Installed Middleware:
('django.middleware.common.CommonMiddleware',
 'django.contrib.messages.middleware.MessageMiddleware')

Traceback:
File "/usr/lib/pymodules/python2.6/django/core/handlers/base.py" in get_response
  100. response = callback(request, *callback_args, **callback_kwargs)
File "/usr/lib/pymodules/python2.6/nav/web/webfront/views.py" in login
  91. return do_login(request)
File "/usr/lib/pymodules/python2.6/nav/web/webfront/views.py" in do_login
  114. account = auth.authenticate(username, password)
File "/usr/lib/pymodules/python2.6/nav/web/auth.py" in authenticate
  144. auth = ldapauth.authenticate(username, password)
File "/usr/lib/pymodules/python2.6/nav/web/ldapauth.py" in authenticate
  126. user.bind(password)
File "/usr/lib/pymodules/python2.6/nav/web/ldapauth.py" in bind
  177. user_dn = self.get_user_dn()
File "/usr/lib/pymodules/python2.6/nav/web/ldapauth.py" in get_user_dn
  197. self.user_dn = self.search_dn()
File "/usr/lib/pymodules/python2.6/nav/web/ldapauth.py" in search_dn
  221. ldap.SCOPE_SUBTREE, filter_)
File "/usr/lib/pymodules/python2.6/nav/web/ldapauth.py" in search_s
  293. if dn is None and value not in seen_referrals]

Exception Type: TypeError at /index/login/
Exception Value: unhashable type: 'list'

[Morten Brekkevold (mbrekkevold)]

Ok, the parsing of the search results was incorrect, an updated patch is attached.

[Galindro (bruno-galindro)]

Morten, that last patch (naive-untested-ldap-referral-chasing2.patch) solved the problem! Now NAV can parse LDAP referrals.

Thank you very much again!

[Galindro (bruno-galindro)]

Morten, sorry my mistake, but the authentication not works even after apply patch2.

Sent apache log to you by mail.

[Galindro (bruno-galindro)]

Morten, any return?

[Morten Brekkevold (mbrekkevold)]

Sorry, Bruno. Been a bit busy lately, especially with the upcoming NAV 3.15. I cannot say for sure when I will have time to look at this patch again, but hopefully before the end of September.

[Galindro (bruno-galindro)]

Don't worry. Tks!