Using non-admin account for report purposes

Excuse me, I posted it twice in the forum. Wasn't aware that there is a review going on before the topics appear.

Hi ,

Yes, that is possible. What is blocking you is not a vault permission, which is why allowing the account everything inside the vaults changed nothing.

Devolutions Server records which kinds of client may sign in with an account, per account and instance-wide. The PowerShell module signs in as a Scripting client, or as CLI with -AsApplication; on the account it sits under Application access, in the Access section, where Scripting has a row to set to Allow. An administrator skips this check, so your admin account cannot show it to you.

That row is allowed by default, so if yours was never changed, check also that the authentication type your service account uses is enabled instance-wide, and whether an MFA requirement applies to it, which a scripted login cannot answer. On the user-and-password path the module reports only that the login failed, never which check refused it.

For unattended work use an application identity instead, under Administration - Application identities: you grant it only the vaults it needs, its account type is always accepted, MFA does not apply, and it is created with CLI access allowed, so the sample's New-DSSession -AsApplication connects as it stands (check CLI is allowed in the instance-wide application list too). It also returns the server's own message, which names a client-access refusal specifically, and whether it is the account's own setting or the instance-wide one, though not the other two.

https://docs.devolutions.net/server/web-interface/administration/user-and-security-management/applications-identities

https://docs.devolutions.net/powershell/devolutions-server-powershell/powershell-connectivity-methods-to-devolutions-server

Give it View on the vaults or entries, and withhold View password and Connect (execute) - the two rights that hand back the credential. Note that the export function itself requires View password as well as Edit and the vault's export permission, so a password-blind account gets a short file rather than an error; build the report by listing the entries and picking the properties you want.

If it still will not connect, post your Devolutions Server version and what your script reports.

Best regards,

Michel

Thank you Michel, I am trying your way but I am still having issues. Cant connect with the app identity either.

I created a new app identity, gave it access to all vaults (there is no CLI allowed in the Application identities set up or I cannot find it).

Then I created the new credential in my credential store (used a combination of name/secret and also app ID/secret for a test)

Still cannot authenticate.

This is what I have:

-------

$CredentialName = "svc-PwdmReportExporterAppIdentity"

$Credentials = Get-AutomationPSCredential -Name $CredentialName # this is to retriever the stored credential from an Azure automation account credential store

$BaseURI = "https://pwdm.blabla.bla"

New-DSSession -Credential $Credentials -BaseURI $BaseURI -AsApplication

--------

Hi ,

You are right, and it is not something you overlooked as an application identity has no CLI setting of its own. That row is instance-wide, under Administration > System settings > Application access, in the Applications table - one line per client, with an "Is allowed" column, and the line you want is Cli.

First, capture what the server says, because with -AsApplication it does return its own reason:

try { New-DSSession -Credential $Credentials -BaseURI $BaseURI -AsApplication -ErrorAction Stop } catch { Write-Output $_.Exception.Message }

Otherwise the failure is a non-terminating error in a runbook: the script carries on and the text goes to the job's error stream, not your output. Three of the messages you can get:

1. "Invalid username or password, please verify your credentials." - the username has to be the

Application ID and not the identity's name, which you may already have tried; the same text covers

a secret that does not match.

2. "Application access denied by system settings. Please contact your administrator." - the Cli line

above is not allowed.

3. "The request timed out." - no answer at all rather than a refusal; that limit is the module's own

and defaults to 15 seconds, so try -Timeout 120.

Either way, post what it prints and your Devolutions Server version. Several of the other checks share one generic wording, so the exact text is what narrows it down.

The secret is shown only while you create the identity. If it was not copied then, use Regenerate application secret - and update the credential stored in your Automation account with the new value, or the login fails with the first message above.

Best regards,

Michel

Hey ,

Good, the login is behind you. For this next step the likeliest cause is the script rather than the permissions, and it is worth ruling out first because it produces exactly what you are seeing, with no error at all - which is why nothing you changed on the vault made any difference.

Since module version 2024.2 many of the DS cmdlets no longer return a ServerResponse wrapper. Get-DSEntry writes the entries themselves onto the pipeline, so the ".Data" on the end of your line resolves to nothing even when the call worked. It does not leave you with an empty variable, though:

$AllEntries comes back with one blank element per entry it retrieved, so if the count is non-zero and every value in it is empty, that confirms it. Drop it:

$AllEntries = Get-DSEntry -VaultID $ServiceAccountRegistryVauldId -All

If you would rather leave the rest of the script alone, add -AsLegacyResponse to that call instead and the old .Data shape comes back.

If it still comes back with nothing, then it is worth looking at permissions - and a refusal here is not silent. A vault the identity may not read makes the call report an error rather than return nothing, and in a runbook that error goes to the job's Errors stream, not your output. Print $Error[0] immediately after the call and you will have it either way.

On a recent module the wording is "Failed to retrieve the contents of vault '<id>'. Verify that the vault ID is valid and that you have permission to access it." On an older one you get an unexpected-exception error from Get-DSFolders that says nothing about permissions at all - read that one as the same thing.

As for which permission it is: listing a vault's entries is gated on the identity's own access to that vault's content, which you grant on the application identity itself. That is a separate layer from the per-entry permissions you were adjusting on the vault.

It takes one of two forms depending on your instance. If the identity's dialog has a Vaults tab, ticking the vault there is the grant, and you said you gave the identity access to all vaults - so that part is already done, which puts this back on the .Data above. If it shows Role assignments instead, add an assignment scoped to that vault; the built-in Vault User role carries that one permission and nothing else, which makes it the right starting point for a read-only report.

Two version numbers would still help: your Devolutions Server version, and the module version from Get-Module -ListAvailable Devolutions.PowerShell. The module version is what decides which of those two error texts you get.

Best regards,

Michel