Unexpected behavior for me

[Andrea De Marco]

Hi everybody.

I need a clarification on the use of AUTH_LDAP_FIND_GROUP_PERMS.
Quoting the docs: "This means that if AUTH_LDAP_FIND_GROUP_PERMS is
True, we must have access to the LDAP directory through
AUTH_LDAP_BIND_DN and AUTH_LDAP_BIND_PASSWORD".

Just to know what we talk about, this is my "djLdap" settings:

import ldap
from django_auth_ldap.config import LDAPSearch, NestedGroupOfNamesType
AUTH_LDAP_SERVER_URI = "ldaps://ldap.dadanoc.com"
AUTH_LDAP_BIND_DN = "uid=apachebind,ou=people,ou=acl,dc=dada,dc=net"
AUTH_LDAP_BIND_PASSWORD = "XXXXXXXXXXXXXXXXX"
AUTH_LDAP_USER_SEARCH = LDAPSearch("ou=people,dc=dada,dc=net",
ldap.SCOPE_SUBTREE, "(uid=%(user)s)")
AUTH_LDAP_GLOBAL_OPTIONS = {
ldap.OPT_X_TLS_REQUIRE_CERT: False,
}
AUTH_LDAP_USER_ATTR_MAP = {
"first_name" : "givenName",
"last_name" : "sn",
"email" : "mail"
}
AUTH_LDAP_ALWAYS_UPDATE_USER = True
AUTH_LDAP_GROUP_SEARCH =
LDAPSearch("ou=groups,ou=djLogic,ou=acl,dc=dada,dc=net",
ldap.SCOPE_SUBTREE)
AUTH_LDAP_GROUP_TYPE = NestedGroupOfNamesType()
AUTH_LDAP_REQUIRE_GROUP =
"cn=active,ou=groups,ou=djLogic,ou=acl,dc=dada,dc=net"
AUTH_LDAP_USER_FLAGS_BY_GROUP = {
"is_active" :
"cn=active,ou=groups,ou=djLogic,ou=acl,dc=dada,dc=net",
"is_staff" :
"cn=staff,ou=groups,ou=djLogic,ou=acl,dc=dada,dc=net",
"is_superuser" :
"cn=superuser,ou=groups,ou=djLogic,ou=acl,dc=dada,dc=net"
}
AUTH_LDAP_FIND_GROUP_PERMS = True

And when i try to log in:

search_s('ou=people,dc=dada,dc=net', 2, '(uid=ademarco)') returned 1
objects: uid=ademarco,ou=people,dc=dada,dc=net
search_s('ou=groups,ou=djLogic,ou=acl,dc=dada,dc=net', 2,
'(&(objectClass=*)(|(member=uid=ademarco,ou=people,dc=dada,dc=net)))')
returned 0 objects:
uid=ademarco,ou=people,dc=dada,dc=net is not a member of
cn=active,ou=groups,ou=djLogic,ou=acl,dc=dada,dc=net

Talking to my LDAP Sys Admin and lookin in ldap log we were able to
see this flow:

1) Bind with AUTH_LDAP_BIND_DN
2) Search of uid=ademarco in ou=people,dc=dada,dc=net
3) Bind with uid=ademarco,ou=people,dc=dada,dc=net
4) Search of member=uid=ademarco,ou=people,dc=dada,dc=net in
ou=groups,ou=djLogic,ou=acl,dc=dada,dc=net

But in our organization "human" users can't perform ldap searches so
at point 4 i got "0 object" and compare_s obviously fails.

Something wrong in my configuration?

For now i patched it inserting
self._ldap_user._bind()
inside _LDAPUserGroups.is_member_of() to rebind with AUTH_LDAP_BIND_DN
when i need a group search.

Any suggestion? :)

Thank you so much for your time.
I hope to read something :)

[Peter Sagerson]

Hi Andrea,

Technically, you're seeing the expected behavior, although I think it's reasonable to say that it's a bug or at least a misfeature. At present, the backend doesn't make any guarantee as to whether we're bound with the default credentials or the user's credentials when we perform operations. In practice, we'll tend to be bound as the user during the request that includes authentication and as the default during subsequent requests. I suppose it's a good idea to make this stricter and more predictable (at the minor cost of some additional LDAP traffic).

I think the right fix for this is to set self._connection_bound=False after binding as the user. This will force us to re-bind with the default credentials the next time we need a connection.

I've attached an sdist with this change. If this looks good to you, I'll push an update. Thanks for the report and sorry for the trouble.

[Andrea De Marco]

Hi Peter,

thank you so much for your celerity :)

Your patch is perfect!

Just to know how build my package to deploy: When can i find 1.0.7 in pypy? For now i put new release in local path!

Another little documentation issue: to solve duplicate rows in logging system i wrapped your advice in settings.py in this way:

if not hasattr(logging, "set_up_done"):

    logging.set_up_done=False

def setup_logger():

    if logging.set_up_done:

        return

    logger = logging.getLogger('django_auth_ldap')

    logger.addHandler(logging.StreamHandler())

    logger.setLevel(logging.DEBUG)

    logging.set_up_done=True

setup_logger()

[Peter Sagerson]

It's up now.

That's a good tip on the logging. I've seen talk on the Django developer list about some kind of run-once-at-init hook, but I'm not sure if anyone's done that yet. Hopefully there will be a good solution at some point.

[Jeff Schroeder]

If you've never seen or used django-sentry, you really need to. There
isn't anything remotely close. I've got 1 site / project running only
the sentry server and then several projects on different servers (with
the sentry.client app in INSTALLED_APPS) pointing to it. I've not had
any tracebacks since getting it working to begin with, but you should
really check it out.

Here is a good example of sentry in use: http://vimeo.com/15235999

--
Jeff Schroeder

Don't drink and derive, alcohol and analysis don't mix.
http://www.digitalprognosis.com

[Di majo]

MT103/202 DIRECT WIRE TRANSFER
PAYPAL TRANSFER
CASHAPP TRANSFER
ZELLE TRANSFER
LOAN DEAL
TRANSFER WISE
WESTERN UNION TRANSFER
BITCOIN FLASHING
BANK ACCOUNT LOADING/FLASHING
IBAN TO IBAN TRANSFER
MONEYGRAM TRANSFER
IPIP/DTC
SLBC PROVIDER
CREDIT CARD TOP UP
DUMPS/ PINS
SEPA TRANSFER
WIRE TRANSFER
BITCOIN TOP UP
GLOBALPAY INC US
SKRILL USA
UNIONPAY RECEIVER

Thanks.


NOTE; ONLY SERIOUS / RELIABLE RECEIVERS CAN CONTACT.

DM ME ON WHATSAPP
+44 7529 555638