Re: Confusion about delegation
On Fri, Feb 01, 2019 at 02:54:39PM -0500, John Byrne wrote: > Thanks, this helps a lot. > > I think the reason it appeared to be working for me when I used the wrong > name HTTP/www.example.com is because I incorrectly had that principal in > the keytab of the other service. An in the second case, where I omitted the > creds altogether, you are correct, it just authenticated as HTTP/ > www.example.com and not kerbtestjohn. > > So, I have set ok_to_auth_as_delegate in my KDC for the intermediate > service principal HTTP/www.example.com, but now I'm getting this error on > the step() call: > > Feb 01 14:47:14 localhost.localdomain krb5kdc[6376](info): TGS_REQ (8 > etypes {18 17 20 19 16 23 25 26}) 192.168.0.22: NOT_ALLOWED_TO_DELEGATE: > authtime 0, HTTP/www.example@example.com for HTTP/ > datastore.example@example.com, Plugin does not support the operation > > I couldn't find any info on this, but I did some reading in the source code > and it looks like the necessary function 'check_allowed_to_delegate' is > only defined for the ldap plugin. Have I got that right - I have to use > ldap to get this feature to work with the krb5 server? Or is there another > way? The only in-tree module that supports constrained elegation, yes. (At least one out-of-tree module also exists, though presumably you would already know if that was one you wanted.) -Ben Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Confusion about delegation
Thanks, this helps a lot. I think the reason it appeared to be working for me when I used the wrong name HTTP/www.example.com is because I incorrectly had that principal in the keytab of the other service. An in the second case, where I omitted the creds altogether, you are correct, it just authenticated as HTTP/ www.example.com and not kerbtestjohn. So, I have set ok_to_auth_as_delegate in my KDC for the intermediate service principal HTTP/www.example.com, but now I'm getting this error on the step() call: Feb 01 14:47:14 localhost.localdomain krb5kdc[6376](info): TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) 192.168.0.22: NOT_ALLOWED_TO_DELEGATE: authtime 0, HTTP/www.example@example.com for HTTP/ datastore.example@example.com, Plugin does not support the operation I couldn't find any info on this, but I did some reading in the source code and it looks like the necessary function 'check_allowed_to_delegate' is only defined for the ldap plugin. Have I got that right - I have to use ldap to get this feature to work with the krb5 server? Or is there another way? Thanks again for the info on this! -John On Fri, Feb 1, 2019 at 12:26 PM Greg Hudson wrote: > On 1/31/19 1:32 PM, John Byrne wrote: > > The client_ctx.step() call returns this error: gssapi.raw.misc.GSSError: > > Major (851968): Unspecified GSS failure. Minor code may provide more > > information, Minor (2529639053): Matching credential not found > > This is a bad error message, and we have an open ticket noting the need > to improve it: > > http://krbdev.mit.edu/rt/Ticket/Display.html?id=8586 > > Because you haven't set the ok_to_auth_as_delegate bit on > HTTP/www.example.com, the KDC issues a non-forwardable service ticket in > the creds.impersonate() step. The GSSAPI layer stores this as a regular > cred object containing a user -> HTTP/www.example.com service ticket, > not an impersonator cred. Such a credential can be interrogated for > name attributes to get PAC information (if it came from a KDC supporting > PACs) or to authenticate to the intermediate service itself, but it > can't be used to authenticate to any other service. > > When gss_init_sec_context() tries to authenticate with this credential, > it can't find either a client -> target or client -> krbtgt/REALM > credential, so it fails with the uninformative error message. > > Release 1.16 added the ability to query a credential for whether it is > an impersonator credential, as noted in the documentation page you > referenced. > > > I've made sure that the target_name principal is in the default keytab > > Only the target service should have a target_name keytab entry. Giving > out that keytab to other parties poses a security issue, allowing those > parties to impersonate (in the attacker sense, not the S4U2Proxy sense) > the target service. > > > The surprising thing is that if I initialize the context with the other > > name instead (HTTP/www.example.com), then this code works perfectly, and > > authenticates me as 'kerbtestjohn' to www.datastore.com. > > I would expect this to authenticate from kerbtestjohn to > HTTP/www.example.com. How would it authenticate to www.datastore.com if > you didn't ask gss_init_sec_context() to do so? > > > Even stranger, if I omit the proxy_creds from the > > SecurityContext, then it also works, using either of the 2 service names. > > So I can impersonate users without the proxy creds!? Shouldn't that be > > rejected? > > If you omit proxy_creds, then it should authenticate from whatever > client is in the default ccache (probably HTTP/www.example.com) to the > target service. It shouldn't authenticate as krbtestjohn. > Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: Confusion about delegation
On 1/31/19 1:32 PM, John Byrne wrote: > The client_ctx.step() call returns this error: gssapi.raw.misc.GSSError: > Major (851968): Unspecified GSS failure. Minor code may provide more > information, Minor (2529639053): Matching credential not found This is a bad error message, and we have an open ticket noting the need to improve it: http://krbdev.mit.edu/rt/Ticket/Display.html?id=8586 Because you haven't set the ok_to_auth_as_delegate bit on HTTP/www.example.com, the KDC issues a non-forwardable service ticket in the creds.impersonate() step. The GSSAPI layer stores this as a regular cred object containing a user -> HTTP/www.example.com service ticket, not an impersonator cred. Such a credential can be interrogated for name attributes to get PAC information (if it came from a KDC supporting PACs) or to authenticate to the intermediate service itself, but it can't be used to authenticate to any other service. When gss_init_sec_context() tries to authenticate with this credential, it can't find either a client -> target or client -> krbtgt/REALM credential, so it fails with the uninformative error message. Release 1.16 added the ability to query a credential for whether it is an impersonator credential, as noted in the documentation page you referenced. > I've made sure that the target_name principal is in the default keytab Only the target service should have a target_name keytab entry. Giving out that keytab to other parties poses a security issue, allowing those parties to impersonate (in the attacker sense, not the S4U2Proxy sense) the target service. > The surprising thing is that if I initialize the context with the other > name instead (HTTP/www.example.com), then this code works perfectly, and > authenticates me as 'kerbtestjohn' to www.datastore.com. I would expect this to authenticate from kerbtestjohn to HTTP/www.example.com. How would it authenticate to www.datastore.com if you didn't ask gss_init_sec_context() to do so? > Even stranger, if I omit the proxy_creds from the > SecurityContext, then it also works, using either of the 2 service names. > So I can impersonate users without the proxy creds!? Shouldn't that be > rejected? If you omit proxy_creds, then it should authenticate from whatever client is in the default ccache (probably HTTP/www.example.com) to the target service. It shouldn't authenticate as krbtestjohn. Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
KDC 1.15.1 - addprinc random failure
Hi all. I run KDC 1.15.1. At the host, I use kadmin.local to add a principle. Very strange that my first attempt failed silently while the second attempt succeeded. Here are the steps: [root@gamma-hactive ~]# kadmin.local Authenticating as principal hdfs/ad...@example.com with password. kadmin.local: addprinc yegui WARNING: no policy specified for ye...@example.com; defaulting to no policy Enter password for principal "ye...@example.com": Re-enter password for principal "ye...@example.com": Principal "ye...@example.com" created. kadmin.local: getprinc yegui get_principal: Principal does not exist while retrieving "ye...@example.com ". kadmin.local: addprinc yegui WARNING: no policy specified for ye...@example.com; defaulting to no policy Enter password for principal "ye...@example.com": Re-enter password for principal "ye...@example.com": Principal "ye...@example.com" created. kadmin.local: getprinc yegui Principal: ye...@example.com Expiration date: [never] Last password change: Fri Feb 01 16:00:09 UTC 2019 Password expiration date: [never] Maximum ticket life: 1 day 00:00:00 Maximum renewable life: 7 days 00:00:00 Last modified: Fri Feb 01 16:00:09 UTC 2019 (hdfs/ad...@example.com) Last successful authentication: [never] Last failed authentication: [never] Failed password attempts: 0 Number of keys: 4 Key: vno 1, aes256-cts-hmac-sha1-96 Key: vno 1, aes128-cts-hmac-sha1-96 Key: vno 1, des3-cbc-sha1 Key: vno 1, arcfour-hmac MKey: vno 1 Attributes: REQUIRES_PRE_AUTH Policy: [none] Any idea? Thanks! Yegui Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos