Planear NPS como servidor RADIUS

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016

Cuando implementa el Servidor de directivas de red (NPS) como servidor RADIUS (Servicio de autenticación remota telefónica de usuario), NPS realiza la autenticación, autorización y contabilidad de las solicitudes de conexión para el dominio local y para los dominios que confían en el dominio local. Puede usar estas directrices de planificación para simplificar la implementación de RADIUS.

Estas directrices de planificación no incluyen las circunstancias en las que se quiera implementar NPS como proxy RADIUS. Al implementar NPS como un proxy RADIUS, NPS reenvía las solicitudes de conexión a un servidor que ejecuta NPS u otros servidores RADIUS en dominios remotos, dominios que no son de confianza o ambos.

Antes de implementar el NPS como un servidor RADIUS en la red, siga las instrucciones siguientes para planificar la implementación.

  • Planifique la configuración del NPS.

  • Planifique los clientes RADIUS.

  • Planee el uso de métodos de autenticación.

  • Planee las directivas de la red.

  • Planifique la contabilización de cuentas del NPS.

Planifique la configuración del NPS.

Debe decidir en qué dominio es miembro el NPS. En entornos de varios dominios, un NPS puede autenticar las credenciales de las cuentas de usuario en el dominio del que es miembro y para todos los dominios que confían en el dominio local del NPS. Para permitir que NPS lea las propiedades de acceso telefónico local de las cuentas de usuario durante el proceso de autorización, debe agregar la cuenta de equipo del NPS al grupo de RAS y NPS para cada dominio.

Después de determinar la pertenencia al dominio del NPS, el servidor debe configurarse para comunicarse con clientes RADIUS, también denominados servidores de acceso a la red, mediante el protocolo RADIUS. Además, puede configurar los tipos de eventos que el NPS registra en el registro de eventos y puede escribir una descripción para el servidor.

Pasos clave

Durante la planificación de la configuración del NPS, puede seguir los pasos siguientes.

  • Determine los puertos RADIUS que usa NPS para recibir mensajes RADIUS de los clientes RADIUS. Los puertos predeterminados son los puertos UDP 1812 y 1645 para los mensajes de autenticación RADIUS y los puertos 1813 y 1646 para los mensajes de contabilidad RADIUS.

  • Si el NPS está configurado con varios adaptadores de red, determine los adaptadores sobre los que desea que se permita el tráfico RADIUS.

  • Determine los tipos de eventos que desea que el NPS registre en el registro de eventos. Puede registrar solicitudes de autenticación rechazadas, solicitudes de autenticación correctas o ambos tipos de solicitudes.

  • Determine si va a implementar más de un NPS. Para proporcionar tolerancia a errores para la autenticación basada en RADIUS y la contabilidad, use al menos dos NPS. Uno de los NPS se usa como servidor RADIUS principal y el otro se usa como copia de seguridad. A continuación, cada cliente RADIUS se configura en ambos NPS. Si el NPS principal deja de estar disponible, los clientes RADIUS envían mensajes de solicitud de acceso al NPS alternativo.

  • Planifique el script utilizado para copiar una configuración de NPS a otros NPS para ahorrar en sobrecarga administrativa y evitar la configuración incorrecta de un servidor. NPS proporciona los comandos Netsh que permiten copiar toda (o parte de) la configuración de un NPS para importarla a otro NPS. Puede ejecutar los comandos manualmente en el símbolo del sistema de Netsh. Sin embargo, si guarda la secuencia de comandos como un script, puede ejecutar el script en una fecha posterior si decide cambiar las configuraciones de servidor.

Planificación de los clientes RADIUS

Los clientes RADIUS son servidores de acceso a la red, como puntos de acceso inalámbrico, servidores de red privada virtual (VPN), conmutadores compatibles con 802.1X y servidores de acceso telefónico. Los servidores proxy RADIUS, que reenvían los mensajes de solicitud de conexión a los servidores RADIUS, también son clientes RADIUS. El NPS admite todos los servidores de acceso de red y servidores proxy RADIUS que cumplen con el protocolo RADIUS, como se describe en RFC 2865, "Remote Authentication Dial-in User Service (RADIUS)" y RFC 2866, "RADIUS Accounting".

Importante

Los clientes de acceso, como los equipos cliente, no son clientes RADIUS. Solo los servidores de acceso a la red y los servidores proxy que admiten el protocolo RADIUS son clientes RADIUS.

