1438729 – Configure local PKINIT on DL0 or when '--no-pkinit' option is used

RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1438729 - Configure local PKINIT on DL0 or when '--no-pkinit' option is used

Summary: Configure local PKINIT on DL0 or when '--no-pkinit' option is used

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 7
Classification:	Red Hat
Component:	ipa
Sub Component:
Version:	7.4
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	---
Assignee:	IPA Maintainers
QA Contact:	Scott Poore
Docs Contact:
URL:
Whiteboard:
Depends On:	1452215
Blocks:
TreeView+	depends on / blocked

Reported:	2017-04-04 10:02 UTC by Petr Vobornik
Modified:	2017-09-11 14:47 UTC (History)
CC List:	9 users (show)
Fixed In Version:	ipa-4.5.0-9.el7
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2017-08-01 09:47:49 UTC
Target Upstream Version:
Embargoed:

Attachments	(Terms of Use)
error_log from httpd (64.30 KB, text/plain) 2017-05-05 12:13 UTC, Scott Poore	no flags	Details
error_log from httpd with ipa debugging (99.33 KB, text/plain) 2017-05-05 16:03 UTC, Scott Poore	no flags	Details
View All

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Red Hat Product Errata	RHBA-2017:2304	0	normal	SHIPPED_LIVE	ipa bug fix and enhancement update	2017-08-01 12:41:35 UTC

Description Petr Vobornik 2017-04-04 10:02:26 UTC

Cloned from upstream: https://pagure.io/freeipa/issue/6830

Currently if PKINIT is not configured, there is no fallback mechanism for FreeIPA framework to obtain armor TGT for password/2FA logins. In this case we should issue a local KDC keypair for use as a fallback mechanism only on the master (it is not expected for this to work on clients). This keypair may be either self-signed, or we may introduce a local PKINIT CA that will sign KDC keypair. This CA will be self-signed in no-PKINIT scenario, and will be replaced by a CA with the same subject and private key after full PKINIT is requested.

For more details see http://www.freeipa.org/page/V4/Kerberos_PKINIT

Comment 2 Petr Vobornik 2017-04-04 10:02:47 UTC

Upstream ticket:
https://pagure.io/freeipa/issue/6830

Comment 3 Jan Cholasta 2017-04-28 08:39:55 UTC

Fixed upstream
master:
https://pagure.io/freeipa/c/b1a1e104391c84cb9af7b0a7c8748c8652442ddb
https://pagure.io/freeipa/c/fb52f7a1f328b126626525179d5250692daca2cd
https://pagure.io/freeipa/c/86972299d937960bcb713fc73b447cddb4ea44bd
https://pagure.io/freeipa/c/3adb9ca875f8eb99e99a29e17a471a2b6f408a4a
https://pagure.io/freeipa/c/68c6a4d4e1340ce01bdc7ec5dd394604a3da7688
https://pagure.io/freeipa/c/2374b648d0dfd08ec4cfbcc35f7987fa8b8a6ffa
https://pagure.io/freeipa/c/a194055c92c7ca4eba29323f990ec3b92026221b
https://pagure.io/freeipa/c/960e361f68a3d7acd9bcf16ec6fe8f6d5376c4ae
ipa-4-5:
https://pagure.io/freeipa/c/31a24436592304db6e84270e4a95df34d1e0af46
https://pagure.io/freeipa/c/b49e075c90a7ab43e82f422aa11dc7540e2fb2c0
https://pagure.io/freeipa/c/a0e2a09292ffa2adbf97c2e7e4facc9693dbc311
https://pagure.io/freeipa/c/fca378c9a65f582ac3dcda4b6201e8847ed9e512
https://pagure.io/freeipa/c/9fcc794dac6ffb1f1cc6c92a588ea0911be5ba14
https://pagure.io/freeipa/c/5031929b6d710336f6308d7f46779c9e8e98103a
https://pagure.io/freeipa/c/2452e6e5f3a7e7a25eadf5243a28da75a47f9d2c
https://pagure.io/freeipa/c/d497c4589cc7506ef9a88b691b8b1d97ad1f1009

Comment 4 Scott Poore 2017-04-29 03:58:07 UTC

