BTW, from the currently used UIDs/GIDs you can clearly see that they have been assigned by two servers which administered 100K IDs each.
On Wed, 3 Jan 2024 at 15:30, Roberto Cornacchia < [email protected]> wrote: > Thanks Rob. > > This is the current situation (I added comma separators to make it more > readable) > > ################# > Domain range: > 117,200,000 - 117,200,999 > > currently used UIDs/GIDs: > 1,172,000,000 (admin) - 1,172,000,029 > 1,172,100,500 - 1,172,100,513 > > DNA ranges: > 1,172,150,501 - 1,172,175,499 > 1,172,175,501 - 1,172,199,999 > ################# > > I have no idea how it came to this. I am the only one busy with it and I > never change any defaults, at least not intentionally. > > The domain range seems to be really wrong, because though the digits are > similar it is an order of magnitude smaller. > The only reason I could think of is that at some point I was in the web > UI, on the range field, and I accidentally removed a trailing zero (and > saved, apparently). > Still, the range size should have been 200K while now it's 1000, that > cannot be a typo. > > Besides the domain range, the DNA ranges don't overlap either with the > currently used IDs. > > Could you please advise on what the best way to set this straight is? > > My intuition would be to leave the existing IDs alone and reset both the > domain range and the DNA ranges so that they cover the existing IDs, so: > > Domain range: 1,172,000,000 - 1,172,199,999 > > Is this the correct way? And would I then need to reset the DNA ranges > manually by splitting this in two, or is that done automatically somehow? > > Thanks, Roberto > > On Wed, 3 Jan 2024 at 14:34, Rob Crittenden <[email protected]> wrote: > >> Roberto Cornacchia via FreeIPA-users wrote: >> > Also, I just noticed this: >> > >> > # ipa-replica-manage dnarange-show >> > ipa02.hq.spinque.com <http://ipa02.hq.spinque.com>: >> 1172150501-1172175499 >> > ipa01.hq.spinque.com <http://ipa01.hq.spinque.com>: >> 1172175501-1172199999 >> > >> > while ipa idrange-find showed: >> > >> > ipabaseid: 117200000 >> > ipaidrangesize: 1000 >> > >> > These ranges are one order of magnitude far apart: >> > >> > 117200000 >> > 1172150501 >> > >> > I'm confused now. Shouldn't the two DNA ranges be the per-replica split >> > of the defined local domain ID range? >> >> Typically yes. We have no insight into your installation so can't really >> speculate. >> >> The ipa-local range should be immutable so I have no idea how that can >> be changed other than someone using ldapmodify directly. The >> initially-allocated range should be in the original >> /var/log/ipaserver-install.log if you still have that. >> >> The DNA ranges can be manually set so it's possible someone fat-fingered >> it at some point. I'd also suggest looking at the DNA next range to see >> if something is set. >> >> I'd suggest to start by looking at the current ids (both uid and gid) >> that have been issued and see what ranges they fall into. >> >> rob >> >> > >> > >> > On Wed, 3 Jan 2024 at 11:22, Roberto Cornacchia >> > <[email protected] <mailto:[email protected]>> >> wrote: >> > >> > Hi Alexander, >> > >> > Looking back at related messages, I've read a bunch of RedHat >> articles. >> > >> > I ran >> > >> > $ ipa config-mod --enable-sid --add-sids >> > >> > which did not return with failure but also did not add SIDs to >> users. >> > >> > Looking further, I understood that this fails because some UIDs and >> > GIDs are outside the defined ID range. >> > I don't really know how that happened, but apparently it did. >> > >> > I have finally landed on this article [1], which should help me fix >> > this and then I'll be able to try the SIDs generation again. >> > >> > If I look at the existing ID ranges, it looks like the primary range >> > is defined to be only 1000 IDs long: >> > >> > # ipa idrange-find --all --raw >> > ---------------- >> > 2 ranges matched >> > ---------------- >> > dn: >> > cn=HQ.SPINQUE.COM_id_range,cn=ranges,cn=etc,dc=hq,dc=spinque,dc=com >> > cn: HQ.SPINQUE.COM_id_range >> > ipabaseid: 117200000 >> > ipaidrangesize: 1000 >> > ipabaserid: 1000 >> > ipasecondarybaserid: 100000000 >> > iparangetype: ipa-local >> > objectclass: top >> > objectclass: ipaIDrange >> > objectclass: ipaDomainIDRange >> > >> > dn: >> > >> cn=HQ.SPINQUE.COM_subid_range,cn=ranges,cn=etc,dc=hq,dc=spinque,dc=com >> > cn: HQ.SPINQUE.COM_subid_range >> > ipabaseid: 2147483648 >> > ipaidrangesize: 2147352576 >> > ipabaserid: 2147482648 >> > ipanttrusteddomainsid: S-1-5-21-738065-838566-3901153701 >> > iparangetype: ipa-ad-trust >> > objectclass: top >> > objectclass: ipaIDrange >> > objectclass: ipaTrustedADDomainRange >> > >> > I seem to remember that the default range size is 200K, and I'm sure >> > I haven't reduced it myself. >> > >> > So my question, before trying to fix this, is: are you aware of this >> > happening for a reason, maybe during one of the upgrades? Can I >> > safely re-expand the range? >> > >> > Thanks for your support, Roberto >> > >> > [1] https://access.redhat.com/solutions/394763 >> > >> > On Tue, 2 Jan 2024 at 17:04, Alexander Bokovoy <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > On Аўт, 02 сту 2024, Roberto Cornacchia via FreeIPA-users wrote: >> > >Hi there, clients are having trouble with kerberos >> authentication: >> > > >> > >$ kinit -V user >> > >Using existing cache: xxxxxxxxxx:yyyyy >> > >Using principal: [email protected] >> > <mailto:[email protected]> <[email protected] >> > <mailto:[email protected]>> >> > >Password for [email protected] <mailto:[email protected] >> > >> > <[email protected] <mailto:[email protected]>>: >> > >kinit: Generic error (see e-text) while getting initial >> credentials >> > > >> > >On the ipa server, /var/log/krb5kdc.log says: >> > > >> > >Dec 24 14:40:34 ipa01.sub.example.com >> > <http://ipa01.sub.example.com> krb5kdc[3324](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)}) < >> > ><http://192.168.0.202/>IP>: NEEDED_PREAUTH: >> > [email protected] <mailto:[email protected]> >> > ><[email protected] <mailto:[email protected]>> for >> > krbtgt/[email protected] >> > <mailto:[email protected]>, >> > >Additional pre-authentication required >> > >Dec 24 14:40:34 ipa01.sub.example.com >> > <http://ipa01.sub.example.com> krb5kdc[3324](info): closing >> down fd >> > >11 >> > >Dec 24 14:40:51 ipa01.sub.example.com >> > <http://ipa01.sub.example.com> krb5kdc[3324](info): AS_REQ : >> > >handle_authdata (2) >> > >Dec 24 14:40:51 ipa01.sub.example.com >> > <http://ipa01.sub.example.com> krb5kdc[3324](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)}) < >> > ><http://192.168.0.202/>IP>: HANDLE_AUTHDATA: user >> > <[email protected] <mailto:[email protected]>> >> > >@SUB.EXAMPLE.COM <http://SUB.EXAMPLE.COM> >> > <[email protected] <mailto:[email protected]>> for >> > krbtgt/ >> > >[email protected] >> > <mailto:[email protected]>, No such file or >> directory >> > >> > ^^^ this means the user roberto has no SID assigned. Look into >> > numerous >> > discussions on this mailing list in 2023, there are plenty of >> > suggested >> > actions in those threads. >> > >> > >Dec 24 14:40:51 ipa01.sub.example.com >> > <http://ipa01.sub.example.com> krb5kdc[3324](info): closing >> down fd >> > >11 >> > >Dec 24 14:40:57 ipa01.sub.example.com >> > <http://ipa01.sub.example.com> krb5kdc[3324](info): AS_REQ (4 >> etypes >> > >{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), >> > >aes256-cts-hmac-sha384-192(20), >> aes128-cts-hmac-sha256-128(19)}) < >> > ><http://192.168.0.16/>IP>: NEEDED_PREAUTH: ldap/ >> > >[email protected] >> > <mailto:[email protected]> for krbtgt/ >> > >[email protected] >> > <mailto:[email protected]>, Additional >> > pre-authentication required >> > >Dec 24 14:40:57 ipa01.sub.example.com >> > <http://ipa01.sub.example.com> krb5kdc[3324](info): closing >> down fd >> > >11 >> > >Dec 24 14:40:57 ipa01.sub.example.com >> > <http://ipa01.sub.example.com> krb5kdc[3324](info): AS_REQ (4 >> etypes >> > >{aes256-cts-hmac-sha1-96(18), aes128-cts-hmac-sha1-96(17), >> > >aes256-cts-hmac-sha384-192(20), >> aes128-cts-hmac-sha256-128(19)}) < >> > ><http://192.168.0.16/>IP>: ISSUE: authtime 1703425257, etypes >> > >{rep=aes256-cts-hmac-sha1-96(18), >> tkt=aes256-cts-hmac-sha1-96(18), >> > >ses=aes256-cts-hmac-sha1-96(18)}, >> > >ldap/[email protected] >> > <mailto:[email protected]> for >> > >krbtgt/[email protected] >> > <mailto:[email protected]> >> > >Dec 24 14:40:57 ipa01.sub.example.com >> > <http://ipa01.sub.example.com> krb5kdc[3324](info): closing >> down fd >> > >11 >> > >Dec 24 14:40:57 ipa01.sub.example.com >> > <http://ipa01.sub.example.com> krb5kdc[3324](info): TGS_REQ (4 >> > >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)}) < >> > ><http://192.168.0.16/>IP>: ISSUE: authtime 1703425257, etypes >> > >{rep=aes256-cts-hmac-sha1-96(18), >> tkt=aes256-cts-hmac-sha1-96(18), >> > >ses=aes256-cts-hmac-sha1-96(18)}, >> > >ldap/[email protected] >> > <mailto:[email protected]> for >> > >ldap/[email protected] >> > <mailto:[email protected]> >> > >Dec 24 14:40:57 ipa01.sub.example.com >> > <http://ipa01.sub.example.com> krb5kdc[3324](info): closing >> down fd >> > >11 >> > > >> > >There are 2 ipa servers, ipa01 (Rocky 9.3, ipa 4.10.2) and >> > ipa02 (Rock 9.1, >> > >ipa4.10.0), both with CA and DNS. ipa02 is CRL master. >> > >On both, ipa-healthcheck doesn't find any issue. >> > > >> > >Also: kinit fails from within ipa01, succeeds from within >> ipa02. >> > > >> > >The issue seems to be in ipa01, and I have already tried to >> > reinstall it >> > >from scratch. One thing that is different is the version. >> > > >> > >Could you please help me figure out what's wrong? >> > > >> > >Best regards, >> > >Roberto >> > >> > >> > >> > >> > -- >> > / Alexander Bokovoy >> > Sr. Principal Software Engineer >> > Security / Identity Management Engineering >> > Red Hat Limited, Finland >> > >> > >> > -- >> > _______________________________________________ >> > FreeIPA-users mailing list -- [email protected] >> > To unsubscribe send an email to >> [email protected] >> > 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/[email protected] >> > Do not reply to spam, report it: >> https://pagure.io/fedora-infrastructure/new_issue >> > >> >>
-- _______________________________________________ FreeIPA-users mailing list -- [email protected] To unsubscribe send an email to [email protected] 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/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
