NetBackup 11 falla al instalar con cuentas de dominio

Una instalación de NetBackup 11 en Windows que indique que la cuenta del servicio web no existe debe contrastarse con los requisitos de cuenta para el servidor web de NetBackup antes de atribuir el problema a Active Directory. En Windows, la cuenta y el grupo deben existir en el formato exacto que NetBackup espera, el usuario debe pertenecer al grupo del servicio web y la cuenta necesita el privilegio efectivo de "Iniciar sesión como servicio" (Log on as a service) en el servidor primario.

Un caso de instalación reciente involucró a un Windows Server 2019 unido a Active Directory. El administrador intentó utilizar una cuenta de dominio y se encontró con un error que señalaba que la cuenta no existía o que un usuario del grupo no existía en el servidor primario. El DNS respondía bien y una directiva de grupo (GPO) supuestamente concedía el inicio de sesión como servicio, pero la instalación seguía fallando. Esa situación vuelve más relevante la configuración efectiva local que las suposiciones sobre el dominio.

¿Necesita un servidor NetBackup en dominio una cuenta de servicio web de dominio?

Un servidor unido a un dominio no exige de forma automática una cuenta de dominio para el servicio web de NetBackup. Veritas documenta una cuenta local y un grupo local como el ejemplo estándar en Windows, con nbwebsvc como usuario local por defecto y nbwebgrp como grupo local predeterminado.

La excepción es el funcionamiento en clúster. Veritas establece expresamente que deben utilizarse cuentas de dominio en entornos de clúster bajo Windows. Determina en qué escenario te encuentras antes de empezar a diagnosticar, porque un servidor primario de Windows independiente que forma parte de un dominio de Active Directory tiene una arquitectura distinta a la de un servidor primario de NetBackup en alta disponibilidad por clúster.

Si el servidor es independiente, probar con el modelo documentado de cuenta local permite comprobar si el instalador y los permisos locales funcionan con normalidad. Si el servidor está en clúster, aplica el diseño de cuenta de dominio obligatorio y verifícalo de manera uniforme en cada nodo participante.

Elige el tipo de cuenta según lo que exijan la arquitectura del despliegue y la política de seguridad, y deja de lado la impresión de que "el dominio parece más empresarial".

¿Qué exige NetBackup a la cuenta del servicio web?

NetBackup requiere una cuenta de privilegios mínimos para el servicio web de su servidor primario, y Veritas advierte de forma explícita contra conceder permisos de administrador a ese usuario. Los nombres locales predeterminados son nbwebsvc para el usuario y nbwebgrp para el grupo, aunque pueden personalizarse.

En Windows, la configuración documentada crea el usuario, crea el grupo local, añade el usuario como miembro de ese grupo y le otorga el derecho de "Iniciar sesión como servicio". Veritas advierte que la instalación del servidor primario falla si no se cumplen estos requisitos.

Existe también un detalle aparentemente menor que puede arruinar un diseño de dominio por lo demás impecable: el nombre de usuario del servicio web en Windows tiene un límite de 20 caracteres. Los nombres largos y descriptivos para cuentas de servicio son habituales en Active Directory. Cuenta los caracteres del nombre real de la cuenta antes de perder horas analizando DNS y políticas.

La cuenta está pensada para tener permisos restringidos. Convertirla en administrador local para superar el asistente de instalación destruye el modelo de seguridad y puede ocultar el permiso que realmente faltaba.

¿Por qué la directiva de grupo puede indicar que el permiso está concedido y la instalación seguir fallando?

Una directiva de grupo puede reflejar el privilegio deseado mientras que el estado efectivo local en el servidor de NetBackup difiere de esa configuración. El caso de instalación mostró justo esa tensión: el administrador sostenía que la cuenta de dominio disponía de "Iniciar sesión como servicio" mediante GPO, mientras que la comunidad insistía en revisar la asignación de seguridad efectiva en la máquina local.

Revisa los derechos de usuario efectivos en el servidor primario tras aplicar las directivas de grupo. Confirma que la directiva correspondiente no esté siendo sobrescrita por otra GPO con mayor precedencia. Comprueba si el permiso se concede de forma directa a la cuenta o a través de un grupo, y verifica que el token actual de la cuenta incluya efectivamente esa pertenencia al grupo.

Revisa además la política opuesta. Windows permite denegar expresamente el inicio de sesión como servicio. Una denegación siempre se impone sobre una autorización. Si las políticas de bastionado de la empresa añaden cuentas de servicio o grupos amplios a una lista de denegación, la cuenta de NetBackup puede parecer correcta en una GPO y seguir resultando inutilizable en la práctica.

Esto no implica que las directivas de grupo fallen. El instalador simplemente lee el estado de seguridad efectivo del servidor, y este puede diferir de la intención original del administrador.

¿Cómo debe verificarse nbwebgrp con una cuenta de dominio?

La cuenta utilizada por el servicio web debe ser reconocida como miembro del grupo de servicios web que NetBackup tiene asignado. El nombre predeterminado del grupo local es nbwebgrp, pero se admiten nombres personalizados, por lo que conviene verificar el nombre exacto entregado al instalador.

En un servidor Windows independiente, inspecciona la pertenencia al grupo local directamente. Si utilizas una cuenta de dominio, confirma que la identidad de dominio aparezca en el grupo local y se resuelva sin errores desde el propio equipo. No te fíes de que la cuenta exista en Active Directory: NetBackup necesita que la relación entre el usuario y el grupo de servicio web configurado sea válida en el servidor primario.

Si el error afirma que un usuario del grupo no existe en el servidor primario, simplifica la prueba. Elimina miembros obsoletos o con nombres incorrectos del grupo. Asegúrate de que solo figure la identidad prevista. Comprueba que el controlador de dominio pueda resolver la cuenta y que el canal seguro del servidor hacia el dominio funcione correctamente.

Luego vuelve a ejecutar la comprobación de requisitos previos o el instalador. Una cuenta limpia y un grupo limpio ofrecen un diagnóstico mucho más fiable que un grupo cargado de identidades de prueba heredadas.

¿Qué más conviene comprobar antes de reinstalar?

Antes de reinstalar, valida la longitud del nombre de cuenta, la contraseña, el estado de la cuenta, la pertenencia a grupos, el derecho efectivo de "Iniciar sesión como servicio" y si el despliegue es en clúster. Confirma asimismo que la cuenta no esté deshabilitada, caducada, bloqueada ni limitada para iniciar sesión en el servidor primario por una regla de estaciones de trabajo en Active Directory.

Usa el formato exacto de cuenta que espera el asistente. Si una pantalla utiliza DOMINIO\\usuario y otro paso de validación resuelve un UPN, mantén la identidad uniforme y comprueba cómo la almacena NetBackup. Que el DNS funcione solo demuestra que el servidor puede resolver nombres de máquinas; si una cuenta de servicio puede resolverse, autenticarse o recibir derechos locales es un asunto independiente.

Si un intento de instalación fallido anterior dejó usuarios o grupos locales a medio crear, examínalos antes de volver a intentarlo. No sigas acumulando cuentas nuevas sobre un estado residual sin tener claro cuál de ellas está leyendo el instalador.

Esto guarda similitud con la resolución de problemas de recuperación en general. La comparativa de backups en Proxmox trata una plataforma diferente, pero refuerza un hábito útil: separa los requisitos previos del plano de control respecto a la función de protección de datos antes de modificar todo el sistema.

¿Conviene hacer una prueba con una cuenta local?

En un servidor primario Windows independiente, una cuenta local sirve como un excelente recurso de diagnóstico porque Veritas documenta esa alternativa de forma directa. Si el esquema documentado con nbwebsvc y nbwebgrp a nivel local tiene éxito, el instalador demuestra que puede completarse y el problema de la cuenta de dominio se delimita con más claridad.

Esto no significa que la cuenta local deba quedarse automáticamente como diseño final para producción. Las políticas de seguridad de la organización pueden exigir identidades de servicio gestionadas de forma centralizada. La prueba simplemente aísla las variables del problema.

En un despliegue Windows en clúster, evita este atajo, ya que Veritas exige cuentas de dominio. En ese escenario, soluciona la cuenta de dominio correctamente en todos los nodos.

Una vez que la instalación culmine con éxito, documenta cómo se gestiona la cuenta, de dónde proceden sus permisos, cómo se gestionan los cambios de contraseña y qué monitoreo alertará ante fallos de inicio de sesión del servicio. Una cuenta de servicio es una dependencia del ciclo de vida del sistema que perdura mucho más allá de la pantalla del instalador donde la escribiste.

El mismo principio aplica a los repositorios de backup descritos en la guía de Proxmox Backup Server. Las credenciales, claves de cifrado e identidades de administración deben soportar el mantenimiento ordinario además de la configuración inicial.

¿Qué haría ante el fallo en Windows Server 2019?

Primero determinaría con certeza si el servidor primario está en clúster. Si es independiente, probaría el formato local documentado al pie de la letra para validar la ruta del instalador. Si está en clúster, mantendría la cuenta de dominio y la validaría en cada nodo.

A continuación contaría los caracteres del nombre de usuario, revisaría la pertenencia local a nbwebgrp, verificaría el privilegio efectivo de inicio de sesión como servicio, descartaría derechos de denegación y confirmaría que la cuenta esté habilitada y autorizada para autenticarse en el servidor. No daría por buena la frase "la GPO contiene la configuración" como validación definitiva.

Solo después de esas comprobaciones procedería a reinstalar o modificar otros componentes de NetBackup. El error inicial apunta a la identidad y al reconocimiento de grupos, así que conviene tratarlo bajo esa perspectiva hasta que las pruebas demuestren lo contrario.

La solución más segura es aquella que deja el servicio web funcionando con los privilegios restringidos para los que NetBackup fue concebido. Si la única configuración que funciona pasa por otorgar permisos de administrador, el problema solo se ha esquivado.