Una aplicación que funciona al iniciarla desde el Explorador de archivos no encuentra su archivo de configuración al iniciarla desde el Programador de tareas. ¿Por qué?

Porque variables de entorno como %APPDATA% se resuelven al perfil del usuario que está ejecutando el programa. Cuando la tarea se ejecuta como SYSTEM o con otra cuenta, las variables de entorno apuntan a un perfil distinto (bajo systemprofile en el caso de SYSTEM), y el archivo de configuración que guardó no existe ahí. Compruebe la cuenta con la que se ejecuta la tarea y, como corrección permanente, coloque los datos que deban compartirse bajo ProgramData.

Una contraseña guardada con ProtectedData.Protect ya no se puede descifrar una vez que la aplicación se convirtió en servicio.

DPAPI en el ámbito CurrentUser depende de la clave maestra del usuario que cifró los datos. Si el servicio se ejecuta con una cuenta distinta, la clave maestra es otra, así que el descifrado falla con una CryptographicException. Rediseñe un secreto que lean tanto el servicio como el usuario interactivo para usar el ámbito LocalMachine más una ACL de archivo, o ejecute el servicio con la cuenta de quien lo cifró.

¿Qué ocurre cuando un proceso que se ejecuta como SYSTEM lee HKCU?

En un proceso LocalSystem, HKEY_CURRENT_USER está asociado al usuario predeterminado (HKEY_USERS\.DEFAULT), así que los valores que el usuario interactivo escribió en HKCU no son visibles. Coloque la configuración de toda la máquina en HKLM y, si de verdad debe leer la configuración de un usuario, suplante a ese usuario y luego use RegOpenCurrentUser.

¿Puedo copiar un perfil de Chrome/Edge con sesión iniciada a una máquina de CI y usarlo?

En general, no. El perfil de un navegador basado en Chromium como Chrome o Edge vive bajo el %LOCALAPPDATA% del usuario, y la clave de cifrado de cookies y contraseñas guardadas está protegida por el DPAPI de ese usuario. Copiar la carpeta a otro usuario o a otra máquina no consigue descifrar porque la clave no coincide (navegadores como Firefox, que tienen su propia protección de perfil, son otro caso). Para la automatización, codifique los pasos de inicio de sesión de una cuenta de prueba, o use el mecanismo de estado de almacenamiento de su herramienta de automatización.

Las credenciales guardadas con cmdkey no se usan cuando la tarea se ejecuta desde el Programador de tareas.

Porque la bóveda del Administrador de credenciales es distinta para cada usuario, y lo que guardó fue a la bóveda de su propio inicio de sesión interactivo. Además, una tarea configurada con «No almacenar la contraseña» (S4U) se ejecuta sin credenciales de red, así que introducir credenciales en la bóveda no ayuda mientras siga en S4U. Considere primero una configuración que almacene la contraseña o un cambio a una cuenta de servicio y, solo entonces, si aún hace falta, introduzca las credenciales en la bóveda de la propia cuenta de ejecución.

El «mismo PC» no es el mismo entorno de ejecución — El límite de usuario que separa AppData, HKCU, DPAPI y las credenciales

28 Aug 2026 01:00 · Actualizado el: 8 Sep 2026 · Go Komura · Windows, DPAPI, Registro, AppData, Credenciales, Programador de tareas

Historial de revisiones (primera versión, publicada el 28 Aug 2026)

28 Aug 2026: Primera publicación

La aplicación lee su archivo de configuración al iniciarla desde el Explorador de archivos, pero el Programador de tareas informa que «no se encuentra». Conviértala en servicio y ya no puede descifrar la contraseña guardada. El navegador de su escritorio tiene la sesión iniciada, pero en CI vuelve a la pantalla de inicio de sesión.

Con este tipo de problema, compruebe quién ejecuta el programa y cómo antes de mirar el código. Los archivos y la configuración que existen en el mismo PC no se pueden usar necesariamente de la misma forma desde un usuario de ejecución distinto.

La pregunta que responde este artículo es por qué una aplicación se rompe cuando no cambió nada en el código y solo se convirtió en una tarea programada, un servicio o un trabajo de CI. Si quiere partir del síntoma, vaya a la sección que coincida en la tabla siguiente.

Síntoma	Qué comparar primero	Dónde leer
No se encuentra el archivo de configuración o un comando	Usuario de ejecución, la ruta real de AppData, variables de entorno de usuario	AppData y variables de entorno
Falta un valor del registro que está seguro de haber escrito	El subárbol de usuario al que apunta HKCU	HKCU
El archivo se puede leer, pero el secreto no se puede descifrar	El ámbito de DPAPI y el propietario de la clave maestra	DPAPI
El estado de inicio de sesión del navegador no se transfiere	Usuario de ejecución, perfil, la clave protegida por DPAPI	Perfiles de navegador
No se pueden usar credenciales o certificados guardados	La bóveda y el almacén de certificados de la cuenta de ejecución, el tipo de inicio de sesión de la tarea	Credenciales y certificados
La unidad Z: desaparece al ejecutar como administrador	El token y la sesión de inicio de sesión antes y después de la elevación	Elevación UAC
Quiere una inspección completa antes de una migración	Las dependencias y la preparación de cada forma de ejecución	Lista de comprobación por forma de ejecución, Procedimiento de investigación

Supuestos de este artículo

Elemento	Contenido
Lectores previstos	Desarrolladores que convierten aplicaciones empresariales en servicios, tareas programadas o trabajos de CI, y personal de operaciones que investiga problemas de «en mi máquina funciona»
Entorno previo	Windows 10/11. El código de verificación se ejecuta en PowerShell 5.1 o posterior
Dificultad	Intermedio

1. Primero la conclusión

La unidad básica que particiona un entorno de ejecución de Windows no es el PC, sino el token de acceso y el SID, es decir, «quién ejecuta el proceso». AppData, HKCU, las claves DPAPI, los perfiles de navegador y las credenciales pertenecen al entorno de ese usuario.

La configuración y el estado de inicio de sesión que preparó bajo su propio inicio de sesión interactivo no se transfieren automáticamente a SYSTEM ni a otra cuenta de servicio. Las áreas para datos de toda la máquina son ProgramData y HKLM, y compartir a través de ellas sigue exigiendo diseñar los derechos de acceso.

flowchart TB
    accTitle: Dos mundos dentro del mismo PC
    accDescr: El mismo PC solo comparte HKLM y ProgramData, mientras que el mundo de su SID y el mundo de otro SID tienen cada uno su propio AppData, su propio subárbol de registro y sus propias claves DPAPI, invisibles entre sí a través del límite de usuario
    pc["Mismo PC"] --> shared["Compartido: HKLM y ProgramData"]
    pc --> wa["El mundo de su SID"]
    pc --> wb["El mundo de otro SID (SYSTEM etc.)"]
    wa --> ra["AppData, HKCU, claves DPAPI"]
    wb --> rb["Otro AppData, otro subárbol, otras claves"]
    ra -.-|"Límite de usuario: invisibles entre sí"| rb

Figura 1: En el mismo PC, un usuario de ejecución distinto significa un AppData distinto, un registro distinto y claves distintas.

Dicho esto, el mismo SID tampoco garantiza el mismo entorno. Compruebe también el tipo de inicio de sesión de la tarea, la carga del perfil de IIS y la diferencia de sesión de inicio de sesión que crea una elevación UAC. Elevarse dentro de la misma cuenta no convierte HKCU ni la bóveda en los de otro usuario; lo que importa es pensar por separado qué límites cambian.

El resto del artículo sigue este orden: el usuario de ejecución como premisa (capítulo 2), los cinco límites (capítulos 3 a 7), la comprobación por forma de ejecución (capítulo 8), y el diseño y la investigación (capítulo 9).

En el diagrama, una línea continua marca una relación que siempre se cumple y una línea discontinua una relación condicional (las condiciones están en la explicación de cada relación en la página de detalle). La lista completa de relaciones (33 en total, con evidencia y grado de certeza) y las definiciones de los conceptos principales están reunidas en la página de detalle del mapa de conocimiento (en japonés). Datos: JSON-LD / Turtle

2. Premisa: «Quién lo ejecuta» lo decide todo

2.1 Compruebe el SID y el token, no el nombre de usuario

El identificador que Windows usa para reconocer a un usuario no es el nombre de usuario, sino el SID (identificador de seguridad). Un proceso tiene un token de acceso, y el token contiene el SID del usuario de ejecución. Este principal de ejecución es el punto de partida siempre que razone sobre comprobaciones de ACL de archivos, el registro físico detrás de un alias o claves de cifrado.

Use whoami /user para la primera comprobación. Confirme el resultado en el entorno de ejecución donde ocurre el problema, no en su propio terminal.

> whoami /user

INFORMACIÓN DE USUARIO
----------------

Nombre de usuario SID
=============== =============================================
desktop\you     S-1-5-21-3623811015-3361044348-30300820-1001

C:\Users\you es la forma en disco del perfil de usuario ligado a ese SID. Un perfil consiste en un conjunto de carpetas como AppData y el subárbol de registro de usuario NTUSER.DAT. Como se copia del perfil predeterminado en el primer inicio de sesión, el perfil de otro usuario parte de un estado inicial distinto del entorno que usted configuró.¹

flowchart TB
    accTitle: De la ruta de inicio al perfil
    accDescr: Tanto si se inicia con doble clic, el Programador de tareas o un servicio o IIS, el proceso tiene el SID en su token de acceso, y el conjunto de datos de perfil de usuario ligado a ese SID se convierte en su entorno de ejecución
    e1["Doble clic"] --> tok["Token del proceso (SID)"]
    e2["Programador de tareas"] --> tok
    e3["Servicio o IIS"] --> tok
    tok --> prof["Conjunto de perfil ligado al SID"]
    prof -.-> note["Un SID distinto significa un perfil distinto, en estado inicial"]

Figura 2: La ruta por la que se inicia un proceso decide el perfil de qué SID lleva mientras se ejecuta.

2.2 Cada cuenta de servicio tiene un entorno propio

Windows tiene cuentas integradas que se ejecutan sin que inicie sesión una persona. Cada una tiene un entorno de ejecución independiente.²

Cuenta	SID	Adónde apuntan su perfil y su registro
SYSTEM (LocalSystem)	`S-1-5-18`	Perfil bajo `C:\Windows\System32\config\systemprofile`. HKCU está asociado al usuario predeterminado³
LocalService	`S-1-5-19`	Bajo `C:\Windows\ServiceProfiles\LocalService`. Tiene su propia subclave bajo `HKEY_USERS`⁴
NetworkService	`S-1-5-20`	Bajo `C:\Windows\ServiceProfiles\NetworkService`. Como LocalService, tiene su propio perfil y subárbol⁴
`IIS AppPool\<nombre>`	`S-1-5-82-…`	Una identidad específica del grupo. El perfil no se carga de forma predeterminada⁵

La diferencia entre las rutas de inicio de un doble clic, el Programador de tareas, un servicio e IIS se convierte en una diferencia de cuyo entorno se usa. No asuma que la configuración, las claves y las credenciales que preparó bajo su inicio de sesión interactivo existen también en ese destino de ejecución.

2.3 Tres condiciones que comprobar después de «el mismo usuario»

Condición que comprobar	Ejemplo de dónde se ve la diferencia
Tipo de inicio de sesión	Con el inicio de sesión S4U de una tarea, la contraseña no se almacena, y no se puede acceder a la red ni a EFS⁶
Carga del perfil	En IIS, `loadUserProfile` decide si AppData y el subárbol de usuario están disponibles⁷
Sesión de inicio de sesión y elevación	Incluso con el mismo SID, un proceso elevado puede no ver las unidades de red asignadas⁸⁹

No se detenga en comprobar el SID; use estas tres para ordenar qué difiere incluso con la misma cuenta. Las tareas se cubren en detalle en el capítulo 8, IIS en los capítulos 4 y 5, y la elevación en el capítulo 7.

3. Límite 1: AppData — La misma variable de entorno apunta a un lugar distinto

El síntoma típico es que el archivo de configuración deja de encontrarse en el momento en que la aplicación se convierte en una tarea programada. La resolución de la ruta no ha fallado; la ruta puede haberse resuelto correctamente a la ubicación de otro usuario, donde el archivo no existe.

3.1 Las divisiones de AppData y cómo las cambia el usuario de ejecución

AppData es una carpeta bajo el perfil de usuario. Sus usos se dividen como sigue.¹⁰

Área	Uso principal
`%APPDATA%` (Roaming)	Configuración de usuario que debe seguir al perfil cuando este se desplaza
`%LOCALAPPDATA%` (Local)	Datos y cachés locales de la máquina
AppData\LocalLow	Datos para procesos que se ejecutan con un nivel de integridad bajo

Aunque el mismo código abra %APPDATA%, la ubicación a la que se refiere cambia con el usuario de ejecución.

Usuario de ejecución	Ejemplo de dónde se busca el archivo de configuración
Usuario A	`C:\Users\a\AppData\Roaming\MyApp`
SYSTEM	AppData bajo `systemprofile`

El archivo que guardó el usuario A no existe del lado de SYSTEM. Un error que solo dice que falta el archivo de configuración no lo deja claro, así que durante la investigación mire la ruta que se abrió de verdad, no el nombre de la variable de entorno.

flowchart TB
    accTitle: Cómo se resuelve %APPDATA% depende del usuario
    accDescr: Aunque el mismo código abra %APPDATA%, se resuelve a una ruta bajo C:\Users si el usuario de ejecución es usted y bajo systemprofile si es SYSTEM, y su archivo de configuración no existe en este último
    code["Mismo código: abrir %APPDATA%"] --> q{"¿Usuario de ejecución?"}
    q -->|"Usted"| a["C:\\Users\\you\\AppData\\Roaming"]
    q -->|"SYSTEM"| b["AppData bajo systemprofile"]
    b -.-> miss["Falta el archivo que puso ahí"]

