Leveraging NFS on Your Servers

Linux supports many ways to share files. As you've just seen, we can leverage Samba to pretend to be a part of an existing Active Directory domain.

The other major way it can share files is via the Network File System (NFS). In this section, we'll set our Linux server to be an NFS server. Then we'll have our Linux clients connect, as well as our Windows clients .

Additionally, SFU 3.5 has the ability to act as an NFS server. That way, your existing Linux clients can connect to it and mount shares just as if it were a real Unix NFS. And here's the best part yet: your Active Directory users can use the same home drive (on Linux, home directory) when they log on with either a Windows or Linux client computer. How amazingly cool is that? Well, you're going to find out firsthand.

The diagram in Figure 4.17 shows how Linux and Windows clients can connect to Linux NFS servers or Windows servers running the NFS services that comes in SFU 3.5.

image from book
Figure 4.17: Linux and Windows clients can be set up to directly connect to servers exporting NFS.

Note that you might not ever need to offer up an NFS mount directly to a Windows client. That is, you could just use Samba (as shown in the last section) to offer up a Linux directory as an SMB share. Why then would you ever need to make an NFS export and have Windows clients see it using Windows NFS tools? It takes an extra step to load Windows NFS tools on the client, so why bother?

Because you could have a situation where the NFS is already perfectly set up on the Linux or, especially , legacy Unix server and you have no desire to run any Samba server components on that server. In that case, it would be necessary to have Windows see those native NFS shares somehow; you'll see how to do that next .

Setting Up a Linux NFS Server

NFS is the original, old-school Unix/Linux way to share files, and there are good reasons why it is still the most common way to share files in a pure Unix environment. NFS has a number of things going for it:

  • It's very simple.

  • It handles Unix users, groups, and permissions easily.

  • Because it's so simple, most implementations are compatible with one another.

Of course, NFS has some significant disadvantages too:

  • It "trusts" machines based on their IP address.

  • Users are not authenticated by a central server.

  • User and group IDs must be the same on every client.

Considering the Flaws of NFS

Are these flaws critical? It comes down to this: If you can reasonably ensure that users on Linux machines cannot change their IP addresses or obtain root access, then NFS is an acceptable choiceand even if Windows clients are involved, NFS can still sometimes be acceptable.

However, since NFS uses a "trusted host" model, where workstations are individually responsible for limiting access to particular files to the correct users, every workstation must be secured carefully . It is critical that both Linux and Windows clients be kept thoroughly up to date with security patches and antivirus updates.

Don't let us give you the impression that NFS has no security capabilities. Here are four ways you can help secure NFS:

  • You can lock down a share to clients on the local network only using a network address and a netmask (which we strongly recommend). See the upcoming note.

  • You can lock down NFS access to individual IP addresses.

  • You can serve up read-only shares. This is useful because for many less secure applications, making sure that a rogue client can't delete files is sufficient.

  • Although NFS doesn't require users to authenticate, an NFS server need not blindly trust clients to act as any user. You can and should configure NFS to prohibit clients from acting with the privileges of the root user. This makes attacks more difficult.

Setting Up NFS Exports

Assuming we've decided that NFS is suitable for what we need to do, how do we configure NFS "exports" (analogous to Windows shares)? Webmin to the rescueit does a great job setting up NFS!

We'll begin by sharing the /home directory of linserv1 . Then we'll configure a Linux client computer ( lincli1 ) to use this exported directory instead of its own /home directory. Actually, if we had a bunch of Linux client machines, we would want to do this on all on them. That way, whenever users bounce from Linux machine to Linux machine, they always receive their home directory centrally from the server. Sort of like a Windows roaming profile, as shown earlier in this chapter.

Once set up, any user can log into any workstation and see their own files, just as they left them. As Martha Stewart would say, "That's a good thing."

Later, we'll also share two other directories to demonstrate how to use NFS in other scenarios.

Exporting Home Directories via NFS

To export /home via NFS, follow these steps:

  1. Log into Webmin as usual. As a reminder, use your favorite web browser to connect to https ://linserv1:10000 and provide root credentials.

  2. Click the "Networking" icon

  3. Click the "NFS Exports" icon.

  4. Click "Add a New Export."

  5. The "Create Export" page will appear (see Figure 4.18).

  6. In the "Directory to export" field, enter / home .

  7. You want to activate the NFS export. Next to "Active?", ensure "Yes" is selected.

  8. To the right of "Export to," select the "Network" radio button.

  9. In the "Network" field, enter 192.168.2.0 .

  10. In the "Netmask" field, enter 255.255.255.0 .

  11. The remaining default selections are acceptable and should match Figure 4.18; see the sidebar "Other NFS Options via Webmin" for more information about what they do.

  12. Click "Create" to create the new export.

  13. The "NFS Exports" page reappears. The /home export should be listed (see Figure 4.19).

  14. Click "Apply Changes."

image from book
Figure 4.18: You can leverage NFS to create an export of /home on linserv1 .
image from book
Figure 4.19: The NFS Exports page shows our new /home export. Click "Apply Changes" to make it take effect.
Note 

How do network addresses and netmasks work? In our case, the network address is 192.168.2.0, and the "netmask" is 255.255.255.0. NFS will compare the IP address of the client to the network address we specify. If the corresponding byte of the netmask is 255, that byte must match in the client address and the network address. If the corresponding byte of the netmask is 0, that byte doesn't have to match. Allowing only the last byte to vary in our situation keeps out machines not on the local LAN. The NFS server actually requires the individual bits that are set in the netmask to match (255 and 0 are not the only acceptable values), but subnet addressing is beyond the scope of this book.

The /home export is ready to go! Soon we'll examine how to mount /home from our Linux client workstation. First though, we'll export two additional directories to demonstrate how NFS can be used to create read-only shares.

image from book
Other NFS Options via Webmin

What do the remaining options do?

  • Setting "Clients must be on secure port?" to "Yes" prevents rogue client applications running as a non-root user on a Linux client from making their own rogue NFS requests . This is only effective if the root account on that particular Linux client hasn't been compromised.

  • Setting "Access mode" to "Read/write" allows users to write to their home directories.

  • Setting "Deny access to directory?" makes the share active but unusable.

  • Setting "Trust remote users" to "Everyone except root" prevents any client from acting as the root user with full control over the exported directory.

  • Selecting "None" for "Don't trust UIDs" and "Don't trust GIDs" forbids clients from acting as additional Unix user IDs and group IDs other than root.

  • "Treat untrusted users as" determines what happens if a client tries to act as root or another forbidden NFS user. The "default" selection causes a request to work with a file as root to be treated as a request from the user "nobody," and it fails unless that file's permissions allow that action for all users.

  • Turning on "Immediately sync all writes" would prevent the NFS server from delaying write operations for the sake of performance. We'll accept the default for this option. Samba's default behavior is not to immediately sync all writes .

image from book
 
Exporting Read-Only Directories via NFS

Why export directories on a read-only basis? It's not uncommon to have a large number of legacy files that all users are permitted to access. You may also want to export them to client workstations that are not well secured and cannot be trusted not to delete or modify them. Since NFS does not authenticate individual users, this is a serious concern. Making the files read-only provides you with a little bit of security (at least they cannot be written to).

Our Linux server, linserv1 , has two types of users in its LDAP database: doctors and nurses . Let's assume we have a need to make certain files available to everyone related to these two groups. We'll create directories for each of these groups with the following simple commands, all but two of which you've seen before. Be sure to execute these as root:

 mkdir /doctorfiles echo "It worked" > /doctorfiles/test.txt chgrp -R doctors /doctorfiles chmod a+r,g+rw /doctorfiles mkdir /nursefiles echo "It worked" > /nursefiles/test.txt chgrp -R nurses /nursefiles chmod a+r,g+rw /nursesfiles 

The chgrp command, like the chown command, changes the ownership of a file but in this case, it sets the group that owns the file rather than the user. Just as with chown , the -R option recursively changes group ownership of the directory and all of its contents.

The echo command (which also exists in Windows), simply outputs the text it receives as an argument to standard output. The > character, as you have seen, redirects standard output to a file. So we've created two little text files containing one line of text each. We'll use these to verify that our NFS mounts are successful.

Now, we'll create read-only NFS mounts for these directories. The procedure is almost identical to that for exporting /home , but there are some differences.

To create a read-only NFS mount:

  1. Log into Webmin as usual.

  2. Click the "Networking" icon.

  3. Click the "NFS Exports" icon.

  4. Click "Add a New Export."

  5. The "Create Export" page will appear.

  6. In the "Directory to export" field, enter / doctorfiles .

  7. Make sure "Yes" is selected next to "Active?"

  8. To the right of "Export to" select the "Network" radio button.

  9. In the "Network" field, enter 192.168.2.0 .

  10. In the "Netmask" field, enter 255.255.255.0 .

  11. To the right of "access mode," select "Read only."

  12. The remaining default selections are acceptable.

  13. Click "Create" to create the new export.

  14. The "NFS Exports" page reappears. The /doctorfiles export should be listed (as shown previously in Figure 4.19).

  15. Click "Apply Changes."

  16. Repeat these steps, substituting /nursefiles for /doctorfiles .

We now have two read-only NFS exports, which are available to everyone. Now, how do we access these exported directories from a Linux client? That's the topic of the next section.

Connecting Linux NFS Clients to Linux NFS Servers

We've got the pieces in place on the server side. We're ready to set up a Linux client so that both home directories and the read-only exports are mounted over NFS. How do we set up the client side?

We're pleased to report that the task is remarkably easy to accomplish. Mounting our NFS exports requires only four steps:

  • We will log into the lincli1 workstation directly as root . The root account has its home directory in a separate location outside of /home , so root won't be disrupted by the change when we switch to the NFS-mounted home directories.

  • We will create the mount points for each export. That is, we'll create a directory where we can hang each NFS export.

  • We will add one line describing each export to /etc/fstab , the system-wide table of file systems that are mounted on every reboot.

  • We will use the mount -a command to mount any file systems in /etc/fstab that are not already mounted. In this case, that means our new NFS mounts.

Let's go through the steps in detail and get this show on the road!

Logging in Directly as Root

We'll start by logging in directly as root. If you are currently logged into the desktop of a non-root user, log out now. It's not good enough to simply use su , because we're about to replace our local home directories with an NFS mount, pulling the rug out from under any non-root user currently logged in! root, fortunately, has its home directory in /root where the mount won't affect it. This is good practice since we may still need root access to the client if the NFS server goes down.

Now log back in to the graphical console as root and proceed to the next step.

Creating the Mount Points

Next, we'll create mount points for all three exports. As you have seen, the Linux mount command requires an existing, typically empty local directory as a "mount point" to attach the server's export to. To take care of the two read-only shares, just enter these commands:

 mkdir /doctorfiles mkdir /nursefiles 

But what about the /home share? Well, we already have a /home directory with local files for the accounts we've used in previous experiments. We could use that nonempty /home directory as a mount point, but that can get confusing fast. We won't know if we're really succeeding if the mount failswe'll have stuff in the directory already. To avoid confusion, we'll rename the original /home directory and create a new, empty /home as our NFS mount point.

If anything does go wrong with the NFS mount, we'll know immediately, as we'll see an empty /home directory! Use these two commands:

 mv /home /home-old-local mkdir /home 

Now we have all three mount points we'll need to mount the NFS exports from the server.

Adding the Mounts to /etc/fstab

We could set up our NFS mounts right now from the command line, using mount -t nfs . However, the goal is to mount /home , /doctorfiles , and /nursefiles automatically all the time. As you've already seen, the file /etc/fstab is a list of mounts that are remounted every time the system reboots. This is where we'll add entries to take care of our NFS mounts.

There are entries for many types of file systems in /etc/fstab , and some of them take complex options. NFS mounts are very simple, however. We need to specify only three things: the export we want to mount, the local mount point, and the file system type. We specify the export very simply; all we have to do is identify the server and the exported path on the server, separated by a colon ( : ):

 servername:/exportpath 

The mount point parameter is just the path of the mount point we created with the mkdir command. The file system type, of course, is nfs . (As we said, it's very easy.) Just add these three lines to the end of /etc/fstab :

 linserv1.corp.com:/home /home   nfs linserv1.corp.com:/doctorfiles /doctorfiles  nfs linserv1.corp.com:/nursefiles /nursefiles  nfs 

Accessing the NFS Mounts Now

We're already finished, in a way. We could reboot lincli1 right now and the NFS mounts would come right up. But there's no need to wait for a reboot. Just use the mount -a command to mount them right now. The -a option specifies that "all" file systems in /etc/fstab should be mounted, if they are not mounted already. Just type

 mount -a 

If the mount command works properly, the shell prompt will reappear with no further messages. If you do receive errors, check to be sure that

  • You created the mount points.

  • linserv1 is up and running, /doctorfiles and /nursefiles exist on linserv1 , and /etc/exports has been set up correctly on linserv1 .

  • The nfs service has been started on linserv1 with the command service nfs start .

Verifying Your Success

Once you have completed the mount command without errors, you can verify your success easily. First, type

 ls /home 

Instead of the empty mount point directory we created locally, you will see the contents of the server's exported /home directory. That list will include /home/doctor1, /home/doctor2, /home/nurse1 , and /home/nurse2 .

Now log out of lincli1 as root and log back on as the user named doctor1 . You can use your home directory and GNOME desktop on the server just as you would use a local home directory. Also try the command

 ls /doctorfiles 

You will be able to see the file test.txt , which we created on the server listed among the contents.

Congratulations: you have successfully configured an NFS client and server. Once you set up all of your Linux client systems to mount home directories via NFS, users will be able to log into any workstation and find their usual files, settings, and so onjust like Windows users utilizing home drives and roaming profiles.

If you choose to use the same Linux server additionally acting as a Samba-based PDC and file server, doctor1 can find her documents on the server when she logs on from a Windows workstation or a Linux workstation. Now that's interoperability.

Having Windows Clients Locate NFS Servers

Now that you've seen our Linux clients connect to NFS mounts, we should also demonstrate how to do the same for our Windows clients. There are two ways to make Windows client machines see NFS exports that live on Linux servers:

  • Use the Windows 2003 server as a gateway for our Windows clients that translates incoming Windows SMB requests to NFS mounts. This software is part of SFU 3.5 and runs on the Windows 2003 server. Indeed, we already installed SFU 3.5 on our server, and when we did, we suggested that you also install the NFS gateway (see Figure 3.8 in Chapter 3).

  • Trot out to each and every Windows client system and load SFU 3.5 and select the "NFS Client" during the installation. That way, Windows clients can connect directly to the machines which are exporting NFS shared files.

Connecting Windows Clients via NFS Gateway

In this example, we'll tell our Windows 2003 server ( Windc1.ad.corp.com ) to accept inbound SMB connections and re-route them as NFS connections. In other words, we'll map what looks like an SMB share to an existing NFS mount. That's the point of the gateway for NFS from SFU 3.5. A diagram of this can be seen in Figure 4.20.

image from book
Figure 4.20: You can use SFU's NFS Gateway to make existing NFS exports on Unix and Linux appear as if they were regular SMB.

To start, log on as administrator to the Windows 2003 Domain Controller. Select Start image from book All Programs image from book Windows Services for Unix image from book Gateway for NFS Configuration as shown in Figure 4.21.

image from book
Figure 4.21: The Gateway for NFS Configuration application has its own icon. It's not part of the SFU console.

When you select the icon, you'll be presented with the "Gateway for NFS Shares" screen. Here, you'll set up the name for the SMB share (which appears as an inbound Windows connections) as well as the name of the NFS mount.

In Figure 4.22, you can see we've entered LINNURSEFILES as the SMB share on Windows, and we've entered the name of the NFS mount (in typical Windows notation) as \\linserv1 \nursefiles .

image from book
Figure 4.22: Input the name that should appear as the SMB share in the "Share Name" field and the name of the existing NFS resource in the "Network Resource" field.

The "Drive" letter designation is optional. Additionally, you can use the "Users" part of the interface to restrict how many clients can connect, and you can use the "Permissions" button to specify who can perform what rights once connected to the share. For instance, perhaps you want only the members of the Human Resources Group in Active Directory ( HRGroup ) to see the files contained within that sensitive Linux export. If desired, go ahead and click "Permissions," remove "Everyone," and specify that only the HRGroup should have, say, "Read" access.

Once you're satisfied, click the "Connect" button to initiate the gateway between the LINNURSEFILES Windows SMB share and the \\linserv1\nursefiles NFS mount. You might be prompted with a warning if your SMB share name is longer than eight characters , as Windows 9 x and clients cannot view long share names .

To check out your work, from a Windows client simply browse to \\Windc1\LINNURSEFILES . Inside, you should see the files we placed inside when we originally created the NFS mount points, as shown in Figure 4.23.

image from book
Figure 4.23: Windows clients can now connect to the NFS resource as a plain ol' SMB share.

Connecting Windows Clients Directly to NFS

The preceding scenario cannot be beat. That is, you set up one little piece of code on your Windows 2003 server and all your Windows clients can magically map NFS mounts via a standard Windows share.

This works great, until you have hundreds of clients pounding down that one server's door to get to the NFS mounts. Ouch, that could be painful for that one poor box. Instead, you could put a NFS client piece directly on the clients that need it. That way, your poor Windows 2003 server doesn't take all the poundingeach client machine individually asks the NFS server for a connection.

Here's how to do that. First, run the SFU 3.5 setup program on your Windows XP client machine. (You can refer to download and initial setup instructions in Chapter 3.)

A "standard" SFU 3.5 installation will install the NFS client on your Windows XP machine. You can accept all the defaults during the Installation Setup Wizard. Once loaded, you're ready to browse NFS mounts from Windows XP.

To see Windows shares from Windows clients loaded with the SFU 3.5 NFS client software:

  1. Select Start image from book My Computer and in the "Other Places" heading, select "My Network Places."

  2. Next, locate and click "Entire Network," still in the "Other Places."

  3. Select "NFS Network." From the list, double-click "Default LAN."

  4. Inside Default LAN, double-click " LinServ1 " to see the NFS mounts it contains.

  5. You should be able to see the NFS mounts we created. Click inside, say, the nursefiles mount and you'll be able to see and open the files we put inside.

Leveraging NFS Exports on Your Windows Server for a Unified Windows and Linux Home Drive

In Chapter 3, you loaded SFU 3.5 on your Domain Controller. When you did this, you performed several key functions. When loading SFU 3.5, you

  • Extended the Active Directory schema to allow for Unix attributes to reside in Active Directory. For instance, a user's UID and a group's GID can now be manipulated in the user's or group's "Unix Attributes" tab.

  • Told Active Directory to answer to NIS queries. Now that SFU 3.5 is installed on your Domain Controller, it can respond to Unix computers asking for the attributes specified on the "Unix Attributes" tab.

  • Loaded (but haven't yet configured) a service called the "User Name Mapping" service. This will come in handy here, as it's a critical piece of the magic required to make the dream of unified home directories a reality. You'll see how this fits in the story in a bit.

  • Loaded (but haven't yet configured) the server for NFS. This allows us to take any directory we want and export it as an NFS mount.

To create a unified home directory for our Active Directory users when they log on to Windows or Linux, we need a battle plan. Here it is:

  • We'll create a home share for our Active Directory users.

  • We'll share that home share via SMB for when Active Directory users log on to Windows.

  • We'll leverage the server for NFS and export that very same directory as a NFS mount. This way our Linux clients can see the exact same directory.

In other words, our Windows clients will connect to the directory via SMB, and our Linux clients will connect via NFS. It'll be beautiful.

In Figure 4.24, you can see what should happen: a user whose account is in Active Directory, say, salesperson1 can log on to either a Linux client (which is a domain member) or a Windows client (which is a domain member).

image from book
Figure 4.24: You can create unified home drives by using Windows 2003, SMB shares, and NFS exports.

There's one extra step in the equation: the User Name Mapping service. However, we'll cross that bridge when we come to it.

Creating, Sharing (via SMB), and Exporting (via NFS) a Unified Home DirectoryOh, and Securing It Too

As we stated, we need to create a unified place on our server for our users to store their junk, er, files. To that end, on our Windows 2003 server we'll create a normal directory using Explorer and we'll call it homedirs . This can be any place you like. A best practice is to put it on a volume that isn't the system (that is, the C) drive. However, for example purposes, feel free. Once created, we need to also share the directory via SMB so our Windows clients can easily access it.

Finally, we'll change the NTFS permissions on that directory so we can set up individual users reading their own directories later.

Sharing homedirs via SMB

Don't panic when, in a moment, we set Authenticated Users to have Change and Read rights on this new SMB share. That's because we'll also set up NTFS permissions on the files and folders inside this directory, which will ultimately keep Windows users writing only where they should.

To create the directory and share via SMB:

  1. Log on to Windows 2003 as administrator .

  2. Select Start image from book My Computer and select the C: drive.

  3. Select File image from book New and enter a name for the directory, say, homedirs .

  4. Right-click over the new directory and select "Sharing and Security."

  5. On the Sharing tab, click the "Share this folder" button, as shown in Figure 4.25. By default the "Share name" field will be the same name as the directory. This is recommended as this is also the name we will use when using NFS in a moment.

  6. Click the "Permissions" button (not shown in the figure). You'll see the Permissions for the share. By default, a Windows 2003 share is Everyone: Read. Change so the access is Authenticated Users: Change and Read, as shown in Figure 4.25.

  7. Select "OK" to return to the properties of the homedirs directory.

image from book
Figure 4.25: You can set the permissions on the home directory share so Authenticated Users has Change access.

Here, the homedirs directory is shared out to Everyone: Full Control. Don't worry: your users will be protected by NTFS permissions, which will be stronger than these initial share-level permissions.

Exporting homedirs via NFS

Now you're ready to also export the directory via NFS. You can do this via the "NFS Sharing" tab on the properties of the directory. Before we do, however let's recall one undeniable tenet of NFS: NFS's security is based on what machine connects to the export. This is very archaic, but that's the breaks, so don't panic when, in a moment, we set all machines to be able to Read and Write to this export. That's because we'll also set up NTFS permissions on the files and folders themselves inside this directory, which will ultimately keep Linux users writing only where they should.

To export the homedirs directory via NFS:

  1. Select the "NFS Sharing" tab, which is in the properties of the homedirs page. Click the "Share this folder" button. By default the "Share name" field will be the same name as the directory. This is recommended as this is also the name we just created via SMB sharing.

  2. By default the "Allow anonymous access" is unchecked. This is goodleave it unchecked, as it's not needed.

  3. On the "NFS Sharing" tab, click the "Permissions" button. The "NFS Share Permissions" dialog appears as shown in Figure 4.26.

  4. By default "ALL MACHINES" have "Read-Only" access. You need to change this so that "ALL MACHINES" have "Read-Write" access. Perform this change by pulling down the drop down next to the "Type of access" and selecting "Read-Write."

  5. Additionally, be sure to select the "Allow root access" check box. This is a highly important step and should not be missed. This will permit Linux clients to map to this directory when they start up. In the next section, we'll make sure we have a root user in Active Directory who can actually perform the connection.

  6. At the NFS Share Permissions screen, click "OK" to return to the homedirs properties

  7. At the homedirs Properties screen, click "OK."

image from book
Figure 4.26: On the NFS tab, "Allow anonymous access" is not needed. On the "NFS Share Permissions" dialog box, ensure the "Allow root access" is selected.
Securing the homedirs Directory via NTFS

Last, but not least, we have to configure NTFS permissions on the underlying homeshares directory. Click the "Security" tab, and you'll see that the Users group has a whole lot of access. This doesn't work for us; we don't want Johnny User seeing what Sally Admin is doing. We'll remove the Users group from having access here, which will force us to explicitly designate permissions just to those users who need permissions where they need them. However, it's a little tricky to remove Users from this default access. Let's do that now. To remove Users from accessing the homedirs folder:

  1. If not already done, click the "Security" tab in the homedirs properties.

  2. Click the "Advanced" button to bring up the "Advanced Security Settings for homedirs ."

  3. Uncheck the "Allow inheritable permissions from this object and all child objects. Include these entries explicitly defined here" check box. The "Security" dialog will appear asking how you should handle permissions. Select Copy. At the "Advanced Security Settings for homedirs " click "OK.

  4. At the homedirs Properties page, select the Users group and click "Remove."

  5. Click "OK" to close the homedirs properties.

Creating an Active Directory Root User

In the last step, you selected "Allow root access" for the NFS share. Without it, your Linux clients will not be able to mount the NFS share. This is because every Linux client has an account named root and has a UID of 0. But Active Directory doesn't know about this, however, so we have to train Active Directory to have a root user and give it the UID of 0.

To do this, you've got two choices:

  • Using Active Directory Users and Computers, select any existing user for instance, the administrator account select the "Unix Attributes" tab, and enter UID 0 .

  • Or create a completely new garden-variety Active Directory user and name it root. Then select the "Unix Attributes" tab and enter UID 0 .

These do the exact same thing. Note that the Active Directory root user need not be an administrative account.

When you're done, your root user's "Unix Attributes" tab should look similar to Figure 4.27. Note, in our case we're arbitrarily selecting a Primary group. It can be whichever Unix-enabled group you like.

image from book
Figure 4.27: Active Directory needs to know who your Linux UID 0 account should be. We suggest you create a new user named root and specifically grant it UID 0.

Mapping Active Directory User Accounts to Unix UIDs

Let's take a look at the big picture again for a moment. Imagine for a second that we are the user named salesperson1 whose account lives in Active Directory. Recall that we specifically Unix enabled this account by going to the "Unix Attributes" tab and entering a Unix UID.

Remember, the goal is to log in on the Linux client and have the Linux client automatically know who we are and what rights we have. You might think that because we authenticated directly to Active Directory that Active Directory would automatically tell the Linux client what the UID of salesperson1 is. But it doesn't.

In order for the Linux client to know the UID within Active Directory of salesperson1 , the Linux client has to query the NIS server that you set up on your Domain Controller. You got that right: Active Directory is pretending to be a NIS server, and the Linux client queries that database to discover what the UID is. Strange but true.

You can ensure that your Active Directory Domain Controller is masquerading as an NIS server while inside the "Services for Unix" console. Figure 4.28 shows the "Server for NIS" heading and the NIS server it's running as. Note the name in our case is ad (that's a lowercase ad ), which will become extraordinarily important to know in a moment.

image from book
Figure 4.28: The User Name Mapping service maps Active Directory accounts with Unix Attributes over to the Active Directory NIS server components.
Warning 

If you don't see the name of your Active Directory NIS server when you double-click the "Server for NIS" heading, you might not have that component loaded properly. Go to the Add/Remove Programs applet in Control Panel, locate the Services for Unix entry, choose to install additional components, and load the NIS server.

When salesperson1 logs on to the Active Directory/NIS server, another service called the User Name Mapping service kicks into high-gear. It says: "Holy cow! salesperson1 is trying to log on to NIS. Let me check inside Active Directory to see what the UID is set to." In other words, as long as you log on as salesperson1 , you'll be automatically able to locate the UID from Active Directory when asking via NISand it's all thanks to the User Name Mapping service.

It's a bit convoluted, but it works.

We simply need to configure the User Name Mapping service once, then forget about it forever. There is one very weird aspect of the User Name Mapping service. By default, it only updates once every day. For instance, if you create a brand spankin' new Active Directory user and enter the Unix Attributes such as the UID, any queries to NIS requesting the UID of the user will not be valid until up to 24 hours later. This can be a troubleshooting nightmare: you set up a new user, provide the Unix Attributes, then pull your hair out wondering why you have no permissions!

You can manually specify a synchronization at any time with the "Synchronize Now" button as shown in Figure 4.29. Better yet, change the refresh interval to one that makes more sense to your environment. Note that synchronization can have some network impact on your environment because it sends all data about every account to all Domain Controllers which are running the SFU 3.5, so be careful in how you set this value.

image from book
Figure 4.29: In the "NIS domain name" field, you must enter the exact NIS domain name you are using for the Active Directory NIS.

Additionally, there are various ways to configure the User Name Mapping server. The simplest and easiest is via what is called "Simple Mapping." It basically means, "When I see user salesperson1 logging in from Linux, it means he's UID 10007."

Here's how to set up the User Name Mapping service to use Simple Mapping:

  1. Select Start image from book All Programs image from book Windows Services for Unix image from book Services for Unix Administration. The Microsoft Windows Services for Unix console appears.

  2. Select the "User Name Mapping" section.

  3. Select the "Use Network Information Service (NIS)" radio button if it's not already selected.

  4. Change the refresh interval to something that makes more sense. Again, the quicker you refresh, the more network traffic to other Domain Controllers you'll generate. In our test lab, we only have one Domain Controller, so setting this value to move quicker will have no consequence other than burn a few CPU cycles.

  5. Click the word "Maps," as shown circled in Figure 4.29.

  6. In the "User Name Mapping on local computer" dialog, select the "Simple Maps" check box.The "Windows domain to NIS domain mapping" dialog box appears, as shown in Figure 4.29.

  7. The Windows domain name " AD " is automatically filled in. Here's the trick: when entering the "NIS domain name," be sure it matches the precise case you see in the NIS domain under "Server for NIS." Click "OK."

  8. In the upper-right corner of the "Maps" screen, select "Apply."

At this point, you've done it. However, for an extra test, select the "Show User Maps" hyperlink and scroll down to the bottom of the page to locate the "Display simple maps in Mapped users list" check box, as shown in Figure 4.30.

image from book
Figure 4.30: The "Display simple maps in Mapped users list" check box demonstrates that queries to NIS will return Unix UIDs stored in Active Directory.

If you haven't clicked the "Apply" button in the upper-right corner, be sure to do so, as you could lose all your settings if you do not. At this point you can close the SFU 3.5 console.

Securing the Underlying homedirs Structure

Earlier, you set the homedirs directory so that mere mortal user accounts cannot read, write, or do much else. However, you do need to add one particular user for access: your Active Directory root user you created earlier with the UID of 0.

In the "Security" tab of the homedirs properties, you need to explicitly add in the new Active Directory root user you created and grant this user "Read & Execute," "List Folder Contents," and "Read" permissions, as shown in Figure 4.31.

image from book
Figure 4.31: Your Active Directory root user needs to have "Read & Execute", "List Folder Contents," and "Read" access on the homedirs directory. You also need to add "Authenticated Users" and give them "List Folder Contents" permissions.

Remember how earlier, when setting up NFS permissions, you selected "Allow root access"? Well, root access was only granted to mounting the share. When it actually comes to seeing what's inside, you'll have no joy until you explicitly add root so it can "see" what's inside this directory. Additionally, you need to add "Authenticated Users" to the list and give them "List Folder Contents" permissions. Yes, this means that all users will be able to see each others' home directoriesbut in the very next step we're going to prevent them from being able to see inside each others' home directories.

Securing a Directory for Each Active Directory User

Now you're ready to create specific directories for each user inside your new homedirs share you created earlier. In Figure 4.32, we can see two hand-created directories salesperson1 and salesperson2 for testing. The goal is to set the permissions so that only the designated user, and the Administrators group can dive in and use the files.

image from book
Figure 4.32: Specifically grant each user access on their own home directory.

However, by default each home directory you create for a user will inherit the permissions from the homedirs directory above it, and this directory has too many permissions. Specifically, it allows Authenticated Users "List directory contents" and allows the Active Directory root user "Full Access." We're going to remove those two entries at the user's specific folder level. To configure an individual user's home directory:

  1. If not already done, create a directory with the same name as a user inside the homedirs directory.

  2. Right-click the directory and select "Sharing and Security." Select the "Security" tab to bring up the NTFS security properties of the directory.

  3. Click the "Advanced" button to bring up the "Advanced Security Settings".

  4. Uncheck the "Allow inheritable permissions from this object and all child objects. Include these entries explicitly defined here" check box. The "Security" dialog will appear asking how you should handle permissions. Select "Copy." At the "Advanced Security Settings for homedirs " screen, click "OK".

  5. At the "Properties" page for the directory, select "Authenticated Users" group and click "Remove." Additionally, select the Active Directory root user and click "Remove."

  6. Click the "Add" button, and in the "Select Users, Computers, or Groups" dialog box, enter the name of the user who will own the home directory.

  7. Grant the user "Full Control" rights, as seen in Figure 4.32.

  8. Click "OK" to close the properties of the specific home directory.

Repeat these steps for each user you wish to create a unified home directory for.

Setting Windows Users in Active Directory to Use SMB Home Drives

Setting up each user to use their new home drive in Windows is easy. Just fire up Active Directory Users and Computers, select the "Profile" tab, and enter the full SMB share and path.

For instance, as shown in Figure 4.33, we're connecting H: to \\windc1\homedirs\salesperson1 .

image from book
Figure 4.33: Use the "Profile" tab in "Active Directory Users and Computers" to specify which drive letter to map to the user's home directory. Be sure to specify the UNC path name for the homedirs share, including the user's specific directory.

The next time salesperson1 logs on to xppro1.ad.corp.com , the user will automatically have the H: drive mapped and it will be all his! salesperson1 can, for instance, launch Windows Notepad and create a text file, saving it to drive H: as myfirsthomefile.txt , as shown in Figure 4.34.

image from book
Figure 4.34: salesperson1 's home drive, as seen from a Windows workstation. All of salesperson1 's files are visible, including files created in Linux.

You'll note that this figure includes some unfamiliar filenames beginning with a "." character. We're jumping ahead in time a little bit here, showing you what the home drive will look like after salesperson1 has also logged on from a Linux workstation (that's coming right up.) Linux doesn't have separate home and profile folders. Instead, Linux keeps profile settings in files beginning with a period, commonly referred to as "dotfiles." Linux knows not to display these in the file browser by default. So users who switch between the two operating systems will need to be educated to leave these "dotfiles" in peace .

Configuring Linux Clients to Use NFS Home Drives

This time the easy part is on Linux! Or rather, it's easy if you have already completed Chapter 3. Here we make one key assumption: you will use the same Linux client system that you created in Chapter 3 to demonstrate the use of LDAP authentication with Active Directory .

This is not adlincli1 .

This is quite important. For this procedure to work, your Linux client must "see" the same user IDs that the Windows NFS server is seeing, and that means your client must fetch user IDs via LDAP from Active Directory, as covered in Chapter 3 in the section "Using Extended Active Directory for Linux Authentication." So if you haven't created that client system yet, go back and do it now. We will call this client system adldaplincli1.ad.corp.com to avoid confusion with adlincli1.ad.corp.com .

To configure adldaplincli1.ad.corp.com to use the /homedrive NFS export of the Windows server, just refer to the "Connecting Linux NFS Clients to Linux NFS Servers" section of this chapter. The procedure is exactly the same, except for one small difference in /etc/fstab . We need to specify the Windows server rather than the Linux server, and the /homedirs export rather than the /home export.

When following the instructions in that section, be sure to replace the line:

 linserv1.corp.com:/home /home nfs 

with this line:

 windc1.ad.corp.com:/homedirs /home nfs 

When you have completed the procedure, you'll be able to log in as the user salesperson1 or any other Unix-enabled user in the AD domain.

Congratulations! You have successfully unified your home directories for Windows and Linux workstations. A user can now log in as salesperson1 on a Linux client and see the files created under Windows, as shown in Figure 4.35. Also refer to Figure 4.34 to see how this looks from the Windows side.

image from book
Figure 4.35: salesperson1 's home drive, as seen from a Linux workstation. All of salesperson1 's files are visible, including files created in Windows.


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