blog.scottlowe.org

I just wanted to provide a quick update on some articles I have in the works to be (hopefully) published soon.

• I’m working on an article discussing when to use various NIC teaming configurations with VMware ESX. There are some significant repercussions here for a variety of network configurations, but especially so for configurations involving IP-based storage (iSCSI or NFS).
• I’m finally wrapping up an article on the Xsigo I/O Director. I’ve been working a Xsigo VP780 in the lab for quite some time, and this article will provide a brief overview along with some tips and tricks.
• I received word from HP that I should be getting a ProCurve switch in my lab soon, so that means I can provide a ProCurve-oriented version of this NIC teaming and VLAN trunking article.
• I have some notes on using NetApp Open Systems SnapVault (OSSV) in conjunction with VMware ESX that I plan to post here as well.

New versions of the Linux and Solaris AD integration articles are on the way as well, starting with an update of the Solaris instructions to accommodate Solaris 10 Update 5 and Windows Server 2008.

If there’s anything else you’re interested in seeing, let me know in the comments. Thanks for reading!

UPDATE: The NIC utilization article is available here.

In UNIX/Linux integration scenarios, it’s useful to know which accounts have been UNIX-enabled, i.e., have had the UID number, NIS domain, login shell, and home directory attributes configured.

It’s certainly very possible to do this with command-line tools such as AdFind or DsQuery, but users may also find it useful to have a saved query available within the Active Directory Users & Computers console for easy reference.

The way to do this is define a custom query using this string:

(objectCategory=Person)(objectClass=User)(uidNumber=*)

If you add just this text and nothing else in the “Find Custom Search” dialog box (the Advanced tab), then the console will automatically add ampersands and additional parentheses to turn it into a “proper” LDAP query that will show you any account that has a UID number configured. Certainly, additional fields like loginShell or unixHomeDirectory could be added as well, but this query will probably be sufficient for most instances.

I started not to publish this, but figured if I couldn’t remember the exact syntax then someone else might not be able to remember the syntax either. This one is as much for me as it is for others.

Reader Scott Merrill pointed out something to me in an e-mail regarding a Registry change that might be necessary in some Active Directory integration scenarios:

Finally, I would like to share one registry change that we’ve found to be necessary in our AD integration. By default, the MS LDAP server only returns 1,000 results. As a university department with more than 1000 active students, this limitation has caused us some frustration.

This KB article shows how to increase the number of results returned in a query: http://support.microsoft.com/kb/315071

We recently set MaxPageSize to 5,000. I don’t know if this will
introduce additional problems down the road, but at least it lets me fully enumerate all our AD users from a Linux machine with `getent passwd`.

If you have an Active Directory domain with more than 1,000 users in the DN specified in your LDAP configuration, then this is a Registry change you’ll want to investigate. Otherwise, you could find that your UNIX/Linux servers aren’t able to fully enumerate all the users in the domain.

Thanks, Scott!

Here’s a quick list of a few of the articles that I currently have in progress:

• I’ve been looking at the recently-announced products from Altor Networks and have their VNSA (Virtual Network Security Analyzer) running in the lab right now. Look for a short post on the product and my initial thoughts. (One piece of advice I can offer to Altor right now: use the virtual appliance OVF format and save your customers a lot of trouble.)
• I’m going to have some hands-on time with a Xsigo I/O Director over the next few weeks, so look for an article on that product.
• Prodded to action by Nick’s comment in my article on thin provisioned VMDKs on NFS, I’ll have an article on using SnapRestore to clone VMs on NFS without losing the thin provisioned VMDKs.
• The Active Directory integration articles are getting a bit long in the tooth, so look for updates to both the Linux and Solaris integration instructions. (By the way, speaking of Solaris integration: I came across this article a short while ago.)

If anyone has any other topics they’d be interested in seeing me tackle, feel free to mention them in the comments below. I can’t make any promises, but I’ll certainly consider them!

UPDATE: The article on preserving thin provisioned VMDKs with SnapRestore is now available.

Reader Jeffrey Spear contacted me a while back with some problems he was experiencing in trying to integrate some Linux systems into Active Directory. Basically, Kerberos was working but LDAP wasn’t. He was able to use “kinit <AD username>” to generate a Kerberos ticket, but using the “getent passwd <AD username>” was not working. No error messages, nothing; it just didn’t work.

We traded e-mails back and forth for a while, and eventually he found the solution himself:

We work with a locked down version of OSs and in this case a domain policy on the Windows server was preventing the RHEL machines from accessing account info.  The policy was “Domain controller: LDAP server signing requirements” which was set to “Require signature.”  When I changed this setting to “None” it worked great.

This is good information and important to keep in mind; I’ll be sure to incorporate this into the next revision of the Linux-AD integration instructions. (No, I don’t have a timeframe on when that will be!)

In the meantime, if anyone has a workaround for this problem that will allow LDAP to work with signatures enabled or required, I’d love to hear it. Speak up in the comments below!

The fine folks over at SearchVMware.com have published another of my VDI articles, this one focusing on the connection broker’s integration into Active Directory:

The broker’s integration with a back-end directory service can play a significant role in many of the decisions regarding how a virtual desktop infrastructure (VDI) environment is deployed in VMware Infrastructure 3 (VI3). In this tip, we’ll examine the integration between the connection broker and a commonly-used back-end directory service, Microsoft Active Directory.

Please go read the full article!

I wanted to take just a brief moment and let everyone know about a few articles that I’ve got “in the pipeline” for the site.  If there is one—or more—of these articles that looks particularly interesting, speak up in the comments.

Here are the articles that are currently under development:

• An update to the Solaris-AD integration instructions:  Last time I ran through these instructions I came across a number of discrepancies and little “gotchas.”  I need to incorporate the workarounds into the integration instructions and publish a new version.
• A brief blurb on NetApp OSSV:  NetApp’s Open Systems SnapVault (OSSV) is a pretty cool technology, so I want to take a quick look at setting it up.  I’m also exploring to see what kind of unique synergies may arise from using OSSV in a VMware environment.
• Restricting access to ESX Server when using AD integration:  As reader Scott Garrett points out in this comment to an earlier article, ESX Server’s version of sshd doesn’t support the UsePAM directive.  This prevents us from using group membership in Active Directory to control access to ESX Server’s Service Console.  Or does it?  I have a hunch that there may be at least one workaround for this problem; once I’ve tested it, I’ll document it here.
• New iSCSI functionality in ESX Server 3.5:  VMware appears to have refreshed the software iSCSI initiator in ESX Server 3.5, so I want to take a closer look at and discuss here some of this new functionality.

That’s it for now, although I’m certainly open to other items that pique reader interest.  Feel free to submit your suggestions in the comments.  Thanks!

Since I had CentOS 5 up and running on ESX Server in the test lab, I decided to try to validate my latest Linux-AD integration instructions on this installation.  Unfortunately, the instructions do not seem to work well at all with CentOS 5; here are some of the errors that I ran into:

• When using “net ads join” to join the Active Directory domain, it didn’t recognize any existing Kerberos tickets.  I’d already run a “kinit <AD username>”, but “net ads” continued to either a) try to use the root account if I didn’t specify the “-U <AD username>” parameter, and b) prompt for password even when I’d already obtained a Kerberos ticket for the specified username.
• When initially trying to join the Active Directory domain, “net ads join” threw this error:
  [2007/12/04 12:57:08, 0] libads/kerberos.c:create_local_private_krb5_conf_
for_domain(594) create_local_private_krb5_conf_for_domain:
failed to create directory /var/cache/samba/smb_krb5.
Error was Permission denied
  This error persisted until I manually created the /var/cache/samba/smb_krb5 directory myself.  Why this directory wasn’t created automatically during the Samba installation is beyond me.  Once I created that directory, the error went away, but Samba still wouldn’t create the keytab or add entries to the keytab.
• The “net ads keytab” command failed miserably; it would not create a keytab, nor would it add entries to a keytab.  No error message is reported; it just doesn’t work.