Figura 3: Las variables de entorno no mienten, pero adónde se resuelven depende del token.

3.2 PATH también difiere por usuario

Las variables de entorno del sistema las comparte toda la máquina, pero las variables de entorno de usuario son por usuario. Cuando un comando que añadió a su propio PATH no se encuentra desde un servicio, compruebe también esta diferencia.

Decida la ubicación de almacenamiento según quién lee los datos. La configuración solo de ese usuario va bajo AppData; los datos compartidos por todos los usuarios o por servicios van bajo %ProgramData%, y para estos últimos diseña las ACL. Para una forma detallada de elegir, vea «Cómo elegir el destino de almacenamiento de datos en una app de Windows ── Tabla de decisión: SQLite / JSON / Registro / Access».

flowchart TB
    accTitle: Elegir la ubicación de almacenamiento según sus lectores
    accDescr: Los datos que solo lee ese usuario van en AppData o HKCU, los datos compartidos con todos los usuarios o servicios van en ProgramData o HKLM, y estos últimos conllevan el diseño de ACL
    q{"¿Quién lee estos datos?"} -->|"Solo ese usuario"| f1["AppData, HKCU"]
    q -->|"Todos los usuarios, servicios"| f2["ProgramData, HKLM"]
    f1 -.-> w1["Reconsiderar si puede convertirse en servicio"]
    f2 -.-> w2["Diseñar permisos de escritura y ACL"]

Figura 4: «No puede leerlo una vez que se convirtió en servicio» es el resultado de saltarse esta rama en el diseño.

4. Límite 2: HKCU — «Usuario actual» cambia con el llamador

El síntoma típico es que un servicio no encuentra la información de licencia que escribió un instalador. Aunque la escritura y la lectura fueran ambas a algo llamado HKCU, no son necesariamente el mismo subárbol físico.

4.1 HKCU es un alias del subárbol del usuario

HKEY_CURRENT_USER (HKCU) no es un subárbol independiente; es un alias que se redirige a una ubicación física según el usuario que llama. En un proceso de usuario ordinario apunta a la clave de ese SID bajo HKEY_USERS. Su contenido es el NTUSER.DAT cargado al iniciar sesión.¹

La excepción es HKCU\Software\Classes, cuya ubicación física es un archivo de subárbol distinto, UsrClass.dat. Ese archivo vive bajo %LOCALAPPDATA%\Microsoft\Windows.¹¹

El HKCU de LocalSystem está asociado al usuario predeterminado (HKEY_USERS\.DEFAULT). Cuando un instalador que se ejecuta con una cuenta de administrador escribe en HKCU y un servicio SYSTEM lee de HKCU, ambos se refieren a sitios distintos.³

flowchart TB
    accTitle: Qué es realmente el alias HKCU
    accDescr: Cuando una aplicación abre HKCU, se redirige a su clave SID bajo HKEY_USERS en su proceso y a la clave del usuario predeterminado en un proceso LocalSystem, así que el valor que escribió el instalador ya no es visible
    app["Código de la app: abrir HKCU"] --> alias["HKCU es un alias de la clave real"]
    alias -->|"Su proceso"| ha["Su SID bajo HKEY_USERS"]
    alias -->|"Proceso SYSTEM"| hd["HKEY_USERS\\.DEFAULT"]
    hd -.-> gone["El valor que escribió no existe"]

Figura 5: Incluso bajo el mismo nombre HKCU, un usuario distinto significa que se lee y se escribe un subárbol distinto.

Coloque la configuración de toda la máquina en HKLM. Microsoft no recomienda acceder a HKCU desde un servicio. Si necesita leer la configuración de un usuario, suplante a ese usuario y luego use RegOpenCurrentUser.¹²

4.2 Compruebe también si el perfil está cargado

Más allá de la cuenta de ejecución, que el perfil esté cargado o no también puede ser el problema.

Los grupos de aplicaciones de IIS se ejecutan sin cargar un perfil de usuario de forma predeterminada. Activar loadUserProfile hace disponibles AppData y el subárbol bajo el perfil.⁷ Esta configuración también afecta a dónde se almacenan las claves de DPAPI y de ASP.NET Core Data Protection del capítulo siguiente.

La configuración de la tarea «No almacenar la contraseña» se comprueba por separado, como restricción del tipo de inicio de sesión. Aunque se indique el mismo usuario, un inicio de sesión S4U no puede usar la red ni EFS. Las diferencias concretas entre configuraciones se resumen en el capítulo 8.⁶

5. Límite 3: DPAPI — El cifrado está cerrado con «la clave del usuario»

Mientras que AppData y HKCU son problemas de buscar en un sitio distinto, DPAPI produce un problema en el que el archivo se puede leer pero su contenido no se puede descifrar. Convertir en servicio una aplicación que usa una contraseña guardada y obtener una CryptographicException es un ejemplo.

5.1 Un propietario distinto de la clave maestra significa que no hay descifrado

DPAPI (Data Protection API) es la facilidad de cifrado que Windows ofrece a las aplicaciones. Llamar a CryptProtectData o a ProtectedData.Protect de .NET permite a una aplicación proteger datos sin llevar una clave de cifrado en su propio código.¹³

Eso no hace innecesaria la clave. DPAPI usa una clave maestra gestionada por el sistema operativo. En el ámbito CurrentUser, una clave maestra por usuario generada al azar se protege con una clave derivada de las credenciales de inicio de sesión y se almacena bajo el perfil.¹⁴

flowchart TB
    accTitle: La cadena de claves de DPAPI
    accDescr: La clave maestra de usuario generada al azar está protegida por una clave derivada de las credenciales de inicio de sesión, esa clave maestra cifra los secretos de la aplicación, y la clave maestra de otro usuario no puede descifrar el mismo texto cifrado
    pwd["Credenciales de inicio de sesión"] -->|"Protege mediante clave derivada"| mk["Su clave maestra"]
    mk -->|"Cifra"| sec["Secreto de la app (contraseña guardada etc.)"]
    mk2["Clave maestra de otro usuario"] -.->|"No puede descifrar"| sec
    mk -.-> loc["Almacenada bajo el perfil"]

Figura 6: Los datos no se cifran directamente a partir de las credenciales; una clave derivada de las credenciales protege la clave maestra.

A continuación hay un ejemplo mínimo en el que el usuario A cifra datos, los coloca en una ubicación compartida y otro usuario intenta descifrarlos. Compartir la ubicación de almacenamiento no cambia quién puede descifrar bajo CurrentUser.

# En la sesión del usuario A: cifrar en el ámbito CurrentUser y guardar en una ubicación compartida
Add-Type -AssemblyName System.Security
$bytes = [Text.Encoding]::UTF8.GetBytes("secret")
$enc = [Security.Cryptography.ProtectedData]::Protect($bytes, $null, "CurrentUser")
[Convert]::ToBase64String($enc) | Set-Content C:\ProgramData\demo.bin

