Closed schnudd31do3 closed 11 months ago
Interesting. We did not perform any major changes to the roles / groups in this release.
But we did modify the LDAP Sync behaviour in 7.0.8.
2023-06-30 LDAP auth sync: Fixed permissions removed in LDAP not being reliably removed from users in Znuny.
Do you have LDAP role sync in place?
Yes, we have LDAP Sync in use. How should I modify my config?
Good question. We modified the Role / Group Sync to remove all roles a user is not in. The problem with the older version is, if a user is no longer in at least on LDAP Group, one role/ group is still assigned and will not be removed. This was a bug and is fixed with 7.0.8 and will be in the upcoming 6.5.
We updated the handling, so that if a LDAP user is not assigned to a role / group and RoleSync is in place, that the roles are removed.
So if you use Role Sync for you users, they have to be in the correct roles. DB Users should not be affected.
You can see which roles / sync is applied at the moment of the login, if the MiniumLoglevel (Sysconfig) is set to notice/info or debug.
Hope that helps
I am wondering. All agents are members of roles. All roles are linked to groups and all groups are linked to queues. But only a few agents were removed from the roles.
I have to make a test installation to debug, in order to not disturb our live system.
I would start with the logins. Set the minimum loglevel to notice or info and monitor the log. Directly after the login of the agents, you will get the infos from the log.
I will try it.
Can you please help me where to adjust this setting?
Hi,
the log level can be modified in the sysconfig: MinimumLogLevel
Strange. Even if I can login, the log shows that my password was wrong. It seems to me to be contradictory.
As I wrote with 7.0.8, ALL agents can login (via LDAP) but only a vew vew agents (including me) have no tickets in their view. Those agents dont have any permissions.
Hi,
this is not strange. Let me try explain (it would help to have your config here btw).
I would guess you have your LDAP Auth after your DB Auth.
$Self->{AuthModule} = 'Kernel::System::Auth::DB';
$Self->{AuthModule1} = 'Kernel::System::Auth::LDAP';
So LDAP is checked after DB.
Do you have an active role sync setting somewhere?
Like
$Self->{'AuthSyncModule::LDAP::UserSyncAttributeGroupsDefinition'}
or
$Self->{'AuthSyncModule::LDAP::UserSyncAttributeRolesDefinition'}
My guess, again - without you config it is hard to check, is that the permissions have been removed and they need to be restored. If it happens all the time, after you set the permissions again and you do not have a Role or Group sync from your LDAP, then this is a bug in 7.0.8. Downgrading will not restore the permissions, but the behaviour.
I can offer community support to help here, if needed.
I have $Self->{'Customer::AuthModule'} = 'Kernel::System::CustomerAuth::DB' $Self->{'Customer::AuthModule1'} = 'Kernel::System::CustomerAuth::LDAP'
I have nothing with ...UserSyncAttributeGroupsDefinition
I have $Self->{'AuthSyncModule'} = 'Kernel::System::Auth::Sync::LDAP' ... $Self->{'AuthSyncModule::LDAP::UserSyncMap'} = {
UserFirstname => 'givenName',
UserLastname => 'sn',
UserEmail => 'mail',
};
I have configured neither a role sync nor a group sync
"Downgrading will not restore the permissions, but the behaviour." This is what I observed. I had to rebuild the permissions after reverting to 7.0.6 (this is, what I wrote in my first post)
@schnudd31do3 I will try to verify this and get back to you with a fix if needed.
The "2. DB is checked first ->Wrong PW" is becauce the PW was not found in the DB. LDAP-user's PW are not stored in the DB because of not syncing. The DB is only used for storing credentials of none-LDAP-users (e. g. admin).
The "2. DB is checked first ->Wrong PW" is becauce the PW was not found in the DB. LDAP-user's PW are not stored in the DB because of not syncing. The DB is only used for storing credentials of none-LDAP-users (e. g. admin).
Correct, and as long as the order is DB->LDAP you will always get this info, because we can not know where a user is coming from / is stored. We always have to check all backends until the login is OK or the chain ends and we do not allow access.
I checked LDAP with "ldapsearch -x -H ldaps://xy.z/ -D [me]@XXXX.XX -W cn=user -d 9"
No errors detected, here is the STDOUT:
EDIT: REMOVED Log is not needed
@schnudd31do3 I'm sorry, but what should us tell this? I maybe missed something.
I tought, that the log perhaps could help to clearify what was going wrong during LDAP autentication.
I tought, that the log perhaps could help to clearify what was going wrong during LDAP autentication.
Who said that something is wrong with the authentication? You have a problem with authorization and this is what I currently verify.
I tought, that the log perhaps could help to clearify what was going wrong during LDAP autentication.
Thanks, but not needed. The problem is not the Auth itself, but (probably) a bug in the change we introduced in 7.0.8. As you wrote, you do not have a role sync in place. We need to take this into account. This is what @rkaldung is verifying at the moment.
We update the issue when we have an update on this.
@hanneshal :Thanks for your friendly explanation.
Today I updated to V 7.0.9. After that, my tickets remain in my view and my permissions remain unchanged.
I keep on observing.
Fixed with cd5110a64e2d70a55a8497e3ff068bd4a65150b5 for Znuny 7 and cd5110a64e2d70a55a8497e3ff068bd4a65150b5 for Znuny LTS 6.5
Environment
Expected behaviour
All my tickets should be shown in any order (e. g. sorted by open, queue, reminder, ..)
Actual behaviour
How to reproduce
Additional information
The logfiles in /opt/znuny/var/log/Deamon/[...ERR].log are there, but they are all empty. The znuny.log.2023-07 does not show any regarding errors.
Screenshots