Re: Query regarding S4U2Self protocol extension

[Isaac Boukris]

Hi Vipul,

On Wed, Aug 25, 2021 at 6:12 AM Vipul Mehta  wrote:
>
> I have one more query on this based on following statement in microsoft 
> document:
>
> "If a non forwardable S4U2self-generated user's service ticket for a 
> nonsensitive user is used, then the SFU client SHOULD<11> locate a 
> DS_BEHAVIOR_WIN2012 DC ([MS-KILE] section 3.2.5.3) to send the request."
>
> https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sfu/ddb2cafd-1f01-4834-b52a-d4a5b34cd960
>
> Is this implemented in the MIT Kerberos client ?

No it isn't, we just assume all the KDCs support RBCD.

I think this has become less relevant now that RBCD requires the
forwardable flag as well [1]. I guess this doc should be updated too.

[1] https://lists.samba.org/archive/cifs-protocol/2021-July/003608.html

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Query regarding S4U2Self protocol extension

[Isaac Boukris]

On Wed, Jul 28, 2021 at 1:46 PM Vipul Mehta  wrote:
>
> Now we know that behavior is unified and S4U2Self ticket should be 
> forwardable to avoid vulnerability, i think we can add a check in MIT 
> Kerberos API itself such that before sending S4U2Proxy TGS-REQ to KDC, if 
> ticket is not forwardable it will fail in client itself.
>
> I can see that JDK has this check:
> https://github.com/openjdk/jdk/blob/739769c8fc4b496f08a92225a12d07414537b6c0/src/java.security.jgss/share/classes/sun/security/krb5/internal/CredentialsUtil.java
>  -> line 105

MIT used to have that as well before RBCD was added, although I don't
think this was ever necessary, as that check should be done in the
KDC. Also disabling NonForwardableDelegation can be a valid usage when
relying on SIDs and not using protected-group, as in the original RBCD
design:

https://github.com/MicrosoftDocs/windowsserverdocs/blob/master/WindowsServerDocs/security/kerberos/kerberos-constrained-delegation-overview.md


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Query regarding S4U2Self protocol extension

[Isaac Boukris]

On Wed, Jul 28, 2021 at 11:10 AM Vipul Mehta  wrote:
>
> I have windows server 2012 R2 with all the security updates installed and did 
> some tests:
>
> Resource Based Constrained Delegation configured for Service A in Service B 
> account.
>
> Case 1) Service A :  trustedToAuthForDelegation = false and non-empty 
> msds-AllowedToDelegateTo -> S42U2Self ticket didn't have a forwardable flag 
> and subsequent S4U2Proxy failed.

That's expected because the default of 'NonForwardableDelegation' is
enabled I think, so RBCD requires forwardable flag now, if you set
NonForwardableDelegation to disabled (that is to 1 ..), then RBCD
S4U2Proxy will continue to work as before the update.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Query regarding S4U2Self protocol extension

[Isaac Boukris]

On Tue, Jul 27, 2021 at 6:54 PM Vipul Mehta  wrote:
>
> Need a clarification:
> MIT KDC will set the forwardable flag in S4U2Self ticket in following cases
> (provided account is not sensitive and not part of secure group):
> 1) ok_to_auth_as_delegate is true
> or
> 2) ok_to_auth_as_delegate is false and Service TGT has forwardable flag set

In case of 2) we'll also check that
'ServicesAllowedToSendForwardedTicketsTo' is empty like in the doc, I
was just suggesting implementation wise that we do it in the plugin
instead of the kdc itself, that is when the principal is retrieved the
plugin will add 'ok_to_auth_as_delegate' if the
'ServicesAllowedToSendForwardedTicketsTo' is empty.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Query regarding S4U2Self protocol extension

[Isaac Boukris]

Note, for MIT I think we don't need the NonForwardableDelegation flag,
just need to behave as enabled and let the plugin's get_principal()
add 'TrustedToAuthForDelegation' if the list is empty. This could
simplify the KDC code as we don't need to check the PAC's
not-delegated flag, although some tests would need updating.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Query regarding S4U2Self protocol extension

[Isaac Boukris]

On Tue, Jul 27, 2021 at 1:17 PM Isaac Boukris  wrote:
>
> On Mon, Jul 26, 2021 at 10:17 PM Greg Hudson  wrote:
> >
> > On 7/23/21 4:38 PM, Vipul Mehta wrote:
> > > I did some testing with Windows KDC and it will set forwardable flag in
> > > S4U2Self service ticket in either of the following cases:
> > >
> > > 1) TrustedToAuthForDelegation is set to true in Service A account.
> > >
> > > 2) Service A TGT used in S4U2Self has forwardable flag set and
> > > msDS-AllowedToDelegateTo list is empty on Service A account.
> > > I am not able to understand why msDS-AllowedToDelegateTo needs to be empty
> > > in the 2nd case.
> > >
> > > Is the behavior of MIT KDC the same as Windows KDC ?
> >
> > We have an analog of the TrustedToAuthForDelegation flag, called
> > ok_to_auth_as_delegate.  We don't check for an empty
> > allowed-to-delegate-to list.
> ...
> > https://support.microsoft.com/en-us/topic/managing-deployment-of-rbcd-protected-user-changes-for-cve-2020-16996-9a59a49f-20b9-a292-f205-da9da0ff24d3
>
> Now that I read this again, and read again the "Additional
> considerations" section in that link, I think what might happened with
> this change is that now RBCD requires the forwardable flag but any
> service with an empty msDS-AllowedToDelegateTo to list, as Vipul
> remarked, gets treated as TrustedToAuthForDelegation and gets the flag
> (presumably, unless the client is in the protected-users group or has
> the not-delegated flag).
>
> I'll run some tests and check it with dochelp.

Yes, now any service is treated as TrustedToAuthForDelegation unless
it has a none-empty msDS-AllowedToDelegateTo list, on the other hand
with
NonForwardableDelegation set to enabled RBCD is no longer allowed with
non-forwardable tickets (this would be the default soon, or it is
already).

I guess that cross-realm would also be required to be forwardable,
which means the other realm is trusted for that, I'll try to test it.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Query regarding S4U2Self protocol extension

[Isaac Boukris]

