Extending Active Directory with UnixLinux Information

Extending Active Directory with Unix/Linux Information

In the previous section, we saw that Linux clients can authenticate to an unmodified Active Directory server. While it's an interesting technical feat, this technique has limitations. Specifically , keeping Unix user IDs and group IDs consistent among Linux systems is a challenge when an unmodified Active Directory server is used for authentication.

So the answer is simple: modify Active Directory so it can get to understand Linux a bit better.

The "big picture" goal is to leverage Active Directory as the "go to" source for account information. Then the idea is that you can change the password in just one place: Active Directory. Storing Linux account information in Active Directory is the goal. Except there's one big problem: out of the box, Active Directory doesn't have the ability to store Unix user, group, and computer account information.

For Windows accounts, Active Directory knows just what to do. It has specific placeholders for things like username, group name , home directory, office phone, etc. However, Active Directory simply doesn't have placeholders for lots of Linux account attributes. Specifically, the two main things we need to teach Active Directory about are Unix user IDs (UIDs) and group IDs (GIDs).

Beyond that, Active Directory also needs to be taught about a location for Linux home directories, which login shell any particular user should use, and a whole lot more.

In short, Active Directory needs to be taught how to embrace Unix user, group, and computer account information. For it to do that, we'll need to extend the Active Directory schema. You extend the schema based on which version of Active Directory you are running.

  • If your domain is Windows 2000 or Windows 2003, download and install the free Services for Unix 3.5 installation from Microsoft.

  • If your domain is Windows 2003/R2 (or you're about to upgrade from Windows 2003 to Windows 2003/R2), then upgrade your Active Directory to the Windows 2003/R2 schema. The Windows 2003/R2 schema specifically includes attributes suitable for storing Unix/Linux account information.

Let's better understand how these paths are different.

Possible Ways to Extend Active Directory

As of this writing, Windows 2003 is out, and Windows 2003/R2 is close at hand. To that end, you may be rearing to go install Windows 2003/R2 when it comes out, or you might wait a while until your other system administrator pals have taken the plunge. So, depending on the road you take, you'll need to know precisely how to extend Active Directory to get Unix/Linux account information inside.

If You have Windows 2000 and Windows 2003: Extend the Schema via SFU 3.5

In this chapter, we're about to inspect and install Microsoft's Services for Unix 3.5. It's a free add-in to Windows 2000 and Windows 2003 that allows Windows to embrace all sorts of Unix-like functionality; it can be downloaded at www.microsoft.com/sfu .

Warning 

You should always download the latest version of SFU 3.5. There have been updates to SFU 3.5 since its release to support Windows 2003 + SP1, but older SFU 3.5 CDs (which you might have picked up a trade show) might have problems.

One of the main facets of SFU 3.5 is that it automatically extends the Active Directory schema so that Unix and Linux attributes can be tucked inside. Once SFU 3.5 is installed on a Domain Controller (which we'll do in a little bit), the Active Directory schema is extended to support the necessary attributes used to support Linux accounts. When this happens, Active Directory will have the information it needs if it wants to act as a NIS server. Yes! It's true. For more information on this added capability, see the sidebar "Really? Active Directory as a NIS Server?"

For a complete list of what's updated in the Active Directory schema, check out a document from Microsoft titled "Windows Services for UNIX 3.0: Schema Changes for Server for NIS" at http://tinyurl.com/6wcu7 .

Note, even though the name of the document says "Windows Services for Unix 3.0" it's still 100 percent valid for SFU 3.5.

If You have Windows 2003/R2: Extend the Schema via Windows 2003/R2

If you're taking the plunge to Windows 2003/R2, that's great. And one of Windows 2003/R2's key advertised features is that it has Unix Identity Management built right into it. In other words, when you upgrade a Windows 2003 domain to Windows 2003/R2 (or build a Windows 2003/R2 domain from scratch) your Windows 2003/R2 domain will have a schema that automatically has placeholders for Unix/Linux accounts.

These placeholders are similar, but not exactly the same as what SFU 3.5 (and SFU 3.0) perform. In short, and to be blunt, the SFU 3.5 schema updates are proprietary. Microsoft has publicly expressed how the Windows 2003/R2 schema updates are RFC compliant. Specifically, they are RFC 2307 compliant. RFC 2307 defines a set of classes and attributes for storing NIS information in LDAP.

The goal of RFC 2307 is to have a unified way to describe how to extend modern LDAP to contain old-and-crusty NIS data. For instance, you might need to extend another LDAP server, like an old Sun iPlanet (now with the impossible name Sun Java System Directory Server), Netscape Directory Services (or whatever they'll call it), or, yes, Active Directory!

Here's the dealthe RFC 2307 extension that Windows 2003/R2 employs are RFC 2307 compliant. But here's the kicker it doesn't employ the entire set of RFC 2307. Yes, that's right. Windows 2003/R2 employs an incomplete set of the RFC 2307. What does this mean for you? Likely not much, unless you have a third party LDAP server that is looking for an RFC 2307 attribute in Active Directory that Windows 2003/R2 doesn't support.

In the downloadable web appendix, we'll specifically demonstrate how to install the Windows 2003/R2 schema, as well as take on the other main parts of this chapter going forward with Windows 2003/R2 (instead of just Windows 2003.) We'll also show you what happens if you've already committed to Windows 2003 and SFU 3.5, then decide to do an upgrade to Windows 2003/R2.

Services for Unix 3.5 Components and Installation

For the rest of this chapter, we're going to assume you're working with Windows 2003 (and not Windows 2003/R2.) To that end, Services for Unix (SFU) 3.5 allow Windows 2000 and 2003 to embrace all sorts of Unix-like functionality. Remember, you should always download it at www.microsoft.com/sfu .

We'll explore some of the functionality explored within SFU 3.5 here because it has ramifications about authentication. We'll explore other functionality in later chapters because they deal with other tools, components, and other utilities that aren't germane to authentication.

So, since we're here anyway, we'll install SFU 3.5 with all the components we'll be talking about in the book.

Tip 

A bunch of great "how-to" articles on SFU 3.5 is available at www.microsoft.com/technet/interopmigration/unix/sfu/default.mspx . Note that SFU 3.5's main enhancements over SFU 3.0 are mostly performance- and cluster-specific. In other words, the technical articles for SFU 3.0 are likely just as valid for SFU 3.5.

What does SFU 3.5 have to Offer?

Here's a rundown of what SFU 3.5 contains. With a price tag of $0.00 is a pretty good deal:

  • Server for NIS This component allows a Windows 2000 or Windows 2003 Domain Controller to pretend to be a master NIS server. It can also pretend to be a slave NIS server but only to other Domain Controllers with the NIS Server components runningnot to Unix NIS master servers. Using this component, you can get rid of all your Unix NIS servers and centralize NIS account information in Active Directory. Why is this good? See the sidebar titled "Really? Active Directory as a NIS Server?"

  • Password Synchronization This suite of tools helps keep collections of Windows and Linux computers up-to-date with password changes on either platform. We'll briefly touch on these features at the end of the chapter.

  • NFS Client, Server, Gateway, and Client for PCNFS and User Name Mapping A suite of tools that runs on a Domain Controller that allows a Windows user to transparently view files contained within Unix/Linux NFS shares. This is explored more in Chapter 4.

  • Base Utilities If you're already familiar with the Unix/Linux set of commands, (e.g., ls, cat, grep , and more), this is the perfect addition. We'll reexamine the base utilities in Chapter 7.

  • Telnet Server and Telnet Client Telnet Server is already built in to both Windows 2000 and Windows 2003. However, loading this software on a Windows 2000 machine gives you a more enhanced version. SFU installs a Telnet Server and Client that operate in both stream and console mode (useful if your Unix application requires it). We won't be exploring the Telnet Server or Telnet client in this book.

  • Development Tools SFU 3.5 includes tools for compiling existing Unix software for which the source code is available in order to make that software work on Windows. We'll talk in more detail about this in Chapter 10.

Note that you can load SFU 3.5 on Windows 2000 and higher, but not all features are available unless you install SFU 3.5 on a server and/or a Domain Controller. Specifically, here's what you won't get:

  • If you load SFU 3.5 on a Windows 2000 or Windows XP workstation, neither Gateway for NFS nor Server for NIS will install.

  • If you load SFU 3.5 on a member server (not a Domain Controller), Server for NIS will not install.

SFU 3.5 Installation

The installation of SFU 3.5 is pretty straightforward. However, there is one key point you need to be aware of before you run the installation program.

As we described, SFU 3.5 has the ability to pretend to be a NIS server. It does this by maintaining Linux accounts in Active Directory. That's the good news. The bad news is that Linux accounts are looking for information about those accounts that aren't "built-in" to Active Directory. Hence, we need to extend the schema of Active Directory. This is a one-time, irreversible operation. Many large corporations make schema changes part of their change-management process. A lot of smaller companies just go for it, usually without incident, but we would be remiss if we didn't express that this is a permanent, one-way change. However, for the examples in this book, we're going to need to have implemented the schema change, so that's what we're going to do here. In practice, there's very little likely to go wrong.

image from book
Really? Active Directory As a NIS Server?

It's true that you can make an Active Directory Domain Controller respond as if it were a Unix NIS server. Why would you ever want to do this? There are a slew of reasons why you might consider this strange combination:

  • Your Unix clients remain untouched (as they think they're still talking to a Unix NIS server). However, they do need to rebind to the Active Directory/NIS server.

  • Old and crusty Unix NIS servers can be decommissioned.

  • Active Directory replication does the hard work of (securely) replicating user accounts around. The "NIS master" role can be played by all Active Directory servers as a result of the multimaster replication capabilities of Active Directory, eliminating a single-point-of-failure inherent to NIS. Active Directory replication is far more robustand far more bandwidth friendlythan traditional NIS map propagation.

  • User provisioning for both Windows and Linux clients would be through one unified tool: Active Directory Users and Computers. You could argue that this lowers costs and simplifies workflow.

In short, this is a low-risk solution that saves some money, increases robustness, and offers a unified tool (Active Directory Users and Computers) and some quality-of-service improvements.

If the idea is so wonderful, why aren't we describing in detail how to do it? Because, in reality, there are larger gains from migrating from NIS and converting those accounts to either Active Directory or OpenLDAP than from keeping NIS around any longer than necessary. However, making a larger jump like this does mean greater risk during the transition.

It might sound like a good idea to leverage this "Active Directory as a NIS server" as a stepping stone to get all your Unix accounts directly into Active Directory. Indeed, you can do this, but be aware that this path could be fraught with peril. In a nutshell , there are a lot of manual steps you need to get right.

A better choice is to perform a migration from NIS to Active Directory or OpenLDAP. Here's how you might go about performing that sort of project (which is beyond the scope of this book). For free advice:

  • A Google search for "NIS to LDAP Migration" yields plenty of hits. There seem to be lots of scripts that profess to migrate NIS data directly to LDAP.

  • Check out Microsoft's excellent document "Solution Guide for Windows Security and Directory Services for Unix" at http://go.microsoft.com/fwlink/?LinkID=23115 .

There are also some commercial options I know that will help you leave NIS behind and go straight to an LDAP directory:

  • PADL Software has a NIS/LDAP gateway product for sale at www.padl.com/Products/NISLDAPGateway.html . Quoting from its website, "It permits existing NIS clients to transparently use LDAP to resolve user, group, and host information."

  • Vintela's VAS product (also discussed later) has a set of tools to help convert NIS tables directly to Active Directory. Check out www.vintela.com .

  • Centrify (at www.centrify.com ) also has tools to help you convert NIS to Active Directory.

Before we leave this section, there is one aspect of Active Directory running as a NIS server that we must leverage in order to be successful. We'll explore that in Chapter 4 when we explore file sharing. Specifically, we must "ask" the Active Directory running as a NIS server to help us determine which user on Linux "maps" to which user in Active Directory. This is all part of the User Name Mapping service, which must interface with Active Directory running as a NIS server. Stay tuned .

image from book
 
Note 

Again, don't proceed if you have Windows 2003/R2. If you do, please download and read the web appendix, which discusses how to proceed.

Now that you understand what SFU 3.5 will do to our Active Directory schema, we're ready to roll. To install SFU 3.5 on our Windows 2003 DC (with the options needed for this book):

  1. Start the SFU 3.5 installation program (SfuSetup.msi).

  2. At the "Welcome" screen, click " Next ."

  3. At the "Customer Information" screen, enter your name and the organization name.

  4. At the "License and Support Information" screen, accept the agreement and click "Next."

  5. At the "Installation Options" screen, select "Custom Installation" and click "Next."

  6. At the "Selecting Components" screen, drill down to Windows Services for Unix image from book NFS image from book Gateway for NFS. Change the defaults so that component is additionally loaded, as shown in Figure 3.9. Additionally, the "Client for NFS" must, unfortunately , be disabled as also seen in Figure 3.9. Again, we'll need to load the NIS server components of SFU 3.5 for this book. They need to be loaded in order to extend the schema. Additionally, they're used in the next chapter in conjunction with the User Name Mapping service.

  7. At the "Security Settings" screen, you have two options: "Enable setuid behavior for Interix programs" and "Change the default behavior to be case sensitive." For our examples, we don't require either of these settings to be checked. (With these options, you decide how Windows should handle case-sensitivity .)

  8. Next, you'll see the "User Name Mapping" screen. We're going to use this feature in the next chapter, so select the "Network Information Service (NIS)" button and click "Next."

  9. You'll next see screen 2 of "User Name Mapping." Select your Windows domain name from the drop-down (in our case it's "AD"). Leave the "NIS domain name" field blank. Also, leave the "NIS Server name:" field blank. Click "Next" to continue.

  10. At the "NIS/Password Synchronization" screen, you'll get a warning stating that schema changes are irreversible. For the purposes of this book, we'll need the changes, so click "Next" to continue.

  11. At the "Install Location" screen, select where you want to install SFU 3.5 The defaults are fine (" c:\SFU "), so click "Next."

image from book
Figure 3.9: Avoid installing the "Client for NFS" and the "Password Synchronization" features, but do install the "Gateway for NFS."

At this point, SFU 3.5 will install. When completed, you'll likely be asked to reboot. Do so, and you'll be ready to continue.

How to Unix-Enable Your Active Directory Users and Groups

Now that SFU 3.5 is fully installed, you can Unix-enable your Active Directory users and groups. It's easy. To get started, just fire up Active Directory Users and Computers. Then, to Unix-enable a user account, we must first have a Unix-enabled group account.

Unix-Enabling an Active Directory Group

Using Active Directory Users and Computers, double-click the SalesGroup we created earlier in the chapter. You'll see a new tab labeled "Unix Attributes," as shown in Figure 3.10.

image from book
Figure 3.10: You can Unix-enable an Active Directory group.

To Unix-enable the group, simply pull down the drop-down in the NIS domain box to select your Active Directory. When you do, Active Directory will automatically assign a GID (group ID) for this Active Directory group that's also now a Unix group.

Unix-Enabling an Active Directory User

Earlier in the chapter, we created salesperson1 and salesperson2 in the Sales OU. Double-click the salesperson1 account and select the "Unix Attributes" tab, as shown in Figure 3.11.

image from book
Figure 3.11: You can Unix-enable your users and specify which Unix-enabled groups they are members of.

To Unix-enable the user, simply pull down the drop-down in the NIS domain box to select your Active Directory. When you do, Active Directory will automatically assign a UID (user ID) for this Active Directory group that's also now a Unix user.

While you're here, you can select " SalesGroup " in the "Primary group name/GID" field. This field is only populated with Active Directory groups that have Unix attributes such as we just set up with the SalesGroup .



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