Also, I just noticed this:

# ipa-replica-manage  dnarange-show
ipa02.hq.spinque.com: 1172150501-1172175499
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?


On Wed, 3 Jan 2024 at 11:22, Roberto Cornacchia <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> 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 <roberto@SUB.EXAMPLE.COM>
>Password for user@SUB.EXAMPLE.COM <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 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
><roberto@SUB.EXAMPLE.COM> for krbtgt/SUB.EXAMPLE.COM@SUB.EXAMPLE.COM,
>Additional pre-authentication required
>Dec 24 14:40:34 ipa01.sub.example.com krb5kdc[3324](info): closing down fd
>11
>Dec 24 14:40:51 ipa01.sub.example.com krb5kdc[3324](info): AS_REQ :
>handle_authdata (2)
>Dec 24 14:40:51 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>
>@SUB.EXAMPLE.COM <roberto@SUB.EXAMPLE.COM> for krbtgt/
>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 krb5kdc[3324](info): closing down fd
>11
>Dec 24 14:40:57 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 for krbtgt/
>SUB.EXAMPLE.COM@SUB.EXAMPLE.COM, Additional pre-authentication required
>Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): closing down fd
>11
>Dec 24 14:40:57 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 for
>krbtgt/SUB.EXAMPLE.COM@SUB.EXAMPLE.COM
>Dec 24 14:40:57 ipa01.sub.example.com krb5kdc[3324](info): closing down fd
>11
>Dec 24 14:40:57 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 for
>ldap/ipa02.sub.example.com@SUB.EXAMPLE.COM
>Dec 24 14:40:57 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