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(a)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(a)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(a)SUB.EXAMPLE.COM
<mailto:user@SUB.EXAMPLE.COM> <roberto(a)SUB.EXAMPLE.COM
<mailto:roberto@SUB.EXAMPLE.COM>>
>Password for user(a)SUB.EXAMPLE.COM <mailto:user@SUB.EXAMPLE.COM>
<roberto(a)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(a)SUB.EXAMPLE.COM <mailto:user@SUB.EXAMPLE.COM>
><roberto(a)SUB.EXAMPLE.COM <mailto:roberto@SUB.EXAMPLE.COM>> for
krbtgt/SUB.EXAMPLE.COM(a)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(a)SUB.EXAMPLE.COM <mailto:roberto@SUB.EXAMPLE.COM>>
>(a)SUB.EXAMPLE.COM <
http://SUB.EXAMPLE.COM>
<roberto(a)SUB.EXAMPLE.COM <mailto:roberto@SUB.EXAMPLE.COM>> for
krbtgt/
>SUB.EXAMPLE.COM(a)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(a)SUB.EXAMPLE.COM
<mailto:ipa01.sub.example.com@SUB.EXAMPLE.COM> for krbtgt/
>SUB.EXAMPLE.COM(a)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(a)SUB.EXAMPLE.COM
<mailto:ipa01.sub.example.com@SUB.EXAMPLE.COM> for
>krbtgt/SUB.EXAMPLE.COM(a)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(a)SUB.EXAMPLE.COM
<mailto:ipa01.sub.example.com@SUB.EXAMPLE.COM> for
>ldap/ipa02.sub.example.com(a)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(a)lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-leave(a)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.fedoraho...
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue