#6590 IPA KDC not honoring or obeying preauth flags
Closed: worksforme Opened by rootwyrm.

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.

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.

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

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:

# 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)

Metadata