[Freeipa-users] Re: krb5kdc: No such file or directory

2024-01-03 Thread Roberto Cornacchia via FreeIPA-users 
Rob,

ldapmodify worked fine and after that I was able to generate all the
missing SIDs, which solved my initial problem.

Thanks a lot!
Roberto

On Wed, 3 Jan 2024 at 15:54, Rob Crittenden  wrote:

> Roberto Cornacchia wrote:
> > 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
> > mailto:roberto.cornacc...@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: 180240
>   ipaidrangesize: 20
>   ipabaserid: 1000
>   ipasecondarybaserid: 1
>   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: 20
> -
> replace: ipabaseid
> ipabaseid: 117200
> 
> 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  > > wrote:
> >
> > Roberto Cornacchia via FreeIPA-users wrote:
> > > Also, I just noticed this:
> > >
> > > # ipa-replica-manage  dnarange-show
> > > ipa02.hq.spinque.com 
> > : 1172150501-1172175499
> > > ipa01.hq.spinque.com 
> > : 1172175501-117219
> > >
> > > while ipa idrange-find showed:
> > >
> > >   ipabaseid: 11720
> > >   ipaidrangesize: 1000
> > >
> > > These ranges are one order of magnitude far apart:
> > >
> > > 11720
> > > 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
> >

[Freeipa-users] Re: krb5kdc: No such file or directory

2024-01-03 Thread Rob Crittenden via FreeIPA-users 
Roberto Cornacchia wrote:
> 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
> mailto:roberto.cornacc...@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: 180240
  ipaidrangesize: 20
  ipabaserid: 1000
  ipasecondarybaserid: 1
  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: 20
-
replace: ipabaseid
ipabaseid: 117200

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  > wrote:
> 
> Roberto Cornacchia via FreeIPA-users wrote:
> > Also, I just noticed this:
> >
> > # ipa-replica-manage  dnarange-show
> > ipa02.hq.spinque.com 
> : 1172150501-1172175499
> > ipa01.hq.spinque.com 
> : 1172175501-117219
> >
> > while ipa idrange-find showed:
> >
> >   ipabaseid: 11720
> >   ipaidrangesize: 1000
> >
> > These ranges are one order of magnitude far apart:
> >
> > 11720
> > 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

[Freeipa-users] Re: krb5kdc: No such file or directory

2024-01-03 Thread Roberto Cornacchia via FreeIPA-users 
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.cornacc...@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.
>
> 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  wrote:
>
>> Roberto Cornacchia via FreeIPA-users wrote:
>> > Also, I just noticed this:
>> >
>> > # ipa-replica-manage  dnarange-show
>> > ipa02.hq.spinque.com :
>> 1172150501-1172175499
>> > ipa01.hq.spinque.com :
>> 1172175501-117219
>> >
>> > while ipa idrange-find showed:
>> >
>> >   ipabaseid: 11720
>> >   ipaidrangesize: 1000
>> >
>> > These ranges are one order of magnitude far apart:
>> >
>> > 11720
>> > 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
>> > mailto:roberto.cornacc...@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: 11720
>> >   ipaidrangesize: 1000
>> >   ipabaserid: 1000
>> >   ipasecondarybaserid: 1
>> >   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

[Freeipa-users] Re: krb5kdc: No such file or directory

2024-01-03 Thread Roberto Cornacchia via FreeIPA-users 
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  wrote:

> Roberto Cornacchia via FreeIPA-users wrote:
> > Also, I just noticed this:
> >
> > # ipa-replica-manage  dnarange-show
> > ipa02.hq.spinque.com :
> 1172150501-1172175499
> > ipa01.hq.spinque.com :
> 1172175501-117219
> >
> > while ipa idrange-find showed:
> >
> >   ipabaseid: 11720
> >   ipaidrangesize: 1000
> >
> > These ranges are one order of magnitude far apart:
> >
> > 11720
> > 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
> > mailto:roberto.cornacc...@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: 11720
> >   ipaidrangesize: 1000
> >   ipabaserid: 1000
> >   ipasecondarybaserid: 1
> >   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  > > wrote:
>

[Freeipa-users] Re: krb5kdc: No such file or directory

2024-01-03 Thread Rob Crittenden via FreeIPA-users 
Roberto Cornacchia via FreeIPA-users wrote:
> Also, I just noticed this:
> 
> # ipa-replica-manage  dnarange-show
> ipa02.hq.spinque.com : 1172150501-1172175499
> ipa01.hq.spinque.com : 1172175501-117219
> 
> while ipa idrange-find showed:
> 
>   ipabaseid: 11720
>   ipaidrangesize: 1000
> 
> These ranges are one order of magnitude far apart:
> 
> 11720
> 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
> mailto:roberto.cornacc...@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: 11720
>   ipaidrangesize: 1000
>   ipabaserid: 1000
>   ipasecondarybaserid: 1
>   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  > 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: xx:y
> >Using principal: u...@sub.example.com
>   >
> >Password for u...@sub.example.com 
> mailto:robe...@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)}) <
> >IP>: NEEDED_PREAUTH:
> u...@sub.example.com 
> >mailto:robe...@sub.example.com>> for
> krbtgt/sub.example@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)
>

[Freeipa-users] Re: krb5kdc: No such file or directory

2024-01-03 Thread Roberto Cornacchia via FreeIPA-users 
Also, I just noticed this:

# ipa-replica-manage  dnarange-show
ipa02.hq.spinque.com: 1172150501-1172175499
ipa01.hq.spinque.com: 1172175501-117219

while ipa idrange-find showed:

  ipabaseid: 11720
  ipaidrangesize: 1000

These ranges are one order of magnitude far apart:

11720
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.cornacc...@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: 11720
>   ipaidrangesize: 1000
>   ipabaserid: 1000
>   ipasecondarybaserid: 1
>   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 
> 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: xx:y
>> >Using principal: u...@sub.example.com 
>> >Password for u...@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)}) <
>> >IP>: NEEDED_PREAUTH: u...@sub.example.com
>> > for krbtgt/sub.example@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)}) <
>> >IP>: HANDLE_AUTHDATA: user <
>> robe...@sub.example.com>
>> >@SUB.EXAMPLE.COM  for krbtgt/
>> >sub.example@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)}) <
>> >IP>: NEEDED_PREAUTH: ldap/
>> >ipa01.sub.example@sub.example.com for krbtgt/
>> >sub.example@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)}) <
>> >IP>: ISSUE: authtime 1703425257, etypes
>> >{rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18),
>>

[Freeipa-users] Re: krb5kdc: No such file or directory

2024-01-03 Thread Roberto Cornacchia via FreeIPA-users 
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: 11720
  ipaidrangesize: 1000
  ipabaserid: 1000
  ipasecondarybaserid: 1
  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  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: xx:y
> >Using principal: u...@sub.example.com 
> >Password for u...@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)}) <
> >IP>: NEEDED_PREAUTH: u...@sub.example.com
> > for krbtgt/sub.example@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)}) <
> >IP>: HANDLE_AUTHDATA: user <
> robe...@sub.example.com>
> >@SUB.EXAMPLE.COM  for krbtgt/
> >sub.example@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)}) <
> >IP>: NEEDED_PREAUTH: ldap/
> >ipa01.sub.example@sub.example.com for krbtgt/
> >sub.example@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)}) <
> >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@sub.example.com for
> >krbtgt/sub.example@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)}) <
> >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@sub.example.com for
>

[Freeipa-users] Re: krb5kdc: No such file or directory

2024-01-02 Thread Roberto Cornacchia via FreeIPA-users 
Hi Alexander,

Thanks for the quick reply, I will look into that.

Roberto

On Tue, 2 Jan 2024 at 17:04, Alexander Bokovoy  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: xx:y
> >Using principal: u...@sub.example.com 
> >Password for u...@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)}) <
> >IP>: NEEDED_PREAUTH: u...@sub.example.com
> > for krbtgt/sub.example@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)}) <
> >IP>: HANDLE_AUTHDATA: user <
> robe...@sub.example.com>
> >@SUB.EXAMPLE.COM  for krbtgt/
> >sub.example@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)}) <
> >IP>: NEEDED_PREAUTH: ldap/
> >ipa01.sub.example@sub.example.com for krbtgt/
> >sub.example@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)}) <
> >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@sub.example.com for
> >krbtgt/sub.example@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)}) <
> >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@sub.example.com for
> >ldap/ipa02.sub.example@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
>
>
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: krb5kdc: No such file or directory

