El NT gestiona tanto a usuarios como máquinas. De forma que deberá validar a los usuarios autorizados y proveerlos de lo necesario para acceder al sistema.

A un nivel general, un dominio NT es una colección de máquinas, a las cuales el controlador de dominio administra como si se tratase de una única máquina, compartiendo una misma base de datos de seguridad. Dicha base de datos mantiene información de todos los usuarios y grupos de ese dominio. Una cuenta de dominio, llamado de otra forma cuenta global, tiene el formato dominio\usuario. Si iniciamos una sesión en una máquina del dominio e intentamos conectarnos a una unidad de red, tendremos que introducir nuestros datos con ese formato.

Además de las cuentas de usuarios, cada máquina puede disponer de una base de datos de seguridad local que contendrá la información de los usuarios y grupos de usuarios exclusivos de ese sistema. De hecho, las máquinas locales funcionan como dominios independientes. Las cuentas de usuarios o grupos en esas máquinas locales tiene el formato maquina\usuario y serán exclusivas de esa máquina.

La herramienta básica para administrar los usuarios y grupos de un dominio es el programa USRMGR.EXE, conocido por Administrador de Usuarios para dominios. Windows NT Workstation incluye una versión reducida de este programa y permite la gestión únicamente de esa máquina. En la figura 1 podemos ver la pantalla resultante de la ejecución de USRMGR.EXE, la cual puede visualizar información local y del dominio, dependiendo de si añadimos parámetros o no al ejecutar el programa. Ejecutar USRMGR sin parámetros, gestionará el dominio al cual es usuario esté conectado en ese momento. Si ejecutamos USRMGR nombre_dominio como parámetro, se gestionará ese dominio en concreto, y si se ejecuta USRMGR \\nombre_máquina, se gestionarán los usuarios de esa máquina en concreto.

Cargar los dominios puede ser cuestión de minutos si se trata de organizaciones con muchos dominios, por lo que se agradece a la larga la posibilidad de parametrizar y gestionar un dominio o máquina en concreto. El programa también permite a los administradores gestionar las relaciones de confianza de los dominios, de forma que el usuarios del dominio A puedan acceder a los recursos del dominio B como si fueran usuarios del segundo.

Un valor único y permanente, el SID (Security Identifier) identifica usuarios individuales y grupos de usuarios. Después de que el sistema asigne un SID, no lo volverá a utilizar, por lo que si por lo que sea borramos un usuario o grupo y más tarde nos vemos en la necesidad de volverlo a crear, se le asignará un nuevo SID. Será necesario volver a reestablecer de nuevo los derechos de acceso sobre los objetos para ese nuevo SID.

Acceso a través de APIs: Seguridad de objectos

NT asegura la seguridad a nivel de objetos verificando todas las peticiones sobre los objetos a través de un mecanismo de seguridad integrado. Muchas de las funciones de la API Win32 disponen de parámetros de seguridad opcionales, y todos los programas que se ejecuten deben utilizar esas APIs para acceder a los objetos. Si pudiésemos ejecutar el interfaz de mandatos y desde allí copiar, renombrar o borrar archivos sin utilizar esas funciones, la seguridad en Windows NT quedaría más que en entredicho. De hecho, la capacidad de manipular el hardware directamente desde Windows 16 bits o desde el DOS era el escollo más importante para ofrecer un sistema de seguridad en esos entornos.

Los parámetros de seguridad en las funciones de la API Win32 son opcionales, pero normalmente el NT echa mano de ellas cuando un programa accede a un recurso general de sistema, como por ejemplo, cambiar la hora del sistema. Algunas aplicaciones pueden implementar niveles de seguridad si trabajan con archivos de usuario o directorios (el impacto sobre el rendimiento es insignificante) pero muchas de las APIs no especifican información de seguridad.

En cambio Windows 95 no tiene en cuenta temas relativos a la seguridad e ignora todos los parámetros de seguridad posibles existentes en la API Win32. Esta "ceguera" de Windows 95 frente a Windows NT puede comportar una sutil diferencia a la hora de programar para un sistema operativo u otro. Precisamente, es esta una de las razones por las cuales es conveniente verificar el adecuado funcionamiento de las aplicaciones en ambas plataformas.

Pero implementar seguridad a nivel de APIs también comporta otra sutileza. En aplicaciones Cliente/Servidor, la aplicación servidor acostumbra a controlar el acceso a los objetos. Puesto que la aplicación cliente, normalmente, no gestiona la seguridad directamente, la aplicación servidor se ve a menudo obligado a trabajar como proxy de la parte cliente. También podría despersonalizar al cliente utilizando APIs del tipo Impersonate…() o iniciar una sesión como cliente (si la aplicación servidor conoce el nombre del usuario y su contraseña.

Asegurar los objetos

Además de archivos y directorios, Windows NT controla la seguridad de otros objetos. La API Win32 implementa cinco grupos de funciones que operan con cinco tipos de objetos distintos.

1. Objetos de archivos y directorios: NT almacena la información relativa a la seguridad. Sólo está disponible en volúmenes formateados NTFS.

2. Objetos de usuario (objetos de gestión de ventanas): Estos objetos incluyen los objetos del escritorio y las ventanas. Estos objetos de usuario residen siempre en memoria y nunca son salvados a disco (no son persistentes).

3. Objetos del Kernel: El kernel del Windows utiliza estos objetos, entre los que se incluyen procesos, hebras, semáforos y "mutes". Al igual que los objetos de usuario, tampoco son persistentes.

4. Objetos de servicio: Estos objetos, entre los que se incluyen todos los servicios que podamos encontrar en el icono Servicios del Panel de Control, se encuentran bajo el control del SMC (Service Control Manager) y tampoco son persistentes.

5. Objetos privados: Los programas de las aplicaciones pueden implementar y deben mantener su propia seguridad, siendo los objetos privados los encargados de interactuar con el sistema de seguridad de la API Win32. Por ejemplo, un sistema de base de datos, como SQL Server, puede necesitar almacenar información de seguridad internamente y utilizar la validación de usuarios por dominios del NT. El Registro es una implementación Win32 de esos objetos privados. La información relativa a la seguridad está almacenada en el Registro del Sistema.

Un SD (Security Descriptor) describe los atributos de seguridad de cada objeto susceptible de ser protegido. Estos atributos identifican el propietario del objeto y dos ACL (Access Control List), una para el acceso al objeto propiamente dicho y otro para las funciones de auditoría. La ACL para el acceso a los objetos se llama DACL

(Discretionary Access Control List) e incluye varias entradas de control de acceso (ACE,

Access-Control Entries). Cada ACE identifica un SID y si es accesible o no. La otra ACL es la SACL (System Access Control List) la cual controla la auditoría de eventos.

Los derechos de los usuarios

Además de los derechos de acceso, los cuales están asociados con los objetos, Windows NT implementa también privilegios. Para asignar derecho a objetos, utilizaremos el Administrador de archivos o el Explorador, dependiendo de la versión de Windows NT. Para asignar privilegios, utilizaremos el Administrador de Usuarios. Los privilegios forman parte del identificador que se asigna al usuario cuando inicia una sesión en el sistema. Es el Sistema Operativo quien determina los privilegios de los usuarios, y no las aplicaciones. En la Tabla 1 podemos ver los privilegios que son reconocidos por NT 4.0.

Los privilegios son siempre fuente de frustración. ¿Se ha encontrado alguna vez que tras crear una cuenta de usuario, al intentar iniciar una sesión local con ese perfil, ha recibido el mensaje "las directivas locales de este sistema no le permiten iniciar una sesión interactiva"?  Por defecto, NT asigna los nuevos usuarios al grupo de Usuarios, pero este grupo, también por defecto, no dispone de permisos para iniciar una sesión local.

Con Microsoft Internet Information Server (IIS), nos podemos encontrar con un problema similar.

La cuenta de usuario predefinida IUSR_maquina, es una cuenta local con unos pocos privilegios, de forma que no puede ser utilizada de inicio de sesión anónimo si se especifica autentificación básica HTTP.

Si echa un vistazo con detenimiento a USRMGR.EXE, verá el grupo "Todos" bajo la opción "Acceder a este ordenador desde la red", aunque este grupo no aparezca después como tal. NT define un grupo de SID, como Todos o Interactivo para ayudar así al administrador de la red con los más frecuentes derechos de acceso.

En general, los privilegios sobreescriben la seguridad individual de los objetos. Un ejemplo de esta sobreescritura se da cuando un administrador de copias de seguridad cambia el indicador (o "flag") a todos los archivos de un volumen. Sin los correspondientes privilegios, el administrador tendría que añadir otro ACE a cada archivo para que el programa de copias de seguridad pudiera modificar sus indicadores. Si añadimos un nuevo SID al grupo Todos, la seguridad del NT no tendrá que  verificar si tiene derechos o no, por lo que determinadas operaciones se ejecutarán más rápido.

Acceso a traves de RAS ( remote access sevice )

El Windows NT RAS ( remote access service ) o servicio de acceso remoto implementa un número de medidas de seguridad para validar acceso remoto de un cliente a la red.

En algunas ocasiones conectarse a la red a través de un RAS es más seguro que acceder a través de una colección local.

El Windows NT Server provee para empresas un método de seguridad usando un dominio confiable. Este método elimina la necesidad de duplicar las cuentas de usuario trabajando en redes de múltiple server.  El Single-Network modelo de logearse se extiende para usuarios de RAS.

El servidor de usuarios RAS utiliza la misma base de datos para las cuentas de usuario que el Windows NT. Esto permite una administración más fácil, porque los clientes se pueden logear con la misma cuenta de usuario que usan en la oficina esta característica asegura que los clientes tengan los mismos privilegios y permisos que normalmente tienen en la oficina.

Para conectarse a un servidor RAS, el cliente debe tener una cuenta de usuario válida, así como un permiso de discado RAS.

Los clientes deben ser auténtificados por el RAS antes de que ellos intenten logearse al Windows NT.

Encriptado automático y proceso de logeo.

Todas las autentificaciones e información de logeo, son encriptadas cuando se transmiten a través del RAS.  De todas formas como complemento, es posible configurar el discado de la red (Dial-up-Networking ) y el RAS, para que todos los datos que pasan entre un cliente y un servidor sean encriptados.

Hosts de seguridad intermedia

Es posible agregar otro nivel de seguridad a la configuración de un RAS mediante la conexión de una tercer pared intermediaria de seguridad de un Host, entre el cliente/s de un RAS y el RAS del servidor/es. Cuando un Host de intermediario de seguridad es usado, los clientes deben tipear una clave o un código para pasar el dispositivo de seguridad, antes de que una conexión se establezca con el servidor RAS.

Seguridad C2

De acuerdo con la TCSEC (Trusted Computer System Evaluation Criteria) publicado por la NCSC (National Computer Security Center), la seguridad C2 requiere una específica combinación y configuración de software y hardware. NT no es "per se" un sistema operativo que cumpla con el nivel C2 de seguridad, pero podemos hacer que lo sea. Microsoft diseñó esta posibilidad dentro del modelo de seguridad del NT desde los primeros momentos. El nivel C2 de seguridad requiere lo siguiente:

• Cada recurso tiene un propietario que debe controlar el acceso al recurso.

• Cada usuario debe iniciar la sesión con un identificador y contraseña exclusivos antes de poder acceder al sistema.

• El sistema monitoriza toda actividad de los usuarios.

• Los administradores de sistema deben auditar los eventos relativos a la seguridad del sistema, y el acceso a los datos de auditoría deben ser seguros.

• El sistema debe poder protegerse a sí mismo de interferencias externas.

El Resource Kit de Windows NT incluye el programa C2CONFIG.EXE (C2 Configuration Manager), que verifica que el sistema cumpla con los requisitos C2, de la forma en que podemos verlo en las figuras 2 y 3.

Auditoría de eventos

La auditoría nos puede descubrir intentos de acceso no autorizados. Tendría que buscar un equilibrio entre los costes y los beneficios derivados de la utilización de la auditoría. Los costes incluyen el impacto en el rendimiento del sistema y en el espacio del disco, además de los esfuerzos que significan escarbar entre grandes cantidades de transacciones, intentando encontrar información interesante.

La herramienta básica de auditoría de Windows NT es el Visor de Eventos. Nos permite auditar accesos a objetos tanto fallidos como efectuados, además de los eventos relativos a los derechos de los usuarios. El diálogo Auditoría en el Explorador del NT, por ejemplo, permite controlar eventos de lectura, escritura, ejecución, borrado, cambio de permisos y adjudicación de propiedad del objeto y del directorio. En la figura 4 podemos ver la información que ofrece el registro de eventos.

Con el programa USRMGR.EXE podemos activar o desactivar la auditoría sobre inicios y fin de sesión, acceso a objetos y archivos, uso de los permisos de los usuarios, gestión de usuarios y grupos, cambios en la directivas de seguridad, reinicialización y apagado del sistema y rastreo de los procesos del mismo. Obviamente, si no asigna a ningún usuario derechos para "Administrar los registros de auditoría y seguridad" (vea la tabla 1 para la lista de derechos), no podrá cambiar nada.