Bug 1898459
| Summary: | ipa-server-upgrade fails without 'admin' user | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Rob Foehl <rwf> | ||||
| Component: | freeipa | Assignee: | IPA Maintainers <ipa-maint> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 33 | CC: | abokovoy, contribs, fcami, ftrivino, ipa-maint, jcholast, jhrozek, mhjacks, pvoborni, rcritten, ssorce, twoerner | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2021-11-05 07:43:37 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Attachments: |
|
||||||
|
Description
Rob Foehl
2020-11-17 08:15:06 UTC
We do not support installations without admin user and admins group. They must exist. I'm not sure where to start with that, given the motivation here... Either leaving 'admin' around is a bad idea for the exact same reason, or this change isn't necessary. I would point you to https://bugzilla.redhat.com/show_bug.cgi?id=1789205 but this bug is private. Let me copy the relevant fragments of it: ------ Customer executed ipa-adtrust-install and it was successful but it throws a warning message. But cutomer has a valid principal of IPA administrator user. He excuted kinit with an IPA administrator user before ipa-adtrust-install. ~~~~~~~~ WARNING: you MUST re-kinit admin user before using 'ipa trust-*' commands family in order to re-generate Kerberos tickets to include AD-specific ~~~~~~~~ But he is not using admin user. They have deleted an admin user and using a user which is in the group of administrators in IPA to perform this. I don't think this should be a problem. Am I correct ? And he tried to create the trust again and that fails. I am attaching those outputs also. They tried with two administrator users. Attaching both the outputs. ----- Deleting pre-defined administrative user and group is certainly not supported. If they are not using those, one can disable 'admin' user with 'ipa user-disable admin' command. ipa-adtrust-install expects both of them exist and specifically admin user to exist before modifying the admins group. ----- This all resulted in updating the documentation to provide the information about admin/admins: User admin is required to exist: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/linux_domain_identity_authentication_and_policy_guide/index#managing-users-life-cycle Group admins is required to exist: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/linux_domain_identity_authentication_and_policy_guide/index#ugroups-intro-default The second part of it was how to recover admin user / admins group: ------ It is a bit complicated. Attached is an update file that needs to be modified before applying. Please run on the initial master # ipa idrange-show EXAMPLE.COM_id_range where EXAMPLE.COM is replaced by your realm name. It should display an ID range assigned to this master. Something like Range name: EXAMPLE.COM_id_range First Posix ID of the range: 1536000000 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 value from 'First Posix ID of the range' and replace string VALUE in the attached file with it. E.g., replace default: uidNumber: VALUE with default: uidNumber: 1536000000 and the same for gidNumber. After that, apply the update file: # ipa-ldap-updater ./80-admin-user.update This should create an admin user with the correct uidNumber and SID. After that, you need to add 'admin' user to admins group with # ipa group-add-member admins --users=admin and, finally, re-run ipa-adtrust-install # ipa-adtrust-install --add-sids Then verify that admins group has a SID ending with -512, like before. ------- We also created https://github.com/freeipa/freeipa-healthcheck/issues/120 to track the issue through ipa-healthcheck. There is a rule now that should highlight the fact that admin/admins are missing. The ticket for healthcheck is still open as tests aren't merged yet. Created attachment 1730052 [details]
admin user recovery LDAP update file
Also, domain SID in the 80-admin-user.update should be updated to correspond to IPA domain SID. Thanks for the pointer on how to recover that user -- I'd already tried to find that without any luck. Still problematic having it around, though. In any case, I'll have to see whether I have the stamina for another round of FreeIPA misadventures tomorrow. This message is a reminder that Fedora 33 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 33 on 2021-11-30. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '33'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 33 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Closing as NOTABUG as the behavior is expected. |