NetBackup Console on CyberArk PAM: How to Onboard It

If your organization requires the NetBackup Windows administrative console to run through CyberArk Privileged Session Manager, treat it as a desktop application integration problem. Check the CyberArk Marketplace for an existing supported connector first. If none fits, CyberArk documents a Custom Universal Connector workflow that uses AutoIt to launch the application, receive session properties from PSM, automate authentication, and hand the application process back to PSM for monitoring.

That is the useful answer behind a very short administrator discussion. The original requirement was simple: the team had already onboarded a web console, but now needed to onboard the NetBackup administrative console executable. A commenter pointed directly to AutoIt and CyberArk's Universal Connector documentation.

Why is onboarding an EXE different from onboarding a web console?

A web console usually fits a browser based PSM connection component. CyberArk can launch a browser, navigate to a URL, inject or broker credentials, and record the privileged session using a familiar web workflow.

A Windows executable is different because the login form, window class, process lifecycle, child windows, credential fields, and application behavior belong to a native client. PSM needs a connection component that knows how to start that program and complete its login sequence without exposing the privileged password to the user.

That is why the requirement should not be reduced to “add this EXE to CyberArk.” The connector has to understand the application launch and authentication flow.

If the security requirement can be met with NetBackup Web UI administration, the NetBackup 11 Web UI and RBAC guide is relevant because browser access may be simpler to govern. If the desktop console is specifically required, continue with a native PSM connector design.

Should you look for a ready-made connector first?

Yes. CyberArk's own Universal Connector documentation points administrators to the CyberArk Marketplace before building a custom component. A supported or community connector can save development effort and may already contain the application launch, process handling, and login automation you need.

The Reddit discussion does not confirm that a NetBackup administrative console connector exists in the Marketplace, so do not assume one is available. Search by NetBackup, Veritas, Cohesity, and the exact client application name used in your environment.

Also verify whether the connector matches the console version. Desktop management applications change window titles, executable paths, authentication dialogs, and controls across releases. A connector written for an older client may launch successfully but fail during login.

If no suitable connector exists, the documented Custom Universal Connector path is the safer next step.

How does the CyberArk AutoIt connector model work?

CyberArk's Custom Universal Connector uses an AutoIt script as the dispatcher for the target application. The script identifies the client executable, starts it, retrieves session information from PSM, automates the login process, and reports the application process ID so PSM can monitor the session.

CyberArk provides a skeleton named PSMAutoItDispatcherSkeleton.au3 in the PSM Components area. The documented workflow is to copy that skeleton to a development machine, define the target application executable, replace the login handling section with application specific logic, then test the connector with the supplied Generic Client Driver.

This is more structured than a normal AutoIt login macro. The connector uses the PSM Universal Connector API to retrieve properties such as username, address, and password from the privileged session. That keeps the credential flow inside the PAM architecture instead of hard coding secrets into a script.

Do not start by recording mouse coordinates. Build the connector around stable window controls, application states, and PSM session properties.

What should the NetBackup connector automate?

Automate only the steps needed to reach an authenticated NetBackup console session. That normally means launching the exact administrative console executable, waiting for the login window, populating the required server or domain information, supplying the privileged credential through PSM, submitting the login, confirming successful application startup, and reporting the correct PID to PSM.

The exact NetBackup dialog fields are not documented in the Reddit source, so they must be discovered in your installed console version. Record the executable path, main window title, window class, login dialog title, control identifiers, and any secondary authentication prompts.

If the NetBackup console delegates authentication to Windows or another identity provider, the connector may need a different flow than a console with its own username and password form. Prove this manually on the PSM development machine before writing automation.

For service account issues on the NetBackup server itself, the NetBackup domain account installation troubleshooting guide covers a separate identity layer. Do not mix NetBackup service accounts with the privileged user account CyberArk is brokering into the console.

Why does SendPID matter in a PSM connector?

CyberArk documents SendPID as the function that reports the connection client process ID to the PSM server. After that handoff, PSM monitors the target client and allows the normal user interaction defined for the session.

If the connector launches NetBackup and exits without reporting the correct process, PSM can treat the session as finished even though the console window is still visible. That creates confusing behavior where login automation appears to work and the session closes immediately afterward.

Native applications can also spawn child processes. Test which process owns the main usable NetBackup window after authentication. The process started initially may not be the process that remains active.

CyberArk also warns that the main application window title and class name matter for preventing the application from being hidden and for session recording. Capture those values during development and give them to the PSM administrator configuring the component.

How should the connector be tested?

Develop and test the AutoIt connector on a separate development machine, as CyberArk recommends. Use the Generic Client Driver and test values before moving the component to a production PSM server.

A useful test sequence is deliberately boring. First prove that the script launches the NetBackup console. Then prove it can detect the login window. Then retrieve placeholder session properties. Then populate one field at a time. Finally test a successful login and the correct PID handoff.

Also test failures. Use a bad password, unavailable NetBackup primary server, expired account, slow network, and unexpected dialog. A PAM connector that works only on the perfect path can lock administrators out exactly when they need emergency access.

The Generic Client Driver creates log output for connector testing. Keep those development logs because they are much more useful than debugging an opaque production PSM session after deployment.

How should the custom connector be packaged?

CyberArk documents compiling the AutoIt script into a 64 bit executable and packaging it with the files required by the connection component. The package includes a package.json file that identifies the client application paths PSM needs to permit through AppLocker.

This packaging step matters because a custom executable copied casually onto a PSM server may be blocked even if the AutoIt logic is correct. The target NetBackup executable, dispatcher, required DLLs, and any additional dependencies need to be part of a controlled deployment design.

CyberArk recommends compiling AutoIt rather than running raw scripts directly with AutoIt3.exe because that reduces security risk. It also advises against placing the executable directly under C:\ and documents using the PSM Components structure and deployment tooling.

Treat the package like privileged access code. Version it, review changes, sign where your process requires it, and keep a known-good rollback copy.

What security mistakes should be avoided?

Do not write the NetBackup password to disk, print it to logs, display it in a dialog, or leave it visible in the application after login. CyberArk's guidance explicitly warns connector developers to prevent credentials from being exposed through the user interface and to clean up sensitive data written during a session.

Do not give users control before the automated login is complete. PSM can block user input during the login process, and the connector should call the appropriate handoff only after authentication reaches the intended state.

Also restrict what the PSM session can launch. A privileged NetBackup console session should not become a general purpose desktop where the same vaulted credential can be reused in unrelated applications.

Finally, test session recording and termination. Closing the NetBackup console should end the connection cleanly, and disconnecting the PSM session should not leave an authenticated console running unattended on the PSM host.

What would I implement for this NetBackup requirement?

I would first search the CyberArk Marketplace for a maintained connector that matches the NetBackup administrative console version. If none exists, I would build a Custom Universal Connector from CyberArk's supplied AutoIt skeleton on a separate development workstation.

The first milestone would be reliable launch and process tracking, not credential injection. After that works, I would add PSM session property retrieval, automate the exact NetBackup login controls, call SendPID only after the console is authenticated, and test session recording and cleanup.

The source discussion gives one direction, AutoIt, and CyberArk's current documentation supports that direction. It does not provide a ready-made NetBackup connector or a finished script. Building the integration as a standard PSM Universal Connector keeps the design supportable and avoids turning a privileged administrative login into a fragile desktop macro.