Hello, I have been using Fedora Core, Samba, and Active Directory to provide authentication services for Windows based users for a few years now, but as an experiment I wanted to accomplish the same service with SUSE 9.3 . I have been able to get this configuration to run successfully with RH9, FC1, FC2, FC3, and FC4 (buggy but works), but with SUSE I have stalled a bit. I feel I have Samba+SUSE 9.3 running about 90% with only winbind and pam restrictions holding up the other 10% (nscd disabled of course). I can use all the wbinfo tricks (-a -g -t -u) to lookup users in AD, which suggests everything is working as it should; however, when I attempt to access a home folder for an established user in the directory I am prompted for a password. So, of course I tried googling and the Samba howto for a light bulb inspiring thought, but the answer eludes me. I did come across this site which caught my eye... http://www-uxsup.csx.cam.ac.uk/pub/doc/suse/suse9.3/suselinux-adminguide_en/sec.update.version.html 4.2.3.16. From Samba 2.x to Samba 3.x Following the update from Samba 2.x to Samba 3.x, winbind authentication is no longer available. The other authentication methods can still be used. For this reason, the following programs have been removed: /usr/sbin/wb_auth /usr/sbin/wb_ntlmauth /usr/sbin/wb_info_group.pl Is this true? Will I not be able to use winbind authentication with SUSE 9.3? Does this rule apply only during the update? The system-auth stacks are setup a little differently in SUSE 9.3 in relation to Fedora Core. I now see common-auth common-account common-session and common-password for SUSE. I realized they use includes to call the separated statements that are normally bundled together in Fedora's system-auth file. I did not think it would be too hard to modify the common-* files and login for use with winbind as I had with Fedora. I was wrong. :( Anyway, I am using SUSE 9.3 all patched up with Samba 3.020101. The server is not a production server, so if I have to downgrade or play a bit it is all good. I have a working /etc/pam.d/login and /etc/pam.d/system-auth configuration that I use for Fedora to enforce the pam restrictions I require. pam.d login #%PAM-1.0 auth required pam_securetty.so auth required pam_stack.so service=system-auth auth required pam_nologin.so account sufficient pam_winbind.so account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session required pam_stack.so service=system-auth session optional pam_console.so # pam_selinux.so open should be the last session rule session required pam_selinux.so multiple open pam.d system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_winbind.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok use_first_pass auth required /lib/security/$ISA/pam_deny.so account sufficient /lib/security/$ISA/pam_winbind.so account required /lib/security/$ISA/pam_unix.so account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet account required /lib/security/$ISA/pam_permit.so password requisite /lib/security/$ISA/pam_cracklib.so retry=3 password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so Since I am new to SUSE it would be of great help if someone could translate the winbind calls used in Fedora's login and system-auth to SUSE's common-* and login files. I also came across this site, http://www.billboswellconsulting.com/addl_Linux_Info_authenticating_suse.html, which didn't mention the login or system-auth, but did use /etc/security/pam_unix2.conf (SUSE 9.1). Should I head in the direction below? The actual path is /etc/security/pam_unix2.conf. You'll need to modify the auth and account lines to show call_modules=winbind. If you neglect to make this change, you won't be able to login using Active Directory credentials. auth: call_modules=winbind account: call_modules=winbind password: session: none Thanks ahead of time for any responses, Guille
Well, once again I think I was able to figure out my own problem, which is impatience. I decided to bypass SWAT and manually configure my smb.conf file. That is when the magic began to start. If I recall correctly in Fedora, the default smb.conf file does not include the Valid Users = %S for the Home share. Once I removed that setting in SUSE to match my Fedora config that is things fell into place. The modified winbind statements worked when I placed them where I thought they ought to go. So I am almost completely happy. So now I am at 99%. When I figure out why I can't get to my share from a VPN client as I can with Fedora I'll be at 100%. Taking my time, Guille -----Original Message----- From: samba-bounces+guillemw=hotmail.com@lists.samba.org [mailto:samba-bounces+guillemw=hotmail.com@lists.samba.org] On Behalf Of Guille Williams Sent: Monday, July 11, 2005 2:01 PM To: samba@lists.samba.org Subject: [Samba] SUSE 9.3 Winbind+ PAM+AD Hello, I have been using Fedora Core, Samba, and Active Directory to provide authentication services for Windows based users for a few years now, but as an experiment I wanted to accomplish the same service with SUSE 9.3 . I have been able to get this configuration to run successfully with RH9, FC1, FC2, FC3, and FC4 (buggy but works), but with SUSE I have stalled a bit. I feel I have Samba+SUSE 9.3 running about 90% with only winbind and pam restrictions holding up the other 10% (nscd disabled of course). I can use all the wbinfo tricks (-a -g -t -u) to lookup users in AD, which suggests everything is working as it should; however, when I attempt to access a home folder for an established user in the directory I am prompted for a password. So, of course I tried googling and the Samba howto for a light bulb inspiring thought, but the answer eludes me. I did come across this site which caught my eye... http://www-uxsup.csx.cam.ac.uk/pub/doc/suse/suse9.3/suselinux-adminguide_en/ sec.update.version.html 4.2.3.16. From Samba 2.x to Samba 3.x Following the update from Samba 2.x to Samba 3.x, winbind authentication is no longer available. The other authentication methods can still be used. For this reason, the following programs have been removed: /usr/sbin/wb_auth /usr/sbin/wb_ntlmauth /usr/sbin/wb_info_group.pl Is this true? Will I not be able to use winbind authentication with SUSE 9.3? Does this rule apply only during the update? The system-auth stacks are setup a little differently in SUSE 9.3 in relation to Fedora Core. I now see common-auth common-account common-session and common-password for SUSE. I realized they use includes to call the separated statements that are normally bundled together in Fedora's system-auth file. I did not think it would be too hard to modify the common-* files and login for use with winbind as I had with Fedora. I was wrong. :( Anyway, I am using SUSE 9.3 all patched up with Samba 3.020101. The server is not a production server, so if I have to downgrade or play a bit it is all good. I have a working /etc/pam.d/login and /etc/pam.d/system-auth configuration that I use for Fedora to enforce the pam restrictions I require. pam.d login #%PAM-1.0 auth required pam_securetty.so auth required pam_stack.so service=system-auth auth required pam_nologin.so account sufficient pam_winbind.so account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session required pam_stack.so service=system-auth session optional pam_console.so # pam_selinux.so open should be the last session rule session required pam_selinux.so multiple open pam.d system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_winbind.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok use_first_pass auth required /lib/security/$ISA/pam_deny.so account sufficient /lib/security/$ISA/pam_winbind.so account required /lib/security/$ISA/pam_unix.so account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet account required /lib/security/$ISA/pam_permit.so password requisite /lib/security/$ISA/pam_cracklib.so retry=3 password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so Since I am new to SUSE it would be of great help if someone could translate the winbind calls used in Fedora's login and system-auth to SUSE's common-* and login files. I also came across this site, http://www.billboswellconsulting.com/addl_Linux_Info_authenticating_suse.htm l, which didn't mention the login or system-auth, but did use /etc/security/pam_unix2.conf (SUSE 9.1). Should I head in the direction below? The actual path is /etc/security/pam_unix2.conf. You'll need to modify the auth and account lines to show call_modules=winbind. If you neglect to make this change, you won't be able to login using Active Directory credentials. auth: call_modules=winbind account: call_modules=winbind password: session: none Thanks ahead of time for any responses, Guille -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba -- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.11/45 - Release Date: 7/9/2005 -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.12/46 - Release Date: 7/11/2005
Hi Anthony, Well, I will try and give you my quick and dirty setup for FC3. The procedure should work with FC4 as well. I don't trust the Samba build Fedora included with FC4 just yet because of output garbage I received on a production server while joining the domain. Although the join was successful, I was troubled by the message. While I have been able to figure out some of the problems I have had in the past, I still feel I am a semi-newbie at this stuff. So those who read this please don't flame me if I am opening up holes in security or making some other mistake. My basic setup... Windows 2000 Server running in Native mode I think (it has been a while). Fedora core 3, Samba 3.0.14a running in ADS mode with Kerberos, and Pam for automatic home directory creation. I am assuming you already have Samba(FC4>client,common,swat,samba)installed so.... Step 1 (Most likely accomplished) Open the firewall ports tcp 139 & 445, udp 137 & 138, and include the Windows server in your host file for proper name resolution. Step 2 (Skip if you choose Server = Domain) Configure Kerberos Edit the following files /etc/krb.conf /etc/krb.realms /etc/krb5.conf /var/kerberos/krb5kdc/kdc.conf and modify the example.com/EXAMPLE.COM domain so that they match your Kerberos realm and server. You may only have to modify krb5.conf and kdc.conf for Kerberos to work properly. Step 3 Edit /etc/nsswitch.conf and add winbind to passwd and group. passwd: files winbind shadow: files group: files winbind Step 4 Modify pam.d files /etc/pam.d/login #%PAM-1.0 auth required pam_securetty.so auth required pam_stack.so service=system-auth auth required pam_nologin.so account sufficient pam_winbind.so account required pam_stack.so service=system-auth password required pam_stack.so service=system-auth # pam_selinux.so close should be the first session rule session required pam_selinux.so close session required pam_stack.so service=system-auth session optional pam_console.so # pam_selinux.so open should be the last session rule session required pam_selinux.so multiple open /etc/pam.d/system-auth #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_winbind.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok use_first_pass auth required /lib/security/$ISA/pam_deny.so account sufficient /lib/security/$ISA/pam_winbind.so account required /lib/security/$ISA/pam_unix.so account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet account required /lib/security/$ISA/pam_permit.so password requisite /lib/security/$ISA/pam_cracklib.so retry=3 password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so /etc/pam.d/samba auth required /lib/security/pam_stack.so service=system-auth # Automatic Home Directory Creation session sufficient /lib/security/pam_mkhomedir.so skel=/etc/skel umask=0022 session required /lib/security/pam_stack.so service=system-auth account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth Step 5 Edit smb.conf [global] workgroup = (Enter Windows Workgroup Name) realm = (Enter REALM.NAME in caps) server string = Samba Server security = ADS client schannel = No (Had to use NO after Windows 2004 SP4 Rollup) obey pam restrictions = Yes password server = (Enter Windows server FQDN) log file = /var/log/samba/%m.log max log size = 50 socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 printcap name = /etc/printcap logon path = preferred master = No local master = No domain master = No dns proxy = No ldap ssl = no idmap uid = 10000-20000 idmap gid = 10000-20000 template homedir = /home/%U winbind use default domain = Yes admin users = "@Domain Admins" write list = "@Domain Admins" cups options = raw [homes] comment = Home Directories path = /home/%U read only = No create mask = 0760 browseable = No [printers] comment = All Printers path = /var/spool/samba printable = Yes browseable = No Step 6 Watch out for SELinux!!! For testing purposes, go to console and > setenforce 0 This will disable SELinux (if enabled) for the time being so that the winbind transactions aren't blocked. setenforce 1 to restart SELinux protection. To permanently allow the winbind transactions, use the Security Level program in Gnome/KDE and check the winbind_disable_trans setting. Step 7 Join the Domain net ads join -U Administrator net join -U Administrator (if Server = Domain) Step 8 Start smbd nmbd and winbindd Step 9 If all went well you have successfully joined the Windows domain. Test access to accounts wbinfo -t checking the trust secret via RPC calls succeeded (This is GOOD) wbinfo -u Should spew out usernames in Windows Wbinfo -g Should spew out groups in Windows In the past I have needed to restart the Windows server at least once after joining for it to allow lookups (Don't know why???). Step 10 This is where Windows gets involved. Make sure you add the linux host as a DNS entry in the Windows server. Restart DNS. Create a new user or modify a current user in AD for testing purposes and change the Home Directory, eg. H: \\linux\home (probably not necessary though). Next, login with the username on a Windows 2K/XP Workstation that has previously joined the domain. See if the share appears while browsing the linux server, eg. \\linux\fred My AD config is a bit more involved, as I use group policy, netlogon, and such for control and mounts. All that info is way out of the scope of this email so I won't go into that here. Hopefully this helps. I am not an expert, but if you run into a problem that I have seen before I might be able to help out. Guille -----Original Message----- From: Anthony PEROT - Generation Unix [mailto:apero@generation-unix.net] Sent: Tuesday, July 12, 2005 5:47 AM To: Guille Subject: RE: [Samba] SUSE 9.3 Winbind+ PAM+AD Hi, I'm running a few workstations on FC4 and I would like to find a way to use AD users accounts and groups instead of local users, could you give me your procedure ? Thanks Anthony -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.8.13/47 - Release Date: 7/12/2005