blog.scottlowe.org

Since I had CentOS 5 up and running on ESX Server in the test lab, I decided to try to validate my latest Linux-AD integration instructions on this installation.  Unfortunately, the instructions do not seem to work well at all with CentOS 5; here are some of the errors that I ran into:

• When using “net ads join” to join the Active Directory domain, it didn’t recognize any existing Kerberos tickets.  I’d already run a “kinit <AD username>”, but “net ads” continued to either a) try to use the root account if I didn’t specify the “-U <AD username>” parameter, and b) prompt for password even when I’d already obtained a Kerberos ticket for the specified username.
• When initially trying to join the Active Directory domain, “net ads join” threw this error:
  [2007/12/04 12:57:08, 0] libads/kerberos.c:create_local_private_krb5_conf_
for_domain(594) create_local_private_krb5_conf_for_domain:
failed to create directory /var/cache/samba/smb_krb5.
Error was Permission denied
  This error persisted until I manually created the /var/cache/samba/smb_krb5 directory myself.  Why this directory wasn’t created automatically during the Samba installation is beyond me.  Once I created that directory, the error went away, but Samba still wouldn’t create the keytab or add entries to the keytab.
• The “net ads keytab” command failed miserably; it would not create a keytab, nor would it add entries to a keytab.  No error message is reported; it just doesn’t work.

I inquired on the #samba IRC channel on irc.freenode.net, but the only person willing or able to respond didn’t have any information to provide (in fact, he’d actually used my Solaris-AD integration instructions as a guide for some of his own work).  Various Google searches also failed to provide any helpful information.

By the way, these tests were performed on a stock installation of CentOS 5, with all the latest packages installed using “yum update”.  The Samba version was 3.0.25b-1.el5_1.2.

In the end, I’ve given up on trying to make Samba work in the AD integration process and will instead fallback to the use of ktpass.exe to create the keytab file.  If you have any useful information to share, please let me know or post it in the comments.  Thanks!

As I had to rebuild some Linux VMs in the lab anyway (they’d gotten messed up with various interoperability tests), I decided to try version 5.0 of CentOS.  I was trying to get this done on Friday before the long holiday weekend, but it turns out that downloading the ISO images for six (yes, six!) CD-ROMs takes a bit longer than I had hoped.  So I downloaded them at home on my 6Mbit DSL connection over the weekend, and had the opportunity to work on it yesterday while at the office.

I didn’t really expect any major issues that would prevent the new version of the distribution from running, but you never really know for sure until you try.  Fortunately, CentOS 5.0 loaded quickly and without any real problems on the lab servers running ESX Server version 3.0.2.  The only issue that came up—and it was a minor one, really, more caused by my own lack of preparation than anything else—was that the VMware Tools did not have a suitable kernel module or a suitable VMXNet driver.  This was only a problem at first because I didn’t have the right parts (compiler, kernel header files, etc.) installed to allow the VMware Tools installer to create its own module and driver.  I had to use yum to install the necessary pieces, then the VMware Tools installer worked without any further problems.

Later in the week I hope to be able to post some information on running Solaris 10 8/07 (aka Update 4) on ESX Server as well.

In the event that your organization is considering a migration later this year (or next?) to Windows Server 2008 (formerly “Longhorn”), here are some instructions for integrating Linux login requests against Active Directory on Windows Server 2008.  These instructions are based on Linux-AD Integration, Version 4 and utilize Kerberos, LDAP, and Samba.

When this process is complete, AD users can be enabled for use on Linux systems on the network and login to those Linux systems using the same username and password as throughout the rest of Active Directory.

If you are looking for information on using Linux with a previous version of Windows before Windows Server 2008, please refer back to my AD integration index and select the appropriate article.  The only significant changes in the process involve the mapping of the LDAP attributes; otherwise, the procedure is very similar between the two versions of Windows.

Preparing Active Directory (One-Time)

The process of installing and configuring Windows Server 2008 is beyond the scope of this article (although I may touch on that in the near future in a separate article).  Therefore, I won’t provide detailed instructions on how to perform some of these tasks, but instead provide a high-level overview.

Enable Editing/Display of UNIX Attributes

In order to store UNIX attributes in Active Directory, the schema must be extended.  To extend the schema, first install Active Directory (add the Active Directory Domain Services role to an installed server, then use the Active Directory Installation Wizard to setup Active Directory) and then add the “Identity Management for UNIX” role service (this can be done in Server Manager).

Once that role service has been installed, then the AD schema now includes a partially RFC 2307-compliant set of UNIX attributes, such as UID, UID number, GID number, login shell, etc.  (Note that it may be that these attributes are already included in the schema for Windows Server 2008; I did not check the schema before installing the Identity Management for UNIX role service.  With Windows Server 2003 R2, the schema was present at the time of installation, but the attributes were not visible until installing the UNIX identity services.)

At this point a new tab, labeled “UNIX Attributes,” will appear in the properties dialog box for users and groups in Active Directory.  You’ll use this tab to edit the UNIX-specific attributes that are required for logins to Linux-based systems.

Create an LDAP Bind Account

You’ll also need to create an account in Active Directory that will be used to bind to Active Directory for LDAP queries.  This account does not need any special privileges; in fact, making the account a member of Domain Guests and not a member of Domain Users is perfectly fine.  This helps minimize any potential security risks as a result of this account.  Just be sure that you know the account’s user principal name (UPN) and password.

Prepare Active Directory (Each User)

Each Active Directory account that will authenticate via Linux must be configured with a UID and other UNIX attributes.  This is accomplished via the new “UNIX Attributes” tab on the properties dialog box of a user account.

After all the user accounts have been configured, then we are ready to configure Active Directory objects for each of the Linux server(s) that we’ll be integrating with AD.

Prepare Active Directory (Each Server)

Prior to using Samba to join Linux computers to Active Directory and generate a keytab automatically, we had to use the ktpass.exe utility on Windows to generate a keytab.  Due to some current Samba-Windows Server 2008 interoperability issues, we can’t use Samba.  That means we’ll be back to using ktpass.exe to map service principals onto accounts in Active Directory.  Unfortunately, you’ll need to first disable User Account Control (UAC) on your server, since UAC interferes with ktpass.exe.  (Nice, huh?)

Once you’ve disabled UAC (and rebooted your server), then you can map the service principal names (SPNs) using the following steps:

1. Create a computer account (or a user account; either will work) with the name of the Linux server.
2. Use the following command to map the needed SPN onto this account (backslashes indicate line continuation):
   ktpass.exe -princ HOST/server.fqdn@REALM.COM \
-mapuser DOMAIN\AccountName$ -crypto all \
-pass Password123 -ptype KRB5_NT_PRINCIPAL \
-out filename.keytab
3. Copy this file to the Linux server (using SCP or SFTP is a good option) and merge it with the existing keytab (if it exists) using ktutil.  If there is no existing keytab, simply copy the file to /etc/krb5.keytab and you should be good to go.

Now that Active Directory has computer objects (and, more importantly, SPNs) for the Linux servers and the AD users have been enabled for UNIX (by populating the UNIX attributes), we’re ready to start configuring the Linux server(s) directly.

Prepare Each Linux Server

Follow the steps below to configure the Linux server for authentication against Active Directory.  (Note that this configuration was tested on a system running CentOS—a variation of Red Hat Enterprise Linux—version 4.3.)

1. Edit the /etc/hosts file and ensure that the server’s fully-qualified domain name is listed first after its IP address.
2. Make sure that the appropriate Kerberos libraries, OpenLDAP, pam_krb5, and nss_ldap are installed.  If they are not installed, install them.
3. Be sure that time is being properly synchronized between Active Directory and the Linux server in question.  Kerberos requires time synchronization.  Configure the NTP daemon if necessary.
4. Edit the /etc/krb5.conf file to look something like this, substituting your actual host names and domain names where appropriate:
   [logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
 
[libdefaults]
default_realm = EXAMPLE.COM
dns_lookup_realm = true
dns_lookup_kdc = true
 
[realms]
EXAMPLE.COM = {
kdc = host.example.com:88
admin_server = host.example.com:749
default_domain = example.com
}
 
[domain_realm]
.example.com = EXAMPLE.COM
example.com = EXAMPLE.COM
 
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
 
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
5. Edit the /etc/ldap.conf file to look something like this, substituting the appropriate host names, domain names, account names, and distinguished names (DNs) where appropriate.  (Please note that the nss_base_group line should not be broken across two lines when you edit it; it has been wrapped here for readability.)
   host 10.10.10.10
base dc=example,dc=com
uri ldap://server.example.com/
binddn ldap@example.com
bindpw adldapbindpw
scope sub
ssl no
nss_base_passwd dc=example,dc=com?sub
nss_base_shadow dc=example,dc=com?sub
nss_base_group dc=mydomain,dc=com?sub?
&(objectCategory=group)(gidnumber=*)
nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_objectclass posixGroup group
nss_map_attribute gecos cn
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute uniqueMember member
6. Configure PAM (this varies according to Linux distributions) to use pam_krb5 for authentication.  Many modern distributions use a stacking mechanism whereby one file can be modified and those changes will applied to all the various PAM-aware services.  For example, in Red Hat-based distributions, the system-auth file is referenced by most other PAM-aware services.  Here’s a properly edited /etc/pam.d/system-auth file taken from CentOS 4.4 (some lines have been wrapped for readability; do not wrap them when editing the file):
   #%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time
# authconfig is run.
auth required /lib/security/pam_env.so
auth sufficient /lib/security/pam_unix.so
   likeauth nullok
auth sufficient /lib/security/pam_krb5.so
auth required /lib/security/pam_deny.so
 
account sufficient /lib/security/pam_unix.so
account sufficient /lib/security/pam_krb5.so
account sufficient /lib/security/pam_succeed_if.so
   uid < 100 quiet
account required /lib/security/pam_deny.so
 
password requisite /lib/security/pam_cracklib.so
   retry=3
password sufficient /lib/security/pam_unix.so
   nullok use_authtok md5 shadow
password required /lib/security/pam_deny.so
 
session required /lib/security/pam_limits.so
session required /lib/security/pam_unix.so
7. Edit the /etc/nsswitch.conf file to include “ldap” as a lookup source for passwd, shadow, and groups.

At this point we are now ready to test our configuration and, if successful, to perform the final step:  to join the Linux server to Active Directory for authentication.

Test the Configuration

To test the Kerberos authentication, use the “kinit” command, as in “kinit <AD username>@<AD domain DNS name>”; this should return no errors.  A “klist” at that point should then show that you have retrieved a TGT (ticket granting ticket) from the AD domain controller.  If this fails, go back and troubleshoot the Kerberos configuration.  In particular, if you are seeing references to failed TGT validation, check to make sure that both your Linux servers and AD domain controllers have reverse lookup (PTR) records in DNS and that the Linux server’s /etc/hosts file listed the FQDN of the server first instead of just the nodename.

<aside>Some readers and some other articles have suggested the use of the AD domain DNS name in the /etc/krb5.conf file instead of an AD domain controller specifically; I recommend against this.  First, I believe it may contribute to TGT validation errors; second, it is possible to list multiple KDCs (AD DCs) in the configuration.  Since the only major reason to use the AD domain DNS name instead of the DNS name of one or more DCs would be fault tolerance, then it doesn’t really gain anything.</aside>

To test the LDAP lookups, use the “getent” command, as in “getent passwd <AD username>”; this should return a listing of the account information from Active Directory.  If this does not work, users will not be able to login, even if Kerberos is working fine.  If you run into errors or failures here, go back and double-check the LDAP configuration.  One common source of errors is the name of the LDAP bind account, so be sure that is correct.

At this point, SSH logins to the Linux system using an account present in Active Directory (one which has had its UNIX attributes specified properly) should be successful.  This will be true as long as you used the ktpass.exe command earlier to map the SPN onto the computer object in Active Directory.  Even if you didn’t copy the keytab over to the Linux server, logins will work.  Why?  Because the PAM Kerberos configuration, by default, does not require a client keytab, and does not attempt to validate the tickets granted by the TGT.  This means that as long as the SPN(s) are mapped to the accounts in AD, the keytab is not necessarily required.

(Note, however, that not using a keytab and/or not requiring a keytab does leave the Linux server open to potentially spoofed Kerberos tickets from a fake KDC.  In addition, “native” Kerberos authentication—i.e., using a Kerberos ticket to authenticate instead of typing in a password—won’t work without a keytab.)

Deal with Home Directories

Unlike Windows systems, home directories are required on Linux-based systems.  As a result, we must provide home directories for each AD user that will log in to a Linux-based system.  We basically have three options here:

• Manually create home directories and set ownership/permissions properly before users will be able to log in.
• Use the pam_mkhomedir.so PAM module to automatically create local home directories “on the fly” as users log in.  To do this, you would add an entry for pam_mkhomedir.so in the session portion of the PAM configuration file.
• Use the automounter to automatically mount home directories from a network server.  This process is fairly complicated (too involved to include the information here), so I’ll refer you to this article on using NFS and automounts for home directories.  This has the added benefit of providing a foundation for unified home directories across both Windows and Linux systems.

Once you’ve settled on and implemented a system for dealing with home directories, you are finished!  UNIX-enabled users in Active Directory can now login to Linux-based systems with their Active Directory username and password.

What’s not addressed in this article?  Password management.  In this configuration, users will most likely not be able to change their password from the Linux servers and have that change properly reflected in Active Directory.  In addition, “native” Kerberos authentication using Kerberos tickets won’t work unless the keytab is present.  In my testing, I ran into a number of issues with the keytab and TGT validation, but I’m not sure if those are errors in my process or the result of the beta status of Windows Server 2008.

I welcome your corrections, additions, or suggestions in the comments below.

This procedure allows Linux-based systems to authenticate against Active Directory.  We use Kerberos for authentication, LDAP for account information, and Samba to help automate the process along the way.  When this process is complete, AD users can be enabled for use on Linux systems on the network and login to those Linux systems using the same username and password as throughout the rest of Active Directory.

These instructions are designed for use with Windows Server 2003 R2.  If you are looking for information on using Linux with a previous version of Windows, please refer back to this article.  The only significant changes in the process involve the mapping of the LDAP attributes; otherwise, the procedure is very similar between the two versions of Windows.

Preparing Active Directory (One-Time)

Enable Editing/Display of UNIX Attributes

Based on my research, it appears that the partially RFC 2307-compliant schema is installed with Windows Server 2003 R2; this means that the schema does not need to be extended to include UNIX-specific attributes such as uid, gid, login shell, etc.  However, while the attributes are there in the schema, there is no way to edit those attributes, and these attributes must be populated correctly in order for this process to work.

The easiest way to enable the editing of these attributes is to install the “Server for NIS” component on at least one domain controller.  This will cause a new tab, labeled “UNIX Attributes,” to appear in the properties dialog box for users and groups.  You’ll use this tab to edit the UNIX-specific attributes that are required for logins to Linux-based systems.  Please note that due to the way this tab is displayed, you’ll need Schema Admin privileges in order to install the “Server for NIS” component on your domain controller.  (More information on this issue is available here.)

You could just as well use LDP, LDIF files, ADSI Edit, or any number of other methods to display and edit these attributes.  To make this process as seamless as possible, however, you’ll want to integrate the management of these attributes into Active Directory Users and Computers using the method described above.

Create an LDAP Bind Account

You’ll also need to create an account in Active Directory that will be used to bind to Active Directory for LDAP queries.  This account does not need any special privileges; in fact, making the account a member of Domain Guests and not a member of Domain Users is perfectly fine.  This helps minimize any potential security risks as a result of this account.

Prepare Active Directory (Each User)

Each Active Directory account that will authenticate via Linux must be configured with a UID and other UNIX attributes.  This is accomplished via the new “UNIX Attributes” tab on the properties dialog box of a user account.  (Installing the “Server for NIS” component enables this, as mentioned previously.)

After all the user accounts have been configured, then we are ready to configure the Linux server(s) for authentication against Active Directory.

Prepare Each Linux Server

Follow the steps below to configure the Linux server for authentication against Active Directory.

1. Edit the /etc/hosts file and ensure that the server’s fully-qualified domain name is listed first after its IP address.
2. Make sure that the appropriate Kerberos libraries, OpenLDAP, pam_krb5, and nss_ldap are installed.  If they are not installed, install them.
3. Be sure that time is being properly synchronized between Active Directory and the Linux server in question.  Kerberos requires time synchronization.  Configure the NTP daemon if necessary.
4. Edit the /etc/krb5.conf file to look something like this, substituting your actual host names and domain names where appropriate:

   [logging]
    default = FILE:/var/log/krb5libs.log
    kdc = FILE:/var/log/krb5kdc.log
    admin_server = FILE:/var/log/kadmind.log
   
   [libdefaults]
    default_realm = EXAMPLE.COM
    dns_lookup_realm = true
    dns_lookup_kdc = true
   
   [realms]
    EXAMPLE.COM = {
     kdc = host.example.com:88
     admin_server = host.example.com:749
     default_domain = example.com
    }
   
   [domain_realm]
    .example.com = EXAMPLE.COM
    example.com = EXAMPLE.COM
   
   [kdc]
    profile = /var/kerberos/krb5kdc/kdc.conf
   
   [appdefaults]
    pam = {
      debug = false
      ticket_lifetime = 36000
      renew_lifetime = 36000
      forwardable = true
      krb4_convert = false
    }

5. Edit the /etc/ldap.conf file to look something like this, substituting the appropriate host names, domain names, account names, and distinguished names (DNs) where appropriate.  (Please note that the nss_base_group line should not be broken across two lines when you edit it; it has been wrapped here for readability.)  (Note:  These schema mappings assume that you are using the newer schema extensions provided by Windows Server 2003 R2.  If you are using SFU 3.5 instead, you will need to use the schema mappings described here.)

   host 10.10.10.10
   base dc=example,dc=com
   uri ldap://server.example.com/
   binddn ldap@example.com
   bindpw adldapbindpw
   scope sub
   ssl no
   nss_base_passwd dc=example,dc=com?sub
   nss_base_shadow dc=example,dc=com?sub
   nss_base_group dc=mydomain,dc=com?sub?
       &(objectCategory=group)(gidnumber=*)
   nss_map_objectclass posixAccount user
   nss_map_objectclass shadowAccount user
   nss_map_objectclass posixGroup group
   nss_map_attribute gecos cn
   nss_map_attribute homeDirectory unixHomeDirectory
   nss_map_attribute uniqueMember member

6. Configure PAM (this varies according to Linux distributions) to use pam_krb5 for authentication.  Many modern distributions use a stacking mechanism whereby one file can be modified and those changes will applied to all the various PAM-aware services.  For example, in Red Hat-based distributions, the system-auth file is referenced by most other PAM-aware services.  Here’s a properly edited /etc/pam.d/system-auth file taken from CentOS 4.4 (some lines have been wrapped for readability; do not wrap them when editing the file):

   #%PAM-1.0
   # This file is auto-generated.
   # User changes will be destroyed the next time authconfig is run.
   auth     required   /lib/security/$ISA/pam_env.so
   auth     sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
   auth     sufficient /lib/security/$ISA/pam_krb5.so
   auth     required   /lib/security/$ISA/pam_deny.so
   
   account  sufficient /lib/security/$ISA/pam_unix.so
   account  sufficient /lib/security/$ISA/pam_krb5.so
   account  sufficient /lib/security/$ISA/pam_succeed_if.so
       uid < 100 quiet
   account  required   /lib/security/$ISA/pam_deny.so
   
   password requisite  /lib/security/$ISA/pam_cracklib.so retry=3
   password sufficient /lib/security/$ISA/pam_unix.so nullok
       use_authtok md5 shadow
   password  required  /lib/security/$ISA/pam_deny.so
   
   session  required   /lib/security/$ISA/pam_limits.so
   session  required   /lib/security/$ISA/pam_unix.so

7. Edit the /etc/nsswitch.conf file to include “ldap” as a lookup source for passwd, shadow, and groups.

At this point we are now ready to test our configuration and, if successful, to perform the final step:  to join the Linux server to Active Directory for authentication.

Test the Configuration

To test the Kerberos authentication, use the “kinit” command, as in “kinit <AD username>@<AD domain DNS name>”; this should return no errors.  A “klist” at that point should then show that you have retrieved a TGT (ticket granting ticket) from the AD domain controller.  If this fails, go back and troubleshoot the Kerberos configuration.  In particular, if you are seeing references to failed TGT validation, check to make sure that both your Linux servers and AD domain controllers have reverse lookup (PTR) records in DNS and that the Linux server’s /etc/hosts file listed the FQDN of the server first instead of just the nodename.

<aside>Some readers and some other articles have suggested the use of the AD domain DNS name in the /etc/krb5.conf file instead of an AD domain controller specifically; I recommend against this.  First, I believe it may contribute to TGT validation errors; second, it is possible to list multiple KDCs (AD DCs) in the configuration.  Since the only major reason to use the AD domain DNS name instead of the DNS name of one or more DCs would be fault tolerance, then it doesn’t really gain anything.</aside>

To test the LDAP lookups, use the “getent” command, as in “getent passwd <AD username>”; this should return a listing of the account information from Active Directory.  If this does not work, users will not be able to login, even if Kerberos is working fine.  If you run into errors or failures here, go back and double-check the LDAP configuration.  One common source of errors is the name of the LDAP bind account, so be sure that is correct.

Join the Linux Server to Active Directory

This is the final step.  Don’t try this step until you’ve successfully tested the configuration.  After this step is completed, you are finished and AD users will be able to login to Linux-based systems (assuming the AD users have been properly configured for Linux logins).

To join the Linux server to Active Directory, follow these steps:

1. Verify the Samba configuration.  Be sure the following settings are specified in /etc/samba/smb.conf:

   workgroup = <NetBIOS name of AD domain>
   security = ads
   realm = <DNS name of AD domain>
   use kerberos keytab = true
   password server = <Space-delimited list of AD DCs>

2. Use “kdestroy” to destroy any existing Kerberos credentials you may have; then run “kinit <Domain administrative account>@AD.DOMAIN.NAME” to get a Kerberos ticket for an account that is a domain administrator account.
3. Run “net ads join” to join the Linux server to Active Directory.  This command will automatically create a computer object in Active Directory and add the appropriate SPNs (service principal names) to the computer object.  In addition, it will populate the local Kerberos key table (/etc/krb5.keytab, by default) with the correct entries for authentication against Active Directory.

Only one small detail remains:  how to deal with home directories for users logging into Linux systems.

Deal with Home Directories

Unlike Windows systems, home directories are required on Linux-based systems.  As a result, we must provide home directories for each AD user that will log in to a Linux-based system.  We basically have two options here:

• Use the pam_mkhomedir.so PAM module to automatically create local home directories “on the fly” as users log in.  To do this, you would add an entry for pam_mkhomedir.so in the session portion of the PAM configuration file.
• Use the automounter to automatically mount home directories from a network server.  This process is fairly complicated (too involved to include the information here), so I’ll refer you to this article on using NFS and automounts for home directories.  This has the added benefit of providing a foundation for unified home directories across both Windows and Linux systems.

(There is a third option as well:  manually create home directories before users can log in.)

Once you’ve settled on and implemented a system for dealing with home directories, you are finished!  UNIX-enabled users in Active Directory can now login to Linux-based systems with their Active Directory username and password.

What’s not addressed in this article?  Password management.  In this configuration, users will most likely not be able to change their password from the Linux servers and have that change properly reflected in Active Directory.  I’ll try to work on that for version 5 of the instructions.

I hope you find this information helpful.  As always, feel free to post corrections, additions, or suggestions in the comments below.

To help make it easier to find the various Active Directory integration articles I’ve written, I’m including links below to the latest version of each article.  As new versions of an article are published, I can simply update this link to point to the new version.

I’ve grouped the integration articles according to product below.

Linux

Latest version for Windows Server 2008 (“Longhorn”)

Latest version for Windows Server 2003 R2

Latest version for Windows 2000 Server and Windows Server 2003 (pre-R2)

SuSE Linux Enterprise Desktop (SLED)-specific version

Solaris 10

Latest version for Solaris 10 x86

Firewalls

Latest version for Cisco PIX VPN

Latest version for WatchGuard Firebox VPN

VMware ESX Server

Latest version for ESX Server 2.5.x

Latest version for ESX Server 3.0.x

OpenBSD

Latest version for OpenBSD 3.9

Networking Equipment and Protocols

Latest version for 802.1x

Latest version for Cisco IOS

As new articles are published or existing articles are revised with new versions, I’ll update this post accordingly.

Suggestions to use Samba in Linux-AD integration scenarios appeared in the comments for the following articles:

Linux, Active Directory, and Windows Server 2003 R2 Revisited
Kerberos-Based SSO with Apache

The idea was that Samba could be used to help automate the process of creating the appropriate service principals in Active Directory.  Previously, I had recommended the use of ktpass.exe and separate user accounts for each service principal (i.e., HOST/ or host/, HTTP/, etc.) because of the limitations of ktpass.exe and adding service principals in Active Directory.  However, a number of readers pointed out that Samba’s “net ads join” and “net ads keytab” commands could help automate and streamline this process.

Since one of my Linux servers had crashed anyway, I decided to try out the Samba toolset while integrating this new Linux server into my existing Active Directory infrastructure.  Here’s what I found and the process that I used to successfully integrate the new Linux server into AD with the Samba tools.

1. First, the Kerberos client had to be configured properly.  I’ll refer you back to any one of the various Linux-AD integration articles I’ve written for more information on how to setup the /etc/krb5.conf file.  You should be able to do a successful “kinit username@AD.DOMAIN.NAME” when /etc/krb5.conf is configured correctly.
2. Next, Samba must be properly configured.  I used the following settings in /etc/samba/smb.conf:

   workgroup = <NetBIOS name of AD domain>
   security = ads
   realm = <DNS name of AD domain>
   use kerberos keytab = true
   password server = <Space-delimited list of AD DCs>

3. For full Linux-AD integration, you must configure the nss_ldap client.  Again, I’ll refer you to any one of the various AD integration articles I’ve written for more details on a suggested nss_ldap configuration.  When nss_ldap is correctly configured, you should be able to do a “getent password <username>” and get back a list of properties (including UID, home directory, login shell, etc.) for that username.
4. Use “kdestroy” to kill any Kerberos credentials you may have established during testing, and then run “kinit <administrative account>@AD.DOMAIN.NAME” to get a Kerberos ticket for an administrative user in the AD domain.
5. If the DNS domain of your Linux server will be different than the DNS domain of the AD domain (for example, perhaps your Linux server will be web1.linux.corp.com whereas Active Directory uses ad.corp.com), then create a computer account in Active Directory.  If the Linux server’s DNS domain will be the same as the DNS domain for AD, then we can have Samba create it for us.  (I ran into problems here since the Linux server does use a different DNS domain than Active Directory, and pre-creating the computer account was the only way to make it work.)
6. Run “net ads join” to join the Linux server to Active Directory.  As part of this process, it will add various SPNs to the computer account in Active Directory automatically and create the appropriate entries in the local Kerberos keytab (/etc/krb5.keytab, by default).  No more ktpass.exe!

At this point, you can configure PAM appropriately (again, refer to one of the previous integration articles for full details on PAM configuration) and login to the Linux server with an Active Directory account.

I used this process to integrate a new CentOS 4.4 server into Active Directory without any problems whatsoever.  I used the Kerberos, LDAP, nsswitch.conf, and PAM configurations from this Linux-AD integration article within the framework of the steps listed above and ran into only one problem (that was the issue with the differing DNS domains).  Otherwise, it worked just fine.

Thanks to those readers who suggested the use of Samba!

Given that I’m neither a Solaris expert (yet) nor an iSCSI expert (yet), I knew that it would be a bit of a challenge to make this work.  Fortunately, a found a very useful blog posting by Frank Berger that gave me the framework I needed to get started.  From there, Sun’s documentation provided the rest of the necessary details.  Perhaps this documentation will prove moderately useful as well.

First, I added the following lines to the /etc/ietd.conf on the CentOS iSCSI target server:

Target iqn.2006-08.net.example:server.lun1
        IncomingUser username complicatedpassword
        Lun 1 Path=/dev/vg00/isanvol1,Type=fileio
        Alias iet-lun1
        MaxConnections          8
        InitialR2T              No
        ImmediateData           Yes

A quick restart of the iSCSI target service and I was all set on the target side.  If you were going to do this yourself in your own environment, you’d need to modify the “IncomingUser” and “Lun X Path”.  In this instance I’m using LVM on CentOS, so my path specifies a logical volume in a volume group.  Your configuration will differ, obviously.  Alternately, if you are using a different iSCSI target implementation, you’d need to configure it appropriately.  (I hope to be able to do some testing against a NetApp iSCSI target in the near future.)

On the initiator side, everything is done with the “iscsiadm” command.  This command is fairly self-explanatory and has built-in help (-?) throughout most of the options, but it did take me a little bit of time to get things working.

First, we have to make sure that the iSCSI initiator is online:

svcs -a | grep iscsi

If disabled, then we can enable it with this command:

svcadm enable svc:/network/iscsi_initiator

From there, we configure the iSCSI initiator:

iscsiadm add discovery-address 10.1.1.1:3260
iscsiadm modify initiator-node -a CHAP
iscsiadm modify initiator-node -H username
iscsiadm modify initiator-node -C
(specify CHAP password)
iscsiadm modify discovery --sendtargets enable

Because I’d also specified a static config as well (dynamic discovery didn’t seem to be working as I expected; more on that in a moment), using “iscsiadm list target” now returned two iSCSI targets.  They appeared to be different targets, and since I do have two targets defined on the iSCSI server (one for VMware and one for this), I didn’t want to take any chances on affecting the VMware LUN.  So, I removed and disabled the dynamic discovery, removed the static config, and then re-added the static config:

iscsiadm add static-config iqn.2006-08.net.example:server.lun1,
10.1.1.1:3260

(This should all be on one line; it was wrapped here for readability.)  After doing that, “iscsiadm list target” showed only a single target identified as “server.lun1”, which assured me that I wasn’t seeing the VMware LUN.

<aside>In a more complex environment, how does one ensure that iSCSI LUNs are properly isolated from unwanted hosts?  The “IncomingUser” parameter was different between my VMware LUN and the raw LUN being presented to Solaris, so in theory I would have been safe.  Better safe than sorry, in my opinion.</aside>

After I was sure that the iSCSI initiator was properly seeing the LUN, then I created a new device, created a new filesystem on that device, and then mounted it:

devfsadm -c iscsi
format (selected new disk identified as iSCSI)
newfs /dev/dsk/c2t1d0s2
mount /dev/dsk/c2t1d0s2 /export/iscsi

Of course, you’ll need to modify the above commands slightly depending upon your configuration, but the overall process should be pretty close to what I’ve outlined above.

This solution builds upon the integration of Solaris 10 and Linux (again, CentOS specifically, but I’ll use Linux here instead of mentioning the specific distribution) into Active Directory for authentication and authorization as outlined in these related articles:

Refined Solaris 10-AD Integration Instructions
Linux, Active Directory, and Windows Server 2003 R2 Revisited

In these articles, we describe a configuration whereby we can use Kerberos against Active Directory for authentication, and LDAP against Active Directory for user and group lookups.  This allows us to centralize the user account information (username, UID number, home directory, login shell, etc.) into Active Directory so that when an account is provisioned in AD it is also available to associated UNIX and Linux systems (as applicable).  Using the information in this article, we can extend that integration to auto-mounted shared home directories between Solaris and Linux.

We’ll accomplish this by using the UNIX interoperability tools included in Windows Server 2003 R2; namely, the Server for NFS, Server for NIS, and the User Name Mapping Server.  On the Solaris and Linux side, we’ll use autofs.

OK, let’s dive right in.

Configuring Solaris

Configuring Solaris is pretty straightforward; it’s pretty much designed out of the box to use auto-mounted home directories.  This is one area where Solaris shows its enterprise pedigree (that’s not a knock against Linux, just an observation about Solaris).

The only real change that needs to be made is to the /etc/auto_home file, which specifies the auto-mounted home directory mappings.  The easiest thing to do is use a wildcard mapping, like this:

*   nfssrvr.example.com:/home/&

Here, the asterisk (*) and the ampersand (&) will be replaced with the appropriate information.  So, if a user name “bjones” logs on, then the the /home/bjones NFS share on the server nfssrvr.example.com would be mounted on /home/bjones on the Solaris server.  Useful, eh?

Note that autofs may be disabled in your installation of Solaris; it wasn’t in mine, but I’ve seen references elsewhere that this is not typical.  Use these commands to check the status and enable autofs, if necessary:

svcs -a | grep autofs
svcadm -v enable svc:/system/filesystem/autofs

At this point, Solaris should be ready to go.  Let’s look at the Linux configuration.

Configuring Linux

The Linux configuration is only slightly more complicated than the Solaris configuration.  Whereas Solaris uses /etc/auto_master to define the automounted filesystems, autofs on Linux uses /etc/auto.master, and it does not (by default, as far as I can tell) define a map for automounted home directories.

So we must first edit /etc/auto.master and add the following line:

/home   /etc/auto.home

This tells autofs to look in the file /etc/auto.home to find the automounted directories under /home.  Then we create the /etc/auto.home file with the following line:

*   nfssrvr.example.com:/home/&

(Just like the Solaris box in this case.)  Finally, we can check for the autofs startup status, fix it, and start autofs with the following commands, respectively:

chkconfig --list autofs
chkconfig autofs on
service autofs start

In fact, you will need to restart the autofs daemon (with “service autofs restart”) in order for the changes to /etc/auto.master and /etc/auto.home to be recognized.  (The same goes for Solaris, too, only using the “svcadm -v restart svc:/system/filesystem/autofs” command instead.)

To further streamline any differences between Solaris and Linux, I also created a /export/home on the Linux server, in the event I wanted/needed local home directories as well.  Please note that I would need to modify the /etc/auto.home (on Linux) or /etc/auto_home (on Solaris) as well if this were the case.

Now that Linux and Solaris are both done, let’s have a look at configuring the UNIX interoperability components on Windows.

Configuring Windows (NFS, NIS, and User Name Mapping)

Surprisingly enough, this part was the hardest part for me.  I don’t know if it was the documentation (if it can be called that) or something else, but I had a hard time with this.  Hopefully the information I share here can help someone else avoid this headache.

Configuring the Domain Controllers

On the domain controllers in your Active Directory domain, install the following components:

• Server for NIS and Administration Components (under Active Directory Services > Identity Management for UNIX)
• Microsoft Services for NFS Administration, RPC External Data Representation, RPC Port Mapper, Server for NFS Authentication, and User Name Mapping (under Other Network File and Print Services > Microsoft Services for NFS)

It may be possible to get by with less than that installed, but I couldn’t get it working until all of those are installed.  If you’ve followed my instructions for AD integration, the Server for NIS and Administration Components are probably already installed, as those expose the “UNIX Attributes” tab in Active Directory Users & Computers.

Once these are installed, use these steps to configure them appropriately:

1. Using the Services MMC, make sure that Server for NIS is running.
2. In the Microsoft Services for NFS MMC, right-click on “Microsoft Services for NFS” and select Properties.  Specify the name of the DC as the “User Name Mapping Server”, check the box labeled “Active Directory Lookup”, and specify the name of the Active Directory domain.  Click OK to save those changes and close the dialog box.
3. Still in Microsoft Services for NFS MMC console, right-click User Name Mapping and select Properties.  Go to the “Simple Mapping” tab, check the box marked “Use simple maps”, and then add one of the DCs from the domain that’s running Server for NIS at the bottom of the dialog box.
4. Right-click on both User Maps and Group Maps and select “Show simple maps,” then click Refresh.  You should see a list of the users in Active Directory that have been UNIX-enabled, i.e., have UNIX attributes specified for their account.  At this point, you can close the Microsoft Services for NFS MMC.

The DC should now be ready to go.  It’s time to move to the file server.

Configuring the File Server

We need to install the Server for NFS component on the file server that will host our automounted home directories.  The Server for NFS is found under “Other Network File and Print Services” in Add Windows Components.

Once that has been installed, repeat step #2 above (configuring the User Name Mapping Server and Active Directory lookup) on the file server.

We’re now ready to create some NFS shares.  Right-click the folder you’d like to share via NFS (I created a folder named “home”—I know, not very creative) and shared that via NFS (there’s an NFS Sharing tab when you open the properties for the folder).  When specifying the share name, be wary of the case since UNIX/Linux are cAsE sEnSiTiVe.  (It’s probably best to stick to all lowercase.)  If you want to allow anonymous access and/or root access, configure it appropriately at this point.

Word of warning:  be sure to include UNIX-enabled groups and/or users in the NTFS access control list for the folder and containing files!  This one threw me for a loop.  At first, I didn’t have any UNIX-enabled groups in the ACL and I kept getting “insufficient permissions” errors when trying to mount the share via NFS.  It wasn’t until I ensured that at least one UNIX-enabled group had read permission to the folder that things started working as expected.

To test your NFS share, use this command from Solaris or Linux, respectively:

mount -F nfs nfssrvr.example.com:/home/nfs /mnt/nfs (for Solaris)
mount -t nfs nfssrvr.example.com:/home/nfs /mnt/nfs (for Linux)

If this mounts the NFS share without any problems, then you should be ready to roll.

(Note:  In case you hadn’t already picked this up, one advantage of using a Windows NFS server is that we can also share the same folder via CIFS/SMB and create unified home directories for Solaris, Linux, and Windows.)

Now, upon logging in to either Solaris or Linux (I tested this via SSH), you should get dropped into “/home/username” (assuming that’s where you configured the automounter to mount the NFS share) automatically.

How I Tested

I tested this procedure using Solaris 10 6/06 and CentOS 4.3.  These systems were configured for Active Directory integration and native Kerberos logons via SSH.  I used Windows Server 2003 R2 Standard Edition for the NFS server, and Windows Server 2003 R2 Standard Edition for the Active Directory domain controllers.  All of these systems were created as virtual machines hosted on a VMware Virtual Infrastructure 3 server farm with servers running ESX Server 3.0.1.

The main goal in undertaking this effort is to create a structure in which hosts running Linux (typically CentOS) and Solaris 10 share common home directories.  These common home directories will be NFS-hosted shares that are automounted when a user logs in.  By combining this with CIFS-hosted shares (for Windows-based clients), we can provide common home directories for users regardless of the OS to which they are logging in.

The plan was to use Windows Server 2003 R2 as the NFS server.  A server running CentOS 4.3 and a server running Solaris 10, both already configured for Active Directory integration, would be used as the clients.  In addition, I was going to test connectivity from a Mac OS X client as well.

Unfortunately, I just can’t seem to make it work.  I have the Server for NFS component installed on a newly-built file server, and I have all the Unix attributes all stored in Active Directory (UID, UID number, login shell, Unix home directory, etc.).  But I can’t seem to get my head wrapped around the need for “User Name Mapping,” which is designed to match Windows accounts with Unix accounts.  In this situation, the Windows accounts are the Unix accounts!  I installed and configured User Name Mapping on one of the DCs, and configured the NFS server to use that server, but things still don’t seem to work.

Any Unix/NFS gurus out there care to help me understand this?

To test what kind of logging occurs, I simply used my existing installation of Windows Server 2003 R2 and Active Directory, for which the logging options had not been modified from their “out of the box” settings.  From there, I cleared the security event logs and then attempted an SSH login to a CentOS 4.3 server that has been configured for AD authentication via Kerberos (through PAM, not directly inside SSH).

After the login, I reviewed the event logs and found a large number of entries for the LDAP bind account (the account that is used to bind to Active Directory to retrieve account information, such as UID number, GID number, login shell, home directory, etc.).  These are useless for identifying unique logons to Linux/Unix-based systems.  However, there is one event that is useful—an event ID 672 with the following text:

Authentication Ticket Request:
 	User Name:		bjones
 	Supplied Realm Name:	EXAMPLE.NET
 	User ID:			EXAMPLEbjones
 	Service Name:		krbtgt
 	Service ID:		EXAMPLEkrbtgt
 	Ticket Options:		0x40800000
 	Result Code:		-
 	Ticket Encryption Type:	0x17
 	Pre-Authentication Type:	2
 	Client Address:		172.16.28.111
 	Certificate Issuer Name:
 	Certificate Serial Number:
 	Certificate Thumbprint:	

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

As you can see, this entry clearly identifies the user that was authenticated as well as the IP address of the host to which the user logged in.  Note that the IP address of the workstation from which the user logon originated is not captured here.

OK, that takes care of the typical Linux system.  Now, what about Solaris 10?  I cleared the security event logs (saving them) and attempted an SSH logon to a Solaris server.  As it turns out, Solaris 10 logs two event entries—event ID 672, as above, as well as event ID 673.  The text for event ID 673 is as follows:

Service Ticket Request:
 	User Name:		bjones@EXAMPLE.NET
 	User Domain:		EXAMPLE.NET
 	Service Name:		host-solarishost01
 	Service ID:		EXAMPLEhost-solarishost01
 	Ticket Options:		0x40800000
 	Ticket Encryption Type:	0x3
 	Client Address:		172.16.28.112
 	Failure Code:		-
 	Logon GUID:		{3a653f45-928c-1f72-2c59-ca951986ac42}
 	Transited Services:	-

For more information, see Help and Support Center at
http://go.microsoft.com/fwlink/events.asp.

This provides the same sort of information as well as the name of the service ticket that was requested by the host.  (Keep in mind, too, that Solaris 10 logged both the event ID 672 and event ID 673, whereas CentOS logged only the event ID 672.)

But what about “native” Kerberos authentication, when a Kerberos ticket is used to authenticate the user?  In this case, I tested three different operating systems:  CentOS 4.3, Solaris 10, and OpenBSD 3.9.  In all three cases an event ID 673, similar to above, was logged.  However, this time it was the IP address of my actual workstation—not the IP address of the server—that was included in the event log text.

In all of the tested scenarios, there was information that identified the specific account that was being authenticated.  However, depending upon whether PAM was involved, the Windows event logs may or may not capture the actual IP address of the originating workstation.  In almost all cases, though, the logs on the Linux, Solaris, or OpenBSD server would capture the IP address of the originating workstation, even if the Windows event logs did not.