[Freeipa-users] Re: CA not configured on second replica but it is configured

[Pavlo Pocheptsov via FreeIPA-users]

Hi Rob and thanks for your answer.
Indeed, I see this error:

[root@ipa2 ~]# ipa-replica-manage -v list ipa2.fluent.local
> ipa3.fluent.local: replica
>   last update status: Error (18) Replication error acquiring replica:
> Incremental update transient warning.  Backing off, will retry update
> later. (transient warning)
>   last update ended: 1970-01-01 00:00:00+00:00
>

Is it possible to remove a reclipa with "ipa-replica-manage del ipa2" and
then connect it again with the same name?

On Mon, 23 May 2022 at 23:08, Rob Crittenden  wrote:

> Pavlo Pocheptsov via FreeIPA-users wrote:
> > Hi list.
> > ipa2 node was promoted to ca with ipa-ca-instal
> > and it shows all is good on its side:
> >
> > [root@ipa2 ~]# ipa-replica-manage list
> > ipa3: master
> > ipa2: master
> > [root@ipa2 ~]# ipa-csreplica-manage list
> > ipa3: master
> > ipa2: *master*
> > [root@ipa2 ~]# ipa config-show |grep CA
> >   Certificate Subject base: O=removed
> >   IPA CA servers: *ipa2, ipa3*
> >   IPA CA renewal master: ipa3
> > [root@ipa2 ~]# ipa server-role-find | grep -A1 -B1 CA
> >   Server name: ipa2
> >   Role name: CA server
> >   Role status: *enabled*
> > --
> >   Server name: ipa3
> >   Role name: CA server
> >   Role status: *enabled*
> > [root@ipa2 ~]# ipa-replica-manage list-ruv
> > Replica Update Vectors:
> > ipa2:389: 11
> > ipa3:389: 9
> > Certificate Server Replica Update Vectors:
> > ipa2:389: 12
> > ipa3:389: 10
> >
> > But ipa3 node doesn't see ipa2 as ca master:
> >
> > [root@ipa3 ~]# ipa-replica-manage list
> > ipa3: master
> > ipa2: master
> > [root@ipa3 ~]# ipa-csreplica-manage list
> > ipa3: master
> > ipa2: *CA not configured*
> > [root@ipa3 ~]# ipa config-show |grep CA
> >   Certificate Subject base: O=removed
> >   IPA CA servers: *ipa3*  <- no ipa2 here
> >   IPA CA renewal master: ipa3
> > [root@ipa3 ~]# ipa server-role-find | grep -B1 -A1 CA
> >   Server name: ipa2
> >   Role name: CA server
> >   Role status: *absent*
> > --
> >   Server name: ipa3
> >   Role name: CA server
> >   Role status: enabled
> > [root@ipa3 ~]# ipa-replica-manage list-ruv
> > Replica Update Vectors:
> > ipa3:389: 9
> > ipa2:389: 11
> > Certificate Server Replica Update Vectors:
> > ipa3:389: 10
> > ipa2:389: 12
> >
> > Centos 7.9
> > FreeIPA, version: 4.6.8
> >
> > What is the real situation here? Is there CA replication btw replicas or
> no?
> > Is it possible to fix this and make ipa2 CA role visible on ipa3?
> > Any extra information I can provide to fully understand the issue?
>
> I'd look for replication issues.
>
> rob
>
>
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: CA not configured on second replica but it is configured

[Rob Crittenden via FreeIPA-users]