On Mon, Jul 26, 2021 at 10:17 PM Greg Hudson  wrote:
>
> On 7/23/21 4:38 PM, Vipul Mehta wrote:
> > I did some testing with Windows KDC and it will set forwardable flag in
> > S4U2Self service ticket in either of the following cases:
> >
> > 1) TrustedToAuthForDelegation is set to true in Service A account.
> >
> > 2) Service A TGT used in S4U2Self has forwardable flag set and
> > msDS-AllowedToDelegateTo list is empty on Service A account.
> > I am not able to understand why msDS-AllowedToDelegateTo needs to be empty
> > in the 2nd case.
> >
> > Is the behavior of MIT KDC the same as Windows KDC ?
>
> We have an analog of the TrustedToAuthForDelegation flag, called
> ok_to_auth_as_delegate.  We don't check for an empty
> allowed-to-delegate-to list.
...
> https://support.microsoft.com/en-us/topic/managing-deployment-of-rbcd-protected-user-changes-for-cve-2020-16996-9a59a49f-20b9-a292-f205-da9da0ff24d3

Now that I read this again, and read again the "Additional
considerations" section in that link, I think what might happened with
this change is that now RBCD requires the forwardable flag but any
service with an empty msDS-AllowedToDelegateTo to list, as Vipul
remarked, gets treated as TrustedToAuthForDelegation and gets the flag
(presumably, unless the client is in the protected-users group or has
the not-delegated flag).

I'll run some tests and check it with dochelp.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos Database Sync with Sub-Domains

[Isaac Boukris]

On Tue, Jul 14, 2020 at 3:55 PM Jonathan Towles  wrote:
>
> I got it to work if I reference the UPN in the command.
>
> The application is doing AS-Requests.

Note that S4U2Self would also use AS-REQ for the client-referrals step
(when enterprise names are used), and then switch to TGS-REQ for the
actual S4U2Self request.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos Database Sync with Sub-Domains

[Isaac Boukris]

On Tue, Jul 14, 2020 at 3:37 PM Jonathan Towles  wrote:
>
> I'm working with an application inside of a Docker container that uses GSS to 
> do Kerberos Constrained Delegation.

Constrained Delegation (S4U2Proxy) is a way to get a service ticket,
but the client name is determined in a preceding step of getting an
initial ticket, which can be done in two ways (only), kinit (AS
request) or protocol-transition (S4U2Self), and they both support the
use of enterprise names (using client-referrals).

> I'm guessing they need to augment the code.

Could be, in recent krb5 libs you can make use of
GSS_KRB5_NT_ENTERPRISE_NAME in gssapi.

> Doing some testing via kinit, I have found that kinit -E only works if the 
> account lives in the parent domain.
>
> If I try to do a kinit -E with their samaccountname or email address, it says 
> they're not found if they are in a child domain.

It should generally work with the UPNs (or samaccountname@realm).

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos Database Sync with Sub-Domains

[Isaac Boukris]

On Tue, Jul 14, 2020 at 3:22 PM Jonathan Towles  wrote:
>
> So by using enterprise principal names, you can essentially point it at the 
> parent domain KDC, and it can get a ticket for even users in the sub-domains?

Client-referrals are used to locate the realm, see details in RFC 6806.

> That's only something that can be done in the GSS config right? You can't do 
> it in the KRB5.conf file?

For kinit, you just need to pass the '-E' flag, no conf involved.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos Database Sync with Sub-Domains

[Isaac Boukris]

On Tue, Jul 14, 2020 at 2:23 PM Jonathan Towles  wrote:
>
> Hi Bryan,
>
> I think essentially the issue/question that comes up is what happens when you 
> have say 5 domains, and you have people with the say domain name in those 5 
> domains.
>
> So here's the use case:
>
> Let's say I have 5 domains:
>
> Synterex.com
> Boston.synterex.com
> Ny.synterex.com
> Miami.synterex.com
> Dallas.synterex.com
>
> When I move to Office 365, I have to make my SMTP and UPN match. This will 
> now make it so everyone in all 5 domains has a UPN ending in synterex.com

You can use enterprise principal name to work with UPNs, e.g. kinit -E
u...@synterex.com (the realm will get canonicalized, and with -C the
name too).

> So, now I have an issue where you have user accounts in 5 domains all with 
> the same REALM of SYNTEREX.COM.
>
> In this situation, there's only two ways this can still work:
>
> 1. You move everyone to the synterex.com domain which can be a real nightmare
> 2. You find a way to point all authentication against the Synterex.com KDC 
> and still be able to get tickets for users living in the sub-domains
>
> I'm not sure if you can actually make #2 work or not. When I have tried, I 
> get user not found in the database issues.
>
> Jon Towles
> CTO, Synterex
> (m) 978-609-5545
>
>
>
> -Original Message-
> From: Bryan Mesich 
> Sent: Monday, July 13, 2020 11:01 PM
> To: Jonathan Towles 
> Cc: kerberos@mit.edu
> Subject: Re: Kerberos Database Sync with Sub-Domains
>
> On Mon, Jul 13, 2020 at 06:58:39PM +, Jonathan Towles wrote:
> > Hi All,
>
> Hello,
>
> > I wanted to ask a question that I have been unable to get clear information 
> > on.
> >
> > Is it technically or functionally possible to get a Kerberos ticket for 
> > someone in the sub-domain against the parent domain
> >
> > Example:
> > User j...@boston.synterex.com wants to get 
> > a Kerberos ticket against dc01.synterex.com but will fail because that user 
> > is not found in the database on that Domain Controller.
>
> It is unclear to me based on your example if you are using one or
> multiple realms in your environment.  Either way, you would want to have
> a properly configured krb5.conf that contains the Kerberos Realm(s) and
> domain-to-realm mapping information.  A single realm might look like the
> following:
>
> [realms]
>   SYNTEREC.COM = {
> kdc = dc01.synterex.com
> admin_server = dc01.synterex.com
>   }
>
> [domain_realm]
>   .synterex.com = SYNTEREC.COM
>
> The above configuration would cause the client to request tickets from
> the SYNTEREC.COM realm if the domain name contains .synterex.com (which
> covers all subdomains as well).  A multiple realm configuration might
> look like the following:
>
> [realms]
>   BOSTON.SYNTEREC.COM = {
> kdc = dc01.boston.synterex.com
> admin_server = dc01.boston.synterex.com
>   }
>   ATLANTA.SYNTEREC.COM = {
> kdc = dc01.atlanta.synterex.com
> admin_server = dc01.atlants.synterex.com
>   }
>
> [domain_realm]
>   .boston.synterex.com = BOSTON.SYNTEREC.COM
>   .atlanta.synterex.com = ATLANTA.SYNTEREC.COM
>
> In this case, each subdomain has its own kerberos REALM.  The
> domain_realm section maps the domain to the correct realm.
>
> It is also possible to request a service ticket from a different realm
> from which you have a valid TGT.  A cross-realm trust would need to be
> setup to allow this.  We have this setup between our MIT Kerberos realm
> and Active Directory realm (works quite nicely).
>
> "User is not found in the database" can often point at user mapping
> issue between your Unix/AD environment.  In your example, you would
> want to make sure your AD user account "jon" exists (or change the
> userPrincipalName attribute in AD to match your Unix account).  You can
> also try specifying the principal name manually using kinit:
>
> kinit j...@synterex.com
>
> Based off your email address and the fact that the domains being used
> in your example match, your AD user name could be jjtowles.  In that
> case, make sure your krb5.conf is configured properly and try using
> kinit with:
>
> kinit jjtow...@synterex.com
>
> If the above works, then you'll have to change your userPrincipalName
> attribute in AD to match your Unix account, or change your Unix account
> name to match your AD account.  Without making the change, using
> Kerberos with ssh is useless due to the fact your principal name doesn't
> match your Unix ID.
>
> > I didn't think that it was, but I wanted to check and see if anyone knows.
>
> Good luck!
>
> Bryan
>
> > Jon Towles
> > CTO, Synterex
> > (m) 978-609-5545
> >
> > [VMware Certified Professional - Digital Workspace 2020][VMware Certified 
> > Professional - Desktop and Mobility 
> > 2020][cid:image003.jpg@01D65926.16A527C0] 
> > [cid:image004.png@01D65926.16A527C0]  [cid:image005.png@01D65926.16A527C0] 
> > [cid:image006.png@01D65926.16A527C0]
> > 

Re: referrals and canonicalization

[Isaac Boukris]

On Thu, Feb 27, 2020 at 8:36 PM Ben Gooley  wrote:
>
> Thanks... for reference, Java enabled both referrals and canonicalization 
> requests by its clients in recent releases of OpenJDK:
> https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8223172

Thanks, interesting read.

(for example, this quote: Principal name changes are allowed in AS-REQ
responses only if 1) *canonicalize* option was set in the AS-REQ
request, 2) PA-REQ-ENC-PA-REP pre-authentication data was sent in the
AS-REQ response (meaning the server supports [RFC 6068][1] FAST
scheme) and 3) the authenticated checksum is correct.)

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: referrals and canonicalization

[Isaac Boukris]

On Thu, Feb 27, 2020 at 8:32 PM Greg Hudson  wrote:
>
> AS request canonicalization (for initial tickets) must be explicitly
> enabled by the caller.

IIRC setting canonicalize=yes in krb5.conf also enables it.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: referrals and canonicalization

[Isaac Boukris]

On Thu, Feb 27, 2020 at 8:03 PM Ben Gooley  wrote:
>
> Hello everyone,
>
> Java just decided to support Kerberos referrals and canonicalization and it
> is turned on by default.
> This brings up a question about implementation in MIT Kerberos:
>
> Does MIT Kerberos support referrals by default or must canonicalization be
> turned on in order to handle referrals?

Can you be more specific, what use case exactly do you have in mind.
Roughly, I think in MIT, both client and KDC won't do referrals if the
canonicalize flag was not set on the request, but it is often set
automatically.

BTW, I my opinion, we shouldn't care about the canonicalize flag for
referrals. Windows doesn't seem to really care either (they'll return
both client and server referrals, even with the flag off), I think MS
just abused this flag in RFC 6806 as a generic excuse flag whenever
they deviated from RFC 4120 (while they only use the flag for
canoicalization purposes).

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Are port numbers supported in server principal names?

[Isaac Boukris]

On Tue, Mar 27, 2018 at 6:02 PM, Markus Kuhn  wrote:
> Microsoft's ODBC driver for SQLServer appends a port number
> after a colon to the domain name in a service principal name,
> as in
>
>MSSQLSvc/db0.ad.cl.cam.ac.uk:1433@
>^
>
> and even relies on that port number to distinguish different
> service instances on the same host:
>
>   "For a TCP/IP connection the SPN is registered in the
>format MSSQLSvc/:. Both named instances
>and the default instance are registered as MSSQLSvc,
>relying on the  value to differentiate the instances."
>
>
> https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/register-a-service-principal-name-for-kerberos-connections
>
> Since Microsoft's ODBC Driver for SQL Server is now also available
> for Linux and macOS
>
>
> https://docs.microsoft.com/en-us/sql/connect/odbc/linux-mac/system-requirements
>
> people like myself are now commonly using it with MIT's Kerberos
> client libraries.
>
> This driver requests tickets for service principal names such as
>
>MSSQLSvc/db0.ad.cl.cam.ac.uk:1433@
>
> i.e., with included port number:
>
>
> https://docs.microsoft.com/en-us/sql/connect/odbc/linux-mac/known-issues-in-this-version-of-the-driver
>
> I suspect that a lot of the mechanics in the MIT Kerberos
> client libraries (e.g., to look up in DNS what
> the realm associated with db0.ad.cl.cam.ac.uk or ad.cl.cam.ac.uk
> is in a cross-realm environment) does not cope with the
> presence of the colon and port number in the SPN (NT-SRV-HST).
>
> For example, the above SPN works in kvno (krb5-1.13.2, Ubuntu 16.04)
> only after I remove the port number (whereas both SPNs are registered
> in our Active Directory KDC):
>
> $ kvno MSSQLSvc/db0.ad.cl.cam.ac.uk:1433@
> kvno: Server not found in Kerberos database while getting credentials for 
> MSSQLSvc/db0.ad.cl.cam.ac.uk:1433@
>
> $ kvno MSSQLSvc/db0.ad.cl.cam.ac.uk@
> MSSQLSvc/db0.ad.cl.cam.ac.uk@: kvno = 2


Note, I tried to simulate in lab, using version 1.15.2 (fedora), and
it seems to work ok.

On the DC I ran:
setspn -S MSSQLSvc/myhost.acme.com:1433 ACME\apache
setspn -S MSSQLSvc/myhost.acme.com:1444 ACME\tomcat
setspn -S MSSQLSvc/myhost.acme.com ACME\ngix

And then the above kvno gets a ticket to each.

See tshark traces at:
https://pastebin.com/Hb80rs6s

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: wrong key is generated by krb5_c_string_to_key

[Isaac Boukris]

On Tue, Jun 6, 2017 at 11:48 AM, Ashi1986  wrote:
>>manually since its just an md4 hash with no salt, something like:
>># echo -n password | iconv -t UTF-16LE | openssl dgst -md4
>>And compare with the key in the keytab:
>># klist -Kekt krb5.keytab
>
> I have derived the key manually by using the below command:
> # echo -n password | iconv -t UTF-16LE | openssl dgst -md4
> and the generated key regarding RC4 is same as key generated by KTPASS
> command.
>
> but the key generated by MIT function krb5_c_string_to_key is different from
> the key generated by KTPASS command.