How can we verify this functionality?

Should anonymous pkinit be enough to test that the fallback has worked when installed with no pkinit is set during install?

1. Install IPA with --no-pkinit
2. kinit -n
3. klist
4. ARMOR_CCACHE=$(klist|grep cache:|cut -d' ' -f3-)
5. kinit -T $ARMOR_CCACHE principal@REALM 

Thanks,
Scott

Comment 6 Martin Babinsky 2017-05-03 11:32:41 UTC

Scott,

since the idea is that login by password should work regardless of the actual PKINIT status, you can adapt the following script I have used to test the feature:

"""
$ cat test_login_password.sh 
#!/bin/bash

COOKIES=/tmp/${1}_session.cookie

curl -v  \
 -H referer:https://`hostname`/ipa \
 -H "Content-Type:application/x-www-form-urlencoded" \
 -H "Accept:text/plain" \
 -c $COOKIES -b $COOKIES \
 --data  "user=$1&password=$2" \
 --cacert /etc/ipa/ca.crt  \
 -X POST \
 https://`hostname`/ipa/session/login_password
"""

If `login_password` succeeds, you should get the session cookie back from the server. If not it should return 401, or even 500 to you.

If you want to test only the anon PKINIT part, make sure you use the KDC's CA cert bundle as anchor:

"""
kinit -n -X X509_anchors=FILE:/var/kerberos/krb5kdc/cacert.pem -T $ARMOR_CCACHE
kinit -T $ARMOR_CCACHE principal@REALM
"""

Comment 7 Scott Poore 2017-05-04 01:46:57 UTC

Martin,

What does it mean if I get a cookie and 500?

[root@rhel7-3 ~]# ./login_password.sh admin Secret123
* About to connect() to rhel7-3.example.com port 443 (#0)
*   Trying 192.168.122.73...
* Connected to rhel7-3.example.com (192.168.122.73) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/ipa/ca.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* 	subject: CN=rhel7-3.example.com,O=EXAMPLE.COM
* 	start date: May 04 01:38:19 2017 GMT
* 	expire date: May 05 01:38:19 2019 GMT
* 	common name: rhel7-3.example.com
* 	issuer: CN=Certificate Authority,O=EXAMPLE.COM
> POST /ipa/session/login_password HTTP/1.1
> User-Agent: curl/7.29.0
> Host: rhel7-3.example.com
> referer:https://rhel7-3.example.com/ipa
> Content-Type:application/x-www-form-urlencoded
> Accept:text/plain
> Content-Length: 29
> 
* upload completely sent off: 29 out of 29 bytes
< HTTP/1.1 500 Internal Server Error
< Date: Thu, 04 May 2017 01:42:13 GMT
< Server: Apache/2.4.6 (Red Hat Enterprise Linux) mod_auth_gssapi/1.5.1 mod_nss/1.0.14 NSS/3.28.1 mod_wsgi/3.4 Python/2.7.5
* Added cookie ipa_session="expiry=1493863933386563" for domain rhel7-3.example.com, path /ipa, expire 1493863933
< Set-Cookie: ipa_session=expiry=1493863933386563;Max-Age=1800;path=/ipa;httponly;secure;
< X-Frame-Options: DENY
< Content-Security-Policy: frame-ancestors 'none'
< Cache-Control: no-cache
* Replaced cookie ipa_session="expiry=1493863933386563" for domain rhel7-3.example.com, path /ipa, expire 1493863933
< Set-Cookie: ipa_session=expiry=1493863933386563;Max-Age=1800;path=/ipa;httponly;secure;
< Content-Length: 527
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
< 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>500 Internal Server Error</title>
</head><body>
<h1>Internal Server Error</h1>
<p>The server encountered an internal error or
misconfiguration and was unable to complete
your request.</p>
<p>Please contact the server administrator at 
 root@localhost to inform them of the time this error occurred,
 and the actions you performed just before this error.</p>
<p>More information about this error may be available
in the server error log.</p>
</body></html>
* Closing connection 0

[root@rhel7-3 ~]# cat /tmp/admin_session.cookie 
# Netscape HTTP Cookie File
# http://curl.haxx.se/docs/http-cookies.html
# This file was generated by libcurl! Edit at your own risk.

#HttpOnly_rhel7-3.example.com	FALSE	/ipa	TRUE	1493863933	ipa_session	expiry=1493863933386563


End of /var/log/httpd/error_log:

[Wed May 03 20:42:13.385782 2017] [:error] [pid 4960] [remote 192.168.122.73:224] mod_wsgi (pid=4960): Exception occurred processing WSGI script '/usr/share/ipa/wsgi.py'.
[Wed May 03 20:42:13.385830 2017] [:error] [pid 4960] [remote 192.168.122.73:224] Traceback (most recent call last):
[Wed May 03 20:42:13.385851 2017] [:error] [pid 4960] [remote 192.168.122.73:224]   File "/usr/share/ipa/wsgi.py", line 51, in application
[Wed May 03 20:42:13.385930 2017] [:error] [pid 4960] [remote 192.168.122.73:224]     return api.Backend.wsgi_dispatch(environ, start_response)
[Wed May 03 20:42:13.385940 2017] [:error] [pid 4960] [remote 192.168.122.73:224]   File "/usr/lib/pyth
on2.7/site-packages/ipaserver/rpcserver.py", line 262, in __call__
[Wed May 03 20:42:13.386118 2017] [:error] [pid 4960] [remote 192.168.122.73:224]     return self.route(environ, start_response)
[Wed May 03 20:42:13.386127 2017] [:error] [pid 4960] [remote 192.168.122.73:224]   File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 274, in route
[Wed May 03 20:42:13.386137 2017] [:error] [pid 4960] [remote 192.168.122.73:224]     return app(environ, start_response)
[Wed May 03 20:42:13.386142 2017] [:error] [pid 4960] [remote 192.168.122.73:224]   File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 914, in __call__
[Wed May 03 20:42:13.386149 2017] [:error] [pid 4960] [remote 192.168.122.73:224]     self.kinit(user_principal, password, ipa_ccache_name)
[Wed May 03 20:42:13.386153 2017] [:error] [pid 4960] [remote 192.168.122.73:224]   File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 948, in kinit
[Wed May 03 20:42:13.386159 2017] [:error] [pid 4960] [remote 192.168.122.73:224]     kinit_armor(armor_path, pkinit_anchor=paths.CACERT_PEM)
[Wed May 03 20:42:13.386165 2017] [:error] [pid 4960] [remote 192.168.122.73:224]   File "/usr/lib/python2.7/site-packages/ipalib/install/kinit.py", line 121, in kinit_armor
[Wed May 03 20:42:13.386207 2017] [:error] [pid 4960] [remote 192.168.122.73:224]     run(args, env=env, raiseonerr=True, capture_error=True)
[Wed May 03 20:42:13.386214 2017] [:error] [pid 4960] [remote 192.168.122.73:224]   File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 495, in run
[Wed May 03 20:42:13.386405 2017] [:error] [pid 4960] [remote 192.168.122.73:224]     raise CalledProcessError(p.returncode, arg_string, str(output))
[Wed May 03 20:42:13.386429 2017] [:error] [pid 4960] [remote 192.168.122.73:224] CalledProcessError: Command '/usr/bin/kinit -n -c /var/run/ipa/ccaches/armor_4960 -X X509_anchors=FILE:/var/kerberos/krb5kdc/cacert.pem' returned non-zero exit status 1

Comment 8 Martin Babinsky 2017-05-05 11:14:16 UTC

It means that something when wrong with anonymous kinit. I need to see httpd error_log from debug mode, and also please check for any AVCs if running in enforcing mode, as we may need a policy for ipaapi user reading KDC CA bundle.

Also please try to manually perform:

"""
KRB5_TRACE=/dev/stderr /usr/bin/kinit -n -X X509_anchors=FILE:/var/kerberos/krb5kdc/cacert.pem
"""

and paste the output.

Comment 9 Scott Poore 2017-05-05 12:13:04 UTC

Interesting...

I put SELinux into permissive mode, changed httpd loglevel to debug and rebooted.


Now it works:

[root@rhel7-3 ~]# ./login_password.sh admin Secret123
* About to connect() to rhel7-3.example.com port 443 (#0)
*   Trying 192.168.122.73...
* Connected to rhel7-3.example.com (192.168.122.73) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/ipa/ca.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* 	subject: CN=rhel7-3.example.com,O=EXAMPLE.COM
* 	start date: May 04 01:38:19 2017 GMT
* 	expire date: May 05 01:38:19 2019 GMT
* 	common name: rhel7-3.example.com
* 	issuer: CN=Certificate Authority,O=EXAMPLE.COM
> POST /ipa/session/login_password HTTP/1.1
> User-Agent: curl/7.29.0
> Host: rhel7-3.example.com
> referer:https://rhel7-3.example.com/ipa
> Content-Type:application/x-www-form-urlencoded
> Accept:text/plain
> Content-Length: 29
> 
* upload completely sent off: 29 out of 29 bytes
< HTTP/1.1 200 Success
< Date: Fri, 05 May 2017 12:02:12 GMT
< Server: Apache/2.4.6 (Red Hat Enterprise Linux) mod_auth_gssapi/1.5.1 mod_nss/1.0.14 NSS/3.28.1 mod_wsgi/3.4 Python/2.7.5
< IPASESSION: MagBearerToken=d3lApKdZgnk04GmaoCMCerogXoUgiuZSNtQGp%2bj6qoZO4pd50vONzMkTh%2fqGK0haF5OPgUMp1qdwQDQY2Y3N0BZuMR0TYQ51Kv9IWin7MnSy0eyXYtcTZ5fvuzzUQi6Mmq9kkKo6Wn%2fYqSFvmYhsssqCu%2b0Whc7qiQH5o905I3H5ZByOF0Mi4P7NfYt6TP4Q&expiry=1493987532787550
* Added cookie ipa_session="MagBearerToken=d3lApKdZgnk04GmaoCMCerogXoUgiuZSNtQGp%2bj6qoZO4pd50vONzMkTh%2fqGK0haF5OPgUMp1qdwQDQY2Y3N0BZuMR0TYQ51Kv9IWin7MnSy0eyXYtcTZ5fvuzzUQi6Mmq9kkKo6Wn%2fYqSFvmYhsssqCu%2b0Whc7qiQH5o905I3H5ZByOF0Mi4P7NfYt6TP4Q&expiry=1493987532789647" for domain rhel7-3.example.com, path /ipa, expire 1493987532
< Set-Cookie: ipa_session=MagBearerToken=d3lApKdZgnk04GmaoCMCerogXoUgiuZSNtQGp%2bj6qoZO4pd50vONzMkTh%2fqGK0haF5OPgUMp1qdwQDQY2Y3N0BZuMR0TYQ51Kv9IWin7MnSy0eyXYtcTZ5fvuzzUQi6Mmq9kkKo6Wn%2fYqSFvmYhsssqCu%2b0Whc7qiQH5o905I3H5ZByOF0Mi4P7NfYt6TP4Q&expiry=1493987532789647;Max-Age=1800;path=/ipa;httponly;secure;
< X-Frame-Options: DENY
< Content-Security-Policy: frame-ancestors 'none'
< Cache-Control: no-cache
< Content-Length: 0
< Content-Type: text/plain; charset=UTF-8
< 
* Connection #0 to host rhel7-3.example.com left intact


But, not AVCs...

So, I put it back into enforcing mode and restarted IPA to try again and did see the error and AVCs that looked like this:

time->Fri May  5 07:07:16 2017
type=SYSCALL msg=audit(1493986036.072:228): arch=c000003e syscall=2 success=no exit=-13 a0=7f95c9b918f8 a1=0 a2=1b6 a3=560dae1f014c items=0 ppid=1 pid=1867 auid=4294967295 uid=389 gid=389 euid=389 suid=389 fsuid=389 egid=389 sgid=389 fsgid=389 tty=(none) ses=4294967295 comm="ns-slapd" exe="/usr/sbin/ns-slapd" subj=system_u:system_r:dirsrv_t:s0 key=(null)
type=AVC msg=audit(1493986036.072:228): avc:  denied  { search } for  pid=1867 comm="ns-slapd" name="/" dev="cgroup" ino=6767 scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:cgroup_t:s0 tclass=dir


Also, here's the kinit output you wanted:

[root@rhel7-3 ~]# KRB5_TRACE=/dev/stderr /usr/bin/kinit -n -X X509_anchors=FILE:/var/kerberos/krb5kdc/cacert.pem
[2328] 1493986093.789410: Resolving unique ccache of type KEYRING
[2328] 1493986093.790975: Getting initial credentials for WELLKNOWN/ANONYMOUS
[2328] 1493986093.791076: Sending request (186 bytes) to EXAMPLE.COM
[2328] 1493986093.791221: Initiating TCP connection to stream 192.168.122.73:88
[2328] 1493986093.791422: Sending TCP request to stream 192.168.122.73:88
[2328] 1493986093.792869: Received answer (338 bytes) from stream 192.168.122.73:88
[2328] 1493986093.792875: Terminating TCP connection to stream 192.168.122.73:88
[2328] 1493986093.792915: Response was from master KDC
[2328] 1493986093.792931: Received error from KDC: -1765328359/Additional pre-authentication required
[2328] 1493986093.792960: Processing preauth types: 16, 15, 14, 136, 19, 147, 2, 133
[2328] 1493986093.792968: Selected etype info: etype aes256-cts, salt "EXAMPLE.COMWELLKNOWNANONYMOUS", params ""
[2328] 1493986093.792971: Received cookie: MIT
[2328] 1493986093.792988: Preauth module pkinit (147) (info) returned: 0/Success
[2328] 1493986093.793342: PKINIT client computed kdc-req-body checksum 9/EFE9B3D0B812C59CA65656495F30028CCA92BBC6
[2328] 1493986093.793346: PKINIT client making DH request
[2328] 1493986093.813943: Preauth module pkinit (16) (real) returned: 0/Success
[2328] 1493986093.813960: Produced preauth for next request: 133, 16
[2328] 1493986093.813981: Sending request (1376 bytes) to EXAMPLE.COM
[2328] 1493986093.814071: Initiating TCP connection to stream 192.168.122.73:88
[2328] 1493986093.814310: Sending TCP request to stream 192.168.122.73:88
[2328] 1493986093.826629: Received answer (1609 bytes) from stream 192.168.122.73:88
[2328] 1493986093.826638: Terminating TCP connection to stream 192.168.122.73:88
[2328] 1493986093.826683: Response was from master KDC
[2328] 1493986093.826705: Processing preauth types: 17, 19, 147
[2328] 1493986093.826710: Selected etype info: etype aes256-cts, salt "EXAMPLE.COMWELLKNOWNANONYMOUS", params ""
[2328] 1493986093.826722: Preauth module pkinit (147) (info) returned: 0/Success
[2328] 1493986093.826888: PKINIT client verified DH reply
[2328] 1493986093.826902: PKINIT client found id-pkinit-san in KDC cert: krbtgt/EXAMPLE.COM
[2328] 1493986093.826905: PKINIT client matched KDC principal krbtgt/EXAMPLE.COM against id-pkinit-san; no EKU check required
[2328] 1493986093.833043: PKINIT client used KDF 2B06010502030602 to compute reply key aes256-cts/6485
[2328] 1493986093.833058: Preauth module pkinit (17) (real) returned: 0/Success
[2328] 1493986093.833060: Produced preauth for next request: (empty)
[2328] 1493986093.833063: AS key determined by preauth: aes256-cts/6485
[2328] 1493986093.833107: Decrypted AS reply; session key is: aes256-cts/34AE
[2328] 1493986093.833120: FAST negotiation: available
[2328] 1493986093.833166: Initializing KEYRING:persistent:0:krb_ccache_15QAXhS with default princ WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS
[2328] 1493986093.833201: Storing WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS -> krbtgt/EXAMPLE.COM in KEYRING:persistent:0:krb_ccache_15QAXhS
[2328] 1493986093.833236: Storing config in KEYRING:persistent:0:krb_ccache_15QAXhS for krbtgt/EXAMPLE.COM: fast_avail: yes
[2328] 1493986093.833245: Storing WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS -> krb5_ccache_conf_data/fast_avail/krbtgt\/EXAMPLE.COM\@EXAMPLE.COM@X-CACHECONF: in KEYRING:persistent:0:krb_ccache_15QAXhS
[2328] 1493986093.833267: Storing config in KEYRING:persistent:0:krb_ccache_15QAXhS for krbtgt/EXAMPLE.COM: pa_type: 16
[2328] 1493986093.833273: Storing WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.COM\@EXAMPLE.COM@X-CACHECONF: in KEYRING:persistent:0:krb_ccache_15QAXhS

[root@rhel7-3 ~]# find / -inum 6767
/sys/fs/cgroup/memory
/sys/bus/pci/drivers/xen-platform-pci/new_id


I'll attach error_log shortly

Comment 10 Scott Poore 2017-05-05 12:13:30 UTC

Created attachment 1276550 [details]
error_log from httpd

Comment 11 Martin Babinsky 2017-05-05 13:23:53 UTC

Thanks Scott, but I meant to put 'debug = True' into /etc/ipa/default.conf and restart httpd to enable framework code debugging. Can you please do this and provide httpd_error log again?

Sorry for not being clear enough.

Comment 12 Scott Poore 2017-05-05 16:03:08 UTC

Created attachment 1276623 [details]
error_log from httpd with ipa debugging

Ok, I tested with both permissive mode and enforcing.  Logs were cleared first so should just have start and those two events.

Comment 13 Martin Babinsky 2017-05-09 11:13:17 UTC

Well now the error is clear:

'''
[Fri May 05 10:58:55.317161 2017] [:error] [pid 1872] ipa: DEBUG: WSGI wsgi_dispatch.__call__:
[Fri May 05 10:58:55.317219 2017] [:error] [pid 1872] ipa: DEBUG: WSGI login_password.__call__:
[Fri May 05 10:58:55.317611 2017] [:error] [pid 1872] ipa: DEBUG: Obtaining armor in ccache /var/run/ipa/ccaches/armor_1872
[Fri May 05 10:58:55.317648 2017] [:error] [pid 1872] ipa: DEBUG: Initializing anonymous ccache
[Fri May 05 10:58:55.317711 2017] [:error] [pid 1872] ipa: DEBUG: Starting external process
[Fri May 05 10:58:55.317746 2017] [:error] [pid 1872] ipa: DEBUG: args=/usr/bin/kinit -n -c /var/run/ipa/ccaches/armor_1872 -X X509_anchors=FILE:/var/kerberos/krb5kdc/cacert.pem
[Fri May 05 10:58:55.326771 2017] [:error] [pid 1872] ipa: DEBUG: Process finished, return code=1
[Fri May 05 10:58:55.326840 2017] [:error] [pid 1872] ipa: DEBUG: stdout=Password for WELLKNOWN/ANONYMOUS: 
[Fri May 05 10:58:55.326845 2017] [:error] [pid 1872] 
[Fri May 05 10:58:55.326873 2017] [:error] [pid 1872] ipa: DEBUG: stderr=kinit: Pre-authentication failed: Cannot open file '/var/kerberos/krb5kdc/cacert.pem': Permission denied while getting initial credentials
'''

So please check perms on '/var/kerberos/krb5kdc/cacert.pem' and also check for AVCs on the file, that seems to be the root cause of your problems.

Comment 14 Scott Poore 2017-05-09 14:12:23 UTC

It appears open and I'm not seeing any AVCs:


[root@rhel7-3 ~]# ls -lZd /var/kerberos/krb5kdc/cacert.pem
-rw-r--r--. root root unconfined_u:object_r:krb5kdc_conf_t:s0 /var/kerberos/krb5kdc/cacert.pem

[root@rhel7-3 ~]# ls -lZd /var/kerberos/krb5kdc/
drwxr-xr-x. root root system_u:object_r:krb5kdc_conf_t:s0 /var/kerberos/krb5kdc/

[root@rhel7-3 ~]# ls -lZd /var/kerberos/
drwxr-xr-x. root root system_u:object_r:var_t:s0       /var/kerberos/

[root@rhel7-3 ~]# ls -lZd /var/
drwxr-xr-x. root root system_u:object_r:var_t:s0       /var/


[root@rhel7-3 ~]# ausearch -m avc -ts 07:47
<no matches>

Comment 23 Scott Poore 2017-05-18 17:54:40 UTC

Verified.  (Only in Permissive mode though)

AVC related issues tracked in bug #1452215

Version ::

ipa-server-4.5.0-10.el7.x86_64


Results ::


[root@rhel7-3 ~]# history|grep ipa-server-install
...
   77  ipa-server-install --no-pkinit --realm EXAMPLE.COM --ds-password Secret123 --admin-password Secret123 --unattended
...


[root@rhel7-3 ~]# sh login_password.sh admin Secret123
* About to connect() to rhel7-3.example.com port 443 (#0)
*   Trying 192.168.122.73...
* Connected to rhel7-3.example.com (192.168.122.73) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/ipa/ca.crt
  CApath: none
* SSL connection using TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
* Server certificate:
* 	subject: CN=rhel7-3.example.com,O=EXAMPLE.COM
* 	start date: May 04 01:38:19 2017 GMT
* 	expire date: May 05 01:38:19 2019 GMT
* 	common name: rhel7-3.example.com
* 	issuer: CN=Certificate Authority,O=EXAMPLE.COM
> POST /ipa/session/login_password HTTP/1.1
> User-Agent: curl/7.29.0
> Host: rhel7-3.example.com
> referer:https://rhel7-3.example.com/ipa
> Content-Type:application/x-www-form-urlencoded
> Accept:text/plain
> Content-Length: 29
> 
* upload completely sent off: 29 out of 29 bytes
< HTTP/1.1 200 Success
< Date: Thu, 18 May 2017 17:49:58 GMT
< Server: Apache/2.4.6 (Red Hat Enterprise Linux) mod_auth_gssapi/1.5.1 mod_nss/1.0.14 NSS/3.28.1 mod_wsgi/3.4 Python/2.7.5
< IPASESSION: MagBearerToken=yIOT1aAoJ2VUP02%2biw3mpX8uWAswnMC9XZy%2f4sxyDcYgPYzQOtrf0KUI8gy9ciGcrixAiWgBTpCCuGVmPXxQEqF2le0%2fjSIsgD%2ftzuQeQD3xvik9TczIssxnqYA31t0NWAFDCY5Oc3whn7%2bRs0TkyNuGDR64O88VOkOpZ7hyYF46Q1jV8OaoAi8WVf0kG3yU&expiry=1495131599187633
* Replaced cookie ipa_session="MagBearerToken=yIOT1aAoJ2VUP02%2biw3mpX8uWAswnMC9XZy%2f4sxyDcYgPYzQOtrf0KUI8gy9ciGcrixAiWgBTpCCuGVmPXxQEqF2le0%2fjSIsgD%2ftzuQeQD3xvik9TczIssxnqYA31t0NWAFDCY5Oc3whn7%2bRs0TkyNuGDR64O88VOkOpZ7hyYF46Q1jV8OaoAi8WVf0kG3yU&expiry=1495131599200885" for domain rhel7-3.example.com, path /ipa, expire 1495131599
< Set-Cookie: ipa_session=MagBearerToken=yIOT1aAoJ2VUP02%2biw3mpX8uWAswnMC9XZy%2f4sxyDcYgPYzQOtrf0KUI8gy9ciGcrixAiWgBTpCCuGVmPXxQEqF2le0%2fjSIsgD%2ftzuQeQD3xvik9TczIssxnqYA31t0NWAFDCY5Oc3whn7%2bRs0TkyNuGDR64O88VOkOpZ7hyYF46Q1jV8OaoAi8WVf0kG3yU&expiry=1495131599200885;Max-Age=1800;path=/ipa;httponly;secure;
< X-Frame-Options: DENY
< Content-Security-Policy: frame-ancestors 'none'
< Cache-Control: no-cache
< Content-Length: 0
< Content-Type: text/plain; charset=UTF-8
< 
* Connection #0 to host rhel7-3.example.com left intact

Comment 24 errata-xmlrpc 2017-08-01 09:47:49 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2304

Note You need to log in before you can comment on or make changes to this bug.