Not sure if anyone is experiencing this or not and apologize if it's already answered, but I've created an FreeIPA account and with a random password using the command line (ipa user-add user1 --uid=6543 --random). I then, within the WebUI, have the admin account reset user1's password to something more human friendly. I then, as user1, attempt to log into the WebUI to set the final password. I provide the user1 username and the more human friendly password and I can't log in. I've created the user through the WebUI and reset the password and it works just like I want it to.
The reason I'm creating the accounts using the CLI is to migrate accounts from an old LDAP instance into FreeIPA via script. I want to then have an admin reset the users password so the user can then log in and set their final password in FreeIPA's WebUI.
Thoughts? Thank you!
On Чцв, 26 вер 2024, Kris C via FreeIPA-users wrote:
Not sure if anyone is experiencing this or not and apologize if it's already answered, but I've created an FreeIPA account and with a random password using the command line (ipa user-add user1 --uid=6543 --random). I then, within the WebUI, have the admin account reset user1's password to something more human friendly. I then, as user1, attempt to log into the WebUI to set the final password. I provide the user1 username and the more human friendly password and I can't log in. I've created the user through the WebUI and reset the password and it works just like I want it to.
The reason I'm creating the accounts using the CLI is to migrate accounts from an old LDAP instance into FreeIPA via script. I want to then have an admin reset the users password so the user can then log in and set their final password in FreeIPA's WebUI.
Both Web UI and IPA command line tool are using the same IPA API, so you'd see how a user account was created in the /var/log/httpd/error_log on the IPA server. In FreeIPA 4.12+ we also log these in audit messages sent to systemd's journal which can be seen with `journalctl -g IPA.API` but this only so far was delivered to Fedora 40+.
Can you show more details on how exactly those entries in error_log look like?
Additionally, what that "I can't log in" looks like, again, in the error_log?
Username and domains have been changed to protect the guilty :-) running FreeIPA 4.12.1 :
ipa user-add test4 --uid 4321 --random --first test4 --last test4
------------------ Added user "test4" ------------------ User login: test4 First name: test4 Last name: test4 Full name: test4 test4 Display name: test4 test4 Initials: tt Home directory: /home/test4 GECOS: test4 test4 Login shell: /bin/bash Principal name: test4@DOMAIN.ORG Principal alias: test4@DOMAIN.ORG User password expiration: 20240926123724Z Email address: test4@DOMAIN.org Random password: 6Qz:Ki,(<O[Gm|M-/g)%n0 UID: 4321 GID: 4321 Password: True Member of groups: ipausers Kerberos keys available: True
no error output from /var/log/httpd/errror_log on freeipa server
Reset user test4 password using FreeIPA web UI, I changed the password to test1234!@#$ :
[Thu Sep 26 05:40:36.643054 2024] [:warn] [pid 2208:tid 2249] [client 192.168.1.95:11771] failed to set perms (3140) on file (/run/ipa/ccaches/admin_user@DOMAIN.ORG-OBcVGG)!, referer: https://idm1.domain.org/ipa/ui/ [Thu Sep 26 05:40:36.984071 2024] [wsgi:error] [pid 1291:tid 1684] [remote 192.168.1.95:11771] ipa: INFO: [jsonserver_session] admin_user@DOMAIN.ORG: passwd('test4', '********', None, version='2.254'): SUCCESS [Thu Sep 26 05:40:36.994647 2024] [:warn] [pid 2208:tid 2260] [client 192.168.1.95:11771] failed to set perms (3140) on file (/run/ipa/ccaches/admin_user@DOMAIN.ORG-OBcVGG)!, referer: https://idm1.domain.org/ipa/ui/ [Thu Sep 26 05:40:37.277897 2024] [wsgi:error] [pid 1290:tid 1693] [remote 192.168.1.95:11771] ipa: INFO: admin_user@DOMAIN.ORG: batch: user_show('test4', rights=True, all=True): SUCCESS [Thu Sep 26 05:40:37.290808 2024] [wsgi:error] [pid 1290:tid 1693] [remote 192.168.1.95:11771] ipa: INFO: admin_user@DOMAIN.ORG: batch: pwpolicy_show(None, rights=True, user='test4', all=True): SUCCESS [Thu Sep 26 05:40:37.314097 2024] [wsgi:error] [pid 1290:tid 1693] [remote 192.168.1.95:11771] ipa: INFO: admin_user@DOMAIN.ORG: batch: krbtpolicy_show('test4', rights=True, all=True): SUCCESS [Thu Sep 26 05:40:37.340971 2024] [wsgi:error] [pid 1290:tid 1693] [remote 192.168.1.95:11771] ipa: INFO: admin_user@DOMAIN.ORG: batch: cert_find(None, sizelimit=0, all=True, user=('test4',)): SUCCESS [Thu Sep 26 05:40:37.341500 2024] [wsgi:error] [pid 1290:tid 1693] [remote 192.168.1.95:11771] ipa: INFO: [jsonserver_session] admin_user@DOMAIN.ORG: batch(user_show('test4', rights=True, all=True), pwpolicy_show(None, rights=True, user='test4', all=True), krbtpolicy_show('test4', rights=True, all=True), cert_find(None, sizelimit=0, all=True, user=('test4',))): SUCCESS [Thu Sep 26 05:40:37.352598 2024] [:warn] [pid 2208:tid 2244] [client 192.168.1.95:11771] failed to set perms (3140) on file (/run/ipa/ccaches/admin_user@DOMAIN.ORG-OBcVGG)!, referer: https://idm1.domain.org/ipa/ui/ [Thu Sep 26 05:40:37.358872 2024] [:warn] [pid 1298:tid 1469] [client 192.168.1.95:11774] failed to set perms (3140) on file (/run/ipa/ccaches/admin_user@DOMAIN.ORG-OBcVGG)!, referer: https://idm1.domain.org/ipa/ui/ [Thu Sep 26 05:40:37.359800 2024] [:warn] [pid 1298:tid 1470] [client 192.168.1.95:11775] failed to set perms (3140) on file (/run/ipa/ccaches/admin_user@DOMAIN.ORG-OBcVGG)!, referer: https://idm1.domain.org/ipa/ui/ [Thu Sep 26 05:40:37.377870 2024] [wsgi:error] [pid 1294:tid 1687] [remote 192.168.1.95:11771] ipa: INFO: [jsonserver_session] admin_user@DOMAIN.ORG: radiusproxy_find(None, version='2.254'): SUCCESS [Thu Sep 26 05:40:37.381330 2024] [wsgi:error] [pid 1293:tid 1696] [remote 192.168.1.95:11774] ipa: INFO: [jsonserver_session] admin_user@DOMAIN.ORG: idp_find(None, version='2.254'): SUCCESS [Thu Sep 26 05:40:37.385839 2024] [wsgi:error] [pid 1291:tid 1684] [remote 192.168.1.95:11775] ipa: INFO: [jsonserver_session] admin_user@DOMAIN.ORG: user_find(None, version='2.254', no_members=True): SUCCESS
Log into WebUI with user test4 using with newly changed (test1234!@#$) password:
[Thu Sep 26 05:44:26.415791 2024] [wsgi:error] [pid 1294:tid 1687] [remote 192.168.1.95:11787] ipa: INFO: 401 Unauthorized: kinit: Generic error (see e-text) while getting initial credentials [Thu Sep 26 05:44:26.415832 2024] [wsgi:error] [pid 1294:tid 1687] [remote 192.168.1.95:11787]
I'd also like to note that I get the same error message in the WebUI:
The password or username you entered is incorrect
if I log in using the old password ( 6Qz:Ki,(<O[Gm|M-/g)%n0 )or what the admin_user sets it to ( test1234!@#$ )
On Чцв, 26 вер 2024, Kris C via FreeIPA-users wrote:
Username and domains have been changed to protect the guilty :-) running FreeIPA 4.12.1 :
ipa user-add test4 --uid 4321 --random --first test4 --last test4
Added user "test4"
User login: test4 First name: test4 Last name: test4 Full name: test4 test4 Display name: test4 test4 Initials: tt Home directory: /home/test4 GECOS: test4 test4 Login shell: /bin/bash Principal name: test4@DOMAIN.ORG Principal alias: test4@DOMAIN.ORG User password expiration: 20240926123724Z Email address: test4@DOMAIN.org Random password: 6Qz:Ki,(<O[Gm|M-/g)%n0 UID: 4321 GID: 4321
^^^^^^^^ I think this is your problem.
If I'd try to add the same user (with uid 4321), dirsrv error log will have this:
[26/Sep/2024:13:12:30.451206787 +0000] - ERR - find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 533]: Cannot convert Posix ID [4321] into an unused SID on entry [uid=test4,cn=users,cn=accounts,dc=ipa1,dc=test]. [26/Sep/2024:13:12:30.457442932 +0000] - ERR - ipa_sidgen_add_post_op - [file ipa_sidgen.c, line 149]: Cannot add SID to new entry.
This is because UID 4321 is out of ID ranges I have.
Then Kerberos authentication will fail because KDC will not be able to create PAC structure for this user (information about user) as PAC requires SIDs.
You'll see this in krb5kdc.log when doing 'kinit' or 'kpasswd' for this user:
Sep 26 13:13:07 master1.ipa1.test krb5kdc[106210](info): AS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.0.197.85: NEEDED_PREAUTH: test4@IPA1.TEST for kadmin/changepw@IPA1.TEST, Additional pre-authentication required Sep 26 13:13:07 master1.ipa1.test krb5kdc[106210](info): closing down fd 11 Sep 26 13:13:08 master1.ipa1.test krb5kdc[106208](info): AS_REQ : handle_authdata (2) Sep 26 13:13:08 master1.ipa1.test krb5kdc[106208](info): AS_REQ (6 etypes {aes256-cts-hmac-sha384-192(20), aes128-cts-hmac-sha256-128(19), aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), camellia256-cts-cmac(26), camellia128-cts-cmac(25)}) 10.0.197.85: HANDLE_AUTHDATA: test4@IPA1.TEST for kadmin/changepw@IPA1.TEST, No such file or directory Sep 26 13:13:08 master1.ipa1.test krb5kdc[106208](info): closing down fd 11
If you can avoid specifying pre-defined UID/GID, the values from existing ID range will be automatically used and everything should work fine.
If you need to force a particular UID/GID value, then you should have local ID range that covers these UID/GID values. And this ID range should have RID parameters that allow to generate SIDs.
See https://freeipa.readthedocs.io/en/latest/designs/id-mapping.html for more details. This article https://access.redhat.com/articles/7027037 goes a bit more in details what SID/RID means and how they connected to ID ranges in IPA.
Password: True Member of groups: ipausers Kerberos keys available: True
no error output from /var/log/httpd/errror_log on freeipa server
Reset user test4 password using FreeIPA web UI, I changed the password to test1234!@#$ :
[Thu Sep 26 05:40:36.643054 2024] [:warn] [pid 2208:tid 2249] [client 192.168.1.95:11771] failed to set perms (3140) on file (/run/ipa/ccaches/admin_user@DOMAIN.ORG-OBcVGG)!, referer: https://idm1.domain.org/ipa/ui/ [Thu Sep 26 05:40:36.984071 2024] [wsgi:error] [pid 1291:tid 1684] [remote 192.168.1.95:11771] ipa: INFO: [jsonserver_session] admin_user@DOMAIN.ORG: passwd('test4', '********', None, version='2.254'): SUCCESS [Thu Sep 26 05:40:36.994647 2024] [:warn] [pid 2208:tid 2260] [client 192.168.1.95:11771] failed to set perms (3140) on file (/run/ipa/ccaches/admin_user@DOMAIN.ORG-OBcVGG)!, referer: https://idm1.domain.org/ipa/ui/ [Thu Sep 26 05:40:37.277897 2024] [wsgi:error] [pid 1290:tid 1693] [remote 192.168.1.95:11771] ipa: INFO: admin_user@DOMAIN.ORG: batch: user_show('test4', rights=True, all=True): SUCCESS [Thu Sep 26 05:40:37.290808 2024] [wsgi:error] [pid 1290:tid 1693] [remote 192.168.1.95:11771] ipa: INFO: admin_user@DOMAIN.ORG: batch: pwpolicy_show(None, rights=True, user='test4', all=True): SUCCESS [Thu Sep 26 05:40:37.314097 2024] [wsgi:error] [pid 1290:tid 1693] [remote 192.168.1.95:11771] ipa: INFO: admin_user@DOMAIN.ORG: batch: krbtpolicy_show('test4', rights=True, all=True): SUCCESS [Thu Sep 26 05:40:37.340971 2024] [wsgi:error] [pid 1290:tid 1693] [remote 192.168.1.95:11771] ipa: INFO: admin_user@DOMAIN.ORG: batch: cert_find(None, sizelimit=0, all=True, user=('test4',)): SUCCESS [Thu Sep 26 05:40:37.341500 2024] [wsgi:error] [pid 1290:tid 1693] [remote 192.168.1.95:11771] ipa: INFO: [jsonserver_session] admin_user@DOMAIN.ORG: batch(user_show('test4', rights=True, all=True), pwpolicy_show(None, rights=True, user='test4', all=True), krbtpolicy_show('test4', rights=True, all=True), cert_find(None, sizelimit=0, all=True, user=('test4',))): SUCCESS [Thu Sep 26 05:40:37.352598 2024] [:warn] [pid 2208:tid 2244] [client 192.168.1.95:11771] failed to set perms (3140) on file (/run/ipa/ccaches/admin_user@DOMAIN.ORG-OBcVGG)!, referer: https://idm1.domain.org/ipa/ui/ [Thu Sep 26 05:40:37.358872 2024] [:warn] [pid 1298:tid 1469] [client 192.168.1.95:11774] failed to set perms (3140) on file (/run/ipa/ccaches/admin_user@DOMAIN.ORG-OBcVGG)!, referer: https://idm1.domain.org/ipa/ui/ [Thu Sep 26 05:40:37.359800 2024] [:warn] [pid 1298:tid 1470] [client 192.168.1.95:11775] failed to set perms (3140) on file (/run/ipa/ccaches/admin_user@DOMAIN.ORG-OBcVGG)!, referer: https://idm1.domain.org/ipa/ui/ [Thu Sep 26 05:40:37.377870 2024] [wsgi:error] [pid 1294:tid 1687] [remote 192.168.1.95:11771] ipa: INFO: [jsonserver_session] admin_user@DOMAIN.ORG: radiusproxy_find(None, version='2.254'): SUCCESS [Thu Sep 26 05:40:37.381330 2024] [wsgi:error] [pid 1293:tid 1696] [remote 192.168.1.95:11774] ipa: INFO: [jsonserver_session] admin_user@DOMAIN.ORG: idp_find(None, version='2.254'): SUCCESS [Thu Sep 26 05:40:37.385839 2024] [wsgi:error] [pid 1291:tid 1684] [remote 192.168.1.95:11775] ipa: INFO: [jsonserver_session] admin_user@DOMAIN.ORG: user_find(None, version='2.254', no_members=True): SUCCESS
Log into WebUI with user test4 using with newly changed (test1234!@#$) password:
[Thu Sep 26 05:44:26.415791 2024] [wsgi:error] [pid 1294:tid 1687] [remote 192.168.1.95:11787] ipa: INFO: 401 Unauthorized: kinit: Generic error (see e-text) while getting initial credentials [Thu Sep 26 05:44:26.415832 2024] [wsgi:error] [pid 1294:tid 1687] [remote 192.168.1.95:11787] -- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Here's my dilemma, I have 30 years' worth of users and data, and their files are EVERYWHERE so the thought of having to re-UID everything doesn't sound appealing. If I create the user accounts without the UID field and then change it after the accounts are created, will that work?
On Чцв, 26 вер 2024, Kris C via FreeIPA-users wrote:
Here's my dilemma, I have 30 years' worth of users and data, and their files are EVERYWHERE so the thought of having to re-UID everything doesn't sound appealing. If I create the user accounts without the UID field and then change it after the accounts are created, will that work?
All you need to do is to add the ID range before adding users (and restart dirsrv).
For example: suppose you have legacy user accounts within 1000..32999 range and you have default IPA ID range that already defines main and secondary RID bases:
# ipa idrange-find ---------------- 5 ranges matched ---------------- Range name: IPA1.TEST_id_range First Posix ID of the range: 449800000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000 Range type: local domain range ....
You want to add new ID range for these users:
# ipa idrange-add IPA1.TEST_legacy_id_range \ --base-id=1000 --range-size=32000 \ --rid-base=$((200000+1000)) \ --secondary-rid-base=$((200000+1000+320000)) \ --type=ipa-local
E.g. we start with POSIX ID at 1000 and end at 33000 (range size 32000). RID base of the default IPA ID range starts at 1000 and that range contains 200000 IDs, so our RID base should be outside of [1000;201000] and should not overlap with that's ID range's secondary RID range of [100000000;100200000].
For simplicity, our RID bases are adjacent to existing RID range of the default ID range.
Now restart your dirsrv to make it take this new ID range into account:
# systemctl restart dirsrv@IPA1-TEST
and adding users will not cause any issue:
# ipa user-add test5 --uid 5421 --random --first test5 --last test5 ------------------ Added user "test5" ------------------ User login: test5 First name: test5 Last name: test5 Full name: test5 test5 Display name: test5 test5 Initials: tt Home directory: /home/test5 GECOS: test5 test5 Login shell: /bin/sh Principal name: test5@IPA1.TEST Principal alias: test5@IPA1.TEST User password expiration: 20240926163037Z Email address: test5@ipa1.test Random password: 0Fi[J7KGaiy2fDfVgW88b! UID: 5421 GID: 5421 Password: True Member of groups: ipausers Kerberos keys available: True
# ipa user-show test5 --all|grep securityidentifier ipantsecurityidentifier: S-1-5-21-890255870-1654639547-3010339007-205421
You can see that IPA chose RID 205421 (ID 5421 minus base ID of 1000 plus RID base 201000 = 205421).
Hmm .. that sounds too reasonable :-).
Would doing this cause any problems with implementing subuids/subgids within IdM? We do development with podman.
So I tried this: ipa idrange-add IPA1.TEST_legacy_id_range \ --base-id=1000 --range-size=32000 \ --rid-base=$((200000+1000)) \ --secondary-rid-base=$((200000+1000+320000)) \ --type=ipa-local
as you suggested and unfortunately it doesn't seem to fix the problem.
On the other hand:
I was able to create the users without the --uid field (ipa user-add test5 --random --first test5 --last test5), allow IdM to generate the account as it wants to then go back and modify the uid field to our legacy numbering (ipa user-mod test5 --uid 3456). So far that's seemed to have worked. I'll do some more testing to make sure it doesn't have any adverse impact. Is there anything you foresee with me doing this that might cause an issue down the road?
I really appreciate your help with this Alexander, I'm very grateful for your support!
On Чцв, 26 вер 2024, Kris C via FreeIPA-users wrote:
So I tried this: ipa idrange-add IPA1.TEST_legacy_id_range \ --base-id=1000 --range-size=32000 \ --rid-base=$((200000+1000)) \ --secondary-rid-base=$((200000+1000+320000)) \ --type=ipa-local
as you suggested and unfortunately it doesn't seem to fix the problem.
You'd need to provide more details. I was suggesting this on a hunch. I hope you did change the values, though. ;)
On the other hand:
I was able to create the users without the --uid field (ipa user-add test5 --random --first test5 --last test5), allow IdM to generate the account as it wants to then go back and modify the uid field to our legacy numbering (ipa user-mod test5 --uid 3456). So far that's seemed to have worked. I'll do some more testing to make sure it doesn't have any adverse impact. Is there anything you foresee with me doing this that might cause an issue down the road?
Probably nothing within IPA would break directly because of that.
Ok, so I guess a final question that I have is: If --uid is an option available to me when I create an account, is it a bug if I create an account specifying a UID that's not in the range of the RIDs? Is it a bug if I have to change it later to match my existing UID scheme? Should the creation of UID and SID/RID be divorced from each other so I as a sysadmin can specify a UID I want to use?
Thanks so much.
Kris C via FreeIPA-users wrote:
Ok, so I guess a final question that I have is: If --uid is an option available to me when I create an account, is it a bug if I create an account specifying a UID that's not in the range of the RIDs? Is it a bug if I have to change it later to match my existing UID scheme? Should the creation of UID and SID/RID be divorced from each other so I as a sysadmin can specify a UID I want to use?
We try not to constrain users too much because of the types of legacy issues you're seeing. Generally creating a new ID range for the old ids is preferable and after that things just work.
If you want to change the UID afterward that's certainly your prerogative but that doesn't preclude a user with that original UID to be created and then you'd have a conflict in SID. Probably a chance approaching zero but if not you'll get a LDAP_CONSTRAINT_VIOLATION.
The SID is calculated from the RID base and the UID of the user.
So for range:
Range name: EXAMPLE.TEST_id_range First Posix ID of the range: 1851200000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000 Range type: local domain range
Take the UID minus the starting value in the idrange.
ID = 1851200003 - 1851200000 + 1000
So the ID = 1003
Add that to the SID base, which in my case is S-1-5-21-745287385-4213998968-1197924862, and you get:
ipantsecurityidentifier: S-1-5-21-745287385-4213998968-1197924862-1003
Note that the admin user is special and is fixed at 500.
So you can do what you want but keep this in mind to avoid conflicts.
Alexander is more an expert than I so maybe he'll chime in too.
rob
On Чцв, 03 кас 2024, Rob Crittenden via FreeIPA-users wrote:
Kris C via FreeIPA-users wrote:
Ok, so I guess a final question that I have is: If --uid is an option available to me when I create an account, is it a bug if I create an account specifying a UID that's not in the range of the RIDs? Is it a bug if I have to change it later to match my existing UID scheme? Should the creation of UID and SID/RID be divorced from each other so I as a sysadmin can specify a UID I want to use?
We try not to constrain users too much because of the types of legacy issues you're seeing. Generally creating a new ID range for the old ids is preferable and after that things just work.
If you want to change the UID afterward that's certainly your prerogative but that doesn't preclude a user with that original UID to be created and then you'd have a conflict in SID. Probably a chance approaching zero but if not you'll get a LDAP_CONSTRAINT_VIOLATION.
The SID is calculated from the RID base and the UID of the user.
So for range:
Range name: EXAMPLE.TEST_id_range First Posix ID of the range: 1851200000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000 Range type: local domain range
Take the UID minus the starting value in the idrange.
ID = 1851200003 - 1851200000 + 1000
So the ID = 1003
Add that to the SID base, which in my case is S-1-5-21-745287385-4213998968-1197924862, and you get:
ipantsecurityidentifier: S-1-5-21-745287385-4213998968-1197924862-1003
Note that the admin user is special and is fixed at 500.
So you can do what you want but keep this in mind to avoid conflicts.
Alexander is more an expert than I so maybe he'll chime in too.
Thank you, this is how it is designed, so nothing to add. ;)
freeipa-users@lists.fedorahosted.org
-
Alexander Bokovoy -
Kris C -
Rob Crittenden