Re: Using ipa-ca-install on a replica

[Ian Kumlien]

On Wed, Mar 20, 2024 at 3:52 PM Ian Kumlien  wrote:
> On Wed, Mar 20, 2024 at 11:21 AM Florence Blanc-Renaud  wrote:
> > Hi,
> >
> > On Wed, Mar 20, 2024 at 10:00 AM Ian Kumlien  wrote:
> > > On Wed, Mar 20, 2024 at 9:45 AM Ian Kumlien  wrote:
> > > > So... this one's new:
> > > >
> > > > Connection to https://freeipa-1.xerces.lan/ipa/json failed with
> > > > Insufficient access: SASL(-1): generic failure: GSSAPI Error:
> > > > Unspecified GSS failure.  Minor code may provide more information
> > > > (Credential cache is empty)
> >
> > this one can happen if you have an existing ticket in your cache, for instance from a previous installation, but that is not valid anymore.
>
> Ah, ok, i did do kdestroy -A but only on the new machine...
>
> A new issue that appeared, no user from the old machines can
> authenticate at all - still looking in to why it doesn't work

Disabling MS-PAC fixed this issue, will have to dig in to why it was later =)

Any clues?
> > flo
> > > > Just haven't seen it before... and it seems like the replica can't
> > > > install, unlike the two that worked before...
> > >
> > > And all of the sudden it just works again... weird...

Using ipa-ca-install on a replica

[Florence Renaud]

> On 20 Mar 2024, at 16:38, Ian Kumlien  wrote:
>
> On Wed, Mar 20, 2024 at 3:52 PM Ian Kumlien  wrote:
> > > On Wed, Mar 20, 2024 at 11:21 AM Florence Blanc-Renaud  wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Mar 20, 2024 at 10:00 AM Ian Kumlien  wrote:
> > > > On Wed, Mar 20, 2024 at 9:45 AM Ian Kumlien  wrote:
> > > > > So... this one's new:
> > > > >
> > > > > Connection to https://freeipa-1.xerces.lan/ipa/json failed with
> > > > > Insufficient access: SASL(-1): generic failure: GSSAPI Error:
> > > > > Unspecified GSS failure.  Minor code may provide more information
> > > > > (Credential cache is empty)
> > >
> > > this one can happen if you have an existing ticket in your cache, for instance from a previous installation, but that is not valid anymore.
> >
> > Ah, ok, i did do kdestroy -A but only on the new machine...
> >
> > A new issue that appeared, no user from the old machines can
> > authenticate at all - still looking in to why it doesn't work
>
> Disabling MS-PAC fixed this issue, will have to dig in to why it was later =)
>
> Any clues?

Your users are probably missing a SID. Run ipa config-mod —enable-sid —add-sids and check with ipa user-show —all —raw that they contain an ipantsecurityidentifier attribute.

HTH,
flo
> > > flo
> > > > > Just haven't seen it before... and it seems like the replica can't
> > > > > install, unlike the two that worked before...
> > > >
> > > > And all of the sudden it just works again... weird...

Using ipa-ca-install on a replica

[Ian Kumlien]

On Wed, Mar 20, 2024 at 9:52 PM Florence Renaud  wrote:
> > On 20 Mar 2024, at 16:38, Ian Kumlien  wrote:
> >
> > On Wed, Mar 20, 2024 at 3:52 PM Ian Kumlien  wrote:
> > > > On Wed, Mar 20, 2024 at 11:21 AM Florence Blanc-Renaud  wrote:
> > > >
> > > > Hi,
> > > >
> > > > On Wed, Mar 20, 2024 at 10:00 AM Ian Kumlien  wrote:
> > > > > On Wed, Mar 20, 2024 at 9:45 AM Ian Kumlien  wrote:
> > > > > > So... this one's new:
> > > > > >
> > > > > > Connection to https://freeipa-1.xerces.lan/ipa/json failed with
> > > > > > Insufficient access: SASL(-1): generic failure: GSSAPI Error:
> > > > > > Unspecified GSS failure.  Minor code may provide more information
> > > > > > (Credential cache is empty)
> > > >
> > > > this one can happen if you have an existing ticket in your cache, for instance from a previous installation, but that is not valid anymore.
> > >
> > > Ah, ok, i did do kdestroy -A but only on the new machine...
> > >
> > > A new issue that appeared, no user from the old machines can
> > > authenticate at all - still looking in to why it doesn't work
> >
> > Disabling MS-PAC fixed this issue, will have to dig in to why it was later =)
> >
> > Any clues?
>
> Your users are probably missing a SID. Run ipa config-mod —enable-sid —add-sids and check with ipa user-show —all —raw that they contain an ipantsecurityidentifier attribute.

Uhm, nope, changed nothing it seems... leaving ms-pac disabled works however
> HTH,
> flo
> > > > flo
> > > > > > Just haven't seen it before... and it seems like the replica can't
> > > > > > install, unlike the two that worked before...
> > > > >
> > > > > And all of the sudden it just works again... weird...

Using ipa-ca-install on a replica

[Alexander Bokovoy]

On Чцв, 21 сак 2024, Ian Kumlien via FreeIPA-users wrote:
> On Wed, Mar 20, 2024 at 9:52 PM Florence Renaud  wrote:
> > > On 20 Mar 2024, at 16:38, Ian Kumlien  wrote:
> > >
> > > On Wed, Mar 20, 2024 at 3:52 PM Ian Kumlien  wrote:
> > > > > On Wed, Mar 20, 2024 at 11:21 AM Florence Blanc-Renaud  wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > On Wed, Mar 20, 2024 at 10:00 AM Ian Kumlien  wrote:
> > > > > > On Wed, Mar 20, 2024 at 9:45 AM Ian Kumlien  wrote:
> > > > > > >
> > > > > > > So... this one's new:
> > > > > > >
> > > > > > > Connection to https://freeipa-1.xerces.lan/ipa/json failed with
> > > > > > > Insufficient access: SASL(-1): generic failure: GSSAPI Error:
> > > > > > > Unspecified GSS failure.  Minor code may provide more information
> > > > > > > (Credential cache is empty)
> > > > >
> > > > > this one can happen if you have an existing ticket in your cache, for instance from a previous installation, but that is not valid anymore.
> > > >
> > > > Ah, ok, i did do kdestroy -A but only on the new machine...
> > > >
> > > > A new issue that appeared, no user from the old machines can
> > > > authenticate at all - still looking in to why it doesn't work
> > >
> > > Disabling MS-PAC fixed this issue, will have to dig in to why it was later =)
> > >
> > > Any clues?
> >
> > Your users are probably missing a SID. Run ipa config-mod —enable-sid —add-sids and check with ipa user-show —all —raw that they contain an ipantsecurityidentifier attribute.
>
> Uhm, nope, changed nothing it seems... leaving ms-pac disabled works however

There were plenty of discussions on this list in past couple months,
including a lot of instructions what to investigate. Have you tried to
apply those suggestions?

You haven't shown a single log excerpt from IPA servers, be it
/var/log/krb5kdc.log or error logs from the directory server.

Disabling MS-PAC basically kills protection mechanisms that we have
against a numerous breaches using Kerberos protocol's issues.

Using ipa-ca-install on a replica

[Ian Kumlien]

On Thu, Mar 21, 2024 at 9:13 AM Alexander Bokovoy  wrote:
> On Чцв, 21 сак 2024, Ian Kumlien via FreeIPA-users wrote:
> > On Wed, Mar 20, 2024 at 9:52 PM Florence Renaud  wrote:
> > > > On 20 Mar 2024, at 16:38, Ian Kumlien  wrote:
> > > >
> > > > On Wed, Mar 20, 2024 at 3:52 PM Ian Kumlien  wrote:
> > > > > > On Wed, Mar 20, 2024 at 11:21 AM Florence Blanc-Renaud  wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > On Wed, Mar 20, 2024 at 10:00 AM Ian Kumlien  wrote:
> > > > > > >
> > > > > > > On Wed, Mar 20, 2024 at 9:45 AM Ian Kumlien  wrote:
> > > > > > >>
> > > > > > >> So... this one's new:
> > > > > > >>
> > > > > > >> Connection to https://freeipa-1.xerces.lan/ipa/json failed with
> > > > > > >> Insufficient access: SASL(-1): generic failure: GSSAPI Error:
> > > > > > >> Unspecified GSS failure.  Minor code may provide more information
> > > > > > >> (Credential cache is empty)
> > > > > >
> > > > > > this one can happen if you have an existing ticket in your cache, for instance from a previous installation, but that is not valid anymore.
> > > > >
> > > > > Ah, ok, i did do kdestroy -A but only on the new machine...
> > > > >
> > > > > A new issue that appeared, no user from the old machines can
> > > > > authenticate at all - still looking in to why it doesn't work
> > > >
> > > > Disabling MS-PAC fixed this issue, will have to dig in to why it was later =)
> > > >
> > > > Any clues?
> > >
> > > Your users are probably missing a SID. Run ipa config-mod —enable-sid —add-sids and check with ipa user-show —all —raw that they contain an ipantsecurityidentifier attribute.
> >
> > Uhm, nope, changed nothing it seems... leaving ms-pac disabled works however
>
> There were plenty of discussions on this list in past couple months,
> including a lot of instructions what to investigate. Have you tried to
> apply those suggestions?

