I would set up your server as a Samba AD and use the directory. Give each user a username and password on the server that they will authenticate to the server with and when they connect the permissions will act as you are expecting. Joining the machines to the domain is not necessary; it simply integrates the workstation with the server so that the user doesn’t have to enter the credentials manually to connect to resources. We use hundreds of non-domain joined Macs to connect to a Samba4 DC-based file server. I hope this helps. Thomas Maerz Network/Systems Engineer> On Feb 18, 2016, at 9:29 AM, Andy Smith <a.smith at ldex.co.uk> wrote: > > > > Thanks for your reply Rowland. I don't think I managed to get my > question across very well on the first attempt. I still really need to > know 2 things: > > 1) Can I see and modify permissions on a Samba share from a PC (either a > domain member or not, please provide detail). I have tested this with a > non domain member and it seems to be not possible, is it just me or is > this expected behaviour. With a domain member will this work as smoothly > as a real windows server (assuming Linux install with ACL ext4 file > system)? Ie open folder permissions from client and add/modify > user/group permissions. > > 2) Is there a reason to install Samba as standalone rather than AD? I > ask as obviously AD systems allow access to non domain members, and it > seems AD is now the mainstream where Samba is concerned, its no skin off > my nose to install as AD. > > thanks again, Andy. > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba
On 18/02/16 17:55, Thomas Maerz wrote:> I would set up your server as a Samba AD and use the directory. Give each user a username and password on the server that they will authenticate to the server with and when they connect the permissions will act as you are expecting. Joining the machines to the domain is not necessary; it simply integrates the workstation with the server so that the user doesn’t have to enter the credentials manually to connect to resources. We use hundreds of non-domain joined Macs to connect to a Samba4 DC-based file server. > > I hope this helps. > > Thomas Maerz > Network/Systems Engineer > >That simply doesn't make sense, why go to all the trouble of setting up a Samba4 AD DC and then just use it as a fileserver ? You might as well just set up Samba as a standalone server with ldap. Rowland
Well, in my opinion, setting up a S4 DC is relatively easy. I’ve actually had more troubles setting up member servers. It’s already integrated with the file server, and you can manage it with the MS tools and manage file permissions from the same place. If he already has an LDAP server (I’ll bet he doesn’t), what you are describing would also make sense. Otherwise he has to set up an OpenLDAP server which requires more expertise than setting up a S4 AD DC in my opinion. Either solution is much more simple, scalable and maintainable than attempting to add a bunch of users manually to each of his workstations. Provisioning a Samba4 domain controller: Install S4 DC packages execute this command samba-tool domain provision --use-rfc2307 --interactive Follow the prompts Test the DC Install Active Directory Users and Computers plugin on any workstation Create users Create file share Documentation is here: https://wiki.samba.org/index.php/Setup_a_Samba_Active_Directory_Domain_Controller#Provisioning_the_Samba_Active_Directory <https://wiki.samba.org/index.php/Setup_a_Samba_Active_Directory_Domain_Controller#Provisioning_the_Samba_Active_Directory> Samba4’s DC functionality is great! Thomas Maerz Network/Systems Engineer> On Feb 18, 2016, at 12:47 PM, Rowland penny <rpenny at samba.org> wrote: > > On 18/02/16 17:55, Thomas Maerz wrote: >> I would set up your server as a Samba AD and use the directory. Give each user a username and password on the server that they will authenticate to the server with and when they connect the permissions will act as you are expecting. Joining the machines to the domain is not necessary; it simply integrates the workstation with the server so that the user doesn’t have to enter the credentials manually to connect to resources. We use hundreds of non-domain joined Macs to connect to a Samba4 DC-based file server. >> >> I hope this helps. >> >> Thomas Maerz >> Network/Systems Engineer >> >> > > That simply doesn't make sense, why go to all the trouble of setting up a Samba4 AD DC and then just use it as a fileserver ? > > You might as well just set up Samba as a standalone server with ldap. > > Rowland > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba
I know this is old, but I wanted to add one more detail: Samba v3 is deprecated as of March 2015 with the release of Samba 4.2! From the Samba 4.2 release notes: https://wiki.samba.org/index.php/Samba_4.2_Features_added/changed <https://wiki.samba.org/index.php/Samba_4.2_Features_added/changed> "IMPORTANT NOTE ABOUT THE SUPPORT END OF SAMBA 3 With the final release of Samba 4.2, the last series of Samba 3 has been discontinued! People still running 3.6.x or earlier, should consider moving to a more recent and maintained version (4.0 - 4.2). One of the common misconceptions is that Samba 4.x automatically means "Active Directory only": This is wrong! Acting as an Active Directory Domain Controller is just one of the enhancements included in Samba 4.0 and later. Version 4.0 was just the next release after the 3.6 series and contains all the features of the previous ones - including the NT4-style (classic) domain support. This means you can update a Samba 3.x NT4-style PDC to 4.x, just as you've updated in the past (e.g. from 3.4.x to 3.5.x). You don't have to move your NT4-style domain to an Active Directory! And of course the possibility remains unchanged, to setup a new NT4-style PDC with Samba 4.x, like done in the past (e.g. with openLDAP backend). Active Directory support in Samba 4 is additional and does not replace any of these features. We do understand the difficulty presented by existing LDAP structures and for that reason there isn't a plan to decommission the classic PDC support. It remains tested by the continuous integration system. The code that supports the classic Domain Controller is also the same code that supports the internal 'Domain' of standalone servers and Domain Member Servers. This means that we still use this code, even when not acting as an AD Domain Controller. It is also the basis for some of the features of FreeIPA and so it gets development attention from that direction as well.” Thomas Maerz Network/Systems Administrator Brewer Science, Inc. A+ NET+ CCENT MCDST tmaerz at brewerscience.com <mailto:tmaerz at brewerscience.com> work: 573-364-0444 x1402 cell: 573-612-1349 CONFIDENTIALITY NOTICE This message (and any of its attachments) is intended for the addressee and may contain confidential information, may be attorney-client privileged, and may constitute inside or non-public information under federal or state laws. Unauthorized use of this information is strictly prohibited and may be unlawful. If you have received this email transmission in error, please immediately notify the sender by return email, delete the email and any attachments, and empty any folders containing the discarded information.> On Feb 18, 2016, at 3:55 PM, Thomas Maerz <tmaerz at brewerscience.com> wrote: > > Well, in my opinion, setting up a S4 DC is relatively easy. I’ve actually had more troubles setting up member servers. It’s already integrated with the file server, and you can manage it with the MS tools and manage file permissions from the same place. If he already has an LDAP server (I’ll bet he doesn’t), what you are describing would also make sense. Otherwise he has to set up an OpenLDAP server which requires more expertise than setting up a S4 AD DC in my opinion. Either solution is much more simple, scalable and maintainable than attempting to add a bunch of users manually to each of his workstations. > > Provisioning a Samba4 domain controller: > > Install S4 DC packages > execute this command > samba-tool domain provision --use-rfc2307 --interactive > Follow the prompts > Test the DC > Install Active Directory Users and Computers plugin on any workstation > Create users > Create file share > > Documentation is here: https://wiki.samba.org/index.php/Setup_a_Samba_Active_Directory_Domain_Controller#Provisioning_the_Samba_Active_Directory <https://wiki.samba.org/index.php/Setup_a_Samba_Active_Directory_Domain_Controller#Provisioning_the_Samba_Active_Directory> > > Samba4’s DC functionality is great! > > Thomas Maerz > Network/Systems Engineer > >> On Feb 18, 2016, at 12:47 PM, Rowland penny <rpenny at samba.org <mailto:rpenny at samba.org>> wrote: >> >> On 18/02/16 17:55, Thomas Maerz wrote: >>> I would set up your server as a Samba AD and use the directory. Give each user a username and password on the server that they will authenticate to the server with and when they connect the permissions will act as you are expecting. Joining the machines to the domain is not necessary; it simply integrates the workstation with the server so that the user doesn’t have to enter the credentials manually to connect to resources. We use hundreds of non-domain joined Macs to connect to a Samba4 DC-based file server. >>> >>> I hope this helps. >>> >>> Thomas Maerz >>> Network/Systems Engineer >>> >>> >> >> That simply doesn't make sense, why go to all the trouble of setting up a Samba4 AD DC and then just use it as a fileserver ? >> >> You might as well just set up Samba as a standalone server with ldap. >> >> Rowland >> >> -- >> To unsubscribe from this list go to the following URL and read the >> instructions: https://lists.samba.org/mailman/options/samba <https://lists.samba.org/mailman/options/samba> >
On 01/04/16 03:09, Thomas Maerz wrote:> I know this is old, but I wanted to add one more detail: Samba v3 is > deprecated as of March 2015 with the release of Samba 4.2! From the > Samba 4.2 release notes: > https://wiki.samba.org/index.php/Samba_4.2_Features_added/changed > > "IMPORTANT NOTE ABOUT THE SUPPORT END OF SAMBA 3 > With the final release of Samba 4.2, the last series of Samba 3 has > been discontinued! People still running 3.6.x or earlier, should > consider moving to a more recent and maintained version (4.0 - 4.2). > One of the common misconceptions is that Samba 4.x automatically means > "Active Directory only": This is wrong! > Acting as an Active Directory Domain Controller is just one of the > enhancements included in Samba 4.0 and later. Version 4.0 was just the > next release after the 3.6 series and contains all the features of the > previous ones - including the NT4-style (classic) domain support. This > means you can update a Samba 3.x NT4-style PDC to 4.x, just as you've > updated in the past (e.g. from 3.4.x to 3.5.x). You don't have to move > your NT4-style domain to an Active Directory! > And of course the possibility remains unchanged, to setup a new > NT4-style PDC with Samba 4.x, like done in the past (e.g. with > openLDAP backend). Active Directory support in Samba 4 is additional > and does not replace any of these features. We do understand the > difficulty presented by existing LDAP structures and for that reason > there isn't a plan to decommission the classic PDC support. It remains > tested by the continuous integration system. > The code that supports the classic Domain Controller is also the same > code that supports the internal 'Domain' of standalone servers and > Domain Member Servers. This means that we still use this code, even > when not acting as an AD Domain Controller. It is also the basis for > some of the features of FreeIPA and so it gets development attention > from that direction as well.” > > Thomas Maerz > Network/Systems Administrator > Brewer Science, Inc. > A+ NET+ CCENT MCDST > tmaerz at brewerscience.com <mailto:tmaerz at brewerscience.com> > work: 573-364-0444 x1402 > cell:573-612-1349 > > CONFIDENTIALITY NOTICE > This message (and any of its attachments) is intended for the > addressee and may contain confidential information, may be > attorney-client privileged, and may constitute inside or non-public > information under federal or state laws. Unauthorized use of this > information is strictly prohibited and may be unlawful. If you have > received this email transmission in error, please immediately notify > the sender by return email, delete the email and any attachments, and > empty any folders containing the discarded information. > >> On Feb 18, 2016, at 3:55 PM, Thomas Maerz <tmaerz at brewerscience.com >> <mailto:tmaerz at brewerscience.com>> wrote: >> >> Well, in my opinion, setting up a S4 DC is relatively easy. I’ve >> actually had more troubles setting up member servers. It’s already >> integrated with the file server, and you can manage it with the MS >> tools and manage file permissions from the same place. If he already >> has an LDAP server (I’ll bet he doesn’t), what you are describing >> would also make sense. Otherwise he has to set up an OpenLDAP server >> which requires more expertise than setting up a S4 AD DC in my >> opinion. Either solution is much more simple, scalable and >> maintainable than attempting to add a bunch of users manually to each >> of his workstations. >> >> Provisioning a Samba4 domain controller: >> >> Install S4 DC packages >> execute this command >> samba-tool domain provision --use-rfc2307 --interactive >> Follow the prompts >> Test the DC >> Install Active Directory Users and Computers plugin on any workstation >> Create users >> Create file share >> >> Documentation is here: >> https://wiki.samba.org/index.php/Setup_a_Samba_Active_Directory_Domain_Controller#Provisioning_the_Samba_Active_Directory >> >> Samba4’s DC functionality is great! >> >> Thomas Maerz >> Network/Systems Engineer >> >>> On Feb 18, 2016, at 12:47 PM, Rowland penny <rpenny at samba.org >>> <mailto:rpenny at samba.org>> wrote: >>> >>> On 18/02/16 17:55, Thomas Maerz wrote: >>>> I would set up your server as a Samba AD and use the directory. >>>> Give each user a username and password on the server that they will >>>> authenticate to the server with and when they connect the >>>> permissions will act as you are expecting. Joining the machines to >>>> the domain is not necessary; it simply integrates the workstation >>>> with the server so that the user doesn’t have to enter the >>>> credentials manually to connect to resources. We use hundreds of >>>> non-domain joined Macs to connect to a Samba4 DC-based file server. >>>> >>>> I hope this helps. >>>> >>>> Thomas Maerz >>>> Network/Systems Engineer >>>> >>>> >>> >>> That simply doesn't make sense, why go to all the trouble of setting >>> up a Samba4 AD DC and then just use it as a fileserver ? >>> >>> You might as well just set up Samba as a standalone server with ldap. >>> >>> Rowland >>> >>> -- >>> To unsubscribe from this list go to the following URL and read the >>> instructions: https://lists.samba.org/mailman/options/samba >> >Old, this topic is that old, that another version of Samba (4.1) has gone EOL since the last post. Rowland