Dear All, We are trying to transfer a SaMBa installation from an old server to a newer more up-to-date one. The original server was sharing files to Windows XP systems in Active Directory (Windows Server 2003 R2 version), but as we move to Windows 7 and Active Directory (Windows Server 2008 R2 version) we need to upgrade the service. The old server was part of a NIS domain, with the "valid users", "write list", etc entries in its smb.conf referring to the NIS groups using the "@" sign (which the documentation says it means "is interpreted as an NIS netgroup first (if your system supports NIS), and then as a UNIX group if the name was not found in the NIS netgroup database"; see http://samba.org/samba/docs/man/manpages-3/smb.conf.5.html#INVALIDUSERS). It all worked fine as it picked users' group membership from NIS. The new server is a Solaris 10 box running SaMBa 3.5.5, and we are having problems with it picking up the group memberships. The old server's smb.conf was transplanted to the new server (with a few path changes), and the new server was successfully added to our Active Directory domain. As the new server is NOT a member of NIS, we made a copy of all the smb.conf-relevant groups to its local /etc/group and added all the users to the /etc/passwd file. With these changes we can access the shares using the AD usernames and passwords as long as they are not access-limited by "valid users", so the integration of the server into AD is working. But if we add a "valid users = @group" line to the share in smb.conf, it will completely refuse access to all users, even the ones belonging to the group. Leaving the share accessible to all, but adding a "write list = @group" line to smb.conf, will allow access, but no one will be able to write to it, even the members of the group. If we change the "write list" and "valid users" lines to list the usernames directly instead of through a group membership, it works. To avoid even attempting to talk to NIS, we changed the "@" signs for "+", but it still kept refusing to recognize group memberships (NIS or local UNIX ones). So it seems our new SaMBa is having problems recognizing group memberships. What am I doing wrong? Have SUN/Oracle done something to stop SaMBa accessing its local UNIX groups? Thank you for your help. Yours, David del Campo
Dear Michal, The user authentication must be being handled by AD; the local accounts on the new server have been added to the /etc/passwd and /etc/shadow files, but the passwords in the /etc/shadow file are set to locked (which means that though the account exists and can own files, people cannot actually log in to the system; root can "su" to them though). As a result AD must be providing the authentication. The usernames in AD and the local files are the same. The /etc/nsswitch.conf file is as follows (comments removed): passwd: files group: files hosts: files dns ipnodes: files dns networks: files protocols: files rpc: files ethers: files netmasks: files bootparams: files publickey: files netgroup: files automount: files aliases: files services: files printers: user files auth_attr: files prof_attr: files project: files tnrhtp: files tnrhdb: files As you can see anything should be handled by the local files. The /etc/samba/smb.conf file is as follows (comments and private removed): [global] workgroup = <removed> server string = Samba Server on %h netbios name = <removed> security = ADS hosts allow = <removed> guest account = nobody log file = /var/samba/log/log.%m max log size = 500 password server = <removed>, <removed> realm = <removed> passdb backend = smbpasswd interfaces = <removed> local master = no os level = 33 domain master = no preferred master= no dns proxy = no [transit] comment = Temporary Backup for Windows 7 Upgrades path = <removed> browseable = no read only = yes valid users = user1, user2, user3, user4 # valid users = @group write list = users1, user2, user3, user4 # write list = +sysman As is, the share works, but as you can see I have to specify the usernames and cannot use +group or @group notation as I did on the old server. The old server was also part of the AD domain, so as far as I can see the only differences between the two setups is the SaMBa version and the fact the new server is not part of NIS; that is why I tried the +group notation, to no avail. I also have a Linux (Fedora 14) machine acting as a temporary SaMBa server (version 3.5.8); it is part of the NIS and AD domains and the @group assignments work fine from NIS. Thank you for your help. Yours, David> -----Original Message----- > From: Michal Belica [mailto:beli+smb at beli.sk] > Sent: 20 May 2011 14:46 > To: F. David del Campo Hill > Subject: Re: [Samba] Problems with group assignments > > Hi, > > ----- Original Message ----- > > From: "F. David del Campo Hill" <delcampo at stats.ox.ac.uk> > > Sent: Friday, May 20, 2011 2:43:49 PM > [...snip...] > > path changes), and the new server was successfully added to our > > Active Directory domain. As the new server is NOT a member of > NIS, > > we made a copy of all the smb.conf-relevant groups to its local > > /etc/group and added all the users to the /etc/passwd file. With > > these changes we can access the shares using the AD usernames and > > passwords as long as they are not access-limited by "valid > users", > > so the integration of the server into AD is working. But if we > add > > a "valid users = @group" line to the share in smb.conf, it will > > Are you using local or AD users and groups or are you mixing them? You > say you have joined the server to AD and also added users and groups to > /etc/passwd and /etc/group. But when a user connects to the Samba > server from Win, (probably) his AD account is used, but in /etc/group, > the members are the local users, which need not be the same (depends on > more factors, like your NS switch settings for example). > Try to check that you're using the AD/local users/groups consistently, > or give more info related to this (e.g. from /etc/nsswitch.conf, > /etc/smb.conf ...). > > -- > Michal Belica - IT consultant > beli+smb at beli.sk | www.beli.sk
What about your ADS? You are authenticate against your ADS?! Why don't use winbind? http://wiki.samba.org/index.php/Samba_&_Active_Directory Good Luck Daniel ----------------------------------------------- EDV Daniel M?ller Leitung EDV Tropenklinik Paul-Lechler-Krankenhaus Paul-Lechler-Str. 24 72076 T?bingen Tel.: 07071/206-463, Fax: 07071/206-499 eMail: mueller at tropenklinik.de Internet: www.tropenklinik.de ----------------------------------------------- -----Urspr?ngliche Nachricht----- Von: samba-bounces at lists.samba.org [mailto:samba-bounces at lists.samba.org] Im Auftrag von F. David del Campo Hill Gesendet: Freitag, 20. Mai 2011 14:44 An: samba at lists.samba.org Betreff: [Samba] Problems with group assignments Dear All, We are trying to transfer a SaMBa installation from an old server to a newer more up-to-date one. The original server was sharing files to Windows XP systems in Active Directory (Windows Server 2003 R2 version), but as we move to Windows 7 and Active Directory (Windows Server 2008 R2 version) we need to upgrade the service. The old server was part of a NIS domain, with the "valid users", "write list", etc entries in its smb.conf referring to the NIS groups using the "@" sign (which the documentation says it means "is interpreted as an NIS netgroup first (if your system supports NIS), and then as a UNIX group if the name was not found in the NIS netgroup database"; see http://samba.org/samba/docs/man/manpages-3/smb.conf.5.html#INVALIDUSERS). It all worked fine as it picked users' group membership from NIS. The new server is a Solaris 10 box running SaMBa 3.5.5, and we are having problems with it picking up the group memberships. The old server's smb.conf was transplanted to the new server (with a few path changes), and the new server was successfully added to our Active Directory domain. As the new server is NOT a member of NIS, we made a copy of all the smb.conf-relevant groups to its local /etc/group and added all the users to the /etc/passwd file. With these changes we can access the shares using the AD usernames and passwords as long as they are not access-limited by "valid users", so the integration of the server into AD is working. But if we add a "valid users = @group" line to the share in smb.conf, it will completely refuse access to all users, even the ones belonging to the group. Leaving the share accessible to all, but adding a "write list = @group" line to smb.conf, will allow access, but no one will be able to write to it, even the members of the group. If we chan ge the "write list" and "valid users" lines to list the usernames directly instead of through a group membership, it works. To avoid even attempting to talk to NIS, we changed the "@" signs for "+", but it still kept refusing to recognize group memberships (NIS or local UNIX ones). So it seems our new SaMBa is having problems recognizing group memberships. What am I doing wrong? Have SUN/Oracle done something to stop SaMBa accessing its local UNIX groups? Thank you for your help. Yours, David del Campo -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba