Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"

Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"

[Nogin, Aleksey]

I am experiencing the same error that Corinna Vinschen have reported on cygwin-apps mailing list about a year ago without any obvious resolution(*), and I was wondering whether somebody was able to resolve it since.

I am running Heimdal's kinit (as came with MobaXterm 6.2) under Windows 7 to get a ticket from a Windows AD, and then ssh'ing into RHEL 5 and 6 boxes set up to use pam_krb to authenticate against the same Windows AD.  gssapi-with-mic authentication succeeds, but credential delegation does not, and I see the same "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10" error(**) previously reported. This is an issue in my environment, where Kerberos-secured NFS is used to provide access to home directories.

One thing I did notice is that when I ssh into an RHEL box, afterwards kinit on the client (Cygwin) side shows a ticket for the RHEL host (as expected), yet it shows that the ticket lacks the "forwardable" flag, which would probably explain the failure to delegate credentials. So perhaps this is a problem with the SSH client on the Cygwin end ("ssh -V" reports "OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012"), rather than Heimdal's? The libdefaults section in krb5.conf on Cygwin does contain "forwardable = yes" and in contract to how it happens on Cygwin, the Linux->Linux ssh that does delegate credentials correctly also does obtain a forwardable ticket on the client side.

TIA for any help.

Aleksey

(*) The last message of the thread at http://cygwin.com/ml/cygwin-apps/2012-03/msg00156.html ends with "Oh well, I guess I just give up.  You proved that it works and I'm trying a pretty unlikely combination." I guess I am trying an unlikely combination too :-(

(**) Here is the full output (RHEL 5 version; RHEL 6 is virtually the same, with OpenSSH_5.3 on the other end).
% ssh -v XXXhostXXX
OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012
debug1: Reading configuration data /home/mobaxterm/.ssh/config
debug1: /home/mobaxterm/.ssh/config line 24: Applying options for *
debug1: Reading configuration data /etc/ssh_config
debug1: Connecting to XXXhostXXX [IP.IP.IP.IP] port 22.
debug1: Connection established.
debug1: identity file /home/mobaxterm/.ssh/id_rsa type 1
debug1: identity file /home/mobaxterm/.ssh/id_rsa-cert type -1
debug1: identity file /home/mobaxterm/.ssh/id_dsa type -1
debug1: identity file /home/mobaxterm/.ssh/id_dsa-cert type -1
debug1: identity file /home/mobaxterm/.ssh/id_ecdsa type -1
debug1: identity file /home/mobaxterm/.ssh/id_ecdsa-cert type -1
debug1: Remote protocol version 2.0, remote software version OpenSSH_4.3
debug1: match: OpenSSH_4.3 pat OpenSSH_4*
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-md5 zlib@openssh.com
debug1: kex: client->server aes128-ctr hmac-md5 zlib@openssh.com
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA XX:XX:XX:...
debug1: Host 'XXXhostXXX' is known and matches the RSA host key.
debug1: Found key in /home/mobaxterm/.ssh/known_hosts:16
debug1: ssh_rsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1:  Miscellaneous failure (see text)
unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10