I haven't found any using google...
> You haven't shown a single log excerpt from IPA servers, be it
> /var/log/krb5kdc.log or error logs from the directory server.

And i haven't been asked - i assumed it was something due to the upgrade path

Doing kerberos results in:
Mar 20 16:18:29 freeipa-4.xerces.lan krb5kdc[113624](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)}) 10.129.0.239: HANDLE_AUTHDATA:
[e-mail] for krbtgt/[e-mail], No such file or
directory

For ldap authentication, which also fails with ms-pac enabled, i
haven't been able to find any real log with issues.
(So, with ms-pac, things that fails for a user: kerberos, ldap,
freeipa webui. Without ms-pac, everything works)

We don't really use kerberos atm, so potentially leaving it disabled
could be fine, however i would much more like to get to the bottom of
this...
> Disabling MS-PAC basically kills protection mechanisms that we have
> against a numerous breaches using Kerberos protocol's issues.
>
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland

Using ipa-ca-install on a replica

[Ian Kumlien]

So update, the one user that works when ms-pac is enabled has a
ipantsecurityidentifier but no other user has that.

ipa config-mod --enable-sid --add-sids did not fix this for some reason

On Thu, Mar 21, 2024 at 9:36 AM Ian Kumlien  wrote:
> On Thu, Mar 21, 2024 at 9:13 AM Alexander Bokovoy  wrote:
> > On Чцв, 21 сак 2024, Ian Kumlien via FreeIPA-users wrote:
> > > On Wed, Mar 20, 2024 at 9:52 PM Florence Renaud  wrote:
> > > > > On 20 Mar 2024, at 16:38, Ian Kumlien  wrote:
> > > > >
> > > > > On Wed, Mar 20, 2024 at 3:52 PM Ian Kumlien  wrote:
> > > > > > > On Wed, Mar 20, 2024 at 11:21 AM Florence Blanc-Renaud  wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Wed, Mar 20, 2024 at 10:00 AM Ian Kumlien  wrote:
> > > > > > >>
> > > > > > >> On Wed, Mar 20, 2024 at 9:45 AM Ian Kumlien  wrote:
> > > > > > >>>
> > > > > > >>> So... this one's new:
> > > > > > >>>
> > > > > > >>> Connection to https://freeipa-1.xerces.lan/ipa/json failed with
> > > > > > >>> Insufficient access: SASL(-1): generic failure: GSSAPI Error:
> > > > > > >>> Unspecified GSS failure.  Minor code may provide more information
> > > > > > >>> (Credential cache is empty)
> > > > > > >
> > > > > > >
> > > > > > > this one can happen if you have an existing ticket in your cache, for instance from a previous installation, but that is not valid anymore.
> > > > > >
> > > > > > Ah, ok, i did do kdestroy -A but only on the new machine...
> > > > > >
> > > > > > A new issue that appeared, no user from the old machines can
> > > > > > authenticate at all - still looking in to why it doesn't work
> > > > >
> > > > > Disabling MS-PAC fixed this issue, will have to dig in to why it was later =)
> > > > >
> > > > > Any clues?
> > > >
> > > > Your users are probably missing a SID. Run ipa config-mod —enable-sid —add-sids and check with ipa user-show —all —raw that they contain an ipantsecurityidentifier attribute.
> > >
> > > Uhm, nope, changed nothing it seems... leaving ms-pac disabled works however
> >
> > There were plenty of discussions on this list in past couple months,
> > including a lot of instructions what to investigate. Have you tried to
> > apply those suggestions?
>
> I haven't found any using google...
> > You haven't shown a single log excerpt from IPA servers, be it
> > /var/log/krb5kdc.log or error logs from the directory server.
>
> And i haven't been asked - i assumed it was something due to the upgrade path
>
> Doing kerberos results in:
> Mar 20 16:18:29 freeipa-4.xerces.lan krb5kdc[113624](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)}) 10.129.0.239: HANDLE_AUTHDATA:
> [e-mail] for krbtgt/[e-mail], No such file or
> directory
>
> For ldap authentication, which also fails with ms-pac enabled, i
> haven't been able to find any real log with issues.
> (So, with ms-pac, things that fails for a user: kerberos, ldap,
> freeipa webui. Without ms-pac, everything works)
>
> We don't really use kerberos atm, so potentially leaving it disabled
> could be fine, however i would much more like to get to the bottom of
> this...
> > Disabling MS-PAC basically kills protection mechanisms that we have
> > against a numerous breaches using Kerberos protocol's issues.
> >
> > --
> > / Alexander Bokovoy
> > Sr. Principal Software Engineer
> > Security / Identity Management Engineering
> > Red Hat Limited, Finland

