RouterOS OpenVPN и NPS: задайте user-auth-method, а не auth

В RouterOS auth избира дайджеста на тунела, а user-auth-method решава как се проверява RADIUS заявката. Съгласувайте второто с политиката на NPS.

RouterOS може да достигне NPS с OpenVPN вход и въпреки това да бъде отхвърлен, а обичайната причина са две настройки, чиито имена звучат като удостоверяване. Едната избира криптографски дайджест за тунела; другата решава как идентификационните данни на потребителя се представят на RADIUS. Промяната на дайджеста никога няма да превърне PAP заявка в MS-CHAPv2, колкото и често услугата да се рестартира. Списъкът по-долу разделя двете и след това проследява един неуспешен вход през политиката на NPS, която го е оценила.

Стъпка 1: прочетете двете настройки, преди да промените която и да е

Отпечатайте ефективната конфигурация на OpenVPN сървъра на рутера, който терминира тунела, не от резервно копие или копиран форумен пост. Двете полета, които ви интересуват, обикновено са в едно и също меню и се четат като алтернативи. Не са: едното е за канала с данни, другото за обмена на идентификационни данни.

/interface ovpn-server server print
/interface ovpn-server server export

Полето auth изброява дайджести като sha1 и sha256 и управлява HMAC, който удостоверява пакетите на тунела. Полето user-auth-method избира pap или mschap2 и решава как рутерът представя идентификационните данни на потребителя на RADIUS. Промяна на дайджеста не може да промени второто поведение и затова същото отхвърляне оцелява при всяка корекция на първото.

Спрете тук, ако вашата версия изобщо не предоставя user-auth-method. По-стари сборки на RouterOS може да не го предлагат на OpenVPN сървъра и поправката принадлежи във версия, която можете да поддържате, а не в команда, копирана от по-нова.

Стъпка 2: намерете политиката, която действително е отхвърлила входа

От страната на NPS заявката за връзка се оценява спрямо мрежови политики и методът за удостоверяване, посочен в съответстващата политика, трябва да е един от действително предложените от клиента. Свържете един неуспешен вход по време и потребител, вместо да четете обобщен брой. Журналът за сигурност записва разрешените и отказаните заявки с код на причината, което ви казва много повече от общия ред за грешка на рутера.

Get-WinEvent -LogName Security -MaxEvents 200 |
  Where-Object { $_.Id -in 6272,6273 } |
  Format-List TimeCreated,Id,Message

Прочетете три неща в събитието: името на съответстващата политика, метода за удостоверяване и кода на причината. Политика, която изисква MS-CHAPv2, отхвърля PAP заявка дори когато паролата е правилна, а политика, която изисква домейн акаунт, отхвърля локален. Записът на RADIUS клиента също трябва да съвпада с изходния адрес на рутера, иначе заявката се изхвърля преди да бъде проверена която и да е политика. Нищо от това не се появява в журнала на OpenVPN.

Спрете тук, ако заявката никога не достига до NPS. Това е проблем със споделената тайна, адреса на клиента или UDP 1812 и промяната на методите за удостоверяване няма да го поправи.

Стъпка 3: сменете един метод, от двете страни

Ако одобреният дизайн е MS-CHAPv2, задайте го на рутера и потвърдете, че съответстващата политика го приема. Сменете едната страна, тествайте отново, после сменете другата; промяната на двете наведнъж ви оставя без възможност да кажете кое е имало значение.

/interface ovpn-server server set user-auth-method=mschap2
/interface ovpn-server server print
/log print where topics~"radius"

Не включвайте всеки по-слаб метод на NPS, за да изчезне грешката. Бекендът трябва да държи материал, който избраният метод може да провери: MS-CHAPv2 се нуждае от достъп до паролата или домейна, а политиката не може да измисли този материал. Разширяването на политиката разширява и това, което атакуващ може да опита срещу същия акаунт. Запишете метода, името на политиката и референцията на промяната заедно, за да наследи следващият човек решение, а не догадка.

Оставете проверката на сертификата на тунела точно каквато беше. Методът за идентификационни данни не замества идентичността на сървъра и намаляването на TLS проверките, за да мине тест, разменя един проблем за по-лош.

Стъпка 4: тествайте три входа и едно разрешение

Тествайте разрешен потребител, грешна парола и изключен потребител, всеки в нова сесия. Първият доказва пътя, вторият доказва, че проверката на идентификационните данни е истинска, а третият доказва, че политиката все още изключва когото трябва. Кеширана сесия може да скрие и трите, затова се разкачайте между опитите.

/log print where topics~"ovpn"
/radius monitor 0

Успешното удостоверяване не е краят на списъка. Проверете адреса, който клиентът е получил, и ресурсите, които този адрес може да достигне, защото потребителят може да се удостовери правилно и пак да попадне в грешен пул. Ако зададеният адрес е грешен, проблемът е в профила или в атрибутите на RADIUS отговора, не в метода. Потвърдете и двете, преди да затворите заявката.

Списъкът е готов, когато настройката на рутера и политиката на NPS посочват един и същ метод, един разрешен потребител се свързва с нова сесия, една грешна парола се отхвърля, един изключен потребител остава изключен и зададеният адрес съвпада с предвидения пул. Всичко по-малко оставя следващия вход на случайността.

Подобни статии