[cvsnt] Re: SSPI Problems

[Bo Berglund]

On Fri, 30 Dec 2005 23:30:39 +0000, Tony Hoyle
<tony.hoyle at march-hare.com> wrote:

>Bob Provencher wrote:
>> Well, I'm pretty experienced at developing for NT security and Active
>> Directory.  Domains are very relevant when talking about logins.  I don't
>> think LSA simply looks in it's own user database for an account with the
>> same username/password as the incoming one.
>
>For SSPI it'll look up based on the domain and the username even on a 
>non-domain machine, since the DOMAIN\Username is translated to a SID 
>which contains both.
>
>The user also needs network login rights to the machine of course, and 
>the account must be enabled etc.
>
>Switching on auditing will usually tell you what the problem is.
>
>The one glitch is logging in from XP Home or a machine with 'simple file 
>sharing' enabled, since this screws up the authentication by forcing 
>every login to the guest account... this affects everything not just 
>cvsnt though (there are workarounds in the code to counteract this 
>effect but I'm not sure they work all the time).
>

This is one item that has intrigued me a lot and now is the time to
ask, I think:

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?

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 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.

I know that when you use :sspi:server:/repo then the user account at
the client PC is used and its credentials are sent over and it would
be a different picture, but this is not the case here.
In my view it is more like sserver with aliasing to a single local
account on the server when one uses :sspi:user at server:/repo

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....


/Bo
(Bo Berglund, developer in Sweden)