Lockdown mode has been around in various forms for many releases. The behaviors have changed a few times since 5.1 with varying levels of usability success. For vSphere 6.0 we are trying to address some of these issues. Personally, what I’d love to see happen with all customers running V6.0 is that you run at a minimum the “Normal” Lockdown Mode.
Category Archive: IT
You’re the virtualization admin. Your security guy comes up to you, looking for information. You really don’t want to give him an account on vCenter, do you? (according to a group discussion session I did at VMworld, the answer was clearly “No” with some being a little more colorful by using the term “NFW”!)
But lets face it, the IT Security folks do have a job to do and they really could use information on a regular basis to do their job. Let’s see if we help them by helping you, shall we?
Give us questions, we’ll give you answers
I’m looking for examples of the types of questions IT Security needs regular answers to. Alan Renouf and I are mulling some ways to help both of you out. No details yet but having Alan involved should give you a hint! :) Give us the questions, let us surprise you.
I’ll start this off with some examples:
Security Guy: “I need to see….
- all the virtual machines that have a CD drive attached
- what virtual machines are on what network/switch/portgroup
- what virtual machines are on what storage device
- what roles are assigned to what users
- ESXi server SSL certificate details like when they expire
- What vSwitches are in promiscuous mode
- any vDS port mirroring details
- the ESXi shell interactive timeout values
- what the syslog IP address is set to on the ESXi servers
Based on that, start posting the questions! We’ll try to get as many included in this little project we are working on. We hope you like it!
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, firstname.lastname@example.org and email@example.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.
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!
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!