I tried upgrading from samba 1.9 to 2.0 on two seperate RedHat servers, and after both upgrades nobody could get authenticated. The windows boxes had the registry hacks to turn off encrypted passwords, and I'm authenticating out of passwd+shadow. I found many similiar posts on DejaNews and in the samba mailing list archives. I broke out strace and found the problem. Samba 2.0 tries to open: /etc/pam.d/samba and failing (since it doesn't exist on any box I've ever seen) opens /etc/pam.d/other The contents of which are: #%PAM-1.0 auth required /lib/security/pam_deny.so account required /lib/security/pam_deny.so password required /lib/security/pam_deny.so session required /lib/security/pam_deny.so The authentication fails. So I created the file /etc/pam.d/samba with this content: #%PAM-1.0 auth required /lib/security/pam_pwdb.so shadow account required /lib/security/pam_pwdb.so password required /lib/security/pam_pwdb.so shadow use_authtok session required /lib/security/pam_pwdb.so Now Samba 2.0 works and everyone can authenticate! You probably want to add this to your FAQ, like I said I've seen dozens of posts regarding this issue (some on FreeBSD w/PAM). Dax Kelson Internet Connect, Inc.
Steve Grose
1999-Jan-27 19:26 UTC
Samba 2.0 RedHat/PAM password troubles found and solved!
With the author's permission, I am posting this message here that was originally posted on the redhat newsgroup:> I tried upgrading from samba 1.9 to 2.0 on two seperate RedHat servers, > and after both upgrades nobody could get authenticated. The windows boxes > had the registry hacks to turn off encrypted passwords, and I'm > authenticating out of passwd+shadow. > > I found many similiar posts on DejaNews and in the samba mailing list > archives. > > I broke out strace and found the problem. > > Samba 2.0 tries to open: > > /etc/pam.d/samba and failing (since it doesn't exist on any box I've > ever seen) > > opens > > /etc/pam.d/other > > The contents of which are: > > #%PAM-1.0 > auth required /lib/security/pam_deny.so > account required /lib/security/pam_deny.so > password required /lib/security/pam_deny.so > session required /lib/security/pam_deny.so > > The authentication fails. > > So I created the file /etc/pam.d/samba > > with this content: > > #%PAM-1.0 > auth required /lib/security/pam_pwdb.so shadow > account required /lib/security/pam_pwdb.so > password required /lib/security/pam_pwdb.so shadow use_authtok > session required /lib/security/pam_pwdb.so > > Now Samba 2.0 works and everyone can authenticate! > > You probably want to add this to your FAQ, like I said I've seen dozens of > posts regarding this issue (some on FreeBSD w/PAM).
Stephen L Arnold
1999-Jan-28 00:01 UTC
Samba 2.0 RedHat/PAM password troubles found and solved!
When the world was young, Dax Kelson carved some runes like this:> Samba 2.0 tries to open: > > /etc/pam.d/samba and failing (since it doesn't exist on any box I've ever > seen) > > opens > > /etc/pam.d/otherI beg to differ ;-) All the RedHat boxes I've been using with samba (RH 4.2 and 5.2) all have the /etc/pam.d/samba file, but it only contains the two following lines: #%PAM-1.0 auth required /lib/security/pam_pwdb.so shadow nullok account required /lib/security/pam_pwdb.so Your password line in /etc/pam.d/samba means it won't look in smbpasswd, right? What about the "nullok" switch? I'm certainly clueless about most of this stuff (but I'm trying to learn, honest), and PAM configuration is one of them. Any advice on integrating PAM/shadow/samba(w/encrypted passwords) with SRP and the associated exponential password suite would be greatly appreciated. According to the docs, the SRP password tools (EPS) can be installed as a PAM module (and can be used to athenticate whatever services one wants). All this is pretty confusing though (my tiny brain can only hold so much before it overflows). For example: I was trying to compile 1.9.18p10 the other night at home, and I couldn't find a set of compile options for glibc (libc6) with both PAM and shadow support. As I understand it, after converting your /etc/passwd to /etc/shadow all the other commands (adduser, etc) should then use the shadow file transparently (ie, they should work just like they did before). Does that mean I can just add the -DSHADOW_PWD or do I need to add the -lshadow lib support too? It looks like the libc5 setup uses the shadow lib, but the libc6 setup doesn't. Is that correct? Thanks in advance for any pointers, etc, etc. **************************************************************** Stephen L. Arnold Senior Systems Engineer ENSCO Inc. email: arnold.steve@ensco.com P.O. Box 5488 www: http://www.ensco.com Vandenberg AFB, CA 93437 voice: 805.734.8232 x68838 fax: 805.734.4779 #include <std_disclaimer.h> ****************************************************************
Jandeep S Kang wrote:> > > > Hi, > > we have installed samba 2.0.0 under solaris. when we try > > to copy a large directory around 160MB to a folder on samba > > it stops in the middle with a message like "session > > cancelled". what is this? did anybody experience the same > > behaviour. i assume some setting is wrong in the smb.conf > > or is it something else?? > > thanks.Andrew Williamson <andrew.williamson@highland.gov.uk> replied> I a similar problem once - it actually turned out to be a fault in the > network cabling of UTP. Only 3 wires out of 4 were connected and it > worked for small files, but anything large killed it which was very > strange. I would have thought it would either work or not at all. > > It could also be the bus mastering on a 3com 3c590 card if you have one. > Check ms support article Q139731 if you use the above network card at > http://support.microsoft.comIf this is taking more than a minute, suspect the "45 second tiumeout" feature of the MS client. If the transmission is suffering from problems, and goes into heavy retransmits, it cxan take more that the 45 second maximum time allowed between smb ACKs by ms clients. In the case of "raw" transfers, this **could** mean that any file that takes more than 45 seconds to transmit will time out. That Would Be Bad (:-)) As a **pure experiment**, see if "read raw = no" causes the problem to go away. If it does, suspect an underlying problem triggering the timeout and start checking hardware. --dave -- David Collier-Brown, | Always do right. This will gratify some people 185 Ellerslie Ave., | and astonish the rest. -- Mark Twain Willowdale, Ontario | http://java.science.yorku.ca/~davecb Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb@canada.sun.com