Npas windows server 2019 что такое

Как быстро и просто настроить авторизацию через RADIUS от Microsoft? Думаю, это поможет тем, кто захочет иметь возможность заходить на устройства MikroTik через дружелюбный WinBox и простой SSH.

План:

Установка роли NPS;
Добавление RADIUS клиента;
Создание политики подключения;
Создание политики сети;
Добавление сервера авторизации на MikroTik;
Проверка через SSH и WinBox.

Установка роли NPS

Имеем Windows Server 2016 Datacenter с уже установленным доменом.

Выбираем сервер, на котором будет разворачиваться роль. Microsoft не рекомендует делать это на контроллере домена, но в некоторых best practices для уменьшения задержек дают совет ставить именно на него. Добавляем роль Network Policy and Access Server вместе с management tools для настройки.

Install-WindowsFeature NPAS -IncludeManagementTools

Запускаем любым удобным способом админку NPS. Например, через менеджер серверов.

Регистрируем сервер NPS в AD.

netsh ras add registeredserver

Добавление RADIUS клиента

Для того, чтобы сервер знал с какими устройствами налаживать общение нужно добавить их в RADIUS Clients.

Для примера, добавляю свой MikroTik wAP. Friendly name установил как Identity на устройстве и IP заданный на его единственном проводном интерфейсе. Для того, чтобы устройство смогло авторизоваться на сервере нужно ввести ключ. Он создается на сервере либо вручную, либо генерируется автоматически. Я предпочел второй вариант.

New-NpsRadiusClient –Address "10.1.1.21" –Name "router01" –SharedSecret "egEcM4myJCptphGlZ1UymS#qLh^urp@fJ1hF8dE6dwb27NI^oIJtTWKKp^MEsU6p"

Vendor name остановим на стандартном RADIUS.

Устройство добавлено.

Создание политики подключения

Подбираем подходящее название для политики.

Определяем наше устройство с которым будет работать сервер.

Я выбрал только Client Friendly Name со значением Router01. Это четко привязывает данный пункт политики к устройству через созданного клиента. Можно идентифицировать устройство Mikrotik по Identity выбрав NAS Identifier.

Без предварительной конфигурации устройства Identity = MikroTik.

Дальнейшая настройка политики.

На этапе выбора протокола аутентификации достаточно выбрать нешифрованный (о чем получите предупреждение) PAP для SSH или шифрованный CHAP для WinBox. Я выбрал оба. Если есть необходимость использовать web версию, то достаточно включить MS-CHAPv2, в остальном всё аналогично.

Собственно, предупреждение о выборе небезопасного способа. Предлагают почитать пошаговый справочный материал.

На данном этапе я не стал ничего трогать.

Итоговые установки политики.

У меня не получилось воспроизвести это через PowerShell, даже стандартный example с technet’а. Буду признателен, если подскажете почему.

netsh nps add crp name = "Request Policy Router01" state = "ENABLE" processingorder = "1" policysource = "0" conditionid ="0x1020" conditiondata = "router01" profileid = "0x1025" profiledata = "0x1" profileid = "0x1009" profiledata = "0x1" "0x2" profileid = "0x1fb0" profiledata = "TRUE"

Выбираем нужный приоритет двигая выше или ниже пункт политики.

Создание политики сети

Назовем её Routers.

Как и прежде, нужно определить условия.

В AD у меня создан дополнительный пользователь состоящий в группе Domain Admins. Выбираю условие Windows Group исходя из того, чтобы все администраторы домена смогли получать доступ к MikroTik.

Разрешительное или запретительное правило. Мы будем разрешать всем, кто попал под условие.

Способ аутенификации выбираем аналогичный прошлой политике.

Исходя из необходимости можно настроить дополнительные настройки. Я оставил без изменений.

Далее необходимо выбрать что будет отправляться на сервер.

Итоговые настройки политики сети.

Выбираем необходимый приоритет среди других политик, если необходимо.

Чтобы учетная запись проверялась через NPS в AD у этого пользователя на вкладке Dial-in в разделе Network Access Permission должен быть отмечен пункт Control access through NPS Network Policy.

Для возможности авторизовываться через WinBox нужно включить обратимое шифрование в профиле пользователя.

Добавление сервера авторизации на MikroTik

Первым делом присвоим System/Identity равным router01 и IP с маской для интерфейса.

/system identity set name=router01
/ip address add address=10.1.1.21/24 interface=ether1 network=10.1.1.0

В System/Users и на вкладке Users включаем пункт Use RADIUS. По умолчанию выбран доступ только для чтения.

/user aaa set use-radius=yes

Открываем настройки Radius и добавляем новый сервер. Сервис выбирается исходя из назначения. Лучше, конечно же, делить доступ между ними. Address — адрес сервера на котором установлен NPS.

Secret — ключ, который был сгенерирован на стадии добавления клиента на сервере.

/radius add address=10.1.1.1 secret=egEcM4myJCptphGlZ1UymS#qLh^urp@fJ1hF8dE6dwb27NI^oIJtTWKKp^MEsU6p service=login

Проверка через SSH и WinBox

Проверка подключения через SSH и экспорт конфигурации.

И проверяем авторизацию в Winbox.

Как видим, в активных пользователях висят системный admin и оба подключения доменного юзера с доступом для чтения через SSH и Winbox.

Всё работает.
Спасибо за внимание.

For network access and policy management capabilities, Microsoft’s RADIUS server and proxy tool is the Network Policy Server (NPS). NPS offers authentication, authorization, and accounting (AAA), enables the use of heterogeneous network equipment and ensures the health of network devices. 

The RADIUS protocol provides the configuration and management of authentication for network clients central to NPS functionality. Current editions of NPS are installable via the Network Policy and Access Services (NPAS) feature in Windows Server 2016 and Server 2019.

This article looks at what RADIUS servers are, the purpose of Network Policy Servers, their role in networking, and best practices for managing NPS.

Learn more about the range of server types, functions, and purposes in our Guide to Servers.

What Is the RADIUS Protocol?

RADIUS stands for Remote Authentication Dial-In User Service and was initially a client-server protocol for dial-up connections. While dial-up has lost its luster in enterprise use, RADIUS servers remain a convenient way to offload authentication from access points. 

RADIUS servers can run on Windows or Unix servers and, most importantly, allow administrators to control who can connect to the network. Clients for the RADIUS server represent network access points; users make requests to RADIUS clients that pass along the request to the RADIUS server for authentication.

What Do RADIUS Servers Do?

Within communication protocols for networks, like user datagram protocol (UDP) or transmission control protocol (TCP), RADIUS servers communicate with network access servers.

A client device makes a connection request to the network access server (NAS). The NAS works with the RADIUS server, relying on its AAA capabilities to authenticate the user and respond with permission for the proper configuration.

Read more: What is Server Management?

What Is the Purpose of NPS?

Network Policy Server is the solution for Windows network administrators using RADIUS capabilities. Not only does NPS offer configurable policies for network access, but it also ensures non-Microsoft devices can connect once authenticated. 

By placing users and client devices in groups or automating classification, administrators can control the types of clients and permissions available to network users. This control allows for continued management of access policies and also enables event logging for accounting purposes. NPS also scans requests to ensure client health and maintain network integrity.

Read more: Server Security Best Practices.

The 3 Roles of NPS

Read more: Syxsense Manage & Syxsense Secure: Endpoint Management Software Review

NPS Best Practices

Microsoft identifies seven areas of best practices when utilizing Network Policy Server. These are provided in the below table.

To learn more about the most recent updates to Network Policy Server, head to Microsoft’s NPS documentation.

При обслуживании больших сетей системные администраторы часто сталкиваются с проблемами аутентификации на сетевом оборудовании. В частности, довольно сложно организовать нормальную работу нескольких сетевых администраторов под индивидуальными учетными записями на большом количестве оборудования (приходится вести и поддерживать в актуальном состоянии базу локальных учетных записей на каждом устройстве). Логичным решение было бы использовать для авторизации уже существующей базы учетных записей — Active Directory. В этой статье мы разберемся, как настроить доменную (Active Directory) аутентификацию на активном сетевом оборудовании (коммутаторы, маршрутизаторы).

Не все сетевое оборудование популярных вендоров (CISCO, HP, Huawei) поддерживает функционал для непосредственного обращения к каталогу LDAP, и такое решение не будет универсальным. Для решения нашей задачи подойдет протокол AAA (Authentication Authorization and Accounting), фактически ставший стандартом де-факто для сетевого оборудования. Клиент AAA (сетевое устройство) отправляет данные авторизующегося пользователя на сервер RADIUS и на основе его ответа принимает решение о предоставлении / отказе доступа.

Протокол Remote Authentication Dial In User Service (RADIUS) в Windows Server 2012 R2 включен в роль NPS (Network Policy Server). В первой части статьи мы установим и настроим роль Network Policy Server, а во второй покажем типовые конфигурации сетевого устройств с поддержкой RADUIS на примере коммутаторов HP Procurve и оборудования Cisco.

Установка и настройка сервера с ролью Network Policy Server

Как правило, сервер с ролью NPS рекомендуется устанавливать на выделенном сервере (не рекомендуется размещать эту роль на контроллере домена). В данном примере роль NPS мы будем устанавливать на сервере с Windows Server 2012 R2.

Откройте консоль Server Manager и установите роль Network Policy Server (находится в разделе Network Policy and Access Services).

После окончания установки запустите mmc-консоль управления Network Policy Server. Нас интересуют три следующих раздела консоли:

1. RADIUS Clients — содержит список устройств, которые могут аутентифицироваться на сервере
2. Connection Request Policies – определяет типы устройств, которые могут аутентифицироваться
3. Network Polices – правила аутентификации

Добавим нового клиента RADIUS (это будет коммутатор HP ProCurve Switch 5400zl), щелкнув ПКМ по разделу RADIUS Clients и выбрав New. Укажем:

• Friendly Name:sw-HP-5400-1
• Address (IP or DNS): 10.10.10.2
• Shared secret (пароль/секретный ключ): пароль можно указать вручную (он должен быть достаточно сложным), либо сгенерировать с помощью специальной кнопки (сгенерированный пароль необходимо скопировать, т.к. в дальнейшем его придется указать на сетевом устройстве).

Отключим стандартную политику (Use Windows authentication for all users) в разделе Connection Request Policies, щелкнув по ней ПКМ и выбрав Disable.

Создадим новую политику с именем Network-Switches-AAA и нажимаем далее. В разделе Сondition создадим новое условие. Ищем раздел RADIUS Client Properites и выбираем Client Friendly Name.

В качестве значения укажем sw-?. Т.е. условие будет применяться для всех клиентов RADIUS, начинающийся с символов :”sw-“. Жмем Next->Next-> Next, соглашаясь со всеми стандартными настройками.

Далее в разделе Network Policies создадим новую политику аутентификации. Укажите ее имя, например Network Switch Auth Policy for Network Admins. Создадим два условия: в первом условии Windows Groups, укажем доменную группу, члены которой могут аутентифицироваться (учетные записи сетевых администраторов в нашем примере включены в группу AD Network Admins) Второе условие Authentication Type, выбрав в качестве протокола аутентификации PAP.

Далее в окне Configure Authentication Methods снимаем галки со всех типов аутентификации, кроме Unencrypted authentication (PAP. SPAP).

В окне Configure Settings изменим значение атрибута Service-Type на Administrative.

В остальных случаях соглашаемся со стандартными настройками и завершаем работу с мастером.

И, напоследок, переместим новую политику на первое место в списке политик.

Настройка сетевого оборудования для работы с сервером RADUIS

Осталось настроить наше сетевое оборудование для работы с сервером Radius. Подключимся к нашему коммутатору HP ProCurve Switch 5400 и внесем следующе изменение в его конфигурацию (измените ip адрес сервера Raduis и пароль на свои).

aaa authentication console enable radius local

aaa authentication telnet login radius local

aaa authentication telnet enable radius local

aaa authentication ssh login radius local

aaa authentication ssh enable radius local

aaa authentication login privilege-mode

radius-server key YOUR-SECRET-KEY

radius-server host 10.10.10.44 YOUR-SECRET-KEY auth-port 1645 acct-port 1646

radius-server host 10.10.10.44 auth-port 1645

radius-server host 10.10.10.44 acct-port 1646

aaa authentication telnet login radius local

aaa authentication telnet enable radius local

Не закрывая консольное окно коммутатора (это важно!, иначе, если что-то пойдет не так, вы более не сможете подключиться к своему коммутатору), откройте вторую telnet-сессию. Должно появиться новое окно авторизации, в котором будет предложено указать имя и пароль учетной записи. Попробуйте указать данные своей учетной записи в AD (она должна входить в группу Network Admins ). Если подключение установлено – вы все сделали правильно!

Для коммутатора Cisco конфигурация, предполагающая использование доменных учетных записей для аутентификации и авторизации, может выглядеть так:

Примечание. В зависимости от модели сетевого оборудования Cisco и версии IOS конфигурация может несколько отличаться.

aaa new-model
radius-server host 10.10.10.44 auth-port 1645 acct-port 1646 key YOUR-SECRET-KEY
aaa authentication login default group radius local
aaa authorization exec default group radius local
ip radius source-interface Vlan421
line con 0
line vty 0 4
line vty 5 15

Примечание. В такой конфигурации для аутентификации сначала используется сервер RADIUS, а если он не доступен – локальная учетная запись.

Для Cisco ASA конфигурация будет выглядеть так:

aaa-server RADIUS protocol radius
aaa-server RADIUS host 10.10.10.44 key YOUR-SECRET-KEY
radius-common-pw YOUR-SECRET-KEY
aaa authentication telnet console RADIUS LOCAL
aaa authentication ssh console RADIUS LOCAL
aaa authentication http console RADIUS LOCAL
aaa authentication http console RADIUS LOCAL

In this post I will show how to set up a RADIUS server on Windows Server 2019 to provide 802.1X Wireless Connections through wireless access points.

Actually I want to set up a RADIUS server for IEEE 802.11 wireless networks, but its nearly the same as for wired (Ethernet) networks besides the NAS Port Type (type of media used) is IEEE 802.11 wireless instead of wired Ethernet.

IEEE 802.1X is an IEEE Standard for port-based Network Access Control (PNAC). It is part of the IEEE 802.1 group of networking protocols. It provides an authentication mechanism to devices wishing to attach to a LAN or WLAN.
Source: https://en.wikipedia.org/wiki/IEEE_802.1X
https://en.wikipedia.org/wiki/IEEE_802

Microsoft’s implementation of a Remote Authentication Dial-In User Service (RADIUS) server is for Windows Server operating systems later than Windows Server 2003 the Network Policy and Access Services (NPAS) server role.

NPAS replaces the Internet Authentication Service (IAS) from Windows Server 2003.
Source: https://en.wikipedia.org/wiki/Network_Policy_Server

So first I will install the Network Policy and Access Services (NPAS) server role either on a domain controller or member server.

Now as the Network Policy and Access Services (NPAS) server role is installed you will have a new console named Network Policy Server.

Open the Network Policy Server console and select the RADIUS server for 802.1X Wireless or Wired Connections template to configure NPS by using the wizard.

Click on Configure 802.1X to start the wizard.

Select Secure Wireless Connections

Here I need to add all my wlan access points as RADIUS clients.

• Friendly name
• IP address or FQDN
• Shared secret
  Use a unique RADIUS shared secret for each wireless AP unless you are planning to configure APs as RADIUS Clients in NPS by group. If you plan to configure APs by group in NPS, the shared secret must be the same for every member of the group. In addition, each shared secret you use should be a random sequence of at least 22 characters that mixes uppercase and lowercase letters, numbers, and punctuation.
  Source: https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/wireless/e-wireless-access-deployment#to-configure-your-wireless-aps

For authentication I will use the Protected EAP (PEAP) protocol.

Click on Configure to select a certificate to prove the identity of the RADIUS server to the clients. You can use here the default computer certificate from your internal PKI.

The clients needs to trust that certificate, otherwise the user’s wont be able to connect to the wireless network.

It then creates an encrypted TLS tunnel between the client and the authentication server. In most configurations, the keys for this encryption are transported using the server’s public key. The ensuing exchange of authentication information inside the tunnel to authenticate the client is then encrypted and user credentials are safe from eavesdropping.

Simplifying WPA2-Enterprise and 802.1x

Client / Supplicant
In order for a device to participate in the 802.1x authentication, it must have a piece of software called a supplicant installed in the network stack. The supplicant is necessary as it will participate in the initial negotiation of the EAP transaction with the switch or controller and package up the user credentials in a manner compliant with 802.1x. If a client does not have a supplicant, the EAP frames sent from the switch or controller will be ignored and the switch will not be able to authenticate.

Fortunately, almost all devices we might expect to connect to a wireless network have a supplicant built-in. SecureW2 provides a 802.1x supplicant for devices that don’t have one natively.

Thankfully, the vast majority of device manufacturers have built-in support for 802.1x. The most common exceptions to this might be consumer gear, such as game consoles, entertainment devices or some printers. Generally speaking, these devices should be less than 10% of the devices on your network and are best treated as the exception rather than the focus.

Switch / Access Point / Controller
The switch or wireless controller plays an important role in the 802.1x transaction by acting as a ‘broker’ in the exchange. Until a successful authentication, the client does not have network connectivity, and the only communication is between the client and the switch in the 802.1x exchange.

The switch/controller initiates the exchange by sending an EAPOL-Start packet to the client when the client connects to the network. The client’s responses are forwarded to the correct RADIUS server based on the configuration in the Wireless Security Settings. When the authentication is complete, the switch/controller makes a decision whether to authorize the device for network access based on the user’s status and possibly the attributes contained in the Access_Accept packet sent from the RADIUS server.

Successful mutual PEAP-MS-CHAP v2 authentication has two main parts:

• The client authenticates the NPS. During this phase of mutual authentication, the NPS sends its server certificate to the client computer so that the client can verify the NPS’s identity with the certificate. To successfully authenticate the NPS, the client computer must trust the CA that issued the NPS certificate. The client trusts this CA when the CA’s certificate is present in the Trusted Root Certification Authorities certificate store on the client computer.
• The NPS authenticates the user. After the client successfully authenticates the NPS, the client sends the user’s password-based credentials to the NPS, which verifies the user’s credentials against the user accounts database in Active Directory Domain Services (AD DS).

If the credentials are valid and authentication succeeds, the NPS begins the authorization phase of processing the connection request. If the credentials are not valid and authentication fails, NPS sends an Access Reject message and the connection request is denied.

The behavior requiring the client to validate the server certificate can be disabled, but disabling server certificate validation is not recommended in production environments.

Source: https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/wireless/a-deploy-8021x-wireless-access#authentication

The server running NPS performs authorization as follows:

• NPS checks for restrictions in the user or computer account dial-in properties in AD DS. Every user and computer account in Active Directory Users and Computers includes multiple properties, including those found on the Dial-in tab. On this tab, in Network Access Permission, if the value is Allow access, the user or computer is authorized to connect to the network. If the value is Deny access, the user or computer is not authorized to connect to the network. If the value is Control access through NPS Network Policy, NPS evaluates the configured network policies to determine whether the user or computer is authorized to connect to the network.
• NPS then processes its network policies to find a policy that matches the connection request. If a matching policy is found, NPS either grants or denies the connection based on that policy’s configuration.

If both authentication and authorization are successful, and if the matching network policy grants access, NPS grants access to the network, and the user and computer can connect to network resources for which they have permissions.

Source: https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/wireless/a-deploy-8021x-wireless-access#authorization

Keep in mind regarding the communication between the NPS server and client as described in both Microsoft articles about authentication and authorization above.

As mentioned further above in the great article from SECUREW2, the client cannot communicate directly with the RADIUS server to authenticate himself and the server, as it does not have network connectivity until a successful authentication. The communication between the client and RADIUS server is established through the access points (switches for wired networks), which will acting as a broker in the exchange between both.

Here I will add all groups which are allowed to access the network through my wlan access points.

For computer authentication you should create a security group which includes all computer accounts they should be able to authenticate against NPS and add it to your network policy (Conditions tab) as windows group. NPS uses then this policy to authorize the connection request.

Further each of those computers needs a computer certificate installed from your internal PKI (CA), which is by default published to the Enterprise NTAuth store.

The computers wlan profile also needs to be configured to enable computer authentication, I will show this further below in the section about configuring a group policy.

Btw. you can also use certificates from a third-party CA, but in that case you need to import the CA certificate into your Enterprise NTAuth store and the computer certificate needs to mapped to the computer account in Active Directory. About how you will find in the following article from Microsoft:
https://docs.microsoft.com/en-us/troubleshoot/windows-server/windows-security/import-third-party-ca-to-enterprise-ntauth-store

The Enterprise NTAuth store is used by your Active Directory domain to determine which certification authorities to trust for issuing certificates that are used to authenticate and authorize a user or computer.

To check which CAs are stored in the Enterprise NTAuth store, you can use the PKI Tool (PKIVIEW). On your CA server open the tool pkiview.msc, right click on Enterprise PKI and select Manage AD Containers… . Here you will see in the tab NTAuthCertificates which CAs are still trusted.

In the next dialog you can configure traffic control attributes (RADIUS tunnel attributes) to allow and deny traffic to user’s based on their assigned VLANs.

You can change all of theses settings later directly in the NPS console.

Here you can modify the RADIUS clients.

The wizard will create a Connection Request Policy and a Network Policy.

Connection Request Policies
https://docs.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-crp-crpolicies

Connection request policies are sets of conditions and settings that allow network administrators to designate which Remote Authentication Dial-In User Service (RADIUS) servers perform the authentication and authorization of connection requests that the server running Network Policy Server (NPS) receives from RADIUS clients. Connection request policies can be configured to designate which RADIUS servers are used for RADIUS accounting.

By default the wizard will set to process the authentication request locally on the server.

Network Policy

You can also configure Accounting for the NPS server.

Configure Network Policy Server Accounting
https://docs.microsoft.com/en-us/windows-server/networking/technologies/nps/nps-accounting-configure

The wizard created our Network Policy and we do not need to change here anything.

By adding Windows Groups, it doesn’t matter if they were local groups on the server itself or domain groups, NPS will process both of them.

As mentioned further above you can use here the default computer certificate on the NPS server from your internal PKI.

The clients needs to trust that certificate, otherwise the user’s wont be able to connect to the wireless network.

It then creates an encrypted TLS tunnel between the client and the authentication server. In most configurations, the keys for this encryption are transported using the server’s public key. The ensuing exchange of authentication information inside the tunnel to authenticate the client is then encrypted and user credentials are safe from eavesdropping.

Configure your WLAN Access Points

On the wlan access points we have to configure the IP address from the NPS (RADIUS) server, port and shared secret.

The Radius Port for authentication by default is UDP 1812 or 1645.

Further we need to select a security mode our access points will use to authenticate users or devices (computer authentication as mentioned further above). When using a RADIUS server we want that users authenticate themselves by using their username and password for the network, therefore we need to select WPA2 or WPA3-Enterpise, also for computer authentication.

Keep in mind that even in the year 2022 not all devices support WPA3.

You can check the ports in the NPS console by right clicking on NPS(Local) and select properties. Here within the tab Ports, you can see on what ports the NPS server is listening for authentication and if used accounting.

The Radius Port for accounting by default is UDP 1813 or 1646.

Optionally we can also configure Radius Accounting as mentioned.

The RADIUS server also collects a variety of information sent by the NAS that can be used for accounting and for reporting on network activity. The RADIUS client sends information to designated RADIUS servers when the User logs on and logs off. The RADIUS client may send additional usage information on a periodic basis while the session is in progress. The requests sent by the client to the server to record logon/logoff and usage information are generally called accounting requests.

For more information on RADIUS accounting, see RFC 2866.

Source: https://learn.microsoft.com/en-us/windows/win32/nps/ias-radius-authentication-and-accounting

Configure Wireless Network (IEEE 802.11) Policies | Wi-Fi profiles

You can configure group policies in your network to define preferred networks and settings for the WLAN connection to your clients.

To activate default Wireless Network (IEEE 802.11) Policies
https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/wireless/e-wireless-access-deployment#to-activate-default-wireless-network-ieee-80211-policies

Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Wireless Network (IEEE 802.11) Policies

Clients should connect automatically to this network when it is in range.

For the network authentication method I have to select Protected EAP (PEAP) as used on the NPS server and for the authentication mode I will use User or Computer authentication.

Even the most common method of authentication with PEAP-MSCHAPv2 is user auth, in which clients are prompted to enter their domain credentials, the Windows NPS server role also supports computer authentication by using the PEAP-MSCHAPv2 protocol.

In order to use computer authentication, you also have to install a computer certificate on the clients and issued from your internal PKI as mentioned further above.

For computer authentication you can configure certificate auto-enrollment for the client computers as shown in my following post: https://blog.matrixpost.net/configure-certificate-auto-enrollment/

In the advanced settings you can enable single sign-on for the wireless network, by checking this your password to logon to your computer will also be passed and used to establish the wireless connection with the access points.

Further if you select Perform immediately before User Logon as show in the figure below, the computer will first try to connect to the wireless access points when the user is entering its password and then subsequently will get logged on to its computer after the wireless connection is established.

In case computer authentication will be performed, the computer already connects at the logon screen to the network, as it doesn’t matter which user will get logged on.

Therefore in both cases the computer can perform a network login against the domain controllers and logon scripts and group policies will be applied to the computer.

If the wireless connection couldn’t be established, the user will get logged on to its computer by using the local cached credentials as usual but without processing the logon scripts and applying the group policies from the domain controller.

At the logon screen you will see the wireless network to which Windows tries to connect after providing your password for the logon.

User vs. Machine Authentication
The most common method of authentication with PEAP-MSCHAPv2 is user auth, in which clients are prompted to enter their domain credentials. It is also possible to configure RADIUS for machine authentication, in which the computers themselves are authenticated against RADIUS, so the user doesn’t need to provide any credentials to gain access. Machine auth is typically accomplished using EAP-TLS, though some RADIUS server options do make it simple to accomplish machine auth using PEAP-MSCHAPv2 (including Windows NPS, as outlined in the example config below).

