Slackware 14 as File Server on Windows domain with Active Directory
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Slackware 14 as File Server on Windows domain with Active Directory
Hi guys!
I want to configure Slackware 14.0 to serve as file server on Windows domain (Windows Server 2003), so that AD users can access folders on him with certain privileges.
What do I mean exactly:
AD users that belong to certain groups (admins (can do everything), readers (can only read all folders but not write), Gr1 (read/write in appropriate folder), Gr2...) can access folders in this manner ->
FolderForGr1 - only admins and Gr1 have full access, readers can read it, other groups cant read/write in it
FolderForGrX - same but for GrX...
Install - only admins can write, others only read
Public - everyone can read and write (file deletion also)
I was googling for similar scenarios, but couldn't find anything appropriate. Closest was this thread but that brought some new questions...
1. My domain is in form NAME.local and I don't know how that interfere with fields in guides where I have to write YOURDOMAIN/yourdomain or YOUR.DOMAIN/your.domain where caps are important..?
2. Another question, is there an option so that users can authenticate from AD, but that these group privileges for folders are set locally on server?
2.1. What is best way to organize groups when comes to overlapping?
Let's say I want to to grant access to user from Gr1 only to read from FolderForGr2, but not to write in it. If I place it in Gr2 he would be able to write in it, which I don't want. If I place it in group readers he would be able to read from all others folders, which I also don't want...
How to solve this? Creating Gr1Read and Gr1Write groups?
3. File system for that shared hard/partition? Some of the Linux ones or NTFS (in case I have to access it from Windows)? And any possible problems with permissions?
I think that's it so far
And I know some of you might say "dont go with linux/slackware" for this, but I wanna do this the hard way
DarkAbraxas:
And I know some of you might say "dont go with linux/slackware" for this, but I wanna do this the hard way
It's not really a matter of the operating system in this case, but the program to use (and it seems you want Samba).
The Samba configuration for a specific version, if not tampered by the distributor, is the same for the same version no matter which Linux distro or BSD you use.
I don't know too much about Samba but they have extensive documentation which might be able to help you out.
The Samba configuration for a specific version, if not tampered by the distributor, is the same for the same version no matter which Linux distro or BSD you use.
I know that, but it seems like that some distributions have more user friendly workarounds and solutions. Although, most of the guides (regardless what distro) are how to setup easy file share or how to set Samba to act like ADC...
Quote:
Originally Posted by TommyC7
I don't know too much about Samba but they have extensive documentation which might be able to help you out.
I know they have, just like kerberos and so on, but that would be like trying to search the entire big dark cave and all paths that leads out of her, while Im looking for some light to guide me for particular way out
It would be nice if someone created similar setup so I could take a look at those config files and, with little modification, adjust them for my needs...
DarkAbraxas:
It would be nice if someone created similar setup so I could take a look at those config files and, with little modification, adjust them for my needs...
Samba has already done this for people as well. Look for "Samba by Example".
Also, I have no idea what you mean by "more user friendly workarounds and solutions" because different people want different things from samba no matter the operating system.
Also, I have no idea what you mean by "more user friendly workarounds and solutions" because different people want different things from samba no matter the operating system.
You didnt understand me, but I also didnt express myself very well. Newermind...
Can some1 at least give me tips for this one:
Quote:
1. My domain is in form NAME.local and I don't know how that interfere with fields in guides where I have to write YOURDOMAIN/yourdomain or YOUR.DOMAIN/your.domain where caps are important..?
Ok , with this guide: Chapter 2. Fast Start: Cure for Impatience, #Domain Member Server I have successfully joined samba to domain and users can access shared folders with simple permissions: full access over folder/files, only read or no access.
I set linux permissions to 777 (I just mounted NTS partition with 0000 umask since I used it for testing), and I have used samba options read only = Yes/No and valid users to make this work in simple way. Priority was to make samba to work with domain, no matter how and now its time for fine tuning.
So far I figured 2 (actually 3) ways to configure shares.
Since file system permissions are stronger then samba's I can:
1. Set root of the share with chown user:AllUsersOnDomain with 770 permission and then to set chown for every subfolder to belong to different domain group with 770 permissions, let's say chown ITuser:ITdepartment with 770, and so on for other departments...
Pros:
- I would have only one folder shared in smb.conf with read only = No option, so file system shares would determine who can access what, and
- I would be able to map that share as drive in My Computer.
Cons:
- I can't cofigure fine shares. If I add users from other departments to ITdepartment group they would be able to write in ITfolder, and I don't want that, I want only read for that particular users
- looks like I can't do that with NTFS partition since global ownerships are set in fstab when mounting
2. Set file permissions to 777 and let samba determine access levels...
Pros:
- with options read list and write list I can create lists with groups for every shared folder, which will give me share control the way I want.
- I can do this with NTFS partition
Cons:
- there is a lot of shared folders and I would have to map every one of them, so question: is there a workaround to set all of these folders accessible from one place in My Computer? (ofc I will google for this answer, but if someone knows let me know). If answer is Yes then maybe this would be way to go... (probably something like this)
3. Last option is to mount drive with ACL option, but I didn't elaborate this enough and it smells like (teen spirit ) that this can be pain in the ass. I need to research this more...
BTW is it just me or LQ.org is frequently down lately?
I run a number of servers with Slackware and Samba on them. Some of them in workgroup, some of them in DC mode. Samba is a fairly complex piece of software - doubly so in domain mode. I would warmly suggest spending some quality time on samba.org, reading through as much of the documentation as you can and understanding the various options. We are all under pressure to get things done quickly, but the simple matter is that being in too much of a hurry to get your Samba setup working without understanding the options will come and bite you in the back sooner than later. Also - if your questions are too broad and general in nature, you are less likely to obtain answers on any forum.
When I was setting up my Samba domains, I've had good responses to questions on the Samba users mailing list. This forum is dedicated to Slackware issues, and although the knowledge and good will here is high, you are far more likely to obtain answers to your questions about advanced Samba setups on the Samba users list. But I would only post there after doing your reading - when you end up with rather more specific questions than the ones above.
I really hope your trying to do this in a test environment , I would strongly suggest not do it in production environment unless your very familiar with samba . I am no way a samba expert but the only time I attempted to do something similar I had to use winbind ( clearly is not the only way ... but unless you wanto to manage two sets of credentials ) wich use PAM ( so no slackware ). Nonetheless I ha do so many problems related to different folder structures and POSIX converions that I decided it was more sensate to use a windows server in a windows environment.
1. My domain is in form NAME.local and I don't know how that interfere with fields in guides where I have to write YOURDOMAIN/yourdomain or YOUR.DOMAIN/your.domain where caps are important..?
A "domain" in Active Directory has two names; a long name that looks like a DNS domain name on the Internet ("mydomain.local"), and one short NetBIOS name in all caps for compatibility reasons ("MYDOMAIN"). Typically, the short name is a capitalized version of the first part of the long domain name, but it can theoretically be anything.
In addition, there's a third name: the Kerberos realm name. This is always identical to the long domain name, but in ALL CAPS ("MYDOMAIN.LOCAL").
As for Samba and Slackware, the Samba binaries shipped with Slackware are compiled without Kerberos support. This is to be expected, as Slackware doesn't have a native Kerberos package either. To have Samba 3.x properly join an Active Directory domain as a member server, you will need to:
download and install a Kerberos implementation (I highly recommend Heimdal)
rebuild the Slackware Samba package (just run the SlackBuild script; it will autodetect the presence of Kerberos binaries)
install the rebuilt Samba package
configure Samba as a domain member
This is not at all difficult. I've done it dozens of times, and I usually throw PAM in the mix as well. Let me know if you need further assistance.
I really hope your trying to do this in a test environment , I would strongly suggest not do it in production environment unless your very familiar with samba .
Very good advice if you're installing the 4.x branch, especially if you're configuring Samba as an AD Domain Controller. Since Samba 4.x doesn't support the DFS-R protocol, any domain member authenticating against the Samba server will be unable to access Group Policy Objects and login scripts. You'll have to set up manual SYSVOL replication with something like rsync.
However, joining Samba 4.x or 3.x to an AD domain as a member server shouldn't cause any troubles, even in a production environment. All that happens is a computer account is created in the directory. It's no different from joining a Windows PC to the domain.
I run a number of servers with Slackware and Samba on them. Some of them in workgroup, some of them in DC mode. Samba is a fairly complex piece of software - doubly so in domain mode. I would warmly suggest spending some quality time on samba.org, reading through as much of the documentation as you can and understanding the various options. We are all under pressure to get things done quickly, but the simple matter is that being in too much of a hurry to get your Samba setup working without understanding the options will come and bite you in the back sooner than later. Also - if your questions are too broad and general in nature, you are less likely to obtain answers on any forum.
When I was setting up my Samba domains, I've had good responses to questions on the Samba users mailing list. This forum is dedicated to Slackware issues, and although the knowledge and good will here is high, you are far more likely to obtain answers to your questions about advanced Samba setups on the Samba users list. But I would only post there after doing your reading - when you end up with rather more specific questions than the ones above.
Good luck with your setup.
This is good advice and I realised it myself already... but lack of time is kinda problem...
Quote:
Originally Posted by NetNightmare
I really hope your trying to do this in a test environment , I would strongly suggest not do it in production environment unless your very familiar with samba.
Why? Cause my life will become your nick?
Too late for that btw
Sorry, I had to make jokes
Quote:
Originally Posted by Ser Olmy
A "domain" in Active Directory has two names; a long name that looks like a DNS domain name on the Internet ("mydomain.local"), and one short NetBIOS name in all caps for compatibility reasons ("MYDOMAIN"). Typically, the short name is a capitalized version of the first part of the long domain name, but it can theoretically be anything.
In addition, there's a third name: the Kerberos realm name. This is always identical to the long domain name, but in ALL CAPS ("MYDOMAIN.LOCAL").
This was really informative, thank you!
Quote:
Originally Posted by Ser Olmy
As for Samba and Slackware, the Samba binaries shipped with Slackware are compiled without Kerberos support. This is to be expected, as Slackware doesn't have a native Kerberos package either. To have Samba 3.x properly join an Active Directory domain as a member server, you will need to:
download and install a Kerberos implementation (I highly recommend Heimdal)
rebuild the Slackware Samba package (just run the SlackBuild script; it will autodetect the presence of Kerberos binaries)
install the rebuilt Samba package
configure Samba as a domain member
This is not at all difficult. I've done it dozens of times, and I usually throw PAM in the mix as well. Let me know if you need further assistance.
Quote:
Originally Posted by Ser Olmy
However, joining Samba 4.x or 3.x to an AD domain as a member server shouldn't cause any troubles, even in a production environment. All that happens is a computer account is created in the directory. It's no different from joining a Windows PC to the domain.
I just joined Samba to domain with winbind, and it worked fine. Privileges over shared folders are done with "valid users" and "write list" combination.
Im surprised this was to easy... problems will probably hit me later
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.