Maybe try to compare your usage to how it is used in ktutil code,
which works perfectly fine afaict (using arcfour-hmac enc-type), see:
https://buildfarm.opencsw.org/source/xref/krb5/src/kadmin/ktutil/ktutil_funcs.c#89

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: wrong key is generated by krb5_c_string_to_key

[Isaac Boukris]

On Mon, Jun 5, 2017 at 6:51 PM, Mark Pröhl  wrote:
> On 06/02/2017 02:29 PM, Ashi1986 wrote:
>> Hi All ,
>>
>> This is my setup .
>>
>> windows 8.1 64 bit
>> windows 2012 R2 server AD and KDC .
>> BS2000 with MIT kerberos 1.13.2
>>
>> I generate keytab for  SPN using this command  :
>>
>> ktpass -princ host/@domain name -mapuser > pass> pass  -crypto RC4-HMAC-NT -ptype KRB5_NT_PRINCIPAL -out
>> C:\KeyTab\HMAC7U6.keytab
>>
> If I do understand you correct, the keytab with the invalid RC4 and AES
> keys is generated with ktpass.exe. If so, how should that be related to
> the krb5_c_string_to_key function from MIT Kerberos?

For AES keys I'd suspect the salt doesn't match (afaik, in AD the salt
is the LHS of the UPN attribute when the password was last set).

But the unmatched RC4 keys is strange, you could derive the key
manually since its just an md4 hash with no salt, something like:
# echo -n password | iconv -t UTF-16LE | openssl dgst -md4
And compare with the key in the keytab:
# klist -Kekt krb5.keytab

HTH


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Which gss calls may block on IO

[Isaac Boukris]

Hello,

If I only acquire credentials for krb5 mech, can I assume that
gss_accpet would not block on IO?
Is there any information available on which gss calls may block on IO
and which not?

Thanks!

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Call to set_com_err_hook() triggers abort

[Isaac Boukris]

Hello,

We are getting random core dumps of httpd on our QA machines and I'm
trying to understand what could cause it.
We have some initialization code which calls set_com_err_hook() with a
static C++ class method, and the crash occurs right afterwards (looks
like com_err_initialize return error, but I have no further info for
now as it happens randomly).

The top of the stack looks like this:
Program terminated with signal 6, Aborted.
#0  0xe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xe410 in __kernel_vsyscall ()
#1  0xf7d94ba0 in raise () from /lib/libc.so.6
#2  0xf7d964b1 in abort () from /lib/libc.so.6
#3  0xf7251acf in set_com_err_hook (
new_proc=0xf6565180 ) at com_err.c:156

Anyone seen this before? Any idea what may be the cause of it?

Thank you!

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Using enterprise principal name in GSS-API

[Isaac Boukris]

Hi Alan,

On Thu, Oct 6, 2016 at 9:29 PM, Alan Braggins  wrote:
> I do have a patch that adds gss_nt_krb5_name_enterprise as a
> recognised OID (szOID_NT_PRINCIPAL_NAME 1.3.6.1.4.1.311.20.2.3),
> and replaces a call to krb5_parse_name with krb5_parse_name_flags
> with KRB5_PRINCIPAL_PARSE_ENTERPRISE in gssapi/krb5/import_name.c

Could you share your changes? I'd be interested to compare it with
what I've got so far, namely:
https://github.com/frenche/krb5/tree/gss_enterprise_name

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Using enterprise principal name in GSS-API

[Isaac Boukris]

On Mon, Sep 26, 2016 at 7:09 PM, Greg Hudson <ghud...@mit.edu> wrote:
> On 09/25/2016 04:32 PM, Isaac Boukris wrote:
>> In such a case (no canonicalization), if the user is found, the KDC
>> returns AS reply with the exact name and name-type (enterprise) as
>> requested.
>
> Interesting.  That's probably not a behavior we want; enterprise names
> should ideally only exist on the edge of the krb5 protocol.  I also
> don't think that's the behavior we would see with an MIT krb5 KDC
> (combined with a third-party KDB module that implements enterprise
> principal name lookup).


I've now looked further into the constrained delegation case.
Using enterprise name works fine with upn, but I see no
canonicalization happening (even with the flag on, enterprise
name-type is returned in TGS-REP).
This can be seen when using the 'kvno' tool to do constrained
delegation, as it always parses the 'for_user' as an enterprise name.
>From MS-SFU doc it sounds like the KDC copies back the username and
realm from the request (PA-FOR-USER).

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Using enterprise principal name in GSS-API

[Isaac Boukris]

On Mon, Sep 26, 2016 at 7:09 PM, Greg Hudson <ghud...@mit.edu> wrote:
> On 09/25/2016 04:32 PM, Isaac Boukris wrote:
>> The more a look at the code and on wire traffic, I think
>> enterprise-name and canonicalization are different things (although
>> related).
>> Here is what my tests against AD (w2k3) seem to show so far.
>>
>> First, the 'kinit' man page says -E implies -C but it doesn't seem to
>> be correct (according to observations).
>
> I see that we don't set the canonicalize KDC option when -E is given.
> Our KDC implementation treats AS requests as having the canonicalize
> flag if the client principal name type is KRB5-NT-ENTERPRISE-PRINCIPAL,
> with the comment "Note that according to the referrals draft we should
> always canonicalize enterprise principal names".  My reading of RFC 6806
> is more ambiguous; in section 5 (defining the enterprise name type) it
> says "The KDC will recognize this name type and then transform the
> requested name into the true principal name if the client account
> resides in the local realm."  But in section 6 (defining the
> canonicalize flag) it doesn't say that the canonicalize flag should be
> inferred from the principal type, and its example AS-REQ scenario
> includes both an enterprise client principal name and the canonicalize flag.
>
>> In such a case (no canonicalization), if the user is found, the KDC
>> returns AS reply with the exact name and name-type (enterprise) as
>> requested.
>
> Interesting.  That's probably not a behavior we want; enterprise names
> should ideally only exist on the edge of the krb5 protocol.  I also
> don't think that's the behavior we would see with an MIT krb5 KDC
> (combined with a third-party KDB module that implements enterprise
> principal name lookup).

I think earlier drafts of the RFC sounded more like MIT implementation logic.

Quote from the third draft:
"The KDC will always return a different name type than
KRB-NT-ENTERPRISE-PRINCIPAL.
This is regardless of the presence of the "canonicalize" KDC option."

