Skip to main content
Solved

Automatic Installation AD iData Agent with install.xml - Password hash (enyryption)

  • 10 February 2021
  • 19 replies
  • 598 views

We do automatic rollouts of Active Directory in Azure for our Customers with Ansible.

We want to install the AD iData Agent with the Unattend Package and Custom “install.xml” File.

These we are already doing successful for MA, Proxy and Restore Agent.

If you do Unattend AD Installation in the XML is PW for AD Agent needed. But it is expected a hash, but i cannot find what hash (for the PW) the Installer expect. Normal PW is not working and sha-256 hash of PW is not working, too.

This is the line in XML:

<activeDirectory>
               <userAccount password="3820c5c6992b6774aced93ecd88e04e35b4398d99e3f0a7d8"          domainName="q1xyz.local" userName="svc-adbackup" />

</activeDirectory>

So it would be important to know with what the setup when you create the package the PW encryptes, because during automatic rollout we get it from our central key Vault during installation.

 

19 replies

S
Rank
Userlevel 7
Badge +15

Hi Marcel

The hash seen in your example is a proprietary hash used internally with Commvault, so there aren’t any commands as such that you can use to generate these yourself.

One way to generate the hash from a pre-defined password is to follow the GUI process and then select “Save as Script” at the final stage which will output the password in hashed form to the XML.

Thanks,

Stuart

 

Customer Support
M
Rank
Userlevel 2
Badge +6

Hi Stuart,

thanks for you answer. Hmm that would not help us. Because we as Service Provider do a complete Rollout of AD SErvices and want generate during Rollout for the customer automatically a User and PW for AD Backup an save it in our Key-Vault. And afterward the AD IData Agent is triggered with XML and we want to use the generated password in the install.xml. So we have not the possibility to run the GUI. Somehow there must be a possibility to do this without the GUI for automation cases.

BR

Marcel

R
Rank
Userlevel 3
Badge +6

Hi Marcel,

You can use the utils class in the workflow engine to encrypt the password. 

EncryptedString es = utils.encryptString("AStrongerPasswordThanThis");
return es;

The above JAVA code in a script activity will provide an EncryptedString type as the output that you can use with the workflow activities that accept / require that type or you can output the string representation of it by simply appending the .toString() method… which in this case above provides the string “3929014b2f18bbbff1e1b1d074001001e369c664f2c0ae4ea24da75e3a0b34ba367c0c7960675041b” 

Does the format look familiar? … you can use this directly in the install XML.

Some process options you can consider:

  1. Call a workflow via Ansible, passing the password as an input, that simply returns the encrypted string for the input provided. Use that string with the rest of your existing process. (TIP: Put the workflow in API mode to avoid a job running and reduce the execution time.)
  2. Call a workflow via Ansible, passing the client, and AD settings that builds and executes an XML command to push install the AD agent to a new or existing CommCell client depending on your preference.
  3. Same as ‘2’ above but also have the workflow retrieve the password from your key vault 

 

M
Rank
Userlevel 2
Badge +6

Hey RMcG,

thanks for the reply, and the options to do this. We have to test if this EncryptedString works with the XML Process and is the way the encrypted Password is needed. Otherwise I will discuss with our automation team the other two options.

Is there somehow more documentation about the workflow engine and the classes?

Thank You very much we will test it.

BR Marcel

R
Rank
Userlevel 3
Badge +6

Hi Marcel,

I’m not aware of any published documentation on the built-in classes other than those in the Script APIs page in the Workflow section of the online docs.

@Seema Ghai here is a similar request to the other in the Workflow Script API thread. It would be beneficial to add some more of the useful methods from the built-in classes to the online documentation.

Onno van den Berg
Rank
Userlevel 7
Badge +19

@RMcG Feels a bit strange that you have to use a workflow to re-encode a password……. normally in this case you would use solutions like Azure Key Vault or Hashicorp Vault to store your secrets that you pull out during you configuration runs.

Additionally you can configure it through Command Center as well, so I do not see any need to leverage a workflow to re-encode the password into Commvault format. @Yash can you assist here how to set the password of the account that is used to run the AD agent level backup?

I b.t.w. had some discussions in the past with some people in regards to in-built key-vault functionality that leverages the credential manager that was introduced some time ago in order to automatically pullout credentials for specific agents based on rules. So for example if clientname=A and agent=B use credentials for username=C

R
Rank
Userlevel 2
Badge +2

@Onno van den Berg

Hi Onno

The context  of the use-case is in the original question. Its an unattended install XML that requires a Commvault credential in the Commvault hashed format. Its not a outcome solved by centralised credential management in Commvault or credential storage in other tools, In this case the specific Commvault format specified is required and Richard’s passed on a technique thats easily useable for an integrator working in an external context (Ansible playbook orchestrating a agent delivery including the injection of the required format of a credential into the install XML) to orchestrate.

Regards

-Roger

 

Onno van den Berg
Rank
Userlevel 7
Badge +19

It doesn't require the password for the agent to be installed but it requires the password to work correctly which is the difference. I just brought up an idea that password are required for more agents to work properly so for less experience coding customers an intelligent credential manager could do the same trick ;-)

But right now for more experienced users API's can definitely do the trick but I do not see the added value of re-encoding a password in Commvault format. Tere are more routes that you can following to achieve what Marcel is trying to achieve. Why blow-up the size if the installation package if you can trigger the installation of the agent via an API call that allows you to pass the password without the need to re-encode an password in another encoded password. 

R
Rank
Userlevel 2
Badge +2

For sure. In this case it looks like Install/Configure is being done.

Agreed a push install might be a better option. (Richard’s point #2), Sometimes push isn’t possible depending on the network/security configuration of the environment. Unknown as to whether that’s true in the authors case.  Anyway  - interesting challenge with many ways to solve.

 

 

M
Rank
Userlevel 2
Badge +6

@Onno van den Berg@Roger@RMcG 

Thank you very much for the discussion here.

Roger are right my point was to give the password direct with installation, (it is not needed at that point) but I thought it would be easy to do this directly and everything is finished. So we us as Hashi Corp Vault for the Credentials and for our complete AD Rollout for customers the credentials stored there. So if you have a nice way to do after the installation the settings for the Agent credentials it would be nice. Because we just started building template rollouts of different Agent Types. AD is just the beginning. If you have any hint for an nice way to use API calls after the deployment in combination with Hashi Vault would be great.

Thank you and would be happy to have a hint here for API calls with setting AD Agent PW.

Onno van den Berg
Rank
Userlevel 7
Badge +19

We did it in the same way in the past but it is much less flexible and to be honest the usage of a formatted XML that contains a password it not so much wanted these days. Everything that you can do through Command Center is API driven and api.commvault.com is the documentation for the API but it doesn't have all possible API calls documented hence my reach out to @Yash if he can shine some light on this. 

M
Rank
Userlevel 2
Badge +6

We did it in the same way in the past but it is much less flexible and to be honest the usage of a formatted XML that contains a password it not so much wanted these days. Everything that you can do through Command Center is API driven and api.commvault.com is the documentation for the API but it doesn't have all possible API calls documented hence my reach out to @Yash if he can shine some light on this. 


Thank You - Yes that would be nice @Yash ;-)

Y
Rank
Userlevel 3
Badge +4

@Onno van den Berg @Marcel Geisen APIs for creating and managing credentials are documented here: https://api.commvault.com/#591e022c-431d-421c-a7e0-3f1caadf29d3

M
Rank
Userlevel 2
Badge +6

@Onno van den Berg @Marcel Geisen APIs for creating and managing credentials are documented here: https://api.commvault.com/#591e022c-431d-421c-a7e0-3f1caadf29d3


Hey @Yash thanks but creating credentials not the problem as I wrote we create them during runtime of our Workflow for AD Rollout and save it in our Hash Corp Vault. When the CV AD Agent is deployed on the DC we want to set the Credentials created before on the CV AD Agent. First i thought it would be nice to do this during runtime with XML (but in the XML is a special HASH needed, no one can really provide) so it would be nice to have API calls for AD to set the credentials from Hashi automatically during runtime of the workflow on the Agent.

Thx a lot.

Y
Rank
Userlevel 3
Badge +4

@Marcel Geisen I think going with the option of encrypting password through WF as mentioned by @RMcG is a good option. You may call the Workflow through Rest API, fetch the encrypted password and insert it into your install xml.

M
Rank
Userlevel 2
Badge +6

@Marcel Geisen I think going with the option of encrypting password through WF as mentioned by @RMcG is a good option. You may call the Workflow through Rest API, fetch the encrypted password and insert it into your install xml.


Thanks @Yash@RMcG  Ok then we are at the question from the beginning is the workflow engine with classes somewhere more  documented? Because at the moment I’m not sure where to start at this point. Thx for the support.

Marcel

 

Y
Rank
Userlevel 3
Badge +4

@Marcel Geisen I’ve attached the WF with name: “EncryptPassword” which you could import and deploy in your CommServe.

 

Doc link on how to run this Workflow through RestAPI: https://documentation.commvault.com/commvault/v11_sp20/article?p=49437_1.htm

 

Curl Example:

Sample Request:

curl --location --request POST 'https://WebconsoleHostname/webconsole/api/Workflow/EncryptPassword/Action/Execute?outputOnly=True' \
--header 'Accept: application/json' \
--header 'Authtoken: QSDK 317cb0ecc7acaff884ebf5211b124ac09e97196c4cfbbb07e882ff42fe5c5a3b820aa71c42a93943c15a7a6681d6d593d4c377e8fbf919d5dd0a3b13eb3b525a54decbf34e99fd206e3f416455aff0e80f52ae183a71c5ac80636fc5e9585980c0b05c1759353f2ed40e38a71568429ab3b8661627648775cf99a7810ca34256df70857d9c2e58951d760c6505081ec165375428a9080ff1ec6ccf59fad9190d16aa59f3a7f5b85b27fc782c79d8065eab3e8288c90a14ff907e2a6c187be3fd1961437588be29583090bcfdf34ccdbc3c3d5d8408d319f3e5e5efed55ffa3ecedd1c68eb4a31fd9668333ed88fea7f143a3c37ef94d811fd818ab002b97de5a6350be05d0cffaaf740141b24e0e2c7a7' \
--header 'Content-Type: application/json' \
--data-raw '{
    "Workflow_StartWorkflow": {
        "outputFormat": "1",
        "options": {
            "inputs": {
                "password": "plainpassword"
            }
        }
    }
}'

 

Sample Response:

{
    "EncryptedPassword": "3aaf283a1811ff96f224e6d6ce5b0fa71fea7cec73f842e31"
}

 

With regards to documenting Workflow Engine classes, we didn’t do it as these are internal classes which may likely tend to change in the future.

 

Thanks,

@Chris Sunderland & Yash

1 Attachment
M
Rank
Userlevel 2
Badge +6

@Yash sorry for the late reply, Friday was to busy. Thank you very very much for putting that together. This is a real help. As soon as possible I will test and see how we can use it in our Ansible AD workflow.

Thanks man, made my day.

And thanks to all others here for the amazing support and thinking how to turn the wheel best ;-)

BR

Marcel

Juergen
Rank
Userlevel 3
Badge +8

Hello,

I configured workflow as described and put the password in my answer file but sorry it want not work, the "EncryptedPassword"  is longer as the password which is created when I use the packet creation.

Has anyone an idea, what going wrong?

I use V11SP20.40

BR

Juergen

PS: ERROR :  Installation EXITING (59) (FailedToRegisterClient)

Reply


Terms & ConditionsCookie settings