[Freeipa-users] Re: Using ipa-ca-install on a replica

2024-03-21 Thread Ian Kumlien via FreeIPA-users
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
--
___
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: Using ipa-ca-install on a replica

2024-03-21 Thread Alexander Bokovoy via FreeIPA-users

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:
>u...@xerces.lan for krbtgt/xerces@xerces.lan, 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.



--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red 

[Freeipa-users] Re: Using ipa-ca-install on a replica

2024-03-21 Thread Ian Kumlien via FreeIPA-users
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:
> >u...@xerces.lan for krbtgt/xerces@xerces.lan, 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
>
--

[Freeipa-users] Re: Using ipa-ca-install on a replica

2024-03-21 Thread Alexander Bokovoy via FreeIPA-users

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:
u...@xerces.lan for krbtgt/xerces@xerces.lan, 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/.

--
/ 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: Using ipa-ca-install on a replica

2024-03-21 Thread Ian Kumlien via FreeIPA-users
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:
> u...@xerces.lan for krbtgt/xerces@xerces.lan, 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
> >
--
___
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: Using ipa-ca-install on a replica

2024-03-21 Thread Ian Kumlien via FreeIPA-users
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:
u...@xerces.lan for krbtgt/xerces@xerces.lan, 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
>
--
___
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: Using ipa-ca-install on a replica

2024-03-21 Thread Alexander Bokovoy via FreeIPA-users

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.



--
/ 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: Using ipa-ca-install on a replica

2024-03-21 Thread Ian Kumlien via FreeIPA-users
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...
> 
> >
>
--
___
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: Using ipa-ca-install on a replica

2024-03-20 Thread Florence Renaud via FreeIPA-users


> 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...
 
> 
--
___
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: Using ipa-ca-install on a replica

2024-03-20 Thread Ian Kumlien via FreeIPA-users
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...
> >>
--
___
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: Using ipa-ca-install on a replica

2024-03-19 Thread Florence Blanc-Renaud via FreeIPA-users
Hi,

On Mon, Mar 18, 2024 at 3:38 PM Ian Kumlien  wrote:

> On Thu, Mar 14, 2024 at 7:36 PM Florence Blanc-Renaud 
> wrote:
> >
> > Hi,
> >
> > On Thu, Mar 14, 2024 at 8:55 AM Ian Kumlien 
> wrote:
> >>
> >> On Wed, Mar 13, 2024 at 1:58 PM Ian Kumlien 
> wrote:
>
> [--8<--]
>
> >> As a side node, the conncheck for ipa-ca-install fails all the time
> >> now, when executing check on remote master it ends with this:
> >> 2024-03-14T07:42:26Z DEBUG Destroyed connection
> >> context.rpcclient_139905569284576
> >> 2024-03-14T07:42:26Z ERROR ERROR: Remote master check failed with
> >> following error message(s):
> >> invalid 'cn': must be "freeipa-4.xerces.lan"
> >> 2024-03-14T07:42:26Z DEBUG Stopping listening thread.
> >>
> >> Which seems really strange...
> >>
> > The message is highly misleading, but basically means that the conncheck
> part tried to check the connection to freeipa-4.xerces.lan, there was an
> issue and then a different server was tried. Discussed in this thread:
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/VCARE7OOXWBEB5UXF75AQVFQXNOA43XM/
>
> Ok, i have actually looked at that and checked the pki
> security-domain-show --- perhaps i should look at the bug options as
> well...
>
> > Can you provide the exact OS + ipa / 389-ds-base versions that you have
> on your server and on your replica? And any relevant info about the history
> of the master (for instance, was the master initially installed with this
> version or was it upgraded from older versions).
>
> I verified that the plugin is available on the other end, so ...
> Centos 8 Stream - master:
> ipa-server-dns-4.9.10-6.module_el8.7.0+1209+42bcbcde.noarch
> ipa-server-4.9.10-6.module_el8.7.0+1209+42bcbcde.x86_64
> ipa-server-common-4.9.10-6.module_el8.7.0+1209+42bcbcde.noarch
> 389-ds-base-1.4.3.28-6.module_el8.6.0+1102+fe5d910f.x86_64
> 389-ds-base-libs-1.4.3.28-6.module_el8.6.0+1102+fe5d910f.x86_64
>
> Fedora 39 - replica:
> freeipa-server-common-4.11.1-2.fc39.noarch
> freeipa-server-4.11.1-2.fc39.x86_64
> freeipa-server-dns-4.11.1-2.fc39.noarch
> 389-ds-base-libs-2.4.5-1.fc39.x86_64
> 389-ds-base-2.4.5-1.fc39.x86_64
>
In this version of 389-ds the default password storage scheme is PBKDF2-SHA
*512* but as far as I know, 389-ds-base-1.4.3.28 does not support this
scheme, only PBKDF2_SHA*256*.
You either need to update the master to a more recent version or force a
different password storage scheme on the replica, for instance by providing
the following config file to ipa-replica-install:
# cat /tmp/dse.ldif
dn: cn=config
changetype: modify
replace: passwordStorageScheme
passwordStorageScheme: PBKDF2_SHA256
# ipa-replica-install [...] --dirsrv-config-file /tmp/dse.ldif

