...
In a VFC system, numerous entities exist containing credential-type data. The endpoints covered in this article allow changing the credentials programmatically. With the following functionality, a custom integrator application can be implemented to rotate passwords of the different entities from a common password vault solution. With this approach, common technical accounts' password leakage or sharing can be prevented. This article introduces how these credentials can be managed via the v1 REST API in the following sections. To get generic information about REST API usage, please visit the Use the REST API article.
| Table of Contents |
|---|
For the applications that manage credentials in the system, the following actions are required:
...
The Active Directory Synchronization Profile entities contain credential data to be able to connect to an LDAP server or an a Microsoft Entra (formerly Azure AD) tenant. The updateable properties are various and depend on the type of the AD Synchronization Profile entity.
...
When there are differences, then a few configuration API endpoints will respond with an HTTP 409 Conflict status and error code PREREQUISITE_NOT_MET.
Step 1: Retrieve the list of the differences in for a certain specific server.
Request:
| Code Block |
|---|
GET https://VFC_MR_DOMAIN/verba/restapi/v1/servers/verbamr01/configurationDifferences |
...
| Code Block |
|---|
{
"differences": [
{
"path": "\\Verba\\Email Settings\\TLSKeyPass",
"valueRegistry": "old encrypted password",
"valueDb": "NEW ENCRYPTED PASSWORD",
"serverCustom": false
},
{
"path": "\\Verba\\Email Settings\\TLSCert",
"valueRegistry": "foo",
"valueDb": "",
"serverCustom": false
}
]
} |
Step 2: Resolve the differences
Based on the retrieved information, the differences must be resolved by specifying which data source contains the correct values. For the resolution, a list has to be sent with the correct data sources.
...
If there are no more differences in the configuration, then an empty list should will be retrieved. In another case, the resolution must continue. During this step, when the central database value is chosen, then configuration tasks will be created for the server.
...
Step 2: Applying the configuration changes on the server
With the The following request can be used to list the created configuration tasks can be listed.:
| Code Block |
|---|
GET https://VFC_MR_DOMAIN/verba/restapi/v1/servers/verbamr01/configurationTasks |
If there is any item in the retrieved list is not empty, then those the tasks have to must be applied to that server. The actual application is done by the following requestthe server:
| Code Block |
|---|
POST https://VFC_MR_DOMAIN/verba/restapi/v1/servers/verbamr01/configurationTasks |
...
| Code Block |
|---|
PUT https://VFC_MR_DOMAIN/verba/restapi/v1/configurationProfiles/1/configuration?settingPath=%5CVerba%5CEmail%20Settings%5CTLSKeyPass NEW ENCRYPTED PASSWORD |
After one change, every server is affected that uses the changed configuration profile. Due to that , so the necessary configuration tasks have been created by the system for every related server. In the case of a configuration profile, there is no need to resolve differences. The following request retrieves the list of the created configuration tasks for every each server.
Request:
| Code Block |
|---|
GET https://VFC_MR_DOMAIN/verba/restapi/v1/configurationTasks |
...
| Code Block |
|---|
POST https://VFC_MR_DOMAIN/verba/restapi/v1/servers/verbamr02/configurationTasks |
Use case: Configure a
...
newly installed VFC server based on
...
the configuration of another existing server
In cloud-based solutions, to decrease the load of a server load , a possible solution is to start a new server with the same role to balance the load during peak times. This example shows a way how configuration management can be achieved for a similar use case.
In the example deployment, the verbamr01 server already exists and is configured. A new MR server has been started with a default configuration with the hostname verbamr02. With the recommended solution, the common configurations should be collected configured in a the configuration profile. In this case, firstly, the used configuration profile should be determined with the following request:
...
From this response, the configurationProfileId can be read out. That configuration profile can be set to the new server with the following requests. Firstly First, get the current server object from the new verbamr02.
...
That configuration list should be used as a template. After changing the values in the template, it can be sent for import to the new server with the following request:
...
After the configuration changes, the generated configuration tasks should be applied on to the new server.
| Code Block |
|---|
POST https://VFC_MR_DOMAIN/verba/restapi/v1/servers/localhost/configurationTasks |