# Como un usuario distinto (por ejemplo, tras convertirse en SYSTEM con PsExec), intentar descifrar
$enc = [Convert]::FromBase64String((Get-Content C:\ProgramData\demo.bin))
[Security.Cryptography.ProtectedData]::Unprotect($enc, $null, "CurrentUser")
# → CryptographicException: La clave no es válida para su uso en el estado especificado.

5.2 Elija el ámbito según quién deba poder descifrar

Ámbito	Unidad de descifrado	Consideración de diseño
`CurrentUser`	La clave maestra del usuario que cifró los datos	No se puede descifrar una vez movido a una cuenta de ejecución distinta
`LocalMachine`	Una clave compartida por la misma máquina	Cualquier proceso de la misma máquina puede descifrar, así que restrinja quién puede leer el texto cifrado con una ACL de archivo

Un secreto que leen tanto un servicio como el usuario interactivo debe diseñarse desde el principio como LocalMachine combinado con una ACL de archivo, o el proceso debe ejecutarse con la cuenta de quien lo cifró. No cambie el ámbito solo para que desaparezca el error de descifrado; decida a quién se le permite descifrar. En máquinas compartidas, tenga también presente el riesgo de que la protección a nivel de máquina sea demasiado amplia.¹⁵

flowchart TB
    accTitle: Cómo elegir el ámbito de DPAPI
    accDescr: Elija el ámbito CurrentUser si solo ese usuario debe poder descifrar y el ámbito LocalMachine si deben poder varios principales en el mismo PC, y restrinja los lectores de este último con una ACL de archivo
    q{"¿Quién debe poder descifrar?"} -->|"Solo ese usuario"| cu["Ámbito CurrentUser"]
    q -->|"Varios principales en el mismo PC"| lm["Ámbito LocalMachine"]
    cu -.-> r1["El descifrado falla al ejecutarse como otro usuario"]
    lm -.-> r2["Restringir lectores con una ACL de archivo"]

Figura 7: Elija el ámbito como decisión de diseño sobre quién descifra, no como «el que casualmente funcionó».

5.3 Un «cambio» y un «restablecimiento» de contraseña son distintos

La clave que guarda la clave maestra depende de las credenciales de inicio de sesión. Cuando los usuarios cambian su propia contraseña, la clave maestra se vuelve a proteger con una clave derivada de la nueva contraseña, y la capacidad de descifrar se transfiere.

En cambio, cuando un administrador restablece la contraseña de una cuenta local, el texto cifrado anterior puede dejar de ser descifrable. Incluso con la misma cuenta, hay que comprobar cómo se cambiaron las credenciales.¹⁴

5.4 Compruebe también dónde se almacenan las claves en ASP.NET Core

Incluso el código que nunca llama a DPAPI directamente puede depender de este límite. ASP.NET Core Data Protection almacena el anillo de claves usado para proteger la autenticación por cookie y similares en una ubicación que depende del entorno.¹⁶

Entorno	Adónde van las claves y la consecuencia
Hay un perfil de usuario disponible	`%LOCALAPPDATA%\ASP.NET\DataProtection-Keys`. En Windows las claves se cifran con DPAPI
No hay perfil disponible y la aplicación está hospedada en IIS	Recurre al registro HKLM, con ACL para la cuenta del proceso de trabajo
No se aplica ninguno	Las claves se vuelven claves efímeras locales del proceso. Se pierden al reiniciar, y datos protegidos como las cookies de autenticación quedan inválidos

Compruebe loadUserProfile, setProfileEnvironment y el modelo de hospedaje como un conjunto, y entienda qué configuración decide dónde se colocan las claves. Lo que importa no es solo que la aplicación arranque, sino si puede usar las mismas claves después de un reinicio.

La elección de ámbito y cuándo usar en su lugar el Administrador de credenciales se cubren en detalle en «Almacenamiento de información confidencial en aplicaciones Windows - Cómo evitar la configuración en texto plano con DPAPI».

6. Límite 4: Perfiles de navegador — «Sesión iniciada» pertenece al usuario

Sesión iniciada en el escritorio, y sin embargo cuando CI lanza el navegador vuelve a la pantalla de inicio de sesión. Este problema se vuelve tratable cuando separa dónde se almacena el perfil de la clave de cifrado.

6.1 Hay dos límites: ubicación de almacenamiento y clave

El perfil de un navegador basado en Chromium como Chrome o Edge vive de forma predeterminada en la carpeta User Data bajo %LOCALAPPDATA%. El historial, las cookies, las extensiones, las contraseñas guardadas, etc. pertenecen al entorno de ese usuario de Windows.¹⁷

Las cookies y las contraseñas guardadas se cifran con una clave de cifrado dentro del perfil, y esa clave misma está protegida por DPAPI. Copiar la carpeta a otro usuario o a otra máquina falla por tanto al descifrar porque la clave no coincide.

Chrome reciente superpone App-Bound Encryption. El descifrado de la clave pasa por un servicio que se ejecuta con privilegios SYSTEM, que verifica no solo al usuario sino también la identidad de la aplicación que lo solicita.¹⁸ Esto se aplica a los navegadores basados en Chromium; la situación difiere en navegadores como Firefox que tienen su propia protección de perfil.

Límite	Qué ocurre en el destino de automatización
El límite de AppData	El usuario del agente de CI o del servicio no tiene el perfil que usa habitualmente
El límite de DPAPI	Aunque se copie la carpeta, la clave protegida no se puede descifrar

flowchart TB
    accTitle: Los dos límites detrás del estado de inicio de sesión de un navegador
    accDescr: El perfil del navegador vive bajo LOCALAPPDATA y pertenece al límite 1, y la clave de cifrado de cookies está protegida por DPAPI y pertenece al límite 3, así que ni el perfil ni la clave se transfieren a otro usuario
    prof["Perfil de navegador"] --> loc["Almacenado bajo LOCALAPPDATA"]
    prof --> key["Clave de cifrado de cookies protegida por DPAPI"]
    loc -.-> ci["El usuario de ejecución de CI recibe un perfil vacío y separado"]
    key -.-> copy["No se puede llevar copiando la carpeta"]

Figura 8: «Llevarse el estado de sesión iniciada» lo bloquean tanto el límite 1 como el límite 3.

6.2 En la automatización, deje explícita la forma de crear el estado de inicio de sesión

Selenium y Playwright se inician de forma predeterminada con un perfil temporal desechable. Así que incluso bajo el mismo usuario, el estado de inicio de sesión de su navegador cotidiano no se usa automáticamente.

Aunque especifique un directorio de perfil persistente, los problemas de ubicación de almacenamiento y de clave de la sección anterior permanecen en el momento en que pasa a un trabajo de CI o a un servicio bajo otro usuario. El remedio no es copiar un perfil con sesión iniciada, sino una de las siguientes.

Codificar los pasos de inicio de sesión de una cuenta de prueba.
Usar el mecanismo de estado de almacenamiento de la herramienta de automatización para guardar y restaurar cookies y similares de forma explícita.

Que otro usuario no pueda usar las cookies con una mera copia no es una molestia; es también un límite de seguridad. Diseñe la automatización partiendo de que este límite existe.

