[Freeipa-users] Re: Extra objectClass for new IPA group
hi all, Nice tip, but no: not Vsphere although it might usefull later; so thanks We need it for several self-build applications. email handtekening privé Met vriendelijke groet, Winfried de Heiden w...@dds.nl Op 10-04-2024 om 17:13 schreef Rob Crittenden: Winfried de Heiden via FreeIPA-users wrote: Hi all, Following documentation as provided on: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/adding-custom-objclasses-groups#doc-wrapper adding an extra objectClass (groupOfUniqueNames in this case) to newly created groups turned out to be easy. It seems we depend of this objectClass and its attribute "uniqueMember" because of existing applications. Adding the latter attribute will only work from the CLI. (ipa group-mod dummy3 --addattr=uniqueMember=uid=someuser,cn=users,cn=accounts,dc=example,dc=com) Let me guess, vSphere? You can tryhttps://www.freeipa.org/page/HowTo/vsphere5_integration but it's very old. I can't guarantee it will work. It has the benefit that rather than manually modifying your entries the extra attributes are calculated on the fly. rob OK, this seems to work well, but the objectClass will be added to ALL newly created groups since the objectClass is added to the defaults. Now, let's say I want to add an extra objectClass to only one new created group; how would that be possible? The command "ipa group-add" command does not provide such an option, does it? FYI, I'm running/testing IPA version: 4.11.0 on RHEL 9.4 Beta :) The new attributes will not be visible in de webUI, only using the CLI (or good-old Apache Directory Studio of ldapsearch). Correct? -- email handtekening privé Met vriendelijke groet, Winfried de Heiden w...@dds.nl -- ___ FreeIPA-users mailing list --freeipa-users@lists.fedorahosted.org To unsubscribe send an email tofreeipa-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 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] Extra objectClass for new IPA group
Hi all, Following documentation as provided on: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/adding-custom-objclasses-groups#doc-wrapper adding an extra objectClass (groupOfUniqueNames in this case) to newly created groups turned out to be easy. It seems we depend of this objectClass and its attribute "uniqueMember" because of existing applications. Adding the latter attribute will only work from the CLI. (ipa group-mod dummy3 --addattr=uniqueMember=uid=someuser,cn=users,cn=accounts,dc=example,dc=com) OK, this seems to work well, but the objectClass will be added to ALL newly created groups since the objectClass is added to the defaults. Now, let's say I want to add an extra objectClass to only one new created group; how would that be possible? The command "ipa group-add" command does not provide such an option, does it? FYI, I'm running/testing IPA version: 4.11.0 on RHEL 9.4 Beta :) The new attributes will not be visible in de webUI, only using the CLI (or good-old Apache Directory Studio of ldapsearch). Correct? -- email handtekening privé Met vriendelijke groet, Winfried de Heiden w...@dds.nl -- ___ 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] 2FA - prompting - single_prompt
Hi all, Using FreeIPA, 2FA can be made optional by enabling "Password" AND "Two factor authentication (password + OTP)" for a user. For particular hosts the 2FA now can be made mandatory by enabling "Two factor authentication (password + OTP)" Now, for hosts for which 2FA is NOT mandatory, according to the man pages, 2FA can be made "invissible" by using the "single_prompt" option. In man sssd.conf: "If the second factor is optional and it should be possible to log in either only with the password or with both factors two-step prompting has to be used." However, this doesn't work. When using the "single_prompt" login will fail. Using two prompts, and just press enter for the second 2FA prompt, login will succeed. Hence: did I forget something or is there a bug involved? FYI: tested on CentOS Stream9 -- email handtekening privé Met vriendelijke groet, Winfried de Heiden w...@dds.nl ___ 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 on the list, report it: https://pagure.io/fedora-infrastructure
[Freeipa-users] Re: getcert status: CA_REJECTED
Nice to know I'm not the only one I'll keep an eye on the Bugzilla. Winfried . -Oorspronkelijk bericht- Van: Rob Crittenden via FreeIPA-users < freeipa-users@lists.fedorahosted.org> Antwoord-naar: FreeIPA users list Aan: FreeIPA users list Cc: Winfried de Heiden , Rob Crittenden < rcrit...@redhat.com> Onderwerp: [Freeipa-users] Re: getcert status: CA_REJECTED Datum: Thu, 20 Aug 2020 07:58:18 -0400 Winfried de Heiden via FreeIPA-users wrote: > Hi all, > For some reason, I messed up with several certificates > in FreeIPA,version: 4.8. One particular KRA cert seems problematic: > Request ID '20200820113800':status: CA_REJECTEDca-error: Server at > ":8080/ca/ee/ca/profileSubmit< > http://ipa.blabla.bla:8080/ca/ee/ca/profileSubmit>;" replied: > Missingcredential: sessionIDstuck: yeskey pair > storage:type=NSSDB,location='/etc/pki/pki- > tomcat/alias',nickname='cert-nickname=transportCertcert-pki- > kra',token='NSS Certificate DB',pin > setcertificate:type=NSSDB,location='/etc/pki/pki- > tomcat/alias',nickname='cert-nickname=transportCertcert-pki- > kra',token='NSS Certificate DB'CA: dogtag-ipa-ca-renew- > agentissuer: subject: expires: unknownpre-save command: > /usr/libexec/ipa/certmonger/stop_pkicadpost-save command: > /usr/libexec/ipa/certmonger/renew_ca_cert"transportCert cert-pki- > kra"track: yesauto-renew: yes > How to fix? We're seeing this on the IPA demo server as well, see BZ https://bugzilla.redhat.com/show_bug.cgi?id=1869605 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 ___ 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
[Freeipa-users] getcert status: CA_REJECTED
Hi all, For some reason, I messed up with several certificates in FreeIPA, version: 4.8. One particular KRA cert seems problematic: Request ID '20200820113800':status: CA_REJECTED ca-error: Server at ":8080/ca/ee/ca/profileSubmit" replied: Missing credential: sessionID stuck: yes key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='cert- nickname=transportCert cert-pki-kra',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki- tomcat/alias',nickname='cert-nickname=transportCert cert-pki- kra',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: subject:expires: unknownpre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "transportCert cert-pki-kra" track: yes auto-renew: yes How to fix? Winfried ___ 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
[Freeipa-users] Re: sss_ssh_authorizedkeys slow on IPA-server
Hi all, After all, no issues at all with FreeIPA. The reboot of the Cable modem caused changing the IPv6 Prefix Delegation, more or less destroying my IPv6 setup. After fixing IPv6 (enabled on IPA also :) ) all is going blazing fast again. Winfried Op 11-02-2020 om 16:01 schreef Winfried de Heiden via FreeIPA-users: Hi all, Got rid of the dropped packages by simply restarting the Cable modem/router... Anyway, this wasn't the problem. Still cannot find the reason why sss_ssh_authorizedkeys slow on IPA-server is so slow, ONLY on the IPA-server... Winfried Op 10-02-2020 om 13:44 schreef Winfried de Heiden via FreeIPA-users: Hi all, sssd 2.20 is being used. I cannot figure out why the network might cause problems since the "good clients" are running on the same network, switches etc. I dived into it anyway, finding a rather large and increasing number of dropped packages and dive into that first. Nevertheless, this hardly cannot be the cause since the issue only happens on the IPA-server itself... Winfried Sumit Bose via FreeIPA-users schreef op 10-02-2020 10:46: On Mon, Feb 10, 2020 at 09:54:04AM +0100, Winfried de Heiden via FreeIPA-users wrote: Hi all, Yep, I do use user-certs for authentication and it seems ocsp takes time; but only on the IPA-server. Even on a Rapsberry Pi 3 as an IPA-client, using the same IPA-server, it is 4 times faster... Hence; something seems going wrong in oscp, but what could be causing the problem? Hi, which versions of SSSD are using one the client and the server? Older version of SSSD might use NSS and do the certificate validation in the ssh responder process, newer version might use OpenSSL and do the validation with the help of p11_child. Not sure if any of this might be a reason. Maybe you can take network trace of the communication with the OCSP responder to see if the delay happens on the network? bye, Sumit Winfried Op 09-02-2020 om 22:06 schreef Alexander Bokovoy: > On su, 09 helmi 2020, Winfried de Heiden via FreeIPA-users wrote: > > Hi all, > > For some reason, for a particular user, sss_ssh_authorizedkeys is > > extremely slow on the IPA-server: > > time /usr/bin/sss_ssh_authorizedkeys ~real 0m9.520suser > > 0m0.022ssys 0m0.018s > > It will return all the public keys, but is is slow, causing > > SSH-login delays using a ssh-keys. > > On another CentOS Stream (8.1) IPA-client, using the same IPA-server: > > time /usr/bin/sss_ssh_authorizedkeys ~real 0m0.020suser > > 0m0.005ssys 0m0.003s > > Some difference...Adding "certificate_verification = no_ocsp" to > > sssd.conf on the IPA-server will bring back performance, but sound > > like a poor workaround. > > Any idea what is happening here? > > SSSD picks up certificates associated with the user entry for use as SSH > keys as well. I guess verification of those certificates via OCSP takes > time and that's why switching off the verification helps. > > ___ 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 ___ 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 ___ 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 ___ 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 ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsub
[Freeipa-users] Re: sss_ssh_authorizedkeys slow on IPA-server
Hi all, Got rid of the dropped packages by simply restarting the Cable modem/router... Anyway, this wasn't the problem. Still cannot find the reason why sss_ssh_authorizedkeys slow on IPA-server is so slow, ONLY on the IPA-server... Winfried Op 10-02-2020 om 13:44 schreef Winfried de Heiden via FreeIPA-users: Hi all, sssd 2.20 is being used. I cannot figure out why the network might cause problems since the "good clients" are running on the same network, switches etc. I dived into it anyway, finding a rather large and increasing number of dropped packages and dive into that first. Nevertheless, this hardly cannot be the cause since the issue only happens on the IPA-server itself... Winfried Sumit Bose via FreeIPA-users schreef op 10-02-2020 10:46: On Mon, Feb 10, 2020 at 09:54:04AM +0100, Winfried de Heiden via FreeIPA-users wrote: Hi all, Yep, I do use user-certs for authentication and it seems ocsp takes time; but only on the IPA-server. Even on a Rapsberry Pi 3 as an IPA-client, using the same IPA-server, it is 4 times faster... Hence; something seems going wrong in oscp, but what could be causing the problem? Hi, which versions of SSSD are using one the client and the server? Older version of SSSD might use NSS and do the certificate validation in the ssh responder process, newer version might use OpenSSL and do the validation with the help of p11_child. Not sure if any of this might be a reason. Maybe you can take network trace of the communication with the OCSP responder to see if the delay happens on the network? bye, Sumit Winfried Op 09-02-2020 om 22:06 schreef Alexander Bokovoy: > On su, 09 helmi 2020, Winfried de Heiden via FreeIPA-users wrote: > > Hi all, > > For some reason, for a particular user, sss_ssh_authorizedkeys is > > extremely slow on the IPA-server: > > time /usr/bin/sss_ssh_authorizedkeys ~real 0m9.520suser > > 0m0.022ssys 0m0.018s > > It will return all the public keys, but is is slow, causing > > SSH-login delays using a ssh-keys. > > On another CentOS Stream (8.1) IPA-client, using the same IPA-server: > > time /usr/bin/sss_ssh_authorizedkeys ~real 0m0.020suser > > 0m0.005ssys 0m0.003s > > Some difference...Adding "certificate_verification = no_ocsp" to > > sssd.conf on the IPA-server will bring back performance, but sound > > like a poor workaround. > > Any idea what is happening here? > > SSSD picks up certificates associated with the user entry for use as SSH > keys as well. I guess verification of those certificates via OCSP takes > time and that's why switching off the verification helps. > > ___ 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 ___ 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 ___ 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 ___ 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
[Freeipa-users] Re: sss_ssh_authorizedkeys slow on IPA-server
Hi all, sssd 2.20 is being used. I cannot figure out why the network might cause problems since the "good clients" are running on the same network, switches etc. I dived into it anyway, finding a rather large and increasing number of dropped packages and dive into that first. Nevertheless, this hardly cannot be the cause since the issue only happens on the IPA-server itself... Winfried Sumit Bose via FreeIPA-users schreef op 10-02-2020 10:46: On Mon, Feb 10, 2020 at 09:54:04AM +0100, Winfried de Heiden via FreeIPA-users wrote: Hi all, Yep, I do use user-certs for authentication and it seems ocsp takes time; but only on the IPA-server. Even on a Rapsberry Pi 3 as an IPA-client, using the same IPA-server, it is 4 times faster... Hence; something seems going wrong in oscp, but what could be causing the problem? Hi, which versions of SSSD are using one the client and the server? Older version of SSSD might use NSS and do the certificate validation in the ssh responder process, newer version might use OpenSSL and do the validation with the help of p11_child. Not sure if any of this might be a reason. Maybe you can take network trace of the communication with the OCSP responder to see if the delay happens on the network? bye, Sumit Winfried Op 09-02-2020 om 22:06 schreef Alexander Bokovoy: > On su, 09 helmi 2020, Winfried de Heiden via FreeIPA-users wrote: > > Hi all, > > For some reason, for a particular user, sss_ssh_authorizedkeys is > > extremely slow on the IPA-server: > > time /usr/bin/sss_ssh_authorizedkeys ~real 0m9.520suser > > 0m0.022ssys 0m0.018s > > It will return all the public keys, but is is slow, causing > > SSH-login delays using a ssh-keys. > > On another CentOS Stream (8.1) IPA-client, using the same IPA-server: > > time /usr/bin/sss_ssh_authorizedkeys ~real 0m0.020suser > > 0m0.005ssys 0m0.003s > > Some difference...Adding "certificate_verification = no_ocsp" to > > sssd.conf on the IPA-server will bring back performance, but sound > > like a poor workaround. > > Any idea what is happening here? > > SSSD picks up certificates associated with the user entry for use as SSH > keys as well. I guess verification of those certificates via OCSP takes > time and that's why switching off the verification helps. > > ___ 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 ___ 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 ___ 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
[Freeipa-users] Re: sss_ssh_authorizedkeys slow on IPA-server
Hi all, Seems like a usefull feature; oscp and I rather keep it enabled. On all other IPA-clients, even a Raspberry Pi 3, it is much much more fast. On the IPA-server is suffering here :( What could be causing this slowness Winfried Op 10-02-2020 om 08:13 schreef Sumit Bose via FreeIPA-users: On Sun, Feb 09, 2020 at 11:06:46PM +0200, Alexander Bokovoy via FreeIPA-users wrote: On su, 09 helmi 2020, Winfried de Heiden via FreeIPA-users wrote: Hi all, For some reason, for a particular user, sss_ssh_authorizedkeys is extremely slow on the IPA-server: time /usr/bin/sss_ssh_authorizedkeys ~real 0m9.520suser 0m0.022ssys 0m0.018s It will return all the public keys, but is is slow, causing SSH-login delays using a ssh-keys. On another CentOS Stream (8.1) IPA-client, using the same IPA-server: time /usr/bin/sss_ssh_authorizedkeys ~real 0m0.020suser 0m0.005ssys 0m0.003s Some difference...Adding "certificate_verification = no_ocsp" to sssd.conf on the IPA-server will bring back performance, but sound like a poor workaround. Any idea what is happening here? SSSD picks up certificates associated with the user entry for use as SSH keys as well. I guess verification of those certificates via OCSP takes time and that's why switching off the verification helps. Hi, if you are not interested in this feature at all you can disable it completely in recent versions of SSSD by setting 'ssh_use_certificate_keys = False' in the [ssh] section of sssd.conf. Please check if 'man sssd.conf' shows this option for your version of SSSD. HTH bye, Sumit -- / 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 ___ 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 ___ 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
[Freeipa-users] Re: sss_ssh_authorizedkeys slow on IPA-server
Hi all, Yep, I do use user-certs for authentication and it seems ocsp takes time; but only on the IPA-server. Even on a Rapsberry Pi 3 as an IPA-client, using the same IPA-server, it is 4 times faster... Hence; something seems going wrong in oscp, but what could be causing the problem? Winfried Op 09-02-2020 om 22:06 schreef Alexander Bokovoy: On su, 09 helmi 2020, Winfried de Heiden via FreeIPA-users wrote: Hi all, For some reason, for a particular user, sss_ssh_authorizedkeys is extremely slow on the IPA-server: time /usr/bin/sss_ssh_authorizedkeys ~real 0m9.520suser 0m0.022ssys 0m0.018s It will return all the public keys, but is is slow, causing SSH-login delays using a ssh-keys. On another CentOS Stream (8.1) IPA-client, using the same IPA-server: time /usr/bin/sss_ssh_authorizedkeys ~real 0m0.020suser 0m0.005ssys 0m0.003s Some difference...Adding "certificate_verification = no_ocsp" to sssd.conf on the IPA-server will bring back performance, but sound like a poor workaround. Any idea what is happening here? SSSD picks up certificates associated with the user entry for use as SSH keys as well. I guess verification of those certificates via OCSP takes time and that's why switching off the verification helps. ___ 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
[Freeipa-users] sss_ssh_authorizedkeys slow on IPA-server
Hi all, For some reason, for a particular user, sss_ssh_authorizedkeys is extremely slow on the IPA-server: time /usr/bin/sss_ssh_authorizedkeys ~real0m9.520suser 0m0.022ssys 0m0.018s It will return all the public keys, but is is slow, causing SSH-login delays using a ssh-keys. On another CentOS Stream (8.1) IPA-client, using the same IPA-server: time /usr/bin/sss_ssh_authorizedkeys ~real0m0.020suser 0m0.005ssys 0m0.003s Some difference...Adding "certificate_verification = no_ocsp" to sssd.conf on the IPA-server will bring back performance, but sound like a poor workaround. Any idea what is happening here? Some more details:CentOS Linux release 8.1.1911 (Core) (stream)ipa-client-4.8.0-13.module_el8.1.0+265+e1e65be4.x86_64sssd-common-2.2.0-19.el8.x86_64 Winfried ___ 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
[Freeipa-users] Re: ipa-server-upgrade failed
Hi all, I'll keep a watch on the bugzilla. For now; the upgrade succeeded and IPA is running perfectly. Thanks a lot! Winfried -Oorspronkelijk bericht- Van: Rob Crittenden via FreeIPA-users < freeipa-users@lists.fedorahosted.org> Antwoord-naar: FreeIPA users list Aan: Winfried de Heiden , FreeIPA users list < freeipa-users@lists.fedorahosted.org> Cc: Rob Crittenden Onderwerp: [Freeipa-users] Re: ipa-server-upgrade failed Datum: Sun, 26 Jan 2020 22:08:25 -0500 Winfried de Heiden wrote: > Hi all, > Fixed it, thanks for the tip Rob :-)!Certmonger was to blame or my > rather slow Udooboard Celeron processor.Anyway, instead of hacking > the upgrade script, I modified thecertmonger.serivce file by adding a > 180 secs (!!) sleep and extraTimeout: (The modified > certmonger.service was removed after the upgrade) > [Unit]Description=Certificate monitoring and PKI > enrollmentAfter=syslog.target network.target dbus.service > [Service]Type=dbusPIDFile=/var/run/certmonger.pidEnvironmentFile=- > /etc/sysconfig/certmongerExecStart=/usr/sbin/certmonger -S -p > /var/run/certmonger.pid -n $OPTSExecStartPost=/bin/sleep > 180TimeoutSec=240BusName=org.fedorahosted.certmonger > Runing "ipa-server-upgrade" finished OK now. Certmonger takes itś > timewhen it's (restarted, some dogtag-ipa-ca-r(enew ?) processes > eating mostof the cpu: > top - 16:00:24 up 18:51, 3 users, load average: 2.41, 1.87, > 1.37Tasks: 261 total, 6 running, 221 sleeping, 0 stopped, 34 > zombie%Cpu0 : 90.2 us, 7.8 sy, 0.0 ni, 0.0 id, 0.0 wa, 1.6 > hi, 0.3si, 0.0 st%Cpu1 : 92.4 us, 6.6 sy, 0.0 ni, 0.0 id, 0.0 > wa, 1.0 hi, 0.0si, 0.0 st%Cpu2 : 95.1 us, 3.6 sy, 0.0 ni, 0.0 > id, 0.0 wa, 1.3 hi, 0.0si, 0.0 st%Cpu3 : 88.6 us, 9.2 sy, 0.0 > ni, 0.0 id, 0.0 wa, 1.3 hi, 1.0si, 0.0 stMiB Mem : 3847.2 > total,335.4 free, 2154.9 used, 1356.9 buff/cacheMiB > Swap: 3968.0 total, 3968.0 free, 0.0 used. 1452.0 avail > Mem > PID USER PR NIVIRTRESSHR > S %CPU %MEM TIME+COMMAND 21750 > root 20 0 401244 85296 22612 R 85.9 2.2 0:13.36dogtag- > ipa-ca-r 21764 > root 20 0 386700 72880 22508 R 78.4 1.8 0:06.93dogtag- > ipa-ca-r 21771 > root 20 0 161788 27332 10812 R 74.5 0.7 0:03.65dogtag- > ipa-ca-r 21758 > root 20 0 394512 78340 22436 R 67.3 2.0 0:10.65dogtag- > ipa-ca-r 21746 > root 20 0 0 0 0 Z 51.6 0.0 0:15.36dogtag- > ipa-ca-r 21778 > root 20 0 106004 1220 0 > R 24.8 0.0 0:00.76certmonger > This seems like a new issue for me... Certainly, the Udoo x86 isn't > thefasted in the world, but was running IPA bravely the last year... > Am Ihitting the bug Rob mentioned? Is there a bug report somewhere > totrack... I'll like to see it fixed in CentOS 8. It should be in 8.2 beta, https://bugzilla.redhat.com/show_bug.cgi?id=1763745 > "getcert list" showed "/var/lib/ipa/private/httpd.key" > and"/var/lib/ipa/certs/httpd.crt" wating for PIN. Running "ipa- > getcertresubmit -i 20200126151811 -p /var/lib/ipa/passwds/ipa.xxx- > 443-RSA"fixed it. I can't explain that. rob > Winfried > -Oorspronkelijk bericht-*Van*: Rob Crittenden < > rcrit...@redhat.com > <mailto:rob%20crittenden%20%3crcrit...@redhat.com%3e>>*Aan*: FreeIPA > users list freeipa%20users%20list%20%3cfreeipa-us...@lists.fedorahosted.org%3e>> > *Cc*: Winfried de Heiden <mailto:winfried%20de%20heiden%20%3c...@dds.nl%3e>>*Onderwerp*: Re: > [Freeipa-users] Re: ipa-server-upgrade failed*Datum*: Sat, 25 Jan > 2020 17:04:39 -0500 > Winfried de Heiden via FreeIPA-users wrote: > > Hi all, > > /var/lib/ipa/private/httpd.key was in a status "waiting for PIN", > > but Idid brong is back to life using "ipa-getcert resubmit -i > > 20200117075404-p /var/lib/ipa/passwds/-443-RSA. All certss look > > fine now. "getcert list" works, although it's a bit slow the first > > time (runningon a Udoo x86 board with a celeron) > > Just to be shure about dbus, I restarted the entire machine; no > > success. :-( > > Timing issue and/or casued by my rather slow Udoo board.? > > It is very possible. I fixed an issue in certmonger where every time > it > forked (and it forks a LOT) it closed ALL the fds it knew about. On > containers this was 1M. It took a LONG time. The default is a more > modest 1k but can still take a while given the amount of forks that > certmonger does. This is fixed upstream, and I don't kno
[Freeipa-users] Re: ipa-server-upgrade failed
Hi all, Fixed it, thanks for the tip Rob :-)! Certmonger was to blame or my rather slow Udooboard Celeron processor. Anyway, instead of hacking the upgrade script, I modified the certmonger.serivce file by adding a 180 secs (!!) sleep and extra Timeout: (The modified certmonger.service was removed after the upgrade) [Unit] Description=Certificate monitoring and PKI enrollment After=syslog.target network.target dbus.service [Service] Type=dbus PIDFile=/var/run/certmonger.pid EnvironmentFile=-/etc/sysconfig/certmonger ExecStart=/usr/sbin/certmonger -S -p /var/run/certmonger.pid -n $OPTS ExecStartPost=/bin/sleep 180 TimeoutSec=240 BusName=org.fedorahosted.certmonger Runing "ipa-server-upgrade" finished OK now. Certmonger takes itś time when it's (restarted, some dogtag-ipa-ca-r(enew ?) processes eating most of the cpu: top - 16:00:24 up 18:51, 3 users, load average: 2.41, 1.87, 1.37 Tasks: 261 total, 6 running, 221 sleeping, 0 stopped, 34 zombie %Cpu0 : 90.2 us, 7.8 sy, 0.0 ni, 0.0 id, 0.0 wa, 1.6 hi, 0.3 si, 0.0 st %Cpu1 : 92.4 us, 6.6 sy, 0.0 ni, 0.0 id, 0.0 wa, 1.0 hi, 0.0 si, 0.0 st %Cpu2 : 95.1 us, 3.6 sy, 0.0 ni, 0.0 id, 0.0 wa, 1.3 hi, 0.0 si, 0.0 st %Cpu3 : 88.6 us, 9.2 sy, 0.0 ni, 0.0 id, 0.0 wa, 1.3 hi, 1.0 si, 0.0 st MiB Mem : 3847.2 total,335.4 free, 2154.9 used, 1356.9 buff/cache MiB Swap: 3968.0 total, 3968.0 free, 0.0 used. 1452.0 avail Mem PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+ COMMAND 21750 root 20 0 401244 85296 22612 R 85.9 2.2 0:13.36 dogtag-ipa-ca-r 21764 root 20 0 386700 72880 22508 R 78.4 1.8 0:06.93 dogtag-ipa-ca-r 21771 root 20 0 161788 27332 10812 R 74.5 0.7 0:03.65 dogtag-ipa-ca-r 21758 root 20 0 394512 78340 22436 R 67.3 2.0 0:10.65 dogtag-ipa-ca-r 21746 root 20 0 0 0 0 Z 51.6 0.0 0:15.36 dogtag-ipa-ca-r 21778 root 20 0 106004 1220 0 R 24.8 0.0 0:00.76 certmonger This seems like a new issue for me... Certainly, the Udoo x86 isn't the fasted in the world, but was running IPA bravely the last year... Am I hitting the bug Rob mentioned? Is there a bug report somewhere to track... I'll like to see it fixed in CentOS 8. "getcert list" showed "/var/lib/ipa/private/httpd.key" and "/var/lib/ipa/certs/httpd.crt" wating for PIN. Running "ipa-getcert resubmit -i 20200126151811 -p /var/lib/ipa/passwds/ipa.xxx-443-RSA" fixed it. Winfried -Oorspronkelijk bericht- Van: Rob Crittenden Aan: FreeIPA users list Cc: Winfried de Heiden Onderwerp: Re: [Freeipa-users] Re: ipa-server-upgrade failed Datum: Sat, 25 Jan 2020 17:04:39 -0500 Winfried de Heiden via FreeIPA-users wrote: > Hi all, > /var/lib/ipa/private/httpd.key was in a status "waiting for PIN", but > Idid brong is back to life using "ipa-getcert resubmit -i > 20200117075404-p /var/lib/ipa/passwds/-443-RSA. All certss look > fine now. "getcert list" works, although it's a bit slow the first > time (runningon a Udoo x86 board with a celeron) > Just to be shure about dbus, I restarted the entire machine; no > success. :-( > Timing issue and/or casued by my rather slow Udoo board.? It is very possible. I fixed an issue in certmonger where every time itforked (and it forks a LOT) it closed ALL the fds it knew about. Oncontainers this was 1M. It took a LONG time. The default is a moremodest 1k but can still take a while given the amount of forks thatcertmonger does. This is fixed upstream, and I don't know of aworkaround, but this can definitely lead to timeout issues if certmongeris being restarted immediately before this failure. To diagnose it see what the load on the system is and what processes arerunning. If you see dozens of certmonger processes with high load thenthat's probably it. You'd have to hack the update script to do a sleepto give things a chance to settle down. rob > Winfried > > > > > Rob Crittenden schreef op za 25-01-2020 om 14:53 [-0500]: > > Winfried de Heiden via FreeIPA-users wrote: > > > Hi all, > > > Using CentOS Linux release 8.1.1911 and the Stream > > > repositories,upgrading IPA fails: > > > (Upgrade > > > ipa-server-common-4.8.0-13.module_el8.1.0+265+e1e65be4.noarch@AppStream > > > Upgradedipa-server-common-4.8.0- > > > 11.module_el8.1.0+253+3b90c921.noarch @@System ) > > > Running ipa-server-upgrade manually will result in: > > > [Upgrading CA schema]CA schema update complete (no > > > changes)[Verifying that CA audit signing cert has 2 year > > > validity][Update certmonger cert
[Freeipa-users] Re: ipa-server-upgrade failed
Too bad, is already the latest version: pm -qi nssName: nssVersion : 3.44.0Release : 9.el8_1Architecture: x86_64~ Winfried Alexander Bokovoy via FreeIPA-users schreef op za 25-01-2020 om 22:38 [+0200]: > On la, 25 tammi 2020, Winfried de Heiden via FreeIPA-users wrote: > > Hi all, > > Using CentOS Linux release 8.1.1911 and the Stream repositories,upgrading > > IPA fails: > > (Upgrade ipa-server-common-4.8.0-13.module_el8.1.0+265+e1e65be4.noarch > > @AppStream Upgraded > > ipa-server-common-4.8.0-11.module_el8.1.0+253+3b90c921.noarch @@System ) > > Running ipa-server-upgrade manually will result in: > > [Upgrading CA schema]CA schema update complete (no changes)[Verifying that > > CA audit signing cert has 2 year validity][Update certmonger certificate > > renewal configuration]Introspect error on > > :1.417:/org/fedorahosted/certmonger:dbus.exceptions.DBusException: > > org.freedesktop.DBus.Error.NoReply: Didnot receive a reply. Possible causes > > include: the remote applicationdid not send a reply, the message bus > > security policy blocked thereply, the reply timeout expired, or the network > > connection was broken. > > Any sugestions? > > try upgrade nss package first. I have seen some reports that it helps. > -- / Alexander BokovoySr. Principal Software EngineerSecurity / Identity > Management EngineeringRed 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 ___ 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
[Freeipa-users] Re: ipa-server-upgrade failed
Hi all, /var/lib/ipa/private/httpd.key was in a status "waiting for PIN", but I did brong is back to life using "ipa-getcert resubmit -i 20200117075404 -p /var/lib/ipa/passwds/-443-RSA. All certss look fine now. "getcert list" works, although it's a bit slow the first time (running on a Udoo x86 board with a celeron) Just to be shure about dbus, I restarted the entire machine; no success. :-( Timing issue and/or casued by my rather slow Udoo board.? Winfried Rob Crittenden schreef op za 25-01-2020 om 14:53 [-0500]: > Winfried de Heiden via FreeIPA-users wrote: > > Hi all, > > > > Using CentOS Linux release 8.1.1911 and the Stream repositories, > > upgrading IPA fails: > > > > (Upgrade ipa-server-common-4.8.0-13.module_el8.1.0+265+e1e65be4.noarch > > @AppStream > > Upgraded > > ipa-server-common-4.8.0-11.module_el8.1.0+253+3b90c921.noarch @@System ) > > > > Running ipa-server-upgrade manually will result in: > > > > [Upgrading CA schema] > > CA schema update complete (no changes) > > [Verifying that CA audit signing cert has 2 year validity] > > [Update certmonger certificate renewal configuration] > > Introspect error on :1.417:/org/fedorahosted/certmonger: > > dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did > > not receive a reply. Possible causes include: the remote application did > > not send a reply, the message bus security policy blocked the reply, the > > reply timeout expired, or the network connection was broken. > > I assume certmonger and dbus services are running? > > Does `getcert list` work? > > The dbus service sometimes isn't too fond of being restarted but you > could try that. > > 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
[Freeipa-users] ipa-server-upgrade failed
Hi all, Using CentOS Linux release 8.1.1911 and the Stream repositories, upgrading IPA fails: (Upgrade ipa-server-common-4.8.0- 13.module_el8.1.0+265+e1e65be4.noarch @AppStream Upgraded ipa-server-common-4.8.0- 11.module_el8.1.0+253+3b90c921.noarch @@System ) Running ipa-server-upgrade manually will result in: [Upgrading CA schema] CA schema update complete (no changes) [Verifying that CA audit signing cert has 2 year validity] [Update certmonger certificate renewal configuration] Introspect error on :1.417:/org/fedorahosted/certmonger: dbus.exceptions.DBusException: org.freedesktop.DBus.Error.NoReply: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken. Any sugestions? Winfried ___ 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
[Freeipa-users] FreeIPA - EL8 - smart card login
Running FreeIPA 4.7.1, on CentOS 8, I configured IPA-server to use smartcard login follwoing https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/configuring_and_managing_identity_management/configuring-idm-for-smart-card-auth_configuring-and-managing-idm#conf-idm-client-for-smart-card-auth_configuring-idm-for-smart-card-auth I configured a CentOS 8 machine to use smartcard-login. After configuring the IPA-client, running the scripts produced by ipa-advise will show an error: ./config-client-for-smart-card-auth.sh /etc/ipa/ca.crt ~ ERROR: Failed to add module "OpenSC". Probable cause : "Unknown PKCS #11 error.". Systemwide CA database updated. Systemwide CA database updated. The ipa-certupdate command was successful Logging in a Yubikey 5 works fine. The error is caused by this line: echo "" | modutil -dbdir /etc/pki/nssdb -add "OpenSC" -libfile /usr/lib64/opensc-pkcs11.so Now, what going on here and can this error really be ignored? Is it worth to create a Bugzilla? Same error also aoocurs on a fresh RHEL 8.1 machine. Winfried ___ 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
[Freeipa-users] Re: sudo and hostgroups
Hi all, Awsome! OK, cannot user "ipaservers" hostgroup, but creating a new one wil work! Thanks a lot! Create a new hostgroup and used that one for the sudorule: [admin@freeipa1 ~]$ ipa sudorule-show sudo_freeipa_admins Rule name: sudo_freeipa_admins Enabled: TRUE Command category: all RunAs User category: all RunAs Group category: all User Groups: admins Host Groups: freeipa-servers The new hostgroup has one momeber: server-group "ipaservers", makes it easier to manage rather than adding each host: [admin@freeipa1 ~]$ ipa hostgroup-show freeipa-servers Host-group: freeipa-servers Description: https://pagure.io/freeipa/issue/7284 Member host-groups: ipaservers Member of Sudo rule: sudo_freeipa_admins Indirect Member hosts: freeipa2.example.local, freeipa1.example.local sudo will work now! [admin@freeipa1 ~]$ sudo -l Matching Defaults entries for admin on freeipa1: !visiblepw, always_set_home, match_group_by_gid, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin User admin may run the following commands on freeipa1: (ALL : ALL) ALL Rob Crittenden schreef op 05-12-2018 14:04: Winfried de Heiden via FreeIPA-users wrote: Hi all, On a brand new install, sudo for hostgroup seems not to work. Ik create a sudo rule for admins, only to to "averything" on all servers within the hostgroup "ipaservers": Rule name: s3_sudo_freeipa_admins Enabled: TRUE Command category: all RunAs User category: all RunAs Group category: all User Groups: admins Host Groups: ipaservers However, user admins is not allowed to to so: admin@freeipa1 <mailto:admin@freeipa1> ~]$ sudo -l [sudo] password for admin: Sorry, user admin may not run sudo on freeipa1. Removing the group but adding the two FreeIPA-servers: Rule name: s3_sudo_freeipa_admins Enabled: TRUE Command category: all RunAs User category: all RunAs Group category: all User Groups: admins Hosts: freeipa1.example.local, freeipa2.example.local After cleaning the sssd-cache: sudo -l [sudo] password for admin: Matching Defaults entries for admin on freeipa1: !visiblepw, always_set_home, match_group_by_gid, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin User admin may run the following commands on freeipa1: (ALL : ALL) ALL There are not clients yet, this issues was reproduced on a brand new CentOS 7.5 IPA installation with no modifications or else... What's hapening here? This is a bug. ipaservers is treated specially internally, see https://pagure.io/freeipa/issue/7284 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] sudo and hostgroups
Hi all, On a brand new install, sudo for hostgroup seems not to work. Ik create a sudo rule for admins, only to to "averything" on all servers within the hostgroup "ipaservers": Rule name: s3_sudo_freeipa_admins Enabled: TRUE Command category: all RunAs User category: all RunAs Group category: all User Groups: admins Host Groups: ipaservers However, user admins is not allowed to to so: admin@freeipa1 ~]$ sudo -l [sudo] password for admin: Sorry, user admin may not run sudo on freeipa1. Removing the group but adding the two FreeIPA-servers: Rule name: s3_sudo_freeipa_admins Enabled: TRUE Command category: all RunAs User category: all RunAs Group category: all User Groups: admins Hosts: freeipa1.example.local, freeipa2.example.local After cleaning the sssd-cache: sudo -l [sudo] password for admin: Matching Defaults entries for admin on freeipa1: !visiblepw, always_set_home, match_group_by_gid, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin User admin may run the following commands on freeipa1: (ALL : ALL) ALL There are not clients yet, this issues was reproduced on a brand new CentOS 7.5 IPA installation with no modifications or else... What's hapening here? Winfried signature.asc Description: This is a digitally signed message part ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: OTP sudo prompts
Hi all, Mmmm, I was afraid so. Any (nearby) plans for a "feature enhancement" on this :) Winfried Op 27-11-18 om 13:47 schreef Sumit Bose: On Tue, Nov 27, 2018 at 01:34:25PM +0100, Winfried de Heiden wrote: Hi all, I tried this as well, created a user for which otp and password is both allowe to enforce OTP login on certain hosts but sudo without otp: Enforcing 2FA for a host currently means enforcing it for all services which are handled by SSSD via PAM including sudo. bye, Sumit ipa user-show winfried User login: winfried First name: Winfried Last name: de Heiden Home directory: /home/winfried Login shell: /bin/bash Principal name: winfried@IPA.EXAMPLE.LOCAL Principal alias: winfried@IPA.EXAMPLE.LOCAL Email address: winfried@ipa.example.local UID: 100018 GID: 100018 User authentication types: password, otp Account disabled: False Password: True Member of groups: ipausers Member of Sudo rule: reboot Member of HBAC rule: freeipa-clientxx Kerberos keys available: True The host indeed will force otp upon login: [winfried@freeipa-client03 ~]$ ipa host-show $(hostname) Host name: freeipa-client03.ipa.example.local Principal name: host/freeipa-client03.ipa.example.local@IPA.EXAMPLE.LOCAL Principal alias: host/freeipa-client03.ipa.example.local@IPA.EXAMPLE.LOCAL SSH public key fingerprint: SHA256:a03P2T5BqumEXarmQlZxqD9VNIw6l9VTSXkhRp3wKo8 (ssh-rsa), SHA256:PlV7LeKRipRw5Fild77ENuazjUWhEIQbwxACegdj+34 (ecdsa-sha2-nistp256), SHA256:DiPQ/ EXr+w4ZSvCZBkdddGGYcJuITR64uIaMSbr0o0s (ssh-ed25519) Authentication Indicators: otp Password: False Member of Sudo rule: reboot Member of HBAC rule: freeipa-clientxx Keytab: True Managed by: freeipa-client03.ipa.example.local However, leaving the second empty, sudo will fail: sudo -l First Factor: Second Factor (optional): Sorry, try again. First Factor: Second Factor (optional): Sorry, try again. First Factor: Second Factor (optional): sudo: 3 incorrect password attempts Both IPA-server and client are running on CentOS 7.5. Op 23-03-18 om 09:32 schreef Sumit Bose via FreeIPA-users: On Thu, Mar 22, 2018 at 10:28:17AM -0700, Sean Hogan via FreeIPA-users wrote: Hello, We are implementing OTP for a new deployment and we can log in with the otp codes however when trying to sudo it fails. We would like to use the 2fa to log in but single factor is ok for sudo escalation. Is OTP supposed You have to allow on the server that the user can use both 1FA (password) or 2FA, see --user-auth-type option of 'ipa user-add'. To force 2FA at the log in you have to define on the server that the host requires the 'OTP' authentication indicator, see --auth-ind option of 'ipa host-mod' HTH bye, Sumit to be getting involved when issuing sudo commands? bob@ipa-client1$ sudo cat /etc/resolv.conf First Factor: Second Factor: Sorry, try again. First Factor: sudo: 1 incorrect password attempt ipa-server-dns-4.5.0-21.el7_4.2.2.noarch python-libipa_hbac-1.15.2-50.el7_4.6.x86_64 python-ipaddress-1.0.16-2.el7.noarch ipa-common-4.5.0-21.el7_4.2.2.noarch ipa-client-common-4.5.0-21.el7_4.2.2.noarch python2-ipalib-4.5.0-21.el7_4.2.2.noarch ipa-server-common-4.5.0-21.el7_4.2.2.noarch ipa-client-4.5.0-21.el7_4.2.2.x86_64 libipa_hbac-1.15.2-50.el7_4.6.x86_64 python2-ipaclient-4.5.0-21.el7_4.2.2.noarch python2-ipaserver-4.5.0-21.el7_4.2.2.noarch sssd-ipa-1.15.2-50.el7_4.6.x86_64 python-iniparse-0.4-9.el7.noarch ipa-server-4.5.0-21.el7_4.2.2.x86_64 Sean Hogan ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org signature.asc Description: OpenPGP digital signature ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: OTP sudo prompts
Hi all, I tried this as well, created a user for which otp and password is both allowe to enforce OTP login on certain hosts but sudo without otp: ipa user-show winfried User login: winfried First name: Winfried Last name: de Heiden Home directory: /home/winfried Login shell: /bin/bash Principal name: winfried@IPA.EXAMPLE.LOCAL Principal alias: winfried@IPA.EXAMPLE.LOCAL Email address: winfried@ipa.example.local UID: 100018 GID: 100018 User authentication types: password, otp Account disabled: False Password: True Member of groups: ipausers Member of Sudo rule: reboot Member of HBAC rule: freeipa-clientxx Kerberos keys available: True The host indeed will force otp upon login: [winfried@freeipa-client03 ~]$ ipa host-show $(hostname) Host name: freeipa-client03.ipa.example.local Principal name: host/freeipa-client03.ipa.example.local@IPA.EXAMPLE.LOCAL Principal alias: host/freeipa-client03.ipa.example.local@IPA.EXAMPLE.LOCAL SSH public key fingerprint: SHA256:a03P2T5BqumEXarmQlZxqD9VNIw6l9VTSXkhRp3wKo8 (ssh-rsa), SHA256:PlV7LeKRipRw5Fild77ENuazjUWhEIQbwxACegdj+34 (ecdsa-sha2-nistp256), SHA256:DiPQ/EXr+w4ZSvCZBkdddGGYcJuITR64uIaMSbr0o0s (ssh-ed25519) Authentication Indicators: otp Password: False Member of Sudo rule: reboot Member of HBAC rule: freeipa-clientxx Keytab: True Managed by: freeipa-client03.ipa.example.local However, leaving the second empty, sudo will fail: sudo -l First Factor: Second Factor (optional): Sorry, try again. First Factor: Second Factor (optional): Sorry, try again. First Factor: Second Factor (optional): sudo: 3 incorrect password attempts Both IPA-server and client are running on CentOS 7.5. Op 23-03-18 om 09:32 schreef Sumit Bose via FreeIPA-users: On Thu, Mar 22, 2018 at 10:28:17AM -0700, Sean Hogan via FreeIPA-users wrote: Hello, We are implementing OTP for a new deployment and we can log in with the otp codes however when trying to sudo it fails. We would like to use the 2fa to log in but single factor is ok for sudo escalation. Is OTP supposed You have to allow on the server that the user can use both 1FA (password) or 2FA, see --user-auth-type option of 'ipa user-add'. To force 2FA at the log in you have to define on the server that the host requires the 'OTP' authentication indicator, see --auth-ind option of 'ipa host-mod' HTH bye, Sumit to be getting involved when issuing sudo commands? bob@ipa-client1$ sudo cat /etc/resolv.conf First Factor: Second Factor: Sorry, try again. First Factor: sudo: 1 incorrect password attempt ipa-server-dns-4.5.0-21.el7_4.2.2.noarch python-libipa_hbac-1.15.2-50.el7_4.6.x86_64 python-ipaddress-1.0.16-2.el7.noarch ipa-common-4.5.0-21.el7_4.2.2.noarch ipa-client-common-4.5.0-21.el7_4.2.2.noarch python2-ipalib-4.5.0-21.el7_4.2.2.noarch ipa-server-common-4.5.0-21.el7_4.2.2.noarch ipa-client-4.5.0-21.el7_4.2.2.x86_64 libipa_hbac-1.15.2-50.el7_4.6.x86_64 python2-ipaclient-4.5.0-21.el7_4.2.2.noarch python2-ipaserver-4.5.0-21.el7_4.2.2.noarch sssd-ipa-1.15.2-50.el7_4.6.x86_64 python-iniparse-0.4-9.el7.noarch ipa-server-4.5.0-21.el7_4.2.2.x86_64 Sean Hogan ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org signature.asc Description: OpenPGP digital signature ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Replica install on RPI3
Hi all, See https://www.freeipa.org/page/ARM As mentioned earlier: I applied these settings but it wasn't enough. The startup_timeout was set at a huge 1200 but somewhere during a restart, it will complain: ... server did not start after 60s\npkispawn: ERROR ... server failed to restart\n') It's complaining about 60 seconds, not 1200 so I guess there's sme other value to set, somewhere Winfried -Oorspronkelijk bericht- Van: Rob Crittenden via FreeIPA-users Antwoord-naar: FreeIPA users list Aan: FreeIPA users list Cc: Winfried de Heiden , Fraser Tweedale , Rob Crittenden Onderwerp: [Freeipa-users] Re: Replica install on RPI3 Datum: Mon, 5 Nov 2018 11:25:21 -0500 Winfried de Heiden via FreeIPA-users wrote: Hi all, Believe me, after modifying "startup_timeout" in/usr/lib/python3.7/site-packages/ipalib/constants.py and/etc/ipa/default.conf is does run on a Pi as a Master but obviously thisis not enough fiir the Replica. See https://www.freeipa.org/page/ARM I did not add this post to discuss whether it is usefull to run on a P,I try to find out which install parameter (I guess) to modify in whichfile. I had FreeIPA running Master running for months on a Pi. It ranstable :) There are multiple reports of it (and related hardware like the bananapi) running fine. How much of a good idea it is is up for debate ;-) TBH I'm glad you're creating a replica with a CA so you don't have asingle point-of-failure. rob Winfried Fraser Tweedale via FreeIPA-users schreef op 05-11-2018 0:37: Dogtag CA is a massive enterprise Java program. Can't do much aboutit. Run a CA-less deployment, or run a CA-ful deployment withRaspberryPi replicas having no CA, and CA replicas running onmachines with more memory and more grunt. Cheers,Fraser On Sun, Nov 04, 2018 at 04:04:27PM +0100, Winfried de Heiden viaFreeIPA-users wrote: Hi all,can't tell it's the only issue. Installing the replica without CAworks well. The error happens during a restart during installationwich take too much time. Don't know what will go wrong after fixingthis issueWinfriedJohn Keates via FreeIPA-users schreef op za 03-11-2018 om 16:41 [+0100]: Ah, so the install went fine but the CA startup is the onlyremaining issue? John On 3 Nov 2018, at 16:39, Winfried de Heiden via FreeIPA-users wrote: Hi all,Yes, the Pi is too slow but funny enough it can work perfectly.The DogTag CA server just takes a painfull time to start. I had a Pirunning as just a master for months quite well, but start Dogtag tooka very long time, but afterwards it all ran well in a smallenvironment (@home...) As mentioned, just for the sake of trying and Pi are so cheap, I'm trying to setup a Pi Replica but default setup timeout settingsneed a modification... Winfried John Keates schreef op za 03-11-2018 om 16:26 [+0100]: My suggestion would be: don’t run it on a Pi, it’s not fastenough. But you came to that conclusion already, so I guess the nextissue would be: where does it fail?I’m assuming the rpm install worksout but ipa-server-install doesn’t? Or does that work but does thestarting of all the components time out? If it’s just the installation that’s failing, you can getaround that by running the install in an emulated ARM machine first,and then copying the filesystem over to the Pi. John On 3 Nov 2018, at 15:53, Winfried de Heiden via FreeIPA-users wrote: Hi all,Just because we can and a Rapsberry Pi 3 is cheap, I'm tryingto install a FreeIPA replica on Fedora 29 ARM. It looks like theRaspberry is a bit too slow for default installation settings: 018-11-03T12:27:12Z DEBUG stderr=WARNING: Password wasgarbage collected before it was cleared.password file contains nodatapkispawn: ERROR... server did not start after60spkispawn: ERROR... server failed to restart 2018-11-03T12:27:12Z CRITICAL Failed to configure CAinstance: CalledProcessError(Command ['/usr/sbin/pkispawn', '-s','CA', '-f', '/tmp/tmpv2y32e9l'] returned non-zero exit status 1:'WARNING: Password was garbage collected before it wascleared.\npassword file contains no data\npkispawn: ERROR ... server did not start after 60s\npkispawn: ERROR ... server failed to restart\n')2018-11-03T12:27:12Z CRITICAL Seethe installation logs and the following files/directories for moreinformation:2018-11-03T12:27:12Z CRITICAL /var/log/pki/pki-tomcat2018-11-03T12:27:12Z DEBUG Traceback (mostrecent call last): File"/usr/lib/python3.7/site-packages/ipaserver/install/dogtaginstance.py",line 164, in spawn_instanceipautil.run(args, nolog=nolog_list) File "/usr/lib/python3.7/site-packages/ipapython/ipautil.py", line573, in run p.returncode, arg_string, output_log, error_logipapython.ipautil.CalledProcessError: CalledProcessError(Command['/usr/sbin/pkispawn', '-s', 'CA', '-f', '/tmp/tmpv2y32e9l'] returnednon-zero exit status 1: 'WARNING: Password was garbage collected b
[Freeipa-users] Re: Replica install on RPI3
Hi all, Believe me, after modifying "startup_timeout" in /usr/lib/python3.7/site-packages/ipalib/constants.py and /etc/ipa/default.conf is does run on a Pi as a Master but obviously this is not enough fiir the Replica. I did not add this post to discuss whether it is usefull to run on a P, I try to find out which install parameter (I guess) to modify in which file. I had FreeIPA running Master running for months on a Pi. It ran stable :) Winfried Fraser Tweedale via FreeIPA-users schreef op 05-11-2018 0:37: Dogtag CA is a massive enterprise Java program. Can't do much about it. Run a CA-less deployment, or run a CA-ful deployment with RaspberryPi replicas having no CA, and CA replicas running on machines with more memory and more grunt. Cheers, Fraser On Sun, Nov 04, 2018 at 04:04:27PM +0100, Winfried de Heiden via FreeIPA-users wrote: Hi all, can't tell it's the only issue. Installing the replica without CA works well. The error happens during a restart during installation wich take too much time. Don't know what will go wrong after fixing this issue Winfried John Keates via FreeIPA-users schreef op za 03-11-2018 om 16:41 [+0100]: > Ah, so the install went fine but the CA startup is the only remaining issue? > John > > > On 3 Nov 2018, at 16:39, Winfried de Heiden via FreeIPA-users wrote: > > > > Hi all, > > Yes, the Pi is too slow but funny enough it can work perfectly. The DogTag CA server just takes a painfull time to start. I had a Pi running as just a master for months quite well, but start Dogtag took a very long time, but afterwards it all ran well in a small environment (@home...) > > As mentioned, just for the sake of trying and Pi are so cheap, I' m trying to setup a Pi Replica but default setup timeout settings need a modification... > > Winfried > > > > > > John Keates schreef op za 03-11-2018 om 16:26 [+0100]: > > > My suggestion would be: don’t run it on a Pi, it’s not fast enough. But you came to that conclusion already, so I guess the next issue would be: where does it fail?I’m assuming the rpm install works out but ipa-server-install doesn’t? Or does that work but does the starting of all the components time out? > > > > > > If it’s just the installation that’s failing, you can get around that by running the install in an emulated ARM machine first, and then copying the filesystem over to the Pi. > > > > > > John > > > > > > > > > > On 3 Nov 2018, at 15:53, Winfried de Heiden via FreeIPA-users wrote: > > > > > > > > Hi all, > > > > Just because we can and a Rapsberry Pi 3 is cheap, I'm trying to install a FreeIPA replica on Fedora 29 ARM. It looks like the Raspberry is a bit too slow for default installation settings: > > > > 018-11-03T12:27:12Z DEBUG stderr=WARNING: Password was garbage collected before it was cleared.password file contains no datapkispawn: ERROR ... server did not start after 60spkispawn: ERROR... server failed to restart > > > > 2018-11-03T12:27:12Z CRITICAL Failed to configure CA instance: CalledProcessError(Command ['/usr/sbin/pkispawn', '-s', 'CA', '-f', '/tmp/tmpv2y32e9l'] returned non-zero exit status 1: 'WARNING: Password was garbage collected before it was cleared.\npassword file contains no data\npkispawn: ERROR ... server did not start after 60s\npkispawn: ERROR... server failed to restart\n')2018-11-03T12:27:12Z CRITICAL See the installation logs and the following files/directories for more information:2018-11-03T12:27:12Z CRITICAL /var/log/pki/pki-tomcat2018-11-03T12:27:12Z DEBUG Traceback (most recent call last): File "/usr/lib/python3.7/site-packages/ipaserver/install/dogtaginstance.py", line 164, in spawn_instanceipautil.run(args, nolog=nolog_list) File "/usr/lib/python3.7/site-packages/ipapython/ipautil.py", line 573, in runp.returncode, arg_string, output_log, error_log ipapython.ipautil.CalledProcessError: CalledProcessError(Command ['/usr/sbin/pkispawn', '-s', 'CA', '-f', '/tmp/tmpv2y32e9l'] returned non-zero exit status 1: 'WARNING: Password was garbage collected before it was cleared.\npassword file contains no data\npkispawn: ERROR... server did not start after 60s\npkispawn: ERROR... server failed to restart\n') > > > > I did change the "startup_timeout" in /usr/lib/python3.7/site-packages/ipalib/constants.py and /etc/ipa/default.conf but it doens't seem to be enough. > > > > Any sugestion? > > > > Winfried > > > > ___ > > > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > > > > To unsubscribe send an ema
[Freeipa-users] Re: Replica install on RPI3
Hi all, can't tell it's the only issue. Installing the replica without CA works well. The error happens during a restart during installation wich take too much time. Don't know what will go wrong after fixing this issue Winfried John Keates via FreeIPA-users schreef op za 03-11-2018 om 16:41 [+0100]: > Ah, so the install went fine but the CA startup is the only remaining issue? > John > > > On 3 Nov 2018, at 16:39, Winfried de Heiden via FreeIPA-users > > wrote: > > > > Hi all, > > Yes, the Pi is too slow but funny enough it can work perfectly. The DogTag > > CA server just takes a painfull time to start. I had a Pi running as just a > > master for months quite well, but start Dogtag took a very long time, but > > afterwards it all ran well in a small environment (@home...) > > As mentioned, just for the sake of trying and Pi are so cheap, I' m trying > > to setup a Pi Replica but default setup timeout settings need a > > modification... > > Winfried > > > > > > John Keates schreef op za 03-11-2018 om 16:26 [+0100]: > > > My suggestion would be: don’t run it on a Pi, it’s not fast enough. But > > > you came to that conclusion already, so I guess the next issue would be: > > > where does it fail?I’m assuming the rpm install works out but > > > ipa-server-install doesn’t? Or does that work but does the starting of > > > all the components time out? > > > > > > If it’s just the installation that’s failing, you can get around that by > > > running the install in an emulated ARM machine first, and then copying > > > the filesystem over to the Pi. > > > > > > John > > > > > > > > > > On 3 Nov 2018, at 15:53, Winfried de Heiden via FreeIPA-users > > > > wrote: > > > > > > > > Hi all, > > > > Just because we can and a Rapsberry Pi 3 is cheap, I'm trying to > > > > install a FreeIPA replica on Fedora 29 ARM. It looks like the Raspberry > > > > is a bit too slow for default installation settings: > > > > 018-11-03T12:27:12Z DEBUG stderr=WARNING: Password was garbage > > > > collected before it was cleared.password file contains no datapkispawn > > > > : ERROR... server did not start after 60spkispawn: > > > > ERROR... server failed to restart > > > > 2018-11-03T12:27:12Z CRITICAL Failed to configure CA instance: > > > > CalledProcessError(Command ['/usr/sbin/pkispawn', '-s', 'CA', '-f', > > > > '/tmp/tmpv2y32e9l'] returned non-zero exit status 1: 'WARNING: Password > > > > was garbage collected before it was cleared.\npassword file contains no > > > > data\npkispawn: ERROR... server did not start after > > > > 60s\npkispawn: ERROR... server failed to > > > > restart\n')2018-11-03T12:27:12Z CRITICAL See the installation logs and > > > > the following files/directories for more > > > > information:2018-11-03T12:27:12Z CRITICAL > > > > /var/log/pki/pki-tomcat2018-11-03T12:27:12Z DEBUG Traceback (most > > > > recent call last): File > > > > "/usr/lib/python3.7/site-packages/ipaserver/install/dogtaginstance.py", > > > > line 164, in spawn_instanceipautil.run(args, nolog=nolog_list) > > > > File "/usr/lib/python3.7/site-packages/ipapython/ipautil.py", line 573, > > > > in runp.returncode, arg_string, output_log, error_log > > > > ipapython.ipautil.CalledProcessError: CalledProcessError(Command > > > > ['/usr/sbin/pkispawn', '-s', 'CA', '-f', '/tmp/tmpv2y32e9l'] returned > > > > non-zero exit status 1: 'WARNING: Password was garbage collected before > > > > it was cleared.\npassword file contains no data\npkispawn: ERROR > > > > ... server did not start after 60s\npkispawn: ERROR > > > > ... server failed to restart\n') > > > > I did change the "startup_timeout" in > > > > /usr/lib/python3.7/site-packages/ipalib/constants.py and > > > > /etc/ipa/default.conf but it doens't seem to be enough. > > > > Any sugestion? > > > > Winfried > > > > ___ > > > > 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://getfedora.org/code-of-conduct.html &g
[Freeipa-users] Re: Replica install on RPI3
Hi all, Yes, the Pi is too slow but funny enough it can work perfectly. The DogTag CA server just takes a painfull time to start. I had a Pi running as just a master for months quite well, but start Dogtag took a very long time, but afterwards it all ran well in a small environment (@home...) As mentioned, just for the sake of trying and Pi are so cheap, I' m trying to setup a Pi Replica but default setup timeout settings need a modification... Winfried John Keates schreef op za 03-11-2018 om 16:26 [+0100]: > My suggestion would be: don’t run it on a Pi, it’s not fast enough. But you > came to that conclusion already, so I guess the next issue would be: where > does it fail?I’m assuming the rpm install works out but ipa-server-install > doesn’t? Or does that work but does the starting of all the components time > out? > > If it’s just the installation that’s failing, you can get around that by > running the install in an emulated ARM machine first, and then copying the > filesystem over to the Pi. > > John > > > > On 3 Nov 2018, at 15:53, Winfried de Heiden via FreeIPA-users > > wrote: > > > > Hi all, > > Just because we can and a Rapsberry Pi 3 is cheap, I'm trying to install a > > FreeIPA replica on Fedora 29 ARM. It looks like the Raspberry is a bit too > > slow for default installation settings: > > 018-11-03T12:27:12Z DEBUG stderr=WARNING: Password was garbage collected > > before it was cleared.password file contains no datapkispawn: ERROR > > ... server did not start after 60spkispawn: ERROR... > > server failed to restart > > 2018-11-03T12:27:12Z CRITICAL Failed to configure CA instance: > > CalledProcessError(Command ['/usr/sbin/pkispawn', '-s', 'CA', '-f', > > '/tmp/tmpv2y32e9l'] returned non-zero exit status 1: 'WARNING: Password was > > garbage collected before it was cleared.\npassword file contains no > > data\npkispawn: ERROR... server did not start after > > 60s\npkispawn: ERROR... server failed to > > restart\n')2018-11-03T12:27:12Z CRITICAL See the installation logs and the > > following files/directories for more information:2018-11-03T12:27:12Z > > CRITICAL /var/log/pki/pki-tomcat2018-11-03T12:27:12Z DEBUG Traceback > > (most recent call last): File > > "/usr/lib/python3.7/site-packages/ipaserver/install/dogtaginstance.py", > > line 164, in spawn_instanceipautil.run(args, nolog=nolog_list) File > > "/usr/lib/python3.7/site-packages/ipapython/ipautil.py", line 573, in run > > p.returncode, arg_string, output_log, error_log > > ipapython.ipautil.CalledProcessError: CalledProcessError(Command > > ['/usr/sbin/pkispawn', '-s', 'CA', '-f', '/tmp/tmpv2y32e9l'] returned > > non-zero exit status 1: 'WARNING: Password was garbage collected before it > > was cleared.\npassword file contains no data\npkispawn: ERROR > > ... server did not start after 60s\npkispawn: ERROR... > > server failed to restart\n') > > I did change the "startup_timeout" in > > /usr/lib/python3.7/site-packages/ipalib/constants.py and > > /etc/ipa/default.conf but it doens't seem to be enough. > > Any sugestion? > > Winfried > > ___ > > 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://getfedora.org/code-of-conduct.html > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: > > https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org signature.asc Description: This is a digitally signed message part ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Replica install on RPI3
Hi all, Just because we can and a Rapsberry Pi 3 is cheap, I'm trying to install a FreeIPA replica on Fedora 29 ARM. It looks like the Raspberry is a bit too slow for default installation settings: 018-11-03T12:27:12Z DEBUG stderr=WARNING: Password was garbage collected before it was cleared. password file contains no data pkispawn: ERROR... server did not start after 60s pkispawn: ERROR... server failed to restart 2018-11-03T12:27:12Z CRITICAL Failed to configure CA instance: CalledProcessError(Command ['/usr/sbin/pkispawn', '-s', 'CA', '-f', '/tmp/tmpv2y32e9l'] returned non-zero exit status 1: 'WARNING: Password was garbage collected before it was cleared.\npassword file contains no data\npkispawn: ERROR... server did not start after 60s\npkispawn: ERROR... server failed to restart\n') 2018-11-03T12:27:12Z CRITICAL See the installation logs and the following files/directories for more information: 2018-11-03T12:27:12Z CRITICAL /var/log/pki/pki-tomcat 2018-11-03T12:27:12Z DEBUG Traceback (most recent call last): File "/usr/lib/python3.7/site- packages/ipaserver/install/dogtaginstance.py", line 164, in spawn_instance ipautil.run(args, nolog=nolog_list) File "/usr/lib/python3.7/site-packages/ipapython/ipautil.py", line 573, in run p.returncode, arg_string, output_log, error_log ipapython.ipautil.CalledProcessError: CalledProcessError(Command ['/usr/sbin/pkispawn', '-s', 'CA', '-f', '/tmp/tmpv2y32e9l'] returned non-zero exit status 1: 'WARNING: Password was garbage collected before it was cleared.\npassword file contains no data\npkispawn: ERROR... server did not start after 60s\npkispawn: ERROR... server failed to restart\n') I did change the "startup_timeout" in /usr/lib/python3.7/site- packages/ipalib/constants.py and /etc/ipa/default.conf but it doens't seem to be enough. Any sugestion? Winfried signature.asc Description: This is a digitally signed message part ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Is IPA-AD two-way trust really two-way?
Hi all, Thanks! This explains a lot, I'm happy :) Winfried Alexander Bokovoy via FreeIPA-users schreef op 26-10-2018 11:16: On pe, 26 loka 2018, Winfried de Heiden wrote: Hi all, Refering to this bit of older post, What now the difference between a One-way or Two-Way Trust anyway? The docs are not too clear abut it: " Two-way trust enables AD users and groups to access resources in IdM. However, the two-way trust in IdM does not give the users any additional rights compared to the one-way trust solution in AD. Both solutions are considered equally secure because of default cross-forest trust SID filtering settings" What a use-case for using a Two-Way Trust? (since Windows cannot use IPA as a AD replacement) Originally we implemented two-way trust first because it was easier to do than one-way trust from technical perspective. It allowed machines from IPA domain to directly query AD DCs about needed information using their own host/... Kerberos principals for authentication purposes. However, a lot of customers were concerned with with AD trusting IPA because it wasn't how AD domain controllers resolved identities (and ran authentication proxying) over trust. We implemented one-way trust with a proper setup and actually moved to always use the credentials one-way-like in two-way trust too with FreeIPA 4.6/latest SSSD 1.15/1.16. However, there is one missing part for a one-way trust: a one-way trust with a shared secret. If you are using a shared secret that is provided to you by AD admins (as opposed to be generated by 'ipa trust-add' automatically), one-way trust cannot be established. A long story short, both FreeIPA and SSSD lacked required logic to allow Windows to perform validation of the trust in this case from a Windows UI and we couldn't initiate the validation from IPA side as we didn't have administrative credentials to AD DCs. So right now two-way trust with a shared secret is your solution for this case, although I'd rather suggest to establish a normal one-way trust with AD admin credentials to get a stronger trust secret generated for you by 'ipa trust-add'. Winfried -Oorspronkelijk bericht- Van: Alexander Bokovoy via FreeIPA-users Antwoord-naar: FreeIPA users list Aan: FreeIPA users list Cc: Michal Sladek , Alexander Bokovoy Onderwerp: [Freeipa-users] Re: Is IPA-AD two-way trust really two-way? Datum: Thu, 23 Aug 2018 12:08:17 +0300 On to, 23 elo 2018, Michal Sladek via FreeIPA-users wrote: Hello, I would like to use IPA server in heterogeneous environment with Linux servers and Windows workstations.IPA domain would be used as a primary source of users and groups.AD domain would be used for management of Widows hosts only (group policies etc.). I have setup a test network with two-trust between AD and IPA domainand realized, that IPA domain sees AD users but AD domain doesn't seeIPA users. Am I missing something or the two-way trust is not two-wayin fact?It is two-way in principle. However, FreeIPA does not implement featuresrequired by AD DC to resolve IPA users on Windows workstations. It is onour long term roadmap. -- / Alexander BokovoySr. Principal Software EngineerSecurity / Identity Management EngineeringRed Hat Limited, Finland___FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.orgTo unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.orgFedora Code of Conduct: https://getfedora.org/code-of-conduct.htmlList Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/OJCXN7VI2NZAUWUHVZDKEZB7SF72NSR2/ ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: Is IPA-AD two-way trust really two-way?
Hi all, Refering to this bit of older post, What now the difference between a One-way or Two-Way Trust anyway? The docs are not too clear abut it: " Two-way trust enables AD users and groups to access resources in IdM. However, the two-way trust in IdM does not give the users any additional rights compared to the one-way trust solution in AD. Both solutions are considered equally secure because of default cross-forest trust SID filtering settings" What a use-case for using a Two-Way Trust? (since Windows cannot use IPA as a AD replacement) Winfried -Oorspronkelijk bericht- Van: Alexander Bokovoy via FreeIPA-users Antwoord-naar: FreeIPA users list Aan: FreeIPA users list Cc: Michal Sladek , Alexander Bokovoy Onderwerp: [Freeipa-users] Re: Is IPA-AD two-way trust really two-way? Datum: Thu, 23 Aug 2018 12:08:17 +0300 On to, 23 elo 2018, Michal Sladek via FreeIPA-users wrote: Hello, I would like to use IPA server in heterogeneous environment with Linux servers and Windows workstations.IPA domain would be used as a primary source of users and groups.AD domain would be used for management of Widows hosts only (group policies etc.). I have setup a test network with two-trust between AD and IPA domainand realized, that IPA domain sees AD users but AD domain doesn't seeIPA users. Am I missing something or the two-way trust is not two-wayin fact?It is two-way in principle. However, FreeIPA does not implement featuresrequired by AD DC to resolve IPA users on Windows workstations. It is onour long term roadmap. -- / Alexander BokovoySr. Principal Software EngineerSecurity / Identity Management EngineeringRed Hat Limited, Finland___FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.orgTo unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.orgFedora Code of Conduct: https://getfedora.org/code-of-conduct.htmlList Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelinesList Archives: https://lists.fedoraproject.org/archives/list/freeipa-users@lists.fedorahosted.org/message/OJCXN7VI2NZAUWUHVZDKEZB7SF72NSR2/ signature.asc Description: This is a digitally signed message part ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: username restrictions
Alexander Bokovoy via FreeIPA-users schreef op 10-10-2018 12:47:
On ke, 10 loka 2018, Winfried de Heiden via FreeIPA-users wrote:
Hi all,
The Red Hat manual is not too clear about this
(https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/linux_domain_identity_authentication_and_policy_guide/#users)
IdM supports user names that can be described by the following regular
expression:
[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?
Note
User names ending with the trailing dollar sign ($) are supported to
enable Samba 3.x machine support.
If you add a user whose user name contains uppercase characters, IdM
automatically converts the name to lowercase when saving it.
Therefore, IdM always requires users to enter their user names all
lowercase when logging in. Additionally, it is not possible to add
users whose user names only differ in letter casing, such as user and
User.
Having co-workers from different countries using different languages
we want to avoid "strange" character from Cyrilic, German, Hindoi etc.
etc.
Reading the docs, it suggest only plain UTF ASCII is supported, no
"strange" characters. Correct? Or else: how to avoid/not allow non
standard ASCII usernames?
ASCII, not UTF(-8). See a good presentation by Paul Gorman on the
topic:
https://paulgorman.org/technical/presentations/linux_username_conventions.pdf
While we can store UTF-8 in 'uid' attribute in LDAP, POSIX systems are
what practically limits us here.
OK, it's stored in UTF-8, which supports an awfull lot of characters...
But IPA seems to protect us:
ipa user-add --first="ßuper" --last="üser" ßuperüser
ipa: ERROR: invalid 'login': may only include letters, numbers, _, -, .
and $
Winfried
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] username restrictions
Hi all,
The Red Hat manual is not too clear about this
(https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html-single/linux_domain_identity_authentication_and_policy_guide/#users)
IdM supports user names that can be described by the following regular
expression:
[a-zA-Z0-9_.][a-zA-Z0-9_.-]{0,252}[a-zA-Z0-9_.$-]?
Note
User names ending with the trailing dollar sign ($) are supported to
enable Samba 3.x machine support.
If you add a user whose user name contains uppercase characters, IdM
automatically converts the name to lowercase when saving it. Therefore,
IdM always requires users to enter their user names all lowercase when
logging in. Additionally, it is not possible to add users whose user
names only differ in letter casing, such as user and User.
Having co-workers from different countries using different languages we
want to avoid "strange" character from Cyrilic, German, Hindoi etc. etc.
Reading the docs, it suggest only plain UTF ASCII is supported, no
"strange" characters. Correct? Or else: how to avoid/not allow non
standard ASCII usernames?
Winfried
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: SSL Private Key Recovery
Agree, there no real need for storing/recovering the private key, BUT:
On some test/development environment server are re-deployed rapidly,
sometimes multiple time a day. (ansible and cattle servers)
It is a bit annoying we endup soon with tons of revoked certificates
Winfried
Fraser Tweedale via FreeIPA-users schreef op 08-10-2018 5:24:
On Fri, Oct 05, 2018 at 04:43:15PM +0200, Winfried de Heiden via
FreeIPA-users wrote:
Hi all,
Creating the SSL certs/keys for for example Apache can easily be done
by using the FreeIPA Dogtag CA-server. With some effort, I put it in
an
Ansible playbook which will install Apache and certficates "on
demand".
Sometimes a server needs to be re-installed ("cattle-servers"); why
bother about backup/restore when a server can be redeployed within
minutes. However, a new certificate needs to created; it seems since I
cannot (re)download the private key once created.
Now: is it just impossible to (re) download the private ssl key later
on for re-use?
We don't support key archival in FreeIPA. The underlying Dogtag CA
software supports it but we don't use that feature.
But I put to you: why bother to archive keys when you can just
generate a fresh keypair and request a new certificate. If a server
redeployment takes minutes, this is a small cost. It also has
security benefits (less chance of key compromise of keys are not
archived, key compromise impact is servers are regularly destroyed
and replaced with fresh server with new keys, etc).
The main reason you would archive private keys is for encryption
applications, not authentication (which is what TLS is) or signing.
HTH,
Fraser
If not possible: FreeIPA vault (KRA) seems a proper way to store
private key. Correct?
Thanks!
Winfried
___
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://getfedora.org/code-of-conduct.html
List Guidelines:
https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] SSL Private Key Recovery
Hi all,
Creating the SSL certs/keys for for example Apache can easily be done
by using the FreeIPA Dogtag CA-server. With some effort, I put it in an
Ansible playbook which will install Apache and certficates "on demand".
Sometimes a server needs to be re-installed ("cattle-servers"); why
bother about backup/restore when a server can be redeployed within
minutes. However, a new certificate needs to created; it seems since I
cannot (re)download the private key once created.
Now: is it just impossible to (re) download the private ssl key later
on for re-use?
If not possible: FreeIPA vault (KRA) seems a proper way to store
private key. Correct?
Thanks!
Winfried
signature.asc
Description: This is a digitally signed message part
___
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
[Freeipa-users] Re: read only replicants
Any progress on this issue? https://pagure.io/freeipa/issue/5569 seems open and no progress for ages now Winfried Op 06-04-18 om 13:57 schreef Florence Blanc-Renaud via FreeIPA-users: > On 04/06/2018 12:10 PM, Angus Clarke via FreeIPA-users wrote: >> Hi >> >> Is there way to lock down a FreeIPA replica so that it can only >> receive updates but not make changes to other FreeIPA systems. >> >> Some of our environments are considered less secure than others, our >> security team are concerned that a FreeIPA in a less secure >> environment might become compromised at which point unwarranted >> changes could be applied that affect our secure production environments. >> >> Thanks a lot >> Angus >> >> >> ___ >> FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org >> To unsubscribe send an email to >> freeipa-users-le...@lists.fedorahosted.org >> > Hi, > > unlike 389-ds, FreeIPA currently supports only read-write replicas. An > RFE is already tracking this request for read-only replicas, see [1]. > > HTH, > Flo > > [1] https://pagure.io/freeipa/issue/5569 > ___ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to > freeipa-users-le...@lists.fedorahosted.org signature.asc Description: OpenPGP digital signature ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: OTP for specific services only
Angry users, indeed...:) NOPASSWD seems like no option, I struggle some more... Winfried -Oorspronkelijke bericht- Datum: Fri, 23 Feb 2018 16:02:06 +0100 Onderwerp: Re: [Freeipa-users] OTP for specific services only Cc: Winfried de Heiden <w...@dds.nl> Aan: FreeIPA users list <freeipa-users@lists.fedorahosted.org> Van: Maciej Drobniuch <m...@collective-sense.com> Hey Winfired, I've been struggling with this too. Currently I'm doing a hack (NO PASSWORD) in sudoers to at least workaround the otp at sudo. It's as always usability+angry users vs security. BR Maciej On Fri, Feb 23, 2018 at 3:07 PM, Winfried de Heiden via FreeIPA-users < freeipa-users@lists.fedorahosted.org> wrote: > > > > > Hi al, > > > > OTP using IPA 4.5 on CentOS seems to work well. However: I can > force a user to use OTP and/or a host. > > > > Selecting a user, ALL authentication needs OTP. Since sudo in > this > case will ask for OTP also, this turn out quite inconvenient. > Is > is possible to select only certain services for OTP. for > example: > > > > login using SSH --> OTP > > login ftp --> OTP > > console --> password only > > sudo --> password only > > > > Winfried > > > ___ > > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > > To unsubscribe send an email to freeipa-users-leave@lists.fedorahoste > d.org > > ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: OTP for specific services only
Hi all, What about an RFE on this :) Winfried -Oorspronkelijke bericht- Datum: Fri, 23 Feb 2018 16:54:45 +0200 Onderwerp: Re: [Freeipa-users] OTP for specific services only Cc: Winfried de Heiden <w...@dds.nl> Aan: FreeIPA users list <freeipa-users@lists.fedorahosted.org> Van: Alexander Bokovoy <aboko...@redhat.com> On pe, 23 helmi 2018, Winfried de Heiden via FreeIPA-users wrote: > Hi al, > > OTP using IPA 4.5 on CentOS seems to work well. However: I can force > a user to > use OTP and/or a host. > > Selecting a user, ALL authentication needs OTP. Since sudo in this > case will > ask for OTP also, this turn out quite inconvenient. Is is possible to > select > only certain services for OTP. for example: > > login using SSH -- OTP > login ftp -- OTP > console -- password only > sudo -- password only Not possible right now, sorry. ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] OTP for specific services only
Hi al, OTP using IPA 4.5 on CentOS seems to work well. However: I can force a user to use OTP and/or a host. Selecting a user, ALL authentication needs OTP. Since sudo in this case will ask for OTP also, this turn out quite inconvenient. Is is possible to select only certain services for OTP. for example: login using SSH --> OTP login ftp --> OTP console --> password only sudo --> password only Winfried ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Fedroa 26 to 27 - FreeIpa upgrade failed on ARM
Hi all, Happy Holidays! Running Feodra ARM on a Raspberry Pi the upgrade from Fedora 26 to Fedora 27 fails, 389 DS refuses to start: ec 24 16:51:18 ipa.blabla.bla systemd[1]: Starting 389 Directory Server xxx Dec 24 16:51:19 ipa.blabla.bla ns-slapd[14513]: [24/Dec/2017:16:51:19.530855564 +0100] - NOTICE - config_set_port - Non-Secure Port Disabled Dec 24 16:51:19 ipa.blabla.bla ns-slapd[14513]: [24/Dec/2017:16:51:19.751813588 +0100] - ERR - symload_report_error - Netscape Portable Runtime error -5975: /usr/lib/dirsrv/plugins/libreplication-plugin.so: undefined symbol: replication_legacy_plugin_init Dec 24 16:51:19 ipa.blabla.bla ns-slapd[14513]: [24/Dec/2017:16:51:19.811553110 +0100] - ERR - symload_report_error - Could not load symbol "replication_legacy_plugin_init" from "/usr/lib/dirsrv/plugins/libreplication-plugin.so" for plugin Legacy Replication Plugin Dec 24 16:51:19 ipa.blabla.bla ns-slapd[14513]: [24/Dec/2017:16:51:19.850720557 +0100] - ERR - load_plugin_entry - Unable to load plugin "cn=Legacy Replication Plugin,cn=plugins,cn=config" Anyone any idea? Winfried ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
[Freeipa-users] Re: Request failed with status 500: Non-2xx response from CA REST API: 500. - pki-tomcatd fails to start
Hi all, certmonger is restarted; "ipa-getcert resubmit -i 20170129002024" will thown in an error in /var/log/pki/pki-tomcat/ca/debug: [13/Sep/2017:16:13:37][ajp-nio-127.0.0.1-8009-exec-1]: CertProcessor: no profile policy set found Policy Set Not Found at com.netscape.cms.servlet.cert.CertProcessor.populateRequests(CertProcessor.java:346) at com.netscape.cms.servlet.cert.EnrollmentProcessor.processEnrollment(EnrollmentProcessor.java:181) at com.netscape.cms.servlet.cert.EnrollmentProcessor.processEnrollment(EnrollmentProcessor.java:96) at com.netscape.cms.servlet.cert.CertRequestDAO.submitRequest(CertRequestDAO.java:195) at org.dogtagpki.server.ca.rest.CertRequestService.enrollCert(CertRequestService.java:173) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) Winfried Op 12-09-17 om 17:08 schreef Rob Crittenden via FreeIPA-users: Winfried de Heiden wrote: Hi all, Yes, there was a discrepancy in de certificates and was fixed by using https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcatd-fails-to-start/. Thanks for that! Now, getcert ist still shows errors. The certmonger logs shows: De certmonger log shows: Sep 12 14:05:35 ipa.blabla.bla certmonger[11551]: 2017-09-12 14:05:35 [11551] Server at https://ipa.blabla.bla/ipa/xml failed request, will retry: 4035 (RPC failed at server. Request failed with status 500: Non-2xx response from CA REST API: 500. *Policy Set Not Found*). Sep 12 14:05:59 ipa.blabla.bla certmonger[11551]: 2017-09-12 14:05:59 [11551] Server at https://ipa.blabla.bla/ipa/xml failed request, will retry: 4035 (RPC failed at server. Request failed with status 500: Non-2xx response from CA REST API: 500. *Policy Set Not Found*). It looks like 2 certificates cannot be renewed but are about to expire What's happening and how to fix? Look at the dogtag debug log for more information on why it is failing the request. You'll want to restart certmonger or resubmit the request manually while watching the debug log to get the times correlated. rob Winfried Op 12-09-17 om 10:04 schreef Florence Blanc-Renaud via FreeIPA-users: On 09/12/2017 09:10 AM, Winfried de Heiden via FreeIPA-users wrote: Hi all, I'll try my using the link provided. However: what is causing "CA_UNREACHABLE"? Request ID '20170129002017': status: CA_UNREACHABLE ca-error: Server at https://ipa.blabla.bla/ipa/xml failed request, will retry: 4035 (RPC failed at server. Request failed with status 500: Non-2xx response from CA REST API: 500. Policy Set Not Found). stuck: no Hi Winfried, certmonger is using the CA 'IPA' for the Server-Cert used by httpd and ldap. This CA helper is communicating with FreeIPA server, and FreeIPA in turn communicates with Dogtag. You will probably find more information in FreeIPA server logs (in /var/log/httpd/error_log) and in Dogtag logs (/var/log/pki/pki-tomcat/ca/debug). Flo Winfried Op 11-09-17 om 17:12 schreef Florence Blanc-Renaud via FreeIPA-users: On 09/11/2017 04:53 PM, Winfried de Heiden via FreeIPA-users wrote: CS.cfg was modified so pki-tomcat can login using a password and non-secure LDAP. At least it is working now: < internaldb.ldapauth.authtype=BasicAuth < internaldb.ldapauth.bindDN=cn=Directory Manager --- > internaldb.ldapauth.authtype=SslClientAuth > internaldb.ldapauth.bindDN=uid=pkidbuser,ou=people,o=ipa-ca 780,781c780,781 < internaldb.ldapconn.port=389 < internaldb.ldapconn.secureConn=false --- > internaldb.ldapconn.port=636 > internaldb.ldapconn.secureConn=true Reversed to the old config, stop/started ipa, debug shows pki-tomcatd cannot login: 11/Sep/2017:16:51:41][localhost-startStop-1]: SSLClientCertificatSelectionCB: Entering! [11/Sep/2017:16:51:41][localhost-startStop-1]: Candidate cert: subsystemCert cert-pki-ca [11/Sep/2017:16:51:41][localhost-startStop-1]: SSLClientCertificateSelectionCB: desired cert found in list: subsystemCert cert-pki-ca [11/Sep/2017:16:51:41][localhost-startStop-1]: SSLClientCertificateSelectionCB: returning: subsystemCert cert-pki-ca [11/Sep/2017:16:51:42][localhost-startStop-1]: SSL handshake happened Could not connect to LDAP server host ipa.blabla.bla port 636 Error netscape.ldap.LDAPException: Authentication failed (49) at com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:205) at com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:166) at com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:130) at com.netscape.cmsco
[Freeipa-users] Re: Request failed with status 500: Non-2xx response from CA REST API: 500. - pki-tomcatd fails to start
Hi all,
Yes, there was a discrepancy in de certificates and was fixed by
using https://floblanc.wordpress.com/2017/09/11/troubleshooting-freeipa-pki-tomcatd-fails-to-start/.
Thanks for that!
Now, getcert ist still shows errors. The certmonger logs shows:
De certmonger log shows:
Sep 12 14:05:35 ipa.blabla.bla certmonger[11551]: 2017-09-12
14:05:35 [11551] Server at https://ipa.blabla.bla/ipa/xml failed
request, will retry: 4035 (RPC failed at server. Request failed
with status 500: Non-2xx response from CA REST API: 500. Policy
Set Not Found).
Sep 12 14:05:59 ipa.blabla.bla certmonger[11551]: 2017-09-12
14:05:59 [11551] Server at https://ipa.blabla.bla/ipa/xml failed
request, will retry: 4035 (RPC failed at server. Request failed
with status 500: Non-2xx response from CA REST API: 500. Policy
Set Not Found).
It looks like 2 certificates cannot be renewed but are about to
expire What's happening and how to fix?
Winfried
Op 12-09-17 om 10:04 schreef Florence
Blanc-Renaud via FreeIPA-users:
On
09/12/2017 09:10 AM, Winfried de Heiden via FreeIPA-users wrote:
Hi all,
I'll try my using the link provided. However: what is causing
"CA_UNREACHABLE"?
Request ID '20170129002017':
status: CA_UNREACHABLE
ca-error: Server at https://ipa.blabla.bla/ipa/xml failed
request, will retry: 4035 (RPC failed at server. Request failed
with status 500: Non-2xx response from CA REST API: 500. Policy
Set Not Found).
stuck: no
Hi Winfried,
certmonger is using the CA 'IPA' for the Server-Cert used by httpd
and ldap. This CA helper is communicating with FreeIPA server, and
FreeIPA in turn communicates with Dogtag.
You will probably find more information in FreeIPA server logs (in
/var/log/httpd/error_log) and in Dogtag logs
(/var/log/pki/pki-tomcat/ca/debug).
Flo
Winfried
Op 11-09-17 om 17:12 schreef Florence Blanc-Renaud via
FreeIPA-users:
On 09/11/2017 04:53 PM, Winfried de
Heiden via FreeIPA-users wrote:
CS.cfg was modified so pki-tomcat can
login using a password and non-secure LDAP. At least it is
working now:
< internaldb.ldapauth.authtype=BasicAuth
< internaldb.ldapauth.bindDN=cn=Directory Manager
---
> internaldb.ldapauth.authtype=SslClientAuth
>
internaldb.ldapauth.bindDN=uid=pkidbuser,ou=people,o=ipa-ca
780,781c780,781
< internaldb.ldapconn.port=389
< internaldb.ldapconn.secureConn=false
---
> internaldb.ldapconn.port=636
> internaldb.ldapconn.secureConn=true
Reversed to the old config, stop/started ipa, debug shows
pki-tomcatd cannot login:
11/Sep/2017:16:51:41][localhost-startStop-1]:
SSLClientCertificatSelectionCB: Entering!
[11/Sep/2017:16:51:41][localhost-startStop-1]: Candidate
cert: subsystemCert cert-pki-ca
[11/Sep/2017:16:51:41][localhost-startStop-1]:
SSLClientCertificateSelectionCB: desired cert found in list:
subsystemCert cert-pki-ca
[11/Sep/2017:16:51:41][localhost-startStop-1]:
SSLClientCertificateSelectionCB: returning: subsystemCert
cert-pki-ca
[11/Sep/2017:16:51:42][localhost-startStop-1]: SSL handshake
happened
Could not connect to LDAP server host ipa.blabla.bla port
636 Error netscape.ldap.LDAPException: Authentication failed
(49)
at
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:205)
at
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:166)
at
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:130)
at
com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:654)
at
com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1172)
at
com.netscape.cms
[Freeipa-users] Re: Request failed with status 500: Non-2xx response from CA REST API: 500. - pki-tomcatd fails to start
Hi all,
I'll try my using the link provided. However: what is causing
"CA_UNREACHABLE"?
Request ID '20170129002017':
status: CA_UNREACHABLE
ca-error: Server at https://ipa.blabla.bla/ipa/xml failed
request, will retry: 4035 (RPC failed at server. Request failed
with status 500: Non-2xx response from CA REST API: 500. Policy
Set Not Found).
stuck: no
Winfried
Op 11-09-17 om 17:12 schreef Florence
Blanc-Renaud via FreeIPA-users:
On
09/11/2017 04:53 PM, Winfried de Heiden via FreeIPA-users wrote:
CS.cfg was modified so pki-tomcat can
login using a password and non-secure LDAP. At least it is
working now:
< internaldb.ldapauth.authtype=BasicAuth
< internaldb.ldapauth.bindDN=cn=Directory Manager
---
> internaldb.ldapauth.authtype=SslClientAuth
>
internaldb.ldapauth.bindDN=uid=pkidbuser,ou=people,o=ipa-ca
780,781c780,781
< internaldb.ldapconn.port=389
< internaldb.ldapconn.secureConn=false
---
> internaldb.ldapconn.port=636
> internaldb.ldapconn.secureConn=true
Reversed to the old config, stop/started ipa, debug shows
pki-tomcatd cannot login:
11/Sep/2017:16:51:41][localhost-startStop-1]:
SSLClientCertificatSelectionCB: Entering!
[11/Sep/2017:16:51:41][localhost-startStop-1]: Candidate cert:
subsystemCert cert-pki-ca
[11/Sep/2017:16:51:41][localhost-startStop-1]:
SSLClientCertificateSelectionCB: desired cert found in list:
subsystemCert cert-pki-ca
[11/Sep/2017:16:51:41][localhost-startStop-1]:
SSLClientCertificateSelectionCB: returning: subsystemCert
cert-pki-ca
[11/Sep/2017:16:51:42][localhost-startStop-1]: SSL handshake
happened
Could not connect to LDAP server host ipa.blabla.bla port 636
Error netscape.ldap.LDAPException: Authentication failed (49)
at
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:205)
at
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:166)
at
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:130)
at
com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:654)
at
com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1172)
at
com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:1078)
at
com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:570)
at com.netscape.certsrv.apps.CMS.init(CMS.java:188)
at com.netscape.certsrv.apps.CMS.start(CMS.java:1621)
Winfried
Op 11-09-17 om 16:18 schreef Rob Crittenden via FreeIPA-users:
Winfried de Heiden via FreeIPA-users
wrote:
Hi All,
Somewhere after an update (I guess) I have issues;
pki-tomcatd@pki-tomcat.service will not start since it
cannot login to
LDAP. It seems I have some certificate isues:
getcert list shows:
Request ID '20170129002017':
status: CA_UNREACHABLE
ca-error: Server athttps://ipa.example.com/ipa/xml
failed request,
will retry: 4035 (RPC failed at server. Request failed with
status 500:
Non-2xx response from CA REST API: 500. Policy Set Not
Found).
stuck: no
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-BLABLA-BLA',nickname='Server-Cert',token='NSS
Certificate
DB',pinfile='/etc/dirsrv/slapd-BLABLA-BLA/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-BLABLA-BLA',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=IPA.LOCAL
201509271650
subject: CN=ipa.example.com,O=IPA.LOCAL 201509271650
expires: 2017-09-27 17:26:00 CEST
key usage:
digitalSignature,nonRepudiatio
[Freeipa-users] Re: Request failed with status 500: Non-2xx response from CA REST API: 500. - pki-tomcatd fails to start
CS.cfg was modified so pki-tomcat can login
using a password and non-secure LDAP. At least it is working
now:
< internaldb.ldapauth.authtype=BasicAuth
< internaldb.ldapauth.bindDN=cn=Directory Manager
---
> internaldb.ldapauth.authtype=SslClientAuth
> internaldb.ldapauth.bindDN=uid=pkidbuser,ou=people,o=ipa-ca
780,781c780,781
< internaldb.ldapconn.port=389
< internaldb.ldapconn.secureConn=false
---
> internaldb.ldapconn.port=636
> internaldb.ldapconn.secureConn=true
Reversed to the old config, stop/started ipa, debug shows
pki-tomcatd cannot login:
11/Sep/2017:16:51:41][localhost-startStop-1]:
SSLClientCertificatSelectionCB: Entering!
[11/Sep/2017:16:51:41][localhost-startStop-1]: Candidate cert:
subsystemCert cert-pki-ca
[11/Sep/2017:16:51:41][localhost-startStop-1]:
SSLClientCertificateSelectionCB: desired cert found in list:
subsystemCert cert-pki-ca
[11/Sep/2017:16:51:41][localhost-startStop-1]:
SSLClientCertificateSelectionCB: returning: subsystemCert
cert-pki-ca
[11/Sep/2017:16:51:42][localhost-startStop-1]: SSL handshake
happened
Could not connect to LDAP server host ipa.blabla.bla port 636
Error netscape.ldap.LDAPException: Authentication failed (49)
at
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.makeConnection(LdapBoundConnFactory.java:205)
at
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:166)
at
com.netscape.cmscore.ldapconn.LdapBoundConnFactory.init(LdapBoundConnFactory.java:130)
at
com.netscape.cmscore.dbs.DBSubsystem.init(DBSubsystem.java:654)
at
com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:1172)
at
com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:1078)
at
com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:570)
at com.netscape.certsrv.apps.CMS.init(CMS.java:188)
at com.netscape.certsrv.apps.CMS.start(CMS.java:1621)
Winfried
Op 11-09-17 om 16:18 schreef Rob
Crittenden via FreeIPA-users:
Winfried de Heiden via FreeIPA-users wrote:
Hi All,
Somewhere after an update (I guess) I have issues;
pki-tomcatd@pki-tomcat.service will not start since it cannot login to
LDAP. It seems I have some certificate isues:
getcert list shows:
Request ID '20170129002017':
status: CA_UNREACHABLE
ca-error: Server at https://ipa.example.com/ipa/xml failed request,
will retry: 4035 (RPC failed at server. Request failed with status 500:
Non-2xx response from CA REST API: 500. Policy Set Not Found).
stuck: no
key pair storage:
type=NSSDB,location='/etc/dirsrv/slapd-BLABLA-BLA',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/dirsrv/slapd-BLABLA-BLA/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/dirsrv/slapd-BLABLA-BLA',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=IPA.LOCAL 201509271650
subject: CN=ipa.example.com,O=IPA.LOCAL 201509271650
expires: 2017-09-27 17:26:00 CEST
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv BLABLA-BLA
track: yes
auto-renew: yes
Request ID '20170129002024':
status: CA_UNREACHABLE
ca-error: Server at https://ipa.example.com/ipa/xml failed request,
will retry: 4035 (RPC failed at server. Request failed with status 500:
Non-2xx response from CA REST API: 500. Policy Set Not Found).
stuck: no
key pair storage:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt'
certificate:
type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS
Certificate DB'
CA: IPA
issuer: CN=Certificate Authority,O=IPA.LOCAL 201509271650
subject: CN=ipa.example.com,O=IPA.LOCAL 201509271650
expires: 2017-09-27 17:41:26 CEST
key usage:
digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
eku: id-kp-serverAuth,id-kp-clientAuth
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/restart_httpd
track: yes
auto-renew: yes
(I managed to start IPA by modifying /etc/pki/pki-tomcat/ca/CS.cfg)
How to fix this. Something seems wrong with de DIRSRV certificate and
http:(
What did you modify?
How to fix? What could have caused this issue?
This is likely not a problem with the certificates but with the
certificate profiles. The dogtag debug log may have more information.
rob
___
FreeIPA-users maili
[Freeipa-users] Request failed with status 500: Non-2xx response from CA REST API: 500. - pki-tomcatd fails to start
Hi All, Somewhere after an update (I guess) I have issues; pki-tomcatd@pki-tomcat.service will not start since it cannot login to LDAP. It seems I have some certificate isues: getcert list shows: Request ID '20170129002017': status: CA_UNREACHABLE ca-error: Server at https://ipa.example.com/ipa/xml failed request, will retry: 4035 (RPC failed at server. Request failed with status 500: Non-2xx response from CA REST API: 500. Policy Set Not Found). stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-BLABLA-BLA',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-BLABLA-BLA/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-BLABLA-BLA',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=IPA.LOCAL 201509271650 subject: CN=ipa.example.com,O=IPA.LOCAL 201509271650 expires: 2017-09-27 17:26:00 CEST key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv BLABLA-BLA track: yes auto-renew: yes Request ID '20170129002024': status: CA_UNREACHABLE ca-error: Server at https://ipa.example.com/ipa/xml failed request, will retry: 4035 (RPC failed at server. Request failed with status 500: Non-2xx response from CA REST API: 500. Policy Set Not Found). stuck: no key pair storage: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/httpd/alias/pwdfile.txt' certificate: type=NSSDB,location='/etc/httpd/alias',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=IPA.LOCAL 201509271650 subject: CN=ipa.example.com,O=IPA.LOCAL 201509271650 expires: 2017-09-27 17:41:26 CEST key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: /usr/libexec/ipa/certmonger/restart_httpd track: yes auto-renew: yes (I managed to start IPA by modifying /etc/pki/pki-tomcat/ca/CS.cfg) How to fix this. Something seems wrong with de DIRSRV certificate and http:( How to fix? What could have caused this issue? Winfried ___ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
