January 2019 - FreeIPA-users - Fedora Mailing-Lists

by Uzor Ide

Hello All, I upgraded our ipa server and after the upgrade ipa won't start again. further investigation shows that components of ipa starts but pki-tomcatd(a)pki-tomcat.service appears to be where the issue lies. checking the logs suggested that issue lies in the certificate database. on checking the directory /etc/pki/pki-tomcat/alias with certutils [namead@ipasvr01 alias]$ sudo certutil -K -d . -f pwdfile.txt certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key and Certificate Services" < 0> rsa 9bb20dbec9d8dd63e1db53b0662eaf37a1518bf9 ocspSigningCert cert-pki-ca < 1> rsa 49d9f7a5f5ab3ed93d4037676b1bf9e236b89d0f subsystemCert cert-pki-ca < 2> rsa df374a636d9a424aaefefc6367dcb868f82f536d Server-Cert cert-pki-ca *< 3> rsa 7cebd0bbadddd5e581c328a99982e0ef5172d61f (orphan)* < 4> rsa 52839be82200bb2a9ff2034629c53cd90a0575a8 auditSigningCert cert-pki-ca < 5> rsa c4a6d42c22a874a69231a2d7446bccfe9ce0cbaa caSigningCert cert-pki-ca Any help in the deleting the key would be appreciated. Thanks _Uz

12 hours, 37 minutes

3
7
0 / 0

Abstracted NTP server configuration

by Rob Crittenden

A PR to support multiple NTP servers was submitted in https://github.com/freeipa/freeipa/pull/2169 This spawned a design at https://www.freeipa.org/page/V4/NTP_Servers_Configuration We need to discuss the design. rob

1 day, 4 hours

5
15
0 / 0

Login WebUI fails

by 74cmonty

Hi, starting today I cannot login to WebUI anymore. This is not a password authentication issue because I can switch to user "admin" in console. When I enter 'kinit list' as root I get this response: kinit: general error (see e-text) for Initial credentials will be fetched. The same error is shown for 'kinit admin'. How can I fix this issue? THX

1 day, 13 hours

2
6
0 / 0

ipa services continue to fail

by Andrew Meyer

