By default, all the tutorials for installing XenDesktop use the defaults. This means [...]]]> XenDesktop 4 has raised the bar for virtual desktop (VDI) solutions. It’s now easier to provide a virtual desktop to users on differing operation systems and platforms. And having Citrix on the iPhone / iPad is just amazing eye candy too.

By default, all the tutorials for installing XenDesktop use the defaults. This means that under Windows, using a browser to connect and launch a session from web interface uses the online plug-in module. It works, provides multi-monitor capability, but has display artifacts and no nifty bar to manage USB connection and such. Besides this client, the Desktop Viewer can also be used as the default (if installed).

With the 11.x and 12.0 clients it’s easy to change. First install the Citrix Online plug-in (not the Citrix Online plugin – web which is smaller and doesn’t include the Desktop client) from here.

From the web interface server that services XenDesktop, browse to the conf directory and edit webinterface.conf. For example, /Citrix/WebDesktop2 is located here:

Edit the file and search for ShowDesktopViewer and change the line from:

# ShowDesktopViewer=Off

to the following:

ShowDesktopViewer=On

Next time a session is launched, the Desktop Viewer will be used instead of the online plugin. This doesn’t work under OS X as there really isn’t a better client than Desktop Viewer yet. Thanks to Richard Parmiter for documenting this!

Hint: To get mult-monitor under Desktop Viewer, re-size to something less than full screen, move the window over the two monitors and re-size to full screen. This setting will persist across sessions.

Certain third party products such as XenDesktop respect the expiration date on the vCenter SSL certificate. The vSphere Client doesn’t mind so much, nor it appears do the vSphere [...]]]> This is an update post to reflect the differences in vCenter 4.1 vs the older vCenter 25 install. The older post can be found here.

Certain third party products such as XenDesktop respect the expiration date on the vCenter SSL certificate. The vSphere Client doesn’t mind so much, nor it appears do the vSphere (ESX/ESXi — err vSphere Hypervisor) hosts, but when your VDIs suddenly can’t be reached, it’s a bad thing. I’m sure other products may have the same issue.

By default, vCenter will create a self-signed certificate issued to “VMware default certificate“. Unlike previous vCenter installs, the certificate is valid for 10 years, but still can cause problems for third parties that want to see the proper common name (e.g., FQDN of the vCenter server).

In our case, since we’re not publishing any SSL services to the public and already have a Microsoft Certificate Authority, we can create and sign our own vCenter certificate. And just like the newer version of vCenter, we’ll set it up for 10 years too.

This can be completed in just under 15 minutes if all the prerequisites are in place. Took me an hour (including this documentation).

Environment Summary

For this process to work, the following assumptions are made:

• Active Directory installed and Certificate Authority installed (in my case, it’s on a Windows 2008 Domain Controller with Certificate Authority and Certificate Authority Web Enrollment )
• DNS used for vCenter and internal FQDN name
• vCenter server part of the domain, Domain Admin access to it
• vCenter installed with local database (SQL Server 2005 Express) and using SYSTEM account – People commented on my previous related post about other steps required for database connectivity
• Using the included web services that comes with vCenter (IIS users on your own for this one)

To test, we’ll use a browser from a workstation and the XenDesktop DDC to validate connection (make sure the root CA certificate is added to the Trusted Roots for the Computer Account on each test and production server)

Prep vCenter

Since vCenter 4.1 now requires a 64-Bit Operating System (Server 2008 R2 Standard in my case), we’ll download the OpenSSL for Windows 64-Bit version.

Download OpenSSL for Windows (binary for the 64-bit version  v1.0.0a is here) You may have to install the Visual C++ 2008 redistributable package first.

Verify the private key exists in: C:\Users\All Users\VMware\VMware VirtualCenter\SSL\rui.key (you will need to change permissions to allow your user account to access this directory and files)

Copy all the files in C:\Users\All Users\VMware\VMware VirtualCenter\SSL to a temporary location such as c:\temp\vcenter\oldssl (create if needed)

Open a command shell and go to c:\temp\vcenter\newssl (create if needed)

Generate the new RSA private key (2048 bit) and the certificate request (most important is that the common name must be the FQDN of the server). For the CSR, I normally use the common name value.csr, but since we’re working with rui.*, we’ll use that here too:

C:\temp\vcenter\newssl>c:\OpenSSL-Win64\bin\openssl.exe req -newkey rsa:2048 -keyout rui.key -nodes -days 3650 -out rui.csr
Loading 'screen' into random state - done
Generating a 2048 bit RSA private key
.............................+++
......................................+++
writing new private key to 'rui.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Georgia
Locality Name (eg, city) []:Cumming
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Gavin Adams
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:vcenter.peanuts.local
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

C:\temp\vcenter\newssl>dir
Volume in drive C has no label.
Volume Serial Number is 204A-99B1
Directory of C:\temp\vcenter\newssl
04/16/2010  03:50 PM    <DIR>          .
04/16/2010  03:50 PM    <DIR>          ..
04/16/2010  03:50 PM             1,024 .rnd
04/16/2010  03:49 PM             1,675 privkey.pem
04/16/2010  03:50 PM             1,679 rui.key
04/16/2010  03:50 PM             1,005 rui.csr

From the vCenter system, browse to the certsrv URL for your Active Directory Certificate Authority (normally https://dcname/certsrv and probably will require a valid Active Directory user):

Select Request a certificate, advanced certificate request, and then Submit a certificate using base-64…. Past the entire contents of the rui.csr (open in Notepad, select all — it will be all on one line, but a CTRL-A CTRL-C will do fine) in the Saved Request box, select Web Server for Certificate template:

At this point the certificate will be signed. On the next page select Base 64 encoded then Download certificate and save as rui.crt in c:\temp\vcenter\newssl

From the private key and certificate, create the PFX fie:

C:\temp\vcenter\newssl>c:\OpenSSL-Win64\bin\openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx

Stop the following services:

VMware VirtualCenter Management Webservices
VMware VirtualCenter Server

Copy all the files in the newssl directory to : C:\Users\All Users\VMware\VMware VirtualCenter\SSL\ replacing the existing ones. Don’t worry, we backed these up.

Now restart the services in this order (unsure if it matters):

VMware VirtualCenter Server
VMware VirtualCenter Management Webservices

Use browser and navigate to the URL of the vCenter (e.g., https://vcenter.peanuts.local) and verify the certificate is valid. Open the vSphere client and verify all looks okay. After restarting the services, you will need to reconnect to the ESX / ESXi hosts and re-authenticate with root credentials on each server. This is because the SSL trust between the two has changed and a new trust relationship needs to be established. Another reason for a longer term certificate!

Problems and Resolution

I’ll update the post with corrections, but with different configurations, we may run into different issues.

By default, vCenter will create a self-signed certificate with just the host [...]]]> Certain third party products such as XenDesktop respect the expiration date on the vCenter SSL certificate. The vSphere Client doesn’t mind so much, nor it appears does the ESX hosts, but when your VDIs suddenly can’t be reached, it’s a bad thing.

By default, vCenter will create a self-signed certificate with just the host name. In our case, since we’re not publishing any SSL services to the public and already have a Microsoft Certificate Authority, we can create and sign our own vCenter certificate. And just like the newer version of vCenter, we’ll set it up for 10 years too.

This can be completed in just under 15 minutes if all the prerequisites are in place. Took me an hour (including this documentation).

Environment Summary

For this process to work, the following assumptions are made:

• Active Directory installed and Certificate Authority installed (in my case, it’s on a Windows 2008 Domain Controller with Certificate Authority and Certificate Authority Web Enrollment )
• DNS used for vCenter and internal FQDN name
• vCenter server part of the domain, Domain Admin access to it
• Using the included web services that comes with vCenter (IIS users on your own for this one)

To test, we’ll use a browser from a workstation and the XenDesktop DDC to validate connection (make sure the root CA certificate is added to the Trusted Roots for the Computer Account on each test and production server)

Prep vCenter