However the standardized draft sound a bit less decisive, quote (on
enterprise-name):
"It is used for conveying the alias name, not for the real principal
names within the realms, and thus is only useful when name
canonicalization is requested."

I've run more tests against w2k8 and the behavior seem the same as in
w2k3, meaning it returns enterprise name-type if no canonicalization
was requested.
I think the name in the returned ticket is also enterprise type as I
get the same name format on acceptor side (something like,
user\@suffix@REALM).
However, windows acceptor indicates the canonical username (perhaps it
takes it from the PAC).

>> We probably want to support both enterprise-name and canonicalization
>> in GSS-API (the latter could be set via conf).
>
> I think perhaps we should be setting the canonicalize option whenever we
> make an AS-REQ with an enterprise client principal name, although I'm
> not entirely confident about this because Heimdal doesn't seem to do it.
>  (Heimdal's kinit actually seems to do the reverse; its kinit
> --canonicalize parses the client principal as enterprise even if
> --enterprise isn't given.)

Heimdal's approach doesn't look right, as the RFC doesn't seem to
limit canonicalization to enterprise names.
In fact, the old version (03) even gives an example of an
KRB-NT-PRINCIPAL canonicalized to an KRB-NT-UID.

Perhaps we could change the -E option to (actually) imply
canonicalization but at the API level I think I would prefer to have
both options as each makes sense in its way (IMO).

- Using enterprise name type indicate the KDC to look up the user by
an alias (implementation dependent, globally unique identifier - like
email, phone, upn).
- Enabling canonicalization to allow KDC to change name and name-type.

> I'm not sure how gss_acquire_cred_with_password() with its current
> signature could express a desire for the canonicalize flag, other than
> by importing an enterprise name.

Yea, it would have been useful to have a flag argument to overload.
In cred-store API we could perhap implement a mech_flags store, but it
doesn't support acquiring with password.

So I think I agree the simplest way would be to introduce a GSS
enterprise-name which would also imply canonicalization.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Using enterprise principal name in GSS-API

[Isaac Boukris]

Hi Greg,

On Fri, Sep 23, 2016 at 5:50 PM, Greg Hudson <ghud...@mit.edu> wrote:
> On 09/23/2016 03:52 AM, Isaac Boukris wrote:
>> Maybe we need a new gss name type oid like GSS_NT_ENTERPRISE_NAME,
>> though I guess it's more complicated than it sounds :)
>
> I think that might be reasonable for this use case.  I've seen requests
> to be able to import enterprise principal names before, although (IIRC)
> sometimes for use cases where it might not have made as much sense.
>
> The concerns I can immediately think of are:
>
> * Is there any prior art we should try to be compatible with?  I don't
> see any in Heimdal, and MS doesn't directly implement GSS-API, so I
> don't think there is.

Indeed.

> * If someone uses one of these GSS names in a different scenario (e.g.
> for an acceptor credential), will it fail gracefully?  I believe that's
> generally the case.

Perhaps we'll need to fail gss_canonicalize_name() since we cannot
know what MN it would produce on acceptor side.

> * Does canonicalization at cred acquisition time pose any issues for the
> GSS-API model, because the name you get creds for won't be the same as
> the name you asked for?  gss_acquire_cred_with_password() is an
> extension, not a standardized part of the API, so I think it shouldn't
> be a problem.

The more a look at the code and on wire traffic, I think
enterprise-name and canonicalization are different things (although
related).
Here is what my tests against AD (w2k3) seem to show so far.

First, the 'kinit' man page says -E implies -C but it doesn't seem to
be correct (according to observations).
When using enterprise name with -E, the client library allows for
embedded '@' sign in the client-name and sends it in AS request with
KRB5-NT-ENTERPRISE-PRINCIPAL name-type, but it does not request
canonicalization (flag off, unless -C was given or canonicalization is
set to true in krb5.conf).

In such a case (no canonicalization), if the user is found, the KDC
returns AS reply with the exact name and name-type (enterprise) as
requested.
This still has the advantage of letting the KDC to lookup the user by
UPN in local realm (especially when different UPN suffixes are used in
local realm).

If however, the user is not found on local realm, the KDC returns an
error but also sets the 'crealm' field in the AS reply to a better
realm and the client tries to get credentials from this realm's KDC.
So the only canonicalization implied so far is perhaps for the realm name.

If canonicalization flag is on (-C or conf), then the (last) KDC
replies with a KRB5-NT-PRINCIPAL name-type containing the
sAMAccountName.
Note that if canonicalization is requested in GSS-API (via conf), then
my trick above (changing krb5_gss_import_name) doesn't work, I get:
gss_acquire_cred_with_password(): Invalid credential was supplied
Principal in credential cache does not match desired name

Also note, that I found one case where canonicalization occurs (when
requested) even using regular KRB5-NT-PRINCIPAL name (the name
changes, not the type).

We probably want to support both enterprise-name and canonicalization
in GSS-API (the latter could be set via conf).
So far I couldn't see find in GSS-API doc any problem with, let's say
returning a canonicalized name (e.g. in inquire_cred) different from
what was imported at acquire.

Thanks,
Isaac B.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Using enterprise principal name in GSS-API

[Isaac Boukris]

Hi again,

On Wed, Sep 21, 2016 at 12:07 AM, Isaac Boukris <ibouk...@gmail.com> wrote:
> Hi all,
>
> Is there a way to support name canonicalization (like kinit -E) when
> acquiring creds via gss_acquire_cred_with_password() and
> gss_acquire_cred_impersonate_name() ?
>
> The use case is to use userPrincipalName for client name against AD.


I've found RFC 4768 already laments the lack of enterprise names in
GSS-API (and raises some concerns, mainly ACL related).
RFC 6860 on the other hand says nothing about GSS-API.

Technically, if I change krb5_gss_import_name() to pass
KRB5_PRINCIPAL_PARSE_ENTERPRISE flag when parsing the name, then both
aforementioned functions work fine with UPN (even when the UPN suffix
differs from realm name).

Maybe we need a new gss name type oid like GSS_NT_ENTERPRISE_NAME,
though I guess it's more complicated than it sounds :)

Thanks and regards.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Using enterprise principal name in GSS-API

[Isaac Boukris]

Hi all,

Is there a way to support name canonicalization (like kinit -E) when
acquiring creds via gss_acquire_cred_with_password() and
gss_acquire_cred_impersonate_name() ?

The use case is to use userPrincipalName for client name against AD.

Thanks!

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Running 'make check' hangs for ever

[Isaac Boukris]

On Fri, Jan 1, 2016 at 12:06 AM, Isaac Boukris <ibouk...@gmail.com> wrote:
> On Thu, Dec 31, 2015 at 2:43 AM, Isaac Boukris <ibouk...@gmail.com> wrote:
>> On Thu, Dec 31, 2015 at 1:08 AM, Greg Hudson <ghud...@mit.edu> wrote:
>>> On 12/30/2015 04:28 PM, Isaac Boukris wrote:
>>>> [pid 21891] 
>>>> fcntl64(6,
>>>> F_OFD_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0,
>>>> l_len=-5230051357888610304}) = -1 EINVAL (Invalid argument)
>>>> [pid 21891] 
>>>> fcntl64(6,
>>>> F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}
>>>
>>> Unfortunately, I can't really tell what's going on.  In ofdlock(), we
>>> pass the same struct flock pointer to both fcntl() invocations when we
>>> fall back to F_SETLKW, so I don't know why the first invocation is
>>> reported a garbage l_len.  I also don't know why the second invocation
>>> is blocking; did the first invocation somehow obtain a lock despite
>>> returning EINVAL?  I can't find any search results about a known kernel
>>> or glibc bug which might explain this odd behavior.
>>
>>
>> Strange indeed, it does look like the fd is locked:
>> # cat /proc/24040/fdinfo/6
>> pos:0
>> flags:  0202
>> mnt_id: 57
>> lock:   1: POSIX  ADVISORY  READ  24040 fd:00:1195813 0 EOF
>>
>> I've pasted a longer output of strace at:
>> http://pastebin.com/Rw8nvjCZ
>
>
> FYI I think there is something wrong with my system.
> I tried to investigate by starting with an example from:
> https://www.gnu.org/software/libc/manual/html_node/Open-File-Description-Locks-Example.html
>
> But it get stuck in a similar manner:
>
> [pid  6683] fcntl64(4, F_OFD_SETLK, {l_type=F_UNLCK,
> l_whence=SEEK_SET, l_start=4294967296, l_len=8367752102667091968}) =
> -1 EINVAL (Invalid argument)
> [pid  6683] nanosleep({0, 1000},  
> [pid  6682] <... open resumed> )= 5
> [pid  6683] <... nanosleep resumed> NULL) = 0
> [pid  6683] madvise(0xb6571000, 8372224, MADV_DONTNEED) = 0
> [pid  6683] exit(0) = ?
> [pid  6683] +++ exited with 0 +++
> [pid  6682] fcntl64(5, F_OFD_SETLKW, {l_type=F_WRLCK,
> l_whence=SEEK_SET, l_start=4294967296, l_len=0}
>
> Thanks for the feedback and happy new year!


FYI 2, I've hit this again and looked a little further.
It looks like the bug is in glibc on 32 arch, see:
https://sourceware.org/bugzilla/show_bug.cgi?id=20251

Changing 'struct flock' to 'struct flock64' in 'lock_file.c' also works.

Regards.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Constrained Delegation incurs high rate of TGS exchange

[Isaac Boukris]

On Jan 4, 2016 5:33 PM, "Greg Hudson" <ghud...@mit.edu> wrote:
>
> On 12/27/2015 10:57 PM, Isaac Boukris wrote:
> >> I'm trying to use gss_acquire_cred_impersonate_name() followed by
> >> gss_store_cred_into() to store impersonated creds into a ccache which
> >> I later use for calling gss_init_sec_context() on behalf of the user.
>
> > I think I found the bug in 'init_sec_context', when we have
> > impersonator credentials we don't check first if we have cached
> > credentials.
> > Please have a look at PR #381 - it fixes it for me (no high rate of
> > TGS exchange and no duplicate entries in ccache).
>
> Thanks for the clear problem description and the pull request.  It may
> take a while to get to this because of a big post-holiday work pileup,
> but it's on the radar.