Pavlo Pocheptsov via FreeIPA-users wrote:
> Hi list.
> ipa2 node was promoted to ca with ipa-ca-instal
> and it shows all is good on its side:
> 
> [root@ipa2 ~]# ipa-replica-manage list
> ipa3: master
> ipa2: master
> [root@ipa2 ~]# ipa-csreplica-manage list
> ipa3: master
> ipa2: *master*
> [root@ipa2 ~]# ipa config-show |grep CA
>   Certificate Subject base: O=removed
>   IPA CA servers: *ipa2, ipa3*
>   IPA CA renewal master: ipa3
> [root@ipa2 ~]# ipa server-role-find | grep -A1 -B1 CA
>   Server name: ipa2
>   Role name: CA server
>   Role status: *enabled*
> --
>   Server name: ipa3
>   Role name: CA server
>   Role status: *enabled*
> [root@ipa2 ~]# ipa-replica-manage list-ruv
> Replica Update Vectors:
> ipa2:389: 11
> ipa3:389: 9
> Certificate Server Replica Update Vectors:
> ipa2:389: 12
> ipa3:389: 10
> 
> But ipa3 node doesn't see ipa2 as ca master:
> 
> [root@ipa3 ~]# ipa-replica-manage list
> ipa3: master
> ipa2: master
> [root@ipa3 ~]# ipa-csreplica-manage list
> ipa3: master
> ipa2: *CA not configured*
> [root@ipa3 ~]# ipa config-show |grep CA
>   Certificate Subject base: O=removed
>   IPA CA servers: *ipa3*  <- no ipa2 here
>   IPA CA renewal master: ipa3
> [root@ipa3 ~]# ipa server-role-find | grep -B1 -A1 CA
>   Server name: ipa2
>   Role name: CA server
>   Role status: *absent*
> --
>   Server name: ipa3
>   Role name: CA server
>   Role status: enabled
> [root@ipa3 ~]# ipa-replica-manage list-ruv
> Replica Update Vectors:
> ipa3:389: 9
> ipa2:389: 11
> Certificate Server Replica Update Vectors:
> ipa3:389: 10
> ipa2:389: 12
> 
> Centos 7.9
> FreeIPA, version: 4.6.8
> 
> What is the real situation here? Is there CA replication btw replicas or no?
> Is it possible to fix this and make ipa2 CA role visible on ipa3?
> Any extra information I can provide to fully understand the issue?

I'd look for replication issues.

rob
___
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahosted.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

[Freeipa-users] Re: expired Server-cert

[Rob Crittenden via FreeIPA-users]

