A while back I wrote about my plans for my Organizations within vCD. As you might recall I’m trying to keep theme going by using my fictious company “Corp, Inc” that I’ve used in my previous SRM and View books. This time around I’ve moprhed Corp Inc into a “holding company”, a business that contains many business. There’s nothing about vCD that requires this construction – but I thought the scenario would be more interesting and lend itself to more “multi-tenancy” approach – because each of the business within Corp Inc, Holdings has a discrete and seperate identity – this lends it well to both a private and public cloud environment. Just remind you I have really four Organizations within the company:
- CorpHQ – This contains the executive team for the holding company. I felt this would be go place to show how vCD catalogs can be “published” the wider business
- istoxs – This an online stockmarket company – which handles the small trades made by “daytraders” in the US market
- Quark – This an alogorthimtic trading company, and its named after its key algorthim “Quark”. It does thousands of transactions per second, second guessing the market and making trades faster than human traders ever could
- CIOG – This a company that has been setup to handle Corp, Inc Holding overseas investments. Each of the business are quite big and its the profits generated from by the companies founders (the Moorcroft Family) that allows this investiment company to exist. The long term plan is to float CIOG to allow members of the public to benefit from CIOG investment expertise.
For me Organizations act as security boundary – in that we can control who can access them using conventional permissions and user rights, but we can also control the network traffic that takes place within and without them. Each Organization get its own “portal” that different users can login into – and that allows for quite sophisiticate teiring of responsibilities. I’m going to engage these standard roles in my organizations so I can “see it from the tenant’s perspective”. I’m hoping that by living within the rules and regulations of the users role that will help me remember what they can and cannot do. Rather than remembering lists of user role privelges. Before you create an Organization there’s a number requirements you’ll need to consider these include:
- The Name of the Organization
- LDAP Authentication
- Catalog Publishing
- Email Preferrences
- Policies
The Name:
The name of the organization is quite obivious. It’s important to keep it short and sweet as it get’s appended to the URL of the vCD cell(s) such as https://vcloud.corp.com/corphq or https://vcloud.corp.com/quark. As the name of the Organization goes towards building these URLs the best practise is to aviod spaces and special characters in the name – because some web-browsers react strangely to those.
LDAP or Local Authentication:
When it comes to authentication there’s a number of choices. You can configure an OU structure on the domain to reflect the different organizations – and then allow the Organization just to be able to “see” the users and groups in that Organization. Alternatively, each Organization can have its one per-Org LDAP configuration. There’s also the possibility of using local users held on the vCD cell itself. This last option I think is undesirable – because resetting passwords and password policies won’t be inherited from LDAP. There’s a whole bunch of limitations with local users which makes their use debatable.
- Groups cannot be used
- A minimum length of 6 character only
- No password complexity policies
- No password expiration policies
- No password history
- No authentication failure controls
- No integration with enterprise identity management system
However, I think there’s one proviso to that – which is what if your LDAP environment was down or unavailable? How would authenticate to your Organization then? For this reason it is recommended you have at least one “local” user per Organization to protect you from this situation.
To give myself proper exposure to different options I’m going to use the OU approach for the CIOG Organization. I’m imagining the investment company as being quite small – say a couple of people in the City of London and couple of people in Wall Street, who don’t need an entire domain to themselves. The Corp, Inc Holding company keeps these folks on a quite tight leash and wants to keep them under their control. In contrast the other business iStoxs and Quark – were originally acquisitions that had their own public identify. They haven’t ever been rolled into the “Corp, Inc” machine – and have maintained their own internal staff and management. For these I’m going to establish a domain structure that they manage independently within their Organization. This means their settings on passwords, policies and so on remain on their hands. With this appraoch I can use both the system wide LDAP settings and also the Organization wide settings. To be fair I’m only really doing this configuration to expose myself to the options – I think it would be unlikely that mulitiple Organizations would feel “comfortable” sharing the same directory service (even if they are seperated by OU). The other complexity is giving them access to an OU structure that was flexible enough for them to their own user/group constructions – or even LDAP policies. But I’m going to persist with this model mainly for the exposure.
If you want to use configure LDAP within the wizard that allows you to create an Organization – you must either add a system based LDAP entry (that can be used for all Organizations) or link to the Organizations custom LDAP service.
Catalog Publishing:
vCD calls is holding of vApps and other files (iso images – floppies? if you like!) as being organized into catalogs. These can be shared WITHIN an organization to help Catalog/vApp Authors create collections of VMs (or vApps) that constiute a service offering. Optionally, these catalogs can also be published BETWEEN organizations. When they are published to other organizations they are read-only – which means no-one else can modify or change its settings. So you can see it as “privilege” that some Organizations have and others don’t. In a public cloud this corresponds to a market place of virtualized services. In the private cloud I see more as the way my holding company – will offer standard approaches to deploying new applications whilst at the same allowing each Organization a degree of automony in being able to build out its own catalog of applications which are specific to their business needs. There is third state for a catalog which is “private” which allows just for the catalog author to have rights.
Email Preferrences:
Email preferrences are a lot like LDAP settings – you can either use the default settings from the system OR you can have per-Organization email settings.
Policies:
The policies settings allow you configure per-Organization policies concerning – leases, quotas, limits and password lockout policies. Lets take each one of these in turn.
Leases control the maximum amount of time a tenant and can use a particular resource – whether it be RAM/CPU/DISK. think the intention of leases is to curtail the rise of so called “Zombie VMs” or VM-Sprawl. The intention is to stop tenants from setting up and forgetting about their VMs, and running them as if they were “free” of cost. There are couple of options – you can set a “vApp Runtime Leases” which controls how long a vApp can “live” after its powered on for the first time. If the lease time is reached then vCD will power off the vApp by default. This sort of lease prevents a vApp from consumming CPU/Memory resources unneccessarily. There are also “Storage Leases” as well, and the timer on this lease starts when a vApp is powered off for the first time – as consequence storage leases do not affect running vApps. Storage Leases can be triggered by other tasks such as adding a vApp template into a vApp, or when a vApp is downloaded, copied or moved. When a Storage Lease runs out the vApp can either be marked as “expired” or can be deleted.
Quotas control how many VMs a tenant can create and power on. When its set in the creation of the Organization it sets a default for all new users of the Organization.
Limits are intended to stop particular tasks (that could be run simulataniously) from overburdening the system. To me they are very much like the limits you see in VMware View. VMware View makes requests to the underlying vCenters – and there are settings to control their concurrency to stop things getting overloaded. The other intention I guess is top potential DDoS attacks by an Organization that has become compromised. These limits can be applied to the Organization, the user and to tasks like opening up the Remote Console on a VM.
Password Policies basic control what happens with repeated failures to login – its standard fair – such as whether the features is enabled, how many attempts the get, and also how long they have to wait before they can try again.
Enabling Secure LDAP and Kerberos for vCloud Director
For me I had to sort out my LDAP settings to allow for me to allocate an OU to my first Organization – CorpHQ. As you might recall I wanted to just use an OU to contain the users for this Organization. To start I created an OU in my AD environment for the corp.com domain, and populated it with some users.
The next step was to configure the system wide LDAP for vCD. There’s two ways of doing this secure and non-secure. The secure option uses certificates from LDAP, and encyption to secure the communications to/from the vCD cell to the director service. In the past I’ve only used non-secure communications (because it is easier) so I decided to set myself a challenge of working our how to do this.
The first step was to enable SSL of Microsoft AD LDAP – fortunately because of my recent work with VMware View & Certificates for the eucbook.com – one of my domain controllers already had a Enteprize Root CA installed to it. I generally use an Enterprize based RootCA because it adds the root CA certificate to any client/server added to the domain using the default domain GPO.
I found Chris Stole’s blogpost “Enable LDAP over SSL (LDAPS) on Windows 2008 Active Directory Domain” very good starting point, but I didn’t have to adjust much relative to his article. I found with the domain controller holding the root CA role it already had a certificate and was responding to Secure SSL requests. I could test this using the ldp.exe ultility…
So I decided to go right ahead and try to configure the vCD System LDAP settings directly.
1. Navigate to the “Administration” view, >System Settings and LDAP node
2. Type in the DC name using an FQDN, 636 for the Secure LDAP port number and Base Distinguished Name – in my case this is dc=corp, dc=com
3. Enabled X Use SSL and X Accept all certfificates
4. At the same time I decide to enabled Kerberos based authentication – this is an inherently more secure authentication method because you have to get past the tripple throated dog of Hades first. Do that you switch the authentication method from “Simple” to “Kerberos“
5. Next I had to specify some parameters for the realm, by clicking the “Edit Realms” button. Using the “Add” button – I added in the name of the realm “CORP.COM” together with the KDC FQDN. Notice how the realm is specified in upper-case (although there is the option to allow lower-case realms if needs be)
Under the “DNS” tab in the Edit Realms box, I specified the DNS options. This involves select the realm just added and specify the DNS by the convention of .corp.com. I got this piece of information from a KB article on this subject.
6. The last step was specify a username (in the UPN/email format) together with a password
7. Finally, click the “Apply” button to save my settings – and with fingers-crossed clicked the “Test LDAP Settings” button. Success!
8. Did search for the user rmoorcroft (Reggie Moorcroft) to see if that would pull in results as well.
Note: The email and telephone properties are normally blank by default on a brand new AD user. To make things pretty (i love green ticks) I filled those in.
The other thing I found was I now had an “LDAP” option along side my SSO configuration I configured a couple of weeks ago. Under the Users and Groups nodes when I click the “Import” button(s)
Right. The LDAP system wide settings were in place. So I was ready to create my first Organization. WooHoo!
Adding an Organization in vCloud Director
1. Organizations can be added using the home page link called “5. Create new organization” and by naviagating to the “Manage & Monitor” tab, selecting the Organizations node and click the + icon. I completed the name, friendly and description fields like so:
2. In this case I used the VCD system LDAP Service, but limited the scope of searches to particular OU within Active Directory. The Distinguished Name in my case is – ou=CorpHQ-Organization,dc=corp, dc=com
3. As per best practises I did add a generic “corphq-orgadmin” account as contingency in case the LDAP services are not available.
4. Next I configured the Catalog settings for the CorpHQ. In my mind the Organizational structure is tree like – with CorpHQ being the top of that tree (representing the interests of the holding company), with the other Organization being sub-branches of that root. For me it makes sense that CorpHQ might want to make available a catalog that all the organizations (or even new ones) could use to be build out their environment.
5. Next I configured the email settings for the CorpHQ organization
Note: Of the end of this dialog box is option to test the email settings – this will fail if you haven’t configured the SMTP options in the vCD system. These are located within the “Administration” tab, >System Settings, and Email.
6. Finally, I setup the default policies. In the end I decided to just accept the defaults – because at this stage I’m not sure what would be appropriate settings for the Organizations. One thing that is worth noting is that the default behaviour is that there are NO quotas. So people with rights to create new vApps are unchecked, and could create as many vApps as they liked.
7. Finally, all I need to do was delegate responsibility the CorpHQ for someone else to take the “Organization Administrators” role. This meant navigating to the Organization’s portal itself, and configuring the settings. As the System Admin I have rights to do this – or alternatively, I could tell the Organization Owner of the local accounts username and password, and allow them to complete the configuration. To do this I told Reggie to navigate to:
URL: https://vcd01.corp.com/cloud/org/corphq/
Username: corphq-orgadmin
Password: Reggie’s special password! 😀
8. Then he navigated to Administration, > Members, Groups and using the Import button – added in the “CorpHQ Organization Admins” group from Active Directory. After logging off I was Reggie was able to login as rmoorcroft@corp.com to the Organization.