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 политика наведу исти метод, дозвољени корисник се повеже у новој сесији, погрешна лозинка буде одбијена, искључени корисник остане искључен и додељена адреса одговара предвиђеном базену. Све мање од тога оставља следећу пријаву случају.

Повезани чланци