Authentication workflow of the operating system connections within the new database agents (94062)

How does the authentication works for the operating system (OS) connections within the new database agents?

It is not possible to set credentials via Global Administration and/or agent properties.

Within version 5.6.4 the OS data collection changed. Now the database agents are not collecting the OS data anymore. It will be done by the infrastructure agent. The infrastructure agent is collecting OS data and is sharing it with every database agent, which is monitoring a database on the server. So there is only one agent collecting OS data and not - as it was before - several agents (DB agents) which are collecting the same data. This approach reduces the load on the monitored server and the network and avoids duplicate data. Only very database specific OS data will be collected by each agent itself, for example: CPU per SQL Server instance.

The credentials for the OS connections can be configured via "Credentials" dashboard. Specific lockboxes can be created and re-used for different agents and several credentials can be assigned to one lockbox. Each credentials could have a more or less specific resource mapping. So in case you have one Windows user to access several server in your environment, you can create one credential and the resource mapping allows the Agent Manager to use this credential for several server. If the OS credentials for an already existing agent needs to be changed, do it via "Managed Credential" dashboard.

When a new database agent will be created, the auto discovery wizard will ask for the lockbox, which should be used. If you do not change it to an already existing lockbox, the default lockbox "DB-Agent-Lockbox" will be created and used. This OS credential will be used for the database specific OS data only.

If the infrastructure agent does not exist when creating a new database agent, a new infrastructure agent will be created automatically.

The connection workflow changed. Now the infrastructure and database agent do not know anything about the OS credentials. The created lockboxes have to be assigned/released to an Agent Manager, while you can assign/release one lockbox to several Agent Managers. The Agent Manager is knowing the credentials now and is creating the needed connections. The agent itself is requesting a connection from the Agent Manager and according to the agent type the Agent Manager is creating the needed connection and hand this connection over to the agent.

The advantage of the lockboxes are: Only few members of the team are knowing the users and passwords. The team member which is creating agents, can use already existing lockboxes for the connections without knowing anything about users and passwords. Also a lockbox can be protected by a password, so that only few team members are able to change the lockboxes/credentials.

Currently only the OS connections are handled that way.