CA install on replica fails - Clone URI does not match...
by Ross Infinger
I'm installing the CA service on an existing replica with command ipa-ca-install. It fails with this error in the log:
Installation failed:
com.netscape.certsrv.base.BadRequestException: Clone URI does not match available subsystems: https://pci-mgmt-ipa01.pci.xxxxxx.com:443
Version of both ca master and replica is 4.5.0 api version 2.228
domain level is 1
ipareplica-ca-install.log attached.
How can I further troubleshoot this?
Thanks,
Ross
5 years, 11 months
ipa replication issues
by Sandor Juhasz
Hello,
we are using freeipa in a 4way multi master replication setup.
Servers ipa14,ipa15 and ipa34,ipa35 on
CentOS Linux release 7.3.1611 (Core) with version
ipa-server-common-4.4.0-14.el7.centos.7.noarch.
We have an issue where one of the servers log a missing CSN. It happens
even after
ipa replication reinitialized.
We are guessing that CSN 5a0a27d9000000060000 only exists on ipa35, but we
see it in those files listed on ipa15 and the error is reported there.
Please see attached file with logs.
How can we fix this?
--
*Sándor Juhász*
System Administrator
*ChemAxon* *Ltd*.
Building Hx, GraphiSoft Park, Záhony utca 7, Budapest, Hungary, H-1031
Cell: +36704258964
5 years, 11 months
Host is enrolled and installed
by Lachlan Musicman
Not 100% sure where to send this. Am trying to write an Ansible playbook to
install SSSD and enroll the host in a domain.
The problem starts when the host exists in the domain and ipa-client is
already installed.
We can use Ansible's delegate module to remove host from domain enrollment
(would be more ideal to test if it's enrolled, then unenroll if test
returns true). And we can use ipa-client-install --uninstall to if
ipa-client is already configured. But neither of these commands provide
easy answers quickly.
ipa host-find {{ host }} | grep matched | cut -d " " -f 1
will turn ipa host-find into something usable. A switch that just returned
the number matched would be ideal, but it's workable currently.
More interestingly, once a host is unenrolled from the domain (ie, ipa
host-del <host> runs successfully on the IPA server), it doesn't, and
probably shouldn't, uninstall ipa-client on the host itself.
But there doesn't seem to be any way to check ipa-client
--install/--uninstall for it's opposite.
IE, if ipa-client is installed, and is run again, one is urged to uninstall
first:
IPA client is already configured on this system.
If you want to reinstall the IPA client, uninstall it first using
'ipa-client-install --uninstall'.
The ipa-client-install command failed. See /var/log/ipaclient-install.log
for more information
if ipa-client is not installed, and you run
ipa-client --uninstall
The message returned is:
IPA client is not configured on this system.
The ipa-client-install command failed. See /var/log/ipaclient-uninstall.log
for more information
Have I missed a true/false return value cli arg for ipa-client-install?
ipa-client-install --exists
ipa-client-install --configured
or something like that?
Am I making hard work of something that is relatively straight forward and
solved elsewhere but I've missed?
Ansible has "ignore_errors: True" available, but I feel that is a weak get
out of jail free card. Given that this is authentication and authorization,
errors shouldn't be ignored (opinion).
cheers
L.
------
"The antidote to apocalypticism is *apocalyptic civics*. Apocalyptic civics
is the insistence that we cannot ignore the truth, nor should we panic
about it. It is a shared consciousness that our institutions have failed
and our ecosystem is collapsing, yet we are still here — and we are
creative agents who can shape our destinies. Apocalyptic civics is the
conviction that the only way out is through, and the only way through is
together. "
*Greg Bloom* @greggish
https://twitter.com/greggish/status/873177525903609857
5 years, 11 months
Potentially Corrupted Tomcat PKI database, recovery steps?
by Brian Weaver
After a recent power outage the IPA master server I built a few years ago
is having some issues. I've done as much troubleshooting as I can and I
think I've tracked down the issue to the certificate database in
'/etc/pki/pki-tomcat/alias'. I can use 'certutil' to view a list of
certificates. I can also view the key ID of the keys, when no nickname is
used to specify a specific key. When I try to look at a specific key it
fails.
[root@ipa-server0 alias]# certutil -d $PWD -L
Certificate Nickname Trust
Attributes
SSL,S/MIME,JAR/XPI
caSigningCert cert-pki-ca CTu,Cu,Cu
subsystemCert cert-pki-ca u,u,u
Server-Cert cert-pki-ca u,u,u
auditSigningCert cert-pki-ca u,u,Pu
ocspSigningCert cert-pki-ca u,u,u
[root@ipa-server0 alias]# certutil -d $PWD -K -f /tmp/xxx
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key
and Certificate Services"
< 0> rsa ab76588f20ba1e9d5f4dc4fe6f62dc70dc96484f NSS Certificate
DB:auditSigningCert cert-pki-ca
< 1> rsa ad2699ef775d3d685d08e6c34b64a02295d6bcef caSigningCert
cert-pki-ca
< 2> rsa a96b674224d50615416ef25644441887b410db3f (orphan)
< 3> rsa 38b6a1d6d1be0dc2f80a2330cf52c73abd22d10d NSS Certificate
DB:ocspSigningCert cert-pki-ca
< 4> rsa 2beb83b689255e03be47430e204d34067fd873f8 NSS Certificate
DB:Server-Cert cert-pki-ca
< 5> rsa 0d733da9de0045c502dbb9f20ea8d4ba426afb47 NSS Certificate
DB:subsystemCert cert-pki-ca
[root@ipa-server0 alias]# for i in $(certutil -d $PWD -L | grep cert-pki |
awk '{print $1}') ; do certutil -d $PWD -K -f /tmp/xxx -n "$i cert-pki-ca"
; done
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key
and Certificate Services"
< 0> rsa ad2699ef775d3d685d08e6c34b64a02295d6bcef caSigningCert
cert-pki-ca
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key
and Certificate Services"
certutil: problem listing keys: SEC_ERROR_UNRECOGNIZED_OID: Unrecognized
Object Identifier.
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key
and Certificate Services"
certutil: problem listing keys: SEC_ERROR_UNRECOGNIZED_OID: Unrecognized
Object Identifier.
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key
and Certificate Services"
certutil: problem listing keys: SEC_ERROR_UNRECOGNIZED_OID: Unrecognized
Object Identifier.
certutil: Checking token "NSS Certificate DB" in slot "NSS User Private Key
and Certificate Services"
certutil: problem listing keys: SEC_ERROR_UNRECOGNIZED_OID: Unrecognized
Object Identifier.
Does anyone have any suggestions on how to recover from this particular
error. It would seem that some of the certificates were recently
regenerated by certmonger based on these lines from the logging
Mar 30 07:26:30 ipa-server0.ipa.sunbirddcim.com certmonger[19770]:
Certificate named "ocspSigningCert cert-pki-ca" in token "NSS Certificate
DB" in database "/etc/pki/pki-tomcat/alias" will no
Mar 30 07:26:30 ipa-server0.ipa.sunbirddcim.com certmonger[19769]:
Certificate named "auditSigningCert cert-pki-ca" in token "NSS Certificate
DB" in database "/etc/pki/pki-tomcat/alias" will n
Mar 30 07:26:30 ipa-server0.ipa.sunbirddcim.com certmonger[19772]:
Certificate named "ipaCert" in token "NSS Certificate DB" in database
"/etc/httpd/alias" will not be valid after 201804261702
Mar 30 07:26:30 ipa-server0.ipa.sunbirddcim.com certmonger[19773]:
Certificate named "Server-Cert cert-pki-ca" in token "NSS Certificate DB"
in database "/etc/pki/pki-tomcat/alias" will not be
Mar 30 07:28:57 ipa-server0.ipa.sunbirddcim.com certmonger[20025]:
Certificate named "ipaCert" in token "NSS Certificate DB" in database
"/etc/httpd/alias" issued by CA and saved.
Mar 30 07:29:48 ipa-server0.ipa.sunbirddcim.com certmonger[20102]:
Certificate named "auditSigningCert cert-pki-ca" in token "NSS Certificate
DB" in database "/etc/pki/pki-tomcat/alias" issued
Mar 30 07:30:03 ipa-server0.ipa.sunbirddcim.com certmonger[20125]:
Certificate named "ocspSigningCert cert-pki-ca" in token "NSS Certificate
DB" in database "/etc/pki/pki-tomcat/alias" issued
Mar 30 07:30:20 ipa-server0.ipa.sunbirddcim.com certmonger[20148]:
Certificate named "subsystemCert cert-pki-ca" in token "NSS Certificate DB"
in database "/etc/pki/pki-tomcat/alias" issued by
Apr 10 07:26:31 ipa-server0.ipa.sunbirddcim.com certmonger[23627]:
Certificate named "Server-Cert" in token "NSS Certificate DB" in database
"/etc/dirsrv/slapd-IPA-SUNBIRDDCIM-COM" will not be
Apr 10 07:27:23 ipa-server0.ipa.sunbirddcim.com certmonger[23724]:
Certificate named "Server-Cert" in token "NSS Certificate DB" in database
"/etc/httpd/alias" issued by CA and saved.
Apr 10 07:27:40 ipa-server0.ipa.sunbirddcim.com certmonger[23783]:
Certificate named "Server-Cert" in token "NSS Certificate DB" in database
"/etc/dirsrv/slapd-IPA-SUNBIRDDCIM-COM" issued by C
I going to continue to try to muddle my way through it. I'm hoping someone
with more knowledge than myself can help me find the correct path.
The result of `ipa --version` is VERSION: 4.3.1, API_VERSION: 2.164. The
system is running Fedora 23 and FreeIPA came from a COPR release
name=Copr repo for freeipa-4-3 owned by @freeipa
baseurl=
https://copr-be.cloud.fedoraproject.org/results/@freeipa/freeipa-4-3/fedo...
Any help would be greatly appreciated.
--
/* insert witty comment here */
5 years, 12 months
clients-per-query
by Andrew Meyer
So in my logs on I am getting the following:
- 23-Apr-2018 01:25:20.041 clients-per-query decreased to 14
I have not seen this on any other DNS server I have come across. IS this normal fro FreeIPA? Can the limits be increased by default?
6 years
HBAC and Kerberos.
by Ildefonso Camargo
Hello,
At this point I am mostly looking for confirmation/denial of the following
observed behavior:
FreeIPA Kerberos will issue service tickets to a user with a valid TGT
regardless of access control rules (HBAC).
Procedure to observe:
1. Create a test user.
2. Allow that user to login to one host, and just one (via ssh or so), HBAC
is used.
3. Check that the user has a TGT (klist),or issue kinit as needed.
4. Try to ssh (or connect to any other Kerberos service) to any other
server, you will probably get access denied (PAM-based services) because of
HBAC, or even allowed (Kerberos-based services that do not use PAM).
5. Get that ticket list again: you got service ticket for every single
host, even the ones to which you do not have access.
This is causing me great grieving ( :( ), because I was hoping to control
authorization to a Kerberos service using FreeIPA, it turns out it just
allows everyone in and now I have to add authorization at the service
level, which could eventually use PAM, but... come on, why doesn't FreeIPA
inspect access policies before issuing the ticket? (unless it does and I am
missing something?)
So... can you confirm if what I found is the way it is supposed to work in
its current state? (version 4.5.0)
Thanks!
Ildefonso
6 years
Any non-root user (ipa) can su / su - to root, when the su/su-i service(s) are not enabled
by Morgan Cox
Hi.
I have a test freeipa server setup.
It is generally working fine, however I have found one major issue.
Even though a user only has 1 service enabled 'sshd' that user can su / su-
to root.
I can confirm I have deleted the allow_all HBAC rule, and can confirm
generally rules are working.
i.e if I remove sshd from allowed services the user cannot login.
Using ipa hbactest - sshd is granted, su is not
Also I have tested the user cannot su / su - [non-root-user]
------------------
[mcox@ipaclient2 ~]$ su - mcox2
Password:
su: Permission denied
------------------
but they can su - (to root).
When I su I see in /var/log/secure
----------------
Apr 26 17:26:28 ipaclient2 su: pam_unix(su:session): session opened for
user root by mcox2(uid=1374400008)
----------------
Looking at the logs in /var/log/sssd when I su only the sssd_nss.log seems
to grow
debug_log = 9 is enabled
--------------------------
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [get_client_cred] (0x4000): Client
creds: euid[0] egid[1374400008] pid[1759].
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [setup_client_idle_timer] (0x4000):
Idle timer re-set for client [0x55937ee13a10][21]
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [accept_fd_handler] (0x0400): Client
connected!
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [sss_cmd_get_version] (0x0200):
Received client version [1].
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [sss_cmd_get_version] (0x0200):
Offered version [1].
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [nss_getby_name] (0x0400): Input
name: root
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [cache_req_set_plugin] (0x2000): CR
#52: Setting "Initgroups by name" plugin
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [cache_req_send] (0x0400): CR #52:
New request 'Initgroups by name'
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [cache_req_process_input] (0x0400):
CR #52: Parsing input name [root]
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [sss_parse_name_for_domains]
(0x0200): name 'root' matched without domain, user is root
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [cache_req_set_name] (0x0400): CR
#52: Setting name [root]
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [cache_req_select_domains] (0x0400):
CR #52: Performing a multi-domain search
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [cache_req_search_domains] (0x0400):
CR #52: Search will check the cache and check the data provider
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [cache_req_validate_domain_type]
(0x2000): Request type POSIX-only for domain cpgbpc.local type POSIX is
valid
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [cache_req_set_domain] (0x0400): CR
#52: Using domain [cpgbpc.local]
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [cache_req_prepare_domain_data]
(0x0400): CR #52: Preparing input data for domain [cpgbpc.local] rules
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [cache_req_search_send] (0x0400): CR
#52: Looking up root(a)cpgbpc.local
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #52: Checking negative cache for [root(a)cpgbpc.local]
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [sss_ncache_check_str] (0x2000):
Checking negative cache for [NCE/USER/cpgbpc.local/root(a)cpgbpc.local]
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [cache_req_search_ncache] (0x0400):
CR #52: [root(a)cpgbpc.local] does not exist (negative cache)
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [cache_req_process_result] (0x0400):
CR #52: Finished: Not found
(Thu Apr 26 17:27:52 2018) [sssd[nss]] [nss_protocol_done] (0x4000):
Sending reply: not found
(Thu Apr 26 17:27:54 2018) [sssd[nss]] [client_idle_handler] (0x2000):
Terminating idle client [0x55937ee0faf0][22]
(Thu Apr 26 17:27:54 2018) [sssd[nss]] [client_close_fn] (0x2000):
Terminated client [0x55937ee0faf0][22]
(Thu Apr 26 17:27:54 2018) [sssd[nss]] [client_idle_handler] (0x2000):
Terminating idle client [0x55937ee12d80][23]
(Thu Apr 26 17:27:54 2018) [sssd[nss]] [client_close_fn] (0x2000):
Terminated client [0x55937ee12d80][23]
--------------------------
Can anyone help me prevent a user being able to su / su - to root ?
If it helps my /etc/pam.d/system-auth config is here :
https://pastebin.com/J3THY44c
Regards
6 years
replica - install fails with CA issue
by Ross Infinger
Thanks for the reply. I tried the workaround but still getting the CA_UNREACHABLE error. The umask on the master was already at 0022.
Is there a way to check the health of the CA master? Maybe the issue is with the CA and not with the replica install?
Here is a little more information. The CA master is pci-mgmt-ipa01. the new client to be promoted is ipa-nyc-pci02.
On the client:
[root@ipa-nyc-pci02 ~]# getcert list
Number of certificates and requests being tracked: 1.
Request ID '20180424223129':
status: CA_UNREACHABLE
ca-error: Server at https://ipa-nyc-pci02.pci.xxxxxxx.com/ipa/xml failed request, will retry: -504 (libcurl failed to execute the HTTP POST transaction, explaining: Failed connect to ipa-nyc-pci02.pci.xxxxxxx.com:443; Connection refused).
stuck: no
key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-PCI-xxxxxxx-COM',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-PCI-xxxxxxx-COM/pwdfile.txt'
certificate: type=NSSDB,location='/etc/dirsrv/slapd-PCI-xxxxxxx-COM',nickname='Server-Cert'
CA: IPA
issuer:
subject:
expires: unknown
pre-save command:
post-save command: /usr/libexec/ipa/certmonger/restart_dirsrv PCI-xxxxxxx-COM
track: yes
auto-renew: yes
On the master:
pki-tomcat is running.
I see a cert_request in /var/log/httpd/error_log.
[Tue Apr 24 22:31:31.490598 2018] [:error] [pid 1133] ipa: INFO: [xmlserver] host/ipa-nyc-pci02.pci.XXXXXXX.com(a)PCI.XXXXXXX.COM: cert_request(u'MIID8jCCAtoCAQAwQjEYMBYGA1UEChMPUENJLk1BU0NPUlAuQ09NMSYwJAYDVQQDEx1pc
...
/QLxsLD7VWO7fGuSHpGnUayuTKi1Em9BdPtMNoD75G4SJ', profile_id=u'caIPAserviceCert', principal=u'ldap/ipa-nyc-pci02.pci.XXXXXXX.com(a)PCI.XXXXXXX.COM', add=True, version=u'2.51'): NotFound
I don't see any request in /var/log/pki/pki-tomcat/ca/debug.
Does this indicate a problem with the Dogtag server?
Thanks,
Ross
_______________________________________
From: Ross Infinger
Sent: Tuesday, April 24, 2018 1:39 PM
To: Florence Blanc-Renaud
Subject: RE: [Freeipa-users] replica - install fails with CA issue
Thanks for the reply. I tried the workaround but still getting the CA_UNREACHABLE error. The umask on the master was already at 0022.
Is there a way to check the health of the CA master? Maybe the issue is with the CA and not with the replica install?
Thanks,
Ross
From: Florence Blanc-Renaud [flo(a)redhat.com]
Sent: Tuesday, April 24, 2018 1:37 AM
To: FreeIPA users list
Cc: Ross Infinger
Subject: Re: [Freeipa-users] replica - install fails with CA issue
On 04/23/2018 10:37 PM, Ross Infinger via FreeIPA-users wrote:
> I'm trying to promote a new client to a replica. I install the client
> first then run ipa-replica-install. The client install goes OK but the
> ipa-replica-install command fails with
>
> RuntimeError: Certificate issuance failed (CA_UNREACHABLE)
>
> Seems the client was able to reach the CA so I'm puzzled why the replica
> cannot.
>
>
>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org
>
Hi,
other users also hit this issue #7193 [1], and the root cause was that
the root's umask on the master was too restrictive. Can you check if
it's your case?
The workaround is to do:
chmod 644 /etc/ipa/ca.crt
chmod 440 /var/lib/ipa/ra-agent.{key|pem}
but the best is to install the master with umask 022.
HTH,
Flo
[1] https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_freeipa_is...
6 years
read only replicants
by Angus Clarke
Hi
Is there way to lock down a FreeIPA replica so that it can only receive
updates but not make changes to other FreeIPA systems.
Some of our environments are considered less secure than others, our
security team are concerned that a FreeIPA in a less secure environment
might become compromised at which point unwarranted changes could be
applied that affect our secure production environments.
Thanks a lot
Angus
6 years
GUI login fails on CA after failed replica install
by Ross Infinger
I get this error when trying to login to the freeipa gui on the CA master.
"Login failed due to an unknow reason"
This started after an attempt to create a new replica failed on another machine.
freeipa version: VERSION: 4.5.0, API_VERSION: 2.228
Snippet from /var/log/httpd/error_log
...
[Wed Apr 25 21:47:43.846406 2018] [:error] [pid 29271] ipa: DEBUG: stderr=kinit: Pre-authentication failed: Cannot read password while getting initial credentials
[Wed Apr 25 21:47:43.846412 2018] [:error] [pid 29271]
[Wed Apr 25 21:47:43.846544 2018] [:error] [pid 29271] [remote 192.168.145.30:188] mod_wsgi (pid=29271): Exception occurred processing WSGI script '/usr/share/ipa/wsgi.py'.
[Wed Apr 25 21:47:43.846603 2018] [:error] [pid 29271] [remote 192.168.145.30:188] Traceback (most recent call last):
[Wed Apr 25 21:47:43.846630 2018] [:error] [pid 29271] [remote 192.168.145.30:188] File "/usr/share/ipa/wsgi.py", line 51, in application
[Wed Apr 25 21:47:43.846690 2018] [:error] [pid 29271] [remote 192.168.145.30:188] return api.Backend.wsgi_dispatch(environ, start_response)
[Wed Apr 25 21:47:43.846711 2018] [:error] [pid 29271] [remote 192.168.145.30:188] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 262, in __call__
[Wed Apr 25 21:47:43.846747 2018] [:error] [pid 29271] [remote 192.168.145.30:188] return self.route(environ, start_response)
[Wed Apr 25 21:47:43.846759 2018] [:error] [pid 29271] [remote 192.168.145.30:188] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 274, in route
[Wed Apr 25 21:47:43.846776 2018] [:error] [pid 29271] [remote 192.168.145.30:188] return app(environ, start_response)
[Wed Apr 25 21:47:43.846787 2018] [:error] [pid 29271] [remote 192.168.145.30:188] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 929, in __call__
[Wed Apr 25 21:47:43.846803 2018] [:error] [pid 29271] [remote 192.168.145.30:188] self.kinit(user_principal, password, ipa_ccache_name)
[Wed Apr 25 21:47:43.846814 2018] [:error] [pid 29271] [remote 192.168.145.30:188] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 965, in kinit
[Wed Apr 25 21:47:43.846829 2018] [:error] [pid 29271] [remote 192.168.145.30:188] pkinit_anchors=[paths.KDC_CERT, paths.KDC_CA_BUNDLE_PEM],
[Wed Apr 25 21:47:43.846843 2018] [:error] [pid 29271] [remote 192.168.145.30:188] File "/usr/lib/python2.7/site-packages/ipalib/install/kinit.py", line 125, in kinit_armor
[Wed Apr 25 21:47:43.846872 2018] [:error] [pid 29271] [remote 192.168.145.30:188] run(args, env=env, raiseonerr=True, capture_error=True)
[Wed Apr 25 21:47:43.846883 2018] [:error] [pid 29271] [remote 192.168.145.30:188] File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 512, in run
[Wed Apr 25 21:47:43.846906 2018] [:error] [pid 29271] [remote 192.168.145.30:188] raise CalledProcessError(p.returncode, arg_string, str(output))
[Wed Apr 25 21:47:43.846976 2018] [:error] [pid 29271] [remote 192.168.145.30:188] CalledProcessError: Command '/usr/bin/kinit -n -c /var/run/ipa/ccaches/armor_29271 -X X509_anchors=FILE:/var/kerberos/krb5kdc/kdc.crt -X X509_anchors=FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem' returned non-zero exit status 1
Anyone seen this before?
Thanks,
Ross
6 years