Thanks for the feedback.

Note that I've tried to make the changes very local as the code flow is
pretty complicated.
I'll be glad however to make necessary adjustments or test an alternative
patch if needed.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Running 'make check' hangs for ever

[Isaac Boukris]

On Thu, Dec 31, 2015 at 2:43 AM, Isaac Boukris <ibouk...@gmail.com> wrote:
> On Thu, Dec 31, 2015 at 1:08 AM, Greg Hudson <ghud...@mit.edu> wrote:
>> On 12/30/2015 04:28 PM, Isaac Boukris wrote:
>>> [pid 21891] 
>>> fcntl64(6,
>>> F_OFD_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0,
>>> l_len=-5230051357888610304}) = -1 EINVAL (Invalid argument)
>>> [pid 21891] 
>>> fcntl64(6,
>>> F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}
>>
>> Unfortunately, I can't really tell what's going on.  In ofdlock(), we
>> pass the same struct flock pointer to both fcntl() invocations when we
>> fall back to F_SETLKW, so I don't know why the first invocation is
>> reported a garbage l_len.  I also don't know why the second invocation
>> is blocking; did the first invocation somehow obtain a lock despite
>> returning EINVAL?  I can't find any search results about a known kernel
>> or glibc bug which might explain this odd behavior.
>
>
> Strange indeed, it does look like the fd is locked:
> # cat /proc/24040/fdinfo/6
> pos:0
> flags:  0202
> mnt_id: 57
> lock:   1: POSIX  ADVISORY  READ  24040 fd:00:1195813 0 EOF
>
> I've pasted a longer output of strace at:
> http://pastebin.com/Rw8nvjCZ


FYI I think there is something wrong with my system.
I tried to investigate by starting with an example from:
https://www.gnu.org/software/libc/manual/html_node/Open-File-Description-Locks-Example.html

But it get stuck in a similar manner:

