June 2022 - FreeIPA-users - Fedora mailing-lists

freeipa/certmonger for openvpn user certificates
by Patrick Spinler 27 Jun '22

27 Jun '22

Hi, I'm setting up an openvpn server and I'd like to use our already existing FreeIPA CA to issue user keys/certs for openvpn's use. Since our OpenVPN box is a freeipa client, I thought it'd be nice to use certmonger to issue and keep up to date these certs. Ergo, I've created a certificate profile: pat@apex-freeipa ~$ ipa certprofile-show --all OpenVPNUserCert dn: cn=OpenVPNUserCert,cn=certprofiles,cn=ca,dc=int,dc=apexmw,dc=com Profile ID: OpenVPNUserCert Profile description: OpenVPN User Certificates Store issued certificates: FALSE objectclass: ipacertprofile, top And also a CA acl. For experimentation (and working vs our test freeipa) I've left this as wide open as I can: [pat@apex-freeipa ~]$ ipa caacl-show --all OpenVPN_User_Certificate_ACL dn: ipaUniqueID=6dde33a6-7849-11e9-aa05-525400b52c7b,cn=caacls,cn=ca,dc=int,dc=apexmw,dc=com ACL name: OpenVPN_User_Certificate_ACL Enabled: TRUE CA category: all Profile category: all User category: all Host category: all Service category: all ipauniqueid: 6dde33a6-7849-11e9-aa05-525400b52c7b objectclass: ipaassociation, ipacaacl Then, on my openvpn server, I ask for a cert for use for one of my users (myself, in this case): root@apex-openvpn:~# ipa-getcert request -f /etc/openvpn/client/pat.crt -k /etc/openvpn/client/pat.key -r -N 'CN=pat,O=INT.APEXMW.COM' -K pat -g 4096 --profile OpenVPNUserCert New signing request "20190603014016" added. But, it fails due to an access err vs the 'userCertificate' attribute of my account: root@apex-openvpn:~# ipa-getcert list (...snippy snip excess...) Request ID '20190603014016': status: CA_REJECTED ca-error: Server at https://apex-freeipa.int.apexmw.com/ipa/xml denied our request, giving up: 2100 (RPC failed at server. Insufficient access: Insufficient 'write' privilege to the 'userCertificate' attribute of entry 'uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com'.). stuck: yes key pair storage: type=FILE,location='/etc/openvpn/client/pat.key' certificate: type=FILE,location='/etc/openvpn/client/pat.crt' CA: IPA issuer: subject: expires: unknown pre-save command: post-save command: track: yes auto-renew: yes If I look at the dirsrv log, here's the accesses I see for this request (trimmed off the date/time to make the lines a _little_ shorter): root@apex-freeipa slapd-INT-APEXMW-COM# grep conn=178 access | cut -d' ' -f3- conn=178 fd=114 slot=114 connection from 10.10.200.1 to 10.10.200.1 conn=178 op=0 BIND dn="" method=sasl version=3 mech=GSS-SPNEGO conn=178 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0025554208 dn="fqdn=apex-openvpn.int.apexmw.com,cn=computers,cn=accounts,dc=int,dc=apexmw,dc=com" conn=178 op=1 SRCH base="cn=ipaconfig,cn=etc,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs=ALL conn=178 op=1 RESULT err=0 tag=101 nentries=1 etime=0.0001319554 conn=178 op=2 SRCH base="cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaConfigObject)(cn=CA))" attrs=ALL conn=178 op=2 RESULT err=0 tag=101 nentries=1 etime=0.0000979573 conn=178 op=3 SRCH base="cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaConfigObject)(cn=CA))" attrs=ALL conn=178 op=3 RESULT err=0 tag=101 nentries=1 etime=0.0000736730 conn=178 op=4 SRCH base="cn=cas,cn=ca,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaca)(cn=ipa))" attrs="" conn=178 op=4 RESULT err=0 tag=101 nentries=1 etime=0.0000499142 conn=178 op=5 SRCH base="cn=ipa,cn=cas,cn=ca,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="ipaCaId ipaCaSubjectDN cn ipaCaIssuerDN description" conn=178 op=5 RESULT err=0 tag=101 nentries=1 etime=0.0000482726 conn=178 op=6 SRCH base="cn=apex-freeipa.int.apexmw.com,cn=masters,cn=ipa,cn=etc,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=ipaConfigObject)(ipaConfigString=enabledService)(cn=CA))" attrs=ALL conn=178 op=6 RESULT err=0 tag=101 nentries=1 etime=0.0000950646 notes=U conn=178 op=7 SRCH base="cn=accounts,dc=int,dc=apexmw,dc=com" scope=2 filter="(&(objectClass=krbprincipalaux)(krbPrincipalName=pat(a)INT.APEXMW.COM))" attrs=ALL conn=178 op=7 RESULT err=0 tag=101 nentries=1 etime=0.0002747849 conn=178 op=8 EXT oid="1.3.6.1.4.1.4203.1.11.3" name="whoami-plugin" conn=178 op=8 RESULT err=0 tag=120 nentries=0 etime=0.0000135034 conn=178 op=9 SRCH base="cn=request certificate ignore caacl,cn=virtual operations,cn=etc,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="objectClass" conn=178 op=9 RESULT err=0 tag=101 nentries=1 etime=0.0000932668 - entryLevelRights: none conn=178 op=10 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="distinguishedName" conn=178 op=10 RESULT err=0 tag=101 nentries=1 etime=0.0000640289 conn=178 op=11 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="telephoneNumber ipaSshPubKey uid krbCanonicalName ipatokenRadiusUserName ipaUserAuthType krbPrincipalExpiration homeDirectory nsAccountLock usercertificate;binary title loginShell uidNumber mail ipaCertMapData memberOf memberofindirect krbPrincipalName givenName gidNumber sn ou userClass ipatokenRadiusConfigLink" conn=178 op=11 RESULT err=0 tag=101 nentries=1 etime=0.0001401737 conn=178 op=12 SRCH base="dc=int,dc=apexmw,dc=com" scope=2 filter="(|(member=uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com)(memberUser=uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com)(memberHost=uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com))" attrs="" conn=178 op=12 RESULT err=0 tag=101 nentries=7 etime=0.0001492344 notes=P pr_idx=0 pr_cookie=-1 conn=178 op=13 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(userPassword=*)" attrs="userPassword" conn=178 op=13 RESULT err=0 tag=101 nentries=1 etime=0.0000524838 conn=178 op=14 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(krbPrincipalKey=*)" attrs="krbPrincipalKey" conn=178 op=14 RESULT err=0 tag=101 nentries=1 etime=0.0000597589 conn=178 op=15 SRCH base="ipaUniqueID=80b23b30-6a0c-11e9-baa3-525400b52c7b,cn=sudorules,cn=sudo,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="cn" conn=178 op=15 RESULT err=0 tag=101 nentries=1 etime=0.0000379744 conn=178 op=16 SRCH base="ipaUniqueID=5fb3a640-705a-11e9-aa05-525400b52c7b,cn=hbac,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="cn" conn=178 op=16 RESULT err=0 tag=101 nentries=1 etime=0.0000337904 conn=178 op=17 SRCH base="cn=caacls,cn=ca,dc=int,dc=apexmw,dc=com" scope=1 filter="(&(objectClass=ipaassociation)(objectClass=ipacaacl))" attrs="serviceCategory cn ipaMemberCertProfile ipaMemberCa ipaCertProfileCategory memberUser userCategory hostCategory memberHost ipaEnabledFlag ipaCaCategory memberService description" conn=178 op=17 RESULT err=0 tag=101 nentries=2 etime=0.0001647058 conn=178 op=18 EXT oid="1.3.6.1.4.1.4203.1.11.3" name="whoami-plugin" conn=178 op=18 RESULT err=0 tag=120 nentries=0 etime=0.0000138321 conn=178 op=19 SRCH base="uid=pat,cn=users,cn=accounts,dc=int,dc=apexmw,dc=com" scope=0 filter="(objectClass=*)" attrs="userCertificate" conn=178 op=19 RESULT err=0 tag=101 nentries=1 etime=0.0001475052 - entryLevelRights: none conn=178 op=20 UNBIND conn=178 op=20 fd=114 closed - U1 To begin with, I note that this session does a BIND with 'dn=""', right at the beginning, it's essentially an anonymous bind, yah? That operation near the end, here: op=17 SRCH base="cn=caacls,cn=ca,dc=int,dc=apexmw,dc=com" scope=1 filter="(&(objectClass=ipaassociation)(objectClass=ipacaacl))" seems like it might be kinda key. and indeed, if I attempt to run this by hand as an anonymous bind, I get no results: root@apex-freeipa slapd-INT-APEXMW-COM# ldapsearch -x -h localhost -b dc=int,dc=apexmw,dc=com -s sub "(|(objectClass=ipaassociation)(objectClass=ipacaacl))" # extended LDIF # # LDAPv3 # base <dc=int,dc=apexmw,dc=com> with scope subtree # filter: (|(objectClass=ipaassociation)(objectClass=ipacaacl)) # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 It's only if I run this as an _authenticated_ bind, that I can find my ACL: root@apex-freeipa slapd-INT-APEXMW-COM# ldapsearch -x -D "cn=Directory Manager" -W -h localhost -b dc=int,dc=apexmw,dc=com -s sub "(&(objectClass=ipaassociation)(objectClass=ipacaacl))" cn Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=int,dc=apexmw,dc=com> with scope subtree # filter: (&(objectClass=ipaassociation)(objectClass=ipacaacl)) # requesting: cn # # c98b740c-6903-11e9-ad1b-525400b52c7b, caacls, ca, int.apexmw.com dn: ipaUniqueID=c98b740c-6903-11e9-ad1b-525400b52c7b,cn=caacls,cn=ca,dc=int,dc =apexmw,dc=com cn: hosts_services_caIPAserviceCert # 6dde33a6-7849-11e9-aa05-525400b52c7b, caacls, ca, int.apexmw.com dn: ipaUniqueID=6dde33a6-7849-11e9-aa05-525400b52c7b,cn=caacls,cn=ca,dc=int,dc =apexmw,dc=com cn: OpenVPN_User_Certificate_ACL # search result search: 2 result: 0 Success # numResponses: 3 # numEntries: 2 Is this (using certmonger to auto-issue signed certs/keys for my openvpn users) going to be essentially impossible to do, here? Do I need to go a more traditional route of creating a seperate keystore/certdb, issuing a CSR, and feeding that to FreeIPA to sign? Any advice appreciated, and thanks in advance, -- Pat

