-
Notifications
You must be signed in to change notification settings - Fork 177
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
New person accounts not being added to dynamic groups #2756
Comments
I can't reproduce:
Do you have more details to help here? |
Something weird about my experience with this issue is that the first user I created does appear in the dynamic groups, but none of the subsequent users do. I only ever used Kanidm 1.2.0, so I can't speak to whether this worked before/differently in prior versions. I don't know if you're familiar enough with NixOS to make sense of this but here's the commit where I set up Kanidm (so it shows all the relevant configuration). Here are some less NixOS-y pieces of information: Shell session demonstrating the problem$ kanidm group get idm_all_persons --name idm_admin
---
class: account_policy
class: builtin
class: dyngroup
class: group
class: object
class: system
credential_type_minimum: mfa
description: Builtin IDM dynamic group containing all persons.
dynmember: charles@kanidm.computer.surgery
name: idm_all_persons
spn: idm_all_persons@kanidm.computer.surgery
uuid: 00000000-0000-0000-0000-000000000035
$ echo "The above is already incorrect, there are more users than just me" > /dev/null
$ kanidm person create test-person "Test Person" --name idm_admin
Successfully created display_name="Test Person" username=test-person
$ kanidm group get idm_all_persons --name idm_admin
---
class: account_policy
class: builtin
class: dyngroup
class: group
class: object
class: system
credential_type_minimum: mfa
description: Builtin IDM dynamic group containing all persons.
dynmember: charles@kanidm.computer.surgery
name: idm_all_persons
spn: idm_all_persons@kanidm.computer.surgery
uuid: 00000000-0000-0000-0000-000000000035
$ echo "Note that test-person does not appear" > /dev/null
$ kanidm person delete test-person --name idm_admin
success - account delete for test-person: deleted
|
After messing about with it for way longer than I thought I'd have to, this appears to be an issue that arises if there's ever a change in the certificates being used. So probably anyone using Let's Encrypt certs is going to run into this within 90 days. Easiest way to reproduce in a test env is just to use Doesn't appear to matter if Kanidm is online or offline when the change occurs and it's apparently not limited to NixOS. I've been able to duplicate this problem running the official container via Podman as well (single volume persisting the db, certs, and config). |
That's... weird and doesn't make any sense - Kanidm doesn't monitor or auto-reload certificates, they're persisted in memory from startup. You'd somehow have to be killing it in a way that silently corrupts the database, which is also... strange. (for context, I've been running LE certs for years now and it works fine) |
Even if you could, every operation is 100% transactional, so a db corruption would mean sqlite corruption which I doubt. Anyway, please show the output of |
Here's the output for an affected account:
|
As discussed, please try image Collect the logs by:
Then post or email me the logs. You may prefer email so you don't have to redact anything. |
Are you also using any other third party tools from nix or other users in your setup? |
How are you creating the users? Because ... I can't reproduce it either... |
I'm a little bit floored that this isn't easily reproducible at this point and am heavily questioning my sanity because of that. From what I've seen after I stopped fixating on certs as a potential culprit and swapped over to running the container, the dynamic groups are breaking pretty immediately on restart. Alright... everything but the kitchen sink follows: Steps TakenAt this point I'm just focusing on getting the container working since it's the preferred deployment method and is slightly faster to totally destroy and redeploy repeatedly. For the sake of consistency, I basically just threw the evaluation quickstart guide from your docs into a script:
From there, the following actions are performed manually (throwaway usernames vary):
That produces these logs with the image specified: Additional ContextAs I've mentioned elsewhere, this is reproducible on three different machines using multiple methods of deployment. There are really only two factors that are consistent between them:
The following setups have all reliably exhibited this issue (all version 1.2.0):
The following setups DO NOT exhibit this issue:
|
For the record, we do believe you that it's a problem, and we really appreciate the time you're putting in to help us here. It's greatly appreciated. We're just as stumped as you that we haven't reproduced it yet. |
I have just reproduced locally. :) |
I did this
kanidm person create someuser someuser
I expected the following
New user would be automatically added to the dynamic groups
idm_all_accounts
andidm_all_persons
as was the case with previous versions.Kanidm version details
kanidm(d) version
: 1.2.0uname -a
): Linux 6.6.29 1-NixOS SMP PREEMPT_DYNAMIC Sat Apr 27 15:11:44 UTC 2024 x86_64 GNU/LinuxAny other comments
The text was updated successfully, but these errors were encountered: