>> you cannot select by username, the reason being that the negotiation
SMBs
>> incidate encrypted or cleartext password capability _before_ a session
>> setup SMB, which indicates username and password.
>
> Which end controls this? I'm perfectly happy to continue to accept
> cleartext from any client that offers it. This is a firewalled
> business environment where people aren't going to be sniffing
> passwords unless they are being paid to do that, in which case they
> already know the root password. I just want to be able to continue
> to work as people install the SP3 virus, err... upgrade.
It's the server that chooses. The server must set the "encrypted
passwords"
bit in the negprot reply, which is the first SMB packet it sends to the client
after the client starts the connection.
The problem is that the server does not know at this stage what username or
share the client is going to connect to. All it knows about the client is
its netbios name.
I have thought of a way to get around this, but it hasn't been implemented
and it's possible that it won't work. The idea would be to delay sending
the negprot reply and instead send a netbios name status request (UDP/137)
to the client and wait for a response. The name status reply should contain
the currently claimed netbios names of the client, which happens to include
the username of the person logged into the console for MS Windows systems.
Samba could then look in the smbpasswd file to see if that user has an
encrypted
password and if they do then Samba can send a "yes" in the
"enable encrypted
passwords" bit of the negprot response.
We may well implement this in a future version of Samba. If it works then
it should provide a neat transparent migration mechanism for encrypted
passwords. If it doesn't work then finding out why will be interesting :-)
> Interesting possibility, but I'd like something more transparent.
Remember
> the reason we have Windows on the desktops is that it is supposed to be
> easy. Is NT equally all-or-nothing on the server side or does it accept
either?
The native password storage system in NT is the same as the encrypted password
system used in SMB (big surprise there!) which means NT doesn't have this
problem. It just always says "I want encrypted passwords".
Note that the "I want encryption" bit does not exclude the client
sending
non-encrypted passwords, it just means that they are supported. The client
is free to send non-encrypted passwords if it wants to and the server will
do the encryption once it arrives.
Andrew