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

Hello again, an update:
Appears that the app connects properly, authenticates now using the app ID and its secret. Next step is failing though. It is about not able to get data from PWDM.

$AllEntries = (Get-DSEntry -VaultID $ServiceAccountRegistryVauldId -All).Data

This doesn't collect anything. I thoroughly checked the Vault's permissions and added the application as reader, as contributor, also with custom permissions, no change. The App just cannot retrieve anything from the Vault. I wonder what the proper permissions should look like?

Please advice! Thanks!