vCartoon of the Week (01/31/2013)

When SSO goes bye bye, things get interesting

So until today I was under the impression that SSO only effects the web-client in 5.1. The way I understood was the vSphere client still behaves the way it did before and SSO is not engaged unless the web-client is used to login. This also brought me to the conclusion that if SSO goes down, one cannot login via the web-client but the vSphere client can still be used. Wrong!!

A colleague of mine pointed me to a this page that clearly states the following:

How does SSO integrate with the vSphere Client?

SSO does not integrate with the vSphere Client. However, when you log in through the vSphere Client, vCenter Server sends the authentication request to SSO.

Once I read that I started doubting my thought process and the importance of SSO in 5.1 Apparently all access to vCenter must be down once SSO is down (both via web and vSphere client).

After doing a lot testing this is what I found (vcenter 5.1 build 799731). When SSO is down,

  • access via web-client is down as expected 
  • access via vSphere client is flakey

What does flakey access mean? Well, I got mixed results and was finally able to see some pattern. When SSO service is down, I was able to login with the account that has had a successful login while SSO was running. The important thing here was, “use windows session credentials” had to be checked for which I had to be logged in with the account that had successfully logged in when SSO was up. If I didnt check the box and entered the credentials myself, it told me the username and pwd were incorrect. I know I can fat finger keys at times but I tested this over and over to come to this conclusion. It wasnt me. Access was only allowed when the check box was checked.

This also meant any new account that was created or granted access couldn’t login using the vSphere client. Rememeber we only had luck with accounts that were able to login succssfuly prior to SSO service going down. And that too required the checkbox to be checked. If the account was just created or granted access after SSO went down, the screen showed the beautiful message on the right. The same message was received if the account didn’t successfully login while SSO was up. Why cant this message say the SSO cannot be reached is beyond me. By the way the web-client will tell you “Failed to communicate with the vCenter Single Sign On server” when SSO is down. So thank you VMware for doing that. 

Another thing to keep in mind. When SSO service is down, your vCenter service continues to run. However, if you attempt to restart your vCenter service you will find yourself in trouble. I was unable to get the vCenter service to start with SSO being offline. Which makes SSO even more important. Yes even with vCenter down your VMs continue to work but there are other vCenter specific features that will not function like DRS, sDRS for example. And if this vCenter is connected to a vCloud instance thats another can of worms.

So the bottom line is, SSO is very very important. It has two parts, the application and the DB part. VMware has done a great job in giving the option to install SSO as single, clustered or even multi-site type deployments. The high availability in the application side is thought out there. However, the problem is DB. VMware does not fully support SSO DB on a SQL cluster. As a matter of fact, there have been known issues that have come about when trying to deploy SSO using a SQL cluster. So the real option with full support is a stand alone SQL node. But that also creates a single point of failure. When the DB goes down, you are unable to login using the web-client, you maybe able to login using the vSphere client and all other things we discussed above.

So building redundancy is extremely important. VMware’s recommended solution is to use vCenter Heartbeat. We all know that can be a pricey solution. However, if full support along with redundancy is importnat to you, that is the way to go. I hope VMware extends their full support to at least allow running DB on a SQL cluster for all their products including vCenter (which is still a grey area). That would be the right thing to do. Heartbeat provides added functionality and there will always be a market for that as well. I hope full support on DB residing on SQL clusters is not further delayed in the interest of the vCenter Heartbeat product.

In the end I will borrow Tom Petty’s words to tell VMware “Don’t do me like that”…

Kemp ESP – Microsoft Forefront TMG and beyond

A fellow vExpert pointed me to a product that I think is pretty cool and will probably fit the need of many who have been scratching their heads after the end of sale for Microsoft Forefront Threat Management Gateway. With virtualization and cloud computing, we tend to think that security is no longer needed. In my opinion, security has become even more important and has to be reworked with the way infrastructure is deployed these days. Specially in a multi-tenant environment.

Anyways, sticking to the topic here. Kemp Technologies is introducing there Edge Security Pack (ESP) which will enable you to continue deploying solutions like Sharepoint  MX etc securely. I am not an expert in this area but I try to keep up with whats happening around me. You can read up more on the solution here. Remember, just because your solution is virtual or in a cloud, doesn’t mean you no longer need security. It’s still required, and it has to be up to par with todays technology. Below is the introductory video of what the Kemp ESP is expected to do.

 

Disappearing data after a migration – Access-based Enumeration

One thing I love about windows is the fact that there is still a whole lot left for me to learn about windows. Not just big infra services that windows provides but little additions that have come about in the recent windows versions. Now I know what I am about to talk about is not exactly new, it was first introduced in Windows 2003 SP1. But this was something that fell off my radar and I didn’t really notice it until recently. So, I will try and publicize this in case it fell off your radar also.

So let’s say you have a share that users access. The share resides on a file server that runs Windows 2003. The share has 50 folders and not all users have access to all folders. When a user tries to access a folder to which access is denied, an access denied message appears. Awesome! Now you decide to take advantage of a newer OS and we will use Win 2008 R2 as an example. So you migrate the data over to the 2008 R2 file server and enable the share. Suddenly pigs starts flying,  your wife starts agreeing with you and Patriots start beating the Giants in the Super Bowl game. What happend?

So you start hearing things like, “Hey, I can only see 20 folders, before I was able to see 50”. You have people throw out all kinds of different numbers and your initial reaction is what in the world! Of course the folders are all there and you can confirm that when you login to the server yourself with your Administrative access. So what happened? Why are users not able to view all folders in the share? Well, your windows server just got a little more secure.

What you will start noticing is users are only able to see folders they have access to. So, if a user only has access to the “Finance” folder in the share, when this user accesses the share the only folder that will appear out of the 50 folders this share has is the “Finance” folder. Pretty nifty aye! So, if one doesn’t have access to a folder, the folder will be invisible. This is happening due to a feature called “Access-based Enumeration”. You can read more about it in this article. And yes, this is enabled by default. 

So the obvious question is, can this be disabled? Well without getting into why would you want to do this and all, the simple answer is YES. On the 2008 R2 file server, you will basically go to the properties of the share using the “Share and Storage Management” console.

Once there click the “Advanced” button in the “Sharing” tab and there it is. Unchecking the checkbox will disable this feature and your environment will be vulnerable once again. Your users will start seeing folders they dont have access to. My advise, leave it enabled. Why tease them when they can’t access it? 🙂

 

Multiple domains, vCenter and SSO

Not having blogged for sometime due to everything else that I have been involved in lately, I figured the new years will help me make time for myself. Well, its been 16 days since the new years so I guess a late happy new year to you. I have been playing around with some of the new features in 5.1. Recently somebody asked me about ways to handle access to a vCenter via different domains. Few months ago I would have pointed them to an AD guy and said build some kind of a trust.

A lot has changed in a few months obviously. SSO has come around, and more importantly it works (finally :D). I know low blow, oh well. Using SSO one can add multiple identity sources (AD, Open LDAP etc). You can have multiple AD identity sources added to the same SSO. So what does that mean?

When you install SSO on a windows server, the domain this server is on automatically gets added as an identity source in SSO. You can then pick users and group from here and assign them privileges. In addition to that, you can also add additional domains to the identity sources and assign entities in this domain access to vCenter as well. And its so simple that even I can do it. But I figured I will still write up a few steps and summarize the process as I can very easily forget what I did to make this work.

  1. In order to add users/groups from a domain, the domain needs to be added to the SSO identity sources
  2. The domain the SSO server is on gets added to the identity sources (in my case, the SSO server is on a domain called cloud)
  3. Login to SSO with Admin permission (default user admin@system-domain works but you can use a different account with same privileges as well)
  4. Click on Administration
  5. Click on “Configuration” under “Sign-on and Discovery”
  6. Click the plus sign on the top left 


  7. Add the appropriate info (In my case, I am adding a domain called “sunny.bilalhashmi.com” with an alias “SUNNY”) – I am using IP for the server URL as I dont have DNS resolution between the SSO server and the SUNNY domain. Ideally you would want to use the DNS name.



  8. Once you have entered the info, test the connection and hit OK, you should be able to add users/groups from the new domain (SUNNY domain in my case)
  9. When adding new users/groups, click on the drop down and you should be able to see the new domain. Select the new domain add the new permissions and you should be all set. Why do I have “Cloud” along with other things in the list? As I mentioned in Step 2, “Cloud” is the domain my SSO server is on, so it gets added automatically. 



  10. Again, no trust requirements between the domain. This is all happening due to our new friend SSO.
Obviously you will have to make sure connectivity between the the new domain and the SSO etc is working. I am unsure about the exact permissions that is needed in AD for making the connection to SSO. Remember in step 7, we add the username and pwd for the account in the domain to make the connection. I used the Administrator account that had all kinds of access. I believe an account that has access to query the accounts should be sufficient, but I havent tested that aspect. 


Why do you have folks from multiple domains coming into the same vCenter? Good question. One use case would be a customer who is supported by another company for their VMware infrastructure. In this case, both the customer and the supporting team can use their own accounts to carry on business. I personally hate having multiple accounts. Thats a recipe for being the account  lockout champion.