[Freeipa-users] Re: certmonger error on ubuntu
Look data via FreeIPA-users wrote: > Hi, > > I know this is old thread but i'm facing the same issue. I have tried all > possible solution mentioned here. > Anyone know how to fix "ca-error: Error 60 connecting to > https://:8443/ca/agent/ca/profileReview: Peer certificate cannot be > authenticated with given CA certificates." Need more context. What version of Ubuntu. Is this a server running on it or a client? If it's a server then its likely the same libnsspem problem Timo mentions in the thread. I'm not sure if that was ever resolved. rob -- ___ 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: certmonger error on ubuntu
Hi, I know this is old thread but i'm facing the same issue. I have tried all possible solution mentioned here. Anyone know how to fix "ca-error: Error 60 connecting to https://:8443/ca/agent/ca/profileReview: Peer certificate cannot be authenticated with given CA certificates." thanks, look -- ___ 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: FreeIPA web UI login's failing
Marc Pearson | i-Neda Ltd via FreeIPA-users wrote:
> Hello, looking for some help.
>
> Weve recently noted that the majority of our web UIs have started to
> fail to login. I have at least 1 thats still allowing log-ins at present.
>
> When attempting to login, we get a 401 unauthorised in the networking
> tab for the login POST request, and a banner appears: Your session has
> expired. Please log in again.
>
> In the kerbos logs I see the following:
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1861](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.13.3.111:
> NEEDED_PREAUTH: WELLKNOWN/anonym...@int.i-neda.com
> for
> krbtgt/int.i-neda@int.i-neda.com
> , Additional
> pre-authentication required
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1861](info): closing
> down fd 12
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](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.13.3.111: ISSUE:
> authtime 1707232119, etypes {rep=aes256-cts-hmac-sha384-192(20),
> tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)},
> WELLKNOWN/anonym...@int.i-neda.com
> for
> krbtgt/int.i-neda@int.i-neda.com
>
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): closing
> down fd 12
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](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.13.3.111:
> NEEDED_PREAUTH: marc.ad...@int.i-neda.com
> for
> krbtgt/int.i-neda@int.i-neda.com
> , Additional
> pre-authentication required
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): closing
> down fd 12
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](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.13.3.111: ISSUE:
> authtime 1707232119, etypes {rep=aes256-cts-hmac-sha1-96(18),
> tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)},
> marc.ad...@int.i-neda.com for
> krbtgt/int.i-neda@int.i-neda.com
>
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): closing
> down fd 12
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1861](info): TGS_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.13.3.111: ISSUE:
> authtime 1707232119, etypes {rep=aes256-cts-hmac-sha1-96(18),
> tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)},
> marc.ad...@int.i-neda.com for
> HTTP/red-ipa01.int.i-neda@int.i-neda.com
>
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1861](info): closing
> down fd 12
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): TGS_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.13.3.111:
> S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1707232119, etypes
> {rep=UNSUPPORTED:(0)} HTTP/red-ipa01.int.i-neda@int.i-neda.com
> for
> ldap/red-ipa01.int.i-neda@int.i-neda.com
> , KDC policy
> rejects request
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): ...
> CONSTRAINED-DELEGATION s4u-client=
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): closing
> down fd 12
>
> Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): TGS_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.13.3.111:
> S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1707232119, etypes
> {rep=UNSUPPORTED:(0)} HTTP/red-ipa01.int.i-neda@int.i-neda.com
> for
> ldap/red-ipa01.int.i-neda@int.i-neda.com
>
[Freeipa-users] FreeIPA web UI login's failing
Hello, looking for some help.
We've recently noted that the majority of our web UI's have started to fail to
login. I have at least 1 that's still allowing log-in's at present.
When attempting to login, we get a 401 unauthorised in the networking tab for
the login POST request, and a banner appears: "Your session has expired. Please
log in again."
In the kerbos logs I see the following:
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1861](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.13.3.111:
NEEDED_PREAUTH:
WELLKNOWN/anonym...@int.i-neda.com
for
krbtgt/int.i-neda@int.i-neda.com,
Additional pre-authentication required
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1861](info): closing down fd 12
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](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.13.3.111: ISSUE:
authtime 1707232119, etypes {rep=aes256-cts-hmac-sha384-192(20),
tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)},
WELLKNOWN/anonym...@int.i-neda.com
for
krbtgt/int.i-neda@int.i-neda.com
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): closing down fd 12
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](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.13.3.111:
NEEDED_PREAUTH: marc.ad...@int.i-neda.com for
krbtgt/int.i-neda@int.i-neda.com,
Additional pre-authentication required
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): closing down fd 12
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](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.13.3.111: ISSUE:
authtime 1707232119, etypes {rep=aes256-cts-hmac-sha1-96(18),
tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)},
marc.ad...@int.i-neda.com for
krbtgt/int.i-neda@int.i-neda.com
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): closing down fd 12
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1861](info): TGS_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.13.3.111: ISSUE:
authtime 1707232119, etypes {rep=aes256-cts-hmac-sha1-96(18),
tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)},
marc.ad...@int.i-neda.com for
HTTP/red-ipa01.int.i-neda@int.i-neda.com
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1861](info): closing down fd 12
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): TGS_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.13.3.111:
S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1707232119, etypes
{rep=UNSUPPORTED:(0)}
HTTP/red-ipa01.int.i-neda@int.i-neda.com
for
ldap/red-ipa01.int.i-neda@int.i-neda.com,
KDC policy rejects request
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): ...
CONSTRAINED-DELEGATION s4u-client=
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): closing down fd 12
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): TGS_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.13.3.111:
S4U2PROXY_EVIDENCE_TKT_WITHOUT_PAC: authtime 1707232119, etypes
{rep=UNSUPPORTED:(0)}
HTTP/red-ipa01.int.i-neda@int.i-neda.com
for
ldap/red-ipa01.int.i-neda@int.i-neda.com,
KDC policy rejects request
Feb 06 15:08:39 red-ipa01.int.i-neda.com krb5kdc[1862](info): ...
CONSTRAINED-DELEGATION s4u-client=
Feb 06 15:08:39 red-ipa01.int.i-neda.com
[Freeipa-users] Re: FreeIPA Upgrade - overwrites custom authselect config
Finn Fysj via FreeIPA-users wrote: >> On Срд, 10 сту 2024, Finn Fysj via FreeIPA-users wrote: >> >> It should tell you what upgrade step is that prior to running the >> command. >> >> I think this is about migration to authselect. Upgrade code considers >> whether migration from authconfig is needed and if we didn't record that >> migration already happened, we perform it. The default configuration is >> 'authselect select sssd with-sudo --force'. >> >> You can avoid re-running this upgrade part by adding a section >> >> [authcfg] >> migrated_to_authselect = True >> >> to /var/lib/ipa/sysupgrade/sysupgrade.state >> >> and rerunning the upgrade. > Is it possible to have `migrated_to_authselect = True` for backup restore > also? > I come to realize that FreeIPA will modify authselect configuration during: > 1. Install > 2. Upgrade > 3. Restore Need more details. What is being overwritten and why do you think it's related to this update state? rob -- ___ 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: FreeIPA Upgrade - overwrites custom authselect config
> On Срд, 10 сту 2024, Finn Fysj via FreeIPA-users wrote: > > It should tell you what upgrade step is that prior to running the > command. > > I think this is about migration to authselect. Upgrade code considers > whether migration from authconfig is needed and if we didn't record that > migration already happened, we perform it. The default configuration is > 'authselect select sssd with-sudo --force'. > > You can avoid re-running this upgrade part by adding a section > > [authcfg] > migrated_to_authselect = True > > to /var/lib/ipa/sysupgrade/sysupgrade.state > > and rerunning the upgrade. Is it possible to have `migrated_to_authselect = True` for backup restore also? I come to realize that FreeIPA will modify authselect configuration during: 1. Install 2. Upgrade 3. Restore -- ___ 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
