I have two FreeIPA servers in a cluster, both running on RHEL 8.9. They started on RHEL 8.0 I believe, and have been upgrading in-place since then. I recently restarted the FreeIPA services, which triggered an ipa-server-upgrade to upgrade from 4.9.11 to 4.9.12. When that ran, it errored out on some expired certificates, which I fixed with ipa-cert-fix, and then the ipa-server-upgrade's finished successfully.
Now, when I or any of my users try to log on to the web UI, we get the error "Your session has expired. Please log in again." Also, when I try to run any ipa command on the command line, I get the error: ipa: ERROR: cannot connect to 'any of the configured servers': https://ipa01.semi.example.net/ipa/session/json, https://ipa02.semi.example.net/ipa/session/json
I've traced down lots of errors, and I think this one is the most relevant: 401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty) I see it in /var/log/httpd/error_log, in the body of the HTTP response from https://ipa01.semi.example.net/ipa/session/json in my web browser, and in the output from the command ipa --debug
Also, in /var/log/krb5kdc.log, I see: Jan 17 01:14:47 ipa01.semi.example.net krb5kdc[55855](info): TGS_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)}) 172.16.121.5: S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1705454084, etypes {rep=UNSUPPORTED:(0)} HTTP/ipa01.semi.example.net@SEMI.EXAMPLE.NET for ldap/ipa01.semi.example.net@SEMI.EXAMPLE.NET, KDC policy rejects request
I have krb5 1.18.2 installed. disable_pac is not present in /var/kerberos/krb5kdc/kdc.conf.
I think I'm experiencing the same issue seen in the recent thread at https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... (subject line "api authorization stopped working after upgrade to 4.9.12-11 on RHEL8").
I don't think any of my users or groups have an SID (ipantsecurityidentifier). This FreeIPA cluster was installed on RHEL 8.0 (or thereabouts), and the servers have been upgraded in-place since then. We've never integrated with any Active Directory or Microsoft product.
This command has no output, showing that even the admin user does not have an SID: ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b cn=users,cn=accounts,dc=semi,dc=example,dc=net uid=admin '*' + | grep -i ipantsecurityidentifier
The solution from the other thread, and from https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm..., does not work for me, since the ipa command doesn't work, not even for the admin user:
[root@ipa01.semi.example.net ~] # kinit admin Password for admin@SEMI.EXAMPLE.NET: [root@ipa01.semi.example.net ~] # ipa config-mod --enable-sid --add-sids ipa: ERROR: cannot connect to 'any of the configured servers': https://ipa01.semi.example.net/ipa/json, https://ipa02.semi.example.net/ipa/json
I found an alternative method at https://freeipa.readthedocs.io/en/latest/designs/adtrust/sidconfig.html#trou..., but this also does not work for me:
[root@ipa01.semi.example.net ~] # ldapmodify -H ldapi://%2Frun%2Fslapd-SEMI-EXAMPLE-NET.socket -f /tmp/ipa-sidgen-task-run.ldif SASL/GSSAPI authentication started SASL username: admin@SEMI.EXAMPLE.NET SASL SSF: 256 SASL data security layer installed. adding new entry "cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config" ldap_add: No such object (32)
I think ipa-sidgen-task does not exist in my LDAP directory, but I'm not sure if I understand how this is supposed to work. I don't see ipa-sidgen-task or anything like it from this search: ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b cn=config | grep cn=tasks
Can anyone help me here? I think if I could get a ipantsecurityidentifier attribute properly set up on my user or on the admin user, then I would be able to use the ipa command to get SID's enabled and created everywhere.
Paul Nickerson via FreeIPA-users wrote:
I have two FreeIPA servers in a cluster, both running on RHEL 8.9. They started on RHEL 8.0 I believe, and have been upgrading in-place since then. I recently restarted the FreeIPA services, which triggered an ipa-server-upgrade to upgrade from 4.9.11 to 4.9.12. When that ran, it errored out on some expired certificates, which I fixed with ipa-cert-fix, and then the ipa-server-upgrade's finished successfully.
Now, when I or any of my users try to log on to the web UI, we get the error "Your session has expired. Please log in again." Also, when I try to run any ipa command on the command line, I get the error: ipa: ERROR: cannot connect to 'any of the configured servers': https://ipa01.semi.example.net/ipa/session/json, https://ipa02.semi.example.net/ipa/session/json
I've traced down lots of errors, and I think this one is the most relevant: 401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty) I see it in /var/log/httpd/error_log, in the body of the HTTP response from https://ipa01.semi.example.net/ipa/session/json in my web browser, and in the output from the command ipa --debug
Also, in /var/log/krb5kdc.log, I see: Jan 17 01:14:47 ipa01.semi.example.net krb5kdc[55855](info): TGS_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)}) 172.16.121.5: S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1705454084, etypes {rep=UNSUPPORTED:(0)} HTTP/ipa01.semi.example.net@SEMI.EXAMPLE.NET for ldap/ipa01.semi.example.net@SEMI.EXAMPLE.NET, KDC policy rejects request
I have krb5 1.18.2 installed. disable_pac is not present in /var/kerberos/krb5kdc/kdc.conf.
I think I'm experiencing the same issue seen in the recent thread at https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... (subject line "api authorization stopped working after upgrade to 4.9.12-11 on RHEL8").
I don't think any of my users or groups have an SID (ipantsecurityidentifier). This FreeIPA cluster was installed on RHEL 8.0 (or thereabouts), and the servers have been upgraded in-place since then. We've never integrated with any Active Directory or Microsoft product.
This command has no output, showing that even the admin user does not have an SID: ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b cn=users,cn=accounts,dc=semi,dc=example,dc=net uid=admin '*' + | grep -i ipantsecurityidentifier
The solution from the other thread, and from https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm..., does not work for me, since the ipa command doesn't work, not even for the admin user:
[root@ipa01.semi.example.net ~] # kinit admin Password for admin@SEMI.EXAMPLE.NET: [root@ipa01.semi.example.net ~] # ipa config-mod --enable-sid --add-sids ipa: ERROR: cannot connect to 'any of the configured servers': https://ipa01.semi.example.net/ipa/json, https://ipa02.semi.example.net/ipa/json
I found an alternative method at https://freeipa.readthedocs.io/en/latest/designs/adtrust/sidconfig.html#trou..., but this also does not work for me:
[root@ipa01.semi.example.net ~] # ldapmodify -H ldapi://%2Frun%2Fslapd-SEMI-EXAMPLE-NET.socket -f /tmp/ipa-sidgen-task-run.ldif SASL/GSSAPI authentication started SASL username: admin@SEMI.EXAMPLE.NET SASL SSF: 256 SASL data security layer installed. adding new entry "cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config" ldap_add: No such object (32)
I think ipa-sidgen-task does not exist in my LDAP directory, but I'm not sure if I understand how this is supposed to work. I don't see ipa-sidgen-task or anything like it from this search: ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b cn=config | grep cn=tasks
Can anyone help me here? I think if I could get a ipantsecurityidentifier attribute properly set up on my user or on the admin user, then I would be able to use the ipa command to get SID's enabled and created everywhere.
Try, as root:
# /usr/libexec/ipa/oddjob/org.freeipa.server.config-enable-sid --add-sids
rob
On Срд, 17 сту 2024, Paul Nickerson via FreeIPA-users wrote:
I have two FreeIPA servers in a cluster, both running on RHEL 8.9. They started on RHEL 8.0 I believe, and have been upgrading in-place since then. I recently restarted the FreeIPA services, which triggered an ipa-server-upgrade to upgrade from 4.9.11 to 4.9.12. When that ran, it errored out on some expired certificates, which I fixed with ipa-cert-fix, and then the ipa-server-upgrade's finished successfully.
Now, when I or any of my users try to log on to the web UI, we get the error "Your session has expired. Please log in again." Also, when I try to run any ipa command on the command line, I get the error: ipa: ERROR: cannot connect to 'any of the configured servers': https://ipa01.semi.example.net/ipa/session/json, https://ipa02.semi.example.net/ipa/session/json
I've traced down lots of errors, and I think this one is the most relevant: 401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty) I see it in /var/log/httpd/error_log, in the body of the HTTP response from https://ipa01.semi.example.net/ipa/session/json in my web browser, and in the output from the command ipa --debug
Also, in /var/log/krb5kdc.log, I see: Jan 17 01:14:47 ipa01.semi.example.net krb5kdc[55855](info): TGS_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)}) 172.16.121.5: S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1705454084, etypes {rep=UNSUPPORTED:(0)} HTTP/ipa01.semi.example.net@SEMI.EXAMPLE.NET for ldap/ipa01.semi.example.net@SEMI.EXAMPLE.NET, KDC policy rejects request
I have krb5 1.18.2 installed. disable_pac is not present in /var/kerberos/krb5kdc/kdc.conf.
I think I'm experiencing the same issue seen in the recent thread at https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... (subject line "api authorization stopped working after upgrade to 4.9.12-11 on RHEL8").
I don't think any of my users or groups have an SID (ipantsecurityidentifier). This FreeIPA cluster was installed on RHEL 8.0 (or thereabouts), and the servers have been upgraded in-place since then. We've never integrated with any Active Directory or Microsoft product.
FreeIPA generates SIDs by default since FreeIPA 4.9.8. It is configured to do so on new installations even when integration with AD is not considered, due to tightened requirements to process constrained delegation in Kerberos.
This command has no output, showing that even the admin user does not have an SID: ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b cn=users,cn=accounts,dc=semi,dc=example,dc=net uid=admin '*' + | grep -i ipantsecurityidentifier
The solution from the other thread, and from https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm..., does not work for me, since the ipa command doesn't work, not even for the admin user:
[root@ipa01.semi.example.net ~] # kinit admin Password for admin@SEMI.EXAMPLE.NET: [root@ipa01.semi.example.net ~] # ipa config-mod --enable-sid --add-sids ipa: ERROR: cannot connect to 'any of the configured servers': https://ipa01.semi.example.net/ipa/json, https://ipa02.semi.example.net/ipa/json
I found an alternative method at https://freeipa.readthedocs.io/en/latest/designs/adtrust/sidconfig.html#trou..., but this also does not work for me:
[root@ipa01.semi.example.net ~] # ldapmodify -H ldapi://%2Frun%2Fslapd-SEMI-EXAMPLE-NET.socket -f /tmp/ipa-sidgen-task-run.ldif SASL/GSSAPI authentication started SASL username: admin@SEMI.EXAMPLE.NET SASL SSF: 256 SASL data security layer installed. adding new entry "cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config" ldap_add: No such object (32)
I think ipa-sidgen-task does not exist in my LDAP directory, but I'm not sure if I understand how this is supposed to work. I don't see ipa-sidgen-task or anything like it from this search: ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b cn=config | grep cn=tasks
Can anyone help me here? I think if I could get a ipantsecurityidentifier attribute properly set up on my user or on the admin user, then I would be able to use the ipa command to get SID's enabled and created everywhere.
You'd need to enable SID generation first, then run those tasks. Without sidgen plugins enabled, one cannot initiate SID generation.
Please follow the command Rob pointed you to. If that one fails, please provide more details about your configuration, including ID ranges you have. You can operate IPA API on IPA master as root with
# ipa -e in_server=True ...
This would use LDAPI connection as root and would map you into a 'cn=Directory Manager' in LDAP. Not all calls would work (some check presence of Kerberos tickets) but at least 'idrange-find' should work.
On Срд, 17 сту 2024, Alexander Bokovoy via FreeIPA-users wrote:
On Срд, 17 сту 2024, Paul Nickerson via FreeIPA-users wrote:
I have two FreeIPA servers in a cluster, both running on RHEL 8.9. They started on RHEL 8.0 I believe, and have been upgrading in-place since then. I recently restarted the FreeIPA services, which triggered an ipa-server-upgrade to upgrade from 4.9.11 to 4.9.12. When that ran, it errored out on some expired certificates, which I fixed with ipa-cert-fix, and then the ipa-server-upgrade's finished successfully.
Now, when I or any of my users try to log on to the web UI, we get the error "Your session has expired. Please log in again." Also, when I try to run any ipa command on the command line, I get the error: ipa: ERROR: cannot connect to 'any of the configured servers': https://ipa01.semi.example.net/ipa/session/json, https://ipa02.semi.example.net/ipa/session/json
I've traced down lots of errors, and I think this one is the most relevant: 401 Unauthorized: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Credential cache is empty) I see it in /var/log/httpd/error_log, in the body of the HTTP response from https://ipa01.semi.example.net/ipa/session/json in my web browser, and in the output from the command ipa --debug
Also, in /var/log/krb5kdc.log, I see: Jan 17 01:14:47 ipa01.semi.example.net krb5kdc[55855](info): TGS_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)}) 172.16.121.5: S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1705454084, etypes {rep=UNSUPPORTED:(0)} HTTP/ipa01.semi.example.net@SEMI.EXAMPLE.NET for ldap/ipa01.semi.example.net@SEMI.EXAMPLE.NET, KDC policy rejects request
I have krb5 1.18.2 installed. disable_pac is not present in /var/kerberos/krb5kdc/kdc.conf.
I think I'm experiencing the same issue seen in the recent thread at https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste... (subject line "api authorization stopped working after upgrade to 4.9.12-11 on RHEL8").
I don't think any of my users or groups have an SID (ipantsecurityidentifier). This FreeIPA cluster was installed on RHEL 8.0 (or thereabouts), and the servers have been upgraded in-place since then. We've never integrated with any Active Directory or Microsoft product.
FreeIPA generates SIDs by default since FreeIPA 4.9.8. It is configured to do so on new installations even when integration with AD is not considered, due to tightened requirements to process constrained delegation in Kerberos.
This command has no output, showing that even the admin user does not have an SID: ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b cn=users,cn=accounts,dc=semi,dc=example,dc=net uid=admin '*' + | grep -i ipantsecurityidentifier
The solution from the other thread, and from https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm..., does not work for me, since the ipa command doesn't work, not even for the admin user:
[root@ipa01.semi.example.net ~] # kinit admin Password for admin@SEMI.EXAMPLE.NET: [root@ipa01.semi.example.net ~] # ipa config-mod --enable-sid --add-sids ipa: ERROR: cannot connect to 'any of the configured servers': https://ipa01.semi.example.net/ipa/json, https://ipa02.semi.example.net/ipa/json
I found an alternative method at https://freeipa.readthedocs.io/en/latest/designs/adtrust/sidconfig.html#trou..., but this also does not work for me:
[root@ipa01.semi.example.net ~] # ldapmodify -H ldapi://%2Frun%2Fslapd-SEMI-EXAMPLE-NET.socket -f /tmp/ipa-sidgen-task-run.ldif SASL/GSSAPI authentication started SASL username: admin@SEMI.EXAMPLE.NET SASL SSF: 256 SASL data security layer installed. adding new entry "cn=sidgen,cn=ipa-sidgen-task,cn=tasks,cn=config" ldap_add: No such object (32)
I think ipa-sidgen-task does not exist in my LDAP directory, but I'm not sure if I understand how this is supposed to work. I don't see ipa-sidgen-task or anything like it from this search: ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b cn=config | grep cn=tasks
Can anyone help me here? I think if I could get a ipantsecurityidentifier attribute properly set up on my user or on the admin user, then I would be able to use the ipa command to get SID's enabled and created everywhere.
You'd need to enable SID generation first, then run those tasks. Without sidgen plugins enabled, one cannot initiate SID generation.
Please follow the command Rob pointed you to. If that one fails, please provide
^^ make sure to pass '--netbios-name NAME' option too. There is currently a bug that the tool does not derive NetBIOS name for the domain properly.
E.g.
# /usr/libexec/ipa/oddjob/org.freeipa.server.config-enable-sid \ --netbios-name EXAMPLE \ --add-sids
Where NetBIOS name (EXAMPLE) is typically a first part of your realm name (EXAMPLE.COM -> EXAMPLE). DO NOT USE full realm/domain name here, it is known to cause a lot of issues later when a trust would be established (be it with AD or, in future, with another IPA deployment), to the point of not being able to upgrade.
more details about your configuration, including ID ranges you have. You can operate IPA API on IPA master as root with
# ipa -e in_server=True ...
This would use LDAPI connection as root and would map you into a 'cn=Directory Manager' in LDAP. Not all calls would work (some check presence of Kerberos tickets) but at least 'idrange-find' should work.
-- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland -- _______________________________________________ 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
Thank you for the assistance. I tried running the oddjob without specifying a NetBIOS name, and it gave a return code of 1, no output, and didn't seem to do anything. Then I saw your NetBIOS comment.
First I checked to see if we already had a NetBIOS name configured, and I didn't find anything (I used ldapsearch because the ipa command was still not working): ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W '(ipaNTFlatName=*)' ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W '(objectClass=ipaNTTrustedDomain)' ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W '(objectclass=ipaNTDomainAttrs)'
So I tried the oddjob with the NetBIOS name option, formatted as you recommended: /usr/libexec/ipa/oddjob/org.freeipa.server.config-enable-sid --netbios-name SEMI --add-sids
This still had no output, but it did do good things. I can now find the NetBIOS name using ldapsearch. Many users and groups now have the ipaNTSecurityIdentifier attribute: ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W '(ipaNTSecurityIdentifier=*)'
However, some users were skipped, like mine. The admin user got the ipaNTSecurityIdentifier attribute, so I tried running the ipa command as that user, hoping to modify the skipped users:
[root@ipa01.semi.example.net ~] # kinit admin Password for admin@SEMI.EXAMPLE.NET: [root@ipa01.semi.example.net ~] # ipa config-mod --enable-sid --add-sids Maximum username length: 32 Maximum hostname length: 64 Home directory base: /home Default shell: /bin/bash Default users group: ipausers Default e-mail domain: semi.example.net Search time limit: 2 Search size limit: 500 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: False Certificate Subject base: O=SEMI.EXAMPLE.NET Password Expiration Notification (days): 4 Password plugin features: AllowNThash, KDC:Disable Last Success SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 Default SELinux user: unconfined_u:s0-s0:c0.c1023 Default PAC types: MS-PAC, nfs:NONE IPA masters: ipa01.semi.example.net, ipa02.semi.example.net IPA master capable of PKINIT: ipa01.semi.example.net, ipa02.semi.example.net IPA CA servers: ipa01.semi.example.net, ipa02.semi.example.net IPA CA renewal master: ipa02.semi.example.net
The skipped users still have no ipaNTSecurityIdentifier. But at least I can run ipa commands now.
I've tried looking for patterns in which users were skipped. It's not all users in the admins group. Maybe it's older users, who I think were migrated from a previous FreeIPA version 3 cluster which crashed and burned years ago? I'm going to keep looking for some pattern in which users did not get the ipaNTSecurityIdentifier, but if you have any ideas, please let me know.
Paul Nickerson via FreeIPA-users wrote:
Thank you for the assistance. I tried running the oddjob without specifying a NetBIOS name, and it gave a return code of 1, no output, and didn't seem to do anything. Then I saw your NetBIOS comment.
First I checked to see if we already had a NetBIOS name configured, and I didn't find anything (I used ldapsearch because the ipa command was still not working): ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W '(ipaNTFlatName=*)' ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W '(objectClass=ipaNTTrustedDomain)' ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W '(objectclass=ipaNTDomainAttrs)'
So I tried the oddjob with the NetBIOS name option, formatted as you recommended: /usr/libexec/ipa/oddjob/org.freeipa.server.config-enable-sid --netbios-name SEMI --add-sids
This still had no output, but it did do good things. I can now find the NetBIOS name using ldapsearch. Many users and groups now have the ipaNTSecurityIdentifier attribute: ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W '(ipaNTSecurityIdentifier=*)'
However, some users were skipped, like mine. The admin user got the ipaNTSecurityIdentifier attribute, so I tried running the ipa command as that user, hoping to modify the skipped users:
[root@ipa01.semi.example.net ~] # kinit admin Password for admin@SEMI.EXAMPLE.NET: [root@ipa01.semi.example.net ~] # ipa config-mod --enable-sid --add-sids Maximum username length: 32 Maximum hostname length: 64 Home directory base: /home Default shell: /bin/bash Default users group: ipausers Default e-mail domain: semi.example.net Search time limit: 2 Search size limit: 500 User search fields: uid,givenname,sn,telephonenumber,ou,title Group search fields: cn,description Enable migration mode: False Certificate Subject base: O=SEMI.EXAMPLE.NET Password Expiration Notification (days): 4 Password plugin features: AllowNThash, KDC:Disable Last Success SELinux user map order: guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$sysadm_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023 Default SELinux user: unconfined_u:s0-s0:c0.c1023 Default PAC types: MS-PAC, nfs:NONE IPA masters: ipa01.semi.example.net, ipa02.semi.example.net IPA master capable of PKINIT: ipa01.semi.example.net, ipa02.semi.example.net IPA CA servers: ipa01.semi.example.net, ipa02.semi.example.net IPA CA renewal master: ipa02.semi.example.net
The skipped users still have no ipaNTSecurityIdentifier. But at least I can run ipa commands now.
I've tried looking for patterns in which users were skipped. It's not all users in the admins group. Maybe it's older users, who I think were migrated from a previous FreeIPA version 3 cluster which crashed and burned years ago? I'm going to keep looking for some pattern in which users did not get the ipaNTSecurityIdentifier, but if you have any ideas, please let me know.
The users have to be inside an IPA range in order to have a SID assigned. If you look in /var/log/dirsrv/slapd-REALM/errors you should find an error message about where it failed. IIRC it stops on the first failure.
rob
I confirmed that users who had an ipaNTSecurityIdentifier attribute could log in to the web UI, and those that did not have the ipaNTSecurityIdentifier attribute could not.
I found the error in /var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors like you said: [17/Jan/2024:20:28:09.571195828 +0000] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... [17/Jan/2024:20:28:09.637675948 +0000] - ERR - find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1566000023] into an unused SID. [17/Jan/2024:20:28:09.658369523 +0000] - ERR - do_work - [file ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry. [17/Jan/2024:20:28:09.666726494 +0000] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [32].
I found some nice documentation at https://access.redhat.com/solutions/394763
I used this command to see the ranges that I have configured: ipa idrange-find
And these two commands to see the UIDs of the users who had not yet been given SIDs (some were inside the existing range; I think you're correct that the process stops at the first error): ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b "cn=users,cn=accounts,dc=semi,dc=example,dc=net" "(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v "# requesting: " | sed 's/uidNumber: //' | sort -n ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b "cn=deleted users,cn=accounts,cn=provisioning,dc=semi,dc=example,dc=net" "(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v "# requesting: " | sed 's/uidNumber: //' | sort -n
Here's some documentation on what ID and RID ranges are for: https://www.freeipa.org/page/V3/ID_Ranges
After doing a bunch of math and guess and check, I ran this: ipa idrange-add SEMI.EXAMPLE.NET_US150777_range --base-id=1441400000 --range-size=531251000 --rid-base=101000000 --secondary-rid-base=633000000
That gave me an additional range (confirmed with ipa idrange-find). I ran ipa config-mod --enable-sid --add-sids again, saw no significant errors in /var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors, and confirmed that there were 0 users left with no ipaNTSecurityIdentifier.
All users are all set now. Thank you again.
Paul Nickerson via FreeIPA-users wrote:
I confirmed that users who had an ipaNTSecurityIdentifier attribute could log in to the web UI, and those that did not have the ipaNTSecurityIdentifier attribute could not.
I found the error in /var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors like you said: [17/Jan/2024:20:28:09.571195828 +0000] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... [17/Jan/2024:20:28:09.637675948 +0000] - ERR - find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1566000023] into an unused SID. [17/Jan/2024:20:28:09.658369523 +0000] - ERR - do_work - [file ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry. [17/Jan/2024:20:28:09.666726494 +0000] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [32].
I found some nice documentation at https://access.redhat.com/solutions/394763
I used this command to see the ranges that I have configured: ipa idrange-find
And these two commands to see the UIDs of the users who had not yet been given SIDs (some were inside the existing range; I think you're correct that the process stops at the first error): ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b "cn=users,cn=accounts,dc=semi,dc=example,dc=net" "(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v "# requesting: " | sed 's/uidNumber: //' | sort -n ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b "cn=deleted users,cn=accounts,cn=provisioning,dc=semi,dc=example,dc=net" "(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v "# requesting: " | sed 's/uidNumber: //' | sort -n
Here's some documentation on what ID and RID ranges are for: https://www.freeipa.org/page/V3/ID_Ranges
After doing a bunch of math and guess and check, I ran this: ipa idrange-add SEMI.EXAMPLE.NET_US150777_range --base-id=1441400000 --range-size=531251000 --rid-base=101000000 --secondary-rid-base=633000000
That gave me an additional range (confirmed with ipa idrange-find). I ran ipa config-mod --enable-sid --add-sids again, saw no significant errors in /var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors, and confirmed that there were 0 users left with no ipaNTSecurityIdentifier.
All users are all set now. Thank you again.
Glad to hear it and thank you for your detailed analysis. I think this will be useful to other users that may run into this.
rob
Thanks to Paul for all the leg work on this issue. Based on that, I can confirm that we have the same problem after updating to 4.9.12-11 from 4.9.11-7. Running the oddjob command to add SIDs to the user accounts fails after encountering UIDs outside of the default IPA range. It was able to get the admin account working though. We have 294 users with UIDs in the range of 1001 to 99657. These were migrated from an ancient NIS domain when the IPA domain was provisioned. We tried adding a secondary IPA range that covers that scope:
ipa idrange-add ID.EXAMPLE.COM_legacy_range --base-id=1000 --range-size=98899
And then running the oddjob command again, but we get the sidgen errors still, plus a error about overlapping rid ranges:
[22/Jan/2024:15:09:50.398460268 -0800] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... [22/Jan/2024:15:09:50.499604871 -0800] - ERR - find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [29034] into an unused SID. [22/Jan/2024:15:09:50.499960197 -0800] - ERR - do_work - [file ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry. [22/Jan/2024:15:09:50.503257753 -0800] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [32]. [22/Jan/2024:15:09:55.035779436 -0800] - ERR - schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=id,dc=example,dc=com [22/Jan/2024:15:09:55.036238563 -0800] - ERR - schema-compat-plugin - Finished plugin initialization. [22/Jan/2024:15:47:04.969286883 -0800] - ERR - ipa_range_check_pre_op - [file ipa_range_check.c, line 670]: New primary rid range overlaps with existing primary rid range.
I suspect that we may not have added the range correctly. We didn't pass the --rid-base= or --secondary-rid-base= flags/values as we were not sure what these values should be.
Any help would be much appreciated.
Scott
-----Original Message----- From: Rob Crittenden via FreeIPA-users freeipa-users@lists.fedorahosted.org Sent: Thursday, January 18, 2024 11:25 AM To: FreeIPA users list freeipa-users@lists.fedorahosted.org Cc: Paul Nickerson pgn674@gmail.com; Rob Crittenden rcritten@redhat.com Subject: [Freeipa-users] Re: Upgrade to FreeIPA 4.9.12 on RHEL 8.9 caused web UI login and ipa command to stop working
Paul Nickerson via FreeIPA-users wrote:
I confirmed that users who had an ipaNTSecurityIdentifier attribute could log in to the web UI, and those that did not have the ipaNTSecurityIdentifier attribute could not.
I found the error in /var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors like you said: [17/Jan/2024:20:28:09.571195828 +0000] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 194]: Sidgen task starts ... [17/Jan/2024:20:28:09.637675948 +0000] - ERR - find_sid_for_ldap_entry - [file ipa_sidgen_common.c, line 522]: Cannot convert Posix ID [1566000023] into an unused SID. [17/Jan/2024:20:28:09.658369523 +0000] - ERR - do_work - [file ipa_sidgen_task.c, line 154]: Cannot add SID to existing entry. [17/Jan/2024:20:28:09.666726494 +0000] - ERR - sidgen_task_thread - [file ipa_sidgen_task.c, line 199]: Sidgen task finished [32].
I found some nice documentation at https://access.redhat.com/solutions/394763
I used this command to see the ranges that I have configured: ipa idrange-find
And these two commands to see the UIDs of the users who had not yet been given SIDs (some were inside the existing range; I think you're correct that the process stops at the first error): ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b "cn=users,cn=accounts,dc=semi,dc=example,dc=net" "(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v "# requesting: " | sed 's/uidNumber: //' | sort -n ldapsearch -H ldap://ipa01.semi.example.net:389/ -x -D "cn=Directory Manager" -W -b "cn=deleted users,cn=accounts,cn=provisioning,dc=semi,dc=example,dc=net" "(!(ipaNTSecurityIdentifier=*))" uidNumber | grep uidNumber | grep -v "# requesting: " | sed 's/uidNumber: //' | sort -n
Here's some documentation on what ID and RID ranges are for: https://www.freeipa.org/page/V3/ID_Ranges
After doing a bunch of math and guess and check, I ran this: ipa idrange-add SEMI.EXAMPLE.NET_US150777_range --base-id=1441400000 --range-size=531251000 --rid-base=101000000 --secondary-rid-base=633000000
That gave me an additional range (confirmed with ipa idrange-find). I ran ipa config-mod --enable-sid --add-sids again, saw no significant errors in /var/log/dirsrv/slapd-SEMI-EXAMPLE-NET/errors, and confirmed that there were 0 users left with no ipaNTSecurityIdentifier.
All users are all set now. Thank you again.
Glad to hear it and thank you for your detailed analysis. I think this will be useful to other users that may run into this.
rob -- _______________________________________________ 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
freeipa-users@lists.fedorahosted.org