Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to firstname.lastname@example.org.
Bo Berglund wrote: > Consider a non-domain CVSNT server that receives a client cvs login > call via protocol :sspi:user at server:/repo > The server presumably receives the username and requests the password > from the client via TCP port 2401. > Now the server has the two items to check, so it goes to its user > database and looks for user, finds him and validates the password. > If OK then it sends the OK back to the client, again via the TCP port > and the client saves the info in the registry. > > Now, where exactly does the simple file sharing come into play? Broken file sharing is implemented at the SSPI level, so what happens is it sees the login call and returns an SSPI packet for logging in as Guest/no password instead of the current user. Specifying a user explicitly is supposed to override this, but on some configurations it doesn't & I haven't worked out why exactly. > For what I can deduce everything between the client and the cvs server > is communicated via TCP port 2401 and so there is no NT user > validation at that point simple file sharing or not. The port is just a channel for the SSPI protocol to go over - you can do SSPI over port 80 for websites too (Its base64 encoded but the same data). > The cvs server is holding a user account name and password and is > about to validate it by getting the SID, I guess. This user is a local > user on the PC so it will authenticate OK. No need for a Guest account > at this point, at least that is what I believe. The cvs server doesn't really do anything with the data, other than tell the system to send it & supply a username/password/domain as necessary. Theres a Win32 API call that returns the packet to send (and another one that receives the packet and generates a reply at the other end). > But then again I might be entierly off track here. But if so then I > don't understand how the TCP communication on a special port outside > of the realm of NT verification can ever be involved in this "simple > file sharing" limitation problem.... It's the way it was implemented by MS... they could have done it at explorer level or SMB level, but chose to do it in the SSPI authentication, which screws up all the non-filesharing uses of it. Tony