Además, tanto los puntos de acceso inalámbrico como los conmutadores deben ser compatibles con la autenticación 802.1X. Si desea implementar el protocolo de autenticación extensible (EAP) o el protocolo de autenticación extensible protegida (PEAP), los puntos de acceso y los conmutadores deben admitir el uso de EAP.

Para probar la interoperabilidad básica de las conexiones PPP para puntos de acceso inalámbrico, configure el punto de acceso y el cliente de acceso para usar el protocolo de autenticación de contraseñas (PAP). Use protocolos de autenticación adicionales basados en PPP, como PEAP, hasta que haya probado los que pretende usar para el acceso a la red.

Pasos clave

Durante la planificación de clientes RADIUS, puede seguir los pasos siguientes.

  • Documente los atributos específicos del proveedor (VSA) que debe configurar en el NPS. Si los servidores de acceso a la red requieren VSA, registre la información de VSA para su uso posterior al configurar las directivas de red en NPS.

  • Documente las direcciones IP de los clientes RADIUS y el NPS para simplificar la configuración de todos los dispositivos. Al implementar los clientes RADIUS, debe configurarlos para que usen el protocolo RADIUS, con la dirección IP del NPS especificada como servidor de autenticación. Y al configurar el NPS para comunicarse con los clientes RADIUS, debe escribir las direcciones IP del cliente RADIUS en el complemento NPS.

  • Cree secretos compartidos para la configuración en los clientes RADIUS y en el complemento NPS. Debe configurar clientes RADIUS con un secreto compartido o una contraseña, que también escribirá en el complemento NPS al configurar clientes RADIUS en el NPS.

Planificación del uso de métodos de autenticación

NPS admite métodos de autenticación basados en contraseña y basados en certificados. Sin embargo, no todos los servidores de acceso a la red admiten los mismos métodos de autenticación. En algunos casos, es posible que desee implementar un método de autenticación diferente en función del tipo de acceso a la red.

Por ejemplo, es posible que quiera implementar el acceso inalámbrico y VPN para su organización, pero usar un método de autenticación diferente para cada tipo de acceso: EAP-TLS para conexiones VPN, debido a la fuerte seguridad que proporciona EAP con seguridad de la capa de transporte (EAP-TLS) y PEAP-MS-CHAP v2 para conexiones inalámbricas 802.1X.

PEAP con Microsoft Challenge Handshake Authentication Protocol versión 2 (PEAP-MS-CHAP v2) proporciona una característica denominada reconexión rápida que está específicamente diseñada para usar con equipos portátiles y otros dispositivos inalámbricos. La reconexión rápida permite a los clientes inalámbricos moverse entre puntos de acceso inalámbricos de la misma red sin tener que volver a autenticarse cada vez que se asocian a un nuevo punto de acceso. Esto proporciona una mejor experiencia para los usuarios inalámbricos y les permite moverse entre puntos de acceso sin tener que volver a escribir sus credenciales. Debido a la rápida reconexión y la seguridad que proporciona PEAP-MS-CHAP v2, es una opción lógica como método de autenticación para las conexiones inalámbricas.

En el caso de las conexiones VPN, EAP-TLS es un método de autenticación basado en certificados que proporciona una seguridad sólida que protege el tráfico de red, incluso cuando se transmite a través de Internet desde equipos domésticos o móviles a los servidores VPN de la organización.

Métodos de autenticación basados en certificados.

Los métodos de autenticación basados en certificados tienen la ventaja de proporcionar una seguridad sólida; y tienen la desventaja de ser más difícil de implementar que los métodos de autenticación basados en contraseña.

Tanto PEAP-MS-CHAP v2 como EAP-TLS son métodos de autenticación basados en certificados, pero hay muchas diferencias entre ellos y la forma en que se implementan.

EAP-TLS

EAP-TLS usa certificados para la autenticación de cliente y servidor, y requiere que implemente una infraestructura de clave pública (PKI) en la organización. La implementación de una PKI puede ser compleja y requiere una fase de planificación independiente del planeamiento para el uso de NPS como servidor RADIUS.

Con EAP-TLS, NPS inscribe un certificado de servidor de una entidad de certificación (CA) y el certificado se guarda en el equipo local del almacén de certificados. Durante el proceso de autenticación, la autenticación del servidor se produce cuando NPS envía su certificado de servidor al cliente de acceso para demostrar su identidad al cliente de acceso. El cliente de acceso examina varias propiedades de certificado para determinar si el certificado es válido y es adecuado para su uso durante la autenticación del servidor. Si el certificado de servidor cumple los requisitos mínimos del certificado de servidor y lo emite una entidad de certificación en la que confía el cliente de acceso, el cliente autentica correctamente el NPS.

Del mismo modo, la autenticación de cliente se produce durante el proceso de autenticación cuando el cliente envía su certificado de cliente al NPS para demostrar su identidad al NPS. El NPS examina el certificado y, si el certificado del cliente cumple los requisitos mínimos del certificado del cliente y es emitido por una CA en la que confía el NPS, el cliente de acceso es autenticado con éxito por el NPS.

Aunque es necesario que el certificado de servidor se almacene en el almacén de certificados en NPS, el cliente o el certificado de usuario se puede almacenar en el almacén de certificados del cliente o en una tarjeta inteligente.

Para que este proceso de autenticación tenga éxito, se requiere que todos los equipos tengan el certificado de entidad de certificación de su organización en el almacén de certificados de las entidades de certificación raíz de confianza para el equipo local y el usuario actual.

PEAP-MS-CHAP v2

PEAP-MS-CHAP v2 usa un certificado para la autenticación del servidor y las credenciales basadas en contraseña para la autenticación de usuario. Dado que los certificados solo se usan para la autenticación del servidor, no es necesario implementar una PKI para poder usar PEAP-MS-CHAP v2. Al implementar PEAP-MS-CHAP v2, puede obtener un certificado de servidor para NPS de una de las dos maneras siguientes:

  • Puede instalar Servicios de certificados de Active Directory (AD CS) y después inscribir automáticamente los certificados en los NPS. Si usa este método, también debe inscribir el certificado de entidad de certificación en los equipos cliente que se conectan a la red para que confíen en el certificado emitido al NPS.

  • Puede comprar un certificado de servidor de una entidad de certificación pública, como VeriSign. Si usa este método, asegúrese de seleccionar una entidad de certificación que ya sea de confianza para los equipos cliente. Para determinar si los equipos cliente confían en una CA, abra el complemento de Microsoft Management Console (MMC) de Certificados en un equipo cliente y, después, consulte el almacén de entidades de certificación raíz de confianza para el equipo local y para el usuario actual. Si hay un certificado de la CA en estos almacenes de certificados, el equipo cliente confía en la CA y, por tanto, confiará en cualquier certificado emitido por la CA.

Durante el proceso de autenticación con PEAP-MS-CHAP v2, la autenticación del servidor se produce cuando NPS envía su certificado de servidor al equipo cliente. El cliente de acceso examina varias propiedades de certificado para determinar si el certificado es válido y es adecuado para su uso durante la autenticación del servidor. Si el certificado de servidor cumple los requisitos mínimos del certificado de servidor y lo emite una entidad de certificación en la que confía el cliente de acceso, el cliente autentica correctamente el NPS.

La autenticación de usuario se produce cuando un usuario intenta conectarse a las credenciales basadas en contraseña de los tipos de red e intenta iniciar sesión. NPS recibe las credenciales y realiza la autenticación y autorización. Si el usuario se autentica y autoriza correctamente, y si el equipo cliente ha autenticado correctamente el NPS, se concede la solicitud de conexión.

Pasos clave

Durante el planeamiento del uso de métodos de autenticación, puede usar los pasos siguientes.

  • Identifique los tipos de acceso a la red que tiene previsto ofrecer, como acceso inalámbrico, VPN, conmutador compatible con 802.1X y acceso telefónico.

  • Determine el método o métodos de autenticación que quiere usar para cada tipo de acceso. Se recomienda usar los métodos de autenticación basados en certificados que proporcionan una fuerte seguridad; sin embargo, puede que no le resulte práctico implementar una PKI, por lo que otros métodos de autenticación podrían proporcionar un mejor equilibrio de lo que necesita para su red.

  • Si va a implementar EAP-TLS, planee la implementación de PKI. Esto incluye planear las plantillas de certificado que va a usar para los certificados de servidor y los certificados de equipo cliente. También incluye determinar cómo inscribir certificados en equipos miembros de dominio y no miembros de dominio y determinar si desea usar tarjetas inteligentes.

  • Si va a implementar PEAP-MS-CHAP v2, determine si desea instalar AD CS para emitir certificados de servidor a los NPS o si desea adquirir certificados de servidor de una CA pública, como VeriSign.

Planear directivas de red

NPS usa directivas de red para determinar si las solicitudes de conexión recibidas de los clientes RADIUS están autorizadas. NPS también usa las propiedades de acceso telefónico de la cuenta de usuario para realizar una determinación de autorización.

Dado que las directivas de red se procesan en el orden en que aparecen en el complemento NPS, planee colocar primero las directivas más restrictivas en la lista de directivas. Para cada solicitud de conexión, NPS intenta hacer coincidir las condiciones de la directiva con las propiedades de la solicitud de conexión. NPS examina cada directiva de red en orden hasta que encuentre una coincidencia. Si no encuentra ninguna coincidencia, se rechaza la solicitud de conexión.

Pasos clave

Durante el planeamiento de las directivas de red, puede usar los pasos siguientes.

  • Determine el orden de procesamiento de NPS preferido de las directivas de red, de más restrictivo al menos restrictivo.

  • Determine el estado de la directiva. El estado de la directiva puede tener el valor de habilitado o deshabilitado. Si la directiva está habilitada, NPS evalúa la directiva mientras realiza la autorización. Si la directiva no está habilitada, no se evalúa.

  • Determine el tipo de directiva. Debe determinar si la directiva está diseñada para conceder el acceso cuando las condiciones de la directiva coinciden con la solicitud de conexión o si está diseñada para denegar el acceso cuando las condiciones de la directiva coinciden con la solicitud de conexión. Por ejemplo, si quiere denegar explícitamente el acceso inalámbrico a los miembros de un grupo de Windows, puede crear una directiva de red que especifique el grupo, el método de conexión inalámbrica y que tenga una configuración de tipo de directiva de Denegar acceso.

  • Determine si desea que NPS omita las propiedades de acceso telefónico local de las cuentas de usuario que son miembros del grupo en el que se basa la directiva. Cuando esta configuración no está activada, las propiedades de acceso telefónico de las cuentas de usuario anulan las configuraciones establecidas en las directivas de red. Por ejemplo, si se configura una directiva de red que concede el acceso a un usuario pero las propiedades de acceso telefónico de la cuenta de usuario de ese usuario se establecen para denegar el acceso, se deniega el acceso al usuario. Pero si habilita la configuración del tipo de directiva Ignorar las propiedades de acceso telefónico de la cuenta de usuario, el mismo usuario tendrá acceso a la red.

  • Determine si la directiva usa la configuración de origen de la directiva. Esta configuración permite especificar fácilmente un origen para todas las solicitudes de acceso. Los posibles orígenes son una Puerta de enlace de servicios de terminal (TS Gateway), un servidor de acceso remoto (VPN o acceso telefónico), un servidor DHCP, un punto de acceso inalámbrico y un servidor de la Autoridad de registro de mantenimiento. Como alternativa, puede especificar un origen específico del proveedor.

  • Determine las condiciones que deben coincidir para que se aplique la directiva de red.

  • Determine la configuración que se aplica si las condiciones de la directiva de red coinciden con la solicitud de conexión.

  • Determine si quiere usar, modificar o eliminar las directivas de red predeterminadas.

Planificación de la contabilización de cuentas del NPS

NPS ofrece la posibilidad de registrar los datos de contabilidad de RADIUS, como la autenticación de usuario y las solicitudes de contabilidad, en tres formatos: formato IAS, formato compatible con bases de datos y registro de Microsoft SQL Server.

El formato IAS y el formato compatible con la base de datos crean archivos de registro en el NPS local en formato de archivo de texto.

El registro en SQL Server ofrece la posibilidad de registrar en una base de datos compatible con SQL Server 2000 o SQL Server 2005 XML, ampliando la contabilidad de RADIUS para aprovechar las ventajas del registro en una base de datos relacional.

Pasos clave

Durante la planificación de la contabilización de cuentas NPS, puede seguir los pasos siguientes.

  • Determine si quiere almacenar los datos de contabilidad de NPS en archivos de registro o en una base de datos SQL Server.

Contabilidad NPS mediante archivos de registro locales

El registro de las solicitudes de autenticación y contabilidad de los usuarios en archivos de registro se usa principalmente para fines de análisis de conexión y facturación, y también es útil como herramienta de investigación de seguridad, ya que le proporciona un método para rastrear la actividad de un usuario malintencionado después de un ataque.

Pasos clave

