[Samba] SaMBa and Active Directory Functional Level
Hi all, We have an Active Directory domain with two Windows Server 2008 R2 domain controllers, but our domain functional level is still Windows Server 2003. We would like to raise the functional level to Windows Server 2008 R2, but due to the age of some of our SaMBa installations, I would like to know which is the earliest version of SaMBa which supported Active Directory at the Windows Server 2008 R2 functional level. Raising the functional level is irreversible, and one of the SaMBa installations is on a SUN (now Oracle) server running a version of SaMBa (3.6.8) which is unlikely to be upgraded anytime soon; so if it turns out to be incompatible, we will be in deep trouble. 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
Re: [Samba] Problems with group assignments
Dear All, We finally managed to find out what was wrong: winbind was running! It seems that the SaMBa package we had from SUN/Oracle installed and started winbind (unlike in the old server and the Linux server). Once we disabled winbind (why did it think it was necessary to run winbind in the first place?), it all started working again: usernames and passwords are authenticated against AD, and group membership is checked against the local /etc/group file. Thank you all for your help. Yours, David del Campo PS: Maybe someone should amend the smb.conf man page to the effect that if you run winbind, the system will ignore the @, + and symbols under the (in)valid users and write list tags. -Original Message- From: samba-boun...@lists.samba.org [mailto:samba- boun...@lists.samba.org] On Behalf Of F. David del Campo Hill Sent: 23 May 2011 17:16 To: muel...@tropenklinik.de; samba@lists.samba.org Subject: Re: [Samba] Problems with group assignments Dear Daniel, The usernames and passwords are already authenticating against ADS; the problem is the groups. We want the groups to authenticate against the local UNIX groups, NOT ADS (like the original server did, and the documentation states); having the groups work through ADS will make us have to keep the local and ADS groups synchronized manually, which we do not want to do (the new server is also a NFS server, so we cannot have the two types of groups drift apart). David -Original Message- From: Daniel Müller [mailto:muel...@tropenklinik.de] Sent: 23 May 2011 07:52 To: F. David del Campo Hill; samba@lists.samba.org Subject: AW: [Samba] Problems with group assignments 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: muel...@tropenklinik.de Internet: www.tropenklinik.de --- -Ursprüngliche Nachricht- Von: samba-boun...@lists.samba.org [mailto:samba- boun...@lists.samba.org] Im Auftrag von F. David del Campo Hill Gesendet: Freitag, 20. Mai 2011 14:44 An: samba@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
Re: [Samba] Problems with group assignments
Dear Daniel, The usernames and passwords are already authenticating against ADS; the problem is the groups. We want the groups to authenticate against the local UNIX groups, NOT ADS (like the original server did, and the documentation states); having the groups work through ADS will make us have to keep the local and ADS groups synchronized manually, which we do not want to do (the new server is also a NFS server, so we cannot have the two types of groups drift apart). David -Original Message- From: Daniel Müller [mailto:muel...@tropenklinik.de] Sent: 23 May 2011 07:52 To: F. David del Campo Hill; samba@lists.samba.org Subject: AW: [Samba] Problems with group assignments 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: muel...@tropenklinik.de Internet: www.tropenklinik.de --- -Ursprüngliche Nachricht- Von: samba-boun...@lists.samba.org [mailto:samba- boun...@lists.samba.org] Im Auftrag von F. David del Campo Hill Gesendet: Freitag, 20. Mai 2011 14:44 An: samba@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 -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[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
Re: [Samba] Problems with group assignments
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+...@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 delca...@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+...@beli.sk | www.beli.sk -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] DFS access
Hi all, This is my first message here, so pardon me if I break some etiquette. I have a Linux (Debian 4, kernel 2.6.18-4-686) SaMBa (3.0.24) server whose shares I want to mount on a Distributed File System running from a Windows Server 2003 R2. The share itself is accessible without problems as long as I try to get to it directly (\\smb\share), but if I try to browse through the DFS I get the \\DFS\share is not accessible. You might not have permission to use this network resource... Configuration information could not be read from the domain controller, either because the machine is unavailable, or access has been denied error message. The SaMBa server is part of the Active Directory domain. Also, a similar server with the same software and smb.conf file (different host and share names, of course) works with that same DFS without any problems whatsoever. Both servers are on the same side of the firewall and reside in the same Organizational Unit of Active Directory. The (sanitized) smb.conf file I use is: [global] workgroup= DOMAIN security = ADS netbios name = smb netbios aliases = smb realm= DOMAIN.UK encrypt passwords= yes password server = * server string= Samba shares for smb on %h bind interfaces only = yes hosts allow = *our IP range* interfaces = *smb IP* log file = /var/log/samba/log.%m log level= 1 passdb:2 auth:2 locking = yes lock directory = /var/log/samba/locks pid directory= /var/run private dir = /etc/samba/private username map = /etc/samba/username.map smb passwd file = /etc/samba/private/smbpasswd show add printer wizard = no utmp directory = /var/log encrypt passwords= yes domain master= no preferred master = no guest account= nobody max log size = 1000 syslog = 0 socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192 invalid users= root admin local master = no dns proxy= no panic action = /usr/share/samba/panic-action %d [share] comment = Webservice Documents path = /data/sites/share printable= no browseable = no write list = @sysman valid users = @sysman force user = sysman force group = sysman The log file (sanitized) only reports: [2007/10/12 13:17:45, 0] smbd/map_username.c:map_username(107) can't open username map /etc/samba/username.map. Error No such file or directory [2007/10/12 13:17:45, 1] smbd/sesssetup.c:reply_spnego_kerberos(310) Username STATS\CLIENT$ is invalid on this system Both SaMBa servers have no username.map, and the CLIENT machine works with the other server. Where else should I look for differences between the two SaMBa servers? What is going on? Thank you for your help. David -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
