I broke freeapi gssapi setup

Ask Fedora
, ,
1

Hi folks,

I recently ran an rpmconf and must have been asleep when it gave me the ipa/pam configs to update. Anyway, I have freeipa 4.10.1-4.fc38. sshd reports “KDC policy rejects request” when attempting a gssapi-with-mic authentication. Where can I find the reference sssd and pam configs to use freeipa client with gssapi? I got complacent because most of the additions I’d made are now part of the defaults. There was obviously one (or more) that I didn’t notice. sssd is using system-auth for validation, but I don’t remember where I was getting reference settings for armoured caching.

Thanks,
Eric

2

‘KDC policy rejects request’ is a server side (KDC) error, not a client side. This is most likely due to enforcement of SIDs in user accounts and your user not having SID for some reason. This is unlikely related to any changes on the client side.

On freeipa-users@ mailing list there are few threads around this kind of issue which go over details of what could be looked at. Please see my answers in this thread (dated March 2023) for some of the reasons: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho… and some materials are available in this thread: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedoraho… and few others.

3

Hi Alexander,

I should have mentioned that there’s not a Windows box to be found here, much less an AD server. I’ve run all the steps to confirm that the SID’s are set for everyone. I also don’t have SAMBA configured since I don’t need an AD server.

I confirmed that I have a subid assigned and FAST is initializing both with kinit and ssh. However, ssh fails on gssapi-with-mic with the following error:

TGS request result: -1765328372/KDC policy rejects request

4

SIDs are now required for all use cases, even without AD or Samba environments. This is a security enhancement we had to do due to known attacks out in the wild that exploit Kerberos protocol deficiencies when metadata about users and Kebreros principals cannot be co-related.

Anyway, it is time to provide logs. :wink: Please provide /var/log/krb5kdc.log from your IPA server around this request to see what is actually happening there.

5

Here’s the relevent entries in krb5kdc.log as well as the KRB5_TRACE of the ssh session startup with ssh -v:

---------- kdc.log -----------

Jul 21 12:12:12 ipasrv1.ipa.example.com krb5kdc1985: TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 192.168.2.20: HIGHER_AUTHENTICATION_REQUIRED: authtime 1689879992, testuser@IPA.EXAMPLE.COM for host/ipasrv1.ipa.example.com@IPA.EXAMPLE.COM, Required auth indicators not present in ticket: pkinit hardened
Jul 21 12:12:12 ipasrv1.ipa.example.com krb5kdc1985: closing down fd 11
Jul 21 12:12:12 ipasrv1.ipa.example.com krb5kdc1985: TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 192.168.2.20: HIGHER_AUTHENTICATION_REQUIRED: authtime 1689879992, testuser@IPA.EXAMPLE.COM for host/ipasrv1.ipa.example.com@IPA.EXAMPLE.COM, Required auth indicators not present in ticket: pkinit hardened
Jul 21 12:12:12 ipasrv1.ipa.example.com krb5kdc1985: closing down fd 11
Jul 21 12:12:19 ipasrv1.ipa.example.com krb5kdc1986: AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 192.168.2.4: NEEDED_PREAUTH: testuser@IPA.EXAMPLE.COM for krbtgt/IPA.EXAMPLE.COM@IPA.EXAMPLE.COM, Additional pre-authentication required
Jul 21 12:12:19 ipasrv1.ipa.example.com krb5kdc1986: closing down fd 11
Jul 21 12:12:19 ipasrv1.ipa.example.com krb5kdc1986: AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 192.168.2.4: ISSUE: authtime 1689955939, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, testuser@IPA.EXAMPLE.COM for krbtgt/IPA.EXAMPLE.COM@IPA.EXAMPLE.COM
Jul 21 12:12:19 ipasrv1.ipa.example.com krb5kdc1986: closing down fd 11
Jul 21 12:12:19 ipasrv1.ipa.example.com krb5kdc1986: TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 192.168.2.4: HIGHER_AUTHENTICATION_REQUIRED: authtime 1689955939, testuser@IPA.EXAMPLE.COM for host/ipasrv1.ipa.example.com@IPA.EXAMPLE.COM, Required auth indicators not present in ticket: pkinit hardened
Jul 21 12:12:19 ipasrv1.ipa.example.com krb5kdc1986: closing down fd 11
Jul 21 12:12:19 ipasrv1.ipa.example.com krb5kdc1986: TGS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 192.168.2.4: HIGHER_AUTHENTICATION_REQUIRED: authtime 1689955939, testuser@IPA.EXAMPLE.COM for host/ipasrv1.ipa.example.com@IPA.EXAMPLE.COM, Required auth indicators not present in ticket: pkinit hardened
Jul 21 12:12:19 ipasrv1.ipa.example.com krb5kdc1986: closing down fd 11
Jul 21 12:12:20 ipasrv1.ipa.example.com krb5kdc1986: AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 192.168.2.4: NEEDED_PREAUTH: testuser@IPA.EXAMPLE.COM for krbtgt/IPA.EXAMPLE.COM@IPA.EXAMPLE.COM, Additional pre-authentication required
Jul 21 12:12:20 ipasrv1.ipa.example.com krb5kdc1986: closing down fd 11
Jul 21 12:12:39 ipasrv1.ipa.example.com krb5kdc1985: AS_REQ (6 etypes {aes256-cts-hmac-sha1-96(18), aes256-cts-hmac-sha384-192(20), camellia256-cts-cmac(26), aes128-cts-hmac-sha256-128(19), aes128-cts-hmac-sha1-96(17), camellia128-cts-cmac(25)}) 192.168.2.4: ISSUE: authtime 1689955959, etypes {rep=aes256-cts-hmac-sha1-96(18), tkt=aes256-cts-hmac-sha1-96(18), ses=aes256-cts-hmac-sha1-96(18)}, testuser@IPA.EXAMPLE.COM for krbtgt/IPA.EXAMPLE.COM@IPA.EXAMPLE.COM
Jul 21 12:12:39 ipasrv1.ipa.example.com krb5kdc1985: closing down fd 11

