blog.scottlowe.org

If you haven’t read the previous articles, take a quick moment to review them before continuing:

Solaris 10 and Active Directory Integration
Native Kerberos Authentication with SSH

Initially, problems cropped up with both of these, but it seems as if the problems have been resolved.

Solaris 10 and Active Directory Integration

The problem, as outlined in the original article, was that TGT validation wasn’t working.  The only way to make Kerberos authentication (via pam_krb5) to work was to disable TGT validation.

Since that time, I have re-enabled TGT validation, and everything seems to work just fine.  I believe that the problem was in the /etc/hosts file, since I’ve been seeing a fair number of comments in the various articles dealing with AD integration of non-Windows platforms.  I believe that the fix is making sure that the server’s fully qualified domain name is listed first in the /etc/hosts file, like so:

127.0.0.1       localhost localhost.localdomain
10.1.1.1        hostname.example.com hostname
<...other entries as needed...>

On the line where the server’s IP address is listed, make sure that the fully qualified domain name is listed first.  I can’t be absolutely sure that this is the fix, but this is the only thing I can think of that I did on both Linux and Solaris.  I hope to perform some testing later this week and I’ll post the results here.

Native Kerberos Authentication

The problem here was again the Solaris server—or so it seemed.  I had (and currently have) it working with a CentOS server; I can obtain a Kerberos ticket and then transparently authenticate to the CentOS server without getting prompted for a password.  With the Solaris server, though, I kept getting a “Server not found in Kerberos database” when attempting to connect.  It wasn’t until today that I realized that the key difference between the Linux installation and the Solaris installation was that the Solaris server was in a different DNS domain.  Since my PowerBook didn’t have the equivalent of an /etc/krb5.conf to match DNS domain names with Kerberos realms, it was trying to obtain a ticket for a realm that does not exist.  More appropriately, it was contacting a Kerberos realm that did not have a matching entry with the right SPN, hence the “Server not found in Kerberos database” error.

To verify this, I edited the /etc/krb5.conf file on a Linux server to map DNS domains and Kerberos realms (i.e., mapped “example.net” to “ad.example.net”), obtained a Kerberos TGT using kinit, and then attempted to make an SSH connection to the Solaris server.  Lo and behold, it worked!  I verified this quickly on Mac OS X using the built-in Kerberos application to properly map DNS domains to Kerberos realms, and it worked as well.

<aside>You are supposed to be able to use Cmd-E in Kerberos.app to edit the domain-realm mapping.  However, I found that keystroke doesn’t work until a Kerberos preferences file (named edu.mit.Kerberos, either in ~/Library/Preferences or /Library/Preferences) is created.  This file is simply the equivalent of an /etc/krb5.conf file as you might see on any other Unix-related platform.  Once that file had been created—even if it was empty—the Cmd-E shortcut and the Edit Realms command on the Edit menu worked as expected.</aside>

So, the server was not the problem, instead it was the configuration of my PowerBook all along.  Go figure!  In any case, it is working now.  The lesson to be learned:  be sure that either your Kerberos realm maps perfectly to Active Directory’s DNS name, or be sure client machines are properly configured for domain-realm mappings.

There were two driving factors that led me to rebuild the iSCSI-based storage that was currently serving the test lab, instead of continuing to use the Data ONTAP Simulator.  First, we had acquired a Gigabit Ethernet backbone for the test lab, and I wasn’t convinced that the Data ONTAP Simulator was taking full advantage of the Gigabit Ethernet NICs I installed in the server.  I also wanted to test bonding some NICs together for more throughput, or possibly to try some multipathing.  I couldn’t do either of those with the Data ONTAP Simulator.  Note that this is not a knock against the Data ONTAP Simulator; it’s not designed or intended for those kinds of things.  (It would be great if I could get a real NetApp device in the lab, but I don’t know if that will ever happen.)

After doing some brief research, I settled on using CentOS 4.3 and the iSCSI Enterprise Target (IET).  The installation of CentOS was straightforward and simple, and the installation of IET was equally simple, due perhaps to these fairly detailed instructions for installation of RHEL 4 (which are equally applicable to CentOS 4).  I heartily recommend, based on my experience so far, using the source RPMs instead of building from source.  It made the process easy and (almost) painless.

I setup a 10GB logical volume using LVM2 and configured IET to present it via iSCSI by editing /etc/ietd.conf to show this:

Target iqn.2006-08.com.example:vmware.lun1
    IncomingUser isanuser secretpw
    Lun 0 Path=/dev/VolGroup00/lvol0,Type=fileio

(Obviously, you’d need to adjust this as appropriate for your own installation.)

Having already learned my lesson regarding the ESX firewall, I ensured that the software iSCSI initiator traffic was allowed outbound before continuing (refer here for more details).  Using the Virtual Infrastructure client, I reconfigured the ESX 3 server to see the new iSCSI server, and the new LUN popped up immediately upon a rescan.  From there, it was a simple operation to establish a new VMFS datastore on the iSCSI LUN and move a VM to the LUN.  That was easy!

The next steps will be to do some performance tuning, test bonding the NICs and/or multipathing, and perform some NFS interoperability tests.  (Remember that NFS is also supported by ESX 3 for datastores.)

You’ve probably all run into the “Unable to relay” error message before.  The usual fixes to this problem are pretty straightforward:

• Add the address space to a recipient policy in Exchange System Manager; this tell Exchange to accept the messages as inbound; or
• Add IP addresses, subnets, or host names to the SMTP virtual server in Exchange System Manager as allowed to relay through this host;

Generally speaking, either one of these two options will generally fix the problem.  If the address space (say, example.com) should truly be accepted inbound, then adding it to an Exchange recipient policy will tell Exchange to accept it as inbound—thus eliminating the relay issue.  Likewise, if the messages should truly be relayed to their final destination, then adding the host(s) to the list of machines allowed to relay via the Exchange SMTP virtual server will indeed do that.  Pretty simple, right?

In this case, the e-mail address space should have been accepted inbound, so I first added the address space to an Exchange recipient policy (leaving the check box to apply that address space to recipients unchecked, since I didn’t really want addresses from this domain applied to users).  That didn’t work.  OK, maybe the check box to apply this domain needs to be checked, so I add it to a recipient policy that has no filter criteria (and therefore won’t be applied to any users).  It still doesn’t work.

Next, I add the appropriate servers to the list of hosts allowed to relay (by modifying the properties of the Exchange SMTP virtual server), restart the SMTP service, and try again.  It still doesn’t work, reporting a “5.7.1 Unable to relay for <username>” message.

My colleague searched the Microsoft Knowledge Base and turns up KB article 323669, titled “XFOR: 550 5.7.1 Unable to relay Error Message When E-Mail is Sent to Local Exchange Recipient”.  In the article, it mentions using MetaEdit to edit the IIS metabase and delete the LM/DS2MB key.

Good idea, but MetaEdit doesn’t support IIS 6.0, and this problem is occurring on Windows Server 2003 with Exchange Server 2003.  Fortunately, the IIS 6.0 Resource Kit comes with the Metabase Explorer, which allows me to delete the key as per the KB article and restart the services.  After restarting the services, the problem is fixed!  (Kudos go to Chauncey, who found both the article and the Metabase Explorer.)

Apparently, the DS2MB portion is involved in one-way replication of configuration data from Active Directory (the directory service, hence the “DS” in the name) to the metabase.  If the metabase (or even just the DS2MB portion of the metabase) gets damaged, then changes made in Exchange System Manager—which are written to Active Directory via the configuration domain controller—will never get synchronized to the IIS metabase.  Since the IIS metabase controls the SMTP service, then SMTP will continue to deny what it believes to be unallowed requests to relay.  Removing the DS2MB key and restarting the services rebuilds that portion of the metabase from scratch, thus pulling in the correct configuration from Active Directory and fixing the problem.

First, a quick disclaimer:  I have only tested this in a very limited configuration.  Namely, using OpenSSH 4.2p1 on Mac OS X (as reported by “ssh -V”) to connect to OpenSSH 3.9p1 on CentOS 4.3 (again, as reported by “ssh -V”).  I have been trying to get it to work with the SSH server in Solaris 10 but have been unsuccessful thus far (more on that in a moment).

Configuring the SSH Server

First off, you’ll need to make sure that the OpenSSH server’s Kerberos configuration (in /etc/krb5.conf) is correct and works, and that the server’s keytab (typically /etc/krb5.keytab) contains an entry for “host/fqdn@REALM” (case-sensitive).  I won’t go into details on how this is done again; instead, I’ll refer you to any one of the recent Kerberos-related articles (like this one, this one, or even this one).  Just be sure that you can issue a “kinit -k host/fqdn@REALM” and get back a Kerberos ticket without having specify a password.  (This tells you that the keytab is working as expected.)

Next, configure the /etc/ssh/sshd_config file (the system-wide SSH daemon configuration file) to include the following lines (note that these lines may already be present, just commented out; other lines may be present, but with different values):

KerberosAuthentication yes
GSSAPIAuthentication yes
GSSAPICleanupCredentials yes
UsePAM no

After these changes are made, you’ll need to restart the SSH daemon.

Configuring the SSH Client

Because the OpenSSH client configuration does not include GSSAPI authentication by default, you’ll most likely need to modify your SSH client configuration.  Edit the global client-side configuration file; on Mac OS X it’s found as /etc/ssh_config.  Change it to include the following lines:

Host *.example.com
  GSSAPIAuthentication yes
  GSSAPIDelegateCredentials yes

This limits GSSAPI authentication to only those hosts in the example.com domain.  Modify the domain to be the appropriate domain for your network.

Testing the Configuration

Obtain a valid Kerberos ticket from Active Directory.  On Mac OS X, you can use the excellent Kerberos.app that’s bundled with the system to obtain a ticket.  You can also just use “kinit username” from the command line.

Once you have a ticket, you should be able to simply “ssh fqdn.of.server” and you will get logged in, without getting prompted for a password.  If you get prompted for a password, go back and double-check your keytab, your SSH daemon configuration, and the time configuration on your OpenSSH server.  Because Kerberos requires time synchronization, differences of greater than 5 minutes will cause the authentication to fail.

Future Configurations

As I mentioned earlier, I have also been trying to make this work with the SSH server bundled with Solaris 10 (which, as I understand it, is not OpenSSH).  So far, I have been unsuccessful in this effort, even though the pam_krb5 integration (having the keyboard-interactive login checked/authenticated via Kerberos) is working just fine.  Sun’s SSH server is supposed to include GSSAPI authentication enabled by default, but for some reason my client is throwing a “Server not found in Kerberos database” error (seen when running “ssh -vvv full.server.name”).  I’m not yet sure what’s going on there, but I intend to continue to research the problem and try to find a solution.  Solaris gurus out there, I’m open for suggestions.

UPDATE:  The problems with Kerberos SSH logins to Solaris was a client-side issue; read more about that here.

I’ll break the information down according by the article to which the information pertains.  If the information pertains to all the articles equally, it is included in the “All Articles” portion.  Links back to the original articles are included.

All Articles

User Accounts vs. Computer Accounts

One thing in common across all these articles is the need to create special accounts in Active Directory. I originally recommended the use of computer accounts, but over the course of time additional integration tasks with Kerberos have led me to believe that the user of user accounts, not computer accounts, is the best way to handle this.  In a very early Linux-AD integration article, I discussed the use of computer accounts instead of user accounts, and the use of the ktpass.exe command to extract a keytab from a computer account.  At that time, it seemed reasonable to recommend computer accounts—we were only discussing a single service principal (the host itself), and using a computer account made sense.

However, because of the fact that additional accounts will have to be created for additional service principals (for example, if you are interested in using Kerberos-based SSO with Apache) and because you can’t have multiple computer accounts with the same name, it’s just as well to use a user account with a naming convention that describes the purpose of each account.  For example, something like “host-fqdn” for the host/fqdn@REALM service principal (used for scenarios involving pam_krb5 and “native” Kerberos/GSSAPI authentication), and “http-fqdn” for the HTTP/fqdn@REALM service principal (used by mod_auth_kerb for Apache-Kerberos integration).  This provides an easy way to distinguish between these accounts, and allows for the multiple accounts that are required in these kinds of scenarios.

Finally, the use of user accounts will eliminate some spurious error messages that ktpass.exe generates when run against a computer account.  Note that these error messages are not substantive; things will still work with a computer account.  It’s just that ktpass.exe appears to have been intended to run against a user account.

Updated ktpass.exe Command Line

In addition, because of differences in the encryption types supported by Active Directory and many Unix/Linux implementations, I have found that using the “+DesOnly” switch with ktpass.exe seems to help.

An updated ktpass.exe, accounting for the change to a user account and the desire to use DES encryption types, would look something like this:

ktpass.exe -princ host/fqdn@REALM -mapuser DOMAINaccount
-crypto des-cbc-md5 +DesOnly -pass Password123 -ptype KRB5_NT_PRINCIPAL
-out c:filename.keytab

Please note that this command, particularly the service principal name (as specified by the “-princ” parameter) is CASE SENSITIVE.  For example, the host SPN (i.e., “host/fqdn@REALM”) that is used by pam_krb5 and “native” Kerberos/GSSAPI authentication is lowercase.  However, the HTTP SPN (used by mod_auth_kerb with Apache) needs to be uppercase.  In both cases, the Kerberos realm (which should be equivalent to the Active Directory DNS domain name) must be in uppercase.

Linux-AD Integration (Pre-R2)

The original article is found here.

In addition to the switch from a computer account to a user account as described above, the only real change to this article pertains to the /etc/ldap.conf file that configures the nss_ldap library.  Remember that in almost all of these scenarios, we are using Kerberos for authentication and LDAP for account information, i.e., storing the information that would normally be stored in /etc/passwd.

The original article calls for /etc/ldap.conf to include this line:

nss_base_group dc=mydomain,dc=com

To help optimize LDAP traffic against Active Directory, change the /etc/ldap.conf as follows:

nss_base_group dc=mydomain,dc=com?sub?
&(objectCategory=group)(gidnumber=*)

(This should all be on a single line.)  This will help reduce the query load on Active Directory by limiting the types of objects for which searches will be issued; in addition, the “objectCategory” type is indexed, which also also greatly speed operations.

Speaking of indexing, if the pam_login_attribute is not modified (it defaults to uid), you’ll also need to index the uid attribute in order to avoid heavy CPU utilization and delays in responses from Active Directory.  This was mentioned in the updated Linux-AD R2 instructions.  Alternately, you can change the pam_login_attribute in /etc/ldap.conf to an indexed attribute, like sAMAccountName.

Last, you may find it useful to edit /etc/ldap.conf and change the gecos field mapping from name to cn (i.e., use “nss_map_attribute gecos cn” instead of “nss_map_attribute gecos name”).

Linux-AD Integration (R2)

The latest version of these instructions are found posted here.

Again, other than the change to a user account instead of a computer account (as described above), the changes mentioned in the previous section also apply here:

• Changing the nss_base_group in /etc/ldap.conf
• Changing the nss_map_attribute for gecos in /etc/ldap.conf
• Changing the pam_login_attribute to an indexed attribute in Active Directory (such as sAMAccountName) or indexing the uid attribute

Otherwise, the revised instructions are reasonably accurate and seem to work pretty well.

Kerberos-Based SSO with Apache

This article is found here, and already incorporates most of the changes mentioned in this posting.  No suggested changes are needed at this time.

Solaris 10 and AD Integration

This article can be found posted here.

This one is a pretty recent article (published within the last week or so), and so already incorporates most of the changes suggested here.  The information that I don’t have yet, however, is exactly how to incorporate some of the other suggested changes.  For example, I’m not yet sure how to use the ldapclient command to modify the LDAP client profile (Solaris 10 doesn’t use nss_ldap by default) to include the refined group query.  I suspect that this command would work correctly:

ldapclient mod -a serviceSearchDescriptor=group:dc=example,dc=com?sub
?&(objectCategory=group)(gidNumber=*)

Of course, the ldapclient command syntax would change depending upon if this was an initial setup or a change to an existing setup.

Likewise, I’m not sure which login attribute the Solaris LDAP libraries are looking for—uid, sAMAccountName, or something else entirely?  If anyone with more Solaris 10 experience than me has the answers to these questions, I’d love to know.

As I continue to expand my knowledge of using Kerberos to integrate these various platforms and applications, I’ll post additional information here.  I know that a number of you have been posting questions in the comments for these various articles; keep the questions coming.  I may not know the answer right away, but I’ll sure do my best to find out!

To use this procedure, you’ll need access to the Directory Service command line tools (these come installed automatically with Windows Server 2003) and Microsoft Log Parser.  With these two tools in hand, let’s proceed.

First, we’ll need to obtain a list of all the CNs in Active Directory for every user and/or every contact, regardless of their container.  It may be possible to do this with Log Parser (using the ADS input format), but I couldn’t figure out how.  Instead, I turned to the Directory Service command line tool dsquery.  Here’s the command to use:

dsquery * “dc=example,dc=com” -scope subtree
-filter “(|(objectCategory=user)(objectCategory=contact))”
-limit 0 > output-file.txt

This creates a file (“output-file.txt”) with a list of the CNs for every user object and contact in your Active Directory domain (obviously, you’ll need to substitute the correct values in the query statement above—unless your domain is called example.com).

Using this file, then we use Log Parser to list only those CNs that occur more than once in this file.  This will identify those objects that have the same name in the domain:

logparser -i:TEXTLINE -stats:off -o:NAT -rtp:-1
“SELECT Text AS objName, COUNT(*) FROM output-file.txt
GROUP BY Text HAVING COUNT(*) > 1” > duplicates.txt

This produces a text file that lists each CN which is found more than once in the input file, along with a count of how many times it was found.  Use this file to go to Active Directory Users and Computers, find the duplicate objects, and rename them as needed.  You can then repeat the process until you don’t find any more duplicate names.

While this may seem like overkill for smaller Active Directory installations, this is certainly very applicable in larger organizations, particularly those with decentralized IT operations.  Think about it—would you want to manually search through 15,000 objects to find the duplicates?

I make no secret of my preference for Mac OS X; in the past, I’ve written about why I chose to use a Mac and my preferred Mac OS X-based applications, including a fair number of open source applications for the Mac.  I’m also not afraid to speak up about what’s wrong with Mac OS X, and to speak out against the misconceptions that many Mac users have.

On Friday, though, I was reminded again of why I love the Mac.  At one point in time, here’s a quick snapshot of what was going on with my Mac:

• On one virtual desktop (I use VirtueDesktops), I had Cyberduck, an open source SFTP client, transferring an ISO image to a VMware ESX Server host.
• On another virtual desktop, I had a couple of Remote Desktop sessions open to some Windows Server 2003 R2-based servers (multiple Remote Desktop sessions made possible by RDC Menu).
• On that same virtual desktop, I had a nested X session running from a virtualized server running Solaris 10, thanks to Mac OS X’s X11 support.
• Neatly tucked away on yet another virtual desktop was my web browser, RSS reader, and Cocoalicious, a native del.icio.us client.
• Just a hotkey away was Quicksilver, ready to do my bidding—opening applications, manipulating data, composing email messages, etc.  (Side thought:  I’m getting more into the hang of using Quicksilver…used it today to control iTunes running in the background.  Handy!)
• Minimized to the Dock was the Kerberos application, which allowed me to obtain a Kerberos ticket from an Active Directory domain; that ticket then granted me single-sign on to any Windows-based shares in the domain(easily mounted on the desktop with a quick Cmd-K keystroke).
• Finally, a Spotlight window sat there showing me all the documents for a particular project I’m working on right now, neatly gathered together regardless of file system location or file type.

Earlier that afternoon I had mounted an NFS volume hosted on a NetApp device (again utilizing a Kerberos ticket, so no password was required) and had both NFS and CIFS volumes sitting on the Desktop.  This in addition to the RDP sessions to the Windows servers, the X11 session to the Solaris server, SSH sessions to various Linux servers (including SSH tunnels), and all the other various applications running.  Honestly, I can’t recall being that connected to that many different systems using that many different protocols when I used Windows.  (That’s not a knock against Windows, just an observation.)  I love the Mac!

This MSRC blog posting outlines the patches that were released last Tuesday, and provides links to the security bulletins for each patch.

<aside>An interesting statistic:  according to this article, Microsoft has released more patches in the first 8 months of 2006 than in all of 2004 and 2005 combined.  I don’t know if that makes me feel more secure—in that they are patching more vulnerabilities instead of not patching them—or less secure.</aside>

The MS06-040 bulletin is the one critical patch that is really getting everyone’s attention; this is the one that is deemed to be “wormable,” capable of creating a self-replicating worm such as Blaster or Slammer.  In fact, there were reports of limited attacks using the exploit patched by MS06-040.  According to a follow-up posting on the MSRC blog, these attacks were limited in nature and only affected Windows 2000 (see this MSRC posting as well).

Fortunately, the MS06-040–based attacks are fairly straightforward to defeat, especially for traffic coming from the Internet.  By blocking TCP ports 139 and 445 at the perimeter, these attacks are defeated.  Of course, that does nothing for the kind of internal infections that were so common with Blaster (which was often carried in by a laptop and then spread behind the firewall).  This article has more information on protecting against the MS06-040 attack.

One other patch (examined in more detail here) fixes the zero-day PowerPoint exploit that garnered attention back around the middle of July.

Because exploit code already exists for both of these vulnerabilities, many security experts are recommending that organizations give priority to getting these patches rolled out to affected systems.

As with the procedure for authenticating Linux against Active Directory and providing Kerberos-based SSO with Apache, there are a few steps to be performed.  Some of these steps are performed on the Active Directory side, some of them are performed on the Solaris 10 system.

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.

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 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 with Solaris.

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 my updated Linux-Windows Server 2003 R2 integration instructions, linked above.)  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.  (Note that this is different than the instructions provided for integrating Linux.  I have an article planned to discuss this in more detail, but for now just trust me.)  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 ready to move on to configuring the Solaris servers themselves.

Configuring Solaris (Each Server)

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

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
        verify_ap_req_nofail = false

[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
        }

Your particular information will need to be supplied here, of course, so you can’t simply copy and paste from here to the Solaris configuration file.

Of particular interest here is the “verify_ap_req_nofail = false” parameter.  I’m still shaking out some TGT validation/verification errors, and this is currently the only way to make authentication work from Solaris.  As soon as I get the validation/verification problems sorted out, I’ll post a new version of these instructions.

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.

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

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.

How I Tested

I tested this configuration using Solaris 10 x86 6/06 (the June 2006 release) running as a VM under VMware ESX Server 3.0.0.  Authentication was performed against a pair of virtual servers (one hosted on ESX 3.0.0, the other on ESX 2.5.3) running Windows Server 2003 R2, Standard Edition.

I won’t go into all the gory details, because I don’t want to speak ill of any person.  Suffice it to say that events transpired in my church that led to the departure of a respected member, someone who had shown Christ in his/her actions every step of the way.  If you’re a Christian, you know the kind of person I’m talking about—he/she is the one that you really respect, that you can just tell His Presence is with him/her.  He/she is the one that you can always trust to be honest with you, even when the truth is not what you want to hear.  He or she is that person that always speaks respectfully of others, even when in strong disagreement with those others.  This was the kind of person that left our church, and in my humble opinion our church is lessened by his/her departure.

This person shared with me his/her account of the events leading up to the departure, well before that departure was ever a possibility.  They knew that something was amiss, and months before these events ever came to light, I knew about them.  I have no reason not to believe that the information shared with me was anything other than the truth; this person’s character speaks for him/her.  Again, this was the kind of person whose integrity and character was borne out in every aspect of their life and their personality.  So, here I have one story, from a godly person I trust and can clearly see God’s work in his/her life.

However, others in the church have a very different view of what happened, and their story is very, very different.  Not just different as in a few changed details, but different as in drastically and dramatically different.  (Sorry, a few too many instances of the word “different” there.)  These people also claim to be Christians, and they’re typically there every Sunday, singing and worshipping in church.  But you don’t get the same feeling from them.  You don’t get the same sense of God’s Presence in their lives, and you don’t see their impeccable character in the words and in their deeds.  Yes, they work hard in the church, and yes, they give off the appearance of being a Christian.  But deeper down, does Christ really live?  When rumors are spread behind your back, is Christ in that?  When hurtful words are spoken and no remorse is shown, is Christ in that?  When hatred shows in your eyes, is Christ in that?  Yes, I know that we all slip up and let Satan get the best of us.  I know that.  Even then, God’s convicting Holy Spirit is there, to speak to us, to tell us that we shouldn’t have said the hurtful things we said.

Sorry, I digress.  Anyway, there was a meeting tonight at the church, to try to reconcile these two very different stories of how this event (the departure of this respected member) came to pass.  People were hurt, people were offended, people were insulted by the way this event transpired, and the idea behind this meeting was to clear up those misconceptions.  Unfortunately, the meeting devolved into a smear session, many people seeking to somehow tear down and hurt others instead of seeking to find the truth.  My wife was insulted and hurt, deeply, by the comments of others—where is Christ in that?  Where is the love of Christ in that?  And again, there were these two different stories, two different accounts, two different histories presented by two different people, both claiming to be telling the truth and both claiming to be Christians.  It was impossible for them both to be telling the truth; one of them had to be a liar.  But which one? Who should be believed?

In the end, the choice was far easier than I thought it would be.  It’s easy to talk the talk, but it’s not so easy to walk the walk.  There’s a saying my kids are so tired of hearing me say—“Actions speak louder than words.”  When I tossed aside the words, when I tossed aside the appearances, and when I really looked down inside, in whom did I see Christ?  In whom did I see the love of Christ?  In whom did I see respect and courtesy for others, even in the midst of disagreement?  In whom did I see restraint of the tongue?  Most of all, in whom did I see compassion?  That is the person to be believed, for their actions speak far, far louder than their words.

This posting may not make any sense to you; that’s OK, because I mainly wrote it for myself.  Consider it my donation to the many pages on the Internet that appear to be written in selfish vanity.  Mainly I needed to get it out, to work through the events, to work through the spiteful words and the hateful looks, to work through the self-righteous indignation, and find Christ in one of these two people.

If you are not a Christian, you’re probably reading this thinking, “Ha!  I knew all those Christians were phony hypocrites.”  No, not all of us.  Many, but not all.  Please, don’t let the actions of a few turn you away.  There are some of us who put aside the fancy words, who put aside the phony appearance, and instead seek to be Christian—“Christ-like”—in our actions, in our character, in our speech.  Then, when you look deeper, you’ll know who to believe, and you’ll find Christ, too.