Integrating Linux Samba File Servers into Windows Active Directory

Linux is free. And its being free is a great reason to build a free server that lets us share files out and serve an existing Windows environment. Additionally, we can then configure it so both Linux and Windows clients can easily get to the files on those servers.

But just plunking in a Linux server as a stand-alone file server isn't ideal. Better than that is to have it act like any ol' Windows member server. That way, once users authenticate to Active Directory, they can seamlessly access files on this new Linux server.

In this section, we'll explore the multiple steps it takes get a Linux Samba server to be as integrated as possible into an existing Active Directory. At the end of this section, this server will be a full-fledged member server with integrated authentication to Active Directory, as shown in Figure 4.11.

image from book
Figure 4.11: You can validate to Active Directory as any user and gain access to SMB shares hosted on Windows or Linux servers.

To pull it off, we'll need to do the following:

  • Create a new Fedora Core 3 Linux server called adsambafp1 because using our existing crop of servers can get messy. We'll also use this server in the next chapter to help out with printing.

  • Add a DNS record on the Windows server so that the hostname adsambafp1.ad.corp.com can be resolved to an IP address.

  • Configure Samba to recognize domain logons by verifying Kerberos tickets from Kerberized clients (and NT 4-style credentials from other clients). That is, when either a Windows or Linux client presents a Kerberos ticket (or authorized credentials that are valid for the domain), we want to make sure Samba accepts them. We can do this with Webmin.

  • Configure Samba to offer a share. We can do this with Webmin also.

  • Configure Fedora Linux to accept logons by Active Directory domain users. Before we can allow ownership of files by domain users, we'll need to make sure the operating system "sees" those users. We'll do this by turning on Winbind authentication via the Fedora Authentication tool.

  • Start smbd and winbindd (the two Linux daemons that need to be running to perform the magic) and configure Fedora Linux to restart them on every reboot.

  • Join the server to our Active Directory domain and start offering up the research share to interested parties.

Ready? Let's get started! We'll take on one major step at a time.

Installing Linux on adsambafp1

We've previously installed Linux on the linserv1 server. For adsambafp1 , we'll install exactly the same Fedora packages. Refer to Chapter 1 for the installation procedure. Here, we'll specify only the differences from the installation procedure for linserv1 , as follows :

  • In the "Edit Interface eth0" dialog box of the "Network Configuration" screen, give our new server its own distinct IP address: 192.168.2.211 .

  • In the "Hostname" section of the "Network Configuration" screen, set the hostname to adsambafp1.ad.corp.com .

  • In the "Miscellaneous Settings" section of the "Network Configuration" screen, set the primary DNS server to 192.168.2.226 (which is our Active Directory Domain Controller Windc1.ad.corp.com ).

Oh, and don't forget to install Webmin on adsambafp1 . We'll need it to configure Samba for file sharing in this chapter and for printing in the next chapter. The steps for installing Webmin can be found in Chapter 1, in the "Leveraging Webmin" section.

Adding a DNS Record for adsambafp1

On windc1.ad.corp.com , add a DNS "A" record resolving adsambafp1 to 192.168.2.211 . To do so, simply fire up the DNS manager in Windows. It's located in Start image from book Programs image from book Administrative Tools image from book DNS. In the zone for the AD.corp.com domain, right-click and select New image from book A Record.

When finished, you should be able to ping adsambafp1.ad.corp.com from WinDC1.ad.corp.com .

Configuring Samba as a Domain Member

Now we're ready to start configuring Samba as an Active Directory domain member. Follow these steps to get started:

  1. Log into Webmin as usual, except of course that you will use the following URL for the new server:

    • https ://adsambafp1.ad.corp.com:10000/

  2. Click the "Servers" button.

  3. Click the "Samba Windows File Sharing" button on the "Servers" page.

  4. On the "Samba Windows File Sharing" page, click "Windows Networking."

Configuring Samba's Windows Networking Options with Webmin

At this point, the "Windows Networking Options" page will appear. We'll be configuring it to match Figure 4.12. Let's discuss each option and the reasons for our choices:

image from book
Figure 4.12: Configuring Samba's Windows networking options with Webmin

Workgroup Samba uses the terms "workgroup" and "domain" interchangeably; if the machine is joined to or serving a domain, then this option refers to the domain. We set this option to AD , the "short name " of our Active Directory domain.

Server name This field can be left blank because Samba will correctly use the hostname, adsambafp1 .

Security We set this field to Active directory to ensure that all logons are verified by the Active Directory server. (When clients use Kerberos, the server can verify that a Kerberos ticket is valid without actually talking to the Active Directory server again every time.)

The remaining options can be left at their default settings as their use is rarely necessary and beyond the scope of this book.

Once you have completed your settings, click the "Save" button to continue.

Configuring Samba's Winbind Options with Webmin

Winbind is the Samba component that verifies login credentials against an Active Directory Domain Controller or NT PDC. You met Winbind previously in Chapter 2. There we used it to verify Linux client logons against an Active Directory Domain Controller. Here, our goal is just a little bit different: to verify "logons" to our Samba file server against an Active Directory Domain Controller. (By logons, we really mean "touches" to our Samba file server from Active Directory users.)

By accepting Active Directory domain logons, we can separate the task of authentication from the task of file sharing. That enables us to keep the benefits of running an Active Directory server on Windows while still reducing costs by running individual file servers on Samba.

To configure Samba's Winbind options, click the "Winbind Options" button. The Winbind Options page will appear. The correct choices are shown in Figure 4.13. Let's take a look at the individual options and our reasons for choosing them:

image from book
Figure 4.13: You'll want to configure your Samba file server's Winbind options as shown here.

Enable Winbind for local accounts? This option would allow clients to log on using local Unix account names on the server. Our goal is to allow only domain logons, so we set this option to "No."

Trust domain server users? This allows our server to accept domain logons, which is exactly what we set out to do! We set this option to "Yes."

Disallow listing of users? Allowing clients to list the names of other users reduces security and is not our job as a domain member file server. We should leave such functions to the Active Directory Domain Controller. Set this option to "Yes."

Disallow listing of groups? Again, allowing clients to list the names of user groups reduces security and is not our purpose as a domain member file server. Set this option to "Yes."

Kerberos realm on domain server As you saw earlier in this chapter, every Active Directory domain is also a Kerberos realm by the same name, in ALL CAPS, so the correct setting is AD.CORP.COM .

Range of UIDs for Windows users As explained in Chapter 3, Samba must "invent" Unix user IDs for each Windows user. The ranges specified here allow for millions of users and are well outside any popular range of IDs for local Unix users.

Range of GIDs for Windows groups As explained in Chapter 3, Samba must also "invent" Unix group IDs for each Windows group . Again, the ranges specified here allow for millions of groups and are well outside any popular range of IDs for local Unix groups.

The remaining options come into play only for stand-alone servers that offer logons other than those offered by the Active Directory Domain Controller. They can be left at their default settings.

Once you have completed your settings, click the "Save" button to continue.

Turning on Winbind Authentication

Samba has now been taught to "understand" Active Directory domain users and groups, but the rest of the operating system doesn't. In other words, we can't leverage Linux tools to manage our Active Directory users. For example, that means we can't yet use the chown command to "give" files to domain users.

We can fix this easily, however. All we need to do is use the Authentication Configuration tool to enable Winbind authentication. We've seen this tool several times before. To set up your Samba file server to adhere to Winbind authentication:

  1. From the "Applications" menu, select System Settings image from book Authentication tool and wait for it to appear.

  2. In the "User Information" tab, check "Enable Winbind Support."

  3. Click the "Authentication" tab.

  4. Verify that "Enable Winbind Support" is checked here also.

  5. Click "OK."

Your system is now ready to recognize Windows users and groups and map them to user and group ID numbers .

Launching smbd and winbindd

The underlying work that we've set in play is really performed by two running Linux daemons: smbd and winbindd . These running programs implement the two major parts of a Samba server: the actual file sharing and Windows-compatible user and group management.

Tip 

The extra "d" on the end stands for "demon" or "daemon," a traditional name for Unix programs that continue to operate in the background. You've already seen an example of this in the name daemon named .

We've configured the settings these programs rely on. Now we're ready to start them up with the service command and install them for automatic launch on the next boot with the chkconfig --add command. We've seen these commands before:

 service winbind start service smb start chkconfig --add winbind chkconfig --add smb 

Our Samba server processes are up and running. Now we're ready to join the Active Directory domain.

Joining the Active Directory Domain

Our next task is to join our server to the Active Directory domain. Webmin provides a button for this, but in our analysis, under the hood it seems to be using Samba commands more appropriate for an NT 4-style domain. We recommend that you instead join the domain at the command line with the net ads join command, which you saw previously in Chapter 3 when we joined Linux workstations to an Active Directory domain. Use this command to join the domain:

 net ads join -U administrator 

When prompted for the password, enter p@ssw0rd .

Your server is now a member of an Active Directory domain. You can verify this in two ways:

The wbinfo command Use the wbinfo command. wbinfo is a handy utility that fetches information from Winbind. In this case, we'll use the -t option, which verifies that our server and the Active Directory Domain Controller share a " t rust secret" that proves we are a member of the domain. Try this command:

 wbinfo -t 

You will receive the following output:

 checking the trust secret via RPC calls succeeded 

Now, let's verify that we can see the list of valid users for the domain. We can do that using the -u option of the wbinfo utility. Use the following command:

 wbinfo -u 

The output you receive will include these two familiar users:

 AD\salesperson1 AD\salesperson2 

Active Directory Users and Computers On your Domain Controller, fire up Active Directory Users and Computers and dive into the Computers folder. You should see the name of the computer you just joined to the domain. In our case, it's adsambafp1 .

Best of all, you should now be able to see your server when browsing the domain from the desktop of any domain member workstation or the Domain Controller itself using Network Neighborhood (on Windows) or Network Servers (on Linux).

Creating and Using Shares with Windows ACL Support

We're almost ready to serve up shares on our Active Directory domain member server. In fact, our server is ready to provide shares now, and serve files, as long as we don't mind some limitations on the permissions we can set on those files. At this point, we can offer the typical Unix model: separate read, write, and execute permissions for the owner of the file, users in the group that owns the file, and everyone else.

However, as Windows administrators know, Windows offers a much richer set of permissions for files and directories. Thanks to Windows ACLs (Access Control Lists), it is possible to set specific permissions on a single file or directory for any number of users and groups. For instance, we can decree that users in AD\SalesGroup should have read, write, and execute access, and allow users in AD\MarketingGroup to read and execute only, while still locking out everyone else.

Are we prevented from doing this with Samba? Not at all! What many Windows and Linux administrators don't know is that modern versions of Linux, including Fedora Core 3, also support ACLs, and Samba has the smarts to translate between Windows ACLs and the POSIX (Portable Operating System Interface) ACLs supported by Fedora, on the fly.

Note 

POSIX is a standard that allows applications to run the same across all platforms. For instance, you can have a POSIX-compliant application on Linux and bring it over to Windows (once SFU 3.5 is installed). Applications need to be recompiled for the new host operating system, but they'll run just the same if they stick to features covered by the POSIX specification. Included in the POSIX specification is how to handle lots of things like ACLs.

Translating Windows ACLs to POSIX ACLs is great, but there's a small catch. Windows ACLs are more general in their capabilities. For instance, in Windows, a file can be writable but not deletable by a given user. When Samba encounters an ACL that ACLs on the Linux side can't fully express, Samba copes by translating the portions that do make sense in both systems. For the most part, this works beautifully. Just bear in mind that your ACLs may look slightly different if you examine them again after having set them from Windows. The actual meaning should be the same, though, as long as what you are trying to do can be expressed fully as a combination of "read," "write," and "execute" permissions.

Note 

There are additional options to fine-tune the behavior of Windows ACLs in Samba, including the ways in which Windows ACLs are mapped to POSIX ACLs. You can find more information about these via the man smb.conf command.

Enabling ACLs in the Linux EXT3 File System

Before we can take advantage of POSIX ACLs, we'll need to enable them on our file system. The EXT3 ("third extended") file system used by default in Fedora Linux does support ACLs, and so does the operating system kernel that ships with Fedora. However, as of this writing, Fedora Core 3 does not turn on ACL support on the root file system by default at boot time. And, because ACL support is relatively new in Fedora, it is not currently something we can turn on through the "System Settings" submenu. Instead, we'll need to add a flag to the configuration file that controls file systems in Linux, /etc/fstab , and reboot the system.

/etc/fstab is a simple text file containing one line for each file system mounted by Linux. Each line consists of five space-separated fields. Although you don't need to understand all of the fields in detail, briefly , the fields of an /etc/fstab entry are as follows:

  1. The device to be mounted.

  2. The existing, usually empty directory where it should be attached to the file system.

  3. The type of file system, such as nfs or ext3 .

  4. Optionally, a comma-separated list of flags to be passed to the file system, such as rw for read/write access and acl to enable ACLs.

  5. Optionally, a 1 to indicate that the file system should be included in backups or a 0 to indicate it should not be.

  6. Optionally, a 1 to indicate the file system should be checked for errors when deemed appropriate, or a 0 to indicate it should not be.

In this case, we're concerned with the following entry:

 /dev/VolGroup00/LogVol00 / ext3 rw 1 1 

As mentioned, the rw flag in the fourth field means that the file system should be mounted with full read and write access. We need to add an additional flag, acl , to indicate that we want ACL support on this file system. The corrected line is

 /dev/VolGroup00/LogVol00 / ext3 rw,acl 1 1 

After we complete this change and save the file, it is necessary to reboot the system. This is because we want to change the way the root file system is mounted, and the root file system is where the Bash shell and desktop GUI tools we're using are located. Making this change without a reboot is relatively complex, while rebooting is a simple solution.

Here are the steps to enable ACLs on Fedora's root file system:

  1. As root, edit the file /etc/fstab on adsambafp1 .

  2. Locate this line. You may see rw in place of defaults :

     /dev/VolGroup00/LogVol00 / ext3 defaults 1 1 
  3. Change it to read as follows:

     /dev/VolGroup00/LogVol00 / ext3 rw,acl 1 1 
  4. Save your changes and exit the editor.

  5. Reboot adsambafp1 .

Creating the Research Share with Webmin

Reboot complete? Great! Now we're ready to make a share available. This part is straightforward and Webmin does all the heavy lifting . To create a share called research in which to keep files for sales and marketing people, we use the "Create a new file share" link on the "Samba Windows File Sharing" page of Webmin. Then we fill out the "Create File Share" page as shown in Figure 4.14. For a more detailed discussion, refer to "Sharing Folders with Samba," earlier in this chapter.

image from book
Figure 4.14: Creating the research share with Webmin

Now that we have created the share, we must be sure to make it writable. By default, as we've mentioned, a Samba share is read-only. Clicking "Create" returned us to the "Samba Windows File Sharing" page. Click "research" in the "Share Name" column. This will bring you to the "Edit File Share page." Click "Security and Access Control." The "Edit Security" page appears. Make sure you set "Writable?" to "Yes ." Scroll to the end of the page and click "Save." The "Edit File Share" page reappears. Click "Save" again to return to the "Samba Windows File Sharing" page. The research share is ready for use.

Enabling ACL Inheritance in Samba

There's one more adjustment to be made to the Samba configuration. This one involves an option that Webmin doesn't know about as of this writing, so we'll need to add a line to /etc/samba/smb.conf and tell Samba to reload its configuration file.

The option we want to enable controls the way ACLs are "inherited" from the parent folder when a new folder is created within it. This matters because our goal is to create a share where all files are under the full control of salespeople, readable by marketing, and inaccessible to anyone elsebut if we don't turn on inheritance, these properties won't be "passed down" from the /research folder to newly created folders within it.

To turn on inheritance of ACLs and restart Samba, follow these steps:

  1. Add the following line to /etc/samba/smb.conf , in the [global] section, before the sections for individual shares such as [ home] :

     map inherit acls = yes 
  2. Make sure Samba reloads its configuration file with this command:

     service smb reload 

Setting Initial Permissions and Ownership of the Research Share