---------- KRB5_TRACE=/dev/stderr ssh -v -----------

OpenSSH_9.0p1, OpenSSL 3.0.9 30 May 2023
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/04-ipa.conf
debug1: Executing command: ‘true’
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Reading configuration data /etc/ssh/ssh_config.d/99-local.conf
debug1: configuration requests final Match pass
debug1: re-parsing configuration
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Reading configuration data /etc/ssh/ssh_config.d/04-ipa.conf
debug1: Executing command: ‘true’
debug1: Reading configuration data /etc/ssh/ssh_config.d/50-redhat.conf
debug1: Reading configuration data /etc/crypto-policies/back-ends/openssh.config
debug1: Reading configuration data /etc/ssh/ssh_config.d/99-local.conf
debug1: Executing proxy command: exec /usr/bin/sss_ssh_knownhostsproxy -p 22 ipasrv1
debug1: identity file /home/testuser/.ssh/id_rsa type 0
debug1: identity file /home/testuser/.ssh/id_rsa-cert type -1
debug1: identity file /home/testuser/.ssh/id_ecdsa type -1
debug1: identity file /home/testuser/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/testuser/.ssh/id_ecdsa_sk type -1
debug1: identity file /home/testuser/.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /home/testuser/.ssh/id_ed25519 type 3
debug1: identity file /home/testuser/.ssh/id_ed25519-cert type -1
debug1: identity file /home/testuser/.ssh/id_ed25519_sk type -1
debug1: identity file /home/testuser/.ssh/id_ed25519_sk-cert type -1
debug1: identity file /home/testuser/.ssh/id_xmss type -1
debug1: identity file /home/testuser/.ssh/id_xmss-cert type -1
debug1: identity file /home/testuser/.ssh/id_dsa type -1
debug1: identity file /home/testuser/.ssh/id_dsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_9.0
debug1: Remote protocol version 2.0, remote software version OpenSSH_9.0
debug1: compat_banner: match: OpenSSH_9.0 pat OpenSSH* compat 0x04000000
debug1: Authenticating to ipasrv1:22 as ‘testuser’
debug1: load_hostkeys: fopen /home/testuser/.ssh/known_hosts2: No such file or directory
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: aes256-gcm@openssh.com MAC: compression: none
debug1: kex: client->server cipher: aes256-gcm@openssh.com MAC: compression: none
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: kex: curve25519-sha256 need=32 dh_need=32
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: SSH2_MSG_KEX_ECDH_REPLY received
debug1: Server host key: ssh-ed25519 SHA256:2LwdjNZeyFy3+64ci18s4JlqA7v1LOwsn9LgPBgDUEg
debug1: load_hostkeys: fopen /home/testuser/.ssh/known_hosts2: No such file or directory
debug1: Host ‘ipasrv1’ is known and matches the ED25519 host key.
debug1: Found key in /var/lib/sss/pubconf/known_hosts:1
Host key fingerprint is SHA256:2LwdjNZeyFy3+64ci18s4JlqA7v1LOwsn9LgPBgDUEg
±-[ED25519 256]–+

.Eo. |
o |
. . . |
. + * o . . |
… S B o . |
o.o+ + + o |
.+ + + o|
. Bo*= o * |
.O*o+.=oo|
±—[SHA256]-----+
debug1: rekey out after 4294967296 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 4294967296 blocks
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: agent returned 3 keys
debug1: Will attempt key: /home/testuser/.ssh/id_rsa RSA SHA256:wwy3FvT2LOg7q6ZxvFKGZSdhZ8xWQh4AmoVYDDZgPxM agent
debug1: Will attempt key: /home/testuser/.ssh/id_ed25519 ED25519 SHA256:RAtqjVfwIjU2k/vwG0MDleyGJKRtQf37xVMtEQ8uHvA agent
debug1: Will attempt key: /home/testuser/.config/gsconnect/private.pem RSA SHA256://nkWaqaVZ9A5/oogE4a1NWFQ+stA2EZP61XEx5Ax+g agent
debug1: Will attempt key: /home/testuser/.ssh/id_ecdsa
debug1: Will attempt key: /home/testuser/.ssh/id_ecdsa_sk
debug1: Will attempt key: /home/testuser/.ssh/id_ed25519_sk
debug1: Will attempt key: /home/testuser/.ssh/id_xmss
debug1: Will attempt key: /home/testuser/.ssh/id_dsa
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com>
debug1: kex_input_ext_info: publickey-hostbound@openssh.com=<0>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure. Minor code may provide more information
KDC policy rejects request

debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Next authentication method: publickey

I’m thinking the specific issue stems from “Required auth indicators not present in ticket: pkinit hardened”

6

Thanks. So this has nothing to do with PAC enforcement. Instead, you did enforce ‘pkinit’ on host/ipaserv1.... principal and that broke it to any user that did not use smartcard to obtain their own ticket.

The indicators on the host/ipasrerv1... principal are actually pkinit and hardened. hardened is allowing use of SPAKE pre-authentication. pkinit allows smartcard use. I think you have used IPA web UI or ipa host-mod --auth-ind={pkinit,hardened} ipaserv1.... to enforce these values. You should not really do that without making sure all your users are using compatible tickets.

Please see Unit 11: Kerberos ticket policy — FreeIPA 4.11-dev documentation for more details.

So my question now would be how did you obtain a Kerberos ticket for testuser user?

7

Just a regular kinit <user>. Before my rpmconf -a on the 17th, SPAKE hardening was working on all hosts, as evidenced by the old KDC logs. I hosed something that I had manually changed in the PAM or SSSD setup over the last 2 years. It all looked like it was all treated as the defaults now, so I merged the current defaults. As a result, all the hardening seems to have been lost.

It’s not the password policy. It’s something in the client config that is not allowing the SPAKE hardening to be instituted. As a work-around, I’ve removed hardening from all hosts and users, because it was preventing me from logging into the machines where I don’t have a local user account.

1 Like
8

Ok, so it is probably not an rpmconf issue. Let’s look at KRB5_TRACE=/dev/stderr kinit testuser first – this should show what pre-authentication mechanisms KDC and the client would negotiate about.

For example, on my system:

...
[16] 1690179435.004880: Preauthenticating using KDC method data
[16] 1690179435.004881: Processing preauth types: PA-PK-AS-REQ (16), PA-FX-FAST (136), PA-ETYPE-INFO2 (19), PA-PKINIT-KX (147), PA-SPAKE (151), PA-ENC-TIMESTAMP (2), PA_AS_FRESHNESS (150), PA-FX-COOKIE (133)
[16] 1690179435.004882: Selected etype info: etype aes256-cts, salt "H>78M!mT4!wWn&nV", params ""
[16] 1690179435.004883: Received cookie: MIT
[16] 1690179435.004884: PKINIT client has no configured identity; giving up
[16] 1690179435.004885: Preauth module pkinit (147) (info) returned: 0/Success
[16] 1690179435.004886: PKINIT client received freshness token from KDC
[16] 1690179435.004887: Preauth module pkinit (150) (info) returned: 0/Success
[16] 1690179435.004888: PKINIT client has no configured identity; giving up
[16] 1690179435.004889: Preauth module pkinit (16) (real) returned: 22/Invalid argument
[16] 1690179435.004890: Sending SPAKE support message
[16] 1690179435.004891: Preauth module spake (151) (real) returned: 0/Success
[16] 1690179435.004892: Produced preauth for next request: PA-FX-COOKIE (133), PA-SPAKE (151)

You can see that the client supports SPAKE and chose to use it. Even when there is no configuration, SPAKE should be usable in MIT Kerberos client if KDC supports it too.

9

Thanks, Alexander,

I’ll have to pick it up again when I get back from holiday. Is there a doc for setting up SPAKE in SSSD config? I think that’s likely what I screwed up with my accepting default config in rpmconf.

Best regards,
Eric

10

SPAKE is not set up in SSSD. It is Kerberos pre-authentication method, it needs Kerberos configuration and we provide one in freeipa via /etc/krb5.conf.d snippet file. Make sure the includedir statement for this folder exists in /etc/krb5.conf.