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

No tickets are visible #461

Closed
schnudd31do3 opened this issue Jul 18, 2023 · 22 comments
Closed

No tickets are visible #461

schnudd31do3 opened this issue Jul 18, 2023 · 22 comments
Assignees

Comments

@schnudd31do3
Copy link

schnudd31do3 commented Jul 18, 2023

Environment

  • OS: Debian bookworm / 12
  • Browser: Chrome
  • Znuny version: 7.0.7 + 7.0.8

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 hanneshal self-assigned this Jul 18, 2023
@hanneshal
Copy link

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
Copy link
Author

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

@hanneshal
Copy link

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
Copy link
Author

schnudd31do3 commented Jul 19, 2023

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
Copy link

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
Copy link
Author

I will try it.

@schnudd31do3
Copy link
Author

Can you please help me where to adjust this setting?

@hanneshal
Copy link

Hi,

the log level can be modified in the sysconfig: MinimumLogLevel

@schnudd31do3
Copy link
Author

schnudd31do3 commented Jul 20, 2023

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
Copy link

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
Copy link
Author

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
Copy link
Contributor

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

@rkaldung rkaldung self-assigned this Jul 20, 2023
@schnudd31do3
Copy link
Author

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
Copy link

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
Copy link
Author

schnudd31do3 commented Jul 21, 2023

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
Copy link

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

@schnudd31do3
Copy link
Author

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

@rkaldung
Copy link
Contributor

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
Copy link

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
Copy link
Author

@hanneshal :Thanks for your friendly explanation.

@schnudd31do3
Copy link
Author

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants