znuny / Znuny

Znuny/Znuny LTS is a fork of the ((OTRS)) Community Edition, one of the most flexible web-based ticketing systems used for Customer Service, Help Desk, IT Service Management.
https://www.znuny.org
GNU General Public License v3.0
335 stars 82 forks source link

No tickets are visible #461

Closed schnudd31do3 closed 11 months ago

schnudd31do3 commented 12 months ago

Environment

Expected behaviour

All my tickets should be shown in any order (e. g. sorted by open, queue, reminder, ..)

Actual behaviour

  1. No tickets are shown (amount of 0)
  2. Some agents have lost their role-permissions. Changing this agents-to-roles are not really stored. After log out & login the configuration is still blank.

How to reproduce

  1. I reverted back from 7.0.8 to 7.0.7: Errors are still there (see above)
  2. I reverted back from 7.0.7 to 7.0.6: After restoring the role-permissions, all is fine again.

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

hanneshal commented 12 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?

schnudd31do3 commented 12 months ago

Yes, we have LDAP Sync in use. How should I modify my config?

hanneshal commented 12 months ago

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

schnudd31do3 commented 12 months ago

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.

hanneshal commented 12 months ago

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.

schnudd31do3 commented 12 months ago

I will try it.

schnudd31do3 commented 12 months ago

Can you please help me where to adjust this setting?

hanneshal commented 12 months ago

Hi,

the log level can be modified in the sysconfig: MinimumLogLevel

schnudd31do3 commented 12 months ago

Strange. Even if I can login, the log shows that my password was wrong. It seems to me to be contradictory. image

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.

hanneshal commented 12 months ago

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.

  1. You login
  2. DB is checked first ->Wrong PW
  3. LDAP Auth is next -> Auth OK

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.

schnudd31do3 commented 12 months ago

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'} = {

DB -> LDAP

    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)

rkaldung commented 12 months ago

@schnudd31do3 I will try to verify this and get back to you with a fix if needed.

schnudd31do3 commented 12 months ago

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).

hanneshal commented 12 months ago

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.

schnudd31do3 commented 12 months ago

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
hanneshal commented 12 months ago

@schnudd31do3 I'm sorry, but what should us tell this? I maybe missed something.

schnudd31do3 commented 12 months ago

I tought, that the log perhaps could help to clearify what was going wrong during LDAP autentication.

rkaldung commented 12 months ago

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.

hanneshal commented 12 months ago

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.

schnudd31do3 commented 12 months ago

@hanneshal :Thanks for your friendly explanation.

schnudd31do3 commented 11 months ago

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.

rkaldung commented 11 months ago

Fixed with cd5110a64e2d70a55a8497e3ff068bd4a65150b5 for Znuny 7 and cd5110a64e2d70a55a8497e3ff068bd4a65150b5 for Znuny LTS 6.5