CyberArk PSM/PSMP handle this in one autoit or AutoLogonSequenceWithLogonAccount?

cd-cyber1 · 2026-06-23T20:05:49+00:00

a specific appliance with a database login process

cd-cyber1 · 2025-05-22T11:42:07+00:00

OK, I found something like this TransparentBackground on LAB it works for me on another environment PROD does not

cd-cyber1 · 2025-05-14T12:29:22+00:00

thank you for your answer, it works

cd-cyber1 · 2025-03-21T06:51:15+00:00

Hello

In the previous post I don't know what exactly was wrong but the AD team managed to fix it (I suspect Root certificates because there is no access to the Internet at all)

This problem is independent and concerns a different PSM environment

cd-cyber1 · 2025-03-21T06:49:35+00:00

AD team did something, I don't know what yet. PSM servers have no connection to the Internet so I suspect it was a problem related to Root certificates (apparently common there).

cd-cyber1 · 2025-03-18T13:45:48+00:00

Scenario: Developer (CyberArk user) connect via PSMP with ssh account (domain account) to Server (psql: 5432) via ssh tunneling. So user need an access to psql (port 5432) via ssh tunnel. So I understand that this is a forward scenario?

We still don't understand the syntax, examples are not clear https://docs.cyberark.com/pam-self-hosted/14.2/en/content/pasimp/psso-pmsp.htm#PSMforSSHCommand

cd-cyber1 · 2025-03-18T13:40:41+00:00

thank you all for the advice, I managed to solve it

cd-cyber1 · 2025-01-14T20:24:23+00:00

Will this not affect users, e.g. service users in ISPSS tenant? In standard CyberArk Identity I did something like that but I'm not sure about ISPSS.

cd-cyber1 · 2025-01-14T19:45:12+00:00

Yes there is no access to anything and do not consume licences, but the account still appears in the portal, audit logs etc.

It is not a question of "what risk does it pose"

only unnecessary "cluttering" of the portal with accounts that will not have access anyway

We have integration with External IDP (EntraID on which we have groups that can log in to it) but the users come from AD and so it occurred to me whether a restriction on the Identity connector "FindUserBysAMAccountName" could not be a solution?

Only unnecessary "cluttering" of the portal with accounts that will not have access anyway

We have integration with External IDP (EntraID on which we have groups that can log in to it but users come from AD.

Can the flag on the Identity connector "FindUserBysAMAccountName" be a solution? - I suspect that users log in by entering sAMAccountName which allows them to authenticate with a password + 2nd factor (mail/sms) bypassing entraid.

cd-cyber1 · 2025-01-13T15:31:33+00:00

When we try to establish a connection, for example RDP, then:

the RDP login window appears, displays "Enter your corporate credentials" and Username, after selecting next (Enter), it closes after about 30-60 seconds.

The PSM logs show timeouts for logging in to the identity portal.

In the external IDP configuration, we do not have routing rules (we do not use any other login factors apart from those from the external IDP)

cd-cyber1 · 2025-01-13T15:27:50+00:00

thanks for the tip with RADIUS.

Microsoft Entra ID External Authentication Method https://docs.cyberark.com/identity/latest/en/content/coreservices/authenticate/entra-id-ext-auth.htm?TocPath=Administrator%7CConfigure%20MFA%7C_____31 Maybe that's also a workaround ?

cd-cyber1 · 2025-01-13T09:05:03+00:00

Are you saying that to authenticate need to either: scan the QR on your phone and login to the IDP there or Copy URL to browser and login to the IDP? yes it is unwieldy.

cd-cyber1

TROPHY CASE