Qué vas a conseguir
Un CyberArk en el que las cuentas con más poder de la organización viven en safes con dueño, cambian de contraseña solas, se usan a través de una sesión grabada sin que nadie vea la credencial y, en las más sensibles, solo con una segunda aprobación y un ticket. Y el método para resolver el ticket más habitual de la plataforma: una cuenta que el CPM no consigue cambiar.
Vale para Privilege Cloud y para PAM self-hosted: cambia dónde vive el Vault y cómo se entra al portal; safes, plataformas, CPM y PSM funcionan igual (en Privilege Cloud, CPM y PSM son conectores en tu red).
Antes de empezar
- Un usuario con permisos de administración de safes y plataformas (en self-hosted, miembro de Vault Admins; en Privilege Cloud, el rol de administrador de Privilege Cloud).
- Al menos un CPM y un PSM con alcance de red a los servidores: el CPM habla con los controladores de dominio y los servidores (RPC/SMB, WinRM o SSH según la plataforma) y el PSM abre las sesiones RDP y SSH.
- Una cuenta de reconciliación por dominio: una cuenta del propio Vault con permiso para restablecer contraseñas en las OU de las cuentas gestionadas, y nada más.
- El inventario: qué cuentas privilegiadas existen, quién las usa y en qué servidores, servicios o tareas programadas está escrita cada contraseña.
1. Safes y sus miembros: el diseño que no se rehace
Un safe es un contenedor de cuentas con su propia lista de acceso. El error típico es un safe por equipo con todo dentro; lo que aguanta en el tiempo es un safe por tipo de cuenta y ámbito, con nombres que se entiendan solos.
- Los miembros son grupos del directorio, no personas: el alta y la baja del puesto se hacen en AD o Entra ID y el safe lo hereda.
- Connect only permite abrir una sesión por PSM sin ver ni copiar la contraseña. Es el permiso que lleva casi todo el mundo; Retrieve (ver o copiar) es la excepción y queda justificada.
- Quien administra el safe no usa sus cuentas sin pasar por el flujo de aprobación.
2. Dar de alta una cuenta con su plataforma
La plataforma decide cómo se trata la cuenta: cada cuántos días cambia, cómo se verifica, con qué cuenta se reconcilia y por qué componente se conecta. Tres casos habituales:
| Cuenta | Plataforma | Rotación | Conexión |
|---|---|---|---|
Administrador de dominio (adm-laura.prado) | Windows Domain Account | Cada 30 días y tras cada uso | PSM-RDP a servidores de salto |
Administrador local (Administrator en srv-file-01) | Windows Server Local Accounts | Cada 30 días | PSM-RDP al propio servidor |
Cuenta de servicio (svc-backup) | Windows Domain Account con sus dependencias | Cada 90 días, en ventana | No se usa para conectarse |
- En la cuenta de dominio, el campo Address es el dominio (
contoso.local) y el CPM cambia la contraseña contra un controlador de dominio. En la local, Address es el servidor. - La cuenta de reconciliación se asocia en la plataforma o en cada cuenta. Es la que el CPM usa cuando la contraseña del Vault ya no coincide con la real.
- Para una cuenta de servicio se dan de alta también sus dependencias (servicio de Windows, tarea programada, grupo de aplicaciones de IIS): el CPM cambia la contraseña en el directorio y después en cada dependencia. Si no sabes dónde está escrita, no la pongas a rotar todavía.
3. Rotar, verificar y reconciliar: el ciclo del CPM
- Change: el CPM genera una contraseña según la política de la plataforma y la cambia en el destino. Puede ser periódico, tras cada uso (one-time password) o manual.
- Verify: el CPM prueba que la contraseña guardada en el Vault funciona. Es lo que detecta que alguien la cambió por fuera.
- Reconcile: si la verificación falla, el CPM entra con la cuenta de reconciliación y fuerza una contraseña nueva. Con reconciliar automáticamente cuando la contraseña no está sincronizada activado en la plataforma, no hace falta que nadie intervenga.
Pon primero las cuentas nuevas solo a verificar durante unos días. Si la verificación pasa, activa el cambio periódico; si falla, has encontrado una contraseña que alguien tiene escrita en algún sitio, antes de que la rotación rompa algo.
4. Conectarse por PSM y la doble aprobación
El administrador pulsa Connect sobre la cuenta, elige el servidor y el componente (PSM-RDP o PSM for SSH). El PSM abre la sesión con la credencial, la graba y el usuario nunca la ve. Para el usuario es un RDP normal; para auditoría, cada tecla y cada ventana quedan asociadas a una persona con nombre.
En la Master Policy (o como excepción por plataforma) se activan, para las cuentas más sensibles:
- Doble control: la petición de acceso necesita la aprobación de un miembro con permiso de aprobador del safe. El aprobador ve quién pide, qué cuenta, para cuánto tiempo y por qué.
- Motivo obligatorio y, si hay integración con el sistema de tickets, un número de ticket válido que se comprueba antes de conceder el acceso.
- Acceso exclusivo (check-in/check-out): mientras alguien tiene la cuenta, nadie más puede usarla, y al devolverla el CPM cambia la contraseña.
Las cuentas de emergencia y una cuenta de reconciliación como mínimo tienen que poder usarse si el Vault o el PSM no responden. Su contraseña se guarda fuera de CyberArk (sobre cerrado, caja fuerte) y su uso se avisa y revisa.
5. El ticket: "el CPM no puede cambiar la contraseña: la cuenta aparece en fallo"
La cuenta svc-backup aparece en rojo en la lista de cuentas:
Se lee de fuera hacia dentro:
- ¿Qué paso falló? No es lo mismo que falle el cambio en el directorio que el de una dependencia. El detalle de la cuenta y el registro del CPM (
pm_error.logyPMTrace.logen la carpeta Logs del CPM) lo dicen. - Acceso denegado (5) al cambiar en el dominio: la cuenta no puede cambiar su propia contraseña (la opción El usuario no puede cambiar la contraseña está marcada) o la directiva de dominio lo impide (antigüedad mínima de contraseña). La solución es una reconciliación, con una cuenta de reconciliación que tenga Restablecer contraseña delegado en esa OU.
- Error de inicio de sesión (1326) al verificar: la contraseña del Vault ya no es la real. Alguien la cambió por fuera. Se reconcilia y se averigua quién y por qué.
- Ruta de red no encontrada (53) o tiempo de espera: el CPM no llega al servidor o al controlador de dominio. Cortafuegos, DNS o el servidor apagado.
- Falla una dependencia: la contraseña ya ha cambiado en AD, pero el servicio o la tarea siguen con la anterior. Se comprueba que la cuenta del CPM tiene permisos de administrador en
srv-bkp-01y que la dependencia está dada de alta con el nombre exacto.
New-PASSession -BaseURI https://pvwa.contoso.local -Credential $cred -type LDAP$a = Get-PASAccount -search "svc-backup" -safeName "WIN-SERVICIO-BACKUP"$a.secretManagementautomaticManagementEnabled : Truestatus : failurelastModifiedTime : 1753862400lastReconciledTime :lastVerifiedTime : 1761552000Invoke-PASCPMOperation -AccountID $a.id -ReconcileTaskSi el CPM ya había deshabilitado la gestión automática, tras corregir la causa se reanuda con Resume. Y una pregunta para el cierre del ticket: si una cuenta de servicio que se usa en un solo servidor podría ser una gMSA, que Windows rota sola, ya no necesita que el CPM la cambie.
6. Revisar grabaciones y lo que miras cada mes
Las grabaciones de PSM están en la sección de grabaciones del portal (Monitoring › Recordings en PVWA), con quién, qué cuenta, qué servidor y cuánto duró. Se revisan con criterio: fuera de horario, largas con cuentas de dominio o con un motivo vago.
Cada mes:
- Cuentas en fallo o con la gestión automática deshabilitada: ninguna debería pasar de una semana.
- Cuentas privilegiadas del directorio que no están en CyberArk (un administrador de dominio nuevo creado a mano es la primera señal de que alguien se salta el proceso).
- Miembros de cada safe frente a la lista de personas del equipo y permisos Retrieve que siguen activos sin motivo.
- Aprobaciones concedidas sin ticket válido y usos de cuentas de emergencia.
Siguientes pasos
- La guía de Microsoft 365: Global Admin y PIM es la pieza complementaria: PIM controla los roles de Entra ID y Microsoft 365 con activación temporal; CyberArk, las cuentas y contraseñas del directorio local y de los servidores.
- Microsoft Sentinel: los eventos del Vault y del PSM enviados por syslog permiten alertar de una cuenta de emergencia usada o de una aprobación fuera de horario.
- ISO 27001/NIS2/RGPD en IT: el control de accesos privilegiados es uno de los primeros puntos que pide una auditoría, y las grabaciones son la evidencia.
¿Falta algo o en tu entorno es distinto? Escríbeme y lo corrijo.
What you'll get
A CyberArk where the most powerful accounts in the organisation live in owned safes, change their password by themselves, are used through a recorded session without anyone seeing the credential and, for the most sensitive ones, only with a second approval and a ticket. And the method for the most common ticket on the platform: an account the CPM can't change.
It holds for Privilege Cloud and for PAM self-hosted: what changes is where the Vault lives and how you sign in to the portal; safes, platforms, CPM and PSM work the same (in Privilege Cloud, CPM and PSM are connectors in your network).
Before you start
- A user with rights to administer safes and platforms (self-hosted: member of Vault Admins; Privilege Cloud: the Privilege Cloud administrator role).
- At least one CPM and one PSM with network reach to the servers: the CPM talks to domain controllers and servers (RPC/SMB, WinRM or SSH depending on the platform) and the PSM opens the RDP and SSH sessions.
- A reconcile account per domain: an account held in the Vault itself with the right to reset passwords in the OUs of the managed accounts, and nothing else.
- The inventory: which privileged accounts exist, who uses them and on which servers, services or scheduled tasks each password is written.
1. Safes and their members: the design you don't redo
A safe is a container of accounts with its own access list. The typical mistake is one safe per team with everything in it; what lasts is one safe per account type and scope, with names that explain themselves.
- Members are directory groups, not people: joiners and leavers are handled in AD or Entra ID and the safe inherits it.
- Connect only allows opening a PSM session without seeing or copying the password. It is the permission almost everyone gets; Retrieve (show or copy) is the exception and is justified.
- Whoever administers the safe doesn't use its accounts without going through the approval flow.
2. Onboarding an account with its platform
The platform decides how the account is handled: how often it changes, how it is verified, which account reconciles it and which component connects with it. Three common cases:
| Account | Platform | Rotation | Connection |
|---|---|---|---|
Domain admin (adm-laura.prado) | Windows Domain Account | Every 30 days and after each use | PSM-RDP to jump servers |
Local admin (Administrator on srv-file-01) | Windows Server Local Accounts | Every 30 days | PSM-RDP to the server itself |
Service account (svc-backup) | Windows Domain Account with its dependencies | Every 90 days, in a window | Not used to connect |
- For the domain account, the Address field is the domain (
contoso.local) and the CPM changes the password against a domain controller. For the local one, Address is the server. - The reconcile account is linked on the platform or on each account. It is the one the CPM uses when the Vault's password no longer matches the real one.
- For a service account you also onboard its dependencies (Windows service, scheduled task, IIS application pool): the CPM changes the password in the directory and then on each dependency. If you don't know where it is written, don't put it on rotation yet.
3. Rotate, verify and reconcile: the CPM cycle
- Change: the CPM generates a password according to the platform's policy and changes it on the target. It can be periodic, after each use (one-time password) or manual.
- Verify: the CPM tests that the password stored in the Vault works. This is what detects that someone changed it outside CyberArk.
- Reconcile: if verification fails, the CPM signs in with the reconcile account and forces a new password. With automatically reconcile when the password is out of sync enabled on the platform, nobody needs to step in.
Put new accounts on verify only for a few days first. If verification passes, enable periodic change; if it fails, you have found a password someone has written down somewhere, before rotation breaks something.
4. Connecting through PSM and dual control
The admin clicks Connect on the account, chooses the server and the component (PSM-RDP or PSM for SSH). The PSM opens the session with the credential, records it and the user never sees it. For the user it is a normal RDP session; for audit, every keystroke and window is tied to a named person.
In the Master Policy (or as an exception per platform), for the most sensitive accounts you enable:
- Dual control: the access request needs approval from a member with approver rights on the safe. The approver sees who is asking, for which account, for how long and why.
- Mandatory reason and, if the ticketing system is integrated, a valid ticket number checked before access is granted.
- Exclusive access (check-in/check-out): while someone has the account, nobody else can use it, and when it is returned the CPM changes the password.
Emergency accounts and at least one reconcile account must be usable if the Vault or the PSM is down. Their password is kept outside CyberArk (sealed envelope, physical safe) and any use is alerted and reviewed.
5. The ticket: "the CPM can't change the password: the account shows a failure"
The svc-backup account shows in red in the account list:
Read it from the outside in:
- Which step failed? A failed change in the directory is not the same as a failed dependency update. The account details and the CPM log (
pm_error.logandPMTrace.login the CPM's Logs folder) say which. - Access denied (5) when changing in the domain: the account can't change its own password (User cannot change password is ticked) or domain policy prevents it (minimum password age). The fix is a reconcile, with a reconcile account that has Reset password delegated on that OU.
- Logon failure (1326) on verify: the Vault's password is no longer the real one. Someone changed it outside CyberArk. Reconcile, and find out who and why.
- Network path not found (53) or a timeout: the CPM can't reach the server or the domain controller. Firewall, DNS or the server is off.
- A dependency fails: the password has already changed in AD, but the service or task still has the old one. Check that the CPM's account has admin rights on
srv-bkp-01and that the dependency is onboarded with its exact name.
New-PASSession -BaseURI https://pvwa.contoso.local -Credential $cred -type LDAP$a = Get-PASAccount -search "svc-backup" -safeName "WIN-SERVICE-BACKUP"$a.secretManagementautomaticManagementEnabled : Truestatus : failurelastModifiedTime : 1753862400lastReconciledTime :lastVerifiedTime : 1761552000Invoke-PASCPMOperation -AccountID $a.id -ReconcileTaskIf the CPM had already disabled automatic management, once the cause is fixed it is resumed with Resume. And one question before closing the ticket: if a service account used on a single server could be a gMSA, which Windows rotates by itself, it no longer needs the CPM to change it.
6. Reviewing recordings and what you check each month
PSM recordings are in the portal's recordings section (Monitoring › Recordings in PVWA), with who, which account, which server and how long. They are reviewed with a criterion: out of hours, long ones with domain accounts or with a vague reason.
Each month:
- Accounts in failure or with automatic management disabled: none should stay that way for more than a week.
- Privileged directory accounts that are not in CyberArk (a new domain admin created by hand is the first sign someone is bypassing the process).
- Each safe's members against the team's list of people, and Retrieve permissions still active for no reason.
- Approvals granted without a valid ticket, and uses of emergency accounts.
Next steps
- The Microsoft 365: Global Admin and PIM guide is the complementary piece: PIM controls Entra ID and Microsoft 365 roles with time-bound activation; CyberArk, the accounts and passwords of the on-premises directory and the servers.
- Microsoft Sentinel: Vault and PSM events sent over syslog let you alert on an emergency account being used or an out-of-hours approval.
- ISO 27001/NIS2/GDPR in IT: privileged access control is one of the first things an audit asks for, and recordings are the evidence.
Is something missing, or different in your environment? Get in touch and I'll fix it.
Tech Career Lab · newsletter
¿Te ha servido? Cada dos semanas envío una idea práctica para perfiles IT: LinkedIn, proyectos, networking y procesos de selección.Found this useful? Every two weeks I send one practical idea for IT professionals: LinkedIn, projects, networking and hiring processes.
Apúntate y llévate las 33 ideasSign up and get the 33 ideas →