I inquired on the #samba IRC channel on irc.freenode.net, but the only person willing or able to respond didn’t have any information to provide (in fact, he’d actually used my Solaris-AD integration instructions as a guide for some of his own work).  Various Google searches also failed to provide any helpful information.

By the way, these tests were performed on a stock installation of CentOS 5, with all the latest packages installed using “yum update”.  The Samba version was 3.0.25b-1.el5_1.2.

In the end, I’ve given up on trying to make Samba work in the AD integration process and will instead fallback to the use of ktpass.exe to create the keytab file.  If you have any useful information to share, please let me know or post it in the comments.  Thanks!

This afternoon, I walked back through my own instructions for integrating Solaris 10 and Active Directory, and I found that the process wasn’t as smooth as perhaps I’d believed it to be.  As a result of walking back through the process again myself, I’ve collected some notes.  At some point in the near future, these notes will be integrated into a new version of the Solaris-AD integration instructions.

So, without further ado, here are the notes I collected in no particular order:

• The Blastwave Samba package does not create it’s own smb.conf file in /opt/csw/etc/samba.  This is correctly pointed out in the latest integration instructions, but I wanted to mention it again here.  You’ll need to manually create the /opt/csw/etc/samba/smb.conf file before attempting to join the Solaris server to Active Directory via the ‘net ads join’ command.
• The defaultServerList portion of the ‘ldapclient manual’ command only supports IP addresses.  The LDAP client service kept going into maintenance mode when using hostnames.  On a hunch, I substituted IP addresses for hostnames, and it worked.  Go figure.
• Apparently, you can’t use ‘ldapclient mod’ to change an existing attribute map.  I had a hunch about resolving a co-existence issue where both Solaris and Linux are both authenticating against Active Directory—more on that particular topic is coming soon as well—and needed to change the attribute maps for the homedirectory and loginshell attributes.  I ended up editing the ldap_client_file manually (found in /var/ldap; must be made writable using chmod) in order to make the change.  If anyone has a more elegant fix, please let me know.
• The ‘net ads join’ command correctly creates a Kerberos keytab with the appropriate entries, but places it in the wrong location.  On my test system, it placed the krb5.keytab file in the /etc directory, and Solaris expected it to be in /etc/krb5 instead.  Until I moved that file, authentication against Active Directory consistently failed.
• It turns out that it’s not really necessary to enable the DNS client using ’svcadm enable svc:/network/dns/client:default’; from what I’ve been able to gather, that’s there as a dependency only.  The ‘nslookup’ and ‘host’ commands seemed to work just fine with this service still disabled.

Again, I’ll be incorporating these changes into a future version of the Solaris-AD integration instructions.  I hope to have that complete within the next week or two, so stay tuned.  In addition, I have information coming to help with the co-existence of multiple UNIX and UNIX-like operating systems all authenticating against the same Active Directory forest, so keep your eyes peeled for that as well.

A reader kindly shared with me some tips and tweaks he used to help resolve some performance issues with Linux-AD integration, and now I’d like to share them with you:

I ran into some nagging performance issues with Linux/AD integration the other day, and managed to solve them (mostly)—I thought you might be interested in the solution.

Since I’m not exactly following your integration guide (I use DNS lookups to locate LDAP servers in AD, and use GSSAPI authentication for nss_ldap instead of a binddn), I have a bit more overhead on my getent system calls, that was starting to get noticable when it came to getting directory listings, etc.

Two things I have done to alleviate this issue:

1. Since we have a flat catalog, and all of our DCs are also GCs, I
   disabled recursion. This is not universally relevant, but it does assist me
2. I edited /etc/nscd.conf to set a 5 minute cache time for passwd and group (but not host!) entries. Data is still usually piping fresh, but now we only call nss_ldap once every 5 minutes, instead of every time we need to know who owns a file. Then I started nscd, and set it to start on boot.

NSCD is a standard part of most RHEL and derivative installs.

Since implementing the above, the user-level experience is no longer
discernably different than the old /etc/passwd method of authentication/authorization.

This is good information to have.  Thanks to Brandon for sharing his experience!