2024-01-02 Thread Alexander Bokovoy via FreeIPA-users 

On Аўт, 02 сту 2024, Roberto Cornacchia via FreeIPA-users wrote:

Hi there, clients are having trouble with kerberos authentication:

$ kinit -V user
Using existing cache: xx:y
Using principal: u...@sub.example.com 
Password for u...@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)}) <
IP>: NEEDED_PREAUTH: u...@sub.example.com
 for krbtgt/sub.example@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)}) <
IP>: HANDLE_AUTHDATA: user 
@SUB.EXAMPLE.COM  for krbtgt/
sub.example@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)}) <
IP>: NEEDED_PREAUTH: ldap/
ipa01.sub.example@sub.example.com for krbtgt/
sub.example@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)}) <
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@sub.example.com for
krbtgt/sub.example@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)}) <
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@sub.example.com for
ldap/ipa02.sub.example@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
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@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.fedorahosted.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[Freeipa-users] Re: krb5kdc: No such file or directory

2024-01-02 Thread Roberto Cornacchia via FreeIPA-users 
Restarting krb5kdc doesn't help, and although it restarts, it complains
about /run/krb5kdc.pid.

[ipa01 ~]# systemctl restart krb5kdc
[ipa01 ~]# systemctl status krb5kdc
● krb5kdc.service - Kerberos 5 KDC
 Loaded: loaded (/usr/lib/systemd/system/krb5kdc.service; disabled;
preset: disabled)
 Active: active (running) since Tue 2024-01-02 16:45:10 CET; 8s ago
Process: 43349 ExecStart=/usr/sbin/krb5kdc -P /run/krb5kdc.pid
$KRB5KDC_ARGS (code=exited, status=0/SUCCESS)
   Main PID: 43351 (krb5kdc)
  Tasks: 3 (limit: 48859)
 Memory: 6.6M
CPU: 70ms
 CGroup: /system.slice/krb5kdc.service
 ├─43351 /usr/sbin/krb5kdc -P /run/krb5kdc.pid -w 2
 ├─43352 /usr/sbin/krb5kdc -P /run/krb5kdc.pid -w 2
 └─43353 /usr/sbin/krb5kdc -P /run/krb5kdc.pid -w 2

Jan 02 16:45:09 ipa01.hq.spinque.com systemd[1]: Starting Kerberos 5 KDC...
Jan 02 16:45:10 ipa01.hq.spinque.com systemd[1]: krb5kdc.service: Can't
open PID file /run/krb5kdc.pid (yet?) after start: Operation not permitted
Jan 02 16:45:10 ipa01.hq.spinque.com systemd[1]: Started Kerberos 5 KDC.

[ipa01 ~]# ll /run/krb5kdc.pid
-rw-r--r--. 1 root root 6 Jan  2 16:45 /run/krb5kdc.pid

[ipa01 ~]# kinit roberto
Password for robe...@hq.spinque.com:
kinit: Generic error (see e-text) while getting initial credentials


On Tue, 2 Jan 2024 at 16:19, Roberto Cornacchia <
roberto.cornacc...@gmail.com> wrote:

> Hi there, clients are having trouble with kerberos authentication:
>
> $ kinit -V user
> Using existing cache: xx:y
> Using principal: u...@sub.example.com 
> Password for u...@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)}) <
> IP>: NEEDED_PREAUTH: u...@sub.example.com
>  for krbtgt/sub.example@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)}) <
> IP>: HANDLE_AUTHDATA: user
> @SUB.EXAMPLE.COM  for
> krbtgt/sub.example@sub.example.com, No such file or directory
> 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)}) <
> IP>: NEEDED_PREAUTH: ldap/
> ipa01.sub.example@sub.example.com for krbtgt/
> sub.example@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)}) <
> 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@sub.example.com for krbtgt/
> sub.example@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)}) <
> 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@sub.example.com for ldap/
> ipa02.sub.example@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
>
--
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To