Have now reproduced on multiple host. In heterogeneous environments (IPA and non-IPA), the KDC is NOT honoring preauth flags on any hosts which are NOT enrolled with ipa-install-client. I have verified with a completely fresh install of 4.4.0 on CentOS 7.3.1611.
Reproduction is relatively simple. Stand up a new IPA environment; you will need a non-Linux client (FreeBSD or AIX is recommended) as I have not tested Linux non-IPA yet. I would expect same behavior.
On the IPA master (using TEST.IPA as the realm):
ipa-master# ipa config-mod --ipaconfigstring=”KDC:Disable Default Preauth for SPNs” ipa-master# ipa config-show Password plugin features: KDC:Disable Default Preauth for SPNs Default PAC types: nfs:NONE, MS-PAC ipa-master# ipa host-add fails.test.ipa --os="Not Linux" --requires-pre-auth=False --ok-as-delegate=True --ip-address=192.168.1.2 ipa-master# ipa service-add nfs/fails.test.ipa@TEST.IPA --requires-pre-auth=False --pac-type=NONE ipa-master# for p in host nfs; do ipa-getkeytab -s ipa-master.test.ipa -p $p/fails.test.ipa -k /root/fails.keytab done ipa-master# ktutil ktutil: rkt /root/fails.keytab ktutil: list -e slot KVNO Principal ---- ---- --------------------------------------------------------------------- 1 2 host/fails.test.ipa@TEST.IPA (aes256-cts-hmac-sha1-96) 2 2 host/fails.test.ipa@TEST.IPA (aes128-cts-hmac-sha1-96) 3 2 nfs/fails.test.ipa@TEST.IPA (aes256-cts-hmac-sha1-96) 4 2 nfs/fails.test.ipa@TEST.IPA (aes128-cts-hmac-sha1-96)
Now copy the keytab (securely of course) to the client system - in our example here, I am explicitly keeping it out of krb5.keytab for testing purposes. The client used here is FreeBSD with Heimdal 1.5.2 from base. This has been previously tested and validated as working with FreeIPA 4.2.
fails# ktutil -k fails.keytab list fails.keytab: Vno Type Principal Aliases 1 aes256-cts-hmac-sha1-96 host/fails.test.ipa@TEST.IPA 1 aes128-cts-hmac-sha1-96 host/fails.test.ipa@TEST.IPA 1 aes256-cts-hmac-sha1-96 nfs/fails.test.ipa@TEST.IPA 1 aes128-cts-hmac-sha1-96 nfs/fails.test.ipa@TEST.IPA fails# vi /etc/krb5.conf ... basic configuration; realm, use dns, do not use pkinit_anchors, debug logging is recommended but produces no output... fails# kinit admin admin@TEST.IPA's Password: fails# klist Credentials cache: FILE:/tmp/krb5cc_0 Principal: admin@TEST.IPA Issued Expires Principal Jan 4 10:43:48 2017 Jan 5 10:43:48 2017 krbtgt/TEST.IPA@TEST.IPA fails# kinit -S nfs/fails.test.ipa@TEST.IPA -t fails.keytab kinit: krb5_get_init_creds: Already tried ENC-TS-info, looping
So as you can see, I'm able to kinit as admin with no issues, but the keytab is failing. Investigation of the IPA master reveals this:
ipa-master# grep 192.168.1.2 /var/log/krb5kdc.log Jan 04 10:43:48 ipa-master.test.ipa krb5kdc[4540](info): AS_REQ (5 etypes {18 17 16 5 23}) 192.168.1.2: NEEDED_PREAUTH: admin@TEST.IPA for krbtgt/TEST.IPA@TEST.IPA, Additional pre-authentication required Jan 04 10:43:48 ipa-master.test.ipa krb5kdc[4541](info): AS_REQ (5 etypes {18 17 16 5 23}) 192.168.1.2: ISSUE: authtime 1483544628, etypes {rep=18 tkt=18 ses=18}, admin@TEST.IPA for krbtgt/TEST.IPA@TEST.IPA Jan 04 10:45:08 ipa-master.test.ipa krb5kdc[4541](info): AS_REQ (5 etypes {18 17 16 5 23}) 192.168.1.2: NEEDED_PREAUTH: admin@TEST.IPA for nfs/fails.test.ipa@TEST.IPA, Additional pre-authentication required Jan 04 10:45:08 ipa-master.test.ipa krb5kdc[4541](info): DISPATCH: repeated (retransmitted?) request from 192.168.1.2, resending previous response ipa-master# rpm -qa | egrep '(ipa|krb5)' | grep -v python ipa-admintools-4.4.0-14.el7.centos.1.1.noarch ipa-server-4.4.0-14.el7.centos.1.1.x86_64 libipa_hbac-1.14.0-43.el7_3.4.x86_64 sssd-ipa-1.14.0-43.el7_3.4.x86_64 krb5-libs-1.14.1-27.el7_3.x86_64 pam_krb5-2.4.8-6.el7.x86_64 ipa-common-4.4.0-14.el7.centos.1.1.noarch ipa-server-common-4.4.0-14.el7.centos.1.1.noarch ipa-client-4.4.0-14.el7.centos.1.1.x86_64 ipa-server-dns-4.4.0-14.el7.centos.1.1.noarch sssd-krb5-common-1.14.0-43.el7_3.4.x86_64 krb5-pkinit-1.14.1-27.el7_3.x86_64 krb5-server-1.14.1-27.el7_3.x86_64 ipa-client-common-4.4.0-14.el7.centos.1.1.noarch sssd-krb5-1.14.0-43.el7_3.4.x86_64 krb5-workstation-1.14.1-27.el7_3.x86_64
As you can clearly see, krb5kdc is entering NEEDED_PREAUTH for the nfs service principal, even though it should NOT, causing Heimdal to return a (slightly misleading) ENC-TS-info error. This is 100% reproducible in my environment.
I wonder if this is related to the auth indicator work.
I was trying to reproduce the issue on RHEL machines but everything works correctly for me. I have no access to FreeBSD/AIX box, however, so I cannot test against differently packaged MIT libraries or Heimdal (this should however not make any difference since the KDC decides about preauth, not client).
I have, however, noted a following discrepancy in the ticket description:
The log excerpt shows KDC requiring preauth for admin@TEST.IPA for service nfs/fails.test.ipa@TEST.IPA, which is expected since 'admin' as a user principal is always required to preauthenticate against KDC. The question is why this principal was selected by Heimdal when doing kinit on the non-Linux host. But maybe the log message is wronng and unrelated to the command being run.
Could you please re-run the reproducer but prepend KRB5_TRACE=/dev/stderr before kinit command (kinit -S nfs/fails.test.ipa@TEST.IPA -t fails.keytab) to see which keys/principals is the client library selecting? It could shed more light on the issue.
kinit -S nfs/fails.test.ipa@TEST.IPA -t fails.keytab
I think using the '-S' option is not what you want. It it used if you not want to use the default TGT service principal 'krbtgt/TEST.IPA@TEST.IPA'. Please try
# kinit -t fails.keytab nfs/fails.test.ipa@TEST.IPA
to get a TGT for the nfs/fails.test.ipa@TEST.IPA principal from the keytab.
HTH
bye, Sumit
Closing as worksforme since the reporter did not submit a reproducer. Feel free to reopen the ticket if you manage to gather more data regarding the issue.
Metadata Update from @rootwyrm: - Issue assigned to someone - Issue set to the milestone: 0.0 NEEDS_TRIAGE
Metadata Update from @rootwyrm: - Issue status updated to: Open (was: Closed)
Reopening as clearly nobody actually bothered to investigate. Which has now resulted in an even WORSE bug. Which is not a new issue either. See https://pagure.io/freeipa/issue/3860
Congratulations. It's now even worse. The lack of PREAUTH is being completely and totally disregarded for all service principals after bumping to ipa 4.4.0-14.el7, rendering a previously bashed-into-working infrastructure a brick.
kadmin.local: getprinc nslcd/teldrassil.removed@REMOVED Principal: nslcd/teldrassil.removed@REMOVED Expiration date: [never] Last password change: Fri Mar 24 20:42:56 EDT 2017 Password expiration date: [none] Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Fri Mar 24 21:16:36 EDT 2017 (admin/admin@REMOVED) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 2 Key: vno 4, aes256-cts-hmac-sha1-96:special Key: vno 4, aes128-cts-hmac-sha1-96:special MKey: vno 1 Attributes: Policy: [none] # ipa host-mod --requires-pre-auth=FALSE teldrassil.removed ipa: ERROR: no modifications to be performed # ipa host-show teldrassil.removed Host name: teldrassil.removed Description: Poudriere, Kickstart, Repositories Platform: VMware Operating system: FreeBSD 11.0 amd64 Principal name: host/teldrassil.removed@REMOVED Principal alias: host/teldrassil.removed@REMOVED MAC address: 00:50:56:<SANITIZED> SSH public key <SANITIZED> Class: virtual Password: False Keytab: True Managed by: teldrassil.removed Users allowed to retrieve keytab: admin teldrassil nslcd[1060]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC returned error string: NO PREAUTH) root@teldrassil:~ # kinit admin ... root@teldrassil:~ # klist Credentials cache: FILE:/tmp/krb5cc_0 Principal: host/teldrassil.removed@REMOVED Issued Expires Principal Mar 24 21:04:42 2017 Mar 25 07:04:42 2017 krbtgt/REMOVED@REMOVED
Regenerating the keytab with ipa-getkeytab has no effect. Nothing has any effect. Deleting and recreating the host, including the kadmin.local -q "modprinc -requires_preauth $svc/$1@REMOVED step, has no effect. As is extremely and thoroughly obvious, the principal should not be requiring PREAUTH. The host can kinit manually.
kadmin.local -q "modprinc -requires_preauth $svc/$1@REMOVED
Sorry but we asked you multiple times to provide a valid reproducer and we were not provided with one. So please can we know where this line:
teldrassil nslcd[1060]: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC returned error string: NO PREAUTH)
comes from? What exactly are you calling so that it fails preauth? We really cannot help you unless you provide us with exact reproducer for your issue.
Moreover, your arrogant and demeaning style of communication does not help either and is not a big incentive for us to help.
People were emailed aside from this ticket with the same instructions basically copy and pasted from your own resources. Multiple. Times.
Create FreeIPA instance. ipa config-mod --pac-type=NONE ipa config-mod --ipaconfigstring='KDC:Disable Default Preauth for SPNs' Create host. ipa-getkeytab straight into /dev/null because first key is garbage. Work around the failure of patch 558 to work as intended. kadmin.local -q "modprinc -requires_preauth $svc/$host@$REALM" ipa-getkeytab -q -s host -p $svc/$host -k outputfile
ipa config-mod --pac-type=NONE
ipa config-mod --ipaconfigstring='KDC:Disable Default Preauth for SPNs'
kadmin.local -q "modprinc -requires_preauth $svc/$host@$REALM"
ipa-getkeytab -q -s host -p $svc/$host -k outputfile
And the resulting keytab still requires PREAUTH. This is broken. The workaround is now ALSO broken after a minor update, resulting in complete failure of the realm. These are the same instructions at the head of the ticket that have been there. And what do you know, a completely new install reproduced here. And another install as well.
Metadata Update from @pvoborni: - Issue set to the milestone: None (was: 0.0 NEEDS_TRIAGE)
I did the same as you so set KDC:Disable Default Preauth for SPNs.
# ipa config-mod --ipaconfigstring='KDC:Disable Default Preauth for SPNs'
Then I requested a keytab for the svc/hostname:
hostname
# ipa service-add svc/`hostname` # ipa-getkeytab -p svc/`hostname` -k /root/svc.keytab Keytab successfully retrieved and stored in: /root/svc.keytab
I kinit as a service:
# kinit -kt /root/svc.keytab svc/`hostname` # klist # klist Ticket cache: KEYRING:persistent:0:krb_ccache_V3jR68b Default principal: svc/hostname@REALM Valid starting Expires Service principal 03/31/2017 19:07:00 04/01/2017 19:07:00 krbtgt/REALM@REALM renew until 04/01/2017 19:07:01
Let's check the KDC logs:
Mar 31 19:07:00 hostname krb5kdc[66063](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.34.58.71: ISSUE: authtime 1490980020, etypes {rep=18 tkt=18 ses=18}, svc/hostname@REALM for krbtgt/REALM@REALM Mar 31 19:07:00 hostname krb5kdc[66063](info): closing down fd 11
No NEEDED_PREAUTH messages there. If iI trace the TGT request I see that the client is ready for preauth but none is needed and I get an AS reply directly:
KRB5_TRACE=/dev/stderr kinit -kt /root/svc.keytab svc/`hostname` [66149] 1490980374.54221: Getting initial credentials for svc/hostname@REALM [66149] 1490980374.57073: Looked up etypes in keytab: aes256-cts, aes128-cts [66149] 1490980374.57158: Sending request (270 bytes) to REALM [66149] 1490980374.57458: Initiating TCP connection to stream 10.34.58.71:88 [66149] 1490980374.57661: Sending TCP request to stream 10.34.58.71:88 [66149] 1490980374.65351: Received answer (981 bytes) from stream 10.34.58.71:88 [66149] 1490980374.65418: Terminating TCP connection to stream 10.34.58.71:88 [66149] 1490980374.65634: Response was from master KDC [66149] 1490980374.65692: Processing preauth types: 19 [66149] 1490980374.65716: Selected etype info: etype aes256-cts, salt "]'`P+&_zg)B)YkKe", params "" [66149] 1490980374.65734: Produced preauth for next request: (empty) [66149] 1490980374.65747: Getting AS key, salt "]'`P+&_zg)B)YkKe", params "" [66149] 1490980374.66092: Retrieving svc/hostname@REALM from FILE:/root/svc.keytab (vno 0, enctype aes256-cts) with result: 0/Success [66149] 1490980374.66149: AS key obtained from gak_fct: aes256-cts/8101 [66149] 1490980374.66216: Decrypted AS reply; session key is: aes256-cts/C1C5 [66149] 1490980374.66259: FAST negotiation: available [66149] 1490980374.66299: Initializing KEYRING:persistent:0:krb_ccache_V3jR68b with default princ svc/hostname@REALM [66149] 1490980374.66421: Storing svc/hostname@REALM-> krbtgt/REALM@REALM in KEYRING:persistent:0:krb_ccache_V3jR68b [66149] 1490980374.66531: Storing config in KEYRING:persistent:0:krb_ccache_V3jR68b for krbtgt/REALM@REALM: fast_avail: yes [66149] 1490980374.66573: Storing svc/hostname@REALM -> krb5_ccache_conf_data/fast_avail/krbtgt\/REALM\@REALM@X-CACHECONF: in KEYRING:persistent:0:krb_ccache_V3jR68b
So indeed, service TGT request does not require preauth. This was tested on FreeIPA 4.4.3. Can you please provide this kind of scenario when preauthentication is required?
@rootwyrm are you still using kinit -S for this test ? If so, can you explain why you are using that specific flag ? Note that using -S does not obatin a ticket as the nfs service, but gets a new ticket directly against the nfs service. This is not what you want in most cases. But if this is expliucitly what you want, can you describe the use cases better ?
Keep in mind that given the keytab you showed what you are likely ending doing is: use the host/fqdn principal and key to get a ticket with a direct AS request for: [host/fqdn]->[nfs/fqdn]
Is this intentional ?
Actually your log states you tried to get a direct ticket from: [admin@REALM]->[nfs/fqdn]
This requires preauth because Admin is not a SPN.
No response for 17 days, closing.
Metadata Update from @pvoborni: - Issue close_status updated to: worksforme - Issue status updated to: Closed (was: Open)