External (ldap) group autorization problem

Hello there,
I have problem adding permission to create events in categories to external groups.

  1. I added my ldap directory to indico as described in the manual. Users can successfully login with ldap credentials.
  2. On the ldap server, I created a group “myorg” and added all users to it.
  3. On indico administraation section I search for the “myorg” group, however it lists only users which logged in into indico at least once (maybe, that’s right)
  4. I added permission to group “myorg” to create events in some categories, but the users from that group still have no rights to create any events.
  5. In indico, I created goup “staff”, and added some users to it, then added the same as in (4) permissions to the “staff” group, and the corresponding users from the local group can add events.

Can I give permission to create events to members of external group in some way? Or maybe I did something wrong?

Thanks in advance,
Vasyl

LDAP group membership checks are cached for 30 minutes, so if the user did anything where his group membership was checked then it may take up to 30 minutes for the LDAP update to show up. I recommend you to check the group member list (which you already found) if the user is shown there. And yes, this page only shows people who have an Indico account.

Also, if you are using openldap, make sure that the memberOf attribute is enabled - see https://docs.getindico.io/en/latest/config/auth/ for details.

Thank you for your reply.
Yes, the user is in the list of group members.
Yes, I use openldap and have memberOf enabled, and all users have this attribute set (checked with ldapsearch)

No more ideas? Still in problem.

Clean install of the latest 2.2.3 on my laptop . The same problem: members of external group cannot add events, members of local group can.
My config:

# General settings
SQLALCHEMY_DATABASE_URI = 'postgresql:///indico'
SECRET_KEY = 'XXXXX'
BASE_URL = 'https://localhost.localdomain'
CELERY_BROKER = 'redis://127.0.0.1:6379/0'
REDIS_CACHE_URL = 'redis://127.0.0.1:6379/1'
CACHE_BACKEND = 'redis'
DEFAULT_TIMEZONE = 'Europe/Kiev'
DEFAULT_LOCALE = 'en_GB'
ENABLE_ROOMBOOKING = True
CACHE_DIR = '/opt/indico/cache'
TEMP_DIR = '/opt/indico/tmp'
LOG_DIR = '/opt/indico/log'
STORAGE_BACKENDS = {'default': 'fs:/opt/indico/archive'}
ATTACHMENT_STORAGE = 'default'

# Email settings
SMTP_SERVER = ('XXXXX', 25)
SMTP_USE_TLS = True
SMTP_LOGIN = 'XXX'
SMTP_PASSWORD = 'XXXXX'
SUPPORT_EMAIL = 'XXXXXXX@XXXXXXX'
PUBLIC_SUPPORT_EMAIL = 'XXXXXXX@XXXXXXX'
NO_REPLY_EMAIL = 'noreply@XXXXXXXX'

STATIC_FILE_METHOD = 'xsendfile'


LOCAL_IDENTITIES = True
LOCAL_REGISTRATION = True
LOCAL_MODERATION = True

_ldap_config = {
    'uri': 'ldap://192.168.XXX.XXX',
    'starttls': True,
    'verify_cert': False,
    'bind_dn': 'XXXXXXXX',
    'bind_password': 'XXXXXXXX',
    'timeout': 30,
    'page_size': 1500,

    'uid': 'uid',
    'user_base': 'OU=People,DC=XXXXXXXXXXX',
    'user_filter': '(mail=*)',

    'gid': 'cn',
    'group_base': 'OU=Group,DC=XXXXXXXXXXX',
    'group_filter': '(objectClass=groupOfNames)',
    'member_of_attr': 'memberOf',
    'ad_group_style': False
}


AUTH_PROVIDERS = {
    'ldap': {
        'type': 'ldap',
        'title': 'XXXXX',
        'ldap': _ldap_config,
        'default': True
    }
}

IDENTITY_PROVIDERS = {
    'ldap': {
        'type': 'ldap',
        'title': 'XXXXX',
        'ldap': _ldap_config,
        'mapping': {
            'first_name': 'givenName',
            'last_name': 'sn',
            'email': 'mail',
            'affiliation': 'company',
            'phone': 'telephoneNumber'
        },
        'trusted_email': True,
        'default_group_provider': True,
        'synced_fields': {'first_name', 'last_name', 'affiliation', 'phone'}
    }
}

Can you test in indico shell what the membership check returns?

from indico.modules.groups import GroupProxy
g = GroupProxy('GROUPNAME', 'ldap')
u = User.get(USERID)

Then check u in g to see if the user is in the group as far as Indico is concerned. If he his, something is wrong with your ACL and LDAP actually works fine. So let’s assume it returns False

Other things to check: The identifiers the user has as far as group checks are concerned:

[x[1] for x in u.iter_identifiers(check_providers=True, providers={'ldap'})]

Then check the identifiers of the group members:

[x.identifier for x in g.group]

There should be one value that’s in both of these two lists.

In [1]: from indico.modules.groups import GroupProxy
In [2]: g = GroupProxy('imath', 'ldap')
In [3]: u = User.get(2)
In [4]: u in g
Out[4]: False
In [5]: [x[1] for x in u.iter_identifiers(check_providers=True, providers={'ldap'})]
Out[5]: [u'vo']
In [6]: [x.identifier for x in g.group]
Out[6]: 
[u'vo',
... all my users ...
]

My username is vo, if you ask, both for local and ldap accounts.

OK, so this means that the group membership check is not working for some reason.

Just to confirm, can you check 'vo' in g.group? If that also returns False, you might want to add some debug prints to the flask-multipass code that handles the actual membership check:

You can trigger the code there using the 'vo' in g.group check. Make sure to restart indico shell after changing the file or your changes won’t be taken into account.

OK, seems that I detected something…
user_data in line 128 has value {'memberOf': ['cn=imath,ou=group,dc=XXXX']}, but self_dn in line 137 is equal to cn=imath,ou=Group,dc=XXXX, the latter contains capital G.
I will fix that in my setup, but this looks like a bug, since LDAP must be case insensitive (according to openldap manual at least)

Thanks for your patience.
Vasyl.

Hi,

I have the same problem. The self.dn value has a capital letter in Group.
How did you solve de problem?
The only way I see to solve the problem is to set

self.dn = dn.lower()

in

I solved this as follows: in line 137 I replaced

            return self.dn in user_data.get(self.ldap_settings['member_of_attr'], [])

with

            return self.dn.lower() in user_data.get(self.ldap_settings['member_of_attr'], [])

Regards,
Vasyl

Thanks, both modifications seems to work.