7. Límite 5: Credenciales y certificados — Cada usuario tiene una bóveda aparte

Las credenciales guardadas con cmdkey no se usan cuando se ejecuta la tarea, y falla la autenticación. Aquí también, compruebe no «se guardó en el PC» sino «con qué usuario se guardó».

7.1 El Administrador de credenciales es una bóveda por usuario de ejecución

El Administrador de credenciales, que puede inspeccionar con cmdkey /list, es una bóveda por usuario.¹⁹ Las credenciales guardadas están en disco, pero las protege DPAPI y las usan los programas que se ejecutan como ese usuario.²⁰

La bóveda contiene credenciales guardadas de servidores de archivos y unidades de red, tokens de Git guardados por git-credential-manager, contraseñas guardadas de conexiones RDP, secretos de aplicaciones que usan la API Credential, y así sucesivamente.

Estar en la bóveda de su inicio de sesión interactivo no las pone en la bóveda de la cuenta que ejecuta el servicio o la tarea. Prepare un paso de configuración que introduzca las credenciales necesarias en el contexto de la propia cuenta de ejecución. Cuando solo el git pull de su escritorio tiene éxito, compruebe también la diferencia de bóvedas.

Sin embargo, una tarea configurada con S4U no se corrige con solo introducir credenciales. Compruebe primero el tipo de inicio de sesión y considere una configuración que almacene la contraseña o un cambio a una cuenta de servicio. El orden de los pasos está en el capítulo 8.

flowchart TB
    accTitle: La bóveda de credenciales es por usuario
    accDescr: Su bóveda contiene credenciales de Git, credenciales guardadas de servidores de archivos y contraseñas RDP, pero la bóveda del usuario de ejecución del servicio está vacía a menos que se introduzcan credenciales, y eso es lo que realmente es el error de autenticación
    you["Su bóveda"] --> g["Credenciales de Git"]
    you --> n["Credenciales guardadas de servidores de archivos"]
    you --> r["Contraseñas RDP guardadas"]
    svc["Bóveda del usuario de ejecución del servicio"] -.-> empty["Vacía si no se introduce nada = el verdadero error de autenticación"]

Figura 9: «La autenticación funciona en mi máquina» es solo una abreviatura de «mi bóveda está disponible».

7.2 En los certificados, compruebe por separado el almacén y los permisos de la clave privada

Almacén	Límite y propósito
`Cert:\CurrentUser`	Almacén por usuario. La clave privada de un certificado de cliente colocado aquí se protege por usuario
`Cert:\LocalMachine`	Almacén de toda la máquina. Coloque aquí los certificados para servicios y conceda a la cuenta de servicio acceso de lectura mediante la ACL de la clave privada

Para un certificado usado por un servicio, el diseño básico es el almacén LocalMachine junto con la ACL de la clave privada.²¹ El almacén de usuario vive físicamente bajo HKCU\Software\Microsoft\SystemCertificates, así que queda dentro del límite de HKCU.²²

Para los detalles, vea «Guía práctica del almacén de certificados de Windows — ¿en el de usuario o en el de equipo?».

7.3 Con la elevación UAC, separe «la misma cuenta» de «una cuenta distinta»

Cuando un usuario administrador inicia sesión con UAC habilitado, se crean dos tokens vinculados: un token estándar con privilegios restringidos y un token de administrador completo.⁸

Las asignaciones de unidades de red son por sesión de inicio de sesión. Z: puede ser visible en el Explorador de archivos e invisible para una herramienta ejecutada como administrador.⁹

Cómo se ejecuta	Qué cambia y qué no
Elevación UAC permaneciendo en la misma cuenta	El SID es el mismo, y HKCU y la bóveda de credenciales siguen iguales. Las asignaciones de unidades, que son por sesión de inicio de sesión, pueden volverse invisibles
Elevación o RunAs con las credenciales de una cuenta de administrador distinta	El SID también cambia. HKCU y la bóveda pasan a ser las de ese administrador. AppData, las claves y el estado del navegador también quedan sujetos al límite del otro usuario

No asuma que todo «deja de funcionar al elevarse» es un cambio de usuario; compruebe primero si es la misma cuenta.

flowchart TB
    accTitle: La división dentro de un mismo usuario creada por la elevación UAC
    accDescr: Un inicio de sesión de administrador con UAC habilitado crea dos tokens, un token estándar y un token elevado, y una unidad de red asignada del lado del token estándar no es visible para un proceso que se ejecuta con el token elevado
    logon["Inicio de sesión del usuario administrador"] --> t1["Token estándar"]
    logon --> t2["Token elevado"]
    t1 --> d1["Unidad Z: asignada aquí"]
    t2 -.->|"Sesión de inicio de sesión distinta"| d2["La herramienta elevada no ve Z:"]

Figura 10: La elevación crea «otro mundo para el mismo usuario». El límite no es solo el SID.

8. Lista de comprobación por forma de ejecución

8.1 En las tareas, mire el tipo de inicio de sesión después de la cuenta de ejecución

En el Programador de tareas, lo que está disponible cambia con el tipo de inicio de sesión incluso cuando se indica el mismo usuario.⁶

Tipo de inicio de sesión	Qué comprobar
Token interactivo (InteractiveToken)	Una configuración que se ejecuta en la sesión que está iniciada
Contraseña almacenada (Password)	Una configuración que puede usar credenciales incluso cuando no es interactiva
S4U (contraseña no almacenada)	La contraseña no se almacena, y no se puede acceder a recursos de red ni a archivos cifrados (EFS)

Cuando una tarea no puede usar credenciales guardadas, compruebe primero la restricción S4U. No haga de añadir credenciales a la bóveda permaneciendo en S4U su corrección. Considere una configuración que almacene la contraseña o un cambio a una cuenta de servicio y, solo entonces, si aún hace falta, introduzca credenciales en la bóveda de la cuenta de ejecución.

Los detalles de la configuración se cubren en «Las tareas del Programador de tareas no se ejecutan o terminan con 0x1 — cómo aislar la causa y diseñar una operación segura».

flowchart TB
    accTitle: El tipo de inicio de sesión de la tarea como segundo eje
    accDescr: Una configuración de ejecución del Programador de tareas tiene un tipo de inicio de sesión de token interactivo, contraseña almacenada o S4U, y con S4U la contraseña no se almacena y no se puede acceder a la red ni a EFS
    task["Configuración de ejecución de la tarea"] --> lt{"Tipo de inicio de sesión"}
    lt -->|"Token interactivo"| it["Se ejecuta en la sesión iniciada"]
    lt -->|"Contraseña almacenada"| pw["Credenciales utilizables incluso sin interacción"]
    lt -->|"S4U (contraseña no almacenada)"| s4u["No puede alcanzar la red ni EFS"]

Figura 11: Incluso con el mismo usuario de ejecución, cómo se inició la sesión cambia lo que está disponible.

8.2 La tabla de inspección antes de cambiar el destino de ejecución

Forma de ejecución	Principal de ejecución	Límites y síntomas que inspeccionar en particular
Programador de tareas	La cuenta indicada al registrarla	Límites 1, 2, 3 y 5. Compruebe adónde apuntan AppData y HKCU, el descifrado de DPAPI y la bóveda. Con S4U no se pueden usar la red ni EFS
Servicio de Windows	SYSTEM, LocalService, NetworkService, una cuenta de servicio	Límites 1 a 5. SYSTEM usa systemprofile y el HKCU del usuario predeterminado; LocalService y NetworkService usan sus propios entornos bajo ServiceProfiles. Las claves, la bóveda y el estado del navegador del desarrollador no se transfieren
Grupo de aplicaciones IIS	Una identidad específica del grupo como `IIS AppPool\<nombre>`	Límites 1, 2, 3 y 5. Compruebe que el perfil no se carga de forma predeterminada, dónde se colocan las claves de Data Protection y el acceso a las claves privadas de certificados CurrentUser
RunAs / elevación UAC	El usuario indicado, o un token distinto del mismo usuario	Con la misma cuenta, el SID, HKCU y la bóveda son los mismos, y las asignaciones de unidades se ven afectadas por la diferencia de sesión. Con una cuenta distinta, inspeccione todos los límites 1 a 5
Agente de CI/CD	El usuario de servicio del agente. A menudo nunca ha iniciado sesión de forma interactiva	Límites 1 a 5. Compruebe dependencias del perfil y el estado de inicio de sesión del navegador, credenciales de Git, la configuración HKCU del desarrollador y datos protegidos por DPAPI
RDP / servidor compartido	Varias sesiones del mismo usuario, o varios usuarios	Varias sesiones del mismo usuario comparten AppData y HKCU, así que vigile conflictos de escritura. Usuarios distintos quedan separados por los límites 1 a 5

La última fila es una precaución en la dirección opuesta. Varias sesiones RDP del mismo usuario no dan a cada sesión su propio AppData y HKCU independientes. Aquí el problema no es que algo sea invisible, sino que se comparte y se escribe lo mismo.

9. Directrices de diseño y de resolución de problemas

9.1 Decida las ubicaciones de almacenamiento y la preparación a partir del principal que las usa

Destino	Bases de diseño
Configuración específica del usuario	Colóquela en AppData o HKCU
Datos y configuración compartidos por todos los usuarios o servicios	Colóquelos en ProgramData o HKLM, y diseñe permisos de escritura y ACL
Secretos	Elija el ámbito de DPAPI según quién deba poder descifrar. Con LocalMachine, diseñe también la ACL de archivo
Credenciales y certificados para servicios	Incluya en el procedimiento de preparación la introducción de credenciales en la bóveda de la cuenta de ejecución, la colocación del certificado en el almacén de certificados LocalMachine y el ajuste de la ACL de la clave privada

Si planea convertir la aplicación en servicio más adelante, incluya ese principal de ejecución entre los lectores en la etapa en que decide dónde almacenar. El principio es no llevar a operaciones una dependencia de «lo que casualmente existía en el entorno del desarrollador».

9.2 Investigue desde el principal de ejecución hasta la ubicación realmente referenciada

flowchart TB
    accTitle: Procedimiento de investigación de problemas de límite de usuario
    accDescr: Confirme el usuario de ejecución con whoami, mire el token en Process Explorer, identifique las rutas y las claves de registro realmente leídas con Process Monitor y, si hace falta, reproduzca desde el mundo del otro lado con psexec
    s1["Confirmar el usuario de ejecución con whoami /all"] --> s2["Comprobar el token en Process Explorer"]
    s2 --> s3["Identificar las rutas y claves reales con ProcMon"]
    s3 --> s4["Reproducir desde el mundo del otro lado con psexec"]
    s3 -.-> hint["Una ruta de perfil inesperada es la pista"]

Figura 12: Confirme el usuario de ejecución, mire las rutas y las claves de registro reales y luego reproduzca como el principal de ejecución de destino.

Paso	Cómo comprobar	Qué mirar
1. Confirmar el usuario de ejecución	Escribir `whoami /all` en el registro justo después del arranque	Si el principal de ejecución de la tarea o el servicio que falla es el mismo que en su escritorio
2. Comprobar el token	Process Explorer	El usuario y la sesión del proceso. ¿Es un usuario distinto, o un contexto de ejecución distinto del mismo usuario?
3. Mirar la ubicación realmente referenciada	Process Monitor	Las rutas de los archivos abiertos y las claves de registro. ¿Aparece en `PATH NOT FOUND` un perfil distinto del esperado?
4. Reproducir como el principal de ejecución de destino	Para SYSTEM, `psexec -s -i cmd`	Probar la misma operación desde un intérprete SYSTEM y confirmar las diferencias con su propio entorno interactivo

Cuando falta configuración, vuelva a AppData y HKCU; cuando el archivo se puede leer pero no descifrar, a DPAPI; cuando solo falla la autenticación, a la bóveda, los certificados y el tipo de inicio de sesión. No juzgue solo por el mensaje de error; el atajo es alinear «quién usó qué ubicación, con qué clave o credenciales».

10. Resumen

«En mi máquina funciona» significa «funciona como ese usuario, con ese perfil, con esas claves y esa bóveda». Incluso cuando se inicia el mismo .exe en el mismo PC, convertirlo en una tarea, un servicio o un trabajo de CI hay que tratarlo como una migración del entorno de ejecución.

AppData y las variables de entorno de usuario se refieren al perfil del usuario de ejecución, y HKCU apunta igualmente al subárbol de ese usuario. El ámbito CurrentUser de DPAPI depende de la clave maestra del usuario, y el estado de inicio de sesión del navegador y el Administrador de credenciales también se ven afectados por ese límite.

Además, incluso con el mismo SID, permanecen las diferencias de tipo de inicio de sesión, carga de perfil y la sesión creada por la elevación UAC. A la inversa, cuando varias sesiones del mismo usuario comparten AppData y HKCU, piense en conflictos de escritura.

En las revisiones de diseño, formule la pregunta siguiente.

¿Este código es correcto independientemente del usuario bajo el que se ejecute?

Proporcione de forma explícita las ubicaciones de almacenamiento, las claves y las credenciales necesarias para el principal de ejecución real. Confirme este principio antes de la migración y podrá reducir, ya en la etapa de diseño, la rotura en la que «el código no cambió y, aun así, se rompió».

Ámbitos de consultoría relacionados

KomuraSoft LLC se ocupa del diseño de entornos de ejecución cuando las aplicaciones empresariales se convierten en servicios o tareas programadas, de la investigación de fallos del tipo «en mi máquina funciona» y del diseño de la gestión de secretos para aplicaciones Windows.

Referencias

