[Freeipa-users] Re: Add a picture to freeipa user
On Fri, 08 Feb 2019, Rufa Rufa via FreeIPA-users wrote:
Hello,
Can someone please help me to add a picture to the freeipa user, i did
the following steps:
first, you don't need to add any additional attributes. jpegPhoto
attribute is already in a default 389-ds set of LDAP schemes, since it
is part of RFC 2798 for inetOrgPerson object class. It is a binary
attribute, so the data is stored in LDAP rather than specifying an
external path.
Since any IPA user has inetOrgPerson object class set by default, just
adding jpegPhoto to the list of attributes returned by default would
make it visible via IPA API. But it is a binary data, so to get ability
to add it from a file needs a change in a client-side API override to
replace binary data with a file-based object. Finally, to get it
displayed in the Web UI you need to create a JavaScript plugin.
I'd suggest you too look into sample plugins I did that demonstrate how
all this can be done, for example, with
https://github.com/abbra/freeipa-userstatus-plugin/tree/master/plugin
you can get a base setup.
All you need to do is to create a definition of a photo-based parameter:
from ipaserver.plugins.user import user
from ipalib.parameters import Bytes
from ipalib import _
user.takes_params += (
Bytes('jpegphoto',
cli_name='photo',
label=_('User photo'),
),
)
user.default_attributes.append('jpegphoto')
---
This is a basic setup for a server-side plugin
(that would be a plugin/ipaserver/plugins/userphoto.py in the terms of
the structure defined in my sample plugins it the plugin is called
'userphoto').
To be able to supply a file through the client (ipa user-mod foo
--photo=/some/path/to/file.jpg), you need to override a client side to
say that you accept file instead of Bytes. I copied the following from
freeipa-desktop-profile plugin which does the same for FleetCommander
integration (https://github.com/abbra/freeipa-desktop-profile):
from ipaclient.frontend import MethodOverride
from ipalib.parameters import File
from ipalib.plugable import Registry
register = Registry()
@register(override=True, no_fail=True)
class baseuser_add(MethodOverride):
def get_options(self):
for opt in super(baseuser_add, self).get_options():
if opt.name == 'jpegphoto' and self.env.interactive:
opt = opt.clone_retype(opt.name, File)
yield opt
@register(override=True, no_fail=True)
class baseuser_mod(MethodOverride):
def get_options(self):
for opt in super(baseuser_mod, self).get_options():
if opt.name == 'jpegphoto' and self.env.interactive:
opt = opt.clone_retype(opt.name, File)
yield opt
That should go into plugin/ipaclient/plugins/userphoto.py
Finally, for Web UI, you need to just add a div that has your photo
displayed, pretty much like userstatus sample plugin adds its own UI
elements into the misc section.
See
https://github.com/abbra/freeipa-userstatus-plugin/blob/master/plugin/ui/userstatus.js
for details on that. We push a radio box there but you'd need to create
a class derived from IPA.field that shows a picture and also provides an
input field to upload a jpeg
file. See Web UI API at https://pvoborni.fedorapeople.org/api/#!/api/IPA.field
and you need to learn a bit more from the FreeIPA source code in
freeipa/install/ui/src/freeipa/
If you are interested in getting this work done, make sure to subscribe to
freeipa-devel@ and discuss it there.
--
/ 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://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: AD Trust: Add "mail" user attribute to AD -> IPA transfer
On Fri, 07 Dec 2018, Lenhardt, Matthias via FreeIPA-users wrote: Hi, we have an IPA 4.6.4 environment with an AD Trust configured and everything's working perfectly. My question is: Is it possible to configure, that extra AD user attributes are transfered? I would need the AD user attribute "mail" with the users email address. This question came up, after I tried to connect GitLab to IPA and authentication with an AD users fails, because IPA doesn't have the "mail" attribute of the user, so logging is denied. (Authentication on Linux systems is working). There are so many assumptions in my answer below because you didn't really tell what you do. I assume you are talking about use of the Compat tree to connect your GitLab instance via LDAP to IPA. I assume you are searching for both AD and IPA users in the cn=compat,$SUFFIX. If that's correct assumption, there is nothing to help here. Compat tree is populated using two sources: - for IPA users it picks up details from the cn=accounts,$SUFFIX - for AD users it queries SSSD on IPA master using a specialized API that only returns details of POSIX attributes There is no such thing as 'mail' in POSIX attributes and we cannot really retrieve it via existing API. I think a better approach would actually be to get GitLab and similar solutions to move on to use SAML2 or OpenID Connect connectors instead of looking up everything in LDAP directly. This is GitLab EE feature but it is really meant to solve this kind of problem. See https://docs.gitlab.com/ee/integration/saml.html for details. If you'd use Keycloak or Ipsilon with SSSD backend as an IdP, you will get all those details and more available to GitLab. -- / 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://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] Add a picture to freeipa user
Hello, Can someone please help me to add a picture to the freeipa user, i did the following steps: 1- Create a new file with ldif extension: $vi test.ldif 2- copy the following lines: dn: cn=schema changetype: modify add: attributeTypes attributeTypes: ( 2.25.28639311321113238241701611583088740684.14.2.2 NAME 'UsersPicture' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'Extending FreeIPA' ) dn: cn=schema changetype: modify add: objectclasses objectclasses: ( 2.25.28639311321113238241701611583088740684.14.2.1 (Not sure if it should be the same than attribute and change 2 by 1 at the end) NAME 'customPerson' SUP person STRUCTURAL MAY ( UsersPicture ) X-ORIGIN 'Extending FreeIPA' ) 3- Get kerberos ticket: $kinit admin 4- add the attribute and objectclass to the ldap with the following command (joined webpage About the IDM client tools): $ldapmodify -D "cn=Directory Manager" -W -p 389 -h ipaserver.example.com -f test.ldif -v 5- Restart freeipa server: $ipactl restart 6- ipa config-mod --addattr=ipaUserObjectClasses=object_class_name_added_above 7- Add the attribute to a user $ ipa user-mod ttest1 --addattr=UsersPicture=path_to_the_picture 8- Verify if the user has the new attribute: $ipa user-show --all loginname | grep UsersPicture $userspictures: L2hvbwuanBn How to add this attribute to the GUI users to check if the picture is working ? Thanks, ___ 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: Failed to start 389 Directory Server
Thanks Thierry,
IPA backup had failed much before, unfortunate not able to restore those logs.
But I did some progress, by trying to restore different daily backups. And I
found one, that was restored "successfully", and 389ds has started after that.
But new problem is that replica from another master permanently fails ("Error
(16) : Incremental update connection error. Backing off, will retry update
later.") and my work around is having this cron job:
ipa-replica-manage -v re-initialize --from=
The result of this is:
1. DB can reinit with latest data, this is good
2. Any action (add user/host) fails with errors like "IPA Error 4203:
DatabaseError". Fine, at least I have that server are read-only in my
infrastructure.
On the top of this in Oct 2018, certmonger had failed to renew certs, and
"back-in" time proposed resolution didn't help. This is obstacle to add new
server, I tried promoting client into server, but replica prepare fails (domain
level 0), so I am not sure what we can do!?
Maybe built new IPA (latest version), same domain name and realm, and manually
migrate from crippled infrastructure.
___
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: AD Trust: Add "mail" user attribute to AD -> IPA transfer
I second this request. We have IPA/IDM configured with a one way trust to AD and it is working well. Yet we would like to have user Auth to LDAP in IPA/IDM and one (among others) fields that cannot be seen via LDAP queries is the AD Email field. This really stops the auth in most cases. There are other fields we need as well but this one is critical. ___ 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: CA no certs being tracked?
Chris Mohler via FreeIPA-users wrote: > Sorry for the delay and multiple posts. I'm having some trouble with my > mail client. > > thanks again for all the help > > As requested Here is the output from getcert list on the CA renewal master: So these errors are from today, when the certs are expired. Can you go back in time and get the errors from back then? They are likely to be different. To do this you need to do something like: # ipactl stop # date # systemctl start dirsrv@DOMAIN-COM httpd krb5kdc pki-tomcatd@pki-tomcat (if you are running DNS add named-pkcs11 right after dirsrv # systemctl restart certmonger Then gather the data. You can return to current time now if you want as well, ipactl stop, date , ipactl --ignore-service-failures start rob > > Number of certificates and requests being tracked: 9. > Request ID '20180131032610': > status: CA_UNREACHABLE > ca-error: Error 58 connecting to > https://ipa1.domain.com:8443/ca/agent/ca/profileReview: Problem with the > local SSL certificate. > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=domain.com > subject: CN=CA Audit,O=domain.com > expires: 2018-12-31 13:28:03 UTC > key usage: digitalSignature,nonRepudiation > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "auditSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20180131032614': > status: CA_UNREACHABLE > ca-error: Error 58 connecting to > https://ipa1.domain.com:8443/ca/agent/ca/profileReview: Problem with the > local SSL certificate. > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS > Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert > cert-pki-ca',token='NSS > Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=domain.com > subject: CN=OCSP Subsystem,O=domain.com > expires: 2018-12-31 13:26:43 UTC > eku: id-kp-OCSPSigning > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "ocspSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20180131032615': > status: CA_UNREACHABLE > ca-error: Error 58 connecting to > https://ipa1.domain.com:8443/ca/agent/ca/profileReview: Problem with the > local SSL certificate. > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=domain.com > subject: CN=CA Subsystem,O=domain.com > expires: 2018-12-31 13:26:53 UTC > key usage: > digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment > eku: id-kp-serverAuth,id-kp-clientAuth > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "subsystemCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20180131032616': > status: MONITORING > stuck: no > key pair storage: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert > cert-pki-ca',token='NSS Certificate DB',pin set > certificate: > type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert > cert-pki-ca',token='NSS Certificate DB' > CA: dogtag-ipa-ca-renew-agent > issuer: CN=Certificate Authority,O=domain.com > subject: CN=Certificate Authority,O=domain.com > expires: 2038-12-31 03:18:40 UTC > key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign > pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad > post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert > "caSigningCert cert-pki-ca" > track: yes > auto-renew: yes > Request ID '20180131032623': > status: CA_UNREACHABLE > ca-error: Error 58 connecting to > https://ipa1.domain.com:8443/ca/agent/ca/profileReview: Problem with the > local SSL certificate. > stuck: no > key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key' >
[Freeipa-users] Possible to ignore all AD groups?
Hello, Hopefully this might be a straightforward question. I have testing instance of FreeIPA version 4.6.4 installed on CentOS 7 from the distro's default repos. I have it configured for a one-way trust to an Active Directory deployment. On the client side, I have installed and configured the freeipa-client package version 4.7.0 on Ubuntu 18.04. This is all basically working as advertised according to the docs. However, when I log into the client with an AD account and run the `id` command, I'm seeing all of my AD groups listed. Is there a way to have FreeIPA completely ignore all groups from AD when dealing with external users? The ultimate goal (and let me know if this is beyond FreeIPA's capabiltiies) is to ignore/discard all groups in AD and manage users instead by groups in FreeIPA. One thing I did try was adding these options to the domain section of `sssd.conf` on the FreeIPA server, but they didn't have any effect and I suspect I don't fully understand what they are for: ignore_group_members = True subdomain_inherit = ignore_group_members Thanks for any advice, even if it's "hey, don't do that". Charles ___ 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: CA no certs being tracked?
Sorry for the delay and multiple posts. I'm having some trouble with my mail client. thanks again for all the help As requested Here is the output from getcert list on the CA renewal master: Number of certificates and requests being tracked: 9. Request ID '20180131032610': status: CA_UNREACHABLE ca-error: Error 58 connecting to https://ipa1.domain.com:8443/ca/agent/ca/profileReview: Problem with the local SSL certificate. stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='auditSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=domain.com subject: CN=CA Audit,O=domain.com expires: 2018-12-31 13:28:03 UTC key usage: digitalSignature,nonRepudiation pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "auditSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20180131032614': status: CA_UNREACHABLE ca-error: Error 58 connecting to https://ipa1.domain.com:8443/ca/agent/ca/profileReview: Problem with the local SSL certificate. stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='ocspSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=domain.com subject: CN=OCSP Subsystem,O=domain.com expires: 2018-12-31 13:26:43 UTC eku: id-kp-OCSPSigning pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "ocspSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20180131032615': status: CA_UNREACHABLE ca-error: Error 58 connecting to https://ipa1.domain.com:8443/ca/agent/ca/profileReview: Problem with the local SSL certificate. stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=domain.com subject: CN=CA Subsystem,O=domain.com expires: 2018-12-31 13:26:53 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" track: yes auto-renew: yes Request ID '20180131032616': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB',pin set certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='caSigningCert cert-pki-ca',token='NSS Certificate DB' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=domain.com subject: CN=Certificate Authority,O=domain.com expires: 2038-12-31 03:18:40 UTC key usage: digitalSignature,nonRepudiation,keyCertSign,cRLSign pre-save command: /usr/libexec/ipa/certmonger/stop_pkicad post-save command: /usr/libexec/ipa/certmonger/renew_ca_cert "caSigningCert cert-pki-ca" track: yes auto-renew: yes Request ID '20180131032623': status: CA_UNREACHABLE ca-error: Error 58 connecting to https://ipa1.domain.com:8443/ca/agent/ca/profileReview: Problem with the local SSL certificate. stuck: no key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key' certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem' CA: dogtag-ipa-ca-renew-agent issuer: CN=Certificate Authority,O=domain.com subject: CN=IPA RA,O=domain.com expires: 2018-12-31 13:27:15 UTC key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert track: yes auto-renew: yes Request ID '20180131032624': status: MONITORING stuck: no key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='Server-Cert
[Freeipa-users] Re: CA no certs being tracked?
Chris Mohler via FreeIPA-users wrote: > I have not been able the get the expired certs renewed. I would > appreciate any help or advice that you have. Right we need information to help. getcert list output, journalctl -u certmonger or /var/log/messages, anything that will show status/output of what is going on. 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] Re: CA no certs being tracked?
I have not been able the get the expired certs renewed. I would appreciate any help or advice that you have. Thanks, -Chris ___ 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: Upgrading from V3 on Fedora to V4 on CentOS, CA promotion steps?
On 2/7/19 5:20 PM, Jernej Jakob via FreeIPA-users wrote: Thanks Florence. That was the way I had intended to do it (I've studied the process quite some time ago, enough that the guide I was studying got deleted), only my mind slipped when writing up the mail. Still, I can't run: "getcert list -d /var/lib/pki-ca/alias -n "subsystemCert cert-pki-ca" | grep post-save" or the "getcert stop-tracking ..." steps as there is no /var/lib/pki-ca on my system. Only /var/lib/pki/pki-tomcat. IIRC in RHEL6 PKI version 9 was used and the instance was installed in /var/lib/pki-ca, while in RHEL7 PKI 10 is used and the instance is in /etc/pki/pki-tomcat/ca. What's important in the steps is to make sure that the RHEL6 node does not act as renewal master any more. I have CS.cfg in: /etc/pki/pki-tomcat/ca/CS.cfg /usr/share/pki/ca/conf/CS.cfg /var/log/pki/server/upgrade/10.0.5/1/oldfiles/var/lib/pki/pki-tomcat/conf/ca/CS.cfg /etc/pki/pki-tomcat contains both the ca and alias subdirs, if I substitute this and continue, I get to a different obstacle: "getcert list -d /var/lib/pki/pki-tomcat/alias -n "subsystemCert cert-pki-ca"" returns "No request found that matched arguments." Only if I run "getcert list" without arguments I get the long list and details about each certificate: /var/lib/pki/pki-tomcat/alias is a symlink to /etc/pki/pki-tomcat/alias. getcert list | grep "subsystemCert cert-pki-ca" key pair storage: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB',pin='' certificate: type=NSSDB,location='/etc/pki/pki-tomcat/alias',nickname='subsystemCert cert-pki-ca',token='NSS Certificate DB' post-save command: /usr/lib64/ipa/certmonger/renew_ca_cert "subsystemCert cert-pki-ca" This means this is the master? Yes, the renewal master is using renew_ca_cert as postsave command while the clones are using restart_pkicad. HTH, flo If there is such a difference in the behavior (output) of getcert on my system, how can I assume the other getcert commands in the process will work? (iow, they likely won't?) - Izvirno sporočilo - Od: "Florence Blanc-Renaud" Za: "FreeIPA users list" Cc: "Jernej Jakob" Poslano: Četrtek, 7. Februar 2019 16:50:03 Zadeva: Re: [Freeipa-users] Upgrading from V3 on Fedora to V4 on CentOS, CA promotion steps? [...] Hi, please find more information here: Migrating IdM from RHEL6 to 7 [1]. The direct upgrade from IdM 3.x to 4.x is not supported, the recommended path is to install a 4.x replica from the 3.x master (with all the needed services, for instance CA, DNS, etc...) then decommission the 6.x master. HTH, flo [1] https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/migrate-6-to-7 [...] ___ 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] Re: CA no certs being tracked?
On 2/7/19 8:22 PM, Chris Mohler via FreeIPA-users wrote: I have not been able to renew the expired certificates yet. I would appreciate help if possible. You will need to start repairing the CA renewal master. Can you provide the output of $ getcert list on that node? Depending on the list of expired certs and their validity dates we will be able to suggest the next steps. It usually involves stopping ntpd, setting the date back to a time when all the certs are valid and letting certmonger do its job. Any error related to certmonger in the journal may also help understand why the renewal failed. HTH, flo Followup summary: Q: Seems like part of the problem is that the KDC was not running. Had you done ipactl stop prior to the upgrade? A: I could not get the KDC to stay running. So yes it was off during the upgrade. Q: Did it end up creating the tracking? Are there expired certs? A: I was able to get the upgrade to finish successfully, after restoring the server from VM snapshot, rolling back the system date, and trying the update again. It did create the cert tracking!!! Yes there are expired certs. Q: As an aside, I'd have suggest deferring the package upgrade until after the other things were sorted. It just adds another moving part. Water under the bridge now. A: Yes sorry. On 2/5/2019 11:18 AM, Rob Crittenden wrote: Chris Mohler wrote: Well... That was a mess. The ipa-server-upgrade didn't go so well. It failed and now my ca-replication master is broken. Here are the details. Any hope? Upgrading IPA:. Estimated time: 1 minute 30 seconds [1/11]: stopping directory server [2/11]: saving configuration [3/11]: disabling listeners [4/11]: enabling DS global lock [5/11]: disabling Schema Compat [6/11]: starting directory server [7/11]: updating schema [8/11]: upgrading server [9/11]: stopping directory server [10/11]: restoring configuration [11/11]: starting directory server Done. Update complete Upgrading IPA services Upgrading the configuration of the IPA services [Verifying that root certificate is published] [Migrate CRL publish directory] CRL tree already moved [Verifying that CA proxy configuration is correct] IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. CA did not start in 300.0s The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information Seems like part of the problem is that the KDC was not running. Had you done ipactl stop prior to the upgrade? Did it end up creating the tracking? Are there expired certs? As an aside, I'd have suggest deferring the package upgrade until after the other things were sorted. It just adds another moving part. Water under the bridge now. rob Here is a wall of errors from my /var/log/ipaupgrade.log Feb 4 17:47:33 ipa2 ns-slapd: [04/Feb/2019:17:47:33.947136504 -0500] - ERR - set_krb5_creds - Could not get initial credentials for principal [ldap/ipa2.domain@domain.com] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) Feb 4 17:47:33 ipa2 ns-slapd: [04/Feb/2019:17:47:33.953577522 -0500] - ERR - slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) Feb 4 17:47:33 ipa2 ns-slapd: [04/Feb/2019:17:47:33.958062514 -0500] - ERR - set_krb5_creds - Could not get initial credentials for principal [ldap/ipa2.domain@domain.com] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm) Feb 4 17:47:33 ipa2 ns-slapd: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (No Kerberos credentials available (default cache: /tmp/krb5cc_389)) Feb 4 17:47:33 ipa2 ns-slapd: [04/Feb/2019:17:47:33.965496432 -0500] - ERR - slapi_ldap_bind - Error: could not bind id [cn=Replication Manager masterAgreement1-ipa2.domain.com-pki-tomcat,ou=csusers,cn=config] authentication mechanism [SIMPLE]: error 32 (No such object) Feb 4 17:47:40 ipa2 server: WARNING: Exception processing realm com.netscape.cms.tomcat.ProxyRealm@3badc78b background process Feb 4 17:47:40 ipa2 server: javax.ws.rs.ServiceUnavailableException: Subsystem unavailable Feb 4 17:47:40 ipa2 server: at com.netscape.cms.tomcat.ProxyRealm.backgroundProcess(ProxyRealm.java:137) Feb 4 17:47:40 ipa2 server: at org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1356) Feb 4 17:47:40 ipa2 server: at org.apache.catalina.core.StandardContext.backgroundProcess(StandardContext.java:5958) Feb 4 17:47:40 ipa2 server: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1542) Feb 4 17:47:40 ipa2 server: at org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1552) Feb 4 17:47:40 ipa2 server: at
