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

[dev.icinga.com #10659] LDAP group members are shown with their DN and membership registration does not work #2146

Closed
icinga-migration opened this issue Nov 17, 2015 · 9 comments
Labels
area/authentication Affects user authentication or authorization bug Something isn't working
Milestone

Comments

@icinga-migration
Copy link

This issue has been migrated from Redmine: https://dev.icinga.com/issues/10659

Created by greatexpectations on 2015-11-17 10:42:06 +00:00

Assignee: jmeyer
Status: Resolved (closed on 2015-11-24 08:46:01 +00:00)
Target Version: 2.1.1
Last Update: 2016-06-16 13:19:06 +00:00 (in Redmine)


Hi,

I have upgraded to Icingaweb2 2.1.0 on CentOS 7 using the Icinga Yum repository. Now we find that our ActiveDirectory authorization scheme which is based on group membership no longer works.

That is, users can still log in using their AD login and password (so user-based authentication works), but all they get is an empty dashboard with no options at all. We have defined roles based on AD group membership, and it seems that the association between users and groups can no longer be established with the last update.

AD groups are still listed in the UI (Configuration -> Authorization -> User Groups), but members are shown using their distinguished name (e.g. "CN=Full Name,OU=Users,DC=foo,DC=bar" instead of just "fname"). When inspecting AD users, no group memberships are shown.

Kind regards

Changesets

2015-11-24 08:45:49 +00:00 by jmeyer 916c417

LdapUserGroupBackend: Avoid inspecting a group with no members

fixes #10659
@icinga-migration
Copy link
Author

Updated by elippmann on 2015-11-17 11:49:39 +00:00

  • Status changed from New to Feedback
  • Assigned to set to greatexpectations

Hi,

Could you please share your configuration for both the user and group backend?

Best,
Eric

@icinga-migration
Copy link
Author

Updated by greatexpectations on 2015-11-17 11:56:48 +00:00

Hi Eric,

sure, however we were just using the default settings.

/etc/icingaweb2/authentication.ini:

[foo.bar Users]
resource = "icingaweb_ldap"
filter = "!(objectClass=computer)"
backend = "msldap"

/etc/icingaweb2/groups.ini:

[foo.bar Groups]
resource = "icingaweb_ldap"
user_backend = "foo.bar Users"
backend = "msldap"

Excerpt from /etc/icingaweb2/resources.ini:

...
[icingaweb_ldap]
type = "ldap"
hostname = "foo.bar"
port = "389"
encryption = "none"
root_dn = "DC=foo,DC=bar"
bind_dn = "icinga-bind"
bind_pw = "password"
...

Regards

@icinga-migration
Copy link
Author

Updated by Foxeronie on 2015-11-17 19:51:07 +00:00

I have the same problem. It worked until this commit

# git reset --hard cfb26e22b35c8e19767233a4db3a22864453a483
HEAD is now at cfb26e2 LdapUserGroupBackend: Dynamically verify member attribute ambiguity

Also my settings:

resources.ini

[ldap_domain]
type = "ldap"
hostname = "it-ldap-slave.domain.de"
port = "1636"
encryption = "ldaps"
root_dn = "o=domain,c=de"
bind_dn = "uid=ldapuser,ou=people,ou=rgy,o=domain,c=de"
bind_pw = "ldappasswd"
reqcert = "1"

authentication.ini

[ldap_user_master03]
resource = "ldap_domain"
user_class = "inetOrgPerson"
filter = "(|(isMemberOf=cn=it,ou=group,ou=rgy,o=domain,c=de)(uid=notituser))"
user_name_attribute = "uid"
backend = "ldap"
base_dn = "o=DOMAIN,c=DE"

groups.ini

[ldap_group_master03]
resource = "ldap_domain"
user_backend = "ldap_user_master03"
group_name_attribute = "cn"
base_dn = "ou=group,ou=rgy,o=domain,c=de"
backend = "ldap"
group_member_attribute = "uniqueMember"
group_class = "groupOfUniqueNames"

@icinga-migration
Copy link
Author

Updated by jmeyer on 2015-11-23 12:18:51 +00:00

Hi all,

we need more details about your environment to solve this appropriately, as it's working in our testing environment with ActiveDirectory and OpenLDAP.
Since this will probably contain some confidential information you may want to email me the following:

  • Your full and non-anonymous base and root DN
  • The output of the command shown in the debug log of Icinga Web 2 which is being emitted when opening the detail page of a group. (e.g. ldapsearch -P 3 -H "ldap[s]://<host>:<port>" -D "<bind_dn>" -w "<bind_pw>" -b "<group-dn>" -s "sub" -z 1 -l 0 -a "never" "(objectClass=<group_class>)" "<group_member_attribute>")

Best regards,
Johannes

@icinga-migration
Copy link
Author

Updated by jmeyer on 2015-11-24 08:43:41 +00:00

  • Subject changed from Icingaweb 2.1.0 breaks Active Directory authorization based on group membership to LDAP group members are shown with their DN and membership registration does not work
  • Status changed from Feedback to Assigned
  • Assigned to changed from greatexpectations to jmeyer
  • Target Version set to 273

@icinga-migration
Copy link
Author

Updated by jmeyer on 2015-11-24 08:46:01 +00:00

  • Status changed from Assigned to Resolved
  • Done % changed from 0 to 100

Applied in changeset 916c417.

@icinga-migration
Copy link
Author

Updated by elippmann on 2015-11-26 10:18:50 +00:00

  • Target Version changed from 273 to 2.1.1

@icinga-migration
Copy link
Author

Updated by jorfermo on 2015-12-09 09:33:06 +00:00

I'm having the same problem even after applying the patch.

AD users log in succesfully but the dashboard page shows: "Currently there is no dashlet available. Please contact the administrator."

EDIT: It was a problem on my config. All's fine now.

@icinga-migration
Copy link
Author

Updated by plarivee on 2016-06-16 13:19:06 +00:00

jorfermo wrote:

I'm having the same problem even after applying the patch.

AD users log in succesfully but the dashboard page shows: "Currently there is no dashlet available. Please contact the administrator."

EDIT: It was a problem on my config. All's fine now.

Can you elaborate on what was the problem in your config ?

@icinga-migration icinga-migration added bug Something isn't working area/authentication Affects user authentication or authorization labels Jan 17, 2017
@icinga-migration icinga-migration added this to the 2.1.1 milestone Jan 17, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/authentication Affects user authentication or authorization bug Something isn't working
Projects
None yet
Development

No branches or pull requests

1 participant