[35779] in Kerberos
Re: ACL for Constrained Delegation?
daemon@ATHENA.MIT.EDU (Rick van Rein)
Thu Feb 20 06:37:15 2014
Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Rick van Rein <rick@openfortress.nl>
In-Reply-To: <alpine.GSO.1.10.1402192147000.1213@multics.mit.edu>
Date: Thu, 20 Feb 2014 12:34:53 +0100
Message-Id: <F7AE882A-F8F7-4A81-9603-1ED665561DDD@openfortress.nl>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: kerberos@mit.edu
Content-Type: text/plain; charset="windows-1252"
Errors-To: kerberos-bounces@mit.edu
Content-Transfer-Encoding: 8bit
Hi Benjamin / MIT,
>> How would I setup these delegations, and only these delegations, with MIT Kerberos5?
>
> http://k5wiki.kerberos.org/wiki/Projects/ConstrainedDelegation notes that there is a krbAllowedToDelegateTo attribute that can be set in LDAP (manually) to limit delegation.
>
> I don't think I have an actual example handy.
Thanks for the pointer!
I looked into the LDAP specs for this attribute, and some questions remain. An example could give a working solution, but perhaps MIT should answer these questions by updating the project documentation page?
LOOKUP:
This refers to an LDAP attribute krbAllowedToDelegateTo. In the LDAP scheme, this is
defined as
> ##### A list of services to which a service principal can delegate.
> attributetype ( 1.3.6.1.4.1.5322.21.2.4
> NAME 'krbAllowedToDelegateTo'
> EQUALITY caseExactIA5Match
> SUBSTR caseExactSubstringsMatch
> SYNTAX 1.3.6.1.4.1.1466.115.121.1.26)
This attribute may be incorporated into the krbPrincipalAux auxiliary class, which
presumably is attached to krbPrincipal:
> ###### The principal data auxiliary class. Holds principal information
> ###### and is used to store principal information for Person, Service objects.
>
> objectclass ( 2.16.840.1.113719.1.301.6.8.1
> NAME 'krbPrincipalAux'
> SUP top
> AUXILIARY
> MAY ( krbPrincipalName $ krbCanonicalName $ krbUPEnabled $
> krbPrincipalKey $ krbTicketPolicyReference $ krbPrincipalExpiration $
> krbPasswordExpiration $ krbPwdPolicyReference $ krbPrincipalType $ krbPwdHistory $
> krbLastPwdChange $ krbLastAdminUnlock $ krbPrincipalAliases $ krbLastSuccessfulAuth $
> krbLastFailedAuth $ krbLoginFailedCount $ krbExtraData $ krbAllowedToDelegateTo ) )
QUESTIONS:
* These specifications do not clarify how the "list of services" is represented in the
attribute -- is it done through multiple krbAllowedToDelegateTo attributes (this is
permitted) or is there a format such as space-separation or comma-separation?
* These specifications do not clarify how "services" are declared -- probably through
their krbPrincipalName or krbCanonicalName? Or does that depend on the whether there
is a krbCanonicalName for the principal? Are abbreviated forms (dropping the @REALM
part) permitted/advised?
It’d be good to have these questions answered.
Thanks for any help you can give,
Rick van Rein
OpenFortress
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
