: 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(a)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>
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 <roberto(a)SUB.EXAMPLE.COM>
> >Password for user(a)SUB.EXAMPLE.COM <roberto(a)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(a)SUB.EXAMPLE.COM
> ><roberto(a)SUB.EXAMPLE.COM> for krbtgt/SUB.EXAMPLE.COM(a)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(a)SUB.EXAMPLE.COM>
> >(a)SUB.EXAMPLE.COM <roberto(a)SUB.EXAMPLE.COM> for krbtgt/
> >SUB.EXAMPLE.COM(a)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(a)SUB.EXAMPLE.COM for krbtgt/
> >SUB.EXAMPLE.COM(a)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(a)SUB.EXAMPLE.COM for
> >krbtgt/SUB.EXAMPLE.COM(a)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(a)SUB.EXAMPLE.COM for
> >ldap/ipa02.sub.example.com(a)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
>
>