Durante la planificación de la contabilidad NPS usando archivos de registro locales, puede usar los siguientes pasos.

  • Determine el formato de archivo de texto que quiere usar para sus archivos de registro de NPS.

  • Elija el tipo de información que quiere registrar. Puede registrar las solicitudes de contabilidad, las solicitudes de autenticación y el estado periódico.

  • Determine la ubicación del disco duro donde quiere almacenar sus archivos de registro.

  • Diseñe la solución de copia de seguridad de archivos de registro. La ubicación del disco duro donde almacene sus archivos de registro debe ser una ubicación que le permita realizar fácilmente copias de seguridad de sus datos. Además, la ubicación del disco duro debe protegerse configurando la lista de control de acceso (ACL) para la carpeta donde se almacenan los archivos de registro.

  • Determine la frecuencia con la que quiere que se creen nuevos archivos de registro. Si quiere que los archivos de registro se creen en función del tamaño del archivo, determine el tamaño máximo de archivo permitido antes de que NPS cree un nuevo archivo de registro.

  • Determine si quiere que NPS elimine los archivos de registro más antiguos si el disco duro se queda sin espacio de almacenamiento.

  • Determine la aplicación o las aplicaciones que desea usar para ver los datos contables y generar informes.

Registro de SQL Server de NPS

El registro de SQL Server de NPS se usa cuando necesita información sobre el estado de la sesión, con fines de creación de informes y análisis de datos, y para centralizar y simplificar la administración de sus datos contables.

NPS ofrece la posibilidad de usar el registro de SQL Server para registrar las solicitudes de autenticación y contabilidad de usuarios recibidas desde uno o varios servidores de acceso a la red a un origen de datos en un equipo que ejecute Microsoft SQL Server Desktop Engine (MSDE 2000), o cualquier versión de SQL Server posterior a SQL Server 2000.

Los datos contables se pasan de NPS en formato XML a un procedimiento almacenado en la base de datos, que es compatible tanto con el lenguaje de consulta estructurado (SQL) como con XML (SQLXML). El registro de las solicitudes de autenticación y contabilidad de usuarios en una base de datos de SQL Server compatible con XML permite que varios NPS tengan un único origen de datos.

Pasos clave

Durante la planificación de la contabilidad de NPS mediante el uso del registro de SQL Server de NPS, puede usar los siguientes pasos.

  • Determine si usted u otro miembro de su organización tiene experiencia en el desarrollo de bases de datos relacionales de SQL Server 2000 o SQL Server 2005 y si comprende cómo usar estos productos para crear, modificar, administrar y gestionar bases de datos de SQL Server.

  • Determine si SQL Server está instalado en NPS o en un equipo remoto.

  • Diseñe el procedimiento almacenado que usará en la base de datos de SQL Server para procesar los archivos XML entrantes que contienen datos contables de NPS.

  • Diseñe la estructura y el flujo de replicación de la base de datos de SQL Server.

  • Determine la aplicación o las aplicaciones que desea usar para ver los datos contables y generar informes.

  • Planee el uso de servidores de acceso de red que envían el atributo Class en todas las solicitudes contables. El atributo Class se envía al cliente de RADIUS en un mensaje Access-Accept y es útil para correlacionar los mensajes Accounting-Request con las sesiones de autenticación. Si el servidor de acceso a la red envía el atributo Class en los mensajes de solicitud de contabilidad, puede usarse para hacer coincidir los registros de contabilidad y autenticación. La combinación de los atributos Unique-Serial-Number, Service-Reboot-Time y Server-Address debe ser una identificación única para cada autenticación que acepte el servidor.

  • Planee usar servidores de acceso a la red que sean compatibles con la contabilidad provisional.

  • Planee usar servidores de acceso a la red que envíen mensajes de Contabilidad activada y Contabilidad desactivada.

  • Planee usar servidores de acceso a la red compatibles con el almacenamiento y el reenvío de datos contables. Los servidores de acceso a la red compatibles con esta característica pueden almacenar datos contables cuando el servidor de acceso a la red no puede comunicarse con el NPS. Cuando el NPS está disponible, el servidor de acceso a la red reenvía los registros almacenados al NPS, lo que proporciona una mayor fiabilidad en la contabilidad con respecto a los servidores de acceso a la red que no proporcionan esta característica.

  • Planifique configurar siempre el atributo Acct-Interim-Interval en las directivas de red. El atributo Acct-Interim-Interval establece el intervalo (en segundos) entre cada actualización intermedia que envía el servidor de acceso a la red. Según RFC 2869, el valor del atributo Acct-Interim-Interval no debe ser inferior a 60 segundos (1 minuto) y no debe ser inferior a 600 segundos (10 minutos), lo que significa que los valores por encima de 600 segundos reducirán la frecuencia de las actualizaciones recibidas por el servidor RADIUS. Para más información, consulte RFC 2869.

  • Asegúrese de que el registro del estado periódico está activado en sus NPS.