[pid  6683] fcntl64(4, F_OFD_SETLK, {l_type=F_UNLCK,
l_whence=SEEK_SET, l_start=4294967296, l_len=8367752102667091968}) =
-1 EINVAL (Invalid argument)
[pid  6683] nanosleep({0, 1000},  
[pid  6682] <... open resumed> )= 5
[pid  6683] <... nanosleep resumed> NULL) = 0
[pid  6683] madvise(0xb6571000, 8372224, MADV_DONTNEED) = 0
[pid  6683] exit(0) = ?
[pid  6683] +++ exited with 0 +++
[pid  6682] fcntl64(5, F_OFD_SETLKW, {l_type=F_WRLCK,
l_whence=SEEK_SET, l_start=4294967296, l_len=0}

Thanks for the feedback and happy new year!

>>> PYTHONPATH=../../util VALGRIND="" python ./t_gss_sample.py
>>> *** Failure: /home/admin/git/krb5/src/appl/gss-sample/gss-client
>>> failed with code 1.
>>
>> There should have been some additional messages explaining how to get
>> more information from a failing Python test; that information (and
>> perhaps more) is needed to figure out why this is failing for you.
>
>
> So I looked at the testlog file and noticed it got confused because my
> host had two DNS records with different names (round robin).
> Once I removed the additional name the 'make check' succeeded.
>
> Thanks!

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Running 'make check' hangs for ever

[Isaac Boukris]

On Thu, Dec 31, 2015 at 1:08 AM, Greg Hudson <ghud...@mit.edu> wrote:
> On 12/30/2015 04:28 PM, Isaac Boukris wrote:
>> [pid 21891] 
>> fcntl64(6,
>> F_OFD_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0,
>> l_len=-5230051357888610304}) = -1 EINVAL (Invalid argument)
>> [pid 21891] 
>> fcntl64(6,
>> F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}
>
> Unfortunately, I can't really tell what's going on.  In ofdlock(), we
> pass the same struct flock pointer to both fcntl() invocations when we
> fall back to F_SETLKW, so I don't know why the first invocation is
> reported a garbage l_len.  I also don't know why the second invocation
> is blocking; did the first invocation somehow obtain a lock despite
> returning EINVAL?  I can't find any search results about a known kernel
> or glibc bug which might explain this odd behavior.


Strange indeed, it does look like the fd is locked:
# cat /proc/24040/fdinfo/6
pos:0
flags:  0202
mnt_id: 57
lock:   1: POSIX  ADVISORY  READ  24040 fd:00:1195813 0 EOF

I've pasted a longer output of strace at:
http://pastebin.com/Rw8nvjCZ

>> PYTHONPATH=../../util VALGRIND="" python ./t_gss_sample.py
>> *** Failure: /home/admin/git/krb5/src/appl/gss-sample/gss-client
>> failed with code 1.
>
> There should have been some additional messages explaining how to get
> more information from a failing Python test; that information (and
> perhaps more) is needed to figure out why this is failing for you.


So I looked at the testlog file and noticed it got confused because my
host had two DNS records with different names (round robin).
Once I removed the additional name the 'make check' succeeded.

Thanks!

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Running 'make check' hangs for ever

[Isaac Boukris]

Hi,

I'm trying to run 'make check' on 32bit fedora (21 / 23) installed on
VM and it hangs for ever.

# uname -a
Linux fedora 4.2.8-300.fc23.i686+PAE #1 SMP Tue Dec 15 17:13:23 UTC
2015 i686 i686 i386 GNU/Linux

Initially I thought it was lack of entropy (had it once) but it seems
something different, related to flock.

The command 'make check' hangs at:

PYTHONPATH=../../../util VALGRIND="" python ./t_cccol.py

With, 'strace -fyv make check' I see:

[pid 21891] 
fcntl64(6,
F_OFD_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0,
l_len=-5230051357888610304}) = -1 EINVAL (Invalid argument)
[pid 21891] 
fcntl64(6,
F_SETLKW, {l_type=F_WRLCK, l_whence=SEEK_SET, l_start=0, l_len=0}

And with 'gdb attach $(pidof kadmin.local)' I get:

#0  0xb77ccbe8 in __kernel_vsyscall ()
#1  0xb75b8c05 in fcntl () from /lib/libpthread.so.0
#2  0xb76912f5 in ofdlock (lock_arg=, cmd=, fd=) at lock_file.c:80
#3  krb5_lock_file (context=0x946a4d8, fd=6, mode=2) at lock_file.c:132
#4  0xb73c159b in osa_adb_get_lock (db=0x946a488, mode=2) at adb_openclose.c:235
#5  0xb73c25cb in ctx_lock (context=context@entry=0x9468880,
dbc=dbc@entry=0x9469e68, lockmode=lockmode@entry=2) at kdb_db2.c:472
#6  0xb73c3655 in krb5_db2_put_principal (context=0x9468880,
entry=0x946af68, db_args=0x0) at kdb_db2.c:839
#7  0xb73c4872 in wrap_krb5_db2_put_principal (ctx=0x9468880,
d=0x946af68, db_args=0x0) at db2_exp.c:124
#8  0xb7792d31 in krb5int_put_principal_no_log (kcontext=0x9468880,
entry=0x946af68) at kdb5.c:866
#9  0xb7792dec in krb5_db_put_principal (kcontext=0x9468880,
entry=0x946af68) at kdb5.c:893
#10 0xb77b28c7 in kdb_put_entry (handle=0x9469b90, kdb=0x946af68,
adb=0xbfd37464) at server_kdb.c:397
#11 0xb77adcf8 in kadm5_create_principal_3 (server_handle=0x9469b90,
entry=0xbfd37564, mask=1, n_ks_tuple=0, ks_tuple=0x0,
password=0xbfd395c4 "alice22387")
at svr_principal.c:579
#12 0xb77addf8 in kadm5_create_principal (server_handle=0x9469b90,
entry=0xbfd37564, mask=1, password=0xbfd395c4 "alice22387") at
svr_principal.c:367
#13 0x0804b751 in create_princ (princ=, mask=, n_ks=, ks=0x0, pass=0xbfd395c4 "alice22387") at
kadmin.c:207
#14 0x0804d029 in kadmin_addprinc (argc=4, argv=0x946abb0) at kadmin.c:1223
#15 0x08051af8 in check_request_table (rqtbl=,
sci_idx=1, argv=0x946abb0, argc=4) at execute_cmd.c:74
#16 really_execute_command (sci_idx=sci_idx@entry=1,
argc=argc@entry=4, argv=argv@entry=0xbfd37b2c) at execute_cmd.c:115
#17 0x08051bc0 in ss_execute_command (sci_idx=1, argv=0xbfd37c28) at
execute_cmd.c:152
#18 0x0804a516 in main (argc=5, argv=0xbfd37c24) at ss_wrapper.c:59


By looking around in the code I managed to workaround this by
disabling POSIX_FILE_LOCKS in 'lock_file.c'.
It nows goes much further, although the tests still fail, this time
properly with:

PYTHONPATH=../../util VALGRIND="" python ./t_gss_sample.py
*** Failure: /home/admin/git/krb5/src/appl/gss-sample/gss-client
failed with code 1.

Thought this may be worth sharing, perhaps someone could make sense of it.

Thanks and regards,
Isaac B.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Constrained Delegation incurs high rate of TGS exchange