Currently in my environment I have 6 servers 2 in my local office and 2 in each region in AWS. The AWS servers are all running CentOS 7.x with FreeIPA 4.5.x running on all 6. The AWS servers are all t2.medium w/ unlimited turned on. Occasionally we issues with all 6 where one of the processes for freeipa stops working completely. This could be the ipa.service or the named-pkcs11, or dirsrv(a)MYREALM.ORG. Sometimes it will be resource constraints, other times the whole system could come to a crawl for no reason whatsoever. Looking through the IPA logs doesn't always tell me what was going on. I usually have to restart the service or reboot the whole instance/machine to get it back to a working state. Also as of right now i'm seeing that dirsrv(a)MYREALM.NET will not start because a configured resource limit was exceeded. Here is the error i'm getting all of a sudden: ● dirsrv(a)EXAMPLE.NET.service - 389 Directory Server EXAMPLE.NET. Loaded: loaded (/usr/lib/systemd/system/dirsrv@.service; enabled; vendor preset: disabled) Active: failed (Result: resources) Jan 14 19:55:21 freeipa01.west.example.net systemd[1]: Failed to load environment files: No such file or directoryJan 14 19:55:21 freeipa01.west.example.net systemd[1]: dirsrv(a)EXAMPLE.NET.service failed to run 'start-pre' task: No such file or directoryJan 14 19:55:21 freeipa01.west.example.net systemd[1]: Failed to start 389 Directory Server EXAMPLE.NET..Jan 14 19:55:21 freeipa01.west.example.net systemd[1]: Unit dirsrv(a)EXAMPLE.NET.service entered failed state.Jan 14 19:55:21 freeipa01.west.example.net systemd[1]: dirsrv(a)EXAMPLE.NET.service failed.Jan 14 19:55:21 freeipa01.west.example.net systemd[1]: Starting 389 Directory Server EXAMPLE.NET....[andrew.meyer@freeipa01 ~]$ Here is a snippet from the logs:/var/log/dirsrv/slapd-EXAMPLE-NET/errors [14/Jan/2019:19:51:42.631413149 +0000] - NOTICE - ldbm_back_start - found 3880412k physical memory[14/Jan/2019:19:51:42.632553293 +0000] - NOTICE - ldbm_back_start - found 3273584k available[14/Jan/2019:19:51:42.633584210 +0000] - NOTICE - ldbm_back_start - cache autosizing: db cache: 97010k[14/Jan/2019:19:51:42.634560420 +0000] - NOTICE - ldbm_back_start - cache autosizing: userRoot entry cache (3 total): 131072k[14/Jan/2019:19:51:42.636236633 +0000] - NOTICE - ldbm_back_start - cache autosizing: userRoot dn cache (3 total): 65536k[14/Jan/2019:19:51:42.639592221 +0000] - NOTICE - ldbm_back_start - cache autosizing: ipaca entry cache (3 total): 131072k[14/Jan/2019:19:51:42.641296133 +0000] - NOTICE - ldbm_back_start - cache autosizing: ipaca dn cache (3 total): 65536k[14/Jan/2019:19:51:42.643594212 +0000] - NOTICE - ldbm_back_start - cache autosizing: changelog entry cache (3 total): 131072k[14/Jan/2019:19:51:42.645241367 +0000] - NOTICE - ldbm_back_start - cache autosizing: changelog dn cache (3 total): 65536k[14/Jan/2019:19:51:42.646916994 +0000] - NOTICE - ldbm_back_start - total cache size: 683450613 B;[14/Jan/2019:19:51:42.650449731 +0000] - NOTICE - dblayer_start - Detected Disorderly Shutdown last time Directory Server was running, recovering database.[14/Jan/2019:19:51:49.346656922 +0000] - ERR - schema-compat-plugin - scheduled schema-compat-plugin tree scan in about 5 seconds after the server startup![14/Jan/2019:19:51:49.544963162 +0000] - ERR - NSACLPlugin - acl_parse - The ACL target cn=groups,cn=compat,dc=example,dc=net does not exist[14/Jan/2019:19:51:49.564630973 +0000] - ERR - NSACLPlugin - acl_parse - The ACL target cn=computers,cn=compat,dc=example,dc=net does not exist[14/Jan/2019:19:51:49.584635724 +0000] - ERR - NSACLPlugin - acl_parse - The ACL target cn=ng,cn=compat,dc=example,dc=net does not exist[14/Jan/2019:19:51:49.604545604 +0000] - ERR - NSACLPlugin - acl_parse - The ACL target ou=sudoers,dc=example,dc=net does not exist[14/Jan/2019:19:51:49.624542861 +0000] - ERR - NSACLPlugin - acl_parse - The ACL target cn=users,cn=compat,dc=example,dc=net does not exist[14/Jan/2019:19:51:49.684538158 +0000] - ERR - NSACLPlugin - acl_parse - The ACL target cn=ad,cn=etc,dc=example,dc=net does not exist[14/Jan/2019:19:51:49.825646593 +0000] - ERR - NSACLPlugin - acl_parse - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=net does not exist[14/Jan/2019:19:51:49.844539895 +0000] - ERR - NSACLPlugin - acl_parse - The ACL target cn=casigningcert cert-pki-ca,cn=ca_renewal,cn=ipa,cn=etc,dc=example,dc=net does not exist[14/Jan/2019:19:51:49.990796503 +0000] - ERR - NSACLPlugin - acl_parse - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist[14/Jan/2019:19:52:00.365183146 +0000] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUV - Rebuilding the replication changelog RUV, this may take several minutes...[14/Jan/2019:19:52:00.445692209 +0000] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUV - Rebuilding replication changelog RUV complete. Result 0 (Success)[14/Jan/2019:19:52:00.446842275 +0000] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUV - Rebuilding the replication changelog RUV, this may take several minutes...[14/Jan/2019:19:52:00.513081196 +0000] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUV - Rebuilding replication changelog RUV complete. Result 0 (Success)[14/Jan/2019:19:52:00.514432537 +0000] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUV - Rebuilding the replication changelog RUV, this may take several minutes...[14/Jan/2019:19:52:00.515614720 +0000] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUV - Rebuilding replication changelog RUV complete. Result 0 (Success)[14/Jan/2019:19:52:00.516689146 +0000] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUV - Rebuilding the replication changelog RUV, this may take several minutes...[14/Jan/2019:19:52:00.517810761 +0000] - NOTICE - NSMMReplicationPlugin - changelog program - _cl5ConstructRUV - Rebuilding replication changelog RUV complete. Result 0 (Success)[14/Jan/2019:19:52:00.526034848 +0000] - WARN - NSMMReplicationPlugin - replica_check_for_data_reload - Disorderly shutdown for replica o=ipaca. Check if DB RUV needs to be updated[14/Jan/2019:19:52:00.584599421 +0000] - ERR - set_krb5_creds - Could not get initial credentials for principal [ldap/freeipa01.west.example.net(a)EXAMPLE.NET] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm)[14/Jan/2019:19:52:00.604610301 +0000] - WARN - NSMMReplicationPlugin - replica_check_for_data_reload - Disorderly shutdown for replica dc=example,dc=net. Check if DB RUV needs to be updated[14/Jan/2019:19:52:00.624573161 +0000] - ERR - set_krb5_creds - Could not get initial credentials for principal [ldap/freeipa01.west.example.net(a)EXAMPLE.NET] in keytab [FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for requested realm)[14/Jan/2019:19:52:00.644588420 +0000] - NOTICE - NSMMReplicationPlugin - Force update of database RUV (from CL RUV) -> 5c3cdd700000001b0000[14/Jan/2019:19:52:00.675318674 +0000] - INFO - slapd_daemon - slapd started. Listening on All Interfaces port 389 for LDAP requests[14/Jan/2019:19:52:00.684551689 +0000] - INFO - slapd_daemon - Listening on All Interfaces port 636 for LDAPS requests[14/Jan/2019:19:52:00.704669406 +0000] - INFO - slapd_daemon - Listening on /var/run/slapd-EXAMPLE-NET.socket for LDAPI requests[14/Jan/2019:19:52:00.752022024 +0000] - ERR - schema-compat-plugin - schema-compat-plugin tree scan will start in about 5 seconds![14/Jan/2019:19:52:04.456691971 +0000] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meTofreeipa03.east.example.net" (freeipa03:389) - Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) ()[14/Jan/2019:19:52:05.055410972 +0000] - ERR - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meTofreeipa02.west.example.net" (freeipa02:389) - Replication bind with GSSAPI auth failed: LDAP error -1 (Can't contact LDAP server) ()[14/Jan/2019:19:52:06.180112049 +0000] - ERR - schema-compat-plugin - warning: no entries set up under cn=computers, cn=compat,dc=example,dc=net[14/Jan/2019:19:52:06.225167327 +0000] - ERR - schema-compat-plugin - Finished plugin initialization.[14/Jan/2019:19:52:09.118232562 +0000] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meTofreeipa02.west.example.net" (freeipa02:389): Replication bind with GSSAPI auth resumed[14/Jan/2019:19:52:09.417962320 +0000] - INFO - NSMMReplicationPlugin - bind_and_check_pwp - agmt="cn=meTofreeipa03.east.example.net" (freeipa03:389): Replication bind with GSSAPI auth resumed For the on premise freeipa servers I have upgraded the RAM/CPU to 4x4. However I wanted to reach out to the mailing list to find out what to do about the servers in AWS. Regards,

1 day, 15 hours

1
0
0 / 0

ManageIQ/Cloudforms integration

by Sigbjorn Lie-Soland

Hi list, Is there a known repository with an existing ManageIQ/Cloudforms Automate framework for FreeIPA? I am primarily looking for the ability to create HBAC and SUDO rules as part of the provisioning process. Thanks. Regards, Siggi

1 day, 16 hours

2
1
0 / 0

CentOS 7 ipa upgrade causes pki-tomcatd not to start CA

by Jason Wood

Upgraded from CentOS 7.5 to 7.6 which includes IPA upgrade.from 4.5.4-10 to 4.6.4-10 upgrade was done via yum upgrade Upgrade went fine. I see no alarming errors in the logs. It stopped and started all the servers did the ipa upgrade. All was fine once completed. Reboot and now pki-tomcatd CA will not start. Tomcat starts, gets all the way to were it should start the CA and doesn't. No errors, Debug doesn't show any blatant errors. It does have "Repository: Server not completely started. Returning .." which is the closest thing I see to an error. All the certs are in monitoring state. None are expired. Domain is not quite a year old. PKI is communicating to LDAP without issues. Validated that. Also checked for and replication errors. There are none. This is happening on all 4 systems. In the exact same way. DNS is up, we can authenticate, kerbrose is working. Can search LDAP via SSL and non-SSL Rebooted into the older kernel just to make sure. Reverted back to an old CS.cfg also, no different. I'm at a complete loss. Most other posts and pages about this all deal with expired certs. And the one that wasn't (from Redhat) was about replication conflicts. Nothing is panning out. Fully patched CentOS Linux release 7.6.1810 (Core) ipa-client-4.6.4-10.el7.centos.x86_64 ipa-client-common-4.6.4-10.el7.centos.noarch ipa-common-4.6.4-10.el7.centos.noarch ipa-server-4.6.4-10.el7.centos.x86_64 ipa-server-common-4.6.4-10.el7.centos.noarch ipa-server-dns-4.6.4-10.el7.centos.noarch libipa_hbac-1.16.2-13.el7.x86_64 python2-ipaclient-4.6.4-10.el7.centos.noarch python2-ipalib-4.6.4-10.el7.centos.noarch python2-ipaserver-4.6.4-10.el7.centos.noarch python-iniparse-0.4-9.el7.noarch python-libipa_hbac-1.16.2-13.el7.x86_64 sssd-ipa-1.16.2-13.el7.x86_64 krb5-pkinit-1.15.1-34.el7.x86_64 pki-base-10.5.9-6.el7.noarch pki-base-java-10.5.9-6.el7.noarch pki-ca-10.5.9-6.el7.noarch pki-kra-10.5.9-6.el7.noarch pki-server-10.5.9-6.el7.noarch pki-tools-10.5.9-6.el7.x86_64

1 day, 17 hours

6
16
0 / 0

Peer certificate cannot be authenticated with given CA certificates

by Petr Benas

Hello, we have an issue with resubmitting several certificates. We suspect the reason might be the encoding mismatch between the certificate and the CA certificate. Our environment was upgraded during the years from some 3.x version to current 4.5.4. So the very first CA certificate was encoded in PRINTABLESTRING. Issuer: organizationName = PRINTABLESTRING:EXAMPLE.COM commonName = PRINTABLESTRING:Certificate Authority Validity Not Before: Dec 1 14:14:37 2014 GMT Not After : Dec 1 14:14:37 2034 GMT Subject: organizationName = PRINTABLESTRING:EXAMPLE.COM commonName = PRINTABLESTRING:Certificate Authority When we renew-ed (due to SHA1) we got to PRINTABLESTRING X UTF8STRING and after we renewed again, so now we have: Issuer: organizationName = UTF8STRING:EXAMPLE.COM commonName = UTF8STRING:Certificate Authority Validity Not Before: Oct 9 07:34:24 2017 GMT Not After : Oct 9 07:34:24 2037 GMT Subject: organizationName = UTF8STRING:EXAMPLE.COM commonName = UTF8STRING:Certificate Authority And most certificated were renewed fine. However, recently we noticed that several certificated can't be resubmitted, all of them seem to be like this: Issuer: organizationName = PRINTABLESTRING:EXAMPLE.COM commonName = PRINTABLESTRING:Certificate Authority Validity Not Before: Nov 24 12:17:12 2016 GMT Not After : Nov 14 12:17:12 2018 GMT Subject: organizationName = UTF8STRING:EXAMPLE.COM commonName = UTF8STRING:ipa07.example.com The error when resubmitting is: Peer certificate cannot be authenticated with given CA certificates. The tcpdump from 8443 says Unknown CA. Is the assumption that the encoding mismatch is blocking the submitting certificate correct? One of the certificate which we also can't renew is the 'IPA RA' (/var/lib/ipa/ra-agent.pem) What we tried: Add all versions of CA certificate to /etc/pki/pki-tomcat/alias trust store (also add them one-by-one) Setting date back before the expiration. Advises from: https://rcritten.wordpress.com/2017/09/20/peer-certificate-cannot-be-auth... Deleting the related CSR from o=ipaca, supposing that newly generated csr will be fine. Any suggestions what else we could try? Thanks Petr

2 days, 3 hours

2
2
0 / 0

Ldap authentication

by Alex Severov

Hello. I have ipa with ad integration. I want to install nextcloud with ldap authentication. I used this document https://www.freeipa.org/page/Owncloud_Authentication_against_FreeIPA I changed ldap tree to compat. But I can't login in nextcloud with ad user password! Wat's wrong? -- Alex Severov

2 days, 9 hours

1
0
0 / 0

CA master reinstall via replication

by Rob Foehl

If I have a pair of IPA servers and need to reinstall the one currently holding the CA master, is it actually necessary to promote the other one, or can I just follow the procedure to rebuild the current master via replication and then verify its CA configuration[1] after the fact? Thanks, -Rob [1] Specifically, everything mentioned in https://www.freeipa.org/page/Howto/Promote_CA_to_Renewal_and_CRL_Master

2 days, 14 hours

2
4
0 / 0

FreeIPA for the maximally paranoid and overworked?

by K. M. Peterson

Hi all, This is a newbie question with respect to FreeIPA, and I haven't seen this elsewhere, so I thought I'd ask. I've just cleaned up an issue with trying to implement a new replica on our domain, and I've realized that there are a couple of areas I don't understand that are causing more stress than I need at this point, for I am maximally paranoid and overworked, and I need some advice on how not to make that worse when implementing FreeIPA. I've been reading this list on and off for most of the last year, and what's struck me is how complicated this project is, especially of course areas where I personally have less expertise (e.g., LDAP, Kerberos). Implementing and managing this is just one of my jobs, and our IdM becomes more critical as time goes on, so I need to understand a few things. Question 1: As I just had, for the first time, to manually modify LDAP to remove data, I'd like to understand how taking that approach can backfire. In other words, it's clear this isn't habitually a good idea, because mistakes will replicate, for example. But, where are the real danger points: for example, I've seen stories of having to recover a server in an environment where the time was intentionally set back to allow an operation on an expired cert. As with a database update that triggers other (unexpected) changes, are there LDAP operations that can't practically be "un-done"? I know that deleting records is permanent (obvious), but are there gotchas like changing a particular object fires some large number of events that there's no way to revert? Or, in colloquial terms, are there places that are really, really bad to try to outwit the management interfaces? I'm not talking everyday updates, but instances where we get stuck (as I was yesterday and today)? Question 2: How to stay safe. Our installation on a small network as a pair of masters replicating with each other, CA and DNS installed on both. They are VMs allocated on separate physical hosts. Before updates, I snapshot both for recovery purposes. I update one at a time, now, and ensure that they're functional before doing the other one (I know that schema changes will propagate before service is applied elsewhere, but I can't do anything else about that). I haven't had to deal with the question of how to make sure my (self-signed) CA certificate doesn't expire, but I know when it will and am leaving myself ample time to understand that. I'm about to start pushing out this functionality to multiple geos, again at small-ish scale, and I'm reading the topology references to be sure I understand what I'm doing. But: what am I missing? I get the impression that trying to (conventionally) "back up" data isn't useful. I've tried to design the network to make it as simple as possible to meet our needs. Does anyone else have anything to add in the sense of "best practices", or to echo my first question "there be dragons <here>"? I've learned a lot from this list, and I'd also like to add a thank you to everyone here who have helped with that! I do see this getting better and better, and it's appreciated.

2 days, 18 hours

3
4
0 / 0