Download OpenSSL for Windows (binaries can be found at: http://www.slproweb.com/products/Win32OpenSSL.html) . You may have to install the 2008 redistributable package first.

Open a command shell and go to c:\temp\vcenter\newssl (create if needed)

Verify the private key exists in: C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\rui.key

Copy all the files in C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL to a temporary location such as c:\temp\vcenter\oldssl (create if needed)

Generate the new RSA private key (2048 bit) and the certificate request (most important is that the common name must be the FQDN of the server). For the CSR, I normally use the common name value.csr, but since we’re working with rui.*, we’ll use that here too:

C:\temp\vcenter\newssl>c:\OpenSSL\bin\openssl.exe req -newkey rsa:2048 -keyout rui.key -nodes –days 3650 -out rui.csr
Loading 'screen' into random state - done
Generating a 2048 bit RSA private key
.............................+++
......................................+++
writing new private key to 'rui.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:US
State or Province Name (full name) [Some-State]:Georgia
Locality Name (eg, city) []:Cumming
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Gavin Adams
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:vcenter.peanuts.local
Email Address []:
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

C:\temp\vcenter\newssl>dir
Volume in drive C has no label.
Volume Serial Number is 204A-99B1
Directory of C:\temp\vcenter\newssl
04/16/2010  03:50 PM    <DIR>          .
04/16/2010  03:50 PM    <DIR>          ..
04/16/2010  03:50 PM             1,024 .rnd
04/16/2010  03:49 PM             1,675 privkey.pem
04/16/2010  03:50 PM             1,679 rui.key
04/16/2010  03:50 PM             1,005 rui.csr

From the vCenter system, browse to the certsrv URL for your Active Directory Certificate Authority:

Select Request a certificate, advanced certificate request, and then Submit a certificate using base-64…. Past the entire contents of the CSR (open in Notepad) in the Saved Request box, select Web Server for Certificate template:

At this point the certificate will be signed. On the next page select Base 64 encoded then  Download certificate and save as rui.crt in c:\temp\vcenter\newssl

From the private key and certificate, create the PFX fie:

C:\temp\vcenter\newssl>c:\openssl\bin\openssl pkcs12 -export -in rui.crt -inkey rui.key -name rui -passout pass:testpassword -out rui.pfx

Stop the following services:

VMware VirtualCenter Management Webservices
VMware VirtualCenter Server

Copy  all the files in the newssl directory to : C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\SSL\ replacing the existing ones. Don’t worry, we backed these up.

Now restart the services in this order (unsure if it matters):

VMware VirtualCenter Server
VMware VirtualCenter Management Webservices

Use browser and navigate to the URL of the vCenter (e.g.,  https://vcenter.peanuts.local) and verify the certificate is valid. Open the vSphere client and verify all looks okay. After restarting the services, you will need  to reconnect to the ESX / ESXi hosts and re-authenticate with root credentials on each server. This is because the SSL trust between the two has changed and a new trust relationship needs to be established. Another reason for a longer term certificate!

So, after downloading the ISO image (at least the DVD can [...]]]> VMware’s Update Manager has always been too complex and cumbersome for small installations. However, back in the EX 3.5 days, it at least worked. Late last year when vSphere 4 Update 1 came out, I once again tried using good ol’ Update Manager.

So, after downloading the ISO image (at least the DVD can be used to build new hosts) I went through the process of baseline creation, compliance, added the host, and viola, Upgrade is not supported from host version 4.0.0 to blah blah blah.

Luckily, esxupdate to the rescue. I uploaded the .zip file bundle (not the ISO image, so another 900MiB download) to VMFS storage and ran the update script from the location of the .zip file after putting the host into maintenance mode:

# esxupdate --bundle=ESX-4.0.0-update01a.zip update

Performed a reboot, and the host is now running at ESX 4.0.0 build 208167. Caveats:

• Make sure 3rd party monitoring and management packages are uninstalled first (e.g., HP or Dell)
• Maintenance mode (natch)

VMware’s market lead is based on large scale management and features you cannot find (yet) in Xen or Hyper-V. I love most features and the UI of vCenter, but the add-ons really need to be better managed.

In the past, simply double-clicking on the .p12 file would prompt for the passphrase and import it into [...]]]> I love OS X and every iteration has gotten better and better. But every once in a while tasks that should be simple–aren’t. Take the case of trying to add a S/MIME certificate to the Keychain.

In the past, simply double-clicking on the .p12 file would prompt for the passphrase and import it into the login chain. After getting my certificate issued by StartSSL and stored in Firefox, I exported the certificate and private key, set a passphrase, double-clicked, and….

An error has occurred. Unable to import an item. The contents of this item cannot be retrieved. You failed to provide the necessary administrator authorization. (Added so the search engines will pick this up)

And so the battle commenced. There really isn’t a lot out there discussing when Keychain Access fails. The closest similar discussion was by Midori Green (email thread here). The error was different, but it was the same attempt to import a PKCS12 file.

I tried using openssl to rearrange the certificates in the file (after exporting into PEM format), tried adding/removing/changing the private key passphrase, import/export from a Windows machine in .PFX format, and even trying to recreate the PKCS12 file from its’ constituent parts.

Luckily, I ran across this post on krypted.com that mentioned the CLI command security. After placing the exported .p12 file (from Firefox) in a directory and launching terminal, I was able to use the command:

linus:gadams$ security import startssl-smime-cert.p12 -f pkcs12 ~/Library/Keychains/login.keychain
1 identity imported.
2 certificates imported.

And bam!, the certificate loaded. Composing a new message in Mail.app showed the signing and encryption boxes. Although I still get invalid signatures when sending rich text format messages, plain text are properly getting signed.

I am curious exactly what command is executed when you double-click on a certificate file. I assume the Keychain access application makes underly calls to security, but I’d like to be able to trace the steps it takes.

Side note, I’m going to do an opinion piece of certificate authorities in general and digital certificates, SSL, S/MIME, and all that rot. There are some great options for small companies and individuals to get certificates at a cheap or free price. No Verisign or GTE Cybertrust (err Verizon Business) $$$$$ prices need apply!

In the past under Windows XP, scheduling tasks was a breeze. It still is under Windows 7, except by default they don’t [...]]]> DeltaCopy is a great easy to use rsync client (and server) for Windows. Based on Cygwin, it front-end the rsync client and adds the capabilities to schedule tasks and send email notifications.

In the past under Windows XP, scheduling tasks was a breeze. It still is under Windows 7, except by default they don’t run. I assume the application hasn’t been fully tested under Windows 7, and I know it can have issues with UAC and the scheduler.

I’ll explain the steps I’ve taken to get backup tasks to operate.

Installation

A normal installation works fine, but to insure UAC doesn’t mess with anything I use C:\DeltaCopy as the installation directory.

Creating a New Copy Job

I won’t go through the details of selecting directories for backup, but when selecting the scheduling option, the way the task is created needs to be modified. For example, a new job called Backup Stuff is created:

By default the schedule is created, but not run. Selecting the Modify Schedule button shows the created settings:

As you can see, the run command reference the .dcp file, which I assume contains the parameters for the backup job. On the run command, insert deltac.exe then a space, then the .DCP file, like so:

Select the Schedule tab or settings for configuring the job like any other Windows task. When you hit apply, the job should run as expected.

let me know if anyone runs into problems with this!

I’m running Windows 7 RC1 64-bit  (build 7100), and downloaded the corresponding driver [...]]]> Overall Photoshop CS4 Extended is running like a champ in 64-bit mode. It sees 6GB of RAM and all my plugins are working fine. However, my older Wacom Graphire tablet isn’t working for pressure sensitivty in Photoshop. There is a solution!

I’m running Windows 7 RC1 64-bit  (build 7100), and downloaded the corresponding driver file for my tablet (release date of Sep 10, 2007). It works fine, and pressure sensitivity works in Photoshop 32-bit and the tablet preferences. Wacom support said to download the driver for the Intuos 4 (Vista OS). The driver is WacomTablet_611-3.exe (link may change) and after removing the older driver and installing this one, all tablet features working AOK!

Make sure to apply the 11.0.1 Photoshop update as there are numerous complaints of tablet issues with the initial CS4 release (11.0.0).

This posting will walk you through the steps [...]]]> Linux and Windows Active Directory (AD) integration has come a long ways since 2000. It is now quite easy to take advantage of Kerberos for managing authentication at the host level (user logins and such). Surprisingly, it’s just as easy to the same in Apache now.

This posting will walk you through the steps needed to configure and test authentication against a valid AD user.

Prerequisites

It is assumed the following prerequisites are in place:

• CentOS 5.2 Server – fully updated
• Apache, Kerberos, and supporting packages installed
• Samba configured as member server (net ads join has been successfully performed)
• Windows Server 2003 R2 or 2008 SP1 with UNIX Identity Management extensions installed
• Kerberos working (kinit from a AD user properly authenticates and klist shows tickets)

If possible, test this from a freshly installed machine. In this example, the following servers and realms will be referenced:

AD Server       dc01.example.com
Linux Server    www.example.com
Computer Object www
Kerberos Realm  EXAMPLE.COM

Creating the SPN

Kerberos uses a service principal name for each service available on the host. For a server that can authenticate against AD, this would include at least the HOST principal. From the AD server, issue the setspn command to view the current SPN’s assigned to www.example.com (use the canonical name for www, not the FQDN):

C:\>setspn -L www
Registered ServicePrincipalNames for CN=www,CN=Computers,DC=example,DC=com:
        HOST/www
        HOST/www.example.com

Now as root on www issue the command to create the HTTP SPN (the net ads command is provided by the samba packages–make sure these are installed even if they are not used):

[root@www /]# net ads keytab add HTTP -U administrator
Processing principals to add...
administrator's password: *******

The -U is used to provide an administrator account with Domain Admin privileges. This step has added the SPN which we’ll see in AD, and it has also updated the local keytab file /etc/krb5.keytab with the SPN bits.

To verify the SPN has been created properly, issue the same setspn command and verify there are entries for HTTP. It should look something like this:

C:\>setspn -L www
Registered ServicePrincipalNames for CN=www,CN=Computers,DC=example,DC=com:
        HTTP/www
        HTTP/www.example.com
        HOST/www
        HOST/www.example.com

Configure Apache

Make sure the package mod_auth_kerb is installed. This should create the configuration file in /etc/httpd/conf.d/auth_kerb.conf which will load the Kerberos module and provide a commented out example (which we’ll use). First, because httpd runs as apache, we need to copy the keytab file and change permissions so that apache can read it. I’ve placed it in the default specified in the auth_kerb.conf file:

[root@www /]# cp /etc/krb5.keytab /etc/httpd/conf/keytab2
[root@www /]# ls -l /etc/httpd/conf
total 64
-rw-r--r-- 1 root   root   33760 Mar 25 14:01 httpd.conf
---------- 1 root   root    1321 Mar 25 15:06 keytab
-rw-r--r-- 1 root   root   12958 Nov 12 10:43 magic
[root@www /]# chown apache.apache /etc/httpd/conf/keytab2
[root@www /]# chmod 400 /etc/httpd/conf/keytab2
[root@www /]# ls -l /etc/httpd/conf
total 64
-rw-r--r-- 1 root   root   33760 Mar 25 14:01 httpd.conf
-r-------- 1 apache apache  1321 Mar 25 15:06 keytab
-rw-r--r-- 1 root   root   12958 Nov 12 10:43 magic

Create an Apache Location for Testing

Now modify the “private” location and uncomment the directives and set them for the realm (changes from defaults in bold):

[root@www /]# vi /etc/http/conf.d/auth_kerb.conf# The mod_auth_kerb module implements Kerberos authentication over
# HTTP, following the "Negotiate" protocol.
#
LoadModule auth_kerb_module modules/mod_auth_kerb.so
#
# Sample configuration: Kerberos authentication must only be
# used over SSL to prevent replay attacks.  The keytab file
# configured must be readable only by the "apache" user, and
# must contain service keys for "HTTP/www.example.com", where
# "www.example.com" is the FQDN of this server.
#

#<Location /private>
#  SSLRequireSSL
 AuthType Kerberos
 AuthName "Kerberos Login"
 KrbMethodNegotiate On
 KrbMethodK5Passwd On
 KrbAuthRealms EXAMPLE.COM
 Krb5KeyTab /etc/httpd/conf/keytab
 require valid-user
</Location>

Create the directory (/var/www/html/private) and a test HTML file in the directory (index.html). Restart httpd and navigate to the URL (http://www.example.com/private/index.html). You should be prompted for credentials. Using a valid AD user and password should get you in. A side benefit is that if logged into a workstation within the domain (e.g., Windows XP, Vista, etc), using Internet Explorer should use your Kerberos credentials to authenticate.

Uses

For production use, any application or web service that can use Apache’s authentication mechanisms should work. Take care to understand that even if you enter a short username, the realm will be appended onto the end. In this example, the username gadams would appear as gadams@EXAMPLE.COM in the log files, and probably be presented to the referenced application.

Credit

I’d like to Scott Lowe for all the articles he has done on Linux / AD / Kerberos integration, and this article, which was where I started my CentOS / Apache / Kerberos / AD journey. His article covers all the basics, but a lot has changed (for the better) since 2006. Thanks Scott!