debug1: Delegating credentials
debug1: Delegating credentials
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (gssapi-with-mic).
Authenticated to XXXhostXXX ([IP.IP.IP.IP]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: No xauth program.
debug1: Requesting X11 forwarding with authentication spoofing.
debug1: Requesting authentication agent forwarding.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"

[Larry Hall (Cygwin)]

On 6/14/2013 5:39 PM, Nogin, Aleksey wrote:
<snip>

> One thing I did notice is that when I ssh into an RHEL box, afterwards
> kinit on the client (Cygwin) side shows a ticket for the RHEL host (as
> expected), yet it shows that the ticket lacks the "forwardable" flag, which
> would probably explain the failure to delegate credentials. So perhaps this
> is a problem with the SSH client on the Cygwin end ("ssh -V" reports
> "OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012"), rather than Heimdal's?

<snip>

An easy way to help answer this question is to update your 'openssh'
(and 'cygwin') package(s) at least and see if that helps.  Allot has
changed in the last year+.

-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"

[Nogin, Aleksey]

> An easy way to help answer this question is to update your 'openssh'
> (and 'cygwin') package(s) at least and see if that helps.  Allot has changed in the last year+.

I've created a fresh installation of Cygwin, and see the exact same error:

$ ssh -v XXXhostXXX
OpenSSH_6.2p2, OpenSSL 1.0.1e 11 Feb 2013
[snip]
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug1: Next authentication method: gssapi-with-mic
debug1:  Miscellaneous failure (see text)
unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10

debug1: Delegating credentials
debug1: Delegating credentials
debug1: Authentication succeeded (gssapi-with-mic).
[snip]

I also observe that the ticket for the "host/XXXhostXXX" lacks the "forwardable" flag.

Aleksey

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"

[Larry Hall (Cygwin)]

On 6/14/2013 6:56 PM, Nogin, Aleksey wrote:
>> An easy way to help answer this question is to update your 'openssh'
>> (and 'cygwin') package(s) at least and see if that helps.  Allot has changed in the last year+.
>
> I've created a fresh installation of Cygwin, and see the exact same error:
>
> $ ssh -v XXXhostXXX
> OpenSSH_6.2p2, OpenSSL 1.0.1e 11 Feb 2013
> [snip]
> debug1: Authentications that can continue: publickey,gssapi-with-mic,password
> debug1: Next authentication method: gssapi-with-mic
> debug1:  Miscellaneous failure (see text)
> unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10
>
> debug1: Delegating credentials
> debug1: Delegating credentials
> debug1: Authentication succeeded (gssapi-with-mic).
> [snip]
>
> I also observe that the ticket for the "host/XXXhostXXX" lacks the "forwardable" flag.

OK, maybe Yaakov has a thought.


-- 
Larry

_____________________________________________________________________

A: Yes.
 > Q: Are you sure?
 >> A: Because it reverses the logical flow of conversation.
 >>> Q: Why is top posting annoying in email?

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"

[Jeffrey Altman]

On 6/14/2013 5:39 PM, Nogin, Aleksey wrote:
> debug1: SSH2_MSG_SERVICE_REQUEST sent
> debug1: SSH2_MSG_SERVICE_ACCEPT received
> debug1: Authentications that can continue: publickey,gssapi-with-mic,password
> debug1: Next authentication method: gssapi-with-mic
> debug1:  Miscellaneous failure (see text)
> unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10
> 
> debug1: Delegating credentials
> debug1: Delegating credentials
> debug1: Enabling compression at level 6.
> debug1: Authentication succeeded (gssapi-with-mic).
> Authenticated to XXXhostXXX ([IP.IP.IP.IP]:22).

I'm not sure what the issue is here.  The authentication succeeded.

MechType 1.3.6.1.4.1.311.2.2.10 is Microsoft's NTLM SSP.  The sshd does
not support NTLM and so rejects it.  The next GSS mechanism is
negotiated within the gssapi-with-mic exchange.  That is probably
Kerberos5 and it succeeds.

Jeffrey Altman



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"

[Nogin, Aleksey]

Jeffrey Altman wrote:

>> debug1: SSH2_MSG_SERVICE_REQUEST sent
>> debug1: SSH2_MSG_SERVICE_ACCEPT received
>> debug1: Authentications that can continue: 
>> publickey,gssapi-with-mic,password
>> debug1: Next authentication method: gssapi-with-mic
>> debug1:  Miscellaneous failure (see text) unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10
>> 
>> debug1: Delegating credentials
>> debug1: Delegating credentials
>> debug1: Enabling compression at level 6.
>> debug1: Authentication succeeded (gssapi-with-mic).
>> Authenticated to XXXhostXXX ([IP.IP.IP.IP]:22).
>
> I'm not sure what the issue is here.  The authentication succeeded.

The issue that despite the "Delegating credentials" message, credentials are not being delegated.

Aleksey

Re: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"

[Jeffrey Altman]

On 6/20/2013 6:31 PM, Nogin, Aleksey wrote:
> Jeffrey Altman wrote:
> 
>>> debug1: SSH2_MSG_SERVICE_REQUEST sent
>>> debug1: SSH2_MSG_SERVICE_ACCEPT received
>>> debug1: Authentications that can continue: 
>>> publickey,gssapi-with-mic,password
>>> debug1: Next authentication method: gssapi-with-mic
>>> debug1:  Miscellaneous failure (see text) unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10
>>>
>>> debug1: Delegating credentials
>>> debug1: Delegating credentials
>>> debug1: Enabling compression at level 6.
>>> debug1: Authentication succeeded (gssapi-with-mic).
>>> Authenticated to XXXhostXXX ([IP.IP.IP.IP]:22).
>>
>> I'm not sure what the issue is here.  The authentication succeeded.
> 
> The issue that despite the "Delegating credentials" message, credentials are not being delegated.
> 
> Aleksey


I still do not understand what does that has to do with the subject of
this message?

The credentials that will be deleted are the credentials of the type
that was accepted by the ssh gssapi-with-mic mechanism.  At the
verbosity level that you are using it does not state what that is.

In any case, I am quite sure that if your ssh client states that it has
delegated credentials that it has done so.   You need to debug the
server side to determine where the sshd environment or gssapi library
has determined the credentials have been stored.   For Kerberos it will
need to be a credential cache.  Heimdal defaults to using a non-FILE
based cache but I suspect that Cygwin does not provide a non-FILE based
cache implementation.

Jeffrey Altman



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"

[Corinna Vinschen]

On Jun 20 18:56, Jeffrey Altman wrote:
> On 6/20/2013 6:31 PM, Nogin, Aleksey wrote:
> > Jeffrey Altman wrote:
> > 
> >>> debug1: SSH2_MSG_SERVICE_REQUEST sent
> >>> debug1: SSH2_MSG_SERVICE_ACCEPT received
> >>> debug1: Authentications that can continue: 
> >>> publickey,gssapi-with-mic,password
> >>> debug1: Next authentication method: gssapi-with-mic
> >>> debug1:  Miscellaneous failure (see text) unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10
> >>>
> >>> debug1: Delegating credentials
> >>> debug1: Delegating credentials
> >>> debug1: Enabling compression at level 6.
> >>> debug1: Authentication succeeded (gssapi-with-mic).
> >>> Authenticated to XXXhostXXX ([IP.IP.IP.IP]:22).
> >>
> >> I'm not sure what the issue is here.  The authentication succeeded.
> > 
> > The issue that despite the "Delegating credentials" message, credentials are not being delegated.
> > 
> > Aleksey
> 
> 
> I still do not understand what does that has to do with the subject of
> this message?
> 
> The credentials that will be deleted are the credentials of the type
> that was accepted by the ssh gssapi-with-mic mechanism.  At the
> verbosity level that you are using it does not state what that is.
> 
> In any case, I am quite sure that if your ssh client states that it has
> delegated credentials that it has done so.   You need to debug the
> server side to determine where the sshd environment or gssapi library
> has determined the credentials have been stored.   For Kerberos it will
> need to be a credential cache.  Heimdal defaults to using a non-FILE
> based cache but I suspect that Cygwin does not provide a non-FILE based
> cache implementation.

Guys, whatever the problem here is, it needs to be investigated and
potentially implemented by somebody who knows this kerberos/gss-api
stuff.  Openssh is built against these libraries and that's it from my
side.  If something's missing in openssh to support this correctly on
Cygwin, or if the Cygwin DLL to support this authentication model, I
simply don't know what it is.  I appreciate any coding help.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"

[Jeffrey Altman]

On 6/21/2013 3:43 AM, Corinna Vinschen wrote:
> Guys, whatever the problem here is, it needs to be investigated and
> potentially implemented by somebody who knows this kerberos/gss-api
> stuff.  Openssh is built against these libraries and that's it from my
> side.  If something's missing in openssh to support this correctly on
> Cygwin, or if the Cygwin DLL to support this authentication model, I
> simply don't know what it is.  I appreciate any coding help.
> 
> Corinna

Corinna,

To the best of my knowledge the Heimdal developers have not been
contacted by the Cygwin Heimdal package maintainer.  One of my
companies, Secure Endpoints, maintains the native Windows distribution
of Heimdal.

  http://www.secure-endpoints.com/heimdal/

Please ask the Heimdal package maintainer for Cygwin to contact me so I
can understand how it is being built.

Jeffrey Altman





--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"

[Corinna Vinschen]

On Jun 21 09:39, Jeffrey Altman wrote:
> On 6/21/2013 3:43 AM, Corinna Vinschen wrote:
> > Guys, whatever the problem here is, it needs to be investigated and
> > potentially implemented by somebody who knows this kerberos/gss-api
> > stuff.  Openssh is built against these libraries and that's it from my
> > side.  If something's missing in openssh to support this correctly on
> > Cygwin, or if the Cygwin DLL to support this authentication model, I
> > simply don't know what it is.  I appreciate any coding help.
> > 
> > Corinna
> 
> Corinna,
> 
> To the best of my knowledge the Heimdal developers have not been
> contacted by the Cygwin Heimdal package maintainer.

Well, if it builds...

> One of my
> companies, Secure Endpoints, maintains the native Windows distribution
> of Heimdal.
> 
>   http://www.secure-endpoints.com/heimdal/
> 
> Please ask the Heimdal package maintainer for Cygwin to contact me so I
> can understand how it is being built.

You can look it up in the source archive really simply:
ftp://cygwin.com/pub/cygwin/release/heimdal/heimdal-1.5.2-4-src.tar.bz2

From what I gather from the heimdal.cygport file, there's nothing
special in this build, except for four patch files which fix minor
build problems and a signal handling bug.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Unable to delegate credentials from Cygwin ssh client was Re: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"

[Jeffrey Altman]

On 6/14/2013 5:39 PM, Nogin, Aleksey wrote:
> I am experiencing the same error that Corinna Vinschen have reported on cygwin-apps mailing list about a year ago without any obvious resolution(*), and I was wondering whether somebody was able to resolve it since.
> 
> I am running Heimdal's kinit (as came with MobaXterm 6.2) under Windows 7 to get a ticket from a Windows AD, and then ssh'ing into RHEL 5 and 6 boxes set up to use pam_krb to authenticate against the same Windows AD.  gssapi-with-mic authentication succeeds, but credential delegation does not, and I see the same "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10" error(**) previously reported. This is an issue in my environment, where Kerberos-secured NFS is used to provide access to home directories.
> 
> One thing I did notice is that when I ssh into an RHEL box, afterwards kinit on the client (Cygwin) side shows a ticket for the RHEL host (as expected), yet it shows that the ticket lacks the "forwardable" flag, which would probably explain the failure to delegate credentials. So perhaps this is a problem with the SSH client on the Cygwin end ("ssh -V" reports "OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012"), rather than Heimdal's? The libdefaults section in krb5.conf on Cygwin does contain "forwardable = yes" and in contract to how it happens on Cygwin, the Linux->Linux ssh that does delegate credentials correctly also does obtain a forwardable ticket on the client side.
> 
> TIA for any help.

Going back to the original posting.

The Heimdal that is being used is MobaXTerm's kinit.

What Heimdal is it?

Is it a native Windows build?

The Secure Endpoints distribution which Microsoft LSA support and MIT
credential cache support?

Or the Heimdal that is packaged for Cygwin?

The Heimdal distribution matters because it will determine where the
krb5.conf configuration file is going to be stored.  If you aren't sure,
use "SysInternals Process Monitor" to trace the "kinit.exe" process and
see what files it accesses.

When "kinit" is executed, is the "-f" parameter provided requesting a
"forwardable" ticket granting ticket?

If the ticket granting ticket (TGT) is not forwardable, then none of the
derived tickets will be.  When delegating credentials it is the TGT that
is forwarded to the remote host, not the host/<hostname>@<REALM> service
ticket which is used solely for authentication.

Jeffrey Altman



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Packaging Heimdal for Cygwin was Re: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"

[Jeffrey Altman]

On 6/21/2013 10:07 AM, Corinna Vinschen wrote:
>> To the best of my knowledge the Heimdal developers have not been
>> contacted by the Cygwin Heimdal package maintainer.
> 
> Well, if it builds...

We are discussing security software that must integrate with the native
environment.  When MIT or Heimdal Kerberos is built for OSX it is built
with specific knowledge of the OSX keychain.

When XYZ Kerberos is built for Windows natively it has specific
knowledge of the Microsoft LSA Kerberos cache (readonly) and provides a
secure credential cache implementation into which credentials can be
stored and accessed via the MIT credential cache api.  The goal of
Kerberos is single sign-on so if the user obtains Kerberos credentials
as part of the OS logon they should be accessible to the applications
that the user executes without requiring that the user enter their
password again.

On Linux the kernel's keyring support is often used to store Kerberos
credentials because it is more secure than plain files.  I suspect that
functionality is not emulated by cygwin1.dll since it could not in fact
be secure unless it was backed by a kernel driver.

Since Cygwin Heimdal is built as Linux without any platform specific
credential cache support it will be restricted to using FILE: caches as
a ticket store.  Microsoft Kerberos never uses FILE: based caches and
native MIT and Heimdal distributions use them only when explicitly
configured to.

The preferred location of a krb5.conf file on Windows is

  %ALLUSERSPROFILE%\Kerberos\krb5.conf

By reading the DOS formatted file stored at that location any configuration
applied to native Kerberos library distributions will also be used by
Cygwin applications.

If Cygwin's /etc/krb5.conf is used the system administrator (often an
end user without knowledge that Kerberos is even being used) must ensure
that the two configuration files are synchronized to avoid inconsistent
application behavior.

