As can be seen e.g. from http://support.microsoft.com/kb/266080 Windows clients check the ok_as_delegate flag on the Kerberos service ticket to determine if the user credentials can be forwarded/delegated to the specific server or not.
A typical use case is a ssh terminal login with putty where a user wants his Kerberos credentials forwarded to the Linux client automatically. It looks that this only works reliable with Windows default settings if the ok_as_delegate flag is set.
Currently is it only possible to set this flag via kadmin.local.
Since this flag has to be set per service principal it would be nice if a method can be added to make bulk assignments of this flag. Alternatively it might make sense to set it by default for all services and hosts?
No a default is not ok, you do not want to allow forwarding credentials by default.
I agree, I do not like having this as a default either. I only mentioned it because afaik there is no similar functionality in the Linux ssh client, i.e. whenever you ask with the '-K' option to forward/delegate a ticket (and the ticket is forwardable) the credentials are send to any target host. So the Linux client behaves as the flag is always set.
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=910897
How-to test:
Since it is currently not clear how this is implemented in the CLI or Web UI I cannot say how to set the flag. But if it is set, e.g. for the host service principal host/hostname.domain.name/DOMAIN.NAME, it can be verified in one of the following ways:
kadmin.local: OK_AS_DELEGATE should be listed in the attribute list
Attributes: REQUIRES_PRE_AUTH OK_AS_DELEGATE
klist: an 'O' (caps o) should be listed in the credential flags
... 02/14/13 18:34:20 02/15/13 17:44:53 host/hostname.domain.name/DOMAIN.NAME Flags: FATO ...
putty.exe: setup trust to an AD domain and use putty.exe on a Windows client from the AD domain to connect to hostname.domain.name. In the configuration tree select Connection->SSH->Auth->GSSAPI and check the 'Allow GSSAPI credential delegation'. If you now connect with GSSAPI authentication and call klist in the opened terminal, the Windows credentials should be listed.
Move all uncompleted tickets to next month bucket.
It doesn't look like python-krbV exposes a way to set flags. We could consider this a rare operation and fork out to kadmin.local in the worst case but we'd then have to carefully handle injection attacks with oddly-formed principals (and the overhead of the fork()).
Why not use LDAP directly? Currently we handle the Kerberos principal flags/attribute as an opaque bit field, but since we have the control over the kdb backend we are free to introduce even new LDAP attributes to represent different flags we are interested in if this would make the usage from the IPA framework easier.
I think it also make sense to take a broader view how to handle Kerberos flags and attributes in general. E.g. it might be necessary to set specific flags to allow OTP token usage.
We just had a conversation about OTP flags too. The design will follow but the concept and reasoning is similar.
I completely agree with the approach proposed in the current design.
Honza volunteered to check this one.
master: 5f26d2c
Web UI added:
master: 5af3b14
Metadata Update from @sbose: - Issue assigned to jcholast - Issue set to the milestone: FreeIPA 3.2 - 2013/03
Login to comment on this ticket.