Serge Krawczenko via FreeIPA-users wrote:
> Hello again
> I was so hoping the story to end but nope.
> 
> ipa-cert-fix managed to renew one of the certs
> but failed on the following ones
> 
> 
> Enter "yes" to proceed: yes
> Proceeding.
> ipapython.ipautil: DEBUG: Starting external process
> ipapython.ipautil: DEBUG: args=pki-server cert-fix --ldapi-socket
> /var/run/slapd-...socket --agent-uid ipara --cert subsystem --cert
> ca_ocsp_signing --extra-cert 268304408 --extra-cert 268304410
> ipapython.ipautil: DEBUG: Process finished, return code=1
> ipapython.ipautil: DEBUG: stdout=ERROR: [SSL:
> SSLV3_ALERT_HANDSHAKE_FAILURE] sslv3 alert handshake failure (_ssl.c:618)
> 
> ipapython.ipautil: DEBUG: stderr=INFO: Loading password config:
> /etc/pki/pki-tomcat/password.conf
> INFO: Fixing the following system certs: ['subsystem', 'ca_ocsp_signing']
> INFO: Renewing the following additional certs: ['268304408', '268304410']
> SASL/EXTERNAL authentication started
> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> SASL SSF: 0
> INFO: Stopping the instance to proceed with system cert renewal
> INFO: Configuring LDAP password authentication
> INFO: Setting pkidbuser password via ldappasswd
> SASL/EXTERNAL authentication started
> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> SASL SSF: 0
> INFO: Selftests disabled for subsystems: ca
> INFO: Resetting password for uid=ipara,ou=people,o=ipaca
> SASL/EXTERNAL authentication started
> SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
> SASL SSF: 0
> INFO: Starting the instance
> INFO: Sleeping for 10 seconds to allow server time to start...
> INFO: Requesting new cert for subsystem
> INFO: Getting subsystem cert info for ca
> INFO: Trying to setup a secure connection to CA subsystem.
> INFO: Starting new HTTPS connection (1): myhost.com 
> INFO: Stopping the instance
> INFO: Selftests enabled for subsystems: ca
> INFO: Restoring previous LDAP configuration
> 
> ipapython.admintool: DEBUG:   File
> "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 178, in
> execute
>     return_value = self.run()
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cert_fix.py",
> line 128, in run
>     replicate_dogtag_certs(subject_base, ca_subject_dn, certs)
>   File
> "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_cert_fix.py",
> line 251, in replicate_dogtag_certs
>     cert = x509.load_certificate_from_file(cert_path)
>   File "/usr/lib/python2.7/site-packages/ipalib/x509.py", line 425, in
> load_certificate_from_file
>     with open(filename, mode='rb') as f:
> 
> ipapython.admintool: DEBUG: The ipa-cert-fix command failed, exception:
> IOError: [Errno 2] No such file or directory:
> '/etc/pki/pki-tomcat/certs/subsystem.crt'
> ipapython.admintool: ERROR: [Errno 2] No such file or directory:
> '/etc/pki/pki-tomcat/certs/subsystem.crt'
> ipapython.admintool: ERROR: The ipa-cert-fix command failed.
> 
> The csr for subsystem was added according
> to https://access.redhat.com/solutions/4852721
> 
> At the time of the above failure in /var/log/pki/pki-tomcat/ca/debug:
> 
> [20/May/2022:07:43:59][localhost-startStop-1]:
> Certutils.verifySystemCertValidityByNickname:  failed :
> java.lang.Exception: Certutils.verifySystemCertValidityByNickname:
>  failed: nickname: ocspSigningCert
>  cert-pki-ca
> [20/May/2022:07:43:59][localhost-startStop-1]: CertUtils:
> verifySystemCertsByTag() failed: java.lang.Exception:
> Certutils.verifySystemCertValidityByNickname:  faliled: nickname:
> ocspSigningCert cert-pki-c
> acause: java.lang.Exception:
> Certutils.verifySystemCertValidityByNickname:  failed: nickname:
> ocspSigningCert cert-pki-ca
> [20/May/2022:07:43:59][localhost-startStop-1]: SignedAuditLogger: event
> CIMC_CERT_VERIFICATION
> [20/May/2022:07:43:59][localhost-startStop-1]: SignedAuditLogger: event
> CIMC_CERT_VERIFICATION
> java.lang.Exception: Certutils.verifySystemCertValidityByNickname:
>  faliled: nickname: ocspSigningCert cert-pki-cacause:
> java.lang.Exception: Certutils.verifySystemCertValidityByNickname:
>  failed: nicknam
> e: ocspSigningCert cert-pki-ca
>         at
> com.netscape.cmscore.cert.CertUtils.verifySystemCertValidityByNickname(CertUtils.java:839)
> 
> Nothing else suspicious

Which certificate was re-issued successfully?

It appears that pki-server-certfix, for which IPA is a wrapper, failed
to connect to the server. Whether the OCSP certs errors are related or
not I don't know. Does that cert exist in your PKI NSS database?

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/freei

[Freeipa-users] Re: hostgroup automember rules

[Angus Clarke via FreeIPA-users]

Thanks a lot Alexander.

From: Alexander Bokovoy 
Sent: 20 May 2022 13:39
To: FreeIPA users list 
Cc: Angus Clarke 
Subject: Re: [Freeipa-users] hostgroup automember rules

Hi Angus,

On pe, 20 touko 2022, Angus Clarke via FreeIPA-users wrote:
>Hello
>
>FreeIPA 4.6.8
>
>We are very happy with hostgroup automember rules based on servername
>attribute however one of our internal customers uses a generic
>servername template for all of their servers regardless of its
>function.
>
>So I'm wondering what other attributes I might use for hostgroup
>automember - perhaps some of the attributes can be configured by the
>ipa-client-install (the host's "description" field perhaps) although I
>don't see such mention in the man page ... Presumably they could use a
>different enrollment user ("enrolledby") for each of their hostgroup
>functions (not ideal.)
>
>There are various attribute fields in the WebUI but I don't find much
>documentation for them. What is the "|" field - perhaps I can exploit
>this somehow?

Few years ago a customer of mine asked a similar question. Here is what
I answered:

--
You can use nsHardwarePlatform attribute (part of nsHost objectclass).
It is exposed as '--platform' in IPA CLI for 'ipa host-*' commands.

Originally it was supposed to be filled by the IPA client join process
to 'uname -m' value. ipa-join tools still sends it to the server but the
value is ignored completely by the join process. As the result,
nsHardwarePlatform attribute is never set on the host object.

I don't see any code in IPA itself that would rely on the content of
nsHardwarePlatform attribute. We have web UI tests upstream that modify
the field to test that you can modify it but that's all.

Alternatively, one can use userClass attribute (--class in IPA CLI for
host-* commands). This one is also not utilized and is left specifically
for the customers to define its semantics.

Another alternative is nsHostLocation attribute (--location in IPA CLI for 
host-*
commands). Again, the semantics is totally left for customers to define.

--

There are two ways of setting these fields:

  - prior to enrollment, by pre-creating a host and setting the
attributes at that time.

  - after the enrollment, right from the host using host keytab

The former can be done by a designated user/service account and can be
tuned with custom permissions to allow such modification. The latter
relies on the fact that the host principal has some write rights
already:

# kinit -k

# ipa host-show `hostname` --rights --all
   dn: fqdn=dc.ipa.test,cn=computers,cn=accounts,dc=ipa,dc=test
   Host name: dc.ipa.test
   Principal name: host/dc.ipa.t...@ipa.test
   Principal alias: host/dc.ipa.t...@ipa.test
   SSH public key: [skip]
   SSH public key fingerprint: [skip]
   Requires pre-authentication: True
   Trusted for delegation: False
   Trusted to authenticate as user: False
   Password: False
   Member of host-groups: ipaservers
   Keytab: True
   Managed by: dc.ipa.test
   Managing: dc.ipa.test
   attributelevelrights: {'aci': '', 'cn': 'rscwo', 'description': 'rscwo', 
'enrolledby': 'rsc', 'fqdn': 'rsc', 'ipaassignedidview': 'rsc', 
'ipaclientversion': 'rsc', 'ipakrbauthzdata': 'rsc', 'ipasshpubkey': 'rscwo', 
'ipauniqueid': 'rsc', 'krballowedtodelegateto': '', 
'krbauthindmaxrenewableage': '', 'krbauthindmaxticketlife': '', 
'krbcanonicalname': 'rsc', 'krbextradata': '', 'krblastadminunlock': '', 
'krblastfailedauth': '', 'krblastpwdchange': 'rscwo', 'krblastsuccessfulauth': 
'', 'krbloginfailedcount': '', 'krbmaxrenewableage': '', 'krbmaxticketlife': 
'', 'krbobjectreferences': '', 'krbpasswordexpiration': 'rsc', 
'krbprincipalaliases': 'rsc', 'krbprincipalauthind': 'rsc', 
'krbprincipalexpiration': 'rsc', 'krbprincipalkey': 'swo', 'krbprincipalname': 
'rsc', 'krbprincipaltype': '', 'krbpwdhistory': '', 'krbpwdpolicyreference': 
'', 'krbticketflags': '', 'krbticketpolicyreference': '', 'krbupenabled': '', 
'l': 'rscwo', 'managedby': 'rsc', 'memberof': 'rsc', 'nsaccountlock': '', 
'nshardwareplatform': 'rscwo', 'nshostlocation': 'rscwo', 'nsosversion': 
'rscwo', 'objectclass': 'rsc', 'serverhostname': 'rsc', 'usercertificate': 
'rscwo', 'userclass': 'rsc', 'userpassword': 'swo'}
   cn: dc.ipa.test
   ipauniqueid: b179f1ea-c4b8-11ec-9e86-52540083ff9d
   krblastpwdchange: 20220425165647Z
   objectclass: top, ipaobject, nshost, ipahost, ipaservice, pkiuser, 
krbprincipalaux, krbprincipal, krbticketpolicyaux, ipasshhost, 
ipaSshGroupOfPubKeys
   serverhostname: dc

So, the host/dc.ipa.t...@ipa.test principal can write to:

   - nsHardwarePlatform
   - nsHostLocation
   - nsOSVersion
   - l (locality)
   - description

but it cannot write to 'userClass' attribute.

A handy mapping between attributes and command parameters is
'show-mappings' command:

# ipa show-mappings host-m

[Freeipa-users] Re: hostgroup automember rules

[Angus Clarke via FreeIPA-users]

Thanks a lot Flo.

From: Florence Blanc-Renaud 
Sent: 20 May 2022 13:12
To: FreeIPA users list 
Cc: Angus Clarke 
Subject: Re: [Freeipa-users] hostgroup automember rules

Hi,

On Fri, May 20, 2022 at 11:48 AM Angus Clarke via FreeIPA-users 
mailto:freeipa-users@lists.fedorahosted.org>>
 wrote:
Hello

FreeIPA 4.6.8

We are very happy with hostgroup automember rules based on servername attribute 
however one of our internal customers uses a generic servername template for 
all of their servers regardless of its function.

So I'm wondering what other attributes I might use for hostgroup automember - 
perhaps some of the attributes can be configured by the ipa-client-install (the 
host's "description" field perhaps) although I don't see such mention in the 
man page ... Presumably they could use a different enrollment user 
("enrolledby") for each of their hostgroup functions (not ideal.)

There are various attribute fields in the WebUI but I don't find much 
documentation for them. What is the "|" field - perhaps I can exploit this 
somehow?

The automember group functionality is described in this chapter: Automating 
group membership using IdM 
CLI.
You can define a new hostgroup with an automember rule based on any attribute 
defined in the schema. Just be aware that the conditions are defined using 
Perl-compatible regular expressions (PCRE) format.
The 'l' attribute is an alias for 'locality' or 'localityname' and can contain 
any string. For any attribute you can find its description in the LDAP schema.

The host entries have multiple object classes. For instance if you run
ipa host-show server.ipa.test --all --raw
you can see all its objectclasses:
  objectClass: top
  objectClass: ipaobject
  objectClass: nshost
  objectClass: ipahost
  objectClass: ipaservice
  objectClass: pkiuser
  objectClass: krbprincipalaux
  objectClass: krbprincipal
  objectClass: krbticketpolicyaux
  objectClass: ipasshhost
  objectClass: ipaSshGroupOfPubKeys

Each object class defines the mandatory/optional attributes that the entry can 
contain. For instance in order to find the attributes for the nshost 
objectclass:
ldapsearch -LLL -o ldif-wrap=no -b cn=schema -s base objectclasses | grep -i 
nshost
objectclasses: ( nsHost-oid NAME 'nsHost' DESC 'Netscape defined objectclass' 
SUP top STRUCTURAL MUST cn MAY ( serverHostName $ description $ l $ 
nsHostLocation $ nsHardwarePlatform $ nsOsVersion ) X-ORIGIN 'Netscape' )

The nshost objectclass allows the presence of serverhostname, description, l 
etc...
Now to find what description can contain:
ldapsearch -LLL -o ldif-wrap=no -b cn=schema -s base attributetypes | grep -i 
description
attributetypes: ( 2.5.4.13 NAME 'description'  EQUALITY caseIgnoreMatch SUBSTR 
caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 X-ORIGIN 'RFC 
4519' )

The SYNTAX part defines the type of data (the RFC 
4517
 defines 1.3.6.1.4.1.1466.115.121.1.15 as a DirectoryString).
With this knowledge, you can pick an attribute where you want to store 
information that can be used to group the hosts together, and create the 
matching rule using this attribute.

If you are curious about LDAP schema in general, you can read the RFC 
4519.
HTH,
flo



Any advice gladly received.

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
Fedora Code of Conduct: 
https:/