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.cornacchia(a)gmail.com <mailto:roberto.cornacchia@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 <rcritten(a)redhat.com
<mailto: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>
<
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.cornacchia(a)gmail.com
<mailto:roberto.cornacchia@gmail.com>
<mailto: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(a)redhat.com <mailto:abokovoy@redhat.com>
> <mailto: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(a)SUB.EXAMPLE.COM
<mailto:user@SUB.EXAMPLE.COM>
> <mailto:user@SUB.EXAMPLE.COM
<mailto:user@SUB.EXAMPLE.COM>> <roberto(a)SUB.EXAMPLE.COM
<mailto:roberto@SUB.EXAMPLE.COM>
> <mailto:roberto@SUB.EXAMPLE.COM
<mailto:roberto@SUB.EXAMPLE.COM>>>
> >Password for user(a)SUB.EXAMPLE.COM
<mailto:user@SUB.EXAMPLE.COM> <mailto:user@SUB.EXAMPLE.COM
<mailto:user@SUB.EXAMPLE.COM>>
> <roberto(a)SUB.EXAMPLE.COM
<mailto:roberto@SUB.EXAMPLE.COM> <mailto: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>
> <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>
<mailto:user@SUB.EXAMPLE.COM <mailto:user@SUB.EXAMPLE.COM>>
> ><roberto(a)SUB.EXAMPLE.COM
<mailto:roberto@SUB.EXAMPLE.COM> <mailto:roberto@SUB.EXAMPLE.COM
<mailto:roberto@SUB.EXAMPLE.COM>>> for
> krbtgt/SUB.EXAMPLE.COM(a)SUB.EXAMPLE.COM
<mailto:SUB.EXAMPLE.COM@SUB.EXAMPLE.COM>
> <mailto: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>
> <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
> <roberto(a)SUB.EXAMPLE.COM
<mailto:roberto@SUB.EXAMPLE.COM> <mailto:roberto@SUB.EXAMPLE.COM
<mailto:roberto@SUB.EXAMPLE.COM>>>
> >(a)SUB.EXAMPLE.COM <
http://SUB.EXAMPLE.COM>
<
http://SUB.EXAMPLE.COM>
> <roberto(a)SUB.EXAMPLE.COM
<mailto:roberto@SUB.EXAMPLE.COM> <mailto:roberto@SUB.EXAMPLE.COM
<mailto:roberto@SUB.EXAMPLE.COM>>> for
> krbtgt/
> >SUB.EXAMPLE.COM(a)SUB.EXAMPLE.COM
<mailto:SUB.EXAMPLE.COM@SUB.EXAMPLE.COM>
> <mailto: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>
> <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.com(a)SUB.EXAMPLE.COM
<mailto:ipa01.sub.example.com@SUB.EXAMPLE.COM>
> <mailto:ipa01.sub.example.com@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>
> <mailto: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>
> <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.com(a)SUB.EXAMPLE.COM
<mailto:ipa01.sub.example.com@SUB.EXAMPLE.COM>
> <mailto:ipa01.sub.example.com@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>
> <mailto: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>
> <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.com(a)SUB.EXAMPLE.COM
<mailto:ipa01.sub.example.com@SUB.EXAMPLE.COM>
> <mailto:ipa01.sub.example.com@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>
> <mailto: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>
> <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
<mailto:freeipa-users@lists.fedorahosted.org>
> To unsubscribe send an email to
freeipa-users-leave(a)lists.fedorahosted.org
<mailto: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.fedoraho...
> Do not reply to spam, report# ldapmodify -Y GSSAPI
SASL/GSSAPI
authentication started
SASL username: admin(a)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: