[jcifs] enumerating domains with Wins server

[Gary Rambo]

Chris,

1	The Windows browser passes the final server name back as the seed 
entry in the NetServerEnum3 request, and gets the same name back as the 
first server in the reply. I'm sure you are right that 'some servers 
"might"' start the reply with the next entry following the seed, but I 
was younger then and assumed that what I was seeing was somehow lawlike. 
The oldest google reference I saw to NetServerEnum3 was an August 2002 
security advisory, which may mean that most of the implementations were 
constructed around the same time, so there may not *yet* be much divergence.

2 & 3	Looking again at the packets I think you are right: the 32-bit 
value certainly looks like the Enum2 serverType field, and the entire 
response once again appears to be 26 bytes, as with Enum2.

Thanks.

Gary



Christopher R. Hertel wrote:
> Gary,
> 
> So... I'm working on writhing up NetServerEnum3 and I'm noticing the
> following oddities:
> 
> - In the trace you sent, the last entry in the NetServerEnum2 (that's '2') 
>   response is "HXXXX".  (Well, it's not exactly that, but I'm fudging for 
>   public posting.)
> 
>   You (correctly--I mean what else could you do) pass that back to the
>   server in the first NetServerEnum3 (that's '3') request.  The odd thing
>   is that the server returns "HXXXX" as the *first* entry in the reply.
> 
>   That's wierd, since the client now has "HXXXX" twice.  Is that what you 
>   see when a Windows box is the client?  The client code will have to make 
>   sure that the entry doesn't get displayed twice.  Just assuming that the 
>   first entry in the second list is a duplicate won't work, since some 
>   servers *might* start the NetServerEnum3 with the entry following 
>   "HXXXX" (which is what I would expect).
> 
> - In your message describing this (back in March) you said that the string 
>   field containing the last returned entry replaces the serverType field.  
>   I'm still seeing the serverType in the trace.  Am I missing something 
>   or was that just early analysis?  I ask because, as I understand it, the 
>   trace I'm seeing was generated using your modified jCIFS as the client
>   and I want to make sure I understand what Windows is doing.
> 
> Also, in your message you said that the NetServerEnum3 response was 
> diminished with respect to the '2' response.  I'm not seeing it.  How does 
> the message change?  It looks different in Ethereal but when I did down I 
> think that's simply Ethereal not handling the packet correctly.
> 
> Interested in anyone's feedback on these.  It's fun tracking down a new 
> call.  :)
> 
> Thanks, Gary!  This is interesting stuff!
> 
> Chris -)-----
> 

-- 
Gary Rambo
Aventail Corporation
Secure access for the real world.
www.aventail.com