Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

can't match LDAP/AD group and assign permissions accordingly #1907

Open
itheodoridis opened this issue Jan 8, 2024 · 1 comment
Open

can't match LDAP/AD group and assign permissions accordingly #1907

itheodoridis opened this issue Jan 8, 2024 · 1 comment

Comments

@itheodoridis
Copy link

itheodoridis commented Jan 8, 2024

Issue Summary
I am deploying Alerta on Docker with Docker Compose, using LDAP against MS Active Directory for authentication. LDAP authentication works, looking up groups where the user is a member works, matching groups against permission/roles doesn't work.

Environment

  • OS: Linux

  • API version: Latest (Not sure about number)

  • Deployment: Docker with Docker Compose on Vmware Ubuntu Server VM

  • For self-hosted, WSGI environment: nginx/uwsgi

  • Database: Postgres

  • Server config:
    Auth enabled? Yes
    Auth provider? LDAP (with MS AD)
    Customer views? No

  • web UI version: Not sure/Latest

  • CLI version: Not sure/Latest

To Reproduce
Steps to reproduce the behavior:

  1. Define an LDAP config in the alertad.conf file as attached below (sanitized)
  2. Assign roles to specific groups using CN notation, specifying at least one as read (only)
  3. Attempt to authenticate using AD credentials with a user belonging to a group assigned the read role.
  4. See error in the web ui (fail to login with 'no customer lookup' if customer views are set to 'false'/login with different permissions if customer views are set to 'true' and user matches with customer)

Expected behavior
The user should be able to login with matching permissions/scope for the group he is a member of (in this case just read).

Screenshots
Not applicable

Additional context

DATABASE_URL='postgres://postgres:postgres@db:5432/monitoring'
AUTH_REQUIRED='True'
CUSTOMER_VIEWS='True'

ALERT_TIMEOUT=120
HEARTBEAT_TIMEOUT=30
LOG_LEVEL='INFO'
LOG_HANDLERS=['console']
PLUGINS=['remote_ip','prometheus','msteams','reject','heartbeat','blackout','normalise','enhance']
#PLUGINS=['remote_ip','prometheus','msteams','reject','heartbeat','blackout','normalise','enhance']


SECRET = "blablablabla"

DEBUG = True

ADMIN_PASSWORD='adminpassword'
ADMIN_KEY='myownsecretkey'
ADMIN_USERS = ['ITheodoridis@domain.com']
ADMIN_KEY_MAXAGE=500

SIGNUP_ENABLED = True
AUTH_PROVIDER = 'ldap'
ALLOWED_EMAIL_DOMAINS = ['domain.com']
LDAP_URL = 'ldaps://msadserver-ldap.domain.com:636'  
LDAP_DOMAINS = {'domain.com': '(&(sAMAccountName=%s)(objectClass=person)),OU=Personnel,OU=Company Users,DC=domain,DC=com'}
LDAP_DOMAINS_BASEDN = {'domain.com': 'DC=domain,DC=com'}
LDAP_DOMAINS_GROUP = {'domain.com': '(&(member={userdn})(objectClass=group))'}

LDAP_BASEDN = 'DC=domain,DC=com'

LDAP_BIND_USERNAME = 'CN=ldapuser,OU=Special Purpose,OU=Company Users,DC=domain,DC=com'
LDAP_BIND_PASSWORD = 'lalalalala'

LDAP_USER_BASEDN = 'OU=Personnel,OU=Company Users,DC=domain,DC=com'
LDAP_USER_FILTER = '(&(sAMAccountName={username})(objectClass=person))'
LDAP_USER_NAME_ATTR = 'sAMAccountName'
LDAP_USER_EMAIL_ATTR = 'mail'

LDAP_GROUP_BASEDN = 'OU=Groups,OU=Company Users,DC=domain,DC=com'
LDAP_GROUP_FILTER = '(&(member={userdn})(objectClass=group))'
LDAP_GROUP_NAME_ATTR = 'dn'
LDAP_USER_MEMBEROF_ATTR = 'memberOf'

LDAP_TIMEOUT = 10
LDAP_ALLOWED_LDAP_GROUPS = [
        'CN=group1,OU=Groups,OU=Company Users,DC=domain,DC=com',
        'CN=group2,OU=Groups,OU=Company Users,DC=domain,DC=com',
        'CN=group3,OU=Groups,OU=Company Users,DC=domain,DC=com'
        ]

LDAP_DEFAULT_DOMAIN = 'domain.com'
LDAP_ALLOW_SELF_SIGNED_CERT='True'


LDAP_CONFIG = {
        "OPT_REFERRALS": 0,
        "OPT_PROTOCOL_VERSION": 3,
        "OPT_DEBUG_LEVEL": -1
}
@autotitan
Copy link

@itheodoridis I was running into the exact same issue and after banging my head against the wall for the last few days I finally found the solution for our particular problem buried in issue #1515.

Root cause: Documentation is missing for how to actually set up proper LDAP RBAC. Thus, this is a bug with documentation - not the app.

Resolution: Here is the direct link to the true fix in the comment (it is the bottom comment - #1515 (comment)

TL;DR:

  • you need to create at least 2 LDAP group inside your LDAP system (I use FreeIPA)
  • add your CN's LDAP group inside the alertad.conf file
  • create the permission in the Alerta Web UI with the name of the permission as your group's CN.

Again... check the bug comment for the details.

Side note: Shoutout to Satterly for creating and open sourcing Alerta. This utililty has been a godsend. So I just want to send my appreciation.
In addition to just saying thank you I will be contributing to the LDAP documentation (https://docs.alerta.io/authentication.html#ldap-auth) as it definitely needs some additions and some things need more clarity. Satterly has provided their contribution. Time for me to give mine back to the community. Expect to see some PRs on the docs soon.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants