Category: Written while at RSA

Baby, what time is it? The importance of time with VMware SSO

For the past week or so, in my copious spare time, I’ve been re-building my vLab at work. It’s a cobbled together menagerie of hardware that makes me wish I had a healthier budget so I could spend more time on learning and less on reconfiguring, scrounging and breaking out the baling wire and chewing gum. Dealing with old hardware is distracting and takes your mind off this things that are critical for success. This happened to me. I know plenty of friends in the vCommunity that also have dealt with this. (I hear your heads nodding)

One of the things I’m playing with in in the lab is configuring VMware vCloud Director 5.1 with vCenter 5.1’s SSO functionality. I’m finding that this is one of those times when you really should RTFM and plan ahead more. But that’s ok, I like diving in without docs because then I get to learn more by breaking things and then I have something to share.

Single Sign On

In vSphere 5.1 there is a new feature called Single Sign On. With the new vCenter client now being web based,  SSO now allows VMware to leverage industry standards like SAML so that an admin can log  once to vCenter and be automatically signed on to other resources like vShield Manager and vCloud Director. There’s a great overview of VMware SSO from Justin King here. You can read more about troubleshooting SSO here.

Not Kirk’s Federation

With vCenter and the SSO components up and running I installed the vCloud virtual appliance OVA and proceeded to set up federation between vCenter and vCloud. You can read more about federation in the Wikipedia article, but in a nutshell, it’s a way of linking identities. So, mike@foo.com and mike@bar.com can be linked. A trust relationship is set up so that if I log in from foo.com and hit a web page that needs my bar.com identity I get logged in using my bar.com account without having to provide the credentials.

Back to my lab, when I tried to do this, I ran into some trouble. I kept getting the following error.

Image 11-7-12 at 4.05 PM
Long story short, I had screwed up. I hadn’t been as diligent as I should have been with setting up my systems. The distractions I mentioned earlier had come back to bite me. Having recently added a couple of disk-less ESXi servers, I didn’t finish configuring them. I hadn’t been leveraging NTP as much as I  should.  What I now had was a number of  systems trying to talk to each other but not agreeing on the time. And with SAML, time is critical. You are issued a token and part of that token is a timestamp. If vCloud thinks it is 9pm and vCenter thinks it is 8pm, the token with a short lifetime will come back as already expired. Just what happened to me.

The Time/Space Continuum is restored

I fixed the problem by setting all the ESXi servers to pull from an NTP server. In addition I also set up my vCenter, SQL server and domain controller to pull from NTP. Just like DNS has become a critical infrastructure component that just needs to be there, NTP is now jumped to the “required” list. Valid, consistent time stamps across your datacenter are needed for the operation of your infrastructure. They are also critical for security in things like authentication and log analysis, especially when you are trying to correlate lots of information!

NTP is critical to other vCloud operations as well. My friend Chris Colotti called this out in this blog article.

If you haven’t set up your datacenter with NTP, now’s the time. Oh, and DNS too. It’s time to ditch the hosts files. (yes, there’s still plenty of people using them!!) Going forward, more and more of your datacenter are going to rely on these key components. Ensuring that you use them consistently will help a LOT in troubleshooting large and complex installations.

Thanks for reading!

mike

That’s my View and I’m sticking to it

Minimizing the clicks & Better Performance

As some of you may know, I’m a user (and fan) of virtual desktops. I’ve been using a VMware View-based virtual desktop now at EMC for about 2+ years. This works well for me because I use my personal MacBook rather than a company issued laptop. I like to keep that separation between what’s mine and what’s EMC’s. I do all my “EMC” work on the virtual desktop. Email, timecard, etc…

So, when new VMware View clients came out, I jumped over to see what’s new. I’m happy to report that a couple of things caught my eye.

URI Support

Screen Shot 2012-11-02 at 11.33.51 AM

The first is the new URI support for the VMware View client. You can now launch the VMware View client from your browser, passing certain characteristics to the client. The URI would be vmware-view://. That was interesting to me as I wanted the ability to launch a URL with the VMware-View URI for specific use cases. Primarily, I wanted to launch the View client with different sizes. One for fitting well on my Macbook Air screen and another when I’m using an external monitor. I looked into the documentation and found this was trivial to set up.

vmware-view://mike@my.view.server.com/MikeF%20Desktop?desktopProtocol=PCoIP&desktopLayout=1280×854

Obviously, I’ve changed the username and server name and desktop name in the above URL. But, as you can see, I can specify the protocol, PCoIP or RDP and the size of the screen, in this case 1280×854. According to the docs and a blog article by Kristina De Nike at VMware you can change all sorts of things. Here’s a list from the blog.

  • View Connection Server address
  • Port number for View Connection Server
  • Active Directory user name
  • Radius or RSA SecurID user name
  • Domain name
  • Desktop display name
  • Window size
  • Desktop actions including reset, log off and roll back
  • Display protocol
  • Options for redirecting USB devices

Screen Shot 2012-11-02 at 11.37.07 AM

How do I get this so I can just click on a desktop icon, add my password and go? By creating a .URL file using a text editor. This .URL file is understood by both PC and Mac browsers and will do the right thing. Here’s the format:

[sourcecode language=”text” padlinenumbers=”true”]
[InternetShortcut]
URL=vmware-view://mike@my.view.server.com/MikeF%20Desktop?desktopProtocol=PCoIP&desktopLayout=1280×854
[/sourcecode]

Copy that into your text editor and save it as a .URL file on your Windows or Mac desktop.

How does this work with things like SecurID? <shameless plug for my employer> It works just fine. When I’m at home and I double-click the icon, I’m prompted for my SecurID credentials and then my Active Directory credentials. When I’m in the office on the corporate LAN, I’m just prompted for my Active Directory credentials. Someday, I would LOVE it if 1Password could fill in the login info, but…

Performance

This now leads me to the second thing I found out with the new VMware View clients. I was originally going to have two .URL files on the deskop. One for RDP and one for PCoIP. The reason being is that I use a USB 2.0 to DVI DisplayLink adapter from Monoprice.

image

As you can imagine, it doesn’t really have a lot of horsepower for graphics. Earlier VMware View clients for the Mac running PCoIP would choke horribly on this device. I used RDP for the past year when I wanted my virtual desktop on the monitor connected to the USB/DVI adapter. But lo and behold, I started up the new View client using PCoIP on the 2nd monitor and it works beautifully! I don’t know what VMware changed, but I sure am glad it’s working. I can now resize at will and as I write this, I have a View session going at 1440×1024 with great performance!

So, to wrap up, the new VMware View clients make it easier to launch the client just the way you like them and if you’re using DisplayLink devices like the Monoprice adapter and the DisplayLink 1.8 drivers you’ll get decent performance to boot.

I hope this was helpful. Please share your comments!

thanks,

mike