LDAP Auth groups broken in 2.4.x and 2.5.x

Support
#1

Problem:
We are using LDAP auth and external groups sync. Everything works normal in 2.3.4 but after upgrading to 2.4.1 user jump out from his User Group on every login.
I tested this on 2.5.1 and behavior is the same. After downgrading to 2.3.4 it works normal.

When user loggs in, it gets permission denied. I manualy trigger external group sync and user apper in group, refresh the foreman and it works until user loggs in again.

Immidiatelly after login user jump out of the usergroup and get permission denied again.
Expected outcome:

Foreman and Proxy versions:
2.4.x
2.5.x

Foreman and Proxy plugin versions:

Distribution and version:
Debian: Buster

Other relevant data:

#2

Interesting, there was no change in the code since 1.22 that I could found. Do you see any additional information in the production.log? Can you enable debug log level, ldap and sql loggers and upload the log then?

#3

Hi Marek,
thx for your reaction. Yes I can provide some logs. I’m preparing testing instance so I can experiment on it.
I’ll attach logs in few days

#4

I’m not able to upload logs here , but I uploaded them on https://osiris.pod.cvut.cz/logs/production-debug.log

I enabled debug with ldap, app and sql loggers.

Log starts almost exatly in moment when user robert.vojcik trying to logg in. Auth is successful but then is user removed from UserGroup and gets permission denied page.

#5

Today I tested 2.3.5-1 version from debian packages, works fine.
I will try to look at this deeply later on, maybe I found where it happens.

I will also test it on freshly seeded database (meybe there was some problem in migration between versions)

#6

Sorry it took me a while, I went through the logs and dont see anything wrong. The only things that’s weird is the following SQL queries

2021-07-27T08:44:02 [D|sql|0c135b27]    (44.6ms)  SELECT "external_usergroups"."usergroup_id" FROM "external_usergroups" WHERE "external_usergroups"."auth_source_id" = $1 AND 1=0  [["auth_source_id", 4]]
2021-07-27T08:44:02 [D|sql|0c135b27]   Usergroup Load (15.7ms)  SELECT "usergroups".* FROM "usergroups" WHERE 1=0 ORDER BY usergroups.name

these are the queries we use to load existing user groups to find out if some should be added or removed. The SQL contains 1=0 condition which is typically added if some permission check or taxonomy (org/loc) check does not grant access.

Can you check you have correctly defined external usergroup mappings for the user’s usergroup? Can you double check user’s org/loc assignment and whether the AuthSource is also linked to the correct org/loc?

#7

Thx for your reply.
So far I didn’t see wrong Org/Loc assignment. I checked Users, Auth Sources.

Thanks for pointing me where to look, I’ll do some tests today and try to play with this little bit. Meybe I find something usefull.

#8

I found this strange SQL in logs:

2021-07-27T08:44:01 [D|sql|0c135b27]   Usergroup Load (23.2ms)  SELECT "usergroups".* FROM "usergroups" WHERE "usergroups"."name" = $1 ORDER BY usergroups.name  [["name", "robert.vojcik"]]

Acording to table and SQL query it trying to lookg for Group name, but instead of group name Egineers it puts there my login.

#9

And this

2021-07-27T08:44:02 [D|sql|0c135b27]    (74.3ms)  SELECT "usergroups"."id" FROM "usergroups" INNER JOIN "usergroup_members" ON "usergroups"."id" = "usergroup_members"."usergroup_id" WHERE "usergroup_members"."member_id" = $1 AND "usergroup_members"."member_type" = $2 AND "usergroups"."id" IN (SELECT "external_usergroups"."usergroup_id" FROM "external_usergroups" WHERE "external_usergroups"."auth_source_id" = $3) ORDER BY usergroups.name  [["member_id", 34], ["member_type", "User"], ["auth_source_id", 4]]
# Here I get correct usergroup id 3
# On the next log line there is 1=0 
2021-07-27T08:44:02 [D|sql|0c135b27]    (44.6ms)  SELECT "external_usergroups"."usergroup_id" FROM "external_usergroups" WHERE "external_usergroups"."auth_source_id" = $1 AND 1=0  [["auth_source_id", 4]]
#10

That is indeed suspicious but turned out to be valid.

This is where the whole sync logic lives foreman/auth_source_ldap.rb at 91c28da70a7bc5a96162ff2614eb1406ef0313ac · theforeman/foreman · GitHub but this SQL query is performed earlier. It is caused by regular user update foreman/user.rb at 91c28da70a7bc5a96162ff2614eb1406ef0313ac · theforeman/foreman · GitHub and that’s due to the validation that the login is different from user groups names foreman/user.rb at 91c28da70a7bc5a96162ff2614eb1406ef0313ac · theforeman/foreman · GitHub. So in other words, that suspicious SQL so in fact correct and expected.

It would be interesting to see what you’d get from LDAP when you perform the same ldap search you see in the logs. Sadly, we don’t have logging of the response in there to tell, what Foreman got as a list of user groups.

#11

I look at this little bit deeper, found partial workaround with disabling Usergroup Sync in LDAP Auth source.
Propably something changed between version on Usergroup Sync on login.

This partial workaround allow me to upgrade production to latest version.

We try to locate the problematic code in the source

#12

OK, we debugged the queries and filter and problem was at the begening. We had wrond objectClass in LDAP.
We used groupOfNames instead of PosixGroup which lead to partial function of the LDAP auth. Syncing groups works (from cron or refresh button) but dynamic refresh on login didn’t (because there is different LDAP query using memberUid which is possix attribute).

We changed LDAP group to posixGroup (which is in fact also in Foreman documentation) and it looks like everything works now.

For others with simmiliard problem, check LDAP group, it has to be posixGroup with memberUid attributes containing only login (uid) part of the user.

@Marek_Hulan thanks a lot for your time and consult

#13

Well, I guess that depends on the server type you have configured. We have a freeipa server and the freeipa server uses groupofnames just fine… It should probably be clarified in the documentation…

1 Like