SSH

I ran across this handy white paper about OpenSSH on Linux using Kerberos authentication with Windows and Active Directory. There’s not a whole lot in there that isn’t also covered in my Active Directory integration notes, but it is useful information nevertheless.

It’s that time again, friends, time for another Virtualization Short Take!

• OpenSolaris on Fusion: As expected, Solaris/OpenSolaris fans are experimenting with OpenSolaris on Fusion. Apparently, it runs rather well.
• Brian Madden had an interesting thought about Thinstall (now ThinApp) plus WINE to eliminate Windows. In the end, Brian feels like many companies will just want to deal with the larger vendors, and won’t be willing to support this kind of “cobbled together” solution. The idea of using ThinApp on WINE on a non-Windows operating system is a pretty cool idea, but it may be a bit early for its time.
• Microsoft Hyper-V made it to RC1, apparently ahead of schedule. I wonder if they will try to make RTM in time for TechEd in Florida in June? In addition, Microsoft also released information about how they are “eating their own dog food” and using Hyper-V for the MSDN and TechNet web sites.
• Citrix has released XenDesktop 2.0, their VDI solution. Alessandro has a fairly complete breakdown of the components involved in the solution and the various editions under which it will be released. A lot of these components are pre-existing products that are being rebundled into XenDesktop; XenApp (Presentation Server) and Provisioning Server (Ardence) are two examples. VMware came out with a competitive response almost immediately, and Gareth dissected that response on DABCC. Having not actually installed XenDesktop yet, I don’t know how integrated—or not integrated—the various components are, so I’ll reserve judgment until later. I have my beefs with VDM; in particular, I don’t like how it mandates VM provisioning in order to use pools. I hope that Leostream’s removal of their P>V product as reported by Alessandro doesn’t portend dark days for Leostream.
• According to Tony Asaro at Virtual Iron, Citrix’s release of XenDesktop signals the beginning of a “shift” in focus from server virtualization to desktop virtualization. One must consider this comment in the context of who is providing the comment; Virtual Iron is, of course, a competitor in the server virtualization market whose product is also based on the Xen hypervisor. Besides, even if that is true, so what? Citrix has made an existence out of focusing on client-side application delivery. This would be completely logical, in my mind, and would allow Citrix to focus on an area where they are strong instead of competing in a market where they are weak.
• Lou Springer brings us a method of connecting to a VM’s console using VNC over SSH from Mac OS X. I’d seen references to using this with VMware Server, but didn’t know that it worked with VI3. Thanks, Lou! (Lou’s trick was based on information from this VMware KB article, by the way.)
• From IPMer, here’s some information on using VMware Converter to assist with VM snapshots. This was picked up by Rich over at VM /ETC and also included in the first-ever VMware Communities Roundtable podcast (which I’ve downloaded but not yet had the opportunity to actually review yet).

That’s it for today. I hope that everyone has a great Memorial Day. Don’t forget to thank a veteran or active serviceman/servicewoman for your freedom!

At the start of 2007, I wrote a pair of articles on Mac FTP/SFTP clients, lamenting the performance of the open source Cyberduck application and eventually settling on Interarchy as my replacement product.

Quite a bit has happened since that time, and I now find myself in a bit of a quandary. Cyberduck has replaced the underlying file transfer engine to dramatically improve overall throughput, and Interarchy has “refined” the user interface to make it look more Mac-like. Unfortunately, in the process, Interarchy has become downright ugly. I don’t like the ugly chiclet buttons in Leopard’s Finder, I don’t like them in Safari, and I don’t like them in Interarchy, either. I very much prefer “old school” color icons in the toolbars.

Given that the new Interarchy interface was really bugging me—the Finder, at least, is still usable when you turn off the sidebar and close the toolbar—I thought I’d try Cyberduck again. Simple, one-file performance tests showed that Cyberduck, with the option to transfer files via SCP enabled, was coming much closer to matching Interarchy’s performance; Interarchy remained in the lead for raw performance, however. I figured that I could live with the performance degradation for most tasks, and started trying to use Cyberduck whenever possible.

Until tonight, that was. I needed to transfer a large number of smaller files up to one of my web sites, and Cyberduck simply dragged. I guess it’s the method whereby Cyberduck manages connections that slowed down the process, since it appeared that it checked the connection to the server for each file it was transferring. In any case, I’ve found that it looks like I’ll just have to suffer through Interarchy’s new look; the alternative is just too slow.

I’m posting this stuff here on the off chance that it someday might be useful to someone out there somewhere. About four years ago, I had a wild hunch to start learning Novell NetWare 6.5, and to perform some integration testing with some other technologies with which I was already familiar. Along the way, I gathered these notes. I make no warranties about the accuracy, validity, or relevance of this information; I’m just publishing it here in case it may prove useful later. (You never know.)

So, that being said, here are the notes:

• SSH “shell” access to NetWare 6.5 server: The SSHD NetWare Loadable Module (NLM) had to be loaded first. Attempts to login failed; the sshd_config file had to be edited and a Novell-specific directive (eDirNameContext) had to be modified in order to add the context where the admin account was stored (in this case, OU=Users.O=Company). After the configuration file was modified and the SSHD NLM unloaded and loaded again (to reflect the changes to the configuration file), logins via SSH were successful. (Note: It appears that NetWare 6.5 does not support the Blowfish-CBC cipher.)
• SFTP access to NetWare 6.5 server: After successful SSH “shell” access (see previous bullet point), SFTP access also worked correctly. Tests using Fugu (a native Mac OS X SFTP application) were successful and without any major events or problems. In fact, SFTP was used to transfer the files necessary for the VNC testing (see next bullet point) to the NetWare server.
• VNC access to NetWare 6.5 console: Using SFTP, a VNC server NLM was copied to the server. After setting the VNC password (using VNCPASS.NLM) and loading the VNC server (VNCSRV.NLM), access to the NetWare server’s GUI via VNC was successful. The VNC client used was Chicken of the VNC, a freeware Mac OS X VNC client. Performance was on par for LAN access to a server.
• Native file access from Mac OS X: As indicated in several online sources, the AFPTCP NLM had to be unloaded and then reloaded with the CLEARTEXT option. Then the SYS volume on the server could be mounted using the Go To Server command. After an initial login, the AFPTCP NLM was unloaded and reloaded without the CLEARTEXT option, and everything continued to work just fine.
• Rconsole access from Mac OS X: Using RconJ, a Java-based port of Rconsole to Mac OS X, Rconsole access was successful. The RCONAG6 NLM had to be loaded first on the server in order for this to work.
• VNC inside SSH tunnel: Creating SSH tunnels (using the –L switch) works in NetWare 6.5 just as it does with Linux or OpenBSD. Using the VNC NLM discussed earlier and an SSH tunnel, the VNC traffic was secured and encrypted across the wire. This worked exactly as expected.
• Native file access from Windows XP: Initial attempts to access the server from a Windows XP system failed (authentication problems). The NDS user object had been created in iManager and a simple password had also been created in iManager as well (necessary before CIFS will work). However, the cifsctxs.cfg file (that specifies contexts) had not been updated with the correct context (OU=Users.O=Company, which is where all user objects are stored). After modifying this file and reloading CIFS, then access from Windows XP still failed (network path not found). Further tests showed that typing the UNC path from the Run command on the Start menu failed, but browsing through My Network Places or typing the UNC path including a share name worked just fine.
• NTP on NetWare 6.5: XNTPD.NLM is an NTP daemon for NetWare, similar in implementation and purpose as NTP on Linux or OpenBSD. Upon editing the NTP.CONF file in SYS:\ETC, XNTPD could be loaded only after TIMESYNC.NLM was unloaded. Even then, XNTPD seemed to unload occasionally and without reason, and the NTPDATE utility had to be used to manually synchronize the time.
• Autoloading specific NLMs on startup: Upon reboot, the VNC, SSH, and Rconsole NLMs weren’t loaded, and so the server was inaccessible except from the console. Using the “rconag6 encrypt” command, a LDRCONAG.NCF file was created with an encrypted Rconsole password. Then, AUTOEXEC.NCF was edited to reference this file (in order to load the Rconsole agent) as well as the SSH and VNC NLMs. This would ensure that the necessary NLMs were loaded every time the server booted.
• Universal passwords: After some difficulty mounting a volume from Mac OS X, setting passwords, and such, the server was rebooted and Universal Passwords were enabled for the Users.Company container. The passwords were then set for various accounts. Following that, native file access from both Mac OS X and Windows XP (with one caveat; see below) worked flawlessly. The caveat for Windows XP native file access is that browsing shares using just the server name in the UNC path does not work; at least one share name must also be included (i.e., \vsninteg does not work, but \vsninteg\sys works just fine). SSH access worked fine after enabling universal passwords. SFTP access worked fine as well, as long as the user logging in had sufficient permissions.

OK, there you go. Here’s hoping it may prove useful to someone. Feel free to correct me, clarify these notes, or just tell me I’m crazy in the comments below.

If you’ve been reading my blog for any reasonable length of time, you already know that I value the Mac OS X-only utility Quicksilver.  It took me some time to get accustomed to it, but I quickly found it indispensable.  Since that time, I’ve been staying alert for new plugins that will help make my life easier.

So imagine my delight last night when I came across this SSH plugin for Quicksilver (updated version available here).  The plugin allows you to make SSH connections to remote hosts, cataloging the known_hosts file along the way to make it easier.  Since I use SSH a lot—it seems like I’m constantly opening an SSH session up to a Linux, Solaris, or ESX Server machine—this plugin is tremendously helpful.  If you use SSH and Quicksilver, I highly recommend this plugin.

Quite a few organizations implementing VMware Virtual Infrastructure 3 (VI3) are not organizations with a great deal of non-Windows experience.  Given that the Service Console is based upon Red Hat Enterprise Linux, this is often a completely new environment for them that introduces unfamiliar processes and applications.

Take the process of copying files, for example.  To an administrator within an organization that is primarily Windows-based servers, the idea of not being able to “map a drive” or just use a Universal Naming Convention (UNC) path is unbelievable.  For someone like myself, who has lived in a non-Windows world for a number of years now, the idea of using SCP/SFTP to copy files to a server seems pretty normal.  Nevertheless, these new VMware administrators must now get accustomed to doing things a bit differently than they have in the past, and the use of an SCP/SFTP client is one of those things.

One big problem with the use of SCP/SFTP clients is granting SCP/SFTP access to a user typically also grants shell access.  This is a problem not only for new users but also for experienced users.  New users may get into the shell and change things that shouldn’t be changed, simply because they don’t know; experienced users may get into the shell and change things that shouldn’t be changed, because they think they do know.  Either way, shell access is something to be avoided where possible, in my opinion.

The solution?  Use an “alternative” shell called scponly:

scponly is an alternative ’shell’ (of sorts) for system administrators who would like to provide access to remote users to both read and write local files without providing any remote execution priviledges. Functionally, it is best described as a wrapper to the tried and true ssh suite of applications.

Here’s how I got scponly working on a test server running ESX Server 3.0.1 in the lab.  Please keep in mind that this method is most likely not supported by VMware, so proceed accordingly.

1. Download the scponly and rsync RPM packages from the DAG repository.  (The links point to the package page, not the actual package itself, so these are not blind download links.)  I used scponly-4.6-3.el3.rf.i386.rpm and rsync-2.6.8-1.el3.rf.i386.rpm, the packages for Red Hat Enterprise Linux 3, since the Service Console is derived from RHEL 3.
2. As root, first install the rsync package with the rpm command.  Something like this should work:

   rpm -Uvh rsync-2.6.8-1.el3.rf.i386.rpm

3. After installing rsync, install scponly:

   rpm -Uvh scponly-4.6-3.el3.rf.i386.rpm

4. Edit the /etc/shells command to include the scponly shell, which in my testing was installed to /usr/bin.  You can simply append /usr/bin/scponly to the end of /etc/shells.

At this point, you should be able to create a user and set the user’s shell to scponly.  This will allow the user to use an SCP/SFTP client to transfer files, but it will not allow interactive shell access.

To test this, I used three file transfer methods:

• Interarchy, a Mac OS X application, via the SFTP protocol
• Command-line SCP from my Mac
• WinSCP on Windows XP, via both SFTP and SCP

In all three cases, I was able to successfully authenticate and transfer files, but I was not able to get access to the shell via SSH.  I would imagine that a determined individual could probably get by scponly, but in this instance we are only using it to provide a layer of protection for the shell.  For that function, it works well.

Although much of the administration of servers running VMware ESX Server 3.0 will occur in the Windows-based Virtual Infrastructure client connected to a VirtualCenter server, there are times when it is quicker or easier to perform an administrative task directly on the ESX Server itself—either via the command-line interface (CLI) or via the VI client authenticating directly against the ESX Server.  The problem with this is that, by default, administrators will have to use different credentials when connecting the VI client to ESX Server directly.  In addition, these credentials must be managed separately from Active Directory, and separately on each individual ESX Server.  As the number of ESX Servers in a farm grows, this can quickly become an administrative nightmare.

Fortunately, we can fairly easily integrate ESX authentication into Active Directory, so that the same account used in VirtualCenter is also used when logging in to the ESX Server directly.  While VMware took the step of automating a portion of this process for us in the esxcfg-auth command, it only takes us part of the way.

Let’s take a look at what part esxcfg-auth does accomplish for us, then look at how to accomplish the rest of the task.

Using esxcfg-auth

The esxcfg-auth command will help automate a good portion of the work required to integrate ESX Server into Active Directory; specifically, it will automate the Kerberos configuration.  To use esxcfg-auth to enable AD authentication, use the following command (lines are wrapped for readability; the backslash indicates line continuation):

esxcfg-auth --enablead --addomain=example.com \
--addc=dc1.example.com

Obviously, you’ll want to substitute the appropriate values for “example.com” and “dc1.example.com” on the command above.  So what does this command do, exactly?  Here’s the breakdown:

• Modifies the /etc/krb5.conf file to use example.com as the default Kerberos realm, and to use dc1.example.com as a KDC for that realm.  In this same file, the domain “example.com” is mapped to the realm “EXAMPLE.COM” (keep in mind Kerberos realms are always specified in UPPERCASE).
• The /etc/pam.d/system-auth file is modified to use pam_krb5.so for Kerberos authentication.

What does this command not do?  Well, for one it doesn’t configure the ESX Server for anything other than pure authentication.  This means that although users will be forced to authenticate against Active Directory, ESX Server still expects to find the accounts defined in the local /etc/passwd file.  This means that password management is centralized, but account management is still decentralized.  (Some might see this as a security advantage, in that we must manually define an account in order to allow that account to log in to that server.)

To fully centralize account management, we’ll need to step outside of the esxcfg-auth framework and get our hands dirty.  Ready?

Finishing esxcfg-auth’s Work

To fully round out the authentication/account management configuration, Active Directory will have to be made aware of some UNIX-specific attributes.  This means extending the schema.  If you are running Windows 2000 or Windows Server 2003 pre-R2, this means installing Services for UNIX (SfU) 3.5; for Windows Server 2003 R2 or later, this means installing Identity Management for UNIX.

I’ll refer you to this article for Windows 2003 and Windows Server 2003 pre-R2 and this article for Windows Server 2003 R2 or later for more information.  (Because the ESX Server service console is based on Red Hat Enterprise Linux, these Linux-AD integration guides are very applicable here.)

Once Active Directory has been configured, the only tasks left for us to do are 1) to configure the nss_ldap libraries; 2) to configure /etc/nsswitch.conf to enable LDAP for naming services; and 3) verify time synchronization.

To configure the nss_ldap libraries, you’ll need to modify the /etc/ldap.conf file as described in Step 5 of the “Prepare Each Linux Server” section of this article (assuming you are using Windows Server 2003 R2).  This sets up the connection to Active Directory via LDAP and configures the attribute maps accordingly.

Please note that you’ll need to create an account in Active Directory (a Domain Guest is fine) that the nss_ldap libraries may use for LDAP queries.  You’ll specify that account information when configuring /etc/ldap.conf.

Next, you’ll need to configure /etc/nsswitch.conf.  You only need to modify the passwd, group, and shadow lines, and you only need to add “ldap” at the end of the lines.  The lines will end up looking something like this:

group:    	files ldap
passwd:    	files ldap
shadow:    	files ldap

At this point, you should be able to test the nss_ldap configuration.  Run “getent passwd <AD user account>” and you should get back information about that account’s home directory, login shell, UID, and name.  If you don’t get back any information, go back and double-check your configuration.

To verify time synchronization, have a look at the NTP configuration found in /etc/ntp.conf.  Make the changes you need here to be sure that both Active Directory (the forest root PDC emulator, specifically) and ESX Server are both synchronizing time and will stay in sync.  Otherwise, the Kerberos authentication process will fail.  Keep in mind that you may need to adjust the Service Console firewall using esxcfg-firewall in order to allow the appropriate traffic outbound.  (Thanks to KentA for reminding me about this step!)

Once “getent passwd” is working as expected and time is in sync, then you should be able to SSH into the ESX Server with any appropriately configured AD account (i.e., any AD account that has the “UNIX Attributes” tab completed with valid information).  This gives you a similar level of control over who is allowed to login and who isn’t; accounts that don’t have any UNIX attributes won’t be able to authenticate and gain access to the ESX Servers.

In addition, you should be able to configure some level of access control as described here.

Summary

To summarize, the process for integrating ESX Server into Active Directory looks like this:

1. Use esxcfg-auth to set up the Kerberos authentication.
2. Extend the AD schema (if necessary) to include UNIX attributes such as login shell, UNIX home directory, UID, UID number, etc.  This is accomplished in different ways depending upon the version of Windows in use.
3. Populate the UNIX attributes for those user accounts that should be allowed to access the ESX Server(s).
4. Configure /etc/ldap.conf on the ESX Server to configure LDAP connectivity back to Active Directory for name service lookups.
5. Configure /etc/nsswitch.conf to use LDAP for name service lookups.
6. Verify (and configure, if needed) time synchronization via NTP on the ESX Server.
7. Test the configuration using “getent passwd” or “getent group” or both.

This configuration will centralize not only authentication for the ESX Servers but will also centralize account management in Active Directory as well.

Please feel free to add any corrections or suggestions for improvement in the comments below.  Thanks!

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.

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

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

Preparing Active Directory (One-Time)

Enable Editing/Display of UNIX Attributes

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

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

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

Create an LDAP Bind Account

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

Prepare Active Directory (Each User)

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

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

Prepare Each Linux Server

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

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

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

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

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

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

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

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

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

Test the Configuration

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

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

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

Join the Linux Server to Active Directory

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

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

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

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

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

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

Deal with Home Directories

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

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

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

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

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

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