On Jul 1, 2008, at 8:49 AM, Gerald (Jerry) Carter wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael B Allen wrote:
>> Dear Cousin,
>>
>> Does anyone know if it's ok to do Kerberos 5 and / or NTLMSSP without
>> SPNEGO for SMB_COM_SESSION_SETUP_ANDX?
>>
>> I'm 95% sure the answer is "yes" but it would be nice if someone gave
>> me assuring pat on the head.
>
> Pretty sure. Been a while since I looked but I think this is how
> Steve previously did NTLMSSP in the cifs fs.
You can with NTLMSSP, not sure about Kerberos. In fact Windows 2003
will do this if they are not part of a domain.

>
>
>
>
>
>
> cheers, jerry
> - --
> ================================================== ===================
> Samba ------- http://www.samba.org
> Likewise Software --------- http://www.likewisesoftware.com
> "What man is a man who does not make the world better?" --Balian
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFIalInIR7qMdg1EfYRAmyQAKCw0urs/1qlp7Ev8OM95uSMAwZnswCgmalo
> z3DVaCqgS3TRHEUkq7WSRfI=
> =BBs+
> -----END PGP SIGNATURE-----

On 02/07/2008, at 1:49 AM, Gerald (Jerry) Carter wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael B Allen wrote:
>> Dear Cousin,
>>
>> Does anyone know if it's ok to do Kerberos 5 and / or NTLMSSP without
>> SPNEGO for SMB_COM_SESSION_SETUP_ANDX?
>>
>> I'm 95% sure the answer is "yes" but it would be nice if someone gave
>> me assuring pat on the head.
>
> Pretty sure. Been a while since I looked but I think this is how
> Steve previously did NTLMSSP in the cifs fs.


I think Windows still does raw NTLMSSP too... never seen raw Kerberos
though, but SSPI is sufficiently well layered that I would expect it
to work.

-- Luke

On 7/1/08, Luke Howard wrote:
>
> On 02/07/2008, at 1:49 AM, Gerald (Jerry) Carter wrote:
>
>
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Michael B Allen wrote:
> >
> > > Dear Cousin,
> > >
> > > Does anyone know if it's ok to do Kerberos 5 and / or NTLMSSP without
> > > SPNEGO for SMB_COM_SESSION_SETUP_ANDX?
> > >
> > > I'm 95% sure the answer is "yes" but it would be nice if someone gave
> > > me assuring pat on the head.
> > >
> >
> > Pretty sure. Been a while since I looked but I think this is how
> > Steve previously did NTLMSSP in the cifs fs.
> >
>
>
> I think Windows still does raw NTLMSSP too... never seen raw Kerberos
> though, but SSPI is sufficiently well layered that I would expect it to
> work.

I was able to get raw NTLMSSP w/ NTLMv2 and raw Kerberos 5 working.
Hopefully it will work reliably with all the major servers.

But I was not able to get NTLMv2 SMB signatures working. From looking
at Samba's libsmb code the UserSessionKey calculation described in
Eric Glass' NTLM doc is completely different. I'm getting the feeling
that SMB just uses it's own rules (as usual).

Mike

--
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/

On Wednesday 02 July 2008 02:58:49 Luke Howard wrote:
> On 02/07/2008, at 1:49 AM, Gerald (Jerry) Carter wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Michael B Allen wrote:
> >> Dear Cousin,
> >>
> >> Does anyone know if it's ok to do Kerberos 5 and / or NTLMSSP without
> >> SPNEGO for SMB_COM_SESSION_SETUP_ANDX?
> >>
> >> I'm 95% sure the answer is "yes" but it would be nice if someone gave
> >> me assuring pat on the head.
> >
> > Pretty sure. Been a while since I looked but I think this is how
> > Steve previously did NTLMSSP in the cifs fs.
>
> I think Windows still does raw NTLMSSP too... never seen raw Kerberos
> though, but SSPI is sufficiently well layered that I would expect it
> to work.

I don't know about SMB_COM_SESSION_SETUP_ANDX, but from the API side of SSPI,
it's easy to select Kerberos without going via SPNEGO. So I agree with Luke
that it'll probably work.

Cheers,
Kai

--
Kai Blin
WorldForge developer http://www.worldforge.org/
Wine developer http://wiki.winehq.org/KaiBlin
Samba team member http://www.samba.org/samba/team/
--
Will code for cotton.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQBIaxexEKXX/bF2FpQRAqsvAJwIXu8BNYXu0inxPe+JNgLXx2X98QCeN3fl
+JQbziObvmkF8BSPDWbsJDE=
=tsFw
-----END PGP SIGNATURE-----

> I was able to get raw NTLMSSP w/ NTLMv2 and raw Kerberos 5 working.
> Hopefully it will work reliably with all the major servers.

That's a fair concern, given that a lot of server implementations were
built from packet traces or incomplete documentation. NetApp, for
example, do not support big-endian PACs (and neither does Samba unless
that has been fixed recently).

> But I was not able to get NTLMv2 SMB signatures working. From looking
> at Samba's libsmb code the UserSessionKey calculation described in
> Eric Glass' NTLM doc is completely different. I'm getting the feeling
> that SMB just uses it's own rules (as usual).

You might take a look at the MS docs too. From memory the first 16
bytes of the Kerberos session key are used.

-- Luke

Luke Howard schrieb:
>> I was able to get raw NTLMSSP w/ NTLMv2 and raw Kerberos 5 working.
>> Hopefully it will work reliably with all the major servers.
>
> That's a fair concern, given that a lot of server implementations were
> built from packet traces or incomplete documentation. NetApp, for
> example, do not support big-endian PACs (and neither does Samba unless
> that has been fixed recently).

when was that fixed in samba? I don't think we support big-endian PACs
in samba4 and I didn't see a related commit in samba3.

What server will ever create a big-endian PAC?

metze


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.7 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFIazP1m70gjA5TCD8RAmM2AJ0UZqQ4mzypal6KbsOYE/oHp2mTRQCglmNj
rARQt9APxFvLJWxE68QutWY=
=7OvI
-----END PGP SIGNATURE-----

On 02/07/2008, at 5:53 PM, Stefan (metze) Metzmacher wrote:

> Luke Howard schrieb:
>>> I was able to get raw NTLMSSP w/ NTLMv2 and raw Kerberos 5 working.
>>> Hopefully it will work reliably with all the major servers.
>>
>> That's a fair concern, given that a lot of server implementations
>> were
>> built from packet traces or incomplete documentation. NetApp, for
>> example, do not support big-endian PACs (and neither does Samba
>> unless
>> that has been fixed recently).
>
> when was that fixed in samba? I don't think we support big-endian PACs
> in samba4 and I didn't see a related commit in samba3.
>
> What server will ever create a big-endian PAC?

None shipping today. XAD did on POWER and S/390. We did have customers
on POWER.

-- Luke

No, both Kerberos and NTLMSSP can't be done without SPNEGO support.

Without SPNEGO, we would not be able to negotiate with the server which one
to use between the 2.

NTLMSSP works without SPNEGO as its the default auth. mechanism used by
Microsoft.

And only Kerberos also can't work without SPNEGO support.

Nilesh.

On Tue, Jul 1, 2008 at 9:19 PM, Gerald (Jerry) Carter
wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael B Allen wrote:
> > Dear Cousin,
> >
> > Does anyone know if it's ok to do Kerberos 5 and / or NTLMSSP without
> > SPNEGO for SMB_COM_SESSION_SETUP_ANDX?
> >
> > I'm 95% sure the answer is "yes" but it would be nice if someone gave
> > me assuring pat on the head.
>
> Pretty sure. Been a while since I looked but I think this is how
> Steve previously did NTLMSSP in the cifs fs.
>
>
>
>
>
> cheers, jerry
> - --
> ================================================== ===================
> Samba ------- http://www.samba.org
> Likewise Software --------- http://www.likewisesoftware.com
> "What man is a man who does not make the world better?" --Balian
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD8DBQFIalInIR7qMdg1EfYRAmyQAKCw0urs/1qlp7Ev8OM95uSMAwZnswCgmalo
> z3DVaCqgS3TRHEUkq7WSRfI=
> =BBs+
> -----END PGP SIGNATURE-----
>

On 02/07/2008, at 7:22 PM, Nilesh Lonari wrote:

> No, both Kerberos and NTLMSSP can't be done without SPNEGO support.
>
> Without SPNEGO, we would not be able to negotiate with the server
> which one
> to use between the 2.

The InitialContextToken contains the OID of the GSS-API mechanism
(NTLMSSP excepted, but it also contains a well known header).

> NTLMSSP works without SPNEGO as its the default auth. mechanism used
> by
> Microsoft.

You've contradicted your first statement.

> And only Kerberos also can't work without SPNEGO support.

On what authority state you this?

[MS-SMB] section 5.2 implies that any GSS-API mechanism is supported
(although that should be qualified by stating that the mechanism
should have an exportable session key).

Now, you may be right, the only way to verify this for sure is to test
it.

-- Luke

On 7/2/08, Luke Howard wrote:
> > I was able to get raw NTLMSSP w/ NTLMv2 and raw Kerberos 5 working.
> > Hopefully it will work reliably with all the major servers.
> >
>
> That's a fair concern, given that a lot of server implementations were
> built from packet traces or incomplete documentation. NetApp, for example,
> do not support big-endian PACs (and neither does Samba unless that has been
> fixed recently).
>
>
> > But I was not able to get NTLMv2 SMB signatures working. From looking
> > at Samba's libsmb code the UserSessionKey calculation described in
> > Eric Glass' NTLM doc is completely different. I'm getting the feeling
> > that SMB just uses it's own rules (as usual).
> >
>
> You might take a look at the MS docs too. From memory the first 16 bytes of
> the Kerberos session key are used.

Yeah, Kerberos was easy. The problem is NTLMv2 SMB signatures. From
looking at a log level 10 of smbclient it looks like it generates the
user_session_key in the if (ntlmssp_state->neg_flags &
NTLMSSP_NEGOTIATE_NTLM2) { case in
libsmb/ntlmssp.c:ntlmssp_client_challenge. I did look at [MS-NLMP]
briefly but it wasn't obvious to me what corresponded to that code. I
got sidetracked with client vs. server subkeys and such but it doesn't
look like SMB uses those keys (which makes sense now because it would
require very different signing behavior). I get the feeling the NTLM
docs are talking about generic NTLMSSP integrity and conf whereas SMB
does something a little different.

Whatever. I'm sure I can make it work. It's just something that
requires a lot of fiddling.

Mike

--
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/

On 7/2/08, Luke Howard wrote:
> On 02/07/2008, at 7:22 PM, Nilesh Lonari wrote:
>
>
> > No, both Kerberos and NTLMSSP can't be done without SPNEGO support.
> >
> > Without SPNEGO, we would not be able to negotiate with the server which
> one
> > to use between the 2.

> [MS-SMB] section 5.2 implies that any GSS-API mechanism is supported

The funny thing about SPNEGO w/ NTLM and Kerberos as mechs that many
people don't realize is that it does not actually negotiate anything.

Consider the two cases:

a) Client sends NTLM but server wan'ts Kerberos: If a Windows client
can't do Kerberos it doesn't send the Keberos OID so it leaves the
server no choices.

b) Client sends Kerberos but server want's NTLM: If the client was
able to acquire a Kerberos service ticket the server has a valid
service account so there should be no reason to reject it.

SPNEGO is basically dead weight.

Mike

--
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/

On 02/07/2008, at 11:57 PM, Michael B Allen wrote:

> On 7/2/08, Luke Howard wrote:
>>> I was able to get raw NTLMSSP w/ NTLMv2 and raw Kerberos 5 working.
>>> Hopefully it will work reliably with all the major servers.
>>>
>>
>> That's a fair concern, given that a lot of server implementations
>> were
>> built from packet traces or incomplete documentation. NetApp, for
>> example,
>> do not support big-endian PACs (and neither does Samba unless that
>> has been
>> fixed recently).
>>
>>
>>> But I was not able to get NTLMv2 SMB signatures working. From
>>> looking
>>> at Samba's libsmb code the UserSessionKey calculation described in
>>> Eric Glass' NTLM doc is completely different. I'm getting the
>>> feeling
>>> that SMB just uses it's own rules (as usual).
>>>
>>
>> You might take a look at the MS docs too. From memory the first 16
>> bytes of
>> the Kerberos session key are used.
>
> Yeah, Kerberos was easy. The problem is NTLMv2 SMB signatures. From
> looking at a log level 10 of smbclient it looks like it generates the
> user_session_key in the if (ntlmssp_state->neg_flags &
> NTLMSSP_NEGOTIATE_NTLM2) { case in
> libsmb/ntlmssp.c:ntlmssp_client_challenge. I did look at [MS-NLMP]
> briefly but it wasn't obvious to me what corresponded to that code. I
> got sidetracked with client vs. server subkeys and such but it doesn't
> look like SMB uses those keys (which makes sense now because it would
> require very different signing behavior). I get the feeling the NTLM
> docs are talking about generic NTLMSSP integrity and conf whereas SMB
> does something a little different.

Right, SMB uses the session key directly for signing, unrelated to
NTLM sign/verify at the GSS layer.

-- Luke

On Wed, Jul 02, 2008 at 10:06:12AM -0400, Michael B Allen wrote:
> On 7/2/08, Luke Howard wrote:
> > On 02/07/2008, at 7:22 PM, Nilesh Lonari wrote:

> > > No, both Kerberos and NTLMSSP can't be done without SPNEGO support.

> > > Without SPNEGO, we would not be able to negotiate with the server which
> > one
> > > to use between the 2.
>
> > [MS-SMB] section 5.2 implies that any GSS-API mechanism is supported

> The funny thing about SPNEGO w/ NTLM and Kerberos as mechs that many
> people don't realize is that it does not actually negotiate anything.

> Consider the two cases:

> a) Client sends NTLM but server wan'ts Kerberos: If a Windows client
> can't do Kerberos it doesn't send the Keberos OID so it leaves the
> server no choices.

> b) Client sends Kerberos but server want's NTLM: If the client was
> able to acquire a Kerberos service ticket the server has a valid
> service account so there should be no reason to reject it.

> SPNEGO is basically dead weight.

If the server doesn't (want to) support kerberos, then this up-front SPNEGO
declaration, coming as it does in the negprot response packet (which already
has to be sent as part of the handshake), saves the client a round-trip to
the KDC to try to acquire a ticket.

And if the server declares that it doesn't support a particular mech, the
client knows not to bother with that mech; there's no need to generate more
pointless network traffic for an authentication that's guaranteed to fail.

That's not dead weight at all, it's a straightforward authentication
negotiation.

--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org

On 7/3/08, Steve Langasek wrote:
> On Wed, Jul 02, 2008 at 10:06:12AM -0400, Michael B Allen wrote:
> > On 7/2/08, Luke Howard wrote:
> > > On 02/07/2008, at 7:22 PM, Nilesh Lonari wrote:
>
> > > > No, both Kerberos and NTLMSSP can't be done without SPNEGO support.
>
> > > > Without SPNEGO, we would not be able to negotiate with the server which
> > > one
> > > > to use between the 2.
> >
> > > [MS-SMB] section 5.2 implies that any GSS-API mechanism is supported
>
> > The funny thing about SPNEGO w/ NTLM and Kerberos as mechs that many
> > people don't realize is that it does not actually negotiate anything.
>
> > Consider the two cases:
>
> > a) Client sends NTLM but server wan'ts Kerberos: If a Windows client
> > can't do Kerberos it doesn't send the Keberos OID so it leaves the
> > server no choices.
>
> > b) Client sends Kerberos but server want's NTLM: If the client was
> > able to acquire a Kerberos service ticket the server has a valid
> > service account so there should be no reason to reject it.
>
> > SPNEGO is basically dead weight.
>
>
> If the server doesn't (want to) support kerberos, then this up-front SPNEGO
> declaration, coming as it does in the negprot response packet (which already
> has to be sent as part of the handshake), saves the client a round-trip to
> the KDC to try to acquire a ticket.
>
> And if the server declares that it doesn't support a particular mech, the
> client knows not to bother with that mech; there's no need to generate more
> pointless network traffic for an authentication that's guaranteed to fail.
>
> That's not dead weight at all, it's a straightforward authentication
> negotiation.

The MO that you describe is a hack and is not how the SPNEGO authors
intended it to be used. You will never see the server reject the
optimistic mech-token and request something else. That server
initiated SPNEGO business is unique to SMB. Also, I'm pretty sure
clients cache information about what was or was not successful so it's
questionable as to whether or not the server-initiated SPNEGO hack is
even worth it.

I don't know if SPNEGO provides any advantages regarding the
negotiation of integrity and confidentiality but otherwise, unless
some other mechs come into the fold, it's pretty much dead weight.

Mike

--
Michael B Allen
PHP Active Directory SPNEGO SSO
http://www.ioplex.com/