Microsoft Learn, About User Profiles. Sobre que el perfil de usuario se crea en el primer inicio de sesión, y sobre que un perfil consiste en el subárbol de registro NTUSER.DAT (cargado al iniciar sesión y asignado a HKEY_CURRENT_USER) y el conjunto de carpetas de perfil en el sistema de archivos. ↩ ↩²
Microsoft Learn, Local accounts. Sobre que SYSTEM (S-1-5-18), NETWORK SERVICE (S-1-5-20) y LOCAL SERVICE (S-1-5-19) son las cuentas de sistema locales predeterminadas usadas para ejecutar el sistema operativo y los servicios. ↩
Microsoft Learn, LocalSystem Account. Sobre que el token LocalSystem incluye NT AUTHORITY\SYSTEM, que no está asociado a ninguna cuenta de usuario con sesión iniciada y, en consecuencia, sobre que HKEY_CURRENT_USER está asociado al usuario predeterminado y sobre la necesidad de suplantar a un usuario para acceder al perfil de ese usuario. ↩ ↩²
Microsoft Learn, LocalService Account. Sobre que la cuenta LocalService tiene su propia subclave bajo HKEY_USERS, y sobre que HKEY_CURRENT_USER está asociado a la cuenta LocalService. Lo mismo se aplica a NetworkService (NetworkService Account). ↩ ↩²
Microsoft Learn, Application Pool Identities. Sobre que los grupos de aplicaciones se ejecutan bajo una identidad específica del grupo, que IIS no carga el perfil de usuario de Windows de forma predeterminada, y sobre establecer el atributo LoadUserProfile en true para cargar el perfil. ↩
Microsoft Learn, logonType Simple Type. Sobre los tipos de inicio de sesión de tarea que incluyen S4U, Password e InteractiveToken, y sobre que un inicio de sesión S4U no almacena la contraseña y no tiene acceso a la red ni a archivos cifrados. ↩ ↩² ↩³
Microsoft Learn, Process Model Settings for an Application Pool. Sobre los atributos loadUserProfile y setProfileEnvironment del processModel de un grupo de aplicaciones, que controlan si el proceso de trabajo carga el perfil de usuario. ↩ ↩²
Microsoft Learn, How User Account Control works. Sobre que el inicio de sesión de un usuario administrador crea dos tokens vinculados, un token de usuario estándar y un token de acceso de administrador completo, cuando UAC está habilitado. ↩ ↩²
Microsoft Learn, Mapped drives are not available from an elevated prompt. Sobre que las unidades de red asignadas en una sesión iniciada con el token estándar no están disponibles para los procesos elevados, y sobre la razón de fondo de que las dos sesiones de inicio de sesión vinculadas mantienen sus asignaciones de unidades por separado. ↩ ↩²
Microsoft Learn, KNOWNFOLDERID. Sobre que FOLDERID_RoamingAppData (%APPDATA%), FOLDERID_LocalAppData (%LOCALAPPDATA%) y FOLDERID_LocalAppDataLow están definidos como carpetas conocidas por usuario. ↩
Microsoft Learn, Error occurs during desktop setup and desktop location is unavailable. Sobre que un perfil de usuario tiene dos archivos de subárbol, NTUSER.DAT y UsrClass.dat, y sobre que UsrClass.dat se coloca bajo AppData\Local\Microsoft\Windows. ↩
Microsoft Learn, Services and the Registry. Sobre que los servicios no deben acceder a HKEY_CURRENT_USER ni a HKEY_CLASSES_ROOT, y sobre usar la función RegOpenCurrentUser al suplantar a un usuario. ↩
Microsoft Learn, CryptProtectData function. Sobre que CryptProtectData suele proteger datos con una clave de sesión asociada al usuario con sesión iniciada y asume el descifrado por el mismo usuario, y sobre el indicador CRYPTPROTECT_LOCAL_MACHINE que pasa a protección a nivel de máquina. ↩
Microsoft Learn, Windows Data Protection. Sobre que DPAPI protege una clave maestra generada al azar cifrándola con una clave derivada de la contraseña del usuario, que la clave maestra se almacena bajo el perfil de usuario, y que la clave maestra se vuelve a proteger cuando cambia la contraseña. ↩ ↩²
Microsoft Learn, ProtectedData Class. Sobre que DataProtectionScope.CurrentUser solo permite el descifrado al usuario que protegió los datos, y que LocalMachine permite el descifrado a cualquier proceso de la misma máquina. ↩
Microsoft Learn, Data Protection key management and lifetime in ASP.NET Core. Sobre que las claves se almacenan en %LOCALAPPDATA%\ASP.NET\DataProtection-Keys y se cifran con DPAPI en Windows cuando hay un perfil de usuario disponible, sobre el recurso al registro HKLM con ACL para la cuenta del proceso de trabajo cuando se hospeda en IIS sin perfil, sobre que las claves se pierden al salir el proceso y las cargas protegidas dejan de poder descifrarse cuando no se aplica ninguna de las condiciones, y sobre la implicación del atributo setProfileEnvironment. ↩
Chromium project, User Data Directory. Sobre que el directorio User Data predeterminado de Chrome en Windows es %LOCALAPPDATA%\Google\Chrome\User Data, y sobre que los perfiles (historial, marcadores, cookies, etc.) se colocan bajo él. ↩
Google Security Blog, Improving the security of Chrome cookies on Windows. Sobre que Chrome ha usado DPAPI para cifrar cookies y similares en Windows, y sobre que App-Bound Encryption protege la clave a través de un servicio que se ejecuta con privilegios SYSTEM y verifica la identidad de la aplicación que solicita el descifrado. ↩
Microsoft Learn, cmdkey. Sobre que el comando cmdkey enumera, crea y elimina nombres de usuario y contraseñas (credenciales) almacenados. ↩
Microsoft Learn, Cached and Stored Credentials Technical Overview. Sobre que las credenciales guardadas en el Administrador de credenciales se almacenan en disco y están protegidas por DPAPI, y sobre que los programas que se ejecutan como ese usuario pueden acceder a las credenciales de este almacén. ↩
Microsoft Learn, Local Machine and Current User Certificate Stores. Sobre que hay dos tipos de almacenes de certificados, el almacén de la máquina local (de toda la máquina) y el almacén del usuario actual (por usuario). ↩
Microsoft Learn, System Store Locations. Sobre que el almacén del sistema CERT_SYSTEM_STORE_CURRENT_USER se coloca bajo HKEY_CURRENT_USER\Software\Microsoft\SystemCertificates en el registro. ↩

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

El manejo seguro de credenciales en PowerShell — Cómo desterrar las contraseñas en texto plano de los scripts

Organiza el procedimiento para migrar las contraseñas en texto plano de scripts de PowerShell a un almacenamiento seguro: SecureString, D...

Leer el artículo

Endurecimiento de la seguridad de PowerShell — registro, AMSI, modo de lenguaje y JEA

Resumen práctico para usar PowerShell con seguridad sin prohibirlo: registro de bloques de script y transcripción, deshabilitar AMSI y ve...

Leer el artículo

Redirección y virtualización de 32/64 bits en el registro de Windows — Wow6432Node y el problema del «valor que debería estar y no está»

Explica cómo la escritura en HKLM\Software desde una app de 32 bits se redirige a Wow6432Node, cuándo la virtualización de UAC la traslad...

Leer el artículo

Power Automate y PowerShell + Programador de tareas: cuándo usar cada uno ── conectar las herramientas de automatización sin mezclarlas, cada una en su lugar

Para TI de pymes con PowerShell y Power Automate a la vez: diferencias, tabla de decisión, integración vía SharePoint y aspectos de licen...

Leer el artículo

Manejo de errores y diseño de reintentos en PowerShell ── de la trampa donde try/catch no funciona a las prácticas recomendadas de exit code y reintentos

Analiza la diferencia entre errores terminantes y no terminantes en PowerShell, la trampa de try/catch, -ErrorAction Stop, $LASTEXITCODE,...

Leer el artículo

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Temas técnicos de Windows

Portal sobre desarrollo de Windows, investigación de fallos y aprovechamiento de activos existentes.

Ver el tema

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Desarrollo de aplicaciones para Windows

Aplicaciones empresariales, integración de dispositivos y herramientas de comunicación, de los requisitos al desarrollo.

Ver el servicio Contactar

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

Una aplicación que funciona al iniciarla desde el Explorador de archivos no encuentra su archivo de configuración al iniciarla desde el Programador de tareas. ¿Por qué?: Porque variables de entorno como %APPDATA% se resuelven al perfil del usuario que está ejecutando el programa. Cuando la tarea se ejecuta como SYSTEM o con otra cuenta, las variables de entorno apuntan a un perfil distinto (bajo systemprofile en el caso de SYSTEM), y el archivo de configuración que guardó no existe ahí. Compruebe la cuenta con la que se ejecuta la tarea y, como corrección permanente, coloque los datos que deban compartirse bajo ProgramData.
Una contraseña guardada con ProtectedData.Protect ya no se puede descifrar una vez que la aplicación se convirtió en servicio.: DPAPI en el ámbito CurrentUser depende de la clave maestra del usuario que cifró los datos. Si el servicio se ejecuta con una cuenta distinta, la clave maestra es otra, así que el descifrado falla con una CryptographicException. Rediseñe un secreto que lean tanto el servicio como el usuario interactivo para usar el ámbito LocalMachine más una ACL de archivo, o ejecute el servicio con la cuenta de quien lo cifró.
¿Qué ocurre cuando un proceso que se ejecuta como SYSTEM lee HKCU?: En un proceso LocalSystem, HKEY_CURRENT_USER está asociado al usuario predeterminado (HKEY_USERS\.DEFAULT), así que los valores que el usuario interactivo escribió en HKCU no son visibles. Coloque la configuración de toda la máquina en HKLM y, si de verdad debe leer la configuración de un usuario, suplante a ese usuario y luego use RegOpenCurrentUser.
¿Puedo copiar un perfil de Chrome/Edge con sesión iniciada a una máquina de CI y usarlo?: En general, no. El perfil de un navegador basado en Chromium como Chrome o Edge vive bajo el %LOCALAPPDATA% del usuario, y la clave de cifrado de cookies y contraseñas guardadas está protegida por el DPAPI de ese usuario. Copiar la carpeta a otro usuario o a otra máquina no consigue descifrar porque la clave no coincide (navegadores como Firefox, que tienen su propia protección de perfil, son otro caso). Para la automatización, codifique los pasos de inicio de sesión de una cuenta de prueba, o use el mecanismo de estado de almacenamiento de su herramienta de automatización.
Las credenciales guardadas con cmdkey no se usan cuando la tarea se ejecuta desde el Programador de tareas.: Porque la bóveda del Administrador de credenciales es distinta para cada usuario, y lo que guardó fue a la bóveda de su propio inicio de sesión interactivo. Además, una tarea configurada con «No almacenar la contraseña» (S4U) se ejecuta sin credenciales de red, así que introducir credenciales en la bóveda no ayuda mientras siga en S4U. Considere primero una configuración que almacene la contraseña o un cambio a una cuenta de servicio y, solo entonces, si aún hace falta, introduzca las credenciales en la bóveda de la propia cuenta de ejecución.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.

Ver el perfil Contactar

Enlaces públicos

ORCID GitHub LinkedIn X COM_BLAS COM_BigDecimal

Volver al blog

Supuestos de este artículo

1. Primero la conclusión

2. Premisa: «Quién lo ejecuta» lo decide todo

2.1 Compruebe el SID y el token, no el nombre de usuario

2.2 Cada cuenta de servicio tiene un entorno propio

2.3 Tres condiciones que comprobar después de «el mismo usuario»

3. Límite 1: AppData — La misma variable de entorno apunta a un lugar distinto

3.1 Las divisiones de AppData y cómo las cambia el usuario de ejecución

3.2 PATH también difiere por usuario

4. Límite 2: HKCU — «Usuario actual» cambia con el llamador

4.1 HKCU es un alias del subárbol del usuario

4.2 Compruebe también si el perfil está cargado

5. Límite 3: DPAPI — El cifrado está cerrado con «la clave del usuario»

5.1 Un propietario distinto de la clave maestra significa que no hay descifrado

5.2 Elija el ámbito según quién deba poder descifrar

5.3 Un «cambio» y un «restablecimiento» de contraseña son distintos

5.4 Compruebe también dónde se almacenan las claves en ASP.NET Core

6. Límite 4: Perfiles de navegador — «Sesión iniciada» pertenece al usuario

6.1 Hay dos límites: ubicación de almacenamiento y clave

6.2 En la automatización, deje explícita la forma de crear el estado de inicio de sesión

7. Límite 5: Credenciales y certificados — Cada usuario tiene una bóveda aparte

7.1 El Administrador de credenciales es una bóveda por usuario de ejecución

7.2 En los certificados, compruebe por separado el almacén y los permisos de la clave privada

7.3 Con la elevación UAC, separe «la misma cuenta» de «una cuenta distinta»

8. Lista de comprobación por forma de ejecución

8.1 En las tareas, mire el tipo de inicio de sesión después de la cuenta de ejecución

8.2 La tabla de inspección antes de cambiar el destino de ejecución

9. Directrices de diseño y de resolución de problemas

9.1 Decida las ubicaciones de almacenamiento y la preparación a partir del principal que las usa

9.2 Investigue desde el principal de ejecución hasta la ubicación realmente referenciada

10. Resumen

Artículos relacionados

Ámbitos de consultoría relacionados

Referencias

Artículos relacionados

El manejo seguro de credenciales en PowerShell — Cómo desterrar las contraseñas en texto plano de los scripts

Endurecimiento de la seguridad de PowerShell — registro, AMSI, modo de lenguaje y JEA

Redirección y virtualización de 32/64 bits en el registro de Windows — Wow6432Node y el problema del «valor que debería estar y no está»

Power Automate y PowerShell + Programador de tareas: cuándo usar cada uno ── conectar las herramientas de automatización sin mezclarlas, cada una en su lugar

Manejo de errores y diseño de reintentos en PowerShell ── de la trampa donde try/catch no funciona a las prácticas recomendadas de exit code y reintentos

Temas relacionados

Temas técnicos de Windows

Servicios relacionados con este tema

Desarrollo de aplicaciones para Windows

Preguntas frecuentes

Perfil del autor

Go Komura