Using ipa-ca-install on a replica

[Alexander Bokovoy]

On Чцв, 21 сак 2024, Ian Kumlien wrote:
> On Thu, Mar 21, 2024 at 9:13 AM Alexander Bokovoy  wrote:
> > On Чцв, 21 сак 2024, Ian Kumlien via FreeIPA-users wrote:
> > > On Wed, Mar 20, 2024 at 9:52 PM Florence Renaud  wrote:
> > > > > On 20 Mar 2024, at 16:38, Ian Kumlien  wrote:
> > > > >
> > > > > On Wed, Mar 20, 2024 at 3:52 PM Ian Kumlien  wrote:
> > > > > > > On Wed, Mar 20, 2024 at 11:21 AM Florence Blanc-Renaud  wrote:
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > On Wed, Mar 20, 2024 at 10:00 AM Ian Kumlien  wrote:
> > > > > > >>
> > > > > > >> On Wed, Mar 20, 2024 at 9:45 AM Ian Kumlien  wrote:
> > > > > > >>>
> > > > > > >>> So... this one's new:
> > > > > > >>>
> > > > > > >>> Connection to https://freeipa-1.xerces.lan/ipa/json failed with
> > > > > > >>> Insufficient access: SASL(-1): generic failure: GSSAPI Error:
> > > > > > >>> Unspecified GSS failure.  Minor code may provide more information
> > > > > > >>> (Credential cache is empty)
> > > > > > >
> > > > > > >
> > > > > > > this one can happen if you have an existing ticket in your cache, for instance from a previous installation, but that is not valid anymore.
> > > > > >
> > > > > > Ah, ok, i did do kdestroy -A but only on the new machine...
> > > > > >
> > > > > > A new issue that appeared, no user from the old machines can
> > > > > > authenticate at all - still looking in to why it doesn't work
> > > > >
> > > > > Disabling MS-PAC fixed this issue, will have to dig in to why it was later =)
> > > > >
> > > > > Any clues?
> > > >
> > > > Your users are probably missing a SID. Run ipa config-mod —enable-sid —add-sids and check with ipa user-show —all —raw that they contain an ipantsecurityidentifier attribute.
> > >
> > > Uhm, nope, changed nothing it seems... leaving ms-pac disabled works however
> >
> > There were plenty of discussions on this list in past couple months,
> > including a lot of instructions what to investigate. Have you tried to
> > apply those suggestions?
>
> I haven't found any using google...
> > You haven't shown a single log excerpt from IPA servers, be it
> > /var/log/krb5kdc.log or error logs from the directory server.
>
> And i haven't been asked - i assumed it was something due to the upgrade path
>
> Doing kerberos results in:
> Mar 20 16:18:29 freeipa-4.xerces.lan krb5kdc[113624](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)}) 10.129.0.239: HANDLE_AUTHDATA:
> [e-mail] for krbtgt/[e-mail], No such file or
> directory
>
> For ldap authentication, which also fails with ms-pac enabled, i
> haven't been able to find any real log with issues.
> (So, with ms-pac, things that fails for a user: kerberos, ldap,
> freeipa webui. Without ms-pac, everything works)
>
> We don't really use kerberos atm, so potentially leaving it disabled
> could be fine, however i would much more like to get to the bottom of
> this...

This is from one of previous emails I sent here:

-----------------------------------------------------------------------
Basically, I think you have users with UID/GIDs outside of your ID
ranges and therefore those users have no SIDs associated with them and
hence cannot be used for constrained delegation (S4U extensions in
Kerberos) anymore. In addition, most likely your existing ID ranges have
no support for generating SIDs as they most likely lack RID bases.

There were plenty of discussions about it on the list in past few
months. You can look at these articles on the Red Hat's Customer Portal:

https://access.redhat.com/articles/7027037
https://access.redhat.com/solutions/7052703
https://access.redhat.com/solutions/7014959
-----------------------------------------------------------------------

For your case, look first at the KCS 7052703, as it has collection of
the instructions to use for different typical use cases. Article 7027037
is a good visualisation of the ID range structure and requirements to
SID bases.

All those articles are accessible with RHEL subscription. You can get a
free subscription at https://developers.redhat.com/.

Using ipa-ca-install on a replica

[Ian Kumlien]

On Thu, Mar 21, 2024 at 10:22 AM Alexander Bokovoy  wrote:
> On Чцв, 21 сак 2024, Ian Kumlien wrote:
> > On Thu, Mar 21, 2024 at 9:13 AM Alexander Bokovoy  wrote:
> > > On Чцв, 21 сак 2024, Ian Kumlien via FreeIPA-users wrote:
> > > > On Wed, Mar 20, 2024 at 9:52 PM Florence Renaud  wrote:
> > > > > > On 20 Mar 2024, at 16:38, Ian Kumlien  wrote:
> > > > > >
> > > > > > On Wed, Mar 20, 2024 at 3:52 PM Ian Kumlien  wrote:
> > > > > > >
> > > > > > >> On Wed, Mar 20, 2024 at 11:21 AM Florence Blanc-Renaud  wrote:
> > > > > > >>
> > > > > > >> Hi,
> > > > > > >>
> > > > > > >> On Wed, Mar 20, 2024 at 10:00 AM Ian Kumlien  wrote:
> > > > > > >>>
> > > > > > >>> On Wed, Mar 20, 2024 at 9:45 AM Ian Kumlien  wrote:
> > > > > > >>>>
> > > > > > >>>> So... this one's new:
> > > > > > >>>>
> > > > > > >>>> Connection to https://freeipa-1.xerces.lan/ipa/json failed with
> > > > > > >>>> Insufficient access: SASL(-1): generic failure: GSSAPI Error:
> > > > > > >>>> Unspecified GSS failure.  Minor code may provide more information
> > > > > > >>>> (Credential cache is empty)
> > > > > > >>
> > > > > > >>
> > > > > > >> this one can happen if you have an existing ticket in your cache, for instance from a previous installation, but that is not valid anymore.
> > > > > > >
> > > > > > > Ah, ok, i did do kdestroy -A but only on the new machine...
> > > > > > >
> > > > > > > A new issue that appeared, no user from the old machines can
> > > > > > > authenticate at all - still looking in to why it doesn't work
> > > > > >
> > > > > > Disabling MS-PAC fixed this issue, will have to dig in to why it was later =)
> > > > > >
> > > > > > Any clues?
> > > > >
> > > > > Your users are probably missing a SID. Run ipa config-mod —enable-sid —add-sids and check with ipa user-show —all —raw that they contain an ipantsecurityidentifier attribute.
> > > >
> > > > Uhm, nope, changed nothing it seems... leaving ms-pac disabled works however
> > >
> > > There were plenty of discussions on this list in past couple months,
> > > including a lot of instructions what to investigate. Have you tried to
> > > apply those suggestions?
> >
> > I haven't found any using google...
> > > You haven't shown a single log excerpt from IPA servers, be it
> > > /var/log/krb5kdc.log or error logs from the directory server.
> >
> > And i haven't been asked - i assumed it was something due to the upgrade path
> >
> > Doing kerberos results in:
> > Mar 20 16:18:29 freeipa-4.xerces.lan krb5kdc[113624](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)}) 10.129.0.239: HANDLE_AUTHDATA:
> > [e-mail] for krbtgt/[e-mail], No such file or
> > directory
> >
> > For ldap authentication, which also fails with ms-pac enabled, i
> > haven't been able to find any real log with issues.
> > (So, with ms-pac, things that fails for a user: kerberos, ldap,
> > freeipa webui. Without ms-pac, everything works)
> >
> > We don't really use kerberos atm, so potentially leaving it disabled
> > could be fine, however i would much more like to get to the bottom of
> > this...
>
> This is from one of previous emails I sent here:
>
> Basically, I think you have users with UID/GIDs outside of your ID
> ranges and therefore those users have no SIDs associated with them and
> hence cannot be used for constrained delegation (S4U extensions in
> Kerberos) anymore. In addition, most likely your existing ID ranges have
> no support for generating SIDs as they most likely lack RID bases.
>
> There were plenty of discussions about it on the list in past few
> months. You can look at these articles on the Red Hat's Customer Portal:
>
> https://access.redhat.com/articles/7027037
> https://access.redhat.com/solutions/7052703
> https://access.redhat.com/solutions/7014959
>
> For your case, look first at the KCS 7052703, as it has collection of
> the instructions to use for different typical use cases. Article 7027037
> is a good visualisation of the ID range structure and requirements to
> SID bases.
>
> All those articles are accessible with RHEL subscription. You can get a
> free subscription at https://developers.redhat.com/.

