Rob, ldapmodify worked fine and after that I was able to generate all the missing SIDs, which solved my initial problem.
Thanks a lot! Roberto On Wed, 3 Jan 2024 at 15:54, Rob Crittenden <rcrit...@redhat.com> wrote: > Roberto Cornacchia wrote: > > 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 > > <roberto.cornacc...@gmail.com <mailto:roberto.cornacc...@gmail.com>> > 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. > > Thanks, the commas made this very gentle on my eyes :-) > > So there are several things to do. To reset to your original range > you'll need to modify LDAP directly because our tooling doesn't allow > the initial range to be changed (for the reason you're seeing, we just > never expected it to somehow get out of whack on its own). > > This will show you how to get and modify the range. My realm is > EXAMPLE.TEST and the domain is example.test. You'll need to modify to > your installation. > > $ kinit admin > $ ipa idrange-show --all --raw cn=EXAMPLE.TEST_id_range > dn: cn=EXAMPLE.TEST_id_range,cn=ranges,cn=etc,dc=example,dc=test > cn: EXAMPLE.TEST_id_range > ipabaseid: 1802400000 > ipaidrangesize: 200000 > ipabaserid: 1000 > ipasecondarybaserid: 100000000 > iparangetype: ipa-local > objectclass: top > objectclass: ipaIDrange > objectclass: ipaDomainIDRange > > $ ldapmodify -Y GSSAPI -Q > dn: cn=EXAMPLE.TEST_id_range,cn=ranges,cn=etc,dc=example,dc=test > changetype: modify > replace: ipaidrangesize > ipaidrangesize: 200000 > - > replace: ipabaseid > ipabaseid: 1172000000 > <empty line> > modifying entry > "cn=EXAMPLE.TEST_id_range,cn=ranges,cn=etc,dc=example,dc=test" > ^D to quit > > You can use ipa-replica-manage dnarange-set to manage the DNA ranges. > Typically it would be cut in half between the two servers assuming > entries are added on both. In short it isn't mandatory for every IPA > server to have a range, but since yours have one why not just split it. > > rob > > > > > 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 <rcrit...@redhat.com > > <mailto:rcrit...@redhat.com>> 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> > > <http://ipa02.hq.spinque.com>: 1172150501-1172175499 > > > ipa01.hq.spinque.com <http://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 > > > <roberto.cornacc...@gmail.com > > <mailto:roberto.cornacc...@gmail.com> > > <mailto:roberto.cornacc...@gmail.com > > <mailto:roberto.cornacc...@gmail.com>>> 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 > > <aboko...@redhat.com <mailto:aboko...@redhat.com> > > > <mailto:aboko...@redhat.com <mailto:aboko...@redhat.com>>> > > 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: u...@sub.example.com > > <mailto:u...@sub.example.com> > > > <mailto:u...@sub.example.com > > <mailto:u...@sub.example.com>> <robe...@sub.example.com > > <mailto:robe...@sub.example.com> > > > <mailto:robe...@sub.example.com > > <mailto:robe...@sub.example.com>>> > > > >Password for u...@sub.example.com > > <mailto:u...@sub.example.com> <mailto:u...@sub.example.com > > <mailto:u...@sub.example.com>> > > > <robe...@sub.example.com > > <mailto:robe...@sub.example.com> <mailto:robe...@sub.example.com > > <mailto:robe...@sub.example.com>>>: > > > >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> > > > <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: > > > u...@sub.example.com <mailto:u...@sub.example.com> > > <mailto:u...@sub.example.com <mailto:u...@sub.example.com>> > > > ><robe...@sub.example.com > > <mailto:robe...@sub.example.com> <mailto:robe...@sub.example.com > > <mailto:robe...@sub.example.com>>> for > > > krbtgt/sub.example....@sub.example.com > > <mailto:sub.example....@sub.example.com> > > > <mailto:sub.example....@sub.example.com > > <mailto:sub.example....@sub.example.com>>, > > > >Additional pre-authentication required > > > >Dec 24 14:40:34 ipa01.sub.example.com > > <http://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> > > > <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> > > > <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 > > > <robe...@sub.example.com > > <mailto:robe...@sub.example.com> <mailto:robe...@sub.example.com > > <mailto:robe...@sub.example.com>>> > > > >@SUB.EXAMPLE.COM <http://SUB.EXAMPLE.COM> > > <http://SUB.EXAMPLE.COM> > > > <robe...@sub.example.com > > <mailto:robe...@sub.example.com> <mailto:robe...@sub.example.com > > <mailto:robe...@sub.example.com>>> for > > > krbtgt/ > > > >sub.example....@sub.example.com > > <mailto:sub.example....@sub.example.com> > > > <mailto:sub.example....@sub.example.com > > <mailto:sub.example....@sub.example.com>>, 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> > > > <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> > > > <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/ > > > >ipa01.sub.example....@sub.example.com > > <mailto:ipa01.sub.example....@sub.example.com> > > > <mailto:ipa01.sub.example....@sub.example.com > > <mailto:ipa01.sub.example....@sub.example.com>> for krbtgt/ > > > >sub.example....@sub.example.com > > <mailto:sub.example....@sub.example.com> > > > <mailto:sub.example....@sub.example.com > > <mailto:sub.example....@sub.example.com>>, Additional > > > pre-authentication required > > > >Dec 24 14:40:57 ipa01.sub.example.com > > <http://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> > > > <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/ipa01.sub.example....@sub.example.com > > <mailto:ipa01.sub.example....@sub.example.com> > > > <mailto:ipa01.sub.example....@sub.example.com > > <mailto:ipa01.sub.example....@sub.example.com>> for > > > >krbtgt/sub.example....@sub.example.com > > <mailto:sub.example....@sub.example.com> > > > <mailto:sub.example....@sub.example.com > > <mailto:sub.example....@sub.example.com>> > > > >Dec 24 14:40:57 ipa01.sub.example.com > > <http://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> > > > <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/ipa01.sub.example....@sub.example.com > > <mailto:ipa01.sub.example....@sub.example.com> > > > <mailto:ipa01.sub.example....@sub.example.com > > <mailto:ipa01.sub.example....@sub.example.com>> for > > > >ldap/ipa02.sub.example....@sub.example.com > > <mailto:ipa02.sub.example....@sub.example.com> > > > <mailto:ipa02.sub.example....@sub.example.com > > <mailto:ipa02.sub.example....@sub.example.com>> > > > >Dec 24 14:40:57 ipa01.sub.example.com > > <http://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 -- > > freeipa-users@lists.fedorahosted.org > > <mailto:freeipa-users@lists.fedorahosted.org> > > > To unsubscribe send an email to > > freeipa-users-le...@lists.fedorahosted.org > > <mailto:freeipa-users-le...@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.fedorahosted.org > > > Do not reply to spam, report# ldapmodify -Y GSSAPI > SASL/GSSAPI authentication started > SASL username: ad...@example.test > SASL SSF: 256 > SASL data security layer installed. > dn: cn=EXAMPLE.TEST_id_range,cn=ranges,cn=etc,dc=example,dc=test > changetype: modify > replace: ipaidrangesize > ipaidrangesize: 1000 > > modifying entry > "cn=EXAMPLE.TEST_id_range,cn=ranges,cn=etc,dc=example,dc=test" > it: > > https://pagure.io/fedora-infrastructure/new_issue > > > > > > >
-- _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
