December 2017 - FreeIPA-users - Fedora mailing-lists

IPA CA allow CSR SAN names in external domains
by Steve Dainard 14 Mar '22

14 Mar '22

Hello I have a RHEL7 IPA server installed as a subordinate CA. I'd like to be able to add SAN's for a different dns domain than exists in the IPA realm. The dns for 'otherdomain.com' is handled by active directory which my IPA server has a cross-forest trust with. ie: host: client1.ipadomain.com certificate: CN = client1.ipadomain.com, SAN = client1.ipadomain.com, servicename.otherdomain.com When I try to submit this CSR with 'ipa-getcert request' the IPA server denies with: "The service principal for subject alt name servicename.otherdomain.com in certificate request does not exist" It seems that the default CAACL enforces a profile named 'caIPAserviceCert', but I'm having some trouble determining what can be modified (or cloned and changed in a new profile) that would allow the CA to sign a CSR that contains *.ipadomain.com and *.otherdomain.com in the SAN. This is the only section in the profile that contains SAN: policyset.serverCertSet.12.constraint.class_id=noConstraintImpl policyset.serverCertSet.12.constraint.name=No Constraint policyset.serverCertSet.12.default.class_id=commonNameToSANDefaultImpl policyset.serverCertSet.12.default.name=Copy Common Name to Subject Alternative Name Thanks, Steve

3 3

ipa-getkeytab: PrincipalName not found
by Harald Dunkel 26 Apr '19

26 Apr '19

Hi folks, maybe I missed something, but shouldn't admin have sufficient privileges to run # ipa-client-install --hostname stretch1.vs.example.de --no-ssh --no-sshd --no-nisdomain --no-sudo --no-ntp --no-dns-sshfp # reboot : : # kinit admin # ipa-getkeytab -s ipa1.example.de -p HTTP/stretch1.vs.example.de -k /etc/apache2/apache2.keytab ? ipa-getkeytab failed with Failed to parse result: PrincipalName not found. I would have expected it to create the principal on the fly. "admin" was created at freeipa install time on the first server, AFAIR. It is member of the "admins" and "trust admins" groups. I am concerned that I corrupted something. Every helpful comment is highly appreciated. Harri

3 5

nfsidmap/nss_getpwnam fails to resolve users with IPA/NFSv4+krb5
by Robert Sturrock 12 Mar '19

12 Mar '19

Hi All. We have IPA setup in an AD trust to support our Linux fleet. I’m running into a problem trying to get Ubuntu (16.04) clients to resolve names/ids on an NFS-mounted filesystem from an NFS server using NFSv4/krb5. Files and directories show up as ‘nobody’ or an incorrect numerical ID when listed with ‘ls’. RHEL7 clients seem to working fine with a very similar configuration (as far as I can tell). The particulars are: - AD forest has domains ‘localdomain’ and ‘student.localdomain’ (my user identity is ‘user@localdomain’) - IPA domain is ‘ipa.localdomain’ - The NFS server (RHEL7) and clients (Ubu16.04, RHEL7) are both enrolled to IPA (with 'Domain=ipa.localdomain’ in /etc/idmapd.conf). I have mounted the NFS volume on the clients with a simple: mount -t nfs4 nfs-server.ipa.localdomain:/export /mnt Listing my directory as myself (‘rns@localdomain’) on the Ubuntu client, I see: $ ls -ld rns drwx------ 18 nobody 4294967294 4096 Oct 25 15:18 rns .. with these corresponding nfsidmap messages: Oct 25 16:49:42 ubuntu-16.04-client.sub.localdomain nfsidmap[6163]: key: 0x2c254c26 type: uid value: rns@localdomain@ipa.localdomain timeout 600 Oct 25 16:49:42 ubuntu-16.04-client.sub.localdomain nfsidmap[6163]: nfs4_name_to_uid: calling nsswitch->name_to_uid Oct 25 16:49:42 ubuntu-16.04-client.sub.localdomain nfsidmap[6163]: nss_getpwnam: name 'rns@localdomain@ipa.localdomain' domain 'ipa.localdomain': resulting localname '(null)' Oct 25 16:49:42 ubuntu-16.04-client.sub.localdomain nfsidmap[6163]: nss_getpwnam: name 'rns@localdomain@ipa.localdomain' does not map into domain 'ipa.localdomain' Oct 25 16:49:42 ubuntu-16.04-client.sub.localdomain nfsidmap[6163]: nfs4_name_to_uid: nsswitch->name_to_uid returned -22 Oct 25 16:49:42 ubuntu-16.04-client.sub.localdomain nfsidmap[6163]: nfs4_name_to_uid: final return value is -22 .. whereas on the RHEL7 client, I see: $ ls -ld rns drwx------. 18 rns@localdomain rns@localdomain 4096 Oct 25 15:18 rns Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30590]: key: 0xf113fd2 type: uid value: rns@localdomain@ipa.localdomain timeout 600 Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30590]: nfs4_name_to_uid: calling nsswitch->name_to_uid Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30590]: nss_getpwnam: name 'rns@localdomain@ipa.localdomain' domain 'ipa.localdomain': resulting localname 'rns@localdomain' Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30590]: nfs4_name_to_uid: nsswitch->name_to_uid returned 0 Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30590]: nfs4_name_to_uid: final return value is 0 Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30592]: key: 0x2125a5d2 type: gid value: rns@localdomain@ipa.localdomain timeout 600 Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30592]: nfs4_name_to_gid: calling nsswitch->name_to_gid Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30592]: nfs4_name_to_gid: nsswitch->name_to_gid returned 0 Oct 25 16:56:23 rhel-7-client.sub.localdomain nfsidmap[30592]: nfs4_name_to_gid: final return value is 0 Why does the Ubuntu client's nfsidmap think that my identity doesn’t map into ‘ipa.localdomain’ and therefore (presumably) returns the error code ‘-22’? (My identity resolves ok from the shell, using ‘id rns@localdomain’ and I can login and use local filesystems without issue). The idmapd.conf looks like this: [General] Verbosity = 4 Pipefs-Directory = /run/rpc_pipefs Domain = ipa.localdomain Local-Realms = LOCALDOMAIN, STUDENT.LOCALDOMAIN, IPA.LOCALDOMAIN [Mapping] Nobody-User = nobody Nobody-Group = nogroup [Translation] Method = nsswitch Any pointers appreciated! Regards, Robert.

3 5

IPA server upgrade fails with KDC error
by Johannes Brandstetter 23 Nov '18

23 Nov '18

Hi, I'm trying to upgrade FreeIPA through ipa-server-upgrade from 4.4 to 4.5. The command fails with an "ACIError: Insufficient access:" . I find in the kdc log that it complains about " Database module does not match KDC version - while initializing database for realm..." Does anybody know how to fix this? Some more info: $ cat /etc/redhat-release CentOS Linux release 7.4.1708 (Core) $ tail /var/log/krb5kdc.log krb5kdc: Server error - while fetching master key K/M for realm XXX krb5kdc: Database module does not match KDC version - while initializing database for realm XXX $ sudo less /var/log/ipaupgrade.log 2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2017-10-16T13:04:13Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2017-10-16T13:04:13Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2017-10-16T13:04:13Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2017-10-16T13:04:13Z DEBUG duration: 0 seconds 2017-10-16T13:04:13Z ERROR IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. 2017-10-16T13:04:14Z DEBUG File "/usr/lib/python2.7/site-packages/ipapython/admintool.py", line 172, in execute return_value = self.run() File "/usr/lib/python2.7/site-packages/ipaserver/install/ipa_server_upgrade.py", line 46, in run server.upgrade() File "/usr/lib/python2.7/site-packages/ipaserver/install/server/upgrade.py", line 1896, in upgrade data_upgrade.create_instance() File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 124, in create_instance runtime=90) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 504, in start_creation run_step(full_msg, method) File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 494, in run_step method() File "/usr/lib/python2.7/site-packages/ipaserver/install/upgradeinstance.py", line 96, in __start api.Backend.ldap2.connect() File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 66, in connect conn = self.create_connection(*args, **kw) File "/usr/lib/python2.7/site-packages/ipaserver/plugins/ldap2.py", line 190, in create_connection client_controls=clientctrls) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1111, in external_bind '', auth_tokens, server_controls, client_controls) File "/usr/lib64/python2.7/contextlib.py", line 35, in __exit__ self.gen.throw(type, value, traceback) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1007, in error_handler raise errors.ACIError(info=info) 2017-10-16T13:04:14Z DEBUG The ipa-server-upgrade command failed, exception: ACIError: Insufficient access: 2017-10-16T13:04:14Z ERROR Insufficient access: 2017-10-16T13:04:14Z ERROR The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information $ sudo less /var/log/yum.log Oct 16 05:36:02 Updated: ipa-common-4.5.0-21.el7.centos.1.2.noarch Oct 16 05:36:02 Updated: ipa-client-common-4.5.0-21.el7.centos.1.2.noarch Oct 16 05:36:25 Updated: libipa_hbac-1.15.2-50.el7_4.2.x86_64 Oct 16 05:36:53 Updated: python-libipa_hbac-1.15.2-50.el7_4.2.x86_64 Oct 16 05:36:55 Updated: python2-ipalib-4.5.0-21.el7.centos.1.2.noarch Oct 16 05:36:55 Updated: python2-ipaclient-4.5.0-21.el7.centos.1.2.noarch Oct 16 05:37:23 Updated: ipa-python-compat-4.5.0-21.el7.centos.1.2.noarch Oct 16 05:38:43 Updated: ipa-server-common-4.5.0-21.el7.centos.1.2.noarch Oct 16 05:38:44 Updated: python2-ipaserver-4.5.0-21.el7.centos.1.2.noarch Oct 16 05:38:44 Updated: sssd-ipa-1.15.2-50.el7_4.2.x86_64 Oct 16 05:39:01 Installed: ipa-client-4.5.0-21.el7.centos.1.2.x86_64 Oct 16 05:39:28 Updated: ipsilon-tools-ipa-2.0.2-5.el7.centos.noarch Oct 16 05:39:29 Updated: ipa-server-4.5.0-21.el7.centos.1.2.x86_64 Oct 16 05:40:48 Erased: ipa-admintools-4.4.0-14.el7.centos.7.noarch Oct 16 05:19:30 Updated: krb5-libs-1.15.1-8.el7.x86_64 Oct 16 05:19:30 Updated: krb5-workstation-1.15.1-8.el7.x86_64 Oct 16 05:19:31 Updated: krb5-server-1.15.1-8.el7.x86_64 Oct 16 05:19:31 Updated: krb5-pkinit-1.15.1-8.el7.x86_64 Oct 16 05:38:22 Updated: sssd-krb5-common-1.15.2-50.el7_4.2.x86_64 Oct 16 05:38:57 Updated: sssd-krb5-1.15.2-50.el7_4.2.x86_64 Cheers, Johannes

4 11

using freeipa with an AWS elastic load balancer
by ridha.zorgui＠infor.com 13 Oct '18

13 Oct '18

I set up a FreeIPA master and replica behind an elastic load balancer in AWS cloud. FreeIPA Clients will be contacting the replica and the master sever through the load balancer so the dns name used when configurting the clients is the ELB CNAME. The problem is when retreiving ldap data and during the authentication, the SSL handshake fails as the certificate sent back from the master or replica has a hostname different than the one used in the sssd ( the ELB CNAME). so the connection is terminated. There is a workaround which is the use reqcert=allow but this bring a security issue with a MITM attack. another solution i found is the use SAN. I was able to add the ELB DNS as a SAN in freeipa servers certificate. i made sure it is there by downloading the certificate and checking that the elb san exist but when testing it the same problem remain. Please help.

3 3

Centos7.4: users not seeing password expired notifications
by Johan Vermeulen 15 Jan '18

15 Jan '18

Hello All, We run some 200 Centos7/Mate laptops, since last year they authenticate against freeipa. Lightdm/Mate are installed using epel repo. On Centos7.3/Lightdm 1.10.6-4.el7 things were al right, when a password expired, users would get the passwd expired field, the "new password" field en warnings if the made a mistake. Since upgrading to Centos7.4/Lightdm 1.25.0-1.el7 things go terribly wrong. Users very often get no warning if a password expired, just an authentication failure. Or they get no message at all. If at that point you got to tty....and log in you do get the warnings on the command line. The log files /var/log/secure also give clear password expired messages, only the user sees nothing. This is a big problem because users cannot login and cannot work without interventions. Many thanks for any help. Greetings, J.

4 13

Replacing externally signed CA long before expiry
by Steve Dainard 11 Jan '18

11 Jan '18

Hello, Using freeipa 4.5. I've replaced an external root CA that had a very short key, and have gone through the process of resigning the ipa intermediate-CA. I've used ipa-cacert-manage to generate a new csr and have signed it with my new external CA. The cert was successfully imported. I also ran ipa-certupdate on 2 of 2 ipa servers and I can see the new CA listed on both ipa servers with 'certutil -L -d /etc/pki/pki-tomcat/alias' When I run 'ipa-getcert resubmit -n Server-Cert -d /etc/httpd/alias' on an ipa server the certificate is resubmitted, but its still being signed by the old ipa intermediate-CA. I also see in the web ui under Authentication -> Certificates -> Certificate Authorities that only one ca named 'ipa' exists, and I can see the Issuer DN is still the old root CA. How can I invalidate the old intermediate-CA so the new intermediate-CA is used to sign certs going forwards? Thanks, Steve

3 7

worst nightmare come true: ipa service doesn't start anymore
by Harald Dunkel 10 Jan '18

10 Jan '18

Hi folks, Platform: Centos 7.4, ipa 4.5.0-21 The ipa service cannot be started anymore. Error message: # systemctl status ipa * ipa.service - Identity, Policy, Audit Loaded: loaded (/usr/lib/systemd/system/ipa.service; enabled; vendor preset: disabled) Active: failed (Result: exit-code) since Wed 2017-12-06 14:45:53 CET; 12min ago Process: 307 ExecStart=/usr/sbin/ipactl start (code=exited, status=1/FAILURE) Main PID: 307 (code=exited, status=1/FAILURE) Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting Directory Service Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting krb5kdc Service Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting kadmin Service Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting httpd Service Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting ipa-custodia Service Dec 06 14:45:52 ipa1.aixigo.de ipactl[307]: Starting pki-tomcatd Service Dec 06 14:45:53 ipa1.aixigo.de systemd[1]: ipa.service: main process exited, code=exited, status=1/FAILURE Dec 06 14:45:53 ipa1.aixigo.de systemd[1]: Failed to start Identity, Policy, Audit. Dec 06 14:45:53 ipa1.aixigo.de systemd[1]: Unit ipa.service entered failed state. Dec 06 14:45:53 ipa1.aixigo.de systemd[1]: ipa.service failed. Apparently pki-tomcatd is to blame. See the attached logfiles. Every helpful comment is highly appreciated. Harri

5 24

Failed to read service file. Hostname does not match any master server in LDAP
by pgb205 05 Jan '18

05 Jan '18

Hello everyone. Periodically and seemingly at random our replicas crash with the above error. Dirsrv shows as stopped and restarting doesn't help.Someone suggested earlier that this is due to problems with topology plugin but I don't think that the cause as we are still ondomainlevel=0. I'm not sure if it's a problem with 389ds or with some other part of freeipa. The only other clue I can think of is that often we see inconsistenciesbetween replicas. IE a user that is supposed to be present everywhere goes missing on just one of the many replicas. I'm quite at a loss on how to troubleshoot this further. I hope that someone can assist. ipactl startStarting Directory ServiceFailed to read data from service file: Failed to get list of services to probe status!Configured hostname 'server.pop.domain.local' does not match any master server in LDAP:No master found because of error: no such entryShutting down cat errors[26/Dec/2017:21:15:56.234793153 +0000] SSL alert: Sending pin request to SVRCore. You may need to run systemd-tty-ask-password-agent to provide the password.[26/Dec/2017:21:15:56.236060353 +0000] SSL alert: Security Initialization: Enabling default cipher set.[26/Dec/2017:21:15:56.236362922 +0000] SSL alert: Configured NSS Ciphers[26/Dec/2017:21:15:56.236652729 +0000] SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384: enabled[26/Dec/2017:21:15:56.236921632 +0000] SSL alert: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA: enabled[26/Dec/2017:21:15:56.237114079 +0000] SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256: enabled[26/Dec/2017:21:15:56.237317678 +0000] SSL alert: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA: enabled[26/Dec/2017:21:15:56.237526365 +0000] SSL alert: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384: enabled[26/Dec/2017:21:15:56.237746660 +0000] SSL alert: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA: enabled[26/Dec/2017:21:15:56.237908539 +0000] SSL alert: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256: enabled[26/Dec/2017:21:15:56.238087338 +0000] SSL alert: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA: enabled[26/Dec/2017:21:15:56.238306056 +0000] SSL alert: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384: enabled[26/Dec/2017:21:15:56.238517868 +0000] SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA: enabled[26/Dec/2017:21:15:56.238724920 +0000] SSL alert: TLS_DHE_DSS_WITH_AES_256_CBC_SHA: enabled[26/Dec/2017:21:15:56.238889982 +0000] SSL alert: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256: enabled[26/Dec/2017:21:15:56.239048124 +0000] SSL alert: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256: enabled[26/Dec/2017:21:15:56.239233534 +0000] SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA: enabled[26/Dec/2017:21:15:56.239402097 +0000] SSL alert: TLS_DHE_DSS_WITH_AES_128_CBC_SHA: enabled[26/Dec/2017:21:15:56.239767245 +0000] SSL alert: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256: enabled[26/Dec/2017:21:15:56.239997083 +0000] SSL alert: TLS_RSA_WITH_AES_256_GCM_SHA384: enabled[26/Dec/2017:21:15:56.240177269 +0000] SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA: enabled[26/Dec/2017:21:15:56.240376177 +0000] SSL alert: TLS_RSA_WITH_AES_256_CBC_SHA256: enabled[26/Dec/2017:21:15:56.240585031 +0000] SSL alert: TLS_RSA_WITH_AES_128_GCM_SHA256: enabled[26/Dec/2017:21:15:56.240745192 +0000] SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA: enabled[26/Dec/2017:21:15:56.240897126 +0000] SSL alert: TLS_RSA_WITH_AES_128_CBC_SHA256: enabled[26/Dec/2017:21:15:56.241075071 +0000] SSL alert: TLS_AES_128_GCM_SHA256: enabled[26/Dec/2017:21:15:56.241245788 +0000] SSL alert: TLS_CHACHA20_POLY1305_SHA256: enabled[26/Dec/2017:21:15:56.241456256 +0000] SSL alert: TLS_AES_256_GCM_SHA384: enabled[26/Dec/2017:21:15:56.241617090 +0000] SSL alert: TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256: enabled[26/Dec/2017:21:15:56.241766851 +0000] SSL alert: TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256: enabled[26/Dec/2017:21:15:56.241947040 +0000] SSL alert: TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256: enabled[26/Dec/2017:21:15:56.249524586 +0000] SSL Initialization - Configured SSL version range: min: TLS1.0, max: TLS1.2[26/Dec/2017:21:15:56.249909319 +0000] 389-Directory/1.3.5.10 B2017.102.203 starting up[26/Dec/2017:21:15:56.261829771 +0000] default_mr_indexer_create: warning - plugin [caseIgnoreIA5Match] does not handle caseExactIA5Match[26/Dec/2017:21:15:56.269563770 +0000] WARNING: changelog: entry cache size 2097152 B is less than db size 149151744 B; We recommend to increase the entry cache size nsslapd-cachememsize.[26/Dec/2017:21:15:56.300878069 +0000] schema-compat-plugin - scheduled schema-compat-plugin tree scan in about 5 seconds after the server startup![26/Dec/2017:21:15:56.399266161 +0000] NSACLPlugin - The ACL target cn=automember rebuild membership,cn=tasks,cn=config does not exist[26/Dec/2017:21:15:56.406444789 +0000] dna-plugin - dna_parse_config_entry: Unable to locate shared configuration entry (cn=posix-ids,cn=dna,cn=ipa,cn=etc,dc=domain,dc=local)[26/Dec/2017:21:15:56.406758873 +0000] dna-plugin - dna_parse_config_entry: Invalid config entry [cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config] skipped[26/Dec/2017:21:15:56.423696836 +0000] schema-compat-plugin - schema-compat-plugin tree scan will start in about 5 seconds![26/Dec/2017:21:15:56.434117007 +0000] slapd started. Listening on All Interfaces port 389 for LDAP requests[26/Dec/2017:21:15:56.434370916 +0000] Listening on All Interfaces port 636 for LDAPS requests[26/Dec/2017:21:15:56.434602326 +0000] Listening on /var/run/slapd-domain-local.socket for LDAPI requests[26/Dec/2017:21:15:56.517403933 +0000] slapd shutting down - signaling operation threads - op stack size 1 max work q size 1 max work q stack size 1[26/Dec/2017:21:15:56.517944438 +0000] slapd shutting down - waiting for 28 threads to terminate[26/Dec/2017:21:15:56.518216669 +0000] slapd shutting down - closing down local subsystems and plugins[26/Dec/2017:21:16:01.429082375 +0000] Waiting for 4 database threads to stop[26/Dec/2017:21:16:02.283796028 +0000] All database threads now stopped[26/Dec/2017:21:16:02.302693986 +0000] slapd shutting down - freed 1 work q stack objects - freed 1 op stack objects[26/Dec/2017:21:16:02.439672563 +0000] slapd stopped.

2 7

debian 8 freeipa-client
by Andrew Radygin 04 Jan '18

04 Jan '18

Hello! I have freeipa server 4.5 on Centos 7. And want to enroll host on Debian 8 to domain. I've found freeipa-client 4.4 in the sid repo, installing of it was almost successful... apt-get cannot complete configuring for certmonger, and I've got following error: ====== # journalctl -u certmonger -- Logs begin at Thu 2017-07-20 18:27:15 MSK, end at Thu 2017-12-21 15:39:01 MSK. -- Dec 21 13:25:36 HOSTNAME systemd[1]: Starting Certificate monitoring and PKI enrollment... Dec 21 13:25:36 HOSTNAME certmonger[18411]: 2017-12-21 13:25:36 [18411] Unable to set well-known bus name "org.fedorahosted.certmonger": Connection ":1.4" is not allowed to own the service "org.fedora Dec 21 13:25:36 HOSTNAME certmonger[18411]: Error connecting to D-Bus. Dec 21 13:25:36 HOSTNAME systemd[1]: certmonger.service: main process exited, code=exited, status=1/FAILURE Dec 21 13:25:36 HOSTNAME systemd[1]: Failed to start Certificate monitoring and PKI enrollment. Dec 21 13:25:36 HOSTNAME systemd[1]: Unit certmonger.service entered failed state. ======== Does anyone know how to deal with it? Thanks! -- Best regards, Andrew.

4 6

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users December 2017