Re: ACL for Constrained Delegation?
Hello, Thanks for your responses. This arrangement seems to suggest that the delegation constraint is something that will be managed for all principals by the KDC explicitly, rather than the end user being able to decide (or even know?) what explicit delegations are being offered. Am i understanding this right? This is what I read into it too — and it is what I was looking (asking) for. Is there any mechanism for user-controllable delegation? (or perhaps more fundamentally, does this question even make sense, given the power held by the KDC already?) You probably know about the capabilities of forwardable and proxiable tickets, right? I was diverting away from that with my question, but: If a ticket is forwardable, then the KDC can issue a new ticket (with a different network address, if necessary) based on the forwardable ticket. This allows for authentication forwarding without requiring a password to be typed in again. For example, if a user with a forwardable TGT logs into a remote system, the KDC could issue a new TGT for that user with the netword address of the remote system, allowing authentication on that host to work as though the user were logged in locally. When the KDC creates a new ticket based on a forwardable ticket, it sets the forwarded flag on that new ticket. Any tickets that are created based on a ticket with the forwarded flag set will also have their forwarded flags set. A proxiable ticket is similar to a forwardable ticket in that it allows a service to take on the identity of the client. Unlike a forwardable ticket, however, a proxiable ticket is only issued for specific services. In other words, a ticket-granting ticket cannot be issued based on a ticket that is proxiable but not forwardable. A proxy ticket is one that was issued based on a proxiable ticket. Source: http://web.mit.edu/~kerberos/krb5-devel/doc/user/tkt_mgmt.html This doesn’t answer all my questions about these bits but it’s clearly not as tight as the KDC’s option, you’d be trusting everything behind a service instead of controlling who-may-do-what. To me, the tight control sounds a bit too tedious to be dealt with by end users, although from a security perspective I do agree with your wish (if I read it correctly) to do that. Constrained Delegation was introduced by Microsoft AFAIK, and their intention was to setup refined contorl in their Active Directory product. If you’d leave it to end users, you’d probably end up with security issues relating the local version of it — the registry or configuration files. It could easily end up being make-belief / feel-good security which isn’t actually as strong as you might think. Cheers, -Rick signature.asc Description: Message signed with OpenPGP using GPGMail Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: ACL for Constrained Delegation?
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
Re: ACL for Constrained Delegation?
On Wed, 2014-02-19 at 09:28 +0100, Rick van Rein wrote: Hello, I’m trying to understand how to configure Constrained Delegation in the KDC. I think I got the GSSAPI client side part, notably S4U2Proxy, but I can only seem to find proxy / proxiable flags in the KDC setup. And these don’t have undisputably clear semantics, from what I’ve read. Let’s say I want to setup webmail.example.com with permissions to access LDAP, IMAP and SMTP; however, sendmail.example.com can only access SMTP and contacts.example.com can only access LDAP; schematically: HTTP/webmail.example.com — ldap/ldap.example.com HTTP/webmail.example.com — imap/imap.example.com HTTP/webmail.example.com — smtp/smtp.example.com HTTP/sendmail.example.com — smtp/smtp.example.com HTTP/contacts.example.com — ldap/ldap.example.com How would I setup these delegations, and only these delegations, with MIT Kerberos5? Hi Rick, it is not currently really possible with Standard MIT. I have introduced a mechanism to handle this in the FreeIPA project (where we build our own DAL) and with Shawn we are working on bringing this to the standard MIT LDAP driver. Se the project page here: http://k5wiki.kerberos.org/wiki/Projects/KerberosDelegationACL If you want to help with this effort there is some work to do to implement thi in the current MIT LDAP code. Simo. -- Simo Sorce * Red Hat, Inc * New York Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: ACL for Constrained Delegation?
On 02/20/2014 06:34 AM, Rick van Rein wrote: * 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? It's done only through multiple attributes. * 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? Dropping the @REALM part should work if it is equal to the KDC realm. The value of krbAllowedToDelegateTo is parsed as a principal name using the standard parsing function, and compared to the target of the constrained delegation request. As for aliases, my reading of the code is that we have had some unintentional behavior changes across versions. * Up to 1.10, we compared against the server name in the request. * In 1.11, we compared against the canonical name of the target server. * In 1.12, we went back to comparing against the requested name. Although the change from 1.10 to 1.11 wasn't specifically intended, it might have been desirable in retrospect. For the moment, you'll need to list each service an intermediate server might request constrained delegation to. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
ACL for Constrained Delegation?
Thanks Greg, This clarifies the last pieces. Dare I suggest upgrading the (online) documentation? Thanks Simo, For adding an interesting future angle to this story -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: ACL for Constrained Delegation?
On Wed, Feb 19, 2014 at 11:41 PM, Daniel Kahn Gillmor d...@fifthhorseman.net wrote: This arrangement seems to suggest that the delegation constraint is something that will be managed for all principals by the KDC explicitly, rather than the end user being able to decide (or even know?) what explicit delegations are being offered. Am i understanding this right? That's exactly right. Is there any mechanism for user-controllable delegation? (or perhaps more fundamentally, does this question even make sense, given the power held by the KDC already?) The question very much makes sense. The original Kerberos design required that the applications have the final say on policy as to, e.g., cross-realm transit path policy and authorization in general. KDCs get to reject things (e.g., if there's no cross-realm trust relationship they must reject), and they get to indicate approval (e.g., TRANSIT-POLICY-CHECKED), but in principle they leave policy to the service application. I missed the cut-off for -00 Internet-Drafts for IETF89, so the following is as-yet not submitted, but it will be submitted soon, and its goal is to address this problem: https://raw.github.com/nicowilliams/kitten/master/gss-authzid.txt Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: ACL for Constrained Delegation?
On Thu, 2014-02-20 at 22:36 +0100, Rick van Rein wrote: Hello Simo, I had a look at the project page KerberosDelegationACL, and one thing struck me as odd about the specification. * lack of AllowToImpersonate means ALL clients can be impersonated. This appears non-intuitive to me; moreover, treating the “zero case” in a special way almost always leads to trouble, exceptions and security hazards. If not in code, then it usually confuses the security admin or surrounding scripts. I have no idea if this is too late, but the following follows IMHO a more consistent / logical line while retaining expressiveness: * lack of the Krb5DelegationACL class means that NO access control restrictions are applied * lack of AllowToImpersonate means NO clients can be impersonated * to impersonate ALL clients, use a suitable regex memberPrincipal FWIW :) Too late :-) In the default case you generally allow all in these situations. This compromise comes fro the fact that there is no real grouping mechanism in the KDC nor a way to experess the concept of all, a regex would not really do it nuless you are thinking of .* We could change the code so that you have to add the literal ALL maybe, I am not opposed, and could easily migrate FreeIPA users to that syntax. Shawn, what do you think ? Simo. -- Simo Sorce * Red Hat, Inc * New York Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: ACL for Constrained Delegation?
Hi Simo, In the default case you generally allow all in these situations. You mean, you’d like to be able to add the ACL class, no further attributes and then let everyone in? Why then mention the ACL, I wonder. The rest of the ACL design says “…and if none of the rules match, than the answer is NO” and the exception for “unless there is no ACL rule, then it is YES” is an inconsistency in the structure. Such flipping points are usually where error and dismay are born. This compromise comes fro the fact that there is no real grouping mechanism in the KDC nor a way to experess the concept of all, a regex would not really do it nuless you are thinking of .*” I was thinking of that regex, yes, but didn’t know what syntax to write down :) It’d be a group named ALL, in your example. We could change the code so that you have to add the literal ALL maybe, I am not opposed, and could easily migrate FreeIPA users to that syntax. That last bit is impressive :) -Rick Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: On acceptor credentials.
Greg, We relooked at our test setup and the 2 cases that you had cited in your previous response for why the hostname is ignored does not apply to us -- We neither specify ignore_acceptor_hostname anywhere (we don't have krb5.conf in the first place) nor do we have multiple principals in the keytab with the same key. (1) The hostname is, however, ignored. I'll explain my setup below. (2) We're unable to specify a desired name of the form cifs/ instance_n...@fully.qualified.domain.name. The gss_acquire_cred fails with the message *No key table entry found matching cifs/instance_name\@FULLY.QUALIFIED.DOMAIN.NAME@.* While importing the name we use GSS_C_NT_HOSTBASED_SERVICE oid. Our test setup: (1) A user representing our SMB server is created in AD in the domain MY.TEST.DOMAIN. It has 2 service principal names assigned, viz., cifs/server_name and cifs/bogus_name. (2) Both the server_name and bogus_name resolve to the IP of our SMB server. (3) The client is a Windows machine. We always do klist purge before every experiment to clear the cached tickets. (4) On the SMB server side, on start up, we register the keytab, import the name cifs/server_name, acquire the creds and later use the creds in the gss_accept_security_context calls. (5) Doing a klist on the keytab at the server side shows the following and only the following for the principal name: cifs/server_n...@my.test.DOMAIN.There are of course multiple entries for the 5 common encryption methods. With this setup here is what I observe. Assume that the SMB share with the name my_share exists. *Case 1:* Windows client domain: MY.TEST.DOMAIN dir \\server_name\my_share Works as expected. *Case 2:* Windows client domain: MY.TEST.DOMAIN dir \\bogus_name\my_share Works. Not expected. Seems that the hostname part is ignored. *Case 3:* Windows client domain: MY_SECOND.TEST.DOMAIN dir \\server_name\my_share Works. May be expected because I could not succeed specifying the realm name while specifying the desired_name to gss_acquire_cred method. *Case 4:* Windows client domain: MY_SECOND.TEST.DOMAIN dir \\bogus_name\my_share Works. But not expected for the same reason as Case 2. We are using KRB 5 Release 1.12.1 with the patch that you gave us for the bug at *http://krbdev.mit.edu/rt/Ticket/Display.html?id=7858 http://krbdev.mit.edu/rt/Ticket/Display.html?id=7858* Can you please clarify? Thanks a lot Prakash N | 408 771 4273 On Wed, Feb 19, 2014 at 9:17 PM, Greg Hudson ghud...@mit.edu wrote: On 02/19/2014 10:19 PM, Prakash Narayanaswamy wrote: While testing the kerberized SMB server, we observed the following: Even if the *gss_acquire_cred* method is passed *both* the service name and host name in the form *service@hostname* for the *desired_name* parameter, the hostname part is ignored during authentication. I cannot reproduce this behavior; in my tests, if a hostname is specified in the desired_name field, it properly restricts which keytab principals can be used. Can you give more detail on what you are observing? (1) When can the above situation arise? As far as I know, only if: * You specify ignore_acceptor_hostname in krb5.conf, or * You have entries for multiple principals in the keytab which share the same key. Because of service aliases, we generally ignore the principal the initiator states that it is trying to authenticate to, and instead just check whether we can decrypt the ticket with any key in the keytab which matches the specified acceptor name. See: http://k5wiki.kerberos.org/wiki/Projects/Aliases (2) When we don't enable AES-128/AES-256 encryption in the Windows 2012 AD for the user account representing our SMB server (with proper SPN set) in the AD domain, we observe that even the domain name/realm name part is ignored during authentication. Is this expected? Since a host-based GSSAPI name does not specify a Kerberos realm, it does not restrict the realm of keytab entries which can be used to decrypt the ticket. (3) We don't see any need for the krb5.conf file on the Linux machine that runs our SMB server. We register the keytab file using *krb5_gss_register_acceptor_identity *method*. *Do we really need the krb5.conf file? What do I lose by not having the krb5.conf in our setup? I don't believe you need a krb5.conf file for a GSS server application. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: On acceptor credentials.
On 02/20/2014 08:28 PM, Prakash Narayanaswamy wrote: (2) We're unable to specify a desired name of the form cifs/instance_n...@fully.qualified.domain.name mailto:instance_n...@fully.qualified.domain.name. The gss_acquire_cred fails with the message /No key table entry found matching cifs/instance_name\@FULLY.QUALIFIED.DOMAIN.NAME@./ GSS host-based names are of the form service or service@host. You cannot specify a realm, and '/' is not a separator. If you want to import a Kerberos principal name, use GSS_KRB5_NT_PRINCIPAL_NAME. (1) A user representing our SMB server is created in AD in the domain MY.TEST.DOMAIN. It has 2 service principal names assigned, viz., cifs/server_name and cifs/bogus_name. I believe in this setup, cifs/server_name and cifs/bogus_name will have the same keys. (4) On the SMB server side, on start up, we register the keytab, import the name cifs/server_name, acquire the creds and later use the creds in the gss_accept_security_context calls. You're importing cifs/server_name as a host-based name? I would expect that to fail with No key table entry found matching cifs\/server_name/@. (5) Doing a klist on the keytab at the server side shows the following and only the following for the principal name: cifs/server_n...@my.test.DOMAIN. There are of course multiple entries for the 5 common encryption methods. If those are the only keys present in the keytab, then there is no way that any other keys could be used to decrypt the ticket. So I think case 2 is succeeding because cifs/bogus_name has the same keys as cifs/server_name, and cases 3 and 4 are succeeding because the client is cross-realm authenticating to MY.TEST.DOMAIN. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: ACL for Constrained Delegation?
On Fri, 2014-02-21 at 00:05 +0100, Rick van Rein wrote: Hi Simo, In the default case you generally allow all in these situations. You mean, you’d like to be able to add the ACL class, no further attributes and then let everyone in? Why then mention the ACL, I wonder. No, the only attribute that is allowed to be missing is AllowedToImpersonate. If any other one is missing you get no authorization. The rest of the ACL design says “…and if none of the rules match, than the answer is NO” and the exception for “unless there is no ACL rule, then it is YES” is an inconsistency in the structure. Such flipping points are usually where error and dismay are born. You misunderstood how this works, if there is no target or member principal there is nothing to match, so no ACL apply so no access is granted. This compromise comes fro the fact that there is no real grouping mechanism in the KDC nor a way to experess the concept of all, a regex would not really do it nuless you are thinking of .*” I was thinking of that regex, yes, but didn’t know what syntax to write down :) It’d be a group named ALL, in your example. Unfortunately AlowToImpersonate is not a free form field, we'd need to add something else. We could change the code so that you have to add the literal ALL maybe, I am not opposed, and could easily migrate FreeIPA users to that syntax. That last bit is impressive :) Unfortunately I kind of have to take it back. I forgot that AllowToImpersonate has actually DN syntax, so you cannot simply store ALL in there. We would need to standardize a DN that represent all users or add a separate attribute to define 'categories' as an additional filter. This was the actual reason why the default is 'all' when it is missing, mostly because all our use cases allow a specific service to proxy any users but only for specific targets. After all it makes no sense to have no allowed clients (why would you create an ACI if that were the case, absence of an ACI already prevents access). HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