The following example configuration outlines how to set up Windows NPS as a RADIUS server, with Active Directory acting as a userbase:

Add the Network Policy Server (NPS) role to Windows Server.
Add a trusted certificate to NPS.
Add APs as RADIUS clients on the NPS server.
Configure a policy in NPS to support PEAP-MSCHAPv2.
(Optional for machine auth) Deploy PEAP-MSCHAPv2 wireless network settings to domain member computers using Group Policy.

Source: https://documentation.meraki.com/MR/Encryption_and_Authentication/Configuring_RADIUS_Authentication_with_WPA2-Enterprise

Create Wi-Fi profiles using the System Center Configuration Manager (SCCM) or Microsoft Intune.

You can also use SCCM or Microsoft Intune to configure Wi-Fi profiles. This topic is well documented from Microsoft in the following articles.

Manage Wi-Fi profiles on local computer by using the netsh command

You can also use the netsh command line tool to manage the Wi-Fi profiles on a local computer.

• netsh wlan show profile -> list profiles located on the local computer
• netsh wlan show profiles interface=”wi-fi” -> list profile for specific interface
• netsh wlan show drivers -> list driver information about the wireless adapter
• netsh wlan show wirelesscapabilities -> list capabilities of the wireless adapter
• netsh wlan show interfaces -> list all wireless interfaces on the local computer
• netsh wlan show profile name=”myAP” key=clear -> will display the security key in plaintext
• netsh wlan set profileparameter name=”myAP” connectionmode=manual -> will disable connect automatically
• netsh wlan set profileparameter name=”myAP” connectionmode=auto -> will enable connect automatically
• netsh wlan delete profile name=”myAP” -> will delete the myAP wlan profile
• netsh wlan delete profile name=* -> will delete all wlan profiles on the local computer
• netsh wlan export profile name=”WiFiNetwork” key=clear folder=”C:path” key=clear -> Export a wlan profile
• netsh wlan add profile filename=”C:pathprofileFile.xml” user=all -> Import a wlan profile for all user’s -> user=current only for the current user
• netsh wlan show wlanreport -> will create a wireless adapter report will ->
  Analyze the wireless network report
  https://support.microsoft.com/en-us/windows/analyze-the-wireless-network-report-76da0daa-1db2-6049-d154-7bb679eb03ed

Troubleshooting

In case something went wrong and your clients won’t connect to the the wireless network, you can investigate several logs to get more details about the problem.

You can search in two locations for logs to investigate the reason why clients can’t connect to the network.

For general configuration problems between the NPS server and the RADIUS clients, you can investigate the Event Viewer.

Custom Views -> Server Roles -> Network Policy and Access Services

For problems regarding authentication from the user’s itself, you should use the Accounting logs. Here you can see the default path from them.

To investigate them I would suggest to use a specific log viewer like the IAS Log Viewer from DeepSoftware LLC. You can use this viewer also to investigate VPN logging from the Windows Routing and Remote Access servers.

IAS Log Viewer
https://www.deepsoftware.com/iasviewer/

IAS_SUCCESS -> the user or computer authenticated successfully against the NPS server, formerly Internet Authentication Service (IAS)

NPAS replaces the Internet Authentication Service (IAS) from Windows Server 2003.
Therefore you will see IAS_SUCCESS messages in the logs from NPS.
Source: https://en.wikipedia.org/wiki/Network_Policy_Server

Reason for rejecting a user. Can be:

Field (26) Reason-Code Number

• 0 = IAS_SUCCESS
• 1 = IAS_INTERNAL_ERROR
• 2 = IAS_ACCESS_DENIED
• 3 = IAS_MALFORMED_REQUEST
• 4 = IAS_GLOBAL_CATALOG_UNAVAILABLE
• 5 = IAS_DOMAIN_UNAVAILABLE
• 6 = IAS_SERVER_UNAVAILABLE
• 7 = IAS_NO_SUCH_DOMAIN
• 8 = IAS_NO_SUCH_USER
• 16 = IAS_AUTH_FAILURE
• 17 = IAS_CHANGE_PASSWORD_FAILURE
• 18 = IAS_UNSUPPORTED_AUTH_TYPE
• 32 = IAS_LOCAL_USERS_ONLY
• 33 = IAS_PASSWORD_MUST_CHANGE
• 34 = IAS_ACCOUNT_DISABLED
• 35 = IAS_ACCOUNT_EXPIRED
• 36 = IAS_ACCOUNT_LOCKED_OUT
• 37 = IAS_INVALID_LOGON_HOURS
• 38 = IAS_ACCOUNT_RESTRICTION
• 48 = IAS_NO_POLICY_MATCH
• 64 = IAS_DIALIN_LOCKED_OUT
• 65 = IAS_DIALIN_DISABLED
• 66 = IAS_INVALID_AUTH_TYPE
• 67 = IAS_INVALID_CALLING_STATION
• 68 = IAS_INVALID_DIALIN_HOURS
• 69 = IAS_INVALID_CALLED_STATION
• 70 = IAS_INVALID_PORT_TYPE
• 71 = IAS_INVALID_RESTRICTION
• 80 = IAS_NO_RECORD
• 96 = IAS_SESSION_TIMEOUT
• 97 = IAS_UNEXPECTED_REQUEST

Source: https://www.radiusreporting.com/IAS-DB-Attribute-Format-Table.html

EAP authentication exchange for wireless clients through the access point and RADIUS server stuck by using a route-based IPSec in pfSense during the SSL handshake and here exactly after the Client Hello

If you ran into that issue, you can read my following post about how to set up a lean Branch Office Network without any Servers and DCs inside by using an IPSec S2S VPN Tunnel connected with the Headquarters Network.

Links

Настраиваем доменную аутентификацию на сетевом оборудовании

При обслуживании больших сетей системные администраторы часто сталкиваются с проблемами аутентификации на сетевом оборудовании. В частности, довольно сложно организовать нормальную работу нескольких сетевых администраторов под индивидуальными учетными записями на большом количестве оборудования (приходится вести и поддерживать в актуальном состоянии базу локальных учетных записей на каждом устройстве). Логичным решение было бы использовать для авторизации уже существующей базы учетных записей — Active Directory. В этой статье мы разберемся, как настроить доменную (Active Directory) аутентификацию на активном сетевом оборудовании (коммутаторы, маршрутизаторы).

Не все сетевое оборудование популярных вендоров (CISCO, HP, Huawei) поддерживает функционал для непосредственного обращения к каталогу LDAP, и такое решение не будет универсальным. Для решения нашей задачи подойдет протокол AAA (Authentication Authorization and Accounting), фактически ставший стандартом де-факто для сетевого оборудования. Клиент AAA (сетевое устройство) отправляет данные авторизующегося пользователя на сервер RADIUS и на основе его ответа принимает решение о предоставлении / отказе доступа.

Протокол Remote Authentication Dial In User Service (RADIUS) в Windows Server 2012 R2 включен в роль NPS (Network Policy Server). В первой части статьи мы установим и настроим роль Network Policy Server, а во второй покажем типовые конфигурации сетевого устройств с поддержкой RADUIS на примере коммутаторов HP Procurve и оборудования Cisco.

Установка и настройка сервера с ролью Network Policy Server

Как правило, сервер с ролью NPS рекомендуется устанавливать на выделенном сервере (не рекомендуется размещать эту роль на контроллере домена). В данном примере роль NPS мы будем устанавливать на сервере с Windows Server 2012 R2.

Откройте консоль Server Manager и установите роль Network Policy Server (находится в разделе Network Policy and Access Services).

После окончания установки запустите mmc-консоль управления Network Policy Server. Нас интересуют три следующих раздела консоли:

Добавим нового клиента RADIUS (это будет коммутатор HP ProCurve Switch 5400zl), щелкнув ПКМ по разделу RADIUS Clients и выбрав New. Укажем:

Отключим стандартную политику (Use Windows authentication for all users) в разделе Connection Request Policies, щелкнув по ней ПКМ и выбрав Disable.

Создадим новую политику с именем Network-Switches-AAA и нажимаем далее. В разделе Сondition создадим новое условие. Ищем раздел RADIUS Client Properites и выбираем Client Friendly Name.

В качестве значения укажем sw-?. Т.е. условие будет применяться для всех клиентов RADIUS, начинающийся с символов :”sw-“. Жмем Next->Next-> Next, соглашаясь со всеми стандартными настройками.

Далее в разделе Network Policies создадим новую политику аутентификации. Укажите ее имя, например Network Switch Auth Policy for Network Admins. Создадим два условия: в первом условии Windows Groups, укажем доменную группу, члены которой могут аутентифицироваться (учетные записи сетевых администраторов в нашем примере включены в группу AD Network Admins) Второе условие Authentication Type, выбрав в качестве протокола аутентификации PAP.

Далее в окне Configure Authentication Methods снимаем галки со всех типов аутентификации, кроме Unencrypted authentication (PAP. SPAP).

В окне Configure Settings изменим значение атрибута Service-Type на Administrative.

В остальных случаях соглашаемся со стандартными настройками и завершаем работу с мастером.

И, напоследок, переместим новую политику на первое место в списке политик.

Настройка сетевого оборудования для работы с сервером RADUIS

Осталось настроить наше сетевое оборудование для работы с сервером Radius. Подключимся к нашему коммутатору HP ProCurve Switch 5400 и внесем следующе изменение в его конфигурацию (измените ip адрес сервера Raduis и пароль на свои).

Совет. Если в целях безопасности вы запретили подключаться к сетевому оборудованию через telnet, эти строки нужно удалить из конфига:

Не закрывая консольное окно коммутатора (это важно!, иначе, если что-то пойдет не так, вы более не сможете подключиться к своему коммутатору), откройте вторую telnet-сессию. Должно появиться новое окно авторизации, в котором будет предложено указать имя и пароль учетной записи. Попробуйте указать данные своей учетной записи в AD (она должна входить в группу Network Admins ). Если подключение установлено – вы все сделали правильно!

Для коммутатора Cisco конфигурация, предполагающая использование доменных учетных записей для аутентификации и авторизации, может выглядеть так:

Для Cisco ASA конфигурация будет выглядеть так:

Совет. Если что то-не работает, проверьте:

Источник

Авторизация через Network Policy Server (NPS) для MikroTik

Как быстро и просто настроить авторизацию через RADIUS от Microsoft? Думаю, это поможет тем, кто захочет иметь возможность заходить на устройства MikroTik через дружелюбный WinBox и простой SSH.

Установка роли NPS

Имеем Windows Server 2016 Datacenter с уже установленным доменом.

Выбираем сервер, на котором будет разворачиваться роль. Microsoft не рекомендует делать это на контроллере домена, но в некоторых best practices для уменьшения задержек дают совет ставить именно на него. Добавляем роль Network Policy and Access Server вместе с management tools для настройки.

Запускаем любым удобным способом админку NPS. Например, через менеджер серверов.

Регистрируем сервер NPS в AD.

Добавление RADIUS клиента

Для того, чтобы сервер знал с какими устройствами налаживать общение нужно добавить их в RADIUS Clients.

Для примера, добавляю свой MikroTik wAP. Friendly name установил как Identity на устройстве и IP заданный на его единственном проводном интерфейсе. Для того, чтобы устройство смогло авторизоваться на сервере нужно ввести ключ. Он создается на сервере либо вручную, либо генерируется автоматически. Я предпочел второй вариант.

Vendor name остановим на стандартном RADIUS.

Создание политики подключения

Подбираем подходящее название для политики.

Определяем наше устройство с которым будет работать сервер.

Я выбрал только Client Friendly Name со значением Router01. Это четко привязывает данный пункт политики к устройству через созданного клиента. Можно идентифицировать устройство Mikrotik по Identity выбрав NAS Identifier.

Без предварительной конфигурации устройства Identity = MikroTik.

Дальнейшая настройка политики.

На этапе выбора протокола аутентификации достаточно выбрать нешифрованный (о чем получите предупреждение) PAP для SSH или шифрованный CHAP для WinBox. Я выбрал оба. Если есть необходимость использовать web версию, то достаточно включить MS-CHAPv2, в остальном всё аналогично.

Собственно, предупреждение о выборе небезопасного способа. Предлагают почитать пошаговый справочный материал.

На данном этапе я не стал ничего трогать.

Итоговые установки политики.

У меня не получилось воспроизвести это через PowerShell, даже стандартный example с technet’а. Буду признателен, если подскажете почему.

Выбираем нужный приоритет двигая выше или ниже пункт политики.

Создание политики сети

Назовем её Routers.

Как и прежде, нужно определить условия.

В AD у меня создан дополнительный пользователь состоящий в группе Domain Admins. Выбираю условие Windows Group исходя из того, чтобы все администраторы домена смогли получать доступ к MikroTik.

Разрешительное или запретительное правило. Мы будем разрешать всем, кто попал под условие.

Способ аутенификации выбираем аналогичный прошлой политике.

Исходя из необходимости можно настроить дополнительные настройки. Я оставил без изменений.

Далее необходимо выбрать что будет отправляться на сервер.

Итоговые настройки политики сети.

Выбираем необходимый приоритет среди других политик, если необходимо.

Чтобы учетная запись проверялась через NPS в AD у этого пользователя на вкладке Dial-in в разделе Network Access Permission должен быть отмечен пункт Control access through NPS Network Policy.

Для возможности авторизовываться через WinBox нужно включить обратимое шифрование в профиле пользователя.

Добавление сервера авторизации на MikroTik

Первым делом присвоим System/Identity равным router01 и IP с маской для интерфейса.

В System/Users и на вкладке Users включаем пункт Use RADIUS. По умолчанию выбран доступ только для чтения.

Открываем настройки Radius и добавляем новый сервер. Сервис выбирается исходя из назначения. Лучше, конечно же, делить доступ между ними. Address — адрес сервера на котором установлен NPS.

Secret — ключ, который был сгенерирован на стадии добавления клиента на сервере.

Проверка через SSH и WinBox

Проверка подключения через SSH и экспорт конфигурации.

И проверяем авторизацию в Winbox.

Как видим, в активных пользователях висят системный admin и оба подключения доменного юзера с доступом для чтения через SSH и Winbox.

Источник

Windows Server 2019

История Windows Server насчитывает уже более 25 лет: Windows NT 3.1 Advanced Server был выпущен 27 июля 1993 года. В октябре 2018 года, через три года после предыдущего большого релиза, был выпущен Windows Server 2019. Windows Server 2019 развивает и улучшает возможности, заложенные в предыдущих релизах. Подробности об этом — под катом!

Начиная с Windows Server 2016 был принят новый цикл выхода релизов. Сейчас есть два канала распространения: LTSC (Long-term servicing channel) – релиз, выходящий через 2-3 года, с 5-летней основной и 5-летней расширенной поддержкой, а также Semi-Annual Channel – релизы, которые выходят каждые полгода, имеют основной цикл поддержки в течение 6 месяцев и расширенную поддержку в течение 18 месяцев. Для чего необходимы эти два канала? Microsoft активно внедряет новшества в свою облачную платформу Azure. Это поддержка виртуальных машин Linux, контейнеры с Linux и Windows, и многие другие технологии.

Заказчики, использующие эти технологии в облаке, также хотят их использовать и в своих датацентрах. Semi-Annual Channel сокращает разрыв в возможностях между Azure и локальными датацентрами. Полугодовые релизы предназначены для динамичных в развитии компаний, которые перешли к гибкой сервисной модели предоставления ИТ-услуг бизнесу. Релизы LTSC предназначены для компаний, которые используют устоявшиеся приложения с длительным циклом поддержки, например, Exchange Server, SharePoint Server, SQL Server, а также инфраструктурные роли, программно-определяемые датацентры и гиперконвергентную инфраструктуру.

Windows Server 2019 – это именно релиз в канале LTSC. Он включает в себя все обновления функционала с Windows Server 2016 и последующих полугодовых релизов.

Основные усилия разработчиков Windows Server 2019 были направлены на четыре ключевые области:

Windows Admin Center

Windows Admin Center (WAC) – это новое средство администрирования серверов. Устанавливается локально в инфраструктуре и позволяет администрировать локальные и облачные экземпляры Windows Server, компьютеры Windows 10, кластеры и гиперконвергентную инфраструктуру.

WAC дополняет, а не заменяет существующие средства администрирования, такие как консоли mmc, Server Manager. Подключение к WAC осуществляется из браузера.

Для выполнения задач используются технологии удаленного управления WinRM, WMI и скрипты PowerShell.

Можно опубликовать WAC и администрировать серверы извне периметра организации. Службы многофакторной аутентификации и прокси приложений Azure AD помогут защитить такой доступ извне, а использование решения Microsoft Enterprise Mobility + Security (EMS) позволит предоставлять или отказывать в доступе в зависимости от соответствия устройства политикам, рискам, местоположению и другим факторам. Использование веб-приложения вместо доступа к удаленному рабочему для администрирования, по моему мнению, это правильная стратегия для обеспечения безопасности.

Системная аналитика

Windows Server 2019 стал интеллектуальнее. С помощью новой функции System Insights реализуется прогнозная аналитика, позволяющая перейти от реактивного к проактивному управлению парком серверов. Модель машинного обучения учитывает счетчики производительности и события для точного предсказания проблем со свободным местом на дисковой подсистеме, определение трендов для процессорных вычислений, сетевому взаимодействию и производительности хранилища.

Новинки в подсистеме хранения

Storage Migration Service

В Windows Server 2019 появилась новая технология для миграции данных со старых серверов на новые – Storage Migration Service.

Миграция происходит в несколько этапов:

Azure File Sync

Azure File Sync трансформирует традиционные файловые серверы и расширяет объём хранения до практически недостижимых в реальной жизни объёмов. Данные распределяются по нескольким уровням: горячий кэш – это данные, хранящиеся на дисках файлового сервера и доступные с максимальной скоростью для пользователей. По мере остывания данные незаметно перемещаются в Azure. Azure File Sync можно использовать совместно с любыми протоколами для доступа к файлам: SMB, NFS и FTPS.

Storage Replica

Эта технология защиты от катастроф впервые появилась в Windows Server 2016. В версии 2019 появилась ограниченная поддержка редакции Windows Server Standard. Сейчас и небольшие компании могут делать автоматическую копию (реплику) хранилища в виртуальные машины Azure, если в инфраструктуре компании нет второго удаленного датацентра.

Storage Spaces Direct

Локальные дисковые пространства – это необходимый компонент для построения гиперконвергентной инфраструктуры и масштабируемого файл-сервера. В Windows Server 2019 появилась встроенная поддержка энергонезависимой памяти, улучшенные алгоритмы дедупликации, в том числе на томах с файловой системой ReFS, масштабируемость до 4ПБ на кластер, улучшения в производительности.

Изменения в отказоустойчивой кластеризации

Появились наборы кластеров (Cluster sets), увеличивающие масштабируемость до сотен узлов.
Для обеспечения кворума в кластерах с четным количеством узлов используется специальный ресурс – диск-свидетель. Во времена Windows Server 2012 R2 для диска-свидетеля необходимо было выделять диск на хранилище, в Windows Server 2016 стало возможно использовать сетевую папку или облачный диск-свидетель. Улучшения в Windows Server 2019 связаны с сокращением требований к инфраструктуре для малых предприятий. В качестве диска-свидетеля может выступать USB-диск, подключенный, например, к роутеру.

Появилась миграция кластеров между доменами и другие улучшения в службе отказоустойчивой кластеризации.

Что нового в платформе приложений

Теперь можно запускать контейнеры на основе Windows и Linux на одном и том же узле контейнера с помощью одинаковой управляющей программы Docker. Это позволяет работать в разнородной среде узлов контейнеров и предоставить разработчикам гибкость в создании приложений.

Контейнеры получили улучшенную совместимость приложений, значительно был уменьшен размер образов Server Core и Nano Server, повысилась производительность.

Windows Server 2019 получил множество других улучшений. Подробнее ознакомиться с ними можно в разделе Windows Server на официальном сайте документации docs.microsoft.com.

Системные требования

Документация описывает минимальные требования к установке Windows Server 2019. Надо понимать, что в зависимости от ролей и компонентов, от запущенных приложений, требования к серверу могут быть повышены.

Windows Server 2019 не поддерживает ATA/PATA/IDE и EIDE для загрузки, файла подкачки или дисков с данными. Минимальный объём – 32 ГБ.

Сравнение выпусков Windows Server 2019 Standard и Datacenter

Windows Server 2019 поставляется в двух редакциях: Standard и Datacenter.

Редакция для датацентров обладает расширенными возможностями: поддержка гиперконвергентной инфраструктуры, локальных дисковых пространств, расширенными лицензионными правами при использовании виртуализации.

Приглашение на вебинар

Подробнее с возможностями Windows Server 2019, сценариях использования, вариантах лицензирования можно будет ознакомиться на вебинаре «Windows Server 2019 для современного датацентра».

Спикер — Дмитрий Узлов, сертифицированный эксперт по решениям Майкрософт с многолетним опытом.

Вебинар пройдет 6 декабря в 11.00, после вебинара вы сможете сделать практические работы по развертыванию виртуальной инфраструктуры Windows Server и настройке типовых сценариев гибридного датацентра. Успешно справившиеся с заданиями практической работы получат электронный сертификат о прохождении тренинга.

Запись вебинара можно посмотреть по ссылке.

Источник

question

Because there were too many confusions by some moderators and other people, I read on other different pages with the same given solution to the problem to authenticate through NPS.

On that server for Windows Server 2019, open Command and type the following:

sc sidtype IAS unrestricted

After a success message, restart the server.

I was able to authenticate through my phone, but my laptop didn’t except through VPN on the second server from this one.

>>I was able to authenticate through my phone, but my laptop didn’t except through VPN on the second server from this one.

Could you provide more details about your issue? I am a bit confused about your question. Did you get any authentication error message? Are you trying to authenticate VPN connections to server 2019 NPS server?

Please first check the NPS event log to see if there are something related for us to troubleshooting.

7 Answers

What I meant is that I’m able to login on my cell phone Wi-Fi but the laptop or desktop will not work for wifi enterprise login. Just a message related to NFTN or something.

It is hard for us to analyze the problem if there is no specific event/error about the problem. If your issue is urgent, I would also suggest you contact Microsoft Customer Support and Services where more in-depth investigation can be done so that you would get a more satisfying explanation and solution to this issue.

You may find phone number for your region accordingly from the link below:

Here is the breakdown,

Windows Server 2016 Standard: I was able to connect any devices such as Windows 10 computer to the wifi NPS via user and password on the interface.

Windows Server 2019 Standard: There was a bug resolved however, I cannot connect any Windows 10 desktop or laptops to Wi-Fi NPS via user and password. Other devices like amazon kindle and my cell phone were able to connect.

Please check the event log both on your client and NPS server to see if there are something related for us to troubleshooting.

The cause might be the Inbound traffic to ports UDP/1812 or UDP/1813 is silently dropped by firewall.

On Windows Server 2019 with NPS role installed, open an admin command prompt & run the following command:

1.sc sidtype IAS unrestricted

2.Reboot the server

3.Attempt the connection

If it still doesn’t work, the following may be required:

Then check if the issue was resolved.

If the Answer is helpful, please click «Accept Answer» and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Also Is the port for 1812 and 1813 on server side or client side? Does TLS need to be enabled?

Also as an idea, if someone can compare both server setting, they can find out what’s really going on with Server 2019

Did you mean run the command of sc sidtype IAS unrestricted and restart the NPS server still doesn’t work?

It might be that the default Windows firewall rules to allow inbound UDP port 1812 (RADIUS authentication) and inbound UDP port 1813 (RADIUS accounting) on NPS server do not work.

To do the troubleshooting, you can enable firewall logging on the NPS server to log both allowed and dropped packets. Attempt VPN connection and observe the firewall logs. Then you might see the firewall is dropping packets inbound on UDP port 1812, as the picture below:

Run the command on the NPS server side：

Is yes set for override? The bug fix still did not fix the issue to connect Windows 10 PC to Server 2019 NPS. Non Windows devices are able to connect.
However, the Windows 10 PC will connect to SSTP via VPN to NPS but not L2TP.

What’s the error message when Windows 10 PC cannot connect to L2TP VPN? Please post the detailed error message for us to troubleshooting.
Also check the event log on both client side and NPS server side to see if there are something related.

I have to get back to it but my VPN server for SSTP is down because it says («A connection to the remote computer could not be established. You might need to change the network settings for this connection».) However, it did detect invalid user and or password. Here, there is a bug as well.

On the VPN server side, here is the screenshot:

From your screenshot, VPN and DC are installed on the same machine? We did not recommend install VPN and DC on the same machine.

Let’s sort out the current problem. Based on my understanding, your issue is that WIFI authentication for windows machine not work with NPS server 2019. Is that right? Please feel free to let me know if my understanding is wrong. If yes, please refer to the following steps:

Carefully review the authentication policy on both the client and server to ensure they match.

When you cannot connect to the WIFI network, what’s the error message keep popping?

Please enable firewall logging on the NPS server to log both allowed and dropped packets. Connect to the WIFI network again, and observe the NPS’s firewall logs. Check if NPS server’s firewall is dropping RADIUS authentication packets.

SSTP is back up. I enabled TLS 1.2 before uninstalling and reinstalling RRAS in Server 2019 VPN. But L2TP has a processing error. L2TP and SSTP works on Server 2016 with no bugs. (One running NPS and other running VPN both on Server 2016)

Overall, The bugs are in Server 2019 for NPS (Windows 10 computers cannot connect, even Windows 10 Mobile)

The NPS and VPN will work correctly in Server 2016. There are some defects in Server 2019

I will do that but I would need someone from those departments to contact me so I can reply back to them and be in the live session.

For how to submit a service request to MS Professional tech support service, you can refer to the following link:

Источник

OverviewEdit

FeaturesEdit

ReferencesEdit

External linksEdit

Обновлено 11.05.2017

Если вы вдруг как и я любите писать скрипты, которые вам упрощают жизнь и ускоряют процесс выполнения задач, то вам это будет полезно. Тут собраны все названия ролей и компонентов которые используются при установке через командную строку в windows server 2008R2/2012R2. Особенно это актуально когда вы устанавливаете роли windows server 2012, через Powershell на большом количестве серверов, либо у вас есть удаленный офис в котором нет it специалистов, а поставить нужные серверные службы необходимо, и передав такой вот скрипт, простому менеджеру можно без особых усилий получить нужный результат, просто попросив его там запустить.

Что такое роли Windows

И так сам по себе Windows Server 2012 R2 или предыдущая версия ни кому не нужны, так как при их установке вы получаете просто обычную систему, но благодаря тому, что это конструктор, вы можете его собирать как вам угодно. Собирается он благодаря так называемым ролям Windows, и у каждой из них своя задача, которая превратит ваш сервер в нужный вам сервис.

Что такое компоненты Windows Server 2012 R2, это по сути мини роли, те которые несут не совсем существенные задачи, например сервер TFTP или Net.Framwork 3.5, согласитесь он на роль не тянет.

В операционной системе посмотреть windows server роли можно в окне Диспетчер сервера. В версии 2012 R2, этот значок выглядит вот так, и уже в пункте Управление вы добавляете либо роль, либо компонент.

В windows Server 2008 R2 это выглядит так же, но тут разница в том, что роли и компоненты разнесены по разным вкладкам.

Для того, чтобы посмотреть роли windows server 2012 r2, нажмите добавить роль и увидите полный список. Самих ролей не так уж и много и вы их наверняка еще знаете с 2008 r2.

Windows server роли

Ниже я собрал полный список содержащий роли windows server 2012 r2 и 2008 r2. Тут синтаксис такой слева просто описание названия службы, а справа то что нужно указывать в скрипте при установке.

1. DHCP-сервер [DHCP] > на сайте я приводил кучу вариантов реализации данный серверной роли, так и на различном сетевом оборудовании.

2. DNS-сервер [DNS] > роль необходимая для Active Directory

3. Hyper-V [Hyper-V] > подробнее про данную роль советую почитать соответствующий раздел. Если в двух словах то это гипервизор, для создания виртуальных машин.

4. Веб-сервер IIS [Web-Server] > роль windows server 2012 r2 для превращения его в хостинг сайтов.

Компоненты IIS

• Веб-сервер [Web-WebServer]
• Основные возможности HTTP [Web-Common-Http]
• Статическое содержимое [Web-Static-Content]
• Стандартный документ [Web-Default-Doc]
• Обзор каталогов [Web-Dir-Browsing]
• Ошибки HTTP [Web-Http-Errors]
• Перенаправление HTTP [Web-Http-Redirect]
• Веб-публикация DAV [Web-DAV-Publishing]
• Разработка приложений [Web-App-Dev]
• ASP.NET [Web-Asp-Net]
• Расширяемость .NET [Web-Net-Ext]
• ASP [Web-ASP]
• CGI [Web-CGI]
• Расширения ISAPI [Web-ISAPI-Ext]
• Фильтры ISAPI [Web-ISAPI-Filter]
• Включения на стороне сервера (SSI) [Web-Includes]
• Работоспособность и диагностика [Web-Health]
• Ведение журнала HTTP [Web-Http-Logging]
• Средства ведения журналов [Web-Log-Libraries]
• Монитор запросов [Web-Request-Monitor]
• Слежение [Web-Http-Tracing]
• Особое ведение журнала [Web-Custom-Logging]
• Ведение журнала ODBC [Web-ODBC-Logging]
• Безопасность [Web-Security]
• Обычная проверка подлинности [Web-Basic-Auth]
• Windows — проверка подлинности [Web-Windows-Auth]
• Дайджест-проверка подлинности [Web-Digest-Auth]
• Проверка подлинности с сопоставлением сертификата клиента [Web-Client-Auth]
• Проверка подлинности с сопоставлением сертификата клиента IIS [Web-Cert-Auth]
• Авторизация URL-адресов [Web-Url-Auth]
• Фильтрация запросов [Web-Filtering]
• Ограничения по IP-адресам и доменам [Web-IP-Security]
• Производительность [Web-Performance]
• Сжатие статического содержимого [Web-Stat-Compression]
• Сжатие динамического содержимого [Web-Dyn-Compression]
• Средства управления [Web-Mgmt-Tools]
• Консоль управления IIS [Web-Mgmt-Console]
• Сценарии и средства управления IIS [Web-Scripting-Tools]
• Служба управления [Web-Mgmt-Service]
• Совместимость управления IIS 6 [Web-Mgmt-Compat]
• Совместимость метабазы IIS 6 [Web-Metabase]
• Совместимость WMI в IIS 6 [Web-WMI]
• Службы сценариев IIS 6 [Web-Lgcy-Scripting]
• Консоль управления IIS 6 [Web-Lgcy-Mgmt-Console]
• FTP-сервер [Web-Ftp-Server]
• Служба FTP [Web-Ftp-Service]
• Расширяемость FTP [Web-Ftp-Ext]
• Ведущий базовый экземпляр IIS [Web-WHC]
• Доменные службы Active Directory [AD-Domain-Services]
• Контроллеры домена Active Directory [ADDS-Domain-Controller]
• Диспетчер удостоверений для UNIX [ADDS-Identity-Mgmt]
• Сервер для служб NIS [ADDS-NIS]
• Синхронизация паролей [ADDS-Password-Sync]
• Средства администрирования [ADDS-IDMU-Tools]
• Сервер приложений [Application-Server]
• Платформа .NET Framework 3.5.1 [AS-NET-Framework]
• Поддержка веб-сервера (IIS) [AS-Web-Support]
• Доступ к сети COM+ [AS-Ent-Services]
• Общий доступ к TCP-портам [AS-TCP-Port-Sharing]
• Поддержка службы активации процессов Windows [AS-WAS-Support]
• Активация по HTTP [AS-HTTP-Activation]
• Активация через очередь сообщений [AS-MSMQ-Activation]
• Активация по TCP [AS-TCP-Activation]
• Активация по именованным каналам [AS-Named-Pipes]
• Распределенные транзакции [AS-Dist-Transaction]
• Входящие удаленные транзакции [AS-Incoming-Trans]
• Исходящие удаленные транзакции [AS-Outgoing-Trans]
• Транзакции WS-AT [AS-WS-Atomic]
• Веб-сервер IIS [Web-Server] > роль windows server 2012 r2 для превращения его в хостинг сайтов.

5. Службы Active Directory облегченного доступа к каталогам [ADLDS]

6. Службы Windows Server Update Services [OOB-WSUS]

7. Службы печати и документов [Print-Services]

Компоненты служб печати

• Сервер печати [Print-Server]
• Служба LPD [Print-LPD-Service]
• Печать через Интернет [Print-Internet]
• Сервер распределенного сканирования [Print-Scan-Server]

8. Службы политики сети и доступа [NPAS] > данные роли windows server 2012 r2, превратят ваш сервер в маршрутизатор или VPN сервер.

Компоненты NPAS

• Сервер политики сети [NPAS-Policy-Server]
• Службы маршрутизации и удаленного доступа [NPAS-RRAS-Services]
• Служба удаленного доступа [NPAS-RRAS]
• Маршрутизация [NPAS-Routing]
• Центр регистрации работоспособности [NPAS-Health]
• Протокол авторизации учетных данных узла [NPAS-Host-Cred]

9. Службы развертывания Windows [WDS] > Автоматизированная установка операционных систем по сети, за счет протокола PXE.

Компоненты WDS

• Сервер развертывания [WDS-Deployment]
• Транспортный сервер [WDS-Transport]

10. Службы сертификации Active Directory [AD-Certificate]

Компоненты Службы сертификации Active Directory

• Центр сертификации [ADCS-Cert-Authority]
• Служба регистрации в центре сертификации через Интернет [ADCS-Web-Enrol
  lment]
• Сетевой ответчик [ADCS-Online-Cert]
• Служба регистрации на сетевых устройствах [ADCS-Device-Enrollment]
• Веб-служба регистрации сертификатов [ADCS-Enroll-Web-Svc]
• Веб-служба политик регистрации сертификатов [ADCS-Enroll-Web-Pol]

12. Службы удаленных рабочих столов [Remote-Desktop-Services] > очень часто эта роль windows server 2012 r2 используется в компаниях.

Компоненты RDS

• Узел сеансов удаленных рабочих столов [RDS-RD-Server]
• Узел виртуализации удаленных рабочих столов [RDS-Virtualization]
• Службы Core Services [RDS-Virtualization-Core]
• RemoteFX [RDS-RemoteFX]
• Лицензирование удаленных рабочих столов [RDS-Licensing]
• Посредник подключений к удаленному рабочему столу [RDS-Connection-Broke
  r]
