Linux

I was going through my list of flagged headlines in NetNewsWire and realized that I’d built up quite a list of articles that I intended to write something about.  Some of them just don’t merit a full-blown post, though, so I thought I’d just toss a bunch of them in here along with a brief sentence or two about them:

• VMTN Discussion Forums: vdiskmanager GUI for OSX:  An enterprising Fusion user has written an OS X GUI for vdiskmanager, so that VMDKs on Fusion can be expanded or defragmented, or new virtual disks can be created.  I haven’t tried it yet, but it looks like it could be extremely useful, and it’s nice to see Fusion users creating useful utilities like this.
• Running ESX 3i Beta in a VM with VMware Fusion:  Still thinking Fusion, this article discusses how a user managed to get ESX Server 3i (the beta version obtained at VMworld 2007) running as a VM under Fusion.  There’s also information on running it under Workstation 6 as well.
• Tech: How to get the command line in ESX Server 3i beta:  Turns out ESX Server 3i has a command line after all, based on BusyBox.  Richard Garsthagen has more information about ESX 3i available at run-virtual.com.  Also see Eric Sloof’s info on boot options.
• Storm Worm Botnet Attacks Anti-Spam Firms:  Is this botnet really as massive as everyone says?  I’ve been seeing so many articles about the Storm botnet, but I have yet to see (perhaps I haven’t looked hard enough yet) definitive information that describes the type of traffic these bots generate.  Surely there’s got to be something we can do about this.
• Microsoft Updates Windows Without User Permission, Apologizes:  Oh, goodness—where do I start with this one?  Let’s just say that I’m glad I’m using Little Snitch, which catches this kind of outbound traffic that so easily slips through the Windows “firewalls” onto the Internet. Otherwise, I might be getting product updates without anyone bothering to tell me so.  (And perhaps it’s just me, but an apology from Microsoft doesn’t make me feel any more trusting of them.)
• NFS vs iSCSI vs FC:  More information on why we should be interested in running VMware over NFS.

I guess that’s all for now, as it’s getting late and I have to get up in the morning and go to church.  Feel free to share any comments or corrections below.  Thanks for reading!

Regular readers of this blog know that I like to work on integrating various systems into Active Directory.  I’ve written a couple of articles on the issue:

Linux-AD Integration, Version 4
Solaris 10-AD Integration, Version 3
Active Directory Integration Index

These articles have been pretty successful and from what I understand have helped a fair number of people integrate their non-Windows systems into Active Directory for simplified user management and authentication.  Occasionally, though, we run into the odd issue that isn’t quite so straightforward to resolve.

For example, I recently had a reader (let’s call him Johnny) who was having a difficult time getting the Linux-AD integration to work.  The “ldapsearch” and “kinit” commands worked fine, but “getent passwd” or “getent group” failed with no output.  The users in Active Directory did indeed have UNIX attributes added to their accounts.  There were no firewalls between the non-Windows systems and the Active Directory domain controllers, and there did not appear to be any connectivity issues whatsoever (this further underscored by the fact that “ldapsearch” successfully returned LDAP search results from AD, and “kinit” successfully obtained a Kerberos ticket from AD).  We were stumped.

Johnny and I traded e-mails back and forth a few times, until finally Johnny found his error and notified me about what had been happening.  As I read the description about the problem, I realized that this may be a problem that is affecting a lot of users, and may, in fact, have stumped some of you out there reading right now.  Here’s the details.

The method that I suggest using for AD integration uses two parts:

• First, we use Kerberos to obtain a Kerberos ticket from an Active Directory domain controller (also a Kerberos key distribution center, or KDC).  This handles the authentication side of things and prevents the password from crossing the wire at any point in time.
• Next, we use LDAP to centrally store account information, such as UID number, GID number, home directory, login shell, etc.  This is the part that typically requires schema extensions (although there is a workaround for that) and using this technique ensures that we don’t have to manage accounts individually on each Linux server.

This approach doesn’t work without both pieces.  The Kerberos authentication takes care of the password, but without account information logins still fail.  So if Kerberos works but LDAP doesn’t, logins will fail.  If Kerberos doesn’t work but LDAP is fine, logins will fail.  So part of troubleshooting this configuration is isolating where the problem lies.  In this particular case, “kinit” worked fine—no error was returned and “klist” showed a valid Kerberos ticket.  So the problem had to be with LDAP.  But where?  The “ldapsearch” command worked fine.

The problem lie with the /etc/ldap.conf file.  See, the nss_ldap libraries (which are responsible for using LDAP—and other sources, as defined in /etc/nsswitch.conf—as the backend information database for account information) are controlled by this file, but “ldapsearch” does not use it.  Specifically, the error was with the account that is used to bind (or connect) to Active Directory to perform the searches.

There are two ways of specifying this account in /etc/ldap.conf.  You can use the full DN, which looks something like “cn=Scott Lowe,cn=Users,dc=example,dc=com” or “cn=John Smith,ou=Marketing,ou=Departments,dc=example,dc=com”.  Alternately, you can use the universal principal name (UPN), which looks something like an e-mail address, such as “slowe@example.com” or “john.smith@example.com”.  In this particular case, Johnny (our reader with the problem) was using the full DN, but he was using the wrong attribute in the DN.  Here’s the information he had:

First Name: John
Last Name: Smith
Full Name: John Smith
Display Name: John Smith
UPN: jsmith@example.com
SAM Account Name (downlevel logon name): jsmith
Object name: jsmith

Which of these do you suppose should be used in the DN?  Full name?  No.  Display name?  No.  It must be the object name, in this case “jsmith”.  You can double-check your object name (or CN) using ADSI Edit or a similar utility.  You could use Active Directory Users and Computers, but that’s typically the confusing part.  In any case, once Johnny fixed the syntax for the bind account then “getent passwd” and “getent group” worked like a champ.

How do we avoid this kind of issue?  Simple: just use the UPN instead of the full DN.  This syntax works just as well and avoids the potential problem of using the wrong name when building the full DN.

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

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

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

As a systems engineer for a value-added reseller/systems integrator, I’m often called upon to perform both pre-sales work as well as post-sales work.  I do a lot of work with VMware (in case you hadn’t guessed by now!), and so a lot of the pre-sales meetings in which I am involved often center around VMware, its product offerings, and the benefits that virtualizing with VMware can offer a customer.  One question that frequently arises during these kinds of meetings is, “Isn’t VMware based on Linux?”

What the potential customer is really asking is, “Is VMware ESX Server based on Linux?”, of course, and the proper party-line answer is that no, it’s not based on Linux, that the vmKernel—the hypervisor at the heart of ESX Server—is custom, proprietary code written by Mendel Rosenblum and others when they founded VMware back in the mid-1990’s.  Yes, there is a Linux component to ESX Server called the Service Console, but it’s used to provide an interface to the vmKernel.  And when given that answer, customers nod in understanding and we move on.  But is that the correct answer?

If you ask VMware, you’ll be told that you gave the correct answer.  But if you ask Christopher Hellwig, Linux SCSI storage maintainer and a top 10 contributor to the Linux kernel, he’ll say that’s not the correct answer.  Instead, he’ll insist that because vmKernel relies upon the Linux kernel in order to load, it is therefore a “derived work” and must fall under the same license as the kernel, GPLv2.  So who’s correct?

In truth, this is a very complicated matter.  I’ll refer you to this VentureCake article titled “The VMware house of cards” for more details on the issue, as well as some links to additional information and viewpoints on the article.  And perhaps just as helpful as the article are the comments to the article, which include a response by Alan Cox (another Linux kernel maintainer) and a response by Zach Amsden of VMware (although he does not speak for VMware officially).  Go read that article and the comments, then come back here.

OK, done reading that article now?

As you can see from the VentureCake article, it’s a fairly in-depth issue that has no clear answers.  The true underlying issue, as I understand it, is this:  Does vmKernel require the Linux kernel in order to boot?  If so, if VMware can’t show that vmKernel has “a life outside of Linux”, then ESX Server is in violation of the GPL.  If not, if VMware can show that vmKernel does not require the Linux kernel in order to operate or load, then all is well.  The problem here, of course, is that only VMware knows the answer to this question, and any answer they provide will be suspect because people will believe they are covering up the truth.

Consider this excerpt from Zach Amsden’s comment:

First, the vmkernel is not a Linux kernel module. The vmkernel is a completely isolated and separate piece of software which is loaded by a module called vmnix. The vmkernel has no knowledge or understanding of Linux data structures or symbols, and as a necessary result, does not depend on the Linux kernel for any services whatsoever.

This would seem to pretty clearly dispel the idea that vmKernel relies upon the Linux kernel.  However, consider this response from the article’s author:

If vmkernel is not ported from another OS and indeed depends on Linux to load (not run), by Linus Torvalds’ logic vmkernel is a derived work. Whether vmkernel continues to depend on Linux after it has loaded or not is irrelevant, if Linux copyright had to be infringed to start vmkernel in the first place.

So, because Zach didn’t say that vmKernel doesn’t rely upon the Linux kernel to load (instead only that it doesn’t rely on the Linux kernel to run), then the underlying question at the core of this issue still isn’t answered.  Some would say that people are being too picky, too selective in their interpretation of the words being used, but I suppose that in a delicate situation such as this that may be necessary.

The VentureCake article quotes Linus Torvalds a couple of items as it pertains to how we determine if a binary module for Linux should fall under the GPL:

The reason I accept binary-only modules at all is that, in many cases, you have, for example, a device driver that is not written for Linux at all, but, for example, works on … other operating systems, and the manufacturer … wants to port that driver to Linux. But because that driver was obviously not derived from Linux (it had a life of its own regardless of any Linux development), I didn’t feel that I had the moral right to require that it be put under the GPL, so the binary-only module interface allows those kinds of modules to exist and work with Linux.

And again:

I personally consider anything a “derived work” that needs special hooks in the kernel to function with Linux (i.e., it is not acceptable to make a small piece of GPL-code as a hook for the larger piece), as that obviously implies that the bigger module needs “help” from the main kernel.

One question that comes up in my mind is this: what is meant by the term “load”?  The VentureCake article keeps indicating that it’s irrelevant what happens after vmKernel is initialized:

It’s possible to ditch, remove, or crash Linux after vmkernel has virtualized it - but you wouldn’t be able to get to that stage without Linux being used to load vmkernel.

In my mind, the clearest application of Torvalds’ logic of what makes a binary module a “derived work” (and therefore subject to the GPL) is not only whether it requires the Linux kernel to load, but also whether it requires the Linux kernel in order to run.  Of course, I’m not a lawyer, not a kernel developer, and not a Linux expert (I’m not really even a VMware expert, despite what people say), so what I have to say about the matter doesn’t really exist.  And despite what people like Zach say, I also suspect that the open source community won’t be happy until VMware open sources the vmKernel and they can look for themselves to see whether or not the Linux kernel was required by vmKernel.  It seems to me that any other response, however well thought-out and logical, will only be interpreted as political posturing and concealing the truth.

One final question:  Is this controversy helping to drive the development of the so-called “virtualization appliances” that will embed the hypervisor (vmKernel) into firmware, as reported by various sites previously?

UPDATE:  This issue is starting to see broader attention, meriting a comment by Gordon Haff of Illuminata.  His article is, in turn, being picked up by many other news aggregators.

I’ve targeted Solaris (specifically, Solaris 10 on x86) as the next major technology that I’m going to try to learn.  I’ve always been fascinated with UNIX and UNIX-like operating systems such as Linux, and Linux’s popularity on the x86 platform made it much easier to learn because I didn’t have to acquire any exotic hardware.  With Sun’s (apparent) renewed interest in x86/x64, Solaris is much more accessible now than it was in the past.

Obviously, I’m not a complete newbie to the Solaris environment, having written a couple articles on Solaris-AD integration (the latest being found here).  However, I don’t feel like I have a solid understanding of the operating system and its architecture, and I’d feel much more comfortable with that information under my belt.  At some point, the IT industry being what it is, I’ll need to seek some sort of Solaris certification, but that’s not my primary goal.  Understanding the product itself is my primary goal; certification will merely be a side effect.

Here’s what I’ve done so far:

• I’ve created a Solaris 10 (32 bit) virtual machine on my VMware ESX Server farm; that’s been the system I’ve used mostly for testing the Active Directory integration instructions.  I’ve also done some work with the automounter (automounting home directories via NFS).
• I’ve also just recently gotten a Solaris 10 (64 bit) VM running under VMware Fusion on my MacBook Pro; I’ll use that system for more day-to-day operational tasks and getting used to the interface.
• I have a group of Solaris- and UNIX-related RSS feeds in NetNewsWire, including BigAdmin (What’s New and Feature Articles), Inchoate Curmudgeon, and a del.icio.us tag feed, among others.

I’d certainly appreciate any suggestions from those who may have already been down this path as to specific projects I should undertake, books I should acquire, websites to frequent, RSS feeds to which I should subscribe, etc.  In addition, any guidance as to how I should balance Solaris vs. OpenSolaris (on which one should I focus more effort?) would be very helpful.  And what builds of Solaris/Solaris Express are most beneficial to use?  I’m currently using Solaris 10 Update 3, but I’m not sure if a different build would be better to work with.  That’s the kind of information that would be great to get from those wiser and more experienced.

Wish me luck!

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

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

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

Preparing Active Directory (One-Time)

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

Enable Editing/Display of UNIX Attributes

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

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

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

Create an LDAP Bind Account

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

Prepare Active Directory (Each User)

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

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

Prepare Active Directory (Each Server)

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

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

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

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

Prepare Each Linux Server

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

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

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

Test the Configuration

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

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

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

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

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

Deal with Home Directories

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

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

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

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

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

I’ll start out by saying that I am neither a security expert nor a statistician.  With that disclaimer in hand, I wanted to briefly share my thoughts on the “days of risk” assessment that has recently been used to compare the security of Windows, Linux (Red Hat and SuSE), Mac OS X, and Sun Solaris.  Before continuing, I encourage you to have a look at the actual report itself, along with a few related articles:

• Days-of-risk in 2006 : Linux, Mac OS X, Solaris and Windows
• Days of Risk in 2006 : Client OS Products
• Recount: Windows Still Safest, Tops Mac OS X, Linux and Sun Solaris - But are statistics a true measure of security?
• Windows v Linux - Days of risk in 2006

In summary, the Days-of-Risk (DoR) assessment showed that Microsoft patched vulnerabilities in Windows more quickly than Red Hat, Novell, Apple, or Sun patched vulnerabilities in their products.  This is true even when only High Severity issues are taken into consideration, although the gap between Microsoft and the other vendors narrowed in that analysis (with the exception of Sun).

OK, that’s all well and good, but we all know statistics can be made to show just about anything.  I’m not saying that Mr. Jones deliberately limited his data to present a favorable outcome for Microsoft; Microsoft has done a very admirable job of improving their security responsiveness, and in that regard the other vendors would do well to improve their own responsiveness to the disclosure of security vulnerabilities.  No, my thoughts are more centered on the question: Is this data the right data to accurately and objectively represent the security profile of an operating system?

I would contend that, in addition to DoR, information on the following areas would also need to be included in order to more accurately depict an operating system’s security profile:

• Number and severity of exploits published or otherwise made available for vulnerabilities
• Number of viruses, trojans, rootkits, or other malware readily available or in active circulation

Now, before you say something like “Well, of course Windows is going to have more viruses and more exploits because it has a larger installed base!”, let me also say that these values should be correlated and weighted according to the installed base of the operating system as well.  This allows the values to account for the fact that Windows is in use by a much larger base of users than Linux, Solaris, or Mac OS X.

Again, I’m not a statistician, but surely there’s a way to correlate this data (including DoR) and start presenting some sort of objective guide, based on measurable facts, regarding the security of an operating system.  Then the vendors (Microsoft, Apple, Novell, Sun, Red Hat, and others) can stand on equal ground and be able to make some sort of reasonable comparison regarding the security of each product.  Isn’t that what we really need anyway?

While I would love to be able to say that this procedure I’m going to describe for resizing disks inside guest VMs is new or unique or original, I can’t.  I’m sure that lots of smart people out there have been down this path before, and more than a couple of them have probably written up good instructions on how to do it.  I’m including this information here partly for myself (in the event I need it in the future), and partly because the information fits in with a lot of the other information I have here on VMware and related technologies.

So, with that being said, here’s how I recently went about resizing some guest VM disks using vmkfstools and GParted (specifically, the GParted LiveCD).  This process assumes you need to resize a Windows guest.  The process should be very similar if not the same for non-Windows guests, but I haven’t tested it so I can’t be absolutely certain.  The process is very straightforward and not unusual in the least, but feel free to post any corrections or questions in the comments.

1. Download the GParted LiveCD (here’s a direct link) and then upload it to your ESX Server using the file upload tool of your choice.  Being a Mac OS X user, I use Interarchy.  Use whatever best suits you.
2. Power off the VM that you will be manipulating.  (I know, that seems obvious, but still…)
3. Open an SSH session to the ESX Server where your guest VM is hosted.  Switch to root, change into the appropriate directory where the VM is stored, and then run the following command:

   vmkfstools -X <New disk size> <VMDK filename>

   If your current virtual hard disk was 10GB and you wanted to make it 20GB, then specify “20g” on the command line, i.e., specify the new total size of the disk, not the amount by which to increase it.

4. Flipping to the graphical VI Client, change the CD-ROM of the guest VM to be the ISO image of the GParted LiveCD you downloaded earlier.  Make sure it is set to connect at power on.  Power on the VM and boot from the CD.

   Note that booting from the CD can be a bit tricky.  You may need to boot up several times before you catch it just right.  Be sure that if Windows starts booting up, you let it boot up and then shut it back down again.  If you reset the VM in the midst of the Windows boot sequence, the NTFS filesystem will be marked as “dirty” and GParted won’t make the changes you wanted.

5. GParted will boot up from the CD.  You may need to press Enter a couple of times to accept the defaults (unless you need settings other than the defaults, of course) before the graphical environment loads and you see the GParted interface.  Once the GParted interface is up, you should be able to figure out how to make the changes you want to make.
6. Shutdown the VM (you can use the shutdown option in GParted), disconnect the CD-ROM, and power the VM back up again.  When Windows boots, it will run a Chkdsk, then reboot again, and then come up to a login screen.  After you login, you may be prompted to reboot again after the discovery of “new hardware.”  After that final reboot, you should be good to go with a new, larger virtual hard disk.

The most time consuming portion, in my experience, is waiting for GParted to boot from the ISO image.  Otherwise, the entire process is almost completely painless.

Network World published today that Microsoft is reportedly seeking royalties on the distribution of open source software that supposedly violates 235 patents.  Now tell me, who didn’t see this coming?  With the recent Novell-Microsoft pact, it became much clearer to me that Microsoft was preparing for outright war against the open source community, and now it appears that is very likely the case.

The Network World article is based on an interview from Fortune magazine (available here via CNN/Money) in which Microsoft officials, including Brad Smith (Microsoft General Counsel) and Horatio Gutierrez (licensing chief?), discussed their plans for getting FOSS (free/open source software) users to pay royalties on violations of no less than 235 Microsoft patents.  (By the way, I strongly recommend you read the full Fortune article.)

Now, it may be true that Microsoft won’t actually sue FOSS users or developers, as indicated here or here.  I certainly agree that it would be monumentally stupid for Microsoft to start suing its own customers, and it makes sense that Microsoft distributing SuSE Linux coupons makes it a Linux distributor and therefore subject to the GPL themselves.  However, after Microsoft skated out of the antitrust violations essentially unharmed, I’m not convinced that the FOSS community is as well-protected as they might think.  I hope that they are, but I’m not entirely convinced yet.

I’ll tell you one thing:  This most certainly reverses a great deal of the goodwill that Microsoft had been generated with the FOSS community and FOSS users, and it drives many users to stop using Microsoft products altogether.  I don’t consider myself a Microsoft basher, and have on many occasions openly welcomed many pieces of Microsoft software because, quite honestly, they were the best available.  I can’t say that I’ll be quite so open to Microsoft now, especially personally.  (Anyone care to recommend a high-quality replacement for Microsoft Office on Mac OS X?)  If nothing else, Microsoft has definitely succeeded in creating a larger amount of bad press, ill will, and mistrust.

There’s a lot of discussion going on around the Internet on this topic; here are just a few links:

• It’s Time for Microsoft to Put Up or Shut Up
• Put up or shut up, Microsoft (Larry Augustin)
• How to Know Microsoft Hates Opensource
• Microsoft Plays Dirty Pool Again

I also strongly recommend that you read the Groklaw article on this turn of events as well.

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.