Icingaweb2: LDAP Group Membership broken in 2.5.1

[marcofl]

LDAP users do not belong to LDAP groups after upgrading to 2.5.1 anymore and therefore will have no permissions in icingaweb2 at all.

Expected Behavior

Users are assigned to the LDAP groups as it was in 2.5.0

Current Behavior

LDAP groups are not assigned to users anymore.

Steps to Reproduce (for bugs)

1. have similar LDAP config to this:

roles.ini

[Administrators]
groups = "group-Admin"
permissions = "*"

groups.ini

[ldap]
backend = "ldap"
base_dn = "DC=corp,DC=ADS,DC=test,DC=ch"
group_class = "group"
group_filter = "&(sAMAccountName=group-*)"
group_member_attribute = "member"
group_name_attribute = "sAMAccountName"
resource = "ldap"
user_backend = "ldap"
user_base_dn = "DC=corp,DC=ADS,DC=test,DC=ch"
user_class = "user"
user_name_attribute = "userPrincipalName"

authentication.ini

[ldap]
backend = "ldap"
base_dn = "DC=corp,DC=ADS,DC=test,DC=ch"
filter = "(&(objectClass=person)(objectClass=user)(|(memberOf=CN=group-Viewer,OU=Distribution,OU=Groups,OU=myunit,DC=corp,DC=ADS,DC=test,DC=ch)(memberOf=CN=group-Benutzer,OU=Distribution,OU=Groups,OU=myunit,DC=corp,DC=ADS,DC=test,DC=ch)(memberOf=CN=group-Admin,OU=Distribution,OU=Groups,OU=myunit,DC=corp,DC=ADS,DC=test,DC=ch)))"
resource = "ldap"
user_class = "user"
user_name_attribute = "userPrincipalName"

1. login with an admin account (non ldap user for example)
2. check the group memberships of a LDAP user, it will be empty
3. downgrade to 2.5.0 icingaweb2
4. login again
5. check the group memberships of a LDAP user, it will display correct ldap groups again

Also adding my ldap user name to the role works around the issue:

[Administrators]
groups = "group-Admin"
users = "[email protected]"
permissions = "*"

Context

Users are still able to login but will have no permissions due to the missing group membership and permissions which are based on those groups

Your Environment

• Icinga Web 2 version and modules (System - About): 2.5.1
• Version used (icinga2 --version): r2.8.1-1
• Operating System and version: Ubuntu Xenial 16.04
• Enabled features (icinga2 feature list): not relevant
• Config validation (icinga2 daemon -C): not relevant

[marcofl]

I found out, that this https://github.com/Icinga/icingaweb2/pull/3258/files actually is the cause for ldap groups no longer working (at least for my use case). When I remove those 3 lines code, everything works as it was in 2.5.0

Unfortunately I was not able figure out how to configure this domain-aware authentication, as I'm using only one ldap backend anyway.

[marcofl]

In our case we use user_name_attribute = "userPrincipalName" where userPrincipalName is something like <sirname>.<lastname>@<randomdomain>.<tld> so I'm not able to set a domain for a backend or group. I could not find out how to tell the group backend not to care about the domain in the username at all.

Also https://github.com/Icinga/icingaweb2/blob/master/doc/05-Authentication.md says

Enabling domain-awareness ...

I did not enable this and I cannot find the way to disable it.

the problem in the change linked above therefor ist, that:

• user has domain (as we use email addresses for login)
• backend has no domain set (because there is no way to know the domain for 1000+ random email addresses and create 100 backends)
• this gives empty group relationship
• therefore no permissions in icingaweb 2

IMHO there should be some global / per backend parameter to disable this behaviour at all. We cannot assume that there are more than one LDAP backends which are responsible for one domain each just because we use email addresses for login.

On solution could be to check if at least one backend has a domain configured and only then do this if ($user->hasDomain()) { return array(); }

[spaolo]