[Isaac Boukris]

Hi again,

On Sat, Dec 26, 2015 at 3:47 AM, Isaac Boukris <ibouk...@gmail.com> wrote:
> Hello,
>
> I'm trying to use gss_acquire_cred_impersonate_name() followed by
> gss_store_cred_into() to store impersonated creds into a ccache which
> I later use for calling gss_init_sec_context() on behalf of the user.
>
> This works fine (against w2k3) but it seems that each call to
> gss_init_sec_context() incurs a new TGS exchange (on wire) and
> subsequently 'klist' shows additional entries although the target
> server is the same.
> This doesn't happen when I use regular 'kinit' to initialize the
> ccache (rather the first TGS seems to be reused).
>
> I was wondering if this is expected in constrained-delegation scenario
> or whether I might be doing something wrong (tested with 1.12.2 and
> 1.14-pre).


I think I found the bug in 'init_sec_context', when we have
impersonator credentials we don't check first if we have cached
credentials.
Please have a look at PR #381 - it fixes it for me (no high rate of
TGS exchange and no duplicate entries in ccache).

Thanks a lot!

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Constrained Delegation incurs high rate of TGS exchange

[Isaac Boukris]

Hello,

I'm trying to use gss_acquire_cred_impersonate_name() followed by
gss_store_cred_into() to store impersonated creds into a ccache which
I later use for calling gss_init_sec_context() on behalf of the user.

This works fine (against w2k3) but it seems that each call to
gss_init_sec_context() incurs a new TGS exchange (on wire) and
subsequently 'klist' shows additional entries although the target
server is the same.
This doesn't happen when I use regular 'kinit' to initialize the
ccache (rather the first TGS seems to be reused).

I was wondering if this is expected in constrained-delegation scenario
or whether I might be doing something wrong (tested with 1.12.2 and
1.14-pre).

Thank you,
Isaac Boukris

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Kerberos Authentication question(s)

[Isaac Boukris]

Hi,

On Thu, Jun 25, 2015 at 11:43 PM, Michael B Allen iop...@gmail.com wrote:
 Pls beware, I'm copying ietf-http-wg at w3.org so please remove one or
 the other addresses (or both!) when replying if necessary. Not sure
 about cross posting netiquette these days but this has become more
 about HTTP authentication (non-Enterprise points at the end) now than
 it is about Kerberos.

 On Thu, Jun 25, 2015 at 12:39 PM, Benjamin Kaduk ka...@mit.edu wrote:
 gotten better over the years). Note that the reason the Windows SSPI
 is used by Java is largely because there is otherwise no way to insert
 credentials into the Windows credential cache. It actually used to be
 possible but at some point early on MS decided this was probably not a
 good idea and so now Java and MIT or Heimdal or whoever cannot insert
 creds into the Windows credential cache. They have to just use the

 This is simply not true -- both MIT KfW and Heimdal for Windows can insert
 Kerberos credentials into the Windows LSA credential cache.

 Interesting. I don't know why I thought it wasn't possible but it's
 actually good to hear that it is.

 Again I am not familiar with your token code but fortunately, even
 though the Authorization: Negotiate ... token is an Internet
 Explorer-ism, it's SPNEGO payload is largely compatible with the

 Huh?  HTTP-Negotiate is published as RFC 4559 and is supported by all
 major browsers.  The token formats described therein are explicitly the
 SPNEGO GSS-API token formats; there's no need to hedge with largely.

 I think it is amusing when someone starts citing RFCs for something
 like this. HTTP-Negotiate was initially used by Internet Explorer and
 Windows and more specifically is a product of the Windows SSPI and it
 is purely a Microsoft invention. So I think it is a little
 disingenuous to cite an RFC in this case. HTTP-Negotiate was defined
 by how Internet Explorer behaved and any RFC that properly states that
 behavior is mostly an afterthought. Having said that, I think it would
 be difficult for MS to change the behavior of SPNEGO now that there is
 an RFC for it and especially since the RFC was written mostly by folks
 from Microsoft.

How protocols evolve is often amusing, nevertheless SPNEGO *is* widely
supported.

 As for the largely hedge, that is because some of these protocols
 are ill-defined and so naturally the RFCs have holes. For example,
 SPNEGO is supposed to negotiate a mechanism. But in practice it does
 no such thing and it's not entirely clear how it could negotiate a
 mechanism. Have you ever seen a client try to do NTLM and end up doing
 Kerberos or vice versa (meaning the server says no, I can't do
 Kerberos, please try again with NTLM)? No. So SPNEGO is actually
 completely useless.

It negotiates pretty well, you  could try for yourself with
mod_auth_gssapi when the server has no keytab (while both client and
server support ntlmssp).

 And it is equally funny that these protocols *try* to implement the
 same thing over and over. SPNEGO is used to select a mech and GSSAPI
 uses an OID to indicate the mech and SASL has a field that specifies
 the mech which leads to the odd scenario where SASL selects the GSSAPI
 mech which in turn has an OID for the actual mech used. Bah! This is
 at least extraneous and silly in light of the fact that in practice
 99.999% of clients are ultimately just using Kerberos or NTLM.

I haven't seen SASL implemented in HTTP clients (although there seem
to be an RFC).

 And as long as I'm peeing in the punch, I would go so far as to say
 these protocols are BAD because it's another layer of stuff that
 someone has to implement and so things like integrity and
 confidentiality options are left out or implemented incorrectly
 because it's not clear how the various flags translate from one layer
 to the next.

Well, sealing / encryption works for LDAP with GSSAPI / GSS-SPNEGO via SASL.
You  could try it with  'ldapsearch' and other clients (I tested
SPNEGO negotiation as well).

 So now you ask ok genius, so what would have been the correct way to
 implement this stuff? The answer is to just do / document what the
 actual working implementation does and not try to design a new Utopian
 protocol from round table at some tech conference (think X.500 and DER
 encoding). For example, in the case of HTTP authentication, it should
 have never used SPNEGO or GSSAPI. It should have just used raw
 Kerberos or raw NTLMSSP as defined by the MS InitializeSecurityContext
 function. Incedentally, this would have made negotiation fairly easy.

Raw GSSAPI (krb / ntlm) usually for just fine with IIS and usual
modules that pass the token to gss_accept_sec_context.
It is in fact common with MS clients to send *raw* ntlmssp token when
the PC is not in the domain.

 So I would argue HTTP authentication should have looked something like
 this (with negotiation thrown in for fun):

 C: Authorization: NTLMSSP optimistic token
 S: WWW-Authenticate: Kerberos
 C: Authorization: