vCO - rights management for WebViews

Yesterday i try to publish a WebView which should be used by only one user group of my Active-Dirctory. After a few attempts i decide to describe the whole process with some pictures. So the goal for todays article is to get only access to the workflow based under "Customer2".

At first you have to define the rights at the root object (Edit access rights....):




Because of the rights heredity you have to enable minimum the "View" right for all objects.



 

In my case a set a view more. After setting the rights for my user group: "Benutzer" which is an Active-Directory group every folder in my hierachy inherits the rights. If you log in to the WebService portal for example, every user in "Benutzer" can view, execute and inspect all folder.

When setting the rigths at the root object is done you have to edit the access rights for the folders you whish to hide. Similar to the steps at the root object you have to select "Edit access rights..." on the folder you want to hide. As you can see the folder has inherited its rights from the parent object (root). Now you have to set the rights, or better the restriction to the folder.

Restrictions in child objects are set by deselecting the rights (cruel sentence...). So deselect all rights and choose the same user group "Benutzer" as before.

After that you can verify the settings and press "Save and Close". Now do the same step for alle folders you want to hide.

In my example the "Customer2" folder is an child of "Customer". Regarding this my parent folder "Customer" needs all the rights set in the root object. If you change the rights here it will affect the child folders! Next we hide my "Customer1" folder because my users should only see workflows in "Customer2". You can do this exactly the same way as for the other folders.

  

As done before we "Edit access rights..." and deactivate all rights for the "Customer1" folder.

After that the child object has no rights and prevails to the parent object. On the "Customer2" folder you have nothing to change (if the parent rights in root are the right ones) because it is visible and the workflows can be executed and inspected.

Now you can logon at the WebViews portal with a user from the Active-Directory group you have enabled ("Benutzer").

In my case the user "Raketen RJ. Joe" can now create a simple virtual machine with his user rights in my vCenter Orchestrator WebViews :-) #

I hope this simple instruction helps you to design a rights management for you administration or user team.

white paper - vCO and secure ldap

Based on the problems at one of our enterprise customers, i decide to releas a white paper which describes the possibilities to implement the vCenter Orchestrator in a secure ldap environment.



The download is available at our Mightycare website:
http://www.mightycare.de/system/files/download/MCS-Whitepaper_vCO_and_ldaps_v0.5.pdf

Please note that the described solution is a workaround, i prefer the more secure PKI based solution.

vCO - secure ldap configuration - UPDATE

Today i had a configuration problem with a larger vCO environment with several domains... After starting the ldap configuration an error code 8 occurs and i had to change to secure ldap (SSL). After this change the vCenter Orchestrator want a new CA certificate for authentification. No problem, if you had an CA and export the CA request (.csr). But in my case i thought they had a "normal" ldap on port 389 and i create an simple self-signed CA.



The problem is: After creating a self-signed Certificate there is no way to create a new request with the company defaults! Deleting all cert* files and restart the configuration server does not work at all.

So you had to install the vCO again... :-( and can not import a configuration, because of the self-signed certificate.

UPDATE #1:
After consulting the vCO installation guide i found out that the certificate is stored in the Database: vmo_keystore. So after cleaning it up you are able to create a new certficate.



With this new certificate, based on the customer data i export the .csr (request) file and send it to the central certificate instance.

UPDATE #2:
Several days after my last attempt my fellow Andreas try to implement the AD SSL/TLS certificates and identifies another problem: the customer doesn´t use certificates in his AD! So after a few mails the basic problem is the NTLMv2 authorization, which is not supported in the ldap configuration.

So we try to find a fix for that and will inform you guys shortly.

UPDATE #3:
Yes, we found the solution!!! After hours of attempts, thinking about it and several coffee cups a simple GPO (thank you Microsoft!) was the cause for all the trouble.



Because the Java engine uses simple bind the connection handshake with the domain controller fails. After turning of the ldap signing request option everything works fine. The second problem was the reverse DNS wich wasn´t right.

So, lessons learned and beer earned!