Ldap auth fails when using AUTH_LDAP_USER_FLAGS_BY_GROUP

[Bernhard Posselt]

Everything works perfectly so far but if i uncomment
AUTH_LDAP_USER_FLAGS_BY_GROUP (configuration below) my login fails. Im
a member of all 3 groups so I dont know what Im doing wrong


A screenshot of my LAM setup:
http://s1.directupload.net/file/d/2403/29ke9hdv_png.htm

My Configuration:

AUTH_LDAP_SERVER_URI = "ldap://ldap"
AUTH_LDAP_BIND_DN = "cn=Administrator,dc=olymp"
AUTH_LDAP_BIND_PASSWORD = "PASS"
AUTH_LDAP_USER_SEARCH = LDAPSearch("ou=users,dc=olymp",
ldap.SCOPE_SUBTREE, "(uid=%(user)s)")
AUTH_LDAP_USER_ATTR_MAP = {
"first_name": "givenName",
"last_name": "sn",
"email": "mail"
}


AUTH_LDAP_GROUP_SEARCH = LDAPSearch("ou=groups,dc=olymp",
ldap.SCOPE_SUBTREE, "(objectClass=groupOfNames)"
)
AUTH_LDAP_GROUP_TYPE = GroupOfNamesType(name_attr="cn")

AUTH_LDAP_USER_FLAGS_BY_GROUP = {
"is_active": "cn=people,ou=groups,dc=olymp",
"is_staff": "cn=hv,ou=groups,dc=olymp",
"is_superuser": "cn=administrators,ou=groups,dc=olymp"
}

AUTHENTICATION_BACKENDS = (
'django_auth_ldap.backend.LDAPBackend',
)

[Peter Sagerson]

I don't see anything obviously wrong. It's hard to say how accurately the configuration matches the server based on a screenshot. You can get a bit more information about what's going on if you install a logging handler.[1] Although it's apparent that it's not recognizing the user as belonging to at least one of the groups (probably people).

[1] http://packages.python.org/django-auth-ldap/#logging

[Bernhard Posselt]

Adding this to the settings.py doesnt change anything. Does it write
the logs anywhere else?

import logging

logger = logging.getLogger('django_auth_ldap')
logger.addHandler(logging.StreamHandler())
logger.setLevel(logging.DEBUG)

All the other groups arent recognized either. I can change the cn to
any other group and it doesnt work.

[Peter Sagerson]

That sample code installs a stream handler to stderr, so the location of the output depends on your deployment. I recommend running the development server to get the log messages on your console. If you're using Apache/mod_wsgi, I believe they'll end up in Apache's logs. settings.py is a reasonable place to put this, although you'll see duplicate messages without some additional trickery. It's just a quirk of Django's handling of settings.py.

[Bernhard Posselt]

Seems like a bug:
search_s('ou=users,dc=olymp', 2, '(uid=Posselt_Bernhard)') returned 1
objects: uid=Posselt_Bernhard,ou=Users,dc=olymp
search_s('ou=users,dc=olymp', 2, '(uid=Posselt_Bernhard)') returned 1
objects: uid=Posselt_Bernhard,ou=Users,dc=olymp
Populating Django user Posselt_Bernhard
Populating Django user Posselt_Bernhard
Caught LDAPError while authenticating Posselt_Bernhard:
NO_SUCH_ATTRIBUTE({'desc': 'No such attribute'},)
Caught LDAPError while authenticating Posselt_Bernhard:
NO_SUCH_ATTRIBUTE({'desc': 'No such attribute'},)

[Peter Sagerson]

(Moving the list to bcc)

Possibly. The source code contains no references to any 'desc' attribute. Off the top of my head, I wouldn't expect to see this error unless the missing attribute were being specifically requested. The circumstances under which this library will reference an individual attribute are few. The next step is of course to find the minimum configuration that reproduces this. AUTH_LDAP_USER_ATTR_MAP is the most likely culprit, as that's where most of the attribute references are.

[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