I can't seem to register or recover my account, it seems to be
separate from the bugzilla one for some reason
(none of the emails sent are reaching me on gmail)

However, it seems like the UID range issue is what I'm facing, which
is odd, it should never have changed
and it makes you wonder what the largest value is... since currently,
for one user it's off by 1714800229
> --
> / Alexander Bokovoy
> Sr. Principal Software Engineer
> Security / Identity Management Engineering
> Red Hat Limited, Finland

Using ipa-ca-install on a replica

[Alexander Bokovoy]

On Чцв, 21 сак 2024, Ian Kumlien wrote:
> On Thu, Mar 21, 2024 at 10:22 AM Alexander Bokovoy  wrote:
> > On Чцв, 21 сак 2024, Ian Kumlien wrote:
> > > On Thu, Mar 21, 2024 at 9:13 AM Alexander Bokovoy  wrote:
> > > > On Чцв, 21 сак 2024, Ian Kumlien via FreeIPA-users wrote:
> > > > > On Wed, Mar 20, 2024 at 9:52 PM Florence Renaud  wrote:
> > > > > > > On 20 Mar 2024, at 16:38, Ian Kumlien  wrote:
> > > > > > >
> > > > > > > On Wed, Mar 20, 2024 at 3:52 PM Ian Kumlien  wrote:
> > > > > > >>
> > > > > > >>> On Wed, Mar 20, 2024 at 11:21 AM Florence Blanc-Renaud  wrote:
> > > > > > >>>
> > > > > > >>> Hi,
> > > > > > >>>
> > > > > > >>> On Wed, Mar 20, 2024 at 10:00 AM Ian Kumlien  wrote:
> > > > > > >>>>
> > > > > > >>>> On Wed, Mar 20, 2024 at 9:45 AM Ian Kumlien  wrote:
> > > > > > >>>>>
> > > > > > >>>>> So... this one's new:
> > > > > > >>>>>
> > > > > > >>>>> Connection to https://freeipa-1.xerces.lan/ipa/json failed with
> > > > > > >>>>> Insufficient access: SASL(-1): generic failure: GSSAPI Error:
> > > > > > >>>>> Unspecified GSS failure.  Minor code may provide more information
> > > > > > >>>>> (Credential cache is empty)
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> this one can happen if you have an existing ticket in your cache, for instance from a previous installation, but that is not valid anymore.
> > > > > > >>
> > > > > > >> Ah, ok, i did do kdestroy -A but only on the new machine...
> > > > > > >>
> > > > > > >> A new issue that appeared, no user from the old machines can
> > > > > > >> authenticate at all - still looking in to why it doesn't work
> > > > > > >
> > > > > > > Disabling MS-PAC fixed this issue, will have to dig in to why it was later =)
> > > > > > >
> > > > > > > Any clues?
> > > > > > Your users are probably missing a SID. Run ipa config-mod —enable-sid —add-sids and check with ipa user-show —all —raw that they contain an ipantsecurityidentifier attribute.
> > > > >
> > > > > Uhm, nope, changed nothing it seems... leaving ms-pac disabled works however
> > > >
> > > > There were plenty of discussions on this list in past couple months,
> > > > including a lot of instructions what to investigate. Have you tried to
> > > > apply those suggestions?
> > >
> > > I haven't found any using google...
> > > > You haven't shown a single log excerpt from IPA servers, be it
> > > > /var/log/krb5kdc.log or error logs from the directory server.
> > >
> > > And i haven't been asked - i assumed it was something due to the upgrade path
> > >
> > > Doing kerberos results in:
> > > Mar 20 16:18:29 freeipa-4.xerces.lan krb5kdc[113624](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)}) 10.129.0.239: HANDLE_AUTHDATA:
> > > [e-mail] for krbtgt/[e-mail], No such file or
> > > directory
> > >
> > > For ldap authentication, which also fails with ms-pac enabled, i
> > > haven't been able to find any real log with issues.
> > > (So, with ms-pac, things that fails for a user: kerberos, ldap,
> > > freeipa webui. Without ms-pac, everything works)
> > >
> > > We don't really use kerberos atm, so potentially leaving it disabled
> > > could be fine, however i would much more like to get to the bottom of
> > > this...
> >
> > This is from one of previous emails I sent here:
> >
> > Basically, I think you have users with UID/GIDs outside of your ID
> > ranges and therefore those users have no SIDs associated with them and
> > hence cannot be used for constrained delegation (S4U extensions in
> > Kerberos) anymore. In addition, most likely your existing ID ranges have
> > no support for generating SIDs as they most likely lack RID bases.
> >
> > There were plenty of discussions about it on the list in past few
> > months. You can look at these articles on the Red Hat's Customer Portal:
> >
> > https://access.redhat.com/articles/7027037
> > https://access.redhat.com/solutions/7052703
> > https://access.redhat.com/solutions/7014959
> >
> > For your case, look first at the KCS 7052703, as it has collection of
> > the instructions to use for different typical use cases. Article 7027037
> > is a good visualisation of the ID range structure and requirements to
> > SID bases.
> >
> > All those articles are accessible with RHEL subscription. You can get a
> > free subscription at https://developers.redhat.com/.
>
> I can't seem to register or recover my account, it seems to be
> separate from the bugzilla one for some reason
> (none of the emails sent are reaching me on gmail)

