blog.scottlowe.org

I’m glad I waited just a bit longer to move forward on a purchase of a new MacBook Pro.  I had considered purchasing one late last week, but decided to wait just a bit longer.  My patience was rewarded with an update to the Core 2 Duo (at a top speed of 2.33GHz), double the RAM (2GB instead of 1GB), and a bigger hard drive size (120GB instead of 100GB).  I spoke to the people at the local Apple store at Crabtree Valley Mall, and they placed me on a contact list for the new 2.33GHz 15.4“ model (17” is too big for me).  I’m the second one on the list!

I’m looking forward to the enhanced performance that I should get from the new laptop.  While I absolutely love my current 1GHz PowerBook G4, it’s getting a bit long in the tooth, and I’ll be moving from a single core CPU to a dual core CPU running at double the clock speed.  Not to mention a SATA hard drive instead of an ATA drive, faster front side bus speed (667MHz vs. 133MHz), Airport Extreme instead of “regular” Airport, built-in Bluetooth, and a faster DVD burner with dual-layer support.  I get excited just thinking about it.

I’ve already inventoried my applications, and the majority of them are already Universal.  There are a few notable exceptions, such as Microsoft Office, but otherwise I’m in pretty good shape.

The one thing I’m looking forward to the most is virtualization.  I’ve been selected to participate in the beta for VMware Fusion, VMware’s new Macintosh desktop product, and I can’t wait to get it installed and start running Windows, Linux, OpenBSD, and Solaris on my Mac laptop.  This is where the 2GB of RAM is really going to come in handy.

As soon as I actally get my new MacBook Pro, I’ll post more details and first impressions here.

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?

Nexenta (also called GNU/OpenSolaris) is a blend of OpenSolaris, GNU, and Debian (Ubuntu, specifically).  It’s pretty cool, actually—blending the OpenSolaris kernel with Ubuntu userland binaries to create something that’s not quite Solaris and not quite Linux, but has some of the values of both.  For those of you interested in running it on VMware ESX Server, I’m happy to report that it does work just fine.

To install Nexenta as a VM in ESX, I used the following settings:

• 512 MB of RAM
• 4GB virtual disk (pre-allocated); obviously, you would want more space if wanted to do anything useful with Nexenta
• LSI Logic SCSI controller
• “Flexible” network adapter

The installation went very smoothly and very quickly (quicker than Solaris 10 and a couple of the other Linux distributions I’ve tried on ESX).  The system came up very smoothly and was immediately accessible across the network.  I didn’t try anything useful or meaningful with it; it is an alpha version, after all.

It’s worth keeping an eye on, at least.  I’ll be interested to see how it develops.

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.

After doing some additional research on the authentication architecture for OpenBSD, I learned that OpenBSD does not support PAM (Pluggable Authentication Mechanism), nor does OpenBSD support NSS (Name Switch Service).  I found this particularly interesting, but not terribly surprising as the OpenBSD leaders have made it very clear that they won’t include software that doesn’t meet their stringent security and licensing requirements.  I suppose that’s a good thing, even if it does make certain tasks impossible.

In any case, I did find some veiled references to login_ldap, which uses the underlying bsd_auth mechanism employed by OpenBSD.  Unfortunately (again), not all the software installed with OpenBSD supports bsd_auth and therefore also doesn’t support login_ldap.

There is a bright spot here, though, and that’s OpenSSH.  OpenSSH supports native Kerberos authentication, i.e., passwordless authentication from a Kerberized SSH client to the OpenSSH daemon, which is itself Kerberized.  I wrote about passwordless Kerberos authentication for Linux and Solaris a while ago; it turns out the process is almost identical for OpenBSD.

To enable native Kerberos authentication in OpenSSH, make sure the following commands are present in the sshd_config file (typically found at /etc/ssh):

KerberosAuthentication yes
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes

Be sure to restart the SSH daemon after making these changes.

