>> 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 accepteither? 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
A non-text attachment was scrubbed... Name: not available Type: text Size: 1544 bytes Desc: not available Url : lists.samba.org/archive/samba/attachments/19971016/b3d17143/attachment.bat
>> 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. > > OK, that's the quick fix! Can you make samba continue to accept > non-encrypted passwords and use its original scheme in addition > to handling encrypted ones so all the old clients don't fail just > because I need to support the new ones? If we can migrate automaticallySamba already does that. It's a required part of the specification. "old" clients, meaning clients that don't support encryption at all, will work no matter what you put in smb.conf. Perhaps you don't realise that all versions of Windows95 and WindowsNT support encryption? Not just the recent patches. The change that Microsoft made in the SP3 patch to NT and in recent patches to Win95 is that by default the client refuses to talk to servers that don't support encryption. Earlier versions would just obey the "support encryption" bit of the negprot response and act accordingly. The possible "solutions" to this problem are: 1) modify the registry on your clients so that they will talk to non-encrypting servers again. This isn't as painful as it sounds as you can just double-click on the supplied Win95_PlainPassword.reg or NT4_PlainPassword.reg files that come with Samba. OR 2) add encryption support to Samba and convert all your users to encrypted passwords. We will be trying to make this option less painful in the future. In 1.9.18 the encryption code is standard in the main source code and will be compiled in by default. You just need to enable it in smb.conf. We also hope to add a automatic migration system at some stage, as has been discussed here before. OR 3) Use a "password server" and security=server OR 4) Give your Samba server two names (on the one machine), with different configuration files. One config file will support encryption and the other won't. Users that haven't converted yet can use the non-encrypting server name. Use the "include = /etc/smb.conf.%m" syntax to implement this. Andrew config file
A non-text attachment was scrubbed... Name: not available Type: text Size: 1556 bytes Desc: not available Url : lists.samba.org/archive/samba/attachments/19971016/6694600d/attachment.bat