There is a long-standing bug in (Open)Solaris and derivatives (including NexentaStor) that breaks Active Directory interoperability:
Beginning with Windows Server 2003, Active Directory supports VLV searches. Every VLV search request must be accompanied by 2 request controls: the SSS control and the VLV control. However, Active Directory imposes some general criteria on the SSS control:
1. Cannot sort based on more than one sort keys/attributes.
2. Cannot sort based on the “distinguishedName” attribute (presumably Microsoft does not use the “DN” attribute).
3. Cannot sort based on a constructed attribute (presumably an attribute not stored on Active Directory).
Unfortunately, Solaris LDAP clients use 2 sort keys/attributes: “cn” and “uid” in the SSS control. Subsequently, when dumping a container or a naming database, Solaris LDAP clients would receive LDAP_UNAVAILABLE_CRITICAL_EXTENSION.
$ ldaplist passwd
ldaplist: Object not found (LDAP ERROR (12): Unavailable critical extension.)
This issue has been detailed elsewhere, including at utexas.edu. There appear to be at least four solutions:
- Wait for the fix from
SunOracle to reach the light of day: this bug was apparently fixed in SNV 144. (I expect the fix is out in Solaris 11 Express now, but have not tested this myself.)
- Apply the hotfix in Microsoft’s KB886683 to your domain controllers, which will disable VLV.
- Run separate ADAM instances with VLV disabled, and point your Solaris machines at them instead of directly at your domain controllers. From the blog post linked above, it sounds like the University of Texas chose this route.
- Use OpenLDAP as a proxy in front of Active Directory; configure your Solaris machines to use the proxies instead of Active Directory servers. This is the solution detailed in this blog post.
Disclaimer: I am not a FirePass administrator; only an end-user and have no other relationship with F5. There may be better methods to address this issue; please comment if you know of one.
Preliminaries: Although the F5 FirePass SSL VPN product supports Linux, as best as I can tell, that support is somewhat limited: My understanding is that they officially claim support for 32-bit installs only, and they do not appear to track new distribution releases particularly aggressively. F5 has also been somewhat slow in supporting new browser versions: They announced support for Firefox 3 on October 6, 2008, nearly four months after its release and with only two months to go before Firefox 2 was end-of-lifed. For Firefox 3.6 support, a comment on the post linked above states that you need to request a special hot fix from F5 (which my site has not applied). There is no Google Chrome support that I am aware of.
Further, F5’s automated client installation tools have unfortunately never worked for me on Linux, even when the architecture and browser are in their support matrix. The manual download instruction links are also broken on the FirePass install I connect to.
Solution: Install a dedicated, 32-bit version of Firefox in a supported version; create a single-purpose Firefox profile for VPN use. Add the FirePass client to that browser and the operating system.
Running a lot of Red Hat VMs in your virtual infrastructure, on shared storage? CentOS, Scientific Linux, both versions 4 and 5, they count for these purposes; Fedora should likely be included too. Do you have the slocate (version 4.x and earlier) or mlocate (version 5.x) RPMs installed? If you’re uncertain, check using the following:
> rpm -q slocate
> rpm -q mlocate
If so, multiple RHEL VMs plus mlocate or slocate may be adding up to an array-crushing 4:02am shared storage load and latency spike for you. Before being addressed, this spike was bad enough at my place of employment (when combined with a NetApp Sunday-morning disk scrub) to cause a Windows VM to crash with I/O errors. Ouch.
I finally got around to installing Ubuntu (Hardy) on my Eee PC this weekend. My only regret: That I waited so long to do it.
In the past, I’ve used our local mirror of the CentOS yum repository to kickstart machines booted using PXE; apparently, this no longer works with CentOS 5.1, although it did with 5.0. If you attempt to do so, after the initial PXE boot, you get the following message:
The CentOS installation tree in that directory does not seem to match your boot media.
So, you recognize that FreeBSD isn’t officially supported on VMware ESX, but you want to give it a try anyway? Here’s what I did to get it installed, with VMware Tools and using e1000 Ethernet drivers:
Installation was for the most part straightforward – I chose “Other” for the operating system type, and allocated resources like I would for pretty much any other operating system. The install from an NFS-mounted ISO image worked fine; I’ve only run into two issues so far: Installing VMware Tools and changing the Ethernet drivers from the default Lance drivers.