The account at the customer portal is different from the bugzilla, so
you need to register a separate one.
> However, it seems like the UID range issue is what I'm facing, which
> is odd, it should never have changed
> and it makes you wonder what the largest value is... since currently,
> for one user it's off by 1714800229

Show your ID ranges with 'ipa idrange-find'

May be you migrated some users using 'ipa migrate-ds' from a different
installation in the past? That doesn't handle adjusting IDs or SIDs.

Using ipa-ca-install on a replica

[Ian Kumlien]

On Thu, Mar 21, 2024 at 1:55 PM Alexander Bokovoy  wrote:
> On Чцв, 21 сак 2024, Ian Kumlien wrote:
> > On Thu, Mar 21, 2024 at 10:22 AM Alexander Bokovoy  wrote:
> > >

[-8<-]
> > I can't seem to register or recover my account, it seems to be
> > separate from the bugzilla one for some reason
> > (none of the emails sent are reaching me on gmail)
>
> The account at the customer portal is different from the bugzilla, so
> you need to register a separate one.
> > However, it seems like the UID range issue is what I'm facing, which
> > is odd, it should never have changed
> > and it makes you wonder what the largest value is... since currently,
> > for one user it's off by 1714800229
>
> Show your ID ranges with 'ipa idrange-find'
>
> May be you migrated some users using 'ipa migrate-ds' from a different
> installation in the past? That doesn't handle adjusting IDs or SIDs.

Not really, but afair it was fedora -> centos 8 stream (because
reasons) -> fedora (because sanity)

We did have issues with ca certificates expiring and so on, so there
has been a lot of trying to fix things
and workarounds...

Anyway, extracted all UID:s and sorted them, and then created a new
range since it was more than 1.7 billion away...
Reran ipa config-mod --enable-sid --add-sids, it eventually failed
with a dbus error, reran it again and it seems to have done the trick