• Шлюз удаленных рабочих столов [RDS-Gateway]
• Веб-доступ к удаленным рабочим столам [RDS-Web-Access]

13. Службы управления правами Active Directory [ADRMS]

Компоненты ADRMS

• Сервер управления правами Active Directory [ADRMS-Server]
• Поддержка удостоверений в службе федерации [ADRMS-Identity]

14. Службы федерации Active Directory [AD-Federation-Services]

Компоненты ADFS

• Служба федерации [ADFS-Federation]
• Прокси-сервер службы федерации [ADFS-Proxy]
• Веб-агенты AD FS [ADFS-Web-Agents]
• Агент, поддерживающий утверждения [ADFS-Claims]
• Агент Windows на основе токенов [ADFS-Windows-Token]

15. Файловые службы [File-Services]

Компоненты файловых служб

• Файловый сервер [FS-FileServer]
• Распределенная файловая система [FS-DFS]
• Пространства имен DFS [FS-DFS-Namespace]
• Репликация DFS [FS-DFS-Replication]
• Диспетчер ресурсов файлового сервера [FS-Resource-Manager]
• Службы для NFS [FS-NFS-Services]
• Служба Windows Search [FS-Search-Service]
• Файловые службы Windows Server 2003 [FS-Win2003-Services]
• Служба индексирования [FS-Indexing-Service]
• Служба BranchCache для сетевых файлов [FS-BranchCache]
• Факс-сервер [Fax]

Компоненты windows server 2012 R2

Так роли windows server 2008 r2 и 2012 r2 мы рассмотрели, давайте узнаем какие компоненты windows server 2012 R2 имеет под капотом.

• BranchCache [BranchCache]
• Quality Windows Audio Video Experience [qWave]
• RPC через HTTP-прокси [RPC-over-HTTP-Proxy]
• Telnet-сервер [Telnet-Server]
• Windows TIFF IFilter [TIFF-IFilter]
• WINS-сервер [WINS-Server]
• Балансировка сетевой нагрузки [NLB]
• Биометрическая платформа Windows [Biometric-Framework]
• Внутренняя база данных Windows [Windows-Internal-DB]
• Возможности .NET Framework 3.5.1 [NET-Framework]
• .NET Framework 3.5.1 [NET-Framework-Core]
• Активация WCF [NET-Win-CFAC]
• Активация через HTTP [NET-HTTP-Activation]
• Не-HTTP активация [NET-Non-HTTP-Activ]
• Возможности рабочего стола [Desktop-Experience]
• Возможности системы архивации данных Windows Server [Backup-Features]
• Система архивации данных Windows Server [Backup]
• Программы командной строки [Backup-Tools]
• Диспетчер системных ресурсов [WSRM]
• Диспетчер хранилища для сетей SAN [Storage-Mgr-SANS]
• Интегрированная среда сценариев (ISE) Windows PowerShell [PowerShell-ISE]
• Клиент Telnet [Telnet-Client]
• Клиент TFTP [TFTP-Client]
• Клиент интернет-печати [Internet-Print-Client]
• Консоль управления DirectAccess [DAMC]
• Многопутевой ввод-вывод [Multipath-IO]
• Монитор LPR-портов [LPR-Port-Monitor]
• Очередь сообщений [MSMQ]
• Службы очереди сообщений [MSMQ-Services]
• Сервер очереди сообщений [MSMQ-Server]
• Интеграция служб каталогов [MSMQ-Directory]
• Триггеры очереди сообщений [MSMQ-Triggers]
• Поддержка HTTP [MSMQ-HTTP-Support]
• Поддержка многоадресной рассылки [MSMQ-Multicasting]
• Служба маршрутизации [MSMQ-Routing]
• DCOM-прокси очереди сообщений [MSMQ-DCOM]
• Пакет администрирования диспетчера подключений [CMAK]
• Подсистема для UNIX-приложений [Subsystem-UNIX-Apps]
• Простые службы TCP/IP [Simple-TCPIP]
• Протокол PNRP [PNRP]
• Расширение WinRM IIS [WinRM-IIS-Ext]
• Сервер SMTP [SMTP-Server]
• Сервер службы имен хранилищ Интернета [ISNS]
• Служба активации процессов Windows [WAS]
• Модель процесса [WAS-Process-Model]
• Среда .NET [WAS-NET-Environment]
• API-интерфейсы конфигурации [WAS-Config-APIs]
• Служба беспроводной локальной сети [Wireless-Networking]
• Службы SNMP [SNMP-Services]
• Служба SNMP [SNMP-Service]
• WMI-поставщик SNMP [SNMP-WMI-Provider]
• Службы рукописного ввода [Ink-Handwriting]
• Поддержка рукописного ввода [IH-Ink-Support]
• Распознавание рукописного ввода [IH-Handwriting]
• Средства миграции Windows Server [Migration]
• Средства удаленного администрирования сервера [RSAT]
• Средства администрирования ролей [RSAT-Role-Tools]
• Средства служб сертификации Active Directory [RSAT-ADCS]
• Средства центра сертификации [RSAT-ADCS-Mgmt]
• Средства сетевого ответчика [RSAT-Online-Responder]
• Средства AD DS и AD LDS [RSAT-AD-Tools]
• Инструменты AD DS [RSAT-ADDS]
• Оснастки AD DS и средства командной строки [RSAT-ADDS-Tools]
• Административный центр Active Directory [RSAT-AD-AdminCenter]
•  Средства сервера для NIS [RSAT-SNIS]
• Оснастки AD LDS и средства командной строки [RSAT-ADLDS]
• Модуль Active Directory для Windows PowerShell [RSAT-AD-PowerShell]
• Средства службы управления правами Active Directory [RSAT-RMS]
• Средства DHCP-сервера [RSAT-DHCP]
• Средства DNS-сервера [RSAT-DNS-Server]
• Средства факс-сервера [RSAT-Fax]
• Средства файловых служб [RSAT-File-Services]
• Средства распределенной файловой системы (DFS) [RSAT-DFS-Mgmt-Con]
• Средства диспетчера ресурсов файлового сервера [RSAT-FSRM-Mgmt]
•  Средства служб для NFS [RSAT-NFS-Admin]
• Средства Hyper-V [RSAT-Hyper-V]
• Средства служб политики сети и доступа [RSAT-NPAS]
• Средства служб печати и документов [RSAT-Print-Services]
• Средства служб удаленных рабочих столов [RSAT-RDS]
• Средства узла сеансов удаленных рабочих столов [RSAT-RDS-RemoteApp]
• Средства шлюза удаленных рабочих столов [RSAT-RDS-Gateway]
• Средства лицензирования удаленных рабочих столов [RSAT-RDS-Licensing]
• Средства посредника подключений к удаленному рабочему столу [RSAT-RDS-Conn-Broker]
• Средства веб-сервера (IIS) [RSAT-Web-Server]
• Средства служб развертывания Windows [RSAT-WDS]
• Средства администрирования возможностей [RSAT-Feature-Tools]
• Средства администрирования программы шифрования дисков BitLocker [RSAT-BitLocker]
• Средства шифрования диска BitLocker [RSAT-Bitlocker-DriveEnc]
• Средство просмотра пароля BitLocker [RSAT-Bitlocker-RecPwd]
• Средства серверных расширений BITS [RSAT-Bits-Server]
• Средства отказоустойчивости кластеров [RSAT-Clustering]
• Средства балансировки сетевой нагрузки [RSAT-NLB]
• Средства SMTP-сервера [RSAT-SMTP]
• Средства WINS-сервера [RSAT-WINS]
• Средство отказоустойчивости кластеров [Failover-Clustering]
• Средство просмотра XPS [XPS-Viewer]
• Удаленное разностное сжатие [RDC]
• Удаленный помощник [Remote-Assistance]
• Управление групповой политикой [GPMC]
• Фоновая интеллектуальная служба передачи (BITS) [BITS]
• Облегченный сервер загрузки [BITS-Compact-Server]
• Расширение сервера IIS [BITS-IIS-Ext]
• Шифрование диска BitLocker [BitLocker]

Как посмотреть в командной строке windows server роли

Для того, чтобы посмотреть windows server роли в 2008 R2, есть два метода это утилита командной строки servermanagercmd. Вводим вот такую команду для получения списка ролей и компонентов.

В итоге получите вот такой вывод команды

Второй метод, просмотреть роли windows server 2008 r2 это конечно же powershell, вводим вот такую команду:

В итоге вы получаете список всех доступных ролей и компонентов Windows Server

Для 2012 r2 и 2016 версии Windows server роли ставятся, только через Powershell, если мы имеем ввиду GUI интерфейс. Уверен, что кому то данная статья поможет.