If you have a single ldap backend and you wish to mix mysql user with ldap user simply remove domain = 'ch' from ldap backend definition in authentication.ini
all users and group will be placed in the 'no domain' context

[spaolo]

Removing domain keword i'ts not enoug as i thougth.
For your situation i agree the optimal behavior would be having a global parameter to disable the "domain aware auth" feature and remove any special meaning for '@'.

[marcofl]

actually this domain="ch" was just me testing around. I don't set that at all (sorry for the confusion here). The user backend works as it should, when no domain is set anywhere but the https://github.com/Icinga/icingaweb2/pull/3258/ broke the groupbackend / group memberships.

so as 2.5.1 is completely unusable with LDAP groups for us, I manually reverted the change locally for us, means further updates will break it again if this does not get fixed until then. would be good to add this to the 2.5.x / 2.6.x roadmap I guess.

[spaolo]

I got a look to the code, default_domain gets always added if backend is ldap or msldap, i suppose that's why you hit the problem, "ldap user should belong to a domain but email logins don't belong to default domain because the @"
Placing an enable/disable flag for domain aware auth does not seem extremely complex i will try a patch in the next days.
Another way could be adding a 'domain_separator' parameter and set it to some other than @ this will let you place all 'email' domain users in a single 'ldap' default_domain regardless the '@', it should be much simple from the patching point of view but i'm scared the program logic will suffer.

[marcofl]

Another way could be adding a 'domain_separator' parameter and set it to some other than @ this will let you place all 'email' domain users in a single 'ldap' default_domain regardless the '@', it should be much simple from the patching point of view but i'm scared the program logic will suffer.

should work too, In my use-case I just need the full login email address (not split by separator) in user_name_attribute in ldap and then the group backend should not try to do some checks for domain awareness when assigning group memberships.

[cstegm]

I have the same requirements as @marcofl - i just need the full login provided by kerberos via apache.

[Al2Klimov]

Hello @marcofl and thank you for reporting!

we use email addresses for login

That's exactly the problem. The auth algos always split the username by @ into (localpart, domain). At the moment you shouldn't configure any domain-aware auth as that will (most likely) break your setup completely.

Best,
AK

[Al2Klimov]

Hello @marcofl,

Please could you

1. Set your user backend's domain to *
2. Revert your changes
3. Apply mine (#3331)
4. Test and tell the result

Best,
AK

[spaolo]

Please be patient to me @Al2Klimov,
I made a small test on #3331. domain=* solution seems working in an email-login environment and i hope @marcofl and @cstegm will confirm it.
Unfortunately 0a002f breaks non email users logging with full "user@authdomain" syntax (non default_domain users are forced to) on the ldap lookup.
I think adding a special case for '*' domain is needed while setting $username to complete the fix.
$username = $this->domain === '*' ? $user->getUsername() : $username = $user->getLocalUsername(); seems working fine for both mail and non mail cases.

[Al2Klimov]

Hello @spaolo and thank you for testing!

Unfortunately your suggestion wouldn't change anything in your case as getUsername() yields the same as getLocalUsername() for non-domain users.
Please could you test adding another user backend w/ the same config, but no domain at all, and a group backend w/ the same config, but referencing the new user backend?

Best,
AK

[spaolo]

I've already tested it and seems working, below recap of tests i've done (with the ternary if included).

1 @marcofl use case (or closest i understood):

• no default_domain in config.ini
• single backend
• email logins in user_name_attribute
• email logins at login form
• domain=* in both auth and group ini
• groups="groupname", permission=* in role.ini
  result: ok
• user@anydomain login ok
• role assigned to user@anydomain

2 my use case:

• no default_domain
• two domain with leftpart only in user_name_attribute on ldap side
• one without domain= keyword in ini files and leftpart only in login form
• one with domain=example.com email login form login form
• groups="[email protected]", permission=* in role.ini
  result ok:
• collidinguser login ok
• [email protected] login ok
• role example.com assigned to [email protected]
• role example.com not assigned to collidinguser

3 my use + default domain case:

• default_domain=icinga.com
• two domain with leftpart only in user_name_attribute on ldap side
• one with domain=icinga.com and leftpart only in login form
• one with domain=example.com email login form login form
• groups="[email protected]", permission=* in role.ini
  result ok:
• collidinguser login ok.
• [email protected] login ok
• [email protected] login ok
• role assigned to [email protected]
• role not assigned to collidinguser
• role not assigned to [email protected]

Without last ternary if tests begin to fail at [email protected] login from the second case.
I would like to expand test cases but i can't do this by hand, have you any suggestion on how to automate them ?

[marcofl]

@Al2Klimov using changes from #3331 and setting domain="*" in authentication.ini for my user backend works.

btw. I would still prefer not having to specify domain="*" anywhere when I have only one non-domain-aware backend and then explicitly have to enable domain-awareness when I need that as the documentation says (even though the documentation does not state what enabling domain-awareness means / how to do it)

[marcofl]

@spaolo that's my use-case yes, besides that I don't see the point of setting domain=* in groups.ini / for the group backend

[spaolo]

@marcofl, the point is which domain belongs the group ?

[marcofl]

@spaolo I don't understand sorry. We don't use domains, there is no such thing as domains for us. email address = username (= user_name_attribute = userPrincipalName), it's one string in our use-case. if icingaweb splits that internally okay, but as long as there a not multiple backends responsible for different sets of users / groups, I don't see the point of checking against domains which I need to configure on the backend definition.

I see that there are more complex use-cases where you have users logging in with and without a domain as part of the username. And I really don't get the big picture here though, I'm fine with any solution as long as it's documented and works :-)

some side note: the problem for us was that this breaking change came in a patch level release from 2.5.0 to 2.5.1. I see that depending on the point of view, this could have been seen as a security fix though.

[Al2Klimov]

Hello @marcofl,

We apologize for that breaking change, we Icinga Web devs indeed didn't think about setups using eMail addresses as usernames (shame on us). We saw that feature just from the LDAP POV.
But especially your users actually have domains - as part of their eMail addresses. IMO counting them as domains or not depending on... whatever would be more overkill than my change.
Anyway thank you for testing.

Best,
AK

[marcofl]

@Al2Klimov yes, I see that now, no problem. Can you then reassign this ticket to a Icingaweb Dev or to you and maybe add a milestone so we have an idea what's the target release for a fix?

[Al2Klimov]

I'm afraid I shall not make decisions about that, but feel free to subscribe to #3331 so you'll get any updates immediately.

[marcofl]

sure, thank you @Al2Klimov and @spaolo for your help.

[dnsmichi]

@lippserd

Likely the same reports.

https://monitoring-portal.org/t/ldap-settings-for-userprincipalname-based-login-groups-management/930
https://monitoring-portal.org/t/ldap-authentication-role-assignement-does-work-for-users-but-not-for-ldap-groups/1241

[kajla]

+1
Any news?
Thanks!

[spaolo]

No, current solutions are rolling back to 2.5.0 or apply PR #3331 and set domain=* in both authentication.ini and groups.ini

[kajla]

Oh, it's bad news.
Okay, I will try it.

[kajla]

I downgraded to 2.5.0, but it's very-very slow and it isn't work too. :(
Look forward to the next stable release.

[kajla]

I applied PR #3331, but I can't login with it. We don't use domain to login. Group membership is still missing. :(

[cstegm]

PR #3331 works for me

[spaolo]

@kajla, remember PR #3331 domain=* in authentication.ini and groups.ini is required to have email logins to work.

[kajla]

@spaolo, I added domain=* string to these files, and I couldn't login anymore.
We don't use the email address to login, we login with simple username like this: john
Thank you!

[kajla]

I made a Python script for temporary fix. It will be automatically sync group members to groups.
sync_group_users.py.txt