[39412] in Kerberos
honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol
daemon@ATHENA.MIT.EDU (James Ralston)
Mon Apr 15 18:19:51 2024
MIME-Version: 1.0
From: James Ralston <ralston@pobox.com>
Date: Mon, 15 Apr 2024 18:19:22 -0400
Message-ID: <CAEkxbZuz1h7Ef4N5nz3teb8vcTxTE6iBUZC+TYssUcayKHhXQQ@mail.gmail.com>
To: kerberos@mit.edu
Content-Type: text/plain; charset="utf-8"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Has anyone else struggled with ssh clients being unable to delegate
Kerberos credentials to a remote host because the Kerberos library
that the ssh client uses implements the MS-SFU Kerberos Protocol
Extensions and therefore honors the TRUSTED_FOR_DELEGATION flag of the
target host?
More generally: does anyone know exactly what Microsoft was thinking
when they dreamed up this flag?
As far as we can tell, for reasons we still have been unable to
fathom, Microsoft decided that simply permitting credential delegation
based on whether the TGT has the forwardable flag set was
insufficient. Instead, Microsoft implemented a new flag in the MS-SFU
Kerberos Protocol Extensions, TRUSTED_FOR_DELEGATION. The flag is a
property of the service principal of the *target* host: if the target
host does not have the TRUSTED_FOR_DELEGATION flag set in the
userAccountControl attribute of the host’s machine account in Active
Directory, then if the Kerberos library that the ssh client uses
honors the MS-SFU Kerberos Protocol Extensions and honors the
TRUSTED_FOR_DELEGATION flag, it will refuse to delegate the user’s
credentials to the target host, *even* if all other settings would
permit credential delegation.
Because MIT Kerberos doesn’t honor the TRUSTED_FOR_DELEGATION flag (or
any part of the MS-SFU Kerberos Protocol Extensions?), our folks who
use only Linux systems have never noticed an issue. But we have an
increasing number of Mac users who wish to ssh from their Macs to
Linux hosts, and since Macs use Heimdal, which *does* implement the
MS-SFU Kerberos Protocol Extensions and therefore honors the
TRUSTED_FOR_DELEGATION flag, Mac users cannot ssh to Linux hosts and
delegate their credentials. Because we use NFS-mounted home
directories with RPCGSS security, this means that Mac users get
"Permission denied" errors when accessing their home directories if
they use gssapi-with-mic or gssapi-keyex ssh authentication to Linux
hosts: they can login via gssapi-with-mic or gssapi-keyex, but without
the credential, they cannot access their home directories.
(The irony here is that the only way for Mac users to login to Linux
hosts and actually have a home directory is if they perform
gssapi-with-mic/gssapi-keyex authentication and then manually run
kinit, or else use an ssh authentication mechanism that performs kinit
explicitly as part of the authentication (password or
keyboard-interaction auth). If Microsoft’s goal for the
TRUSTED_FOR_DELEGATION flag was to prevent users from passing their
credentials to a remote host that might be operated by a grey-hat or
otherwise not-completely-trusted administrator, then congratulations:
by attempting to prevent exposure of the credential to that
not-completely-trusted admin, you’ve only guaranteed that users must
now expose their *actual passwords* instead.)
Once we finally figured out that it was the TRUSTED_FOR_DELEGATION
flag that was preventing Mac users from passing credentials, we asked
our Active Directory administrators to grant our Linux admins the
ability to set the TRUSTED_FOR_DELEGATION flag for Linux hosts, so
that we can set the flag when we create a new Linux host and join it
to AD. But our AD admins are balking, because Microsoft’s
documentation is abysmally unclear in explaining the greater security
ramifications of setting the TRUSTED_FOR_DELEGATION for a host.
Our tentative conclusion at this point is that the
TRUSTED_FOR_DELEGATION flag was a fantastically stupid idea on
Microsoft’s part and the correct course of action is to work-around
its existence as best we can: by ensuring that the flag is set on the
AD host machine account on every Linux host which accepts remote ssh
logins. As far as we can discern, the only thing this will enable is
the ability for anyone to delegate a forwardable Kerberos credential
to the host—which is exactly what we want.
Have we misunderstood the goal of the TRUSTED_FOR_DELEGATION flag?
Does anyone know of any security ramifications of enabling it that we
have not considered?
(As a side note, if MIT Kerberos ever decides to implement/honor the
TRUSTED_FOR_DELEGATION flag, we fervently hope that the implementation
also creates a new krb5.conf flag to ignore it; e.g.,
honor_trusted_for_delegation_die_die_die.)
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
