IPA CA allow CSR SAN names in external domains
by Steve Dainard
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
1 year
ipa-getkeytab: PrincipalName not found
by Harald Dunkel
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 years, 11 months
nfsidmap/nss_getpwnam fails to resolve users with IPA/NFSv4+krb5
by Robert Sturrock
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(a)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(a)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(a)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(a)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(a)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(a)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.
4 years
IPA server upgrade fails with KDC error
by Johannes Brandstetter
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 years, 4 months
using freeipa with an AWS elastic load balancer
by ridha.zorgui＠infor.com
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.
4 years, 5 months
Centos7.4: users not seeing password expired notifications
by Johan Vermeulen
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.
5 years, 2 months
Replacing externally signed CA long before expiry
by Steve Dainard
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
5 years, 2 months
worst nightmare come true: ipa service doesn't start anymore
by Harald Dunkel
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 years, 2 months
Failed to read service file. Hostname does not match any master server in LDAP
by pgb205
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.
5 years, 2 months
debian 8 freeipa-client
by Andrew Radygin
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.
5 years, 2 months
