A non-text attachment was scrubbed... Name: not available Type: text Size: 721 bytes Desc: not available Url : http://lists.samba.org/archive/samba/attachments/19971011/5242fca6/attachment.bat
Luke Kenneth Casson Leighton
1997-Oct-12 11:53 UTC
Encrypted and cleartext at the same time?
On Sun, 12 Oct 1997, Leslie Mikesell wrote:> Is it possible to make samba accept both cleartext and encrypted > passwords, and continue to match the cleartext against the > unix password file?well... you could _possibly_ do it by ip address or by some form of hack based on the "hosts allow" code (@netgroup) like this: encrypt hosts = @group_1 or cleartext hosts = @group_2 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. oops. an alternative would be to have two NetBIOS names for your server. have "include = smb.conf.%M", and in smb.conf.SERVER_ENC have one line "encrypted passwords = yes". then ask people to use the other NetBIOS name when connecting from NT SP3. apart from anything, they'll find that they _can't_ connect to the old name. alternatively, you could create deliberate inconvenience for your users by renaming your server to SERVER_CLR. if people didn't want to rename their shares, then they could upgrade to SP3. this has the advantage that by the time your users have finished upgrading, your server name doesn't change: you can just get rid of smb.conf.SERVER_CLR (with a single entry of "encrypted passwords = no"). luke> I'd like to add the encrypted capability > but not force everyone to updated their password on the same > day. What would be ideal would be if samba could automatically > create/update the new-style encrypted entry after validating a > clear text password against the unix password file.oo! hey, i _like_ this idea!!!! "migrate passwords = yes" automatically generates entries in smbpasswd. once verified, you still have the clear-text password, from which you can generate an smbpasswd entry. you still have the problem above (you would have to have your users connecting for a day or two, which gives you the chance to auto-generate the smbpasswd entries) namely that you have to ask users to connect to a different netbios name to _use_ encrypted passwords. intriguing and thought-provoking, les. thanks. <a href="mailto:lkcl@switchboard.net" > Luke Kenneth Casson Leighton </a> <a href="http://mailhost.cb1.com/~lkcl"> Lynx2.7-friendly Home Page </a> <br><b> "Apply the Laws of Nature to your environment before your environment applies the Laws of Nature to you" </b>
> From: Leslie Mikesell <les@Mcs.Net> > just work transparently. How are other people dealing with the > problem of keeping the system and samba passwords in sync as > users change them and expect the same one to work for POP, etc.?I've replaced passwd with a combination of perl and expect that authenticates a user and calls various other programs to set passwords. (I've got samba encrypted passwords, apache passwords and APOP passwords.) I also put a https front end on it, since the system password for almost all the users is '*'. It's ugly and kludgey, but it does work. -- Michael Stone, Sysadmin, ITRI PGP: key 1024/76556F95 from mit keyserver, mstone@itri.loyola.edu finger, or email with "Subject: get pgp key"
At 06:03 PM 10/13/97 +1000, you wrote:>> I'd like to add the encrypted capability >> but not force everyone to updated their password on the same >> day. What would be ideal would be if samba could automatically >> create/update the new-style encrypted entry after validating a >> clear text password against the unix password file. > >oo! hey, i _like_ this idea!!!! "migrate passwords = yes" automatically >generates entries in smbpasswd. once verified, you still have the >clear-text password, from which you can generate an smbpasswd entry.Are you talking about wishes here, or an already included option? I did not find this "migrate passwords" option, and my testparm (v.1.9.17p2) complains about it if I put it in the smb.conf file. I would certainly agree with an option like this. I could imagine it in the following way: 1. An option like require encryption = yes/no to specify if you allow only encrypted authentication or clear text too. 2. If "require encryption = no", then smbd would authenticate against smbpasswd first, if there is no entry for the user in smbpasswd then tries to authenticate using standard Unix passwords and fill in the appropriate the smbpasswd file entry, and if this fails then rejects then connection. Of course it would work only if you compiled Samba with -DUSE_LIBDES option (and others), and have encrypt passwords = yes in smb.conf. This would work transparently to the user, if you set "require encryption no": 1. If the user already has a valid password entry in the smbpasswd file, then authentication is done using encrypted passwords. 2. If the user does not have a valid password entry in the smbpasswd file, then authentication is done using standard Unix passwords, smbd fills out the password entry in the smbpasswd file, and any time after that the authentication will work according to 1. Summary: An administrator could allow "require encryption = no" for a couple of days/weeks so that the entries in the smbpasswd file are filled in as the users are using Samba, then setting "require encryption = yes" would work as it works now with "encrypt passwords = yes": only allowing encypted authentication. What do you think? Geza ************************************************************************* * Name: Geza Makay * * Institute: Jozsef Attila University of Szeged * * Mail: Bolyai Institute, Aradi vertanuk tere 1. * * H-6720, Szeged, Hungary * * Tel: (62) 454-091 (Hungary's code: 36) * * Fax/Message: (62) 326-246 (Hungary's code: 36) * * E-mail: makayg@math.u-szeged.hu * * World Wide Web: http://www.math.u-szeged.hu/ * ************************************************************************* * "To err is human, but to really mess things up you need a computer." * *************************************************************************