Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?
Greetings, * Ken Hornstein via Kerberos (kerberos@mit.edu) wrote: > >Has anyone else struggled with ssh clients being unable to delegate > >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. > > I'm a LITTLE confused as to what you're describing here. As I > understand you, the TRUSTED_FOR_DELEGATION flag doesn't appear on the > wire and only in the account properties. What, exactly, is there for a > client implementation to honor or not honor? If you're talking about > the OK-AS-DELEGATE flag in the Kerberos ticket, MIT Kerberos does > implement that flag (but ... the library already provides an option > to ignore that flag and it seems that by default it DOES ignore that > flag). It seems like some versions of Heimdal also will ignore the > OK-AS-DELEGATE flag by default and you can configure Heimdal to respect > that flag but I am unclear what the OS X Heimdal does. Calling that a > Microsoft extension is incorrect, though, as that appears in RFC 4120. > As for the thinking behind this flaga, well, the RFC provides what I > would consider a cognizant explanation: > > https://datatracker.ietf.org/doc/html/rfc4120#section-2.8 > > If you're talking about something else, I would be curious as to what > you mean. I didn't think ssh could utilize any of the S4U stuff > but it's always possible that could have changed. Before delving too deeply here ... frankly, I'd *strongly* encourage you to ignore what OSX comes with in terms of Kerberos "support" and push to move everything away from what OSX ships with and to instead use MIT Kerberos. In my experience, this is far from the only issue you're going to run into with the hacked up Kerberos from OSX and they don't seem to care to properly maintain it. Thanks, Stephen signature.asc Description: PGP signature Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?
>Has anyone else struggled with ssh clients being unable to delegate >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. I'm a LITTLE confused as to what you're describing here. As I understand you, the TRUSTED_FOR_DELEGATION flag doesn't appear on the wire and only in the account properties. What, exactly, is there for a client implementation to honor or not honor? If you're talking about the OK-AS-DELEGATE flag in the Kerberos ticket, MIT Kerberos does implement that flag (but ... the library already provides an option to ignore that flag and it seems that by default it DOES ignore that flag). It seems like some versions of Heimdal also will ignore the OK-AS-DELEGATE flag by default and you can configure Heimdal to respect that flag but I am unclear what the OS X Heimdal does. Calling that a Microsoft extension is incorrect, though, as that appears in RFC 4120. As for the thinking behind this flaga, well, the RFC provides what I would consider a cognizant explanation: https://datatracker.ietf.org/doc/html/rfc4120#section-2.8 If you're talking about something else, I would be curious as to what you mean. I didn't think ssh could utilize any of the S4U stuff but it's always possible that could have changed. --Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
honoring the TRUSTED_FOR_DELEGATION KDC MS-SFU Kerberos Protocol Extensions flag?
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