HTH,
flo
--
___
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: Using ipa-ca-install on a replica

2024-03-18 Thread Ian Kumlien via FreeIPA-users
On Thu, Mar 14, 2024 at 7:36 PM Florence Blanc-Renaud  wrote:
>
> Hi,
>
> On Thu, Mar 14, 2024 at 8:55 AM Ian Kumlien  wrote:
>>
>> On Wed, Mar 13, 2024 at 1:58 PM Ian Kumlien  wrote:

[--8<--]

>> As a side node, the conncheck for ipa-ca-install fails all the time
>> now, when executing check on remote master it ends with this:
>> 2024-03-14T07:42:26Z DEBUG Destroyed connection
>> context.rpcclient_139905569284576
>> 2024-03-14T07:42:26Z ERROR ERROR: Remote master check failed with
>> following error message(s):
>> invalid 'cn': must be "freeipa-4.xerces.lan"
>> 2024-03-14T07:42:26Z DEBUG Stopping listening thread.
>>
>> Which seems really strange...
>>
> The message is highly misleading, but basically means that the conncheck part 
> tried to check the connection to freeipa-4.xerces.lan, there was an issue and 
> then a different server was tried. Discussed in this thread: 
> https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org/thread/VCARE7OOXWBEB5UXF75AQVFQXNOA43XM/

Ok, i have actually looked at that and checked the pki
security-domain-show --- perhaps i should look at the bug options as
well...

> Can you provide the exact OS + ipa / 389-ds-base versions that you have on 
> your server and on your replica? And any relevant info about the history of 
> the master (for instance, was the master initially installed with this 
> version or was it upgraded from older versions).

I verified that the plugin is available on the other end, so ...
Centos 8 Stream - master:
ipa-server-dns-4.9.10-6.module_el8.7.0+1209+42bcbcde.noarch
ipa-server-4.9.10-6.module_el8.7.0+1209+42bcbcde.x86_64
ipa-server-common-4.9.10-6.module_el8.7.0+1209+42bcbcde.noarch
389-ds-base-1.4.3.28-6.module_el8.6.0+1102+fe5d910f.x86_64
389-ds-base-libs-1.4.3.28-6.module_el8.6.0+1102+fe5d910f.x86_64

Fedora 39 - replica:
freeipa-server-common-4.11.1-2.fc39.noarch
freeipa-server-4.11.1-2.fc39.x86_64
freeipa-server-dns-4.11.1-2.fc39.noarch
389-ds-base-libs-2.4.5-1.fc39.x86_64
389-ds-base-2.4.5-1.fc39.x86_64
--
___
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: Using ipa-ca-install on a replica

2024-03-14 Thread Florence Blanc-Renaud via FreeIPA-users
Hi,

On Thu, Mar 14, 2024 at 8:55 AM Ian Kumlien  wrote:

> On Wed, Mar 13, 2024 at 1:58 PM Ian Kumlien  wrote:
> >
> > On Wed, Mar 13, 2024 at 11:39 AM Florence Blanc-Renaud 
> wrote:
> > >
> > > Hi,
> > >
> > > On Wed, Mar 13, 2024 at 10:06 AM Ian Kumlien 
> wrote:
> > >>
> > >> On Tue, Mar 12, 2024 at 10:36 PM Florence Blanc-Renaud <
> f...@redhat.com> wrote:
> > >> >
> > >> > Hi,
> > >> >
> > >> > On Tue, Mar 12, 2024 at 12:54 PM Ian Kumlien via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
> > >> >>
> > >> >> Hi,
> > >> >>
> > >> >> So i have spent quite some time trying to get out of the swamp
> that is
> > >> >> centos stream 8 and back to something with a actual upgrade path,
> > >> >> fedora =)
> > >> >>
> > >> >> Everything works except the ipa-ca-install on the replica - mostly
> > >> >> fails at the same step
> > >> >>
> > >> >> At some point the conncheck failed, dropping me in to a prompt
> asking
> > >> >> for the password of a admin- account
> > >> >>
> > >> >> Anyway, I do know about the issue with - vs _ and validated on
> master,
> > >> >> changed on replica as detailed here:
> > >> >>
> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/IHIPPVMMIWV2TL7BNLW55XII3OIQ62HK/
> > >> >>
> > >> >> But it still fails..
> > >> >>
> > >> >> Oh and btw, none of the machines are running any firewalls =)
> > >> >>
> > >> >> Anyone that has a clue of what to test next?
> > >> >>
> > >> >> Btw, it's 4.9 to 4.11 if there is other issues with
> interoperability
> > >> >>
> > >> >> ipa-ca-install --skip-conncheck
> > >> >> Directory Manager (existing master) password:
> > >> >>
> > >> >> Configuring certificate server (pki-tomcatd). Estimated time: 3
> minutes
> > >> >>   [1/28]: creating certificate server db
> > >> >>   [2/28]: setting up initial replication
> > >> >> Starting replication, please wait until this has completed.
> > >> >> Update in progress, 7 seconds elapsed
> > >> >> Update succeeded
> > >> >>
> > >> >>   [3/28]: creating ACIs for admin
> > >> >>   [4/28]: creating installation admin user
> > >> >> ipaserver.install.dogtaginstance: ERRORUnable to log in as
> > >> >> uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on
> > >> >> ldap://freeipa-1.xerces.lan:389
> > >> >>   [error] NotFound:
> uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
> > >> >> did not replicate to ldap://freeipa-1.xerces.lan:389
> > >> >>
> > >> >> Your system may be partly configured.
> > >> >> Run /usr/sbin/ipa-server-install --uninstall to clean up.
> > >> >>
> > >> >> Unexpected error - see /var/log/ipareplica-ca-install.log for
> details:
> > >> >> NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not
> > >> >> replicate to ldap://freeipa-1.xerces.lan:389
> > >> >>
> > >> > The installation of a CA clone creates this user on the replica,
> lets the replication copy the entry on the master and then checks by doing
> a ldap bind from the replica to the master that the entry has been properly
> replicated.
> > >> > When this error happens, it can either mean that the entry was not
> replicated or that the bind failed.
> > >> >
> > >> > In order to know exactly what is happening for you, you can check
> > >> > - on the master freeipa-1.xerces.lan, do a ldapsearch for this
> entry and check if it exists. If the entry is present, the replication
> properly propagated the entry from replica to master and you are probably
> hitting the 2nd issue.
> > >> > # ldapsearch -D "cn=directory manager" -W -b
> uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
> > >> >
> > >> > - on the replica, do a ldapsearch for this entry and check the
> userpassword attribute. It is base64-encoded, and you can decode it in
> order to find the password storage scheme that was used to encrypt the
> password.
> > >> > For instance on my machine:
> > >> >
> > >> > dn: uid=admin-replica.ipa.test,ou=people,o=ipaca
> > >> > userPassword::
> e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZ
> > >> >
> NTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pT
> > >> >
> dy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb
> > >> >
> 055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3
> > >> >
> pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4
> > >> >
> wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZL
> > >> >
> ZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM
> > >> >
> 2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
> > >> >
> > >> >
> > >> > If I base64 decode the value:
> > >> >
> > >> > # echo
> 

[Freeipa-users] Re: Using ipa-ca-install on a replica

2024-03-14 Thread Ian Kumlien via FreeIPA-users
On Wed, Mar 13, 2024 at 1:58 PM Ian Kumlien  wrote:
>
> On Wed, Mar 13, 2024 at 11:39 AM Florence Blanc-Renaud  
> wrote:
> >
> > Hi,
> >
> > On Wed, Mar 13, 2024 at 10:06 AM Ian Kumlien  wrote:
> >>
> >> On Tue, Mar 12, 2024 at 10:36 PM Florence Blanc-Renaud  
> >> wrote:
> >> >
> >> > Hi,
> >> >
> >> > On Tue, Mar 12, 2024 at 12:54 PM Ian Kumlien via FreeIPA-users 
> >> >  wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> So i have spent quite some time trying to get out of the swamp that is
> >> >> centos stream 8 and back to something with a actual upgrade path,
> >> >> fedora =)
> >> >>
> >> >> Everything works except the ipa-ca-install on the replica - mostly
> >> >> fails at the same step
> >> >>
> >> >> At some point the conncheck failed, dropping me in to a prompt asking
> >> >> for the password of a admin- account
> >> >>
> >> >> Anyway, I do know about the issue with - vs _ and validated on master,
> >> >> changed on replica as detailed here:
> >> >> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/IHIPPVMMIWV2TL7BNLW55XII3OIQ62HK/
> >> >>
> >> >> But it still fails..
> >> >>
> >> >> Oh and btw, none of the machines are running any firewalls =)
> >> >>
> >> >> Anyone that has a clue of what to test next?
> >> >>
> >> >> Btw, it's 4.9 to 4.11 if there is other issues with interoperability
> >> >>
> >> >> ipa-ca-install --skip-conncheck
> >> >> Directory Manager (existing master) password:
> >> >>
> >> >> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
> >> >>   [1/28]: creating certificate server db
> >> >>   [2/28]: setting up initial replication
> >> >> Starting replication, please wait until this has completed.
> >> >> Update in progress, 7 seconds elapsed
> >> >> Update succeeded
> >> >>
> >> >>   [3/28]: creating ACIs for admin
> >> >>   [4/28]: creating installation admin user
> >> >> ipaserver.install.dogtaginstance: ERRORUnable to log in as
> >> >> uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on
> >> >> ldap://freeipa-1.xerces.lan:389
> >> >>   [error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
> >> >> did not replicate to ldap://freeipa-1.xerces.lan:389
> >> >>
> >> >> Your system may be partly configured.
> >> >> Run /usr/sbin/ipa-server-install --uninstall to clean up.
> >> >>
> >> >> Unexpected error - see /var/log/ipareplica-ca-install.log for details:
> >> >> NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not
> >> >> replicate to ldap://freeipa-1.xerces.lan:389
> >> >>
> >> > The installation of a CA clone creates this user on the replica, lets 
> >> > the replication copy the entry on the master and then checks by doing a 
> >> > ldap bind from the replica to the master that the entry has been 
> >> > properly replicated.
> >> > When this error happens, it can either mean that the entry was not 
> >> > replicated or that the bind failed.
> >> >
> >> > In order to know exactly what is happening for you, you can check
> >> > - on the master freeipa-1.xerces.lan, do a ldapsearch for this entry and 
> >> > check if it exists. If the entry is present, the replication properly 
> >> > propagated the entry from replica to master and you are probably hitting 
> >> > the 2nd issue.
> >> > # ldapsearch -D "cn=directory manager" -W -b 
> >> > uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
> >> >
> >> > - on the replica, do a ldapsearch for this entry and check the 
> >> > userpassword attribute. It is base64-encoded, and you can decode it in 
> >> > order to find the password storage scheme that was used to encrypt the 
> >> > password.
> >> > For instance on my machine:
> >> >
> >> > dn: uid=admin-replica.ipa.test,ou=people,o=ipaca
> >> > userPassword:: 
> >> > e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZ
> >> >  
> >> > NTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pT
> >> >  
> >> > dy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb
> >> >  
> >> > 055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3
> >> >  
> >> > pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4
> >> >  
> >> > wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZL
> >> >  
> >> > ZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM
> >> >  2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
> >> >
> >> >
> >> > If I base64 decode the value:
> >> >
> >> > # echo 
> >> > 

[Freeipa-users] Re: Using ipa-ca-install on a replica

2024-03-13 Thread Ian Kumlien via FreeIPA-users
On Wed, Mar 13, 2024 at 11:39 AM Florence Blanc-Renaud  wrote:
>
> Hi,
>
> On Wed, Mar 13, 2024 at 10:06 AM Ian Kumlien  wrote:
>>
>> On Tue, Mar 12, 2024 at 10:36 PM Florence Blanc-Renaud  
>> wrote:
>> >
>> > Hi,
>> >
>> > On Tue, Mar 12, 2024 at 12:54 PM Ian Kumlien via FreeIPA-users 
>> >  wrote:
>> >>
>> >> Hi,
>> >>
>> >> So i have spent quite some time trying to get out of the swamp that is
>> >> centos stream 8 and back to something with a actual upgrade path,
>> >> fedora =)
>> >>
>> >> Everything works except the ipa-ca-install on the replica - mostly
>> >> fails at the same step
>> >>
>> >> At some point the conncheck failed, dropping me in to a prompt asking
>> >> for the password of a admin- account
>> >>
>> >> Anyway, I do know about the issue with - vs _ and validated on master,
>> >> changed on replica as detailed here:
>> >> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/IHIPPVMMIWV2TL7BNLW55XII3OIQ62HK/
>> >>
>> >> But it still fails..
>> >>
>> >> Oh and btw, none of the machines are running any firewalls =)
>> >>
>> >> Anyone that has a clue of what to test next?
>> >>
>> >> Btw, it's 4.9 to 4.11 if there is other issues with interoperability
>> >>
>> >> ipa-ca-install --skip-conncheck
>> >> Directory Manager (existing master) password:
>> >>
>> >> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
>> >>   [1/28]: creating certificate server db
>> >>   [2/28]: setting up initial replication
>> >> Starting replication, please wait until this has completed.
>> >> Update in progress, 7 seconds elapsed
>> >> Update succeeded
>> >>
>> >>   [3/28]: creating ACIs for admin
>> >>   [4/28]: creating installation admin user
>> >> ipaserver.install.dogtaginstance: ERRORUnable to log in as
>> >> uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on
>> >> ldap://freeipa-1.xerces.lan:389
>> >>   [error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
>> >> did not replicate to ldap://freeipa-1.xerces.lan:389
>> >>
>> >> Your system may be partly configured.
>> >> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>> >>
>> >> Unexpected error - see /var/log/ipareplica-ca-install.log for details:
>> >> NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not
>> >> replicate to ldap://freeipa-1.xerces.lan:389
>> >>
>> > The installation of a CA clone creates this user on the replica, lets the 
>> > replication copy the entry on the master and then checks by doing a ldap 
>> > bind from the replica to the master that the entry has been properly 
>> > replicated.
>> > When this error happens, it can either mean that the entry was not 
>> > replicated or that the bind failed.
>> >
>> > In order to know exactly what is happening for you, you can check
>> > - on the master freeipa-1.xerces.lan, do a ldapsearch for this entry and 
>> > check if it exists. If the entry is present, the replication properly 
>> > propagated the entry from replica to master and you are probably hitting 
>> > the 2nd issue.
>> > # ldapsearch -D "cn=directory manager" -W -b 
>> > uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
>> >
>> > - on the replica, do a ldapsearch for this entry and check the 
>> > userpassword attribute. It is base64-encoded, and you can decode it in 
>> > order to find the password storage scheme that was used to encrypt the 
>> > password.
>> > For instance on my machine:
>> >
>> > dn: uid=admin-replica.ipa.test,ou=people,o=ipaca
>> > userPassword:: 
>> > e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZ
>> >  
>> > NTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pT
>> >  
>> > dy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb
>> >  
>> > 055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3
>> >  
>> > pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4
>> >  
>> > wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZL
>> >  
>> > ZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM
>> >  2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
>> >
>> >
>> > If I base64 decode the value:
>> >
>> > # echo 
>> > e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZNTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pTdy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZLZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
>> >  | base64 -d
>> > 

[Freeipa-users] Re: Using ipa-ca-install on a replica

2024-03-13 Thread Florence Blanc-Renaud via FreeIPA-users
Hi,

On Wed, Mar 13, 2024 at 10:06 AM Ian Kumlien  wrote:

> On Tue, Mar 12, 2024 at 10:36 PM Florence Blanc-Renaud 
> wrote:
> >
> > Hi,
> >
> > On Tue, Mar 12, 2024 at 12:54 PM Ian Kumlien via FreeIPA-users <
> freeipa-users@lists.fedorahosted.org> wrote:
> >>
> >> Hi,
> >>
> >> So i have spent quite some time trying to get out of the swamp that is
> >> centos stream 8 and back to something with a actual upgrade path,
> >> fedora =)
> >>
> >> Everything works except the ipa-ca-install on the replica - mostly
> >> fails at the same step
> >>
> >> At some point the conncheck failed, dropping me in to a prompt asking
> >> for the password of a admin- account
> >>
> >> Anyway, I do know about the issue with - vs _ and validated on master,
> >> changed on replica as detailed here:
> >>
> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/IHIPPVMMIWV2TL7BNLW55XII3OIQ62HK/
> >>
> >> But it still fails..
> >>
> >> Oh and btw, none of the machines are running any firewalls =)
> >>
> >> Anyone that has a clue of what to test next?
> >>
> >> Btw, it's 4.9 to 4.11 if there is other issues with interoperability
> >>
> >> ipa-ca-install --skip-conncheck
> >> Directory Manager (existing master) password:
> >>
> >> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
> >>   [1/28]: creating certificate server db
> >>   [2/28]: setting up initial replication
> >> Starting replication, please wait until this has completed.
> >> Update in progress, 7 seconds elapsed
> >> Update succeeded
> >>
> >>   [3/28]: creating ACIs for admin
> >>   [4/28]: creating installation admin user
> >> ipaserver.install.dogtaginstance: ERRORUnable to log in as
> >> uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on
> >> ldap://freeipa-1.xerces.lan:389
> >>   [error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
> >> did not replicate to ldap://freeipa-1.xerces.lan:389
> >>
> >> Your system may be partly configured.
> >> Run /usr/sbin/ipa-server-install --uninstall to clean up.
> >>
> >> Unexpected error - see /var/log/ipareplica-ca-install.log for details:
> >> NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not
> >> replicate to ldap://freeipa-1.xerces.lan:389
> >>
> > The installation of a CA clone creates this user on the replica, lets
> the replication copy the entry on the master and then checks by doing a
> ldap bind from the replica to the master that the entry has been properly
> replicated.
> > When this error happens, it can either mean that the entry was not
> replicated or that the bind failed.
> >
> > In order to know exactly what is happening for you, you can check
> > - on the master freeipa-1.xerces.lan, do a ldapsearch for this entry and
> check if it exists. If the entry is present, the replication properly
> propagated the entry from replica to master and you are probably hitting
> the 2nd issue.
> > # ldapsearch -D "cn=directory manager" -W -b
> uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
> >
> > - on the replica, do a ldapsearch for this entry and check the
> userpassword attribute. It is base64-encoded, and you can decode it in
> order to find the password storage scheme that was used to encrypt the
> password.
> > For instance on my machine:
> >
> > dn: uid=admin-replica.ipa.test,ou=people,o=ipaca
> > userPassword::
> e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZ
> >
> NTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pT
> >
> dy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb
> >
> 055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3
> >
> pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4
> >
> wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZL
> >
> ZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM
> >  2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
> >
> >
> > If I base64 decode the value:
> >
> > # echo
> e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZNTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pTdy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZLZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
> | base64 -d
> >
> 

[Freeipa-users] Re: Using ipa-ca-install on a replica

2024-03-13 Thread Ian Kumlien via FreeIPA-users
On Tue, Mar 12, 2024 at 10:36 PM Florence Blanc-Renaud  wrote:
>
> Hi,
>
> On Tue, Mar 12, 2024 at 12:54 PM Ian Kumlien via FreeIPA-users 
>  wrote:
>>
>> Hi,
>>
>> So i have spent quite some time trying to get out of the swamp that is
>> centos stream 8 and back to something with a actual upgrade path,
>> fedora =)
>>
>> Everything works except the ipa-ca-install on the replica - mostly
>> fails at the same step
>>
>> At some point the conncheck failed, dropping me in to a prompt asking
>> for the password of a admin- account
>>
>> Anyway, I do know about the issue with - vs _ and validated on master,
>> changed on replica as detailed here:
>> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/IHIPPVMMIWV2TL7BNLW55XII3OIQ62HK/
>>
>> But it still fails..
>>
>> Oh and btw, none of the machines are running any firewalls =)
>>
>> Anyone that has a clue of what to test next?
>>
>> Btw, it's 4.9 to 4.11 if there is other issues with interoperability
>>
>> ipa-ca-install --skip-conncheck
>> Directory Manager (existing master) password:
>>
>> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
>>   [1/28]: creating certificate server db
>>   [2/28]: setting up initial replication
>> Starting replication, please wait until this has completed.
>> Update in progress, 7 seconds elapsed
>> Update succeeded
>>
>>   [3/28]: creating ACIs for admin
>>   [4/28]: creating installation admin user
>> ipaserver.install.dogtaginstance: ERRORUnable to log in as
>> uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on
>> ldap://freeipa-1.xerces.lan:389
>>   [error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
>> did not replicate to ldap://freeipa-1.xerces.lan:389
>>
>> Your system may be partly configured.
>> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>>
>> Unexpected error - see /var/log/ipareplica-ca-install.log for details:
>> NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not
>> replicate to ldap://freeipa-1.xerces.lan:389
>>
> The installation of a CA clone creates this user on the replica, lets the 
> replication copy the entry on the master and then checks by doing a ldap bind 
> from the replica to the master that the entry has been properly replicated.
> When this error happens, it can either mean that the entry was not replicated 
> or that the bind failed.
>
> In order to know exactly what is happening for you, you can check
> - on the master freeipa-1.xerces.lan, do a ldapsearch for this entry and 
> check if it exists. If the entry is present, the replication properly 
> propagated the entry from replica to master and you are probably hitting the 
> 2nd issue.
> # ldapsearch -D "cn=directory manager" -W -b 
> uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
>
> - on the replica, do a ldapsearch for this entry and check the userpassword 
> attribute. It is base64-encoded, and you can decode it in order to find the 
> password storage scheme that was used to encrypt the password.
> For instance on my machine:
>
> dn: uid=admin-replica.ipa.test,ou=people,o=ipaca
> userPassword:: e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZ
>  NTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pT
>  dy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb
>  055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3
>  pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4
>  wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZL
>  ZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM
>  2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
>
>
> If I base64 decode the value:
>
> # echo 
> e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZNTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pTdy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZLZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
>  | base64 -d
> {PBKDF2_SHA256}AAAIABYS+Xu1TBsoESr2KAYxFVGXdGYfMNlE7wBdtQWR1Q3qi7JMz+wgn/2+sSJ06ImxAzx9fDvTB+0+/BFr2db/ZSw/zc7a5iU4eBbvGzoE834TzHlppy/TxTasAZro58mbONNiGAniuszUpNgoNyGwKbJjC6PxJMy+gRINklZ8rcLpPJFKjocGE/CShyaPactoVYBVUXp33zrykYVPH/JHR3PojgfsTojQ/l9Qh5Pa0V5UgErPjE+Gl5kKKqLia4wozFN03z3f5pDfCFvNJ/BTGD4xircapVRTncM4AgLOBPBkhhVmolFAdvt9U1cVKduCedaYU3evkKXGqlwjZSlJOvD9JYIoAGFPp9rDFRlqMLXHTrLviZ1Mh23dhkHkGEW3zgkun+aHrsoaFLYd0f/y69px0Q32or/o9pYWQzKZi5Ai

Yes, and the value is the same on both replicas, both the encoded
base64 and the password scheme: 

[Freeipa-users] Re: Using ipa-ca-install on a replica

2024-03-12 Thread Florence Blanc-Renaud via FreeIPA-users
Hi,

On Tue, Mar 12, 2024 at 12:54 PM Ian Kumlien via FreeIPA-users <
freeipa-users@lists.fedorahosted.org> wrote:

> Hi,
>
> So i have spent quite some time trying to get out of the swamp that is
> centos stream 8 and back to something with a actual upgrade path,
> fedora =)
>
> Everything works except the ipa-ca-install on the replica - mostly
> fails at the same step
>
> At some point the conncheck failed, dropping me in to a prompt asking
> for the password of a admin- account
>
> Anyway, I do know about the issue with - vs _ and validated on master,
> changed on replica as detailed here:
>
> https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/IHIPPVMMIWV2TL7BNLW55XII3OIQ62HK/
>
> But it still fails..
>
> Oh and btw, none of the machines are running any firewalls =)
>
> Anyone that has a clue of what to test next?
>
> Btw, it's 4.9 to 4.11 if there is other issues with interoperability
>
> ipa-ca-install --skip-conncheck
> Directory Manager (existing master) password:
>
> Configuring certificate server (pki-tomcatd). Estimated time: 3 minutes
>   [1/28]: creating certificate server db
>   [2/28]: setting up initial replication
> Starting replication, please wait until this has completed.
> Update in progress, 7 seconds elapsed
> Update succeeded
>
>   [3/28]: creating ACIs for admin
>   [4/28]: creating installation admin user
> ipaserver.install.dogtaginstance: ERRORUnable to log in as
> uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca on
> ldap://freeipa-1.xerces.lan:389
>   [error] NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca
> did not replicate to ldap://freeipa-1.xerces.lan:389
>
> Your system may be partly configured.
> Run /usr/sbin/ipa-server-install --uninstall to clean up.
>
> Unexpected error - see /var/log/ipareplica-ca-install.log for details:
> NotFound: uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca did not
> replicate to ldap://freeipa-1.xerces.lan:389
>
> The installation of a CA clone creates this user on the replica, lets the
replication copy the entry on the master and then checks by doing a ldap
bind from the replica to the master that the entry has been properly
replicated.
When this error happens, it can either mean that the entry was not
replicated or that the bind failed.

In order to know exactly what is happening for you, you can check
- on the master freeipa-1.xerces.lan, do a ldapsearch for this entry and
check if it exists. If the entry is present, the replication properly
propagated the entry from replica to master and you are probably hitting
the 2nd issue.
# ldapsearch -D "cn=directory manager" -W -b
uid=admin-freeipa-4.xerces.lan,ou=people,o=ipaca

- on the replica, do a ldapsearch for this entry and check the userpassword
attribute. It is base64-encoded, and you can decode it in order to find the
password storage scheme that was used to encrypt the password.
For instance on my machine:

dn: uid=admin-replica.ipa.test,ou=people,o=ipaca
userPassword:: e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZ
 NTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pT
 dy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb
 055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3
 pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4
 wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZL
 ZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM
 2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp


If I base64 decode the value:

# echo 
e1BCS0RGMl9TSEEyNTZ9QUFBSUFCWVMrWHUxVEJzb0VTcjJLQVl4RlZHWGRHWWZNTmxFN3dCZHRRV1IxUTNxaTdKTXord2duLzIrc1NKMDZJbXhBeng5ZkR2VEIrMCsvQkZyMmRiL1pTdy96YzdhNWlVNGVCYnZHem9FODM0VHpIbHBweS9UeFRhc0Facm81OG1iT05OaUdBbml1c3pVcE5nb055R3dLYkpqQzZQeEpNeStnUklOa2xaOHJjTHBQSkZLam9jR0UvQ1NoeWFQYWN0b1ZZQlZVWHAzM3pyeWtZVlBIL0pIUjNQb2pnZnNUb2pRL2w5UWg1UGEwVjVVZ0VyUGpFK0dsNWtLS3FMaWE0d296Rk4wM3ozZjVwRGZDRnZOSi9CVEdENHhpcmNhcFZSVG5jTTRBZ0xPQlBCa2hoVm1vbEZBZHZ0OVUxY1ZLZHVDZWRhWVUzZXZrS1hHcWx3alpTbEpPdkQ5SllJb0FHRlBwOXJERlJscU1MWEhUckx2aVoxTWgyM2Roa0hrR0VXM3pna3VuK2FIcnNvYUZMWWQwZi95NjlweDBRMzJvci9vOXBZV1F6S1ppNUFp
| base64 
-d*{PBKDF2_SHA256}*AAAIABYS+Xu1TBsoESr2KAYxFVGXdGYfMNlE7wBdtQWR1Q3qi7JMz+wgn/2+sSJ06ImxAzx9fDvTB+0+/BFr2db/ZSw/zc7a5iU4eBbvGzoE834TzHlppy/TxTasAZro58mbONNiGAniuszUpNgoNyGwKbJjC6PxJMy+gRINklZ8rcLpPJFKjocGE/CShyaPactoVYBVUXp33zrykYVPH/JHR3PojgfsTojQ/l9Qh5Pa0V5UgErPjE+Gl5kKKqLia4wozFN03z3f5pDfCFvNJ/BTGD4xircapVRTncM4AgLOBPBkhhVmolFAdvt9U1cVKduCedaYU3evkKXGqlwjZSlJOvD9JYIoAGFPp9rDFRlqMLXHTrLviZ1Mh23dhkHkGEW3zgkun+aHrsoaFLYd0f/y69px0Q32or/o9pYWQzKZi5Ai

which means that the replica used PBKDF2_SHA256 as password storage scheme.
You need to check if this password storage scheme is supported on the
master (we had issues in the past with a password storage scheme used by
the replica that was not supported on the master and caused the