blog.scottlowe.org

I just finished submitting my proposal for a VMworld 2007 presentation.  When I first came up with the idea for this presentation, I thought it was a great idea, but the more that I worked with it the less enamored I became of it.  So instead of the presentation being a “how to” on how to use this specific functionality, it became more of a discussion of advantages versus disadvantages of going down that route.  I have no idea how the proposal will be received by the VMworld presentation committee, but I figured I should at least give it a try.  After all, the worse that can happen is for them to say No, right?

Thanks to some very helpful individuals in the #solaris channel on irc.freenode.net, I’ve been able to get ADS support working in Samba on Solaris 10, and thus have been able to incorporate the use of Samba in the Solaris 10-AD integration instructions.

To refer to earlier versions of the Solaris 10-AD integration instructions, see this article or this article.  I would expect that you won’t need to refer to those posts, though, and will be able to get most of what you need directly from this post.

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.  (I only have a single article written that includes pre-R2 attribute mapping, and that’s this Linux-AD article.  The schema mapping should be very, very similar between that article and Solaris 10.)

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.  The only workarounds I’ve found to address these issues is the clever use of symlinks and the use of NFS automounts for home directories.

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.

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, and ensure that both forward and reverse lookups work from each of the Solaris server(s).

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).

Installing Blastwave Packages

This is the key to getting ADS support into Samba on Solaris 10.  I won’t go into excruciating detail on this since this process is amply covered elsewhere, but here’s the basic idea of the process:

• Use the standard wget (found in /usr/sfw/bin) to download the pkg-get file used by Blastwave.
• Use pkgadd to install pkg-get.
• Configure pkg-get to use the unstable packages (makes sure you get the latest builds).
• Use pkg-get to install the CSWsamba package and all requisite packages (there were quite a few dependency packages during my testing).

Once the CSWsamba package and related packages are installed, we’ll need to configure Samba by creating /opt/csw/etc/samba/smb.conf with the following contents:

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

At this point, we are ready to configure Kerberos and then proceed with testing the configuration and join the Active Directory domain.

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
        }

There will also be a file named cswkrb5.conf in the /etc directory; you can configure this file with the contents of the [libdefaults], [reamls], and [domain_realms] sections as listed above.  You don’t need to include the [logging] or [appdefaults] sections in this file.

Note that you can’t simply copy and paste from here to the Solaris configuration files, as you’ll need to customize your version for your particular network, hostnames, domain names, etc.  If you must copy and paste from here, put it into a text editor first to customize it for your implementation.

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 the “nslookup” command.  As mentioned previously, be sure to test both forward and reverse lookups.

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 join the Solaris server to Active Directory using Samba.

Joining the Solaris 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 the Solaris server (assuming the AD users have been properly configured).

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

1. Verify the Samba configuration as outlined earlier.  Key to the configuration are the “security = ads” and “use kerberos keytab = true” directives.
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 Solaris 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.  You may see an error about a missing userPrincipalName, but this does not appear to affect any functionality.

At this point, all properly configured AD users (those users who have UNIX attributes) should be able to login to the Solaris server using their Active Directory username and password.  Of course, this assumes that you’ve already dealt with home directories (or are automounting home directories).

As with previous instructions, these instructions don’t address password management (the ability to change an AD password from Solaris) and don’t address how to handle home directories.  Hey, I’ve got to leave a few challenges for others to tackle, right?

How I Tested

This testing was done using Solaris 10 11/06 (Update 3) running on VMware ESX Server 3.0.1.  Active Directory was running on a pair of servers with Windows Server 2003 R2, also virtual machines on ESX Server.  Authentication testing was performed using SSH from a client system running Mac OS X.

The idea of chrooting (or jailing) certain security-sensitive services is a well-known and pretty well-accepted method of protecting systems against further compromise in the event of a security breach.  BIND is commonly run in a chroot jail, as can be Apache HTTPD or an FTP server.  SSH is another common target for running in a chroot jail, and SSHjail is a patch designed to simplify the process of running OpenSSH in a chroot jail.  (UNIX die-hards, please forgive me and correct me if I am mistakenly interchanging “chroot” and “jail”.)

I was alerted to SSHjail via this article on Linux.com, and it certainly appears that SSHjail greatly simplifies the process of running OpenSSH in a chroot jail.  What interested me more than the configuration or use of SSHjail (which, as I mentions, looks pretty straightforward—kudos to the developer) was the question, “Could SSHjail be used in centralized authentication environments?”

Perhaps due to my work in Linux/UNIX-Active Directory integration, but the idea of using SSHjail initially seemed to be at odds with an environment where users are being authenticated via Kerberos/LDAP against Active Directory.  After all, the home directory would normally be specified on the user object’s properties in AD, so how would that interact with the home directory configuration specified in the /etc/sshjail.conf file?  Is SSHjail so transparent that it won’t matter?#160; For example, if I specify that “/home/slowe” is the UNIX home directory in AD, and SSHjail is configured to put me into a jail at “/chroot/ssh/”, do I need to then change the UNIX home directory in AD?  The article seems to imply that it does, as it mentions editing local users to specify a new home directory location.  How, then, do we handle disparate systems where SSH may be jailed on some and not on others?

<aside>Of course, this brings back up the question of how to handle different operating systems, such as Solaris and Linux, that (by default) place home directories in different locations on the file system or in different file systems.</aside>

Any feedback or clarification from Linux/UNIX experts out there is welcome.  It would be great to be able to include information on how to utilize SSHjail in conjunction with AD integration.

The last update to the Solaris 10-Active Directory integration instructions was in October of last year, over six months ago.  Since that time, Sun has released another update to Solaris (Solaris 10 11/06, or Update 3) and I have been able to gather some additional information on using an Active Directory-aware version of Samba to help with the process (much like described in the latest version of the Linux-AD instructions).

The new version will use Kerberos for authentication, LDAP for account information, and Samba to do the “heavy lifting” of joining Active Directory, creating the necessary objects, and creating the keytab and keytab entries on Solaris.

I hope to post the updated integration instructions within the next few days, before I have to leave for a business trip to Canada.

Using Samba in Linux-AD integration scenarios is tremendously helpful because it removes the need to manually create the SPNs and export the keytabs out of Active Directory.  I wrote up my first test of Samba in Linux-AD integration, then proceeded to verify that procedure and include it in the full Linux-AD integration instructions.  But would it work in Solaris-AD integration scenarios?

In theory, yes.  After all, Samba is included with Solaris 10, right?  Right!  Unfortunately, the version of Samba that’s included was not compiled with ADS support, and recompiling Samba to include ADS support means also recompiling a whole ton of other junk as well.  Fortunately, this thread titled “Samba on Solaris 10 in native ADS environment” gives complete instructions on how to compile Samba with ADS support on Solaris 10 so that one can use Samba for AD integration.

I plan to test this in my lab as soon as possible, and when I have some first results I’ll post more information here.

This is one of those commands that you need to know, but use it so very rarely that it’s hard to memorize.  It seems like I have to go back and look this up every time I need to use it.  What is it?  It’s the command to mount an SMB share from the typical Linux host.

The command looks something like this:

mount -t smbfs -o username=User,password=Pass
  //host.IP.addr.ess/sharename /local/mnt

Of course, this should be typed all on a single line.

I find myself most often using this command when I need to mount an SMB share from the Service Console of one of my ESX hosts.  So, to keep myself from having to go out and perform yet another Google search next time I need this, I’ll know to just look right here.

This is really exciting news.  Development on Cocoalicious, the Mac OS X native application that front-ends del.icio.us, has started back up again.

I’ve blogged many times about Cocoalicious (starting as far back as June of 2005) and how much I enjoy using the application to manage my del.icio.us bookmarks.  I was really disappointed that development had stalled, and had even started searching for replacements to the application.  Fortunately, it looks like the new developer (who is working with the original author, not replacing him, from what I understand) is already seeking feedback and ideas for future versions.

Personally, I’m pretty thrilled with the application as it is, and have only one feature request:  please, please, PLEASE drop the brushed metal interface.  Or at least offer us an option to toggle back and forth.  I’d love to see a fresh new UI like that used by Mail.app or NetNewsWire, with the tags in a pane on the left and your bookmarks listed on the right, and a divider (like the one used now) to open, close, or resize the built-in browser.  Combine that with a new, modern unified toolbar (not Mail.app’s lozenges, please!) and perhaps incorporate some of the tag UIs that have been proposed (like this one), and you’ve got yourself one killer del.icio.us client.

A week ago, I posted a call for prayer for my family.  I appreciate the many responses that I received, and I am happy to report that the Lord has answered our prayers.  Although the answer did not come in the form that I had hoped, I am still thanking God for deliverance and I am praising God for his wondrous works.

Things could have gone much, much worse in this situation, but God’s power carried my family and I through this trial and I believe that our faith and our belief is stronger for it.  Again, thanks to everyone who responded, and thanks to all those who lifted their voices in prayer for my family.  I hope that God richly blesses each and every one of you for your compassion and concern.

The author of this recent post suggests that using VMware as “middleware for the OS” provides an abstraction layer that can help organizations in a variety of ways:

A layer between the hardware and OS could drastically reduce the complexity of upgrades and help to future proof a changing environment.

In that regard, I agree.  Years ago, Dave Cutler and the Windows NT development team envisioned the HAL (Hardware Abstraction Layer) as a tool to do the same thing that VMware’s virtualization layer is doing today, and that is to hide many of the platform dependencies.  In Windows NT’s heyday, you could run the OS on x86, MIPS, PowerPC, and DEC Alpha systems—all based on the same high-level code and derived from the same code base, made possible by the HAL.  Now VMware has stepped in to perform a similar function, abstracting workloads from the underlying hardware so that workloads can be transparently scheduled across CPU cores both within and between server chassis.  With the rise of x86/x64 and the fall of RISC chips, the need to be portable across processor platforms has decreased, and so instead of providing portability across CPU architectures, VMware’s virtualization layer provides portability across CPUs and CPU cores.  It’s a tradeoff I’ll take.

So, in one regard, I agree with the author in that using VMware as an abstraction layer can reduce complexity and provide flexibility and protection against future upgrades.

Where I differ from the author’s perspective is the idea of a “1:1 ratio” of operating system to hardware, with the virtualization layer in the middle.  In my mind, one of the key benefits of the virtualization layer is higher utilization of the underlying hardware.  As multi-core processors proliferate, many mainstream operating systems (not all, but many) are unable to effectively utilize the processing power.  This will become more and more evident as the number of cores and the parallel processing power of each core increases.  Why then not multiplex workloads onto the hardware?  In this case, you still gain the abstraction benefits but you also gain a better return on investment.

I know that my weblog defies the “normal rules” of how one should run a weblog in that I freely mix both personal and professional topics on the same site.  As I said in my very first post, I can’t hide who I am, and I am a Christian.  If that means that my Christianity bleeds into everything else, so be it.

I don’t know if you read my site for my technical articles, or for my occasional personal post, and I don’t know if any of you reading out there are indeed Christians.  If you are a follower of Christ, then I’d like to make a simple request of you: please pray for my family.

My family is going through a rough time right now.  The details of the specific situation aren’t important; what’s important is that I—we—continue to lean upon the Lord and His strength in order to make it through the storm.  To do that, we’ve already enlisted the help of many prayer warriors that we know personally.  Now I seek the help of prayer warriors that I don’t know personally.

This situation that we are going through will come to a head sometime next week.  If you could, please remember my family in your prayers throughout the remainder of this week.  My wife and I are praying together with the family nightly, and praying with each other every day.  Our friends, our pastors (past and present), Christian co-workers, and fellow church members also have us on their prayer lists.  Will you pray as well?  I know that through the combined prayer and faith of the believers that my family can emerge through this situation with a powerful testimony to share with others.