4 6

Possible to remove trust controller role?
by Ranbir 24 Jun '22

24 Jun '22

Hi Everyone, Is it possible to remove the trust controller role from masters? I ran the trust agent setup on two masters that I just wanted to handle the trust agent role and now they're showing up as trust controllers, too. I don't know why that happened since I've done this before. I could run the server uninstall on those two masters and enroll them again. But, I'd like to avoid that if I can. Thanks in advance. -- Ranbir

2 3

Kerberos after migration
by skrawczenko＠gmail.com 24 Jun '22

24 Jun '22

Hello again. I gave up restoring certificates as discussed in https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… While i had to recover the service and rescue data at any cost So my decision was probably wrong but i didn't have options I deployed RedHat instead of CentOS and then deployed fresh IPA 4.9.8 Then i migrated directory from the old cluster excluding kerberos fields and some service accounts/groups Rebuilt DNS etc Initially everything was good at least users, groups and credentials were saved. But further configuration resulted some troubles. Briefly, i can't run commands as admin and anyone else kinit admin Password for admin@<REALM> [root@idm0 ~]# klist Ticket cache: KCM:0 Default principal: admin@<REALM> Valid starting Expires Service principal 06/20/22 07:42:19 06/21/22 06:42:23 krbtgt/<REALM>@<REALM> [root@idm0 ~]# ipa user-show admin ipa: ERROR: cannot connect to 'https://idm0...../ipa/session/json': Exceeded number of tries to forward a request. kinit <any other user> ipa user-show <any other user> ipa: ERROR: Insufficient access: Invalid credentials and /var/log/httpd/error.log has ipa: INFO: 401 Unauthorized: Insufficient access: Invalid credential What could be broken? This happened while i was trying to generate a keytab for kinit -kt <file> scripts...

5 7

Error upon establishing trust
by Ronald Wimmer 24 Jun '22

24 Jun '22

Hi, we have set up two more IPA environments. Today we tried to establish the trust to the AD domain but unfortunately we were not successful: [root@pipag01 ~]# ipa trust-add --type=ad someaddomain.at --admin someadadmin --password Active Directory domain administrator's password: ipa: ERROR: CIFS server communication error: code "3221225653", message "{Device Timeout} The specified I/O operation on %hs was not completed before the time-out period expired." (both may be "None") What might be the cause? Where should we take a closer look? Cheers, Ronald

2 2

Problem registering CentOS 8 Client to IPA server 4.6.8-5
by Alex Bihlmaier 22 Jun '22

22 Jun '22

Hiya. I am running IPA server 4.6.8-5 on CentOS 7 and there is an issue registering a CentOS 8 client to this IPA System. When using CentOS 7 registering works flawless. On CentOS 8 it fails because: " Unable to initialize STARTTLS session Connect error: TLS: hostname does not match subjectAltName in peer certificate Failed to bind to server! Retrying with pre-4.0 keytab retrieval method... Unable to initialize STARTTLS session Connect error: TLS: hostname does not match subjectAltName in peer certificate Failed to bind to server! Failed to get keytab " I will attach the complete log.

2 3

"Invalid IV size (16) for CBC" when retrieving from vaults via RHEL 9 server
by Sam Morris 22 Jun '22

22 Jun '22

I've added a RHEL 9 server to my IPA domain and I am finding that 'ipa vault-retrieve' fails intermittently. It turns out that whenever the ipa client talks to the RHEL 9 server, this error happens: $ ipa vault-retrieve --service host/myhost.example.com manager-password Traceback (most recent call last): File "/usr/lib/python3/dist-packages/ipalib/backend.py", line 141, in execute return self.Command[_name](*args, **options) File "/usr/lib/python3/dist-packages/ipalib/frontend.py", line 471, in __call__ return self.__do_call(*args, **options) File "/usr/lib/python3/dist-packages/ipalib/frontend.py", line 499, in __do_call ret = self.run(*args, **options) File "/usr/lib/python3/dist-packages/ipalib/frontend.py", line 1229, in run return self.forward(*args, **options) File "/usr/lib/python3/dist-packages/ipaclient/plugins/vault.py", line 1069, in forward vault_data = self._unwrap_response( File "/usr/lib/python3/dist-packages/ipaclient/plugins/vault.py", line 1021, in _unwrap_response cipher = Cipher(algo, modes.CBC(nonce), backend=default_backend()) File "/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/ciphers/base.py", line 97, in __init__ mode.validate_for_algorithm(algorithm) File "/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/ciphers/modes.py", line 85, in _check_iv_and_key_length _check_iv_length(self, algorithm) File "/usr/lib/python3/dist-packages/cryptography/hazmat/primitives/ciphers/modes.py", line 69, in _check_iv_length raise ValueError( ValueError: Invalid IV size (16) for CBC. ipa: ERROR: an internal error has occurred I can reproduce this both on Debian unstable (with ipalib 4.9.8-1) and RHEL 8. I do this by overriding the value of xmlrpc_uri in /etc/ipa/default.conf to point to the RHEL 9 server before running 'ipa vault-retrieve'. If I run the command on the RHEL 9 server, it works fine. I don't have a RHEL 9 client to test with. -- Sam Morris <https://robots.org.uk/> PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9

2 2

Re: ipa-server-certinstall -k
by Fraser Tweedale 21 Jun '22

21 Jun '22

On Mon, Jun 20, 2022 at 07:49:16PM +0000, Charles Hedrick wrote: > Keeping our own certificates up to date on the various types of > clients is messy enough that we gave up on that. > > The only thing we would actually use it for is kinit -n, to > bootstrap kinit for OTP. While kinit -n would be the most elegant > way to do it, we have several other approaches. > > Documentation seems to say that if pkinit_eku_checking is set to > kpServerAuth, we don't need the extension. I've found that kinit > -n actually does work when the client sets this. However I have to > install the certificates manually on the KDC, since the command > won't do it. This approach substitutes a certificate distribution requirement with a config distribution requirement. Every client would have to accept the certificate with id-kp-serverAuth instead of id-pkinit-KPKdc** - non-default behaviour which does not conform to RFC 4556. Some client implementations might not have a workaround. This workaround might be acceptable for your environment. In general, accepting certificates that do not conform to the requirements of RFC 4556 introduces a substantial risk of FreeIPA administrators misconfiguring their environment. Rob & Michal, perhaps this can be considered as an RFE: to relax this requirement via a flag, accompanied by ample warnings? ** id-pkinit-KPKdc is not required if the krbtgt/REALM principal name appears in a id-pkinit-san otherName SAN value. But public CAs will not include that either. Thanks, Fraser > ________________________________ > From: Fraser Tweedale <ftweedal(a)redhat.com> > Sent: Sunday, June 19, 2022 11:34 PM > To: Charles Hedrick <hedrick(a)rutgers.edu>; Rob Crittenden via FreeIPA-users <freeipa-users(a)lists.fedorahosted.org> > Cc: Rob Crittenden <rcritten(a)redhat.com> > Subject: Re: [Freeipa-users] Re: ipa-server-certinstall -k > > On Wed, Jun 15, 2022 at 04:23:30PM -0400, Rob Crittenden via FreeIPA-users wrote: > > Charles Hedrick via FreeIPA-users wrote: > > > the error is > > > > > > The KDC certificate in cert.pem, privkey.pem is not valid: invalid for a KDC > > > > A PKINIT certificate needs an EKU extension, > > https://datatracker.ietf.org/doc/html/rfc4556 > > > > When generating the key with OpenSSL you need to include "-extensions > > kdc_cert" > > > It's unlikely that publicly trusted CAs will issue certs with > id-pkinit-KPKdc in EKU. CABForum Baseline Requirements[1] > 7.1.2.3(f) says: > > Either the value id-kp-serverAuth [RFC5280] or id-kp-clientAuth > [RFC5280] or both values MUST be present. id-kp-emailProtection > [RFC5280] MAY be present. Other values SHOULD NOT be present. > > [1]: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-1.8.4.pdf > > Charles, you might need to use a certificate issued directly by the > IPA CA for your KDC, or else do without PKINIT. > > Thanks, > Fraser > > > > > > > > > > > > ------------------------------------------------------------------------ > > > *From:* Charles Hedrick via FreeIPA-users > > > <freeipa-users(a)lists.fedorahosted.org> > > > *Sent:* Wednesday, June 15, 2022 3:39 PM > > > *To:* freeipa-users(a)lists.fedorahosted.org > > > <freeipa-users(a)lists.fedorahosted.org> > > > *Cc:* Charles Hedrick <hedrick(a)rutgers.edu> > > > *Subject:* [Freeipa-users] ipa-server-certinstall -k > > > > > > ipa-server-certinstall works fine for http and ldap. But I can't get the > > > -k option to work. > > > > > > I've tried cert.pem and privkey.pem with and without chain.pem, as well > > > as fullchain.pem and privkey.pem (fullchain has both the cert and the > > > chain). > > > > > > The certs were issued by Internet2, which chains up to addtrust. > > > > > > kinit -n works fine if I install the pem files manually, so presumably > > > my files are valid. > > > > > > > > > _______________________________________________ > > > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > > > To unsubscribe send an email to freeipa-users-leave(a)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.fedorahost… > > > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > > > > _______________________________________________ > > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > > To unsubscribe send an email to freeipa-users-leave(a)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.fedorahost… > > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure >

3 2

ipa_check_consistency - Ghost
by Kathy Zhu 21 Jun '22

21 Jun '22

Hello team, We use ipa_check_consistency <https://github.com/peterpakos/checkipaconsistency/blob/master/README.md> tool to check IPA master consistency every night via cron. One of the masters failed at Ghost last night. Here is the check for Ghost: ldapsearch -o ldif-wrap=no -ZZ -LLLx -h ipa1.example.com -D "cn=Directory Manager" -W -s sub -b "dc=example,dc=com" "(&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff))" nscpentrywsi What is the significance of this inconsistency? Is there a way to fix this other than reinitialize? Thanks. Kathy.

2 2

Failed to read data from service file: Failed to get list of services to probe status!
by rui liang 21 Jun '22

21 Jun '22

root@ipa-test-65-191:/var/log/dirsrv/slapd-YYDEVOPS-COM# ipactl start Existing service file detected! Assuming stale, cleaning and proceeding Starting Directory Service Failed to read data from service file: Failed to get list of services to probe status! Configured hostname 'ipa-test-65-191.hiido.host.yydevops.com' does not match any master server in LDAP: ipa-test-65-190.hiido.host.yydevops.com Shutting down my topology A<->B A (CA) B (replica) ssh A root@ipa-test-65-190:/home/liangrui# ipa-replica-manage list ipa-test-65-190.hiido.host.yydevops.com: master ipa-test-65-191.hiido.host.yydevops.com: master root@ipa-test-65-190:/home/liangrui# ipa-replica-manage del ipa-test-65-191.hiido.host.yydevops.com Checking connectivity in topology suffix 'ca' 'ipa-test-65-191.hiido.host.yydevops.com' is not a part of topology suffix 'ca' Not checking connectivity Checking connectivity in topology suffix 'domain' Skipping replication agreement deletion check for suffix 'ca' Checking for deleted segments in suffix 'domain' Agreements deleted root@ipa-test-65-190:/home/liangrui# ipa-replica-manage list ipa-test-65-190.hiido.host.yydevops.com: master ssh B root@ipa-test-65-191:/home/liangrui# ipactl status Directory Service: STOPPED Directory Service must be running in order to obtain status of other services ipa: INFO: The ipactl command was successful root@ipa-test-65-191:/home/liangrui# ipactl start Existing service file detected! Assuming stale, cleaning and proceeding Starting Directory Service Failed to read data from service file: Failed to get list of services to probe status! Configured hostname 'ipa-test-65-191.hiido.host.yydevops.com' does not match any master server in LDAP: ipa-test-65-190.hiido.host.yydevops.com Shutting down root@ipa-test-65-191:/home/liangrui# ipa-replica-install ipa.ipapython.install.cli.install_tool(Replica): ERROR IPA server is already configured on this system. If you want to reinstall the IPA server, please uninstall it first using 'ipa-server-install --uninstall'. ipa.ipapython.install.cli.install_tool(Replica): ERROR The ipa-replica-install command failed. See /var/log/ipareplica-install.log for more information ssh A root@ipa-test-65-190:/home/liangrui# ipa hostgroup-add-member ipaservers --hosts ipa-test-65-191.hiido.host.yydevops.com Host-group: ipaservers Description: IPA server hosts Member hosts: ipa-test-65-190.hiido.host.yydevops.com, ipa-test-65-191.hiido.host.yydevops.com ------------------------- Number of members added 1 ------------------------- root@ipa-test-65-190:/home/liangrui# ipa topologysegment-add --leftnode=ipa-test-65-191.hiido.host.yydevops.com --rightnode=ipa-test-65-190.hiido.host.yydevops.com Suffix name: domain Segment name [ipa-test-65-191.hiido.host.yydevops.com-to-ipa-test-65-190.hiido.host.yydev…] ipa: ERROR: invalid 'leftnode': left node is not a topology node: ipa-test-65-191.hiido.host.yydevops.com Why is service B unavailable after copy B is deleted and cannot be restored?Is this a normal phenomenon?How to recover? Request big guy guidance, thank you!

2 2

SAN not added to requested cert
by Ranbir 21 Jun '22

21 Jun '22

Hello Everyone, I have an AlmaLinux 9.0 client enrolled into a 4.9.8 ipa domain running on a Rocky Linux 8.6 server. I'm running the following command on the client to request a cert: ipa-getcert request -I cockpit -k /etc/cockpit/ws-certs.d/0-cockpit.key -f /etc/cockpit/ws-certs.d/0-cockpit.crt -g 2048 -K HTTP/$(hostname) -D hostname.theinside.rnr -m 640 -M 640 -o root:cockpit-ws -O root:cockpit-ws The cert gets issued without error. But, I don't see the "dns" line in the ouput: status: MONITORING stuck: no key pair storage: type=FILE,location='/etc/cockpit/ws- certs.d/0-cockpit.key' certificate: type=FILE,location='/etc/cockpit/ws-certs.d/0- cockpit.crt' CA: IPA issuer: CN=Certificate Authority,O=THEINSIDE.RNR subject: CN=hostname.theinside.rnr,O=THEINSIDE.RNR issued: 2022-06-20 21:31:39 EDT expires: 2024-06-20 21:31:39 EDT principal name: HTTP/hostname.theinside.rnr(a)THEINSIDE.RNR key usage: digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment eku: id-kp-serverAuth,id-kp-clientAuth pre-save command: post-save command: track: yes auto-renew: yes The result is Firefox complains about the cert when I try to visit the cockpit web UI. I've run it now a few times with the same result. Which one of the myriad of logs should I check to maybe understand why this is happening? -- Ranbir

1 2

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users June 2022