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 rcritten@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:
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 <roberto.cornacchia@gmail.com mailto:roberto.cornacchia@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 <abokovoy@redhat.com <mailto:abokovoy@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: user@SUB.EXAMPLE.COM <mailto:user@SUB.EXAMPLE.COM> <roberto@SUB.EXAMPLE.COM <mailto:roberto@SUB.EXAMPLE.COM>> >Password for user@SUB.EXAMPLE.COM <mailto:user@SUB.EXAMPLE.COM> <roberto@SUB.EXAMPLE.COM <mailto:roberto@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> 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: user@SUB.EXAMPLE.COM <mailto:user@SUB.EXAMPLE.COM> ><roberto@SUB.EXAMPLE.COM <mailto:roberto@SUB.EXAMPLE.COM>> for krbtgt/SUB.EXAMPLE.COM@SUB.EXAMPLE.COM <mailto:SUB.EXAMPLE.COM@SUB.EXAMPLE.COM>, >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 <roberto@SUB.EXAMPLE.COM <mailto:roberto@SUB.EXAMPLE.COM>> >@SUB.EXAMPLE.COM <http://SUB.EXAMPLE.COM> <roberto@SUB.EXAMPLE.COM <mailto:roberto@SUB.EXAMPLE.COM>> for krbtgt/ >SUB.EXAMPLE.COM@SUB.EXAMPLE.COM <mailto:SUB.EXAMPLE.COM@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> 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/ >ipa01.sub.example.com@SUB.EXAMPLE.COM <mailto:ipa01.sub.example.com@SUB.EXAMPLE.COM> for krbtgt/ >SUB.EXAMPLE.COM@SUB.EXAMPLE.COM <mailto:SUB.EXAMPLE.COM@SUB.EXAMPLE.COM>, 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/ipa01.sub.example.com@SUB.EXAMPLE.COM <mailto:ipa01.sub.example.com@SUB.EXAMPLE.COM> for >krbtgt/SUB.EXAMPLE.COM@SUB.EXAMPLE.COM <mailto:SUB.EXAMPLE.COM@SUB.EXAMPLE.COM> >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/ipa01.sub.example.com@SUB.EXAMPLE.COM <mailto:ipa01.sub.example.com@SUB.EXAMPLE.COM> for >ldap/ipa02.sub.example.com@SUB.EXAMPLE.COM <mailto:ipa02.sub.example.com@SUB.EXAMPLE.COM> >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 -- 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: