I can't connect a linux(fedora core 3) client to win2003 via ldap,kerboros,
(and sfu 3.5(services for unix
I got this error when use these commands
Su – salesperson1
Su: user salesperson1 does not exist
&
Ldapsearch –v
Ldap_sasl_interactive_bind_s: cant't contact ldap server (-1);
I be able to ping to server from linux and viceversa
please tell me how can I connect it!
Preparing Active Directory for User Logins
You already set up Active Directory in
Chapter 1. When you did, you created a centralized repository for user, group, and computer accounts to be authenticated to. In this chapter, we'll start to leverage that repository and make it worth the money you paid for it.
Now is a great time to create some sample user accounts in some sample OUs (organizational units). Otherwise, we'll have no user accounts to authenticate against (other than the administrator account).
Creating Active Directory Organizational Units (OUs)
First, we'll create our OUs, then we'll put some sample users inside. To create our OUs:
- Log on to your Windows Active Directory server as the domain administrator. Select Start [IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image001.gif[/IMG]Programs [IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image001.gif[/IMG]Administrative Tools [IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image001.gif[/IMG]Active Directory Users & Computers.
- Right-click the domain name (ad.corp.com) and select New [IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image001.gif[/IMG]Organizational Unit, as shown in Figure 3.1.
- In the "New Object — Organizational Unit" dialog, enter Sales.
Repeat these steps and create another OU for Marketing and another for Human Resources.
Creating Active Directory User Accounts
It's easy to create Active Directory users. Simply right-click the OU in which you want to create your users and select New [IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image001.gif[/IMG]User. Then, follow the wizard to create your first user.
- In the Sales OU, create two users: salesperson1 and salesperson2.
- In the Marketing OU, create two users: marketperson1 and marketperson2.
- In the Human Resources OU, create two users: HRperson1 and HRperson2.
Be sure to give everyone the same password. For this book, we'll stick with p@ssw0rd. We'll use these users a bit later.
Creating Active Directory Group Accounts
It's also easy to create Active Directory groups. Simply right-click the OU in which you want to create the group and select New [IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image001.gif[/IMG]Group. Then follow the wizard to create your first user. In the Sales OU, create a group named SalesGroup.
To add salesperson1 and salesperson2 to that group, press Shift and click both salesperson1 and salesperson2, right-click and select "Add to a group," then choose the new SalesGroup you created.
Repeat by creating MarketingGroup and adding marketperson1 and marketperson2 to it. Additionally, create HRGroup and add HRperson1 and HRperson2 to it.
We'll use the SalesGroup a bit later in this chapter and the others in the
next chapter.
Authenticating Windows Clients to Active Directory
To authenticate Windows clients to Active Directory, the computer account has to be "joined" to the domain. You should have already done this in
Chapter 1 during setup, but if you weren't able to perform this step for some reason, here's how to do it.
Joining Windows XP Machines to Active Directory
Select Start, then right-click My Computer and select "Properties." Select the "Computer Name" tab, then click the "Change…" button. At the "Computer Name Changes" screen, select the radio button labeled "Domain:" then enter the name of the domain. You can enter either AD (the short name) or ad.corp.com (the Fully Qualified Domain Name); then press Enter. Enter your administrative credentials to join the domain, then reboot.
If you're having trouble joining the domain, be sure to check the client's IP address, subnet mask, and DNS settings. Specifically, make sure the client machine is using the IP address of windc1.ad.corp.com (192.168.2.226) as the "Preferred DNS server."
Logging into Active Directory from Windows XP
There's nothing special that you need to do to authenticate Windows Clients to Active Directory. On rebooting your Windows XP machine, you'll be asked to select the domain to authenticate to in the Ctl+Alt+Del drop-down, as shown in
Figure 3.2.
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 deal—the 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.
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 running—not 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.
[IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image003.gif[/IMG]
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 robust—and far more bandwidth friendly—than 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.
[IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image003.gif[/IMG]
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):
- Start the SFU 3.5 installation program (SfuSetup.msi).
- At the "Welcome" screen, click "Next."
- At the "Customer Information" screen, enter your name and the organization name.
- At the "License and Support Information" screen, accept the agreement and click "Next."
- At the "Installation Options" screen, select "Custom Installation" and click "Next."
- At the "Selecting Components" screen, drill down to Windows Services for Unix [IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image001.gif[/IMG]NFS [IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image001.gif[/IMG]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.
- 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.)
- 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."
- 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.
- 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.
- At the "Install Location" screen, select where you want to install SFU 3.5 The defaults are fine ("c:\SFU"), so click "Next."
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.
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.
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.
Using Extended Active Directory for Linux Authentication
In the immediately preceding section, we enhanced our Active Directory sever by installing Microsoft Services for Unix (SFU). Or perhaps you downloaded the web-appendix and learned how to extend the schema using Windows 2003/R2.
Active Directory is now aware of Unix user IDs and group IDs and has provisions to store them for each user and group account. That means we can authenticate Linux clients directly against Active Directory without worrying about file ownership inconsistencies when files are moved from one Linux client to another, because Active Directory is the sole arbiter of user and group IDs. This is a great improvement over the Winbind-based approach we discussed earlier. For the full gist of this, see the sidebar earlier, titled "
How Winbind Fakes Linux User IDs (and How It Can Hurt)."
But how does the Linux client obtain the Unix user ID (UIDs) and group IDs (GIDs) from the Active Directory server? Since those fields are not part of the traditional Windows networking protocols, Linux's Winbind (which emulates those protocols) can't grab the goods. Handily for us, Active Directory responds to LDAP queries and, because we can use our Linux client to make LDAP queries to Active Directory, we can just ask for those UIDs and GIDs.
Setting the Stage for Active Directory/LDAP Requests and Authentication
In the last chapter, we authenticated a Linux LDAP client to a Linux LDAP server in the section "
Authenticating Linux Clients to the OpenLDAP Server." When we did this, the OpenLDAP client components on lincli1.corp.com made contact with the OpenLDAP server components on linserv1.corp.com. In one fell swoop, we looked up our user account and authenticated directly to OpenLDAP. Nice.
Now our goal is to get the OpenLDAP client components on a brand new machine, adldaplincli1.ad.corp.com, and have it talk to the Active Directory on windc1.ad.corp.com, as shown in
Figure 3.12.
But "talking" to Active Directory isn't enough. There are two big steps the Linux client needs to perform:
- Step 1 Find the user account in Active Directory and grab the UID and GIDs (and other information home directory paths) stored therein. We'll configure the client pieces of OpenLDAP on adldaplincli1.ad.corp.com to make contact to Active Directory to do this.
- Step 2 Authenticate to Active Directory. We'll use a robust protocol that Active Directory uses to do the same task: Kerberos. This is a very strong protocol that protects all authentication traffic.
If we're really feeling frisky, we can go the extra mile and encrypt the LDAP traffic whenever we ask Active Directory to find our user accounts (in that first step).
Note
Step 1 is the easy part. It'll be similar to what we did in Chapter 2's "
Authenticating Linux Clients to the OpenLDAP Server." Step 2 is the new part. We'll simply configure our Linux client to authenticate directly to Active Directory's Kerberos server components. The optional "extra mile" of encrypting the initial LDAP traffic is the hard part. You'll see why a bit later.
[IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image003.gif[/IMG]
About Kerberos Authentication
Kerberos is a standard for authenticating and authorizing users. Built into Microsoft's Active Directory at a fundamental level, Kerberos is also used by Linux and other operating systems.
Kerberos is highly secure and also has other advantages beyond simple login authentication. One of the most interesting is that Kerberos makes it much easier to implement "single sign-on," allowing a user access to many services after they log on without the need to present a password over and over again.
Unfortunately, most popular Linux applications are not yet "kerberized," so we won't benefit much from the single sign-on feature in this book. For the purposes of this chapter, the most important feature of Kerberos is its ability to authenticate logons in a highly secure fashion, but it's worth bearing in mind that additional benefits will appear as more and more applications such as web browsers and file sharing clients are "kerberized."
Kerberos is a complex beast, and multiple books have been written about the protocol. For our purposes, here are the three fundamental crib notes:
- First, a Kerberos server is properly known as a "KDC" (Key Distribution Center). The term "KDC" appears in the Fedora authentication configuration dialogs, so we'll try to be consistent and use that term.
- Second, a KDC plays host to a Kerberos "realm," which has a name of its own. A single Kerberos server could, in theory, be the "go to" server and host many different collections of security principals without name conflicts (as long as they all belonged to different realms.) In practice, however, an Active Directory domain's Kerberos realm name always matches the Active Directory domain name, but IN ALL CAPS. And that's important. Entering the Kerberos realm name in lowercase (as it typically appears in Windows) will simply not work.
- Third, a Kerberos "admin server" is a KDC that has the power to change passwords on a user's behalf. It is possible to create distributed "master" and "slave" KDCs, and in that situation we might specify a separate "admin server." But for our purposes in this book, the admin server is the same as the KDC.
[IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image003.gif[/IMG]
Warning
If you have not extended the Active Directory schema with Microsoft Services for Unix (SFU) 3.5, or Windows 2003/R2, you'll need to do that now as described earlier.
To pull this off, we'll refine our two "big steps" into five ministeps:
- We'll add a user account to the Active Directory server purely for LDAP browsing purposes. The issue here is that Active Directory always requires us to authenticate at the LDAP level as a user before we can make any directory queries, so we'll create a special account for that purpose.
- We'll set up our Fedora Linux workstation to use LDAP "user information" directory services. The Fedora GUI does about 90 percent of the work.
- We'll set up the workstation to use Kerberos authentication and specify the name of the Kerberos KDC (Key Distribution Center). The Fedora GUI takes care of this step for us very neatly.
- We'll reconfigure /etc/ldap.conf, allowing Linux to interoperate correctly with Active Directory. There are a few extra settings needed to account for differences between Active Directory and other LDAP user account directories. (See Chapter 2 for an introduction to /etc/ldap.conf.)
- We'll make sure that home directories can be created as needed.
Then we'll be ready to log in to Active Directory using LDAP and Kerberos! Hold on to your seats! (And people think we lead boring lives.)
Setting Up a User Who can "Touch" Active Directory
In order for Linux clients to search Active Directory via LDAP for user accounts to utilize, you have to make a choice. You could "dumb down" Active Directory and allow "anonymous" LDAP traffic. You have to change the way the Active Directory reacts to queries. This is called the "heuristics" of the directory service. KB article 326690 describes how to modify the Active Directory heuristics to allow anonymous queries."
A better solution is to just tell our Linux clients about a regular user account for which we provide a password in the LDAP configuration file. Insecure? Maybe a little bit, but this user account won't really be able to do anything. The account will have no privileges other than be able to make LDAP queries. This special account will authenticate using LDAP "simple authentication."
Here's the bad news: simple authentication sends the user's password in cleartext. Because of this, at the end of this chapter, we'll go the extra mile and encrypt the LDAP traffic. So let's go ahead and create this special account that will enable LDAP lookups.
In this example, we'll create an Active Directory user account called dirsearch:
- Select Start [IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image001.gif[/IMG]Programs [IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image001.gif[/IMG]Administrative Tools [IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image001.gif[/IMG]Active Directory Users and Computers.
- Right-click the "Users" folder, and select New [IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image001.gif[/IMG]User.
- Follow the wizard to create your first user. You can fill in any name you want in the "First name" and "Last name" and "Full name" fields. Just be sure to enter dirsearch in the "User logon name" field.
- Be sure to enter the same password as usual: p@ssw0rd.
- Once the user is created, double-click the account and select the "Account" tab. Check "User cannot change password" and "Password never expires."
Configuring the LDAP Client with the Fedora Authentication Tool
Rather than use one of the Linux clients that we configured previously, before proceeding, we'll create a brand-spankin' new Fedora Core 3 client so we're sure to avoid interactions with other authentication methods. The goal of this Linux client is to authenticate to Active Directory using LDAP. In our examples, we'll call this fresh machine adldaplincli1.ad.corp.com (think of that as "active directory ldap linux client #1").
We need to tell our new Linux client to look up user information using LDAP and to perform authentication with Kerberos. We'll use the Authentication tool, accessed via the "
System Settings" submenu of the "Applications" menu. This was covered at length in
Chapter 2.
Configuring LDAP User Information
To configure the Fedora Core 3 Authentication tool to perform lookups using LDAP:
- On your Linux client machine, from the Applications menu select System Settings [IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image001.gif[/IMG]Authentication. The "Authentication Configuration" dialog will appear.
- You will default to the "User Information" tab. Check the "Enable LDAP Support" box.
- Select the "Configure LDAP" button. The "LDAP Settings" dialog appears. Then, set the LDAP Search Base DN to dc=ad,dc=corp,dc=com and the LDAP server name to windc1.ad.corp.com. Do not check "Use TLS to encrypt connections" at this time. We'll reexamine that issue in the "Securing Active Directory LDAP Traffic" section. You can see these settings in Figure 3.13.
- Click "OK" to return to the "Authentication Configuration" dialog. Now you're ready to configure Kerberos authentication.
[IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image008.gif[/IMG]
Figure 3.13: Enter the name of the Active Directory distinguished name (dn) and the Active Directory server name.
Configuring Kerberos Authentication on the Client
Fedora makes setting up Kerberos authentication easy. Just follow these simple steps to configure Kerberos authentication with your Active Directory server. Again, we'll be performing these steps on the adldaplincli1.ad.corp.com client. To configure the Linux client for Kerberos authentication to Active Directory:
- If you have not already done so, access the Fedora Authentication tool as described in the previous section.
- Click the "Authentication" tab.
- Check the "Enable Kerberos Support" box.
- Click "Configure Kerberos"; you'll see the "Kerberos Settings" dialog.
- In the "Realm" field, enter AD.CORP.COM in ALL CAPS (as shown in Figure 3.14).
- In the "KDCs" field, enter windc1.ad.corp.com .
- In the "Admin Servers" field, enter windc1.ad.corp.com . Note that we'll leave the two check boxes for DNS entries unchecked. That's because we're specifying the entries instead of asking the system to try to find them.
- Click "OK" to exit the "Kerberos Settings" dialog.
- Click "OK" to exit the Authentication tool.
[IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image009.gif[/IMG]
Figure 3.14: Enter the Active Directory name and the name of our Active Directory Domain Controller in the Kerberos Settings in the Authentication tool.
Achieving Compatibility with SFU-Enhanced Active Directory
If we were using an ordinary Linux-based LDAP server, we'd be nearly done at this point. However, there are a few important differences between Active Directory and the OpenLDAP server we built in the
previous chapter.
First, we need to spell out the key differences in /etc/ldap.conf settings when communicating with an Active Directory server (versus an OpenLDAP server).
In this section, we'll introduce each /etc/ldap.conf option that provides compatibility with Active Directory's LDAP support. Here, we need to:
- Tell Linux which Active Directory account to utilize for searching.
- Tell Linux which fields to use in Active Directory.
- Tell Linux where to dig up a user's account information.
- Tell Linux where to start searching for users in Active Directory.
- Tell Linux where to locate the "username" field in Active Directory.
- Speed up Active Directory searches.
Then we'll present a complete /etc/ldap.conf file that uses these features to successfully obtain user information via an SFU-enhanced Active Directory server's LDAP interface.
Tip
Panic not if you're using the Windows 2003/R2 schema. Simply download the web appendix for how to achieve the same level of compatibility with a Windows 2003/R2 schema.
Tell Linux Which Active Directory Account to Utilize for Searching
By default, Active Directory does not allow "anonymous bind" via LDAP. That means that clients must log into the LDAP interface of Active Directory with a valid username and password; that's why we created our dirsearch user in the Active Directory. Our goal is to present that dirsearch user's LDAP "distinguished name" when needed so we can touch Active Directory.
The two lines we'll need to add to the /etc/ldap.conf file are
binddn cn=dirsearch,cn=Users,dc=ad,dc=corp,dc=com
bindpw p@ssw0rd
You'll see these in the final /etc/ldap.conf file at the end of this section.
Tell Linux Which Fields to Use in Active Directory
As previously described, there are dueling standards for extending Active Directory's schema: the SFU 3.5 way and the Windows 2003/R2 (RFC 2307) way. (See the section titled "
Possible ways to extend Active Directory".)
Since in this chapter, we're demonstrating the schema extensions of SFU 3.5, we need to teach Fedora Core 3 how to leverage the SFU 3.5 schema attributes.
When Services for Unix extends the Active Directory schema, the new attributes are prefixed with msSFU30. Yes, that's right. They're msSFU30 even though we're working with SFU 3.5. So, for instance, the Unix home directory field in an Active Directory extended with SFU 3.5 is known as msSFU30HomeDirectory.
Fortunately, nss_ldap supports a technique called schema remapping. This allows us to tell the Linux system that the homeDirectory field can be found in the msSFU30HomeDirectory field when talking to an Active Directory server. We accomplish this using the nss_map_attribute option in /etc/ldap.conf. Here are the key lines we'll add to /etc/ldap.conf. Again, you'll see the complete file at the end of this section.
nss_map_attribute uid sAMAccountName
nss_map_attribute uidNumber msSFU30UidNumber
nss_map_attribute gidNumber msSFU30GidNumber
nss_map_attribute loginShell msSFU30LoginShell
nss_map_attribute gecos name
nss_map_attribute homeDirectory msSFU30HomeDirectory
nss_map_objectclass posixGroup Group
nss_map_attribute uniqueMember member
nss_map_attribute cn sAMAccountName
Tell Linux Where to Dig Up a User's Account Information
Active Directory also calls the account object, which contains all information about an account, by a different name. In a typical Unix LDAP directory, the account object would be called a posixAccount, and the "shadow password" information would be in a similar object called a shadowAccount; Active Directory, however, has a single type or class of object, called a user, that serves both purposes.
We'll use the nss_map_objectclass option to tell Linux where the account information it expects can be found in Active Directory. Here are the key lines we'll add to /etc/ldap.conf. Again, you'll see the complete file at the end of this section.
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
Tell Linux Where to Start Searching for Users in Active Directory
The nss_base_passwd, nss_base_shadow, and nss_base_group options are similar to the base option we've discussed previously.
They must be identical to or "beneath" the base. They indicate where in the LDAP hierarchy nss_ldap should start looking for user, shadow password, and group objects. Here are the key lines we'll add to /etc/ldap.conf:
nss_base_passwd dc=ad,dc=corp,dc=com
nss_base_shadow dc=ad,dc=corp,dc=com
nss_base_group dc=ad,dc=corp,dc=com
For instance, in our example, all three are set to dc=ad,dc=corp,dc=com. This allows all users in any part of the Active Directory LDAP database to log into this workstation.
You might want to set the base to a lower point in the LDAP hierarchy, such as a particular department's organizational unit. Although beyond the scope of this book, creatively restricting the nss_base_passwd, nss_base_shadow, and nss_base_group options and the base option can improve performance and help to enforce policy. Or you might want to restrict the search to just one portion of the LDAP tree, say, an OU (organizational unit) such as Sales. This could be an effective way to restrict the use of a workstation exclusively to salespeople.
Such restrictions can also improve performance by avoiding the need to exhaustively explore tens of thousands of accounts for each login attempt when the only people who should be using a particular workstation are salespeople. Such a restricted setting might look like: nss_base_passwd ou=Sales,dc=ad,dc=corp,dc=com
But in our case, we want to search the whole Active Directory domain.
Tell Linux Where to Locate the "Username" Field in Active Directory
The user logs on by entering a username. What field in the LDAP schema should be searched for a match with that username? The key line we'll add to /etc/ldap.conf is
pam_login_attribute sAMAccountName
We use the pam_login_attribute option to set this to sAMAccountName, which is the Windows "username" field. This allows users to log into Linux workstations using the same username they would use on a Windows workstation.
Speed Up Active Directory Searches
We've covered the bare necessities, but there's one more option that will help keep us out of trouble. One additional line we'll want to add is
pam_filter objectcategory=User
By setting pam_filter to objectcategory=User, we ensure that our LDAP search doesn't waste time or generate bogus results by trying to match usernames to objects that don't contain account information at all. While it may seem unlikely that such objects will have a sAMAccountName field, they certainly could, and we speed up our search by skipping them.
Tip
Note that there are many attributes with darn similar names. Specifically, be very careful and set pam_filter to objectcategory=User (and not to objectclass=User). These are not the same. Specifically the User object class includes computer objects. Setting it to objectcategory=User specifically hones in just on user objects.
The Complete /etc/ldap.conf File for a Linux Client to Authenticate Using LDAP to Active Directory with SFU 3.5
In this chapter, the goal is to provide LDAP authentication against an SFU-enhanced Active Directory server (in our case, windc1.ad.corp.com). Our Active Directory domain name is ad.corp.com, and to search Active Directory via LDAP we're leveraging a basic user account named dirsearch (with the password p@ssw0rd). Each of these options is explained in the preceding section.
Listing 3.1: /etc/ldap.conf for LDAP Authentication against Active Directory
[IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image003.gif[/IMG]
# Here, we'll use unencryupted LDAP port 389. ("ldap")
uri ldap://windc1.ad.corp.com
base dc=ad,dc=corp,dc=com
binddn cn=dirsearch,cn=Users,dc=ad,dc=corp,dc=com
bindpw p@ssw0rd
nss_base_passwd dc=ad,dc=corp,dc=com
nss_base_shadow dc=ad,dc=corp,dc=com
nss_base_group dc=ad,dc=corp,dc=com
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute uid sAMAccountName
nss_map_attribute uidNumber msSFU30UidNumber
nss_map_attribute gidNumber msSFU30GidNumber
nss_map_attribute loginShell msSFU30LoginShell
nss_map_attribute gecos name
nss_map_attribute homeDirectory msSFU30HomeDirectory
nss_map_objectclass posixGroup Group
nss_map_attribute uniqueMember member
nss_map_attribute cn sAMAccountName
pam_login_attribute sAMAccountName
pam_filter objectcategory=User
[IMG]file:///C:/DOCUME%7E1/Slayer/LOCALS%7E1/Temp/msohtml1/01/clip_image003.gif[/IMG]
Tip
For additional information about /etc/ldap.conf, see
Chapter 2.
Making Home Directories on the Fly
We've configured the Linux workstation to use LDAP and added the crucial options to achieve compatibility with SFU-enhanced Active Directory. There's only one step to go.
When a new user logs into a particular workstation for the first time, that user doesn't have a local home directory yet. As you saw in
Chapter 2, a user can log in via three methods:
- The shell
- Encrypted shell (via ssh)
- The GNOME interface
Briefly, the procedure is:
- As root, open the file /etc/pam.d/sshd with your text editor.
- Add the following line to the end of the file:
3.session required pam_mkhomedir.so skel=/etc/skel umask=0077
- Repeat steps 1 and 2 for /etc/pam.d/gdm and /etc/pam.d/login.
Logging into Active Directory Using Linux via LDAP
We're there! Log out of your Fedora workstation and log in again as salesperson1 with the password p@ssw0rd.
You should receive a message explaining that a home directory has been created for salesperson1, and your desktop should then appear as normal.
Congratulations!
Your Linux workstation is now authenticating against an Active Directory server.
Thanks to Microsoft Services for Unix, the Active Directory server now provides centralized management of Linux user IDs and group IDs, as well as all other account information—and Windows workstations can log on with the very same accounts!
If it Doesn't Work
Here are some suggestions if it doesn't go quite as planned:
- Be sure that Windows workstations can log into the Active Directory domain using the same credentials you are testing on your Windows workstation. It bears repeating: always, always rule out the obvious.
- Make sure you installed Microsoft Services for Unix 3.5 on the Active Directory server as described in the section "Services for Unix 3.5 Components and Installation."
- Did you create the dirsearch and salesperson1 accounts on the Active Directory server? If not, do so following our instructions.
- Double-check your /etc/ldap.conf file to make sure it matches our configuration.
- As root, try the command su - salesperson1. This opens a new shell running as salesperson1 rather than root. Root can switch to any other user at any time, so you will not be prompted for a password. You should receive an illuminating error message if this command fails. If it succeeds, you'll be returned to the prompt logged in as salesperson1, so type exit to return to root's shell prompt. When this command succeeds but logon attempts still fail, it is likely that you are not logging in with the right password.
- Add a new line to /etc/ldap.conf to help you debug: just add a single line (anywhere) that says debug 1. Then try step 5 again. You should receive quite a bit of debugging output, which may shed some light on the problem. Be sure to remove that line afterward.
- As recommended at the end of Chapter 2, use the command tail -20 /var/log/messages to check for error messages relevant to the logon process.
- Always try Google searches for error messages you receive.
Checkout
To authenticate a Linux client via the LDAP interface of an Active Directory server:
- We installed Microsoft Services for Unix.
- We created a dirsearch account in the Active Directory for LDAP binding purposes. We also created a user account named salesperson1 for testing purposes.
- We used the Fedora Core 3 GUI Authentication tool to enable LDAP authorization and authentication and specified the Active Directory server as the LDAP server.
- We customized our /etc/ldap.conf file to enable compatibility with Active Directory's significantly different LDAP schema.
We added support for creating home directories on the fly using pam_mkhomedir.so.
موضوعات مشابه:
LinkBack URL
About LinkBacks
نوشته اصلی توسط shabake_karan