I guess that cygwin1.dll could special case /etc/krb5.conf and have it
shadow %ALLUSERSPROFILE%\Kerberos\krb5.conf with appropriate end-of-line
translations.

> You can look it up in the source archive really simply:
> ftp://cygwin.com/pub/cygwin/release/heimdal/heimdal-1.5.2-4-src.tar.bz2
> 
> From what I gather from the heimdal.cygport file, there's nothing
> special in this build, except for four patch files which fix minor
> build problems and a signal handling bug.

Of the four patches included in the tar ball all but the
lib/roken/signal.c patch are specific to the Cygwin build and
installation.  The lib/roken/signal.c patch could be submitted upstream
via a github.com pull request against https://github.com/heimdal/heimdal.

Jeffrey Altman



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Packaging Heimdal for Cygwin was Re: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"

[Corinna Vinschen]

On Jun 21 13:35, Jeffrey Altman wrote:
> Since Cygwin Heimdal is built as Linux without any platform specific
> credential cache support it will be restricted to using FILE: caches as
> a ticket store.  Microsoft Kerberos never uses FILE: based caches and
> native MIT and Heimdal distributions use them only when explicitly
> configured to.
> 
> The preferred location of a krb5.conf file on Windows is
> 
>   %ALLUSERSPROFILE%\Kerberos\krb5.conf
> 
> By reading the DOS formatted file stored at that location any configuration
> applied to native Kerberos library distributions will also be used by
> Cygwin applications.

Sorry if I'm dense but what does that mean exactly for Cygwin?  Assuming
the Cygwin heimdal package would use that file location, would it be only
able to interact correctly with other third part kerberos or heimdal
packages, or would it also work with the native stuff and AD?

> If Cygwin's /etc/krb5.conf is used the system administrator (often an
> end user without knowledge that Kerberos is even being used) must ensure
> that the two configuration files are synchronized to avoid inconsistent
> application behavior.
> 
> I guess that cygwin1.dll could special case /etc/krb5.conf and have it
> shadow %ALLUSERSPROFILE%\Kerberos\krb5.conf with appropriate end-of-line
> translations.

Not in the cygwin DLL.  THis would have to be done in the heimdal package.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Packaging Heimdal for Cygwin was Re: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"

[Jeffrey Altman]

On 6/24/2013 5:10 AM, Corinna Vinschen wrote:
> On Jun 21 13:35, Jeffrey Altman wrote:
>> Since Cygwin Heimdal is built as Linux without any platform specific
>> credential cache support it will be restricted to using FILE: caches as
>> a ticket store.  Microsoft Kerberos never uses FILE: based caches and
>> native MIT and Heimdal distributions use them only when explicitly
>> configured to.
>>
>> The preferred location of a krb5.conf file on Windows is
>>
>>   %ALLUSERSPROFILE%\Kerberos\krb5.conf
>>
>> By reading the DOS formatted file stored at that location any configuration
>> applied to native Kerberos library distributions will also be used by
>> Cygwin applications.
> 
> Sorry if I'm dense but what does that mean exactly for Cygwin?  Assuming
> the Cygwin heimdal package would use that file location, would it be only
> able to interact correctly with other third part kerberos or heimdal
> packages, or would it also work with the native stuff and AD?

If Cygwin shared that location it would share the configuration for
native MIT and Heimdal Kerberos distributions.

Microsoft's Kerberos SSP is in-kernel and does not use configuration
files.  All Microsoft configuration is via Group Policy and Registry
manipulation.

Jeffrey Altman



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

RE: Unable to delegate credentials from Cygwin ssh client was Re: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"

[Nogin, Aleksey]

Jeffrey Altman wrote:

> > I am running Heimdal's kinit (as came with MobaXterm 6.2) under
> > Windows 7 to get a ticket from a Windows AD, and then ssh'ing into RHEL
> > 5 and 6 boxes set up to use pam_krb to authenticate against the same
> > Windows AD.  gssapi-with-mic authentication succeeds, but credential
> > delegation does not, and I see the same "unknown mech-code 2529639054
> > for mech 1 3 6 1 4 1 311 2 2 10" error(**) previously reported. This is
> > an issue in my environment, where Kerberos-secured NFS is used to
> > provide access to home directories.
> >
> > One thing I did notice is that when I ssh into an RHEL box, afterwards
> > kinit on the client (Cygwin) side shows a ticket for the RHEL host (as
> > expected), yet it shows that the ticket lacks the "forwardable" flag,
> > which would probably explain the failure to delegate credentials. So
> > perhaps this is a problem with the SSH client on the Cygwin end ("ssh -
> > V" reports "OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012"), rather than
> > Heimdal's? The libdefaults section in krb5.conf on Cygwin does contain
> > "forwardable = yes" and in contract to how it happens on Cygwin, the
> > Linux->Linux ssh that does delegate credentials correctly also does
> > obtain a forwardable ticket on the client side.
> 
> Going back to the original posting.
> 
> The Heimdal that is being used is MobaXTerm's kinit.
> 
> What Heimdal is it?

"kinit --version" reports "kinit (Heimdal 1.5.2)". That said, things look exactly the same with plain Cygwin (which reports the same version of Heimdal)

[snip]

> The Heimdal distribution matters because it will determine where the
> krb5.conf configuration file is going to be stored.  If you aren't sure,
> use "SysInternals Process Monitor" to trace the "kinit.exe" process and
> see what files it accesses.

The configuration is stored in /etc/krb5.conf (behavior changes depending on the contents of that(. I am using the exact same krb5.conf that works correctly on RHEL.

> When "kinit" is executed, is the "-f" parameter provided requesting a
> "forwardable" ticket granting ticket?

No, but I have "forwardable = yes" under "[libdefaults]" in krb5.conf. I can run "klist -vvv" and I see that the flags are as follows:


Server: krbtgt/REALM@REALM
Client: anogin@REALM
[...]
Ticket flags: pre-authent, initial, renewable, forwardable
Addresses: addressless

Server: host/sshserver@REALM
Client: anogin@REALM
[...]
Ticket flags: pre-authent
Addresses: addressless

Again, the above is the same with "plain" Cygwin.

Re: Unable to delegate credentials from Cygwin ssh client was Re: Heimdal 1.5.2: "unknown mech-code 2529639054 for mech 1 3 6 1 4 1 311 2 2 10"

[Jeffrey Altman]

On 6/25/2013 1:23 AM, Nogin, Aleksey wrote:
> Jeffrey Altman wrote:
> 
>>> I am running Heimdal's kinit (as came with MobaXterm 6.2) under
>>> Windows 7 to get a ticket from a Windows AD, and then ssh'ing into RHEL
>>> 5 and 6 boxes set up to use pam_krb to authenticate against the same
>>> Windows AD.  gssapi-with-mic authentication succeeds, but credential
>>> delegation does not, and I see the same "unknown mech-code 2529639054
>>> for mech 1 3 6 1 4 1 311 2 2 10" error(**) previously reported. This is
>>> an issue in my environment, where Kerberos-secured NFS is used to
>>> provide access to home directories.
>>>
>>> One thing I did notice is that when I ssh into an RHEL box, afterwards
>>> kinit on the client (Cygwin) side shows a ticket for the RHEL host (as
>>> expected), yet it shows that the ticket lacks the "forwardable" flag,
>>> which would probably explain the failure to delegate credentials. So
>>> perhaps this is a problem with the SSH client on the Cygwin end ("ssh -
>>> V" reports "OpenSSH_6.1p1, OpenSSL 1.0.1c 10 May 2012"), rather than
>>> Heimdal's? The libdefaults section in krb5.conf on Cygwin does contain
>>> "forwardable = yes" and in contract to how it happens on Cygwin, the
>>> Linux->Linux ssh that does delegate credentials correctly also does
>>> obtain a forwardable ticket on the client side.
>>
>> Going back to the original posting.
>>
>> The Heimdal that is being used is MobaXTerm's kinit.
>>
>> What Heimdal is it?
> 
> "kinit --version" reports "kinit (Heimdal 1.5.2)". That said, things look exactly the same with plain Cygwin (which reports the same version of Heimdal)
> 
> [snip]

If it is the Cygwin binary then it will be linked against cygwin1.dll.
If it is the native binary it will contain resource information visible
in the explorer shell and if it came from the Secure Endpoints package
will be digitally signed.

>> The Heimdal distribution matters because it will determine where the
>> krb5.conf configuration file is going to be stored.  If you aren't sure,
>> use "SysInternals Process Monitor" to trace the "kinit.exe" process and
>> see what files it accesses.
> 
> The configuration is stored in /etc/krb5.conf (behavior changes depending on the contents of that(. I am using the exact same krb5.conf that works correctly on RHEL.
>
>> When "kinit" is executed, is the "-f" parameter provided requesting a
>> "forwardable" ticket granting ticket?
> 
> No, but I have "forwardable = yes" under "[libdefaults]" in krb5.conf. I can run "klist -vvv" and I see that the flags are as follows:
> 
> 
> Server: krbtgt/REALM@REALM
> Client: anogin@REALM
> [...]
> Ticket flags: pre-authent, initial, renewable, forwardable
> Addresses: addressless
> 
> Server: host/sshserver@REALM
> Client: anogin@REALM
> [...]
> Ticket flags: pre-authent
> Addresses: addressless
> 
> Again, the above is the same with "plain" Cygwin.

The TGT issued to your principal is forwardable but the
host/<fqdn>@<REALM> principal is not.  There are four possibilities:

1. sshd is not properly requesting a forwardable ticket

2. a request to the KDC is being issued with the forwardable flag but
   the KDC is refusing to issue a forwardable ticket because:

  a. The krbtgt/<REALM>@<REALM> service principal does not permit
     forwarding

  b. The host/<fqdn>@<REALM> service principal does not permit
     forwarding

3. a bug in Heimdal where the forwardable flag is not set when it
   should be.

I would start by using wireshark to examine the requested tickets
and the response.




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple