Now that Orchestrator is up and running, we can start configuring it. We will configure Orchestrator to use SSO for authentication as well as an external database.
Wait! We did say that Orchestrator is preconfigured. So, what is already actually there ready to be used?
The Orchestrator Appliance comes with an embedded PostgreSQL database as well as a configured LDAP directory service. The LDAP contains the vcoadmin
user that we just used to log in. In addition to this, Orchestrator has a self-signed packaged certificate and a 90-day trial license. Both of these items are stored in the embedded PostgreSQL database, which also means that these items have to be recreated when you use a new and empty external database.
What is not configured is any connection to the vSphere environment. We will do this in the next chapter. In this chapter, we will have a look at how one can replace the preconfigured database and authentication with an external database and SSO authentication.
We will use the Orchestrator workflows to configure Orchestrator. In Chapter 4, Working with Workflows, we will take a closer look at how one can run workflows and deal with errors. If you experience any problems with the following instructions, skip forward to Chapter 4, Working with Workflows, and have a look at how to deal with errors in workflows.
The first thing that we should do is configure Orchestrator to use SSO. You don't necessarily need do this. You can operate Orchestrator by using its internal LDAP authentication. However, if you want to use Orchestrator in production, the best option is SSO authentication. If you prefer to keep the local authentication with the vcoadmin
users, then just skip this step.
First, let's add the SSL certificate of the SSO component to Orchestrator, as follows:
https://
and then the FQDN of your vCenter Server (if you are using the embedded SSO/PSC) or your Platform Services Controller (PSC) followed by :7444
.Now, we add Orchestrator to SSO.
:7444
.[email protected]
as well as the corresponding password.[Short domain name][usergroup]
form. Please note that this entry is case-sensitive.The internal PostgreSQL database can be used. However, as already mentioned, an external database is better. We will now connect a MS SQL database to Orchestrator.
If you would like to connect an external PostgreSQL or Oracle database to Orchestrator, the same process is used.
The package certificate that we will now create will make sure that all the workflows that you create are stored with your name or the company's name. Later, when you export and import workflows (see Chapter 9, Packing It All Up), you will see that the package certificate will always stay with them.
Now that everything is configured, we will need to license Orchestrator. This is done by using the vCenter license. Also, there is a workflow that lets you use the vCenter license directly. However, there are some differences between vSphere 5.x and vSphere 6. So, for the sake of simplicity, we will just enter the 25-letter vCenter license key. You can skip this step if you would like to use the 90-day trial license that Orchestrator is automatically configured with.
It might be a bit weird to run a troubleshooting workflow now, but due to an easy and fast configuration, we are going to clean up a few things. Please make sure that these steps are carried out before we can go on and enjoy Orchestrator.
Form |
Example |
---|---|
[Short AD domain name][username] |
|
[username]@[[FQDN AD domain name] |