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