Skip to Content.
Sympa Menu

freetds - Re: Windows NT Authentication

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Brian Bruns <camber AT ais.org>
  • To: TDS Development Group <freetds AT franklin.metalab.unc.edu>
  • Subject: Re: Windows NT Authentication
  • Date: Fri, 19 Apr 2002 07:52:42 -0400 (EDT)


Hi,

The 0x11 packet type is the challenge response. The 0x04 immediately
after login contains a challenge against which the client must encrypt
it's hashed password. The 0x11 packet is then the answer to the
challenge. I used to have working code for it, but for the life of me
can't find it right now...part of it is in challenge.c but I can't find
the rest...I'll search my old directories and see if it turns up.

Brian

On Fri, 19 Apr 2002, jhlee wrote:

> Hi there~
>
> I wonder if anyone here is interested in the Windows NT Authentication
> mode.
> I have questions about the packet type 0x11 and the second byte in the
> header(the last packet byte).
>
> ---------------------------------------------------
> 1-1. When the client sends a login packet...
> It sends a packet with a header like...
> Header: 10 01 .. .. .. .. .. .. (8 bytes in hexa)
> ( 0x10:packet type=login, 0x01:last packet=true)
>
> 1-2. it 'usually' gets a response with a login ack.
> Header: 04 01 .. .. .. .. .. ..
> ( 0x04:packet type=server response, 0x01:last packet=true)
> and the token stream includes the login ack token. (0x01)
>
> <summary> SQL Server Authentication
> -> 10 01 (login packet with ID, password)
> <- 04 01 (login ack)
>
>
> ...but with Windows NT Authentication
> -> 10 01 (login packet)
> <- 04 00 (security level) (why not 04 01 ?)
> -> 11 01 (client info???)
> <- 04 01 (login ack)
>
> 2-1. the login packet doesn't have enough info...
>
> 2-2. so it doesn't get a login ack.
> It gets a response that 'doesn¡¯t have the login ack' and starts with
> Header 04 00 .. .. .. .. .. ..
> ( 0x04:packet type=server response, 0x01:last packet=false)
>
> Where the the 'last packet byte'(the second byte) is set to 0x00...
> Which means this isn't the last packet, and there's more data to send
> from the server.
>
> 2-3. But the following packet is not another (server response)
> It's a (client->server) packet with
> Header: 11 01 .. .. .. .. .. ..
> ( 0x11: don¡¯t know what type it is...)
> And holds information about the client domain.
>
> 2-4. And 'after' that the client gets server response with a login ack.
> Header: 04 01 .. .. .. .. .. ..
> ( 0x04:packet type=server response, 0x01:last packet=true)
>
>
> What I'd like to ask...
> #1. Does anyone know about the packet type 0x11. (first byte in the
> header)
> I think it has client domain(?) information...
>
> #2. Is it possible to send a packet to the other side(change directions)
> even if the last packet you received had a header with 0x00(false)
> as the
> 'last packet status'(second byte in the header) byte?
>
> I thought you were supposed to wait until the other side sends a
> packet with the 'last packet byte' set as 0x01 in order to send data.
>
> Example) Long queries are usually handled like...
> -> 01 00 (long query)
> -> 01 00 (query cont'd)
> -> 01 01 (query ended)
> <- 04 00 (results)
> <- 04 01 (results)
> -> 01 01 (short query)
> <- 04 01 (result)
>
> The versions I used...
> Win2k with MS SQL 2k Server - Windows 2000 Server with 2k Client
> Win2k with MS SQL 2k Server - Windows NT 4.0 with SQL 7.0 Client
>
> @ I'm having a hard time explaining all the binary packets with plain
> text.
> I have NetMON captured traffic. Please mail me if you need some
> examples or would like to help but can't understand...
>
>
>
> ---
> You are currently subscribed to freetds as: [camber AT ais.org]
> To unsubscribe, forward this message to $subst('Email.Unsub')
>





Archive powered by MHonArc 2.6.24.

Top of Page