Also, configure the krb5.conf file (found in OpenBSD at /etc/kerberosV—note the capitalization!) appropriately; refer to any of the Kerberos-related articles here for more information on the appropriate configuration.  For this test, I also created a keytab (using ktpass.exe) and placed it in the /etc/kerberosV directory as well.  I don’t know for sure if that’s required.  As I have time, I’ll do some additional testing and try to find out.

Because there is no NSS support in OpenBSD, you’ll need to maintain accounts (but not passwords) in the local files.  So, to test this, first be sure to create an account (using useradd), create the home directory, and assign appropriate permissions to the home directory.  Otherwise, it won’t work.

Once the configuration changes have been made, SSHd has been restarted, and a local account created, SSH connections from a Kerberos-enabled client (with a valid Kerberos ticket) should just work without any prompt for password.

Although this doesn’t provide the broad integration with Active Directory that some may be seeking, it can at least help with SSH access to the OpenBSD systems, and that’s better than nothing.

The original instructions are found here.  Note, however, that this post contains all the information from the original post plus a few added points found during the latest run through the steps.

Assumptions

This procedure assumes that you are using Windows Server 2003 R2; if you are using a previous version, the LDAP attribute mapping will need to be modified to match the schema extensions found in Microsoft’s Services for Unix (SfU) add-on product.  This will require changes to the “ldapclient manual” command shown below, which handles the schema/attribute mapping.

Preparing Active Directory (One-Time)

These steps only need to be performed once.  Note that if you have performed any of these steps as part of authenticating Linux or Solaris to Active Directory, they do not need to be performed again.  Simply make note of the information used earlier and re-use that information again this time.

1. Install the “Server for NIS” component on at least one Active Directory domain controller (DC), so that the Active Directory schema can be extended to become partially RFC 2307-compliant.  Installing this component will also add a “UNIX Attributes” tab to objects inside the Active Directory Users and Computers MMC console.  You may also need to install the Server for NIS administrative tools on your workstation to see the “UNIX Attributes” tab.
2. Use the Schema Management MMC snap-in to index the uid attribute, which is not indexed by default.  This will speed up the login process and reduce the overall load on your DCs.  (For more information, refer to the Linux-Windows Server 2003 R2 integration instructions.)  It may be possible to change the attribute that Solaris is looking for, but I haven’t found a way to do that yet.
3. 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.  I recommend giving this account a simple, short name; this will make specifying the DN of the account later easier to do.
4. Create a global security group in Active Directory Users & Computers and set the UNIX attributes for this group.

Once these one-time steps have been completed, we can proceed to configuring the individual users that will be authenticating to Active Directory from your Solaris server(s).

Preparing Active Directory (Each User)

Each Active Directory account that will authenticate via Solaris 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 (this tab was made visible by the installation of the Server for NIS component).  The attributes that must be populated are:

• NIS domain:  It’s required on this tab in order to populate the other fields, but we won’t be using it.
• UID:  This is actually the UID number.  Each user must have a unique UID; I believe that the Server for NIS defaults at a starting UID of 10000, which is pretty safe for most systems.
• GID:  In addition, each member must have a GID (group ID); simply specify the group that was created earlier.
• Login Shell:  Specify a login shell (such as “usr/bin/csh” or “/sbin/sh”) for each user.
• Home Directory:  Specify the home directory (such as “/export/home/slowe”) that will be used for this user.  Keep in mind that these values may apply across multiple systems and platforms, and the path must be valid on all systems and platforms.

Based on my experience so far, the values for Solaris will often be very different than what might be specified for Linux-based logins.  I haven’t yet figured out how to reconcile these differences in a multi-platform environment (suggestions are welcome).

After all the user accounts have been configured, then we are ready to perform the additional tasks within Active Directory and on the Solaris server(s) that will enable the authentication.

Preparing Active Directory (Each Solaris Server)

These steps need to be repeated for each Solaris server that will authenticating via Kerberos to Active Directory.

1. Create a user account (not a computer account) for each Solaris server.  (Review this article for more information on the reasoning behind this approach.)  I highly suggest using a naming convention that supports a) the service principal(s) involved; and b) the name of the server.  Since Solaris will use the host service principal, a name like “host-solarissrvr” would be good.  The password doesn’t matter, but do be sure to check the “Password never expires” check box, and after the account is created specify a good description so that you’ll remember what this account is for in 6 months.
2. For each account that was created, run the ktpass.exe command to generate a unique keytab for each account.  The command will look something like this (substitute the appropriate values where necessary):

   ktpass -princ host/fqdn@REALM -mapuser DOMAINaccount
   -crypto DES-CBC-MD5 +DesOnly -pass password -ptype KRB5_NT_PRINCIPAL
   -out filename

   Be sure to specify a unique output filename (so that you don’t overwrite files; each server/account will needs its own unique file).  I suggest using the server’s name as the filename, i.e., something like “solarissrvr.keytab”.

Now that each Solaris server has a matching account in Active Directory, and each account has had a keytab generated for it, we’re almost ready to move on to configuring the Solaris servers themselves.  First, though, we need to take care of some name resolution issues.

Configuring Reverse DNS

On the DNS server handling the reverse lookup zones for the subnet on which the Solaris server is located, add a PTR record for the Solaris server and it’s IP address.  This will ensure that reverse DNS lookups work as expected.  Make sure that each Solaris server that will be authenticating against Active Directory has a reverse lookup record in DNS.

Configuring Solaris (Each Server)

The following steps need to be performed on each Solaris server that will authenticate against Active Directory.

Configuring the hosts file

To enable reliable TGT validation (this ensures that the Kerberos ticket returned by a KDC actually came from the KDC and not a spoofed server), you’ll need to edit the hosts file.  On Solaris 10, this is found in /etc/inet/hosts and is read-only, even for root.  Edit this file (changing permissions as necessary) so that the line with the server’s IP address looks something like this:

10.1.1.1        hostname.example.com hostname loghost

What we’re doing here is making sure that the server’s fully qualified domain name (not just the short hostname) is the first name entry on the line for the server’s IP address.

There may or may not be other entries in the file; leave those entries untouched (unless you know you need to modify them).

Configuring Kerberos

Solaris keeps its Kerberos configuration in the /etc/krb5 directory as krb5.conf.  Edit this file using your editor of choice to look something like the one below.  Depending upon how you configured Solaris during the installation, some of this configuration may already be present.

[libdefaults]
        default_realm = EXAMPLE.COM
        dns_lookup_kdc = true

[realms]
        EXAMPLE.COM = {
        kdc = dc01.example.com
        kdc = dc02.example.com
        admin_server = dc01.example.com
        }

[domain_realm]
        .example.com = EXAMPLE.COM
        .subdomain.example.com = EXAMPLE.COM

[logging]
        default = FILE:/var/krb5/kdc.log
        kdc = FILE:/var/krb5/kdc.log
        kdc_rotate = {
        period = 1d
        version = 10
        }

[appdefaults]
        kinit = {
        renewable = true
        forwardable= true
        }

You can’t simply copy and paste from here to the Solaris configuration file, as you’ll need to customize your version for your particular network, hostnames, domain names, etc.

Transfer the keytab generated earlier by the ktpass.exe utility (in our example, it was called “solarissrvr.keytab”) to the Solaris server in some secure fashion, like SFTP or SCP.  Place it in the /etc/krb5 directory as krb5.keytab, and make sure that only root has permissions to the file.

Configuring LDAP

We’ll use the native Solaris “ldapclient” utility to configure the LDAP support in Solaris.  The command you’ll type in looks something like this (please don’t copy and paste this, as it contains generic/incorrect information that won’t work!):

ldapclient manual 
-a credentialLevel=proxy 
-a authenticationMethod=simple 
-a proxyDN=cn=proxyuser,cn=Users,dc=example,dc=com 
-a proxyPassword=Password1 
-a defaultSearchBase=dc=example,dc=com 
-a domainName=example.com 
-a “defaultServerList=172.16.1.10” 
-a attributeMap=group:userpassword=userPassword 
-a attributeMap=group:memberuid=memberUid 
-a attributeMap=group:gidnumber=gidNumber 
-a attributeMap=passwd:gecos=cn 
-a attributeMap=passwd:gidnumber=gidNumber 
-a attributeMap=passwd:uidnumber=uidNumber 
-a attributeMap=passwd:homedirectory=unixHomeDirectory 
-a attributeMap=passwd:loginshell=loginShell 
-a attributeMap=shadow:shadowflag=shadowFlag 
-a attributeMap=shadow:userpassword=userPassword 
-a objectClassMap=group:posixGroup=group 
-a objectClassMap=passwd:posixAccount=user 
-a objectClassMap=shadow:shadowAccount=user 
-a serviceSearchDescriptor=passwd:dc=example,dc=com?sub 
-a serviceSearchDescriptor=group:dc=example,dc=com?sub

The easiest way to handle this would probably be to copy it into a blank text file, edit it to include the specific details for your network, and then paste it into a terminal session on the Solaris server.

After this command has been run, Solaris will create the LDAP configuration in /var/ldap and will update /etc/nsswitch.conf to use LDAP.  However, because we only want to use LDAP for specific purposes, we’ll need to go back and edit /etc/nsswitch.conf again.  Just remove “ldap” from all entries in /etc/nsswitch.conf except for passwd and group.

While you’re editing /etc/nsswitch.conf, be sure to add a “dns” entry at the end of the line for hosts:

hosts          files dns

This will help ensure that Solaris is properly configured to use DNS for host name resolution.

I think it’s necessary at this point to restart the LDAP client service:

svcadm restart svc:/network/ldap/client:default

Use the “svcs -a | grep ldap” command to verify the exact name of the LDAP client service on your Solaris server.

Configuring the DNS Client

You’ll also need to make sure that the DNS client is enabled and running.  Using “svcs -a | grep dns” will help you identify the correct service, which you can then enable with svcadm:

svcadm enable svc:/network/dns/client:default

Test DNS resolution using either the “host” or “nslookup” commands.

Configuring PAM

The /etc/pam.conf file controls the PAM (Pluggable Authentication Mechanism) configuration on Solaris.  You’ll need to edit the /etc/pam.conf file to look something like what’s shown below.  I’ve edited away all the non-essential sections, so only change the sections listed below.

# Default definition for Authentication management
#
other   auth requisite          pam_authtok_get.so.1
other   auth required           pam_dhkeys.so.1
other   auth sufficient         pam_krb5.so.1
other   auth required           pam_unix_cred.so.1
other   auth required           pam_unix_auth.so.1
#
# Default definition for Account management
#
other   account requisite       pam_roles.so.1
other   account sufficient      pam_unix_account.so.1
other   account required        pam_ldap.so.1
#

With this configuration in place, Solaris will use Kerberos authentication and will retrieve account information via LDAP.

Reboot the Solaris Server

I know this sounds stupid, but even after restarting LDAP and enabling/starting/restarting the DNS client, things still didn’t work for me in the lab.  However, after rebooting the Solaris server, it worked like a champ.  So, just in case, reboot the Solaris server after completing the configuration.

Testing the Configuration

Once all of the configuration steps have been completed, you can test the configuration with the following commands:

• You can use “getent passwd <Name of AD user>” from the Solaris server; this command should return UID number, GID number, UNIX home directory, and login shell.
• You can use “kinit <Name of AD user>” to test Kerberos authentication.  A succesful Kerberos test will not return any feedback, and the “klist” command will show a ticket granting ticket (TGT) from the Active Directory DC/KDC.

If either of these tests are unsuccessful, review the log files on the Solaris server and resolve the problems before continuing.  Both of these tests will need to be successful in order for authentication to work correctly.

If the tests are successful, then you should now be able to authenticate on a Solaris server using your Active Directory username and password.  I tested this using SSH and the X Desktop login.

The syntax for finding recently created Active Directory accounts using either Dsquery or AdFind is listed below.  In this context, we’re defining “newly created accounts” as all accounts created after a specific date.  The date is encoded into the commands, as explained below, so you can tailor this to your specific environment.

Using AdFind, the syntax would look like this:

adfind -b dc=example,dc=net -f “(&(objectCategory=Person)
(objectClass=User)(whenCreated>=20061001000000.0Z))”

This would return all user accounts created on or after October 1, 2006.  Of course, you could add the “-csv” option to output the results in CSV format, and redirect the output to a text file (using the > redirection symbol) for further processing as needed.

Using Dsquery, the syntax would look like this:

dsquery * dc=example,dc=net -filter “(&(objectCategory=Person)
(objectClass=User)(whenCreated>=20061001000000.0Z))”

The syntax is very similar, and the actual LDAP query is identical between the two applications.

The key to making it work is the syntax of the whenCreated portion of the LDAP query, which breaks down like this:

YYYY MM DD HH mm ss.s Z
2006 10 01 00 00 00.0 Z

Specify a value of zeroes where the value is not important; in this case, we don’t really care what time on or after October 1, 2006 the account was created so we leave the hour, minute, and seconds fields empty.  The capital Z at the end is mandatory.

This article at Microsoft discusses some of the search criteria, but the breakdown of the syntax for the whenCreated value wasn’t correct; I found working values from this Usenet discussion on microsoft.public.win2000.active_directory.

To setup a simple NAT router/firewall using OpenBSD, use these steps as a general guideline.  I’m assuming that you have general knowledge of OpenBSD.

First, configure the network interfaces appropriately.  Typically, this will involve editing the hostname.<NIC type> file.  In a VMware ESX Server environment, OpenBSD uses pcn0 for the first virtual NIC, pcn1 for the second virtual NIC, etc., so the appropriate configuration files would be hostname.pcn0, hostname.pcn1, and so forth.

Next, enable IP forwarding by editing /etc/sysctl.conf and making the following change (the line is present in a default installation, you just need to uncomment it):

net.inet.ip.forwarding=1

Next, we’ll need to enable the OpenBSD packet filter, pf.  This is typically done by creating/editing the file /etc/rc.conf.local and making sure the following line is present:

pf=YES

Next, we’ll configure pf for network address translation (NAT) and simple packet filtering.  If you’ve never configured pf before, I highly recommend this OpenBSD PF guide; it will introduce you to the functionality of this very powerful packet filtering engine.  (Sometimes I wish Mac OS X would switch to using pf.)  You configure pf by placing a ruleset into /etc/pf.conf.

Here’s a quick sample ruleset (keep in mind this is based on OpenBSD running as a virtual machine in a VMware environment):

# Set some variables for use later
ext_if=“pcn1”
int_if=“pcn0”
icmp_types=“echoreq”

# Skip all loopback traffic
set skip on lo

# Scrub all traffic
scrub in

# Perform NAT on external interface
nat on $ext_if from $int_if:network -> ($ext_if:0)

# Define default behavior
block in
pass out keep state

# Allow inbound traffic on internal interface
pass quick on $int_if

# Protect against spoofing
antispoof quick for { lo $int_if }

# Allow other traffic
pass in on $ext_if proto tcp to ($ext_if) port ssh flags S/SA keep state
pass in inet proto icmp from $allowed_hosts icmp-type $icmp_types keep state

This is a really, really simple configuration, but it will get the job done.  (I did title this “OpenBSD as a Simple NAT Router”, after all.)

For more advanced configurations, I highly recommended reviewing the OpenBSD documentation (which, by the way, is very thorough and very extensive; kudos to the OpenBSD team for their documentation efforts.)