Hi Is it posible for samba 2.2.2 to get it's passwords from the builit linux passwords (eg /etc/passwd and /etc/shadow) and not it's own smbpasswd? Thanks Marcus Birkin
On Saturday 27 October 2001 6:38 pm, Marcus Birkin wrote:
Hi
Is it posible for samba 2.2.2 to get it's passwords from the builit linux passwords (eg /etc/passwd and /etc/shadow) and not it's own smbpasswd?
Thanks
Marcus Birkin Read up on Winbind - although I believe it is not yet production quality.
Cheers -- Phil Driscoll
On Saturday 27 October 2001 6:38 pm, Marcus Birkin wrote:
Hi
Is it posible for samba 2.2.2 to get it's passwords from the builit
Doesn't winbind just get users/groups from a PDC (or Samba) for use in
Linux..
I need other way round eg. Linux is master, samba is slave
Marcus
----- Original Message -----
From: "Phil Driscoll"
passwords (eg /etc/passwd and /etc/shadow) and not it's own smbpasswd?
Thanks
Marcus Birkin Read up on Winbind - although I believe it is not yet production quality.
Cheers -- Phil Driscoll
On Sat, 27 Oct 2001, Marcus Birkin wrote:
Doesn't winbind just get users/groups from a PDC (or Samba) for use in Linux.. I need other way round eg. Linux is master, samba is slave
Yes, winbind does do it the other way around. Not sure how you coerce Samba into doing this though, because on my distro (Mandrake) it's set up that way to start with. If it helps, I could send you a sample smb.conf file (although there's a lot of other junk in there as well). One thing you will need to do is force the Windows stations to use plain text passwords. See, for example, all the *_PlainPassword.reg files in the docs/ directory of the Samba documentation (probably in /usr/share/doc/samba-VERSION/docs). HTH, Michael Brown Fen Systems Ltd.
On Sat, 27 Oct 2001, Marcus Birkin wrote:
Doesn't winbind just get users/groups from a PDC (or Samba) for use in Linux.. I need other way round eg. Linux is master, samba is slave
Yes, winbind does do it the other way around. Not sure how you coerce Samba into doing this though, because on my distro (Mandrake) it's set up that way to start with. If it helps, I could send you a sample smb.conf file (although there's a lot of other junk in there as well).
One thing you will need to do is force the Windows stations to use
On Saturday, October 27, 2001 7:57 PM Michael Brown wrote: plain
text passwords. See, for example, all the *_PlainPassword.reg files in the docs/ directory of the Samba documentation (probably in /usr/share/doc/samba-VERSION/docs).
Not really. Winbind uses (and unless I missed something last time I looked, requires) encrypted passwords on the wire. And if you actually don't mind unencrypted passwords (though I certainly would) then you don't need Windbind at all. Just don't set a password server in your smb.conf, and Samba will authenticate using the passwd/shadow files of the host it's running on (and if you want pseudo-PDC authentication by this route, you can use NIS to make those files the master authetication source for all your Linux boxes). But why do you want to make Linux authentication primary in this way? Michael --------------------------------------------------------- Michael Beddow http://www.mbeddow.net/ XML and the Humanities page: http://xml.lexilog.org.uk/ Linux in Schools: http://linux.lexilog.org.uk/ The Anglo-Norman Dictionary http://anglo-norman.net/ ---------------------------------------------------------
On Mon, 29 Oct 2001, Michael Beddow wrote:
One thing you will need to do is force the Windows stations to use plain text passwords. See, for example, all the *_PlainPassword.reg files in the docs/ directory of the Samba documentation (probably in /usr/share/doc/samba-VERSION/docs). Not really. Winbind uses (and unless I missed something last time I looked, requires) encrypted passwords on the wire.
I should have made it clearer: you will need to use plain text passwords if you want Samba to authenticate users in the "normal" Linux way (via PAM).
And if you actually don't mind unencrypted passwords (though I certainly would)
AFAIK and FWIW, the "encrypted" passwords that Windows uses are effectively plain-text anyway. If you have an encrypted password then, with a little hacking of the SMB client, you can use the encrypted password without ever needing to know the plain-text password. Disclaimer: my knowledge on this may be out of date or inaccurate. Personally, I prefer to use strong schemes such as Kerberos or SSH for authentication.
But why do you want to make Linux authentication primary in this way?
Why not? Michael
On Monday, October 29, 2001 6:47 PM Michael Brown wrote:
AFAIK and FWIW, the "encrypted" passwords that Windows uses are effectively plain-text anyway. If you have an encrypted password then, with a little hacking of the SMB client, you can use the encrypted password without ever needing to know the plain-text password. Disclaimer: my knowledge on this may be out of date or inaccurate.
Well, there is a security snag over SMB encrypted passwords, but I wouldn't agree it makes then "effectively plain text". If a rogue user gets read access to the smbpasswd file on the server (and of course something has already gone seriously wrong with the sysadmin's security practices if this happens), s/he can indeed use a hacked SMBclient to fool the server into thinking that that client knows the cleartext password of any users in that file. But without access to the smbpasswd file, this cannot be done. Contrast that with the much lower threshold required to gain illicit access on a clear-text system. There our rogue user simply uses a readily-available program to put the NIC on a Win9x client into promiscuous mode and sniff password exchanges. Using this same technique where passwords are SMB encrypted would not work: what goes on the wire and can be sniffed is not the "password-equivalent" string from the smbpasswd file, but the result of using that string as a key to encrypt another, random string. So provided access to the smbpasswd file is prevented, the method is significantly more secure than plain text (which isn't really secure at all).
But why do you want to make Linux authentication primary in this way?
Why not?
Because in an environment where Samba is the principal means by which users access their files on a Linux system (and Markus may or may not have such an environment, which is why I asked) it is arguably preferable to make SMB the primary authentication mode and to manage all non-administrative users as Samba users (only). Of course, all Samba users also need to have (pending full implementation of Winbind) a Linux id as well, but that can be created along with their Samba id, and they need never know they have it. Other servers requiring authentication (e.g. IMAP, POP3, Squid, etc) can be configured to authenticate via PAM to Samba instead of to passwd/shadow. Michael --------------------------------------------------------- Michael Beddow
On Mon, 29 Oct 2001, Michael Beddow wrote:
AFAIK and FWIW, the "encrypted" passwords that Windows uses are effectively plain-text anyway. If you have an encrypted password then, with a little hacking of the SMB client, you can use the encrypted password without ever needing to know the plain-text password. Disclaimer: my knowledge on this may be out of date or inaccurate. Well, there is a security snag over SMB encrypted passwords, but I wouldn't agree it makes then "effectively plain text". If a rogue user gets read access to the smbpasswd file on the server (and of course something has already gone seriously wrong with the sysadmin's security practices if this happens), s/he can indeed use a hacked SMBclient to fool the server into thinking that that client knows the cleartext password of any users in that file. But without access to the smbpasswd file, this cannot be done. Contrast that with the much lower threshold required to gain illicit access on a clear-text system. There our rogue user simply uses a readily-available program to put the NIC on a Win9x client into promiscuous mode and sniff password exchanges. Using this same technique where passwords are SMB encrypted would not work: what goes on the wire and can be sniffed is not the "password-equivalent" string from the smbpasswd file, but the result of using that string as a key to encrypt another, random string. So provided access to the smbpasswd file is prevented, the method is significantly more secure than plain text (which isn't really secure at all).
From what you're saying, it seems as though SMB effectively uses challenge-reponse authentication with a shared secret, where the shared secret is the "encrypted" Windows password. Has the advantage of not sending passwords over the wire in the clear, but has the disadvantage that the password database is, to all practical intents and purposes, a listing of the plain-text passwords. If you manage to snag a copy of the password database (and yes, I have seen this done) then you have everyone's passwords instantly available (unlike if you get hold of /etc/passwd or /etc/shadow). Swings and roundabouts.
As I said, I prefer to use something a little stronger! And I try to mandate use of strong passwords - having seen L0phtcrack retrieve a few hundred in under three seconds I am under no illusions about the ease of cracking most user passwords (Windows or Linux). Michael
But why do you want to make Linux authentication primary in this way?
Because the linux (here FreeBSD, but that's not relevant) password file has been the only authentication system here for more than the past five years. This year we have put in our first NT server, and I have just ordered 20 WTS licences for it, but in order to use it (through www.rdesktop.org) we have to adapt our Samba so that NT WTS logins can use the Samba authentication. There will have to be two password files, but synchronised by offering password changing only through a Web interface that updates both systems. There are already a dozen OSS servers sharing the existing password file through NIS/YP: the problem we are tackling shortly is to add one NT server to this system. -- Christopher Dawkins, Felsted School, Dunmow, Essex CM6 3JG 01371-820527 or 07798 636725 cchd@felsted.essex.sch.uk
participants (5)
-
Christopher Dawkins -
Marcus Birkin -
Michael Beddow -
Michael Brown -
Phil Driscoll