To make things interesting, we'll decree that members of the Active Directory group AD\SalesGroup can read and write to the share, members of AD\MarketingGroup can only read it, and everyone else except the administrator will have no access. This wouldn't be possible with old-fashioned Unix permissions. Fortunately, we can now use ACLs, and we can use our Windows client to set them with beautiful friendly dialog boxes instead of the Linux command line.

Before we do that, though, we need to solve a "chicken-and-egg" problem. Linux doesn't allow any user to set or change ACLs on a directory except for (a) the root user or (b) the owner of the file. But our Windows domain users are not root, and when first created by Webmin, the /research directory belongs to root. So at the Linux command line, we'll give ownership of that directory to a domain user who belongs to AD\SalesGroup . Then we'll log into our Windows client as that user to do the really interesting ACL stuff.

We can use the chown command to grant ownership of files to domain users just as we would with regular Unix users. There is one catch: we need to "escape" the backslash ( \ ) character that separates the domain from the username with an extra backslash ( \ ), which is why you'll notice a double slash on the chown command line. This is intentional.

We'll also save some time and effort by setting the initial permissions on /research so that only the owner, AD\salesperson1 , has any access to the file to begin with. That way, when we do start setting ACLs, the effect will be more obvious.

To give the /research directory to AD\salesperson1 and set the initial permissions, follow these steps:

  1. Open a terminal window and become root with the su command if you did not log in as root.

  2. Use this command to set ownership:

     chown AD\salesperson1 /research 
  3. Use this command to set permissions:

     chmod a-rwx,u+rwx /research 

Now we're ready to log into our Windows client and set up the rest of the permissions we want in a user-friendly and elegant way. We could set up the permissions we want entirely on the Linux server side using the setfacl command, but we'll be using a Windows client instead. After all, our goal is to demonstrate that Windows machines can set ACLs and the Samba server will respect them. However, see the sidebar "Setting ACLs from the Linux Command Line" for more information about how the setfacl command could be used to accomplish the same thing.

image from book
Setting ACLs from the Linux Command Line

setfacl is the Linux command to set ACLs on a file or directory. When started with the -m option, it "modifies" the ACL set for a particular user or group.

The next option to setfacl is broken into three parts, separated by colons ( : ).

The first part is a single letter, either u or g , indicating whether we wish to set an ACL for a user, for a group, or for all others who do not match another ACL.

The second is the name of the user or group.

The last is the actual set of permissions to assign, using the r, w , and x characters with the same meanings as in the chmod command.

These four commands would give the folder the permissions we want. As a starting point, we use a simple chmod command to establish that no one should have access to the file. Then we use ACLs to grant access to the two groups:

 chmod a-rwx /research setfacl -m g:SalesGroup:rwx /research setfacl -m g:MarketingGroup:rx /research 

The setfacl command has additional options. For more information, type man setfacl at the Linux command line.

You will note that we don't specify the domain name when referring to SalesGroup and MarketingGroup in the preceding commands. That's because in our tests setfacl didn't handle slashes in domain usernames correctly. The commands work as they are written if we include the following line:

 use default domain = yes 

in the file:

 /etc/samba/smb.conf 

Setting use default domain = yes has a downside, though: it rules out setting permissions for users in other trusted domains. We hope that support for the " \ " domain separator character in commands like setfacl will improve in the near future. There is also a winbind separator Samba option that can be used to set a different separator character instead of "\", but you may find that alternative separator characters also cause difficulties with some commands. Check out the man smb.conf command for more information.

image from book
 

Setting ACLs with the Windows GUI

Now we're ready to log into our Windows client and set up our ACLs just the way we want them for the research share. First, we'll log into the xppro1 workstation as the AD domain user salesperson1 . Then we'll browse the network neighborhood and locate the research share on the adsambafp1 server. Once we're there, we'll edit the properties of the research directory and set up access control just the way we like it. Then we can do some simple tests as salesperson2 , marketperson1 , and hrperson1 to verify that our actions have the desired effects.

When we set ACLs on the main folder of a share, we receive a warning message from Windows. That's because, on a true Windows file server, changing ACLs on a folder affects all of the existing files in the folder. But the share is currently empty and there are no existing files whose permissions would be disturbed by the change. Even if there were, Linux wouldn't automatically change the permissions and ACLs of existing files in the folder. But Windows doesn't know that, so it warns us anyway.

Warning 

In our tests, ACLs looked great in the Windows GUI while initially setting them, but we did have one frustrating problem when re-opening the "Security" tab of the "Properties" window later: SalesGroup and MarketingGroup appeared as SIDs rather than as user-friendly names. For instance, SalesGroup appeared as S-1-5-21-875667829-2241442456-3328505926-1130 . However, the actual behavior of the ACLs was completely correct, and the getfacl command on the Linux side shows that the correct access controls are in force. We hope this apparent Samba issue will be resolved in the near future.

Here is a summary of what we aim to accomplish by setting ACLs on the research share:

  • salesperson2 , or another member of the SalesGroup , should be able to read and write files.

  • marketperson1 , or another member of the MarketingGroup, should be able to read files but not write to them.

  • hrperson1 and other members of neither group should not be able to access any files.

Follow these steps to set up ACLs for the research folder using the Windows GUI:

  1. Log on to the xppro1 workstation as the AD domain user salesperson1 .

  2. Select Start image from book My Computer.

  3. Select the text in the "address" field at the top of the "My Computer" window and type \\adsambafp1

  4. Press Enter. A list of shares available on adsambafp1 appears.

  5. Right-click the research share.

  6. Choose "Properties" from the menu.

  7. Click the "Security" tab.

  8. Click the "Add " button.

  9. The "Select Users, Computers or Groups" dialog box appears. Enter AD\SalesGroup in the "Enter the object names to select" field and click "OK." AD\SalesGroup now appears in the "Group or user names" list in the "Properties" dialog box.

  10. Select " AD\SalesGroup ."

  11. In the "Permissions for SalesGroup " list, check the "Allow" box next to "Full Control" as shown in Figure 4.15.

  12. Click "Apply."

  13. The message box in Figure 4.16 appears. Click "Yes."

  14. Repeat steps 915 for AD\MarketingGroup. This time, instead of "Full Control," check the "Read," "Execute" and "List Folder Contents" boxes.

  15. Click "OK" to exit the "Properties" window.

image from book
Figure 4.15: Setting an ACL on the Samba Server via a Windows client
image from book
Figure 4.16: Confirmation message when changing ACLs on the root folder of a share

Browsing Our Shares from a Windows Workstation

You can now browse into the AD domain and then onto our new server using the normal network browsing features of any domain member workstation. The procedure is no different from that for exploring shares on a domain member server that runs Windows; that's the point, after all! But here's one way to access the research share:

  1. Select Start image from book My Computer.

  2. Select the text in the "address" field at the top of the "My Computer" window and type \\adsambafp1

  3. Press Enter. A list of shares available on adsambafp1 appears.

  4. Double-click the research share.

The research share will allow you to store and retrieve files normally, provided that you are logged in as salesperson1 or another member of the S alesGroup . You'll be able to read files if you are logged in as a member of the M arketingGroup . You will have no access at all if you are logged on as a member of another group. That's exactly what we set out to achieve!

A final note: you can also browse your shares from the adlincli1 Linux workstation just as you browsed shares on windc1 . This works because the Linux client adlincli1 and our new server adsambafp1 are both members of the AD domain.

If it Doesn't Work

Here are some things to check out if you have unexpected problems:

  • Be sure the system clocks agree . Kerberos is very picky about the current time; there must be close agreement between the machines involved.

  • Double-check your configuration settings . Did you skip one of the Webmin configuration pages?

  • Be sure to enable ACLs in /etc/fstab . Did you forget to reboot after this step?

  • Restart smbd and winbindd . After correcting any oversights, you'll need to restart the smbd and winbindd processes. You can do so with the following commands:

     service smb restart service winbind restart 


Windows and Linux Integration. Hands-on Solutions for a Mixed Environment
Windows And Linux Integration Hands-on Solutions for a Mixed Environment - 2005 publication.
ISBN: B003JFRFG0
EAN: N/A
Year: 2005
Pages: 71

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net