Creating Trusts between Samba and Active Directory Domains | Windows And Linux Integration Hands-on Solutions for a Mixed Environment

As we stated in the goals for this chapter, the "big deal" we want to make happen is that anyone , from any client type should be able to log in via the VPN. The simplest way to that goal is to create a trust relationship between the Active Directory domain ( ad ) and the Samba domain ( corp ).

As everyone knows , it takes two to trust: one to trust and one to lie. No, no that's not it. It takes one to trust and one to be trusted. The Samba domain is one-half of that relationship. It's going to be trusted. That is, user accounts that live in the Samba ( corp ) domain will be able to access resources that live on servers in the Active Directory ( ad ) domain.

It turns out that there's an incompatibility between Samba and Windows that we need to fix for VPN access to work properly, and the fix involves upgrading Samba. Let's do the fix before setting up the trust.

Upgrading Samba, If Needed

Domain trusts are well supported in Samba. They are a fundamental part of NT 4-style Windows authentication, which Active Directory continues to support. By configuring a trust, users in the corp domain can log in at workstations in the ad domain or access resources on servers in the ad domain. All we need to do is create a cross-domain trust. Samba is a team player here.

The Point to Point Tunneling Protocol (PPTP) used in VPNs also uses Windows authentication, so allowing users to log in over the Windows-hosted PPTP VPN shouldn't be hard either right?

Well, almost. To utilize a Windows VPN server, users must have a special flag set before logging into the VPN. Under the hood, it's called "Grant dial-in permission to user."

Unfortunately, an incompatibility exists between the version of Samba (3.0.10-1-FC3) in Fedora Core 3 as of this writing and Microsoft's RAS (Remote Access Service). This incompatibility prevents RAS from "seeing" that a user in the Samba domain does have the dial-in permission flag set.

Are we stuck? Fortunately, no. This incompatibility was fixed in Samba 3.0.11. There's a good chance that by the time you read this, a fully updated installation of Fedora Core 3 already includes Samba 3.0.11 or better. So we'll first show how to verify that. And if you do have the older version of Samba, we'll also show how to upgrade relatively painlessly using Fedora Core 3-specific RPMs made available by the official Samba development team.

Verifying Your Samba Version

If your Samba is version 3.0.11 or better, you don't need to upgrade. How can you verify this? Like most well-written Unix tools, Samba's smbd daemon accepts a --version option on the command line. We'll use this option to find out what version we've got.

Use the following command on linserv1.corp.com to check your Samba version:

 /usr/sbin/smbd --version

If you receive the following output:

 Version 3.0.10-1.fc3

Or any output indicating a version older than 3.0.11, you'll need to upgrade. If not, you can skip the next section and move on to "Samba Side Trust Creation."

Upgrading Samba with Official Samba rpms

In the previous section we verified that Samba is older than version 3.0.11, and when we want RAS to be able to check the dial-up flag, that won't cut it. So how do we upgrade as painlessly as possible?

Very easily, as it turns out! The Samba project, as we've mentioned, offers rpms to upgrade Samba on Fedora Core 3 systems. These rpms are correctly preconfigured to find the right database and configuration files in the right places for Fedora Core 3. We strongly recommend them over attempting to build from source code.

We'll obtain the rpms by browsing through the binary download directories of the Samba website. Installing them is as simple as installing any other rpm. However, we will need to use the --force option of the rpm command to replace the official Fedora Samba rpms, which would otherwise produce an error message.

To download the rpms, follow these steps:

Access the page www.samba.org/ .
Click "Binaries" in the navigation area at the left. A directory listing appears.
Click the "Fedora" folder. A new directory listing appears, offering "RPMS" and "SRPMS."
Click "RPMS" to obtain precompiled binaries. A directory listing of supported binary platforms appears.
Click "i386." A list of Fedora distribution types appears, with the sole option currently being "core."
Click "core." A list of Fedora Core versions for which rpms are currently available appears. Click "3." A list of current Samba binary rpms for Fedora Core 3 appears.
We need all of the rpms except for the SWAT interface, which we don't use in this book. Download each of the following files and move them to /tmp on linserv1.corp.com (version numbers will vary; use the currently available versions):
```
 samba-3.0.14a-1.i386.rpm samba-client-3.0.14a-1.i386.rpm samba-common-3.0.14a-1.i386.rpm 
```
Shut down the running Samba server with this command:
```
 service smb stop 
```
Install the rpms with the following command:
```
 rpm -i --force samba*.rpm 
```
Verify that version 3.0.14a (or better) is now installed with this command:
```
 /usr/sbin/smbd --version 
```
This should produce
```
 Version 3.0.14a 
```
or a later version. If not, make sure the rpm command did not produce errors and that you remembered to specify the --force option.
Restart the Samba daemons, running the new versions:
```
 service smb start 
```

Now that Samba has been upgraded to a sufficiently modern version, we'll move on to the creation of a domain trust.

Samba-Side Trust Creation

We're ready to create a domain trust. Our domain trust will allow users of any workstation that supports logons in the ad domain to also accept logons in the corp domain.

Users of Windows clients , such as xppro1.ad.corp.com , will now see corp as a drop-down possibility when choosing a logon domain. Later, when we use Windows XP's VPN client, we can specify credentials, which live either in corp or ad . We'll arrange the same access for Linux VPN clients.

So, who should trust whom? The goal is for the ad domain to trust the corp domain. That way, services like the Windows VPN server that rely on Active Directory for authentication will automatically gain the ability to accept corp domain logons as well.

This is established between the two domains by something called a "trust account." Strangely enough, though, the domain to be trusted is the one that must get the ball rolling to create a domain trust.

That means our Samba PDC on linserv1.corp.com has to make the first move in this dance . How do we set up the Samba side of the domain trust? By creating a domain trust account using the smbldap-useradd tool we first encountered in Chapter 2. We'll use options similar to those used to create a machine trust account, but we'll also add the -i option, which sets the " inter-domain trust" flag for that particular account. This distinguishes it from a machine trust account.

Warning

The following steps require that you have previously configured an LDAP-based Samba PDC for the corp domain, running on linserv1.corp.com , as described in Chapter 2.

To create the domain trust account, follow these steps:

In a production environment, choose a secure password for the domain trust. You'll need this password again when you configure the Windows side of the trust. For test purposes only, we used p@ssw0rd .
Execute this command on linserv1.corp.com to create the account:
```
 /usr/local/sbin/smbldap-useradd -w -i ad 
```

You may see the following warnings, which may be safely ignored:

 Use of uninitialized value in string at /usr/lib/perl5/site_perl/smbldap_ tools.pm line 169. Use of uninitialized value in string at /usr/lib/perl5/site_perl/smbldap_ tools.pm line 169.

Enter and confirm the domain trust account password when prompted.

The Linux side of the domain trust is ready! Now we're ready to configure the Windows side and begin reaping the benefits.

Active Directory-Side Trust Creation

To create the actual trust, we need to fire up the Active Directory Domains and Trusts tool on windc1.ad.corp.com . To create the trust between ad and corp :

Select Start Administrative Tools Active Directory Domains and Trusts.
If you followed the instructions earlier in the chapter, you should have two domains listed, ad.corp.com and peerad.corp.com . We're interested in creating a trust between ad.corp.com and Samba's corp . Right-click over ad.corp.com and select "Properties."
In the " ad.corp.com Properties" page, click "Trusts." Then click "New Trust."
At the first page of the wizard, click "Next." In the "Trust Name" screen, in the " Name " field, enter corp and click "Next."
In the "Direction of Trust" page, select "One-way: outgoing" and select "Next."
In the "Outgoing Trust Authentication Level" page select "Domain-Wide authentication" and select "Next."
In the "Trust Password" page enter and re-enter the password we're using for the trust: p@ssw0rd and click "Next."
You'll find a "Trust Creation Complete" page. Your only option is to click "Next."
At the "Confirm Outgoing Trust" page, select "Yes, confirm the outgoing trust" and click "Next."
At the final page of the wizard, you should get a message that the trust relationship was successfully created. Click "Finish."

Tip	Upon closing the wizard, you may get a notice about SID filtering. For the examples in this book, this can be safely ignored. Just click "OK" if prompted.

Ensuring corp Users can Log on to a Windows XP Computer (Joined to the ad.corp.com Domain)

To verify the trust is active and in place, use xppro1.ad.corp.com (or any other computer joined to the ad.corp.com domain). Log off and then note if the corp domain is available from the "Log on to" drop-down as shown in Figure 9.11.

Figure 9.11: Once the trust to corp is established, it should be available within the "Log on to" drop-down

Go ahead and try to log on using the corp domain with the doctor1 account. Use the password of p@ssw0rd and see if you can successfully log in. If not, check the following:

Examine the event logs on windc1.ad.corp.com , the ad Domain Controller.
Use the tail command to check the file /var/log/samba/windc1.log on linserv1.corp.com , which contains information about cross-domain authentication attempts.