Първо методът EAP: кой хеш на парола може да използва една VPN
VPN проверява тайната, а не уеб хеша. Прочетете метода, после проверете какво съхранява хранилището, преди да обещаете, че същите пароли ще продължат да работят.
Много екипи имат уеб вход, който работи, и VPN, който отказва всяка парола от същата таблица. Уеб приложението сравнява хеш, който само е изчислило, докато тунелът иска от клиента да докаже притежание на тайна по начин, който сървърът трябва да може да провери. Това са различни изисквания към съхранения материал. Именно в пропастта между тях повечето такива проекти засядат.
Прочетете метода, после схемата
Запишете какво доказателство изисква избраният метод, преди да погледнете каквато и да е схема. Методът предизвикателство-отговор се нуждае от материал, от който сървърът може да изчисли очаквания отговор, което на практика означава паролата или съвместима производна форма. Метод, който носи паролата в защитен тунел, се нуждае от самата парола при проверяващия. Четете документацията на метода за изискването към проверяващия, а не за конфигурацията на клиента, защото изискванията към клиента обикновено са лесната част.
Посоленият хеш, който произвежда една съвременна уеб рамка, не дава нито едното. Той проверява едно конкретно сравнение и не може да бъде върнат обратно към тайната, от която е произлязъл.
Предизвикателство-отговор не може да използва посолен хеш
MSCHAPv2 е обмен предизвикателство-отговор, затова сървърът никога не получава паролата и не може да сравни съхранен низ. Той трябва да извлече очаквания отговор от материал, който вече притежава, и затова съвместимите съхранени форми са толкова тесни. Стойност на bcrypt или Argon2 с отделна сол за всеки потребител е еднопосочна по начин, който напълно изключва обмена. Таблицата по-долу започва от формата на съхранение, а не от името на метода, защото именно формата на съхранение решава отговора.
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
Документацията на SQL плъгина за strongSwan дефинира собствена схема за конфигурация и идентификационни данни, а проектът все още отбелязва този плъгин като експериментален. Нищо в нея не се приспособява към таблицата с потребители на приложение и не отгатва коя схема за хеширане е създала съхранена стойност. Реалистичните варианти са следователно миграция към хранилище, което шлюзът може да използва, или услуга за удостоверяване пред съществуващото хранилище, която може да извърши обмена. Всичко друго е конектор със скрито допускане вътре в него.
RADIUS мести работата, не изискването
Делегирането на EAP на RADIUS сървър променя къде се извършва проверката и обикновено подобрява одитната следа. То не възстановява парола от еднопосочен хеш, затова услугата за удостоверяване все още се нуждае от материал, съвместим с метода, който прекратява. Екипите разбират това, след като построят пътя през RADIUS и срещнат същата стена от другата страна.
Там, където RADIUS сървърът може да чете директория със съвместими идентификационни данни, дизайнът работи и VPN шлюзът остава прост. Там, където не може, честният отговор е промяна в регистрацията, а не още един конектор. Предоставянето и отнемането принадлежат на този, който притежава идентичността, затова копирана таблица без поддържан процес за синхронизация е втори жизнен цикъл на идентификационни данни, а не еднократно влизане. Тя се разминава първия път, когато някой смени парола само на едно място, и разминаването е безшумно, докато акаунт, който съществува в двете системи, не започне да се държи различно във всяка.
Ограничете акаунта, който чете директорията, само до това четене и го дръжте отделно от акаунта, който шлюзът използва за собствената си конфигурация. Споделен административен акаунт превръща дизайн само за четене в много по-широк радиус на поражение.
Къде да живее акаунтът
След като въпросът с материала е решен, остават две архитектури. Шлюзът може да притежава малко хранилище за идентификационни данни, което чете само той, или да делегира на услуга за удостоверяване, която стои пред корпоративната директория.
Първата е по-лесна за обмисляне и по-лоша за потребителя, който се сдобива с втора парола за поддръжка. Втората пази една идентичност и добавя зависимост от услуга, която вече трябва да работи, преди някой да се свърже. Нито една не е грешна, но изборът трябва да се запише до конфигурацията на шлюза, защото иначе следващият инженер ще предположи, че е избрана другата. Каквото и да изберете, двете команди по-долу са тези, които показват текущото състояние, преди да го промените.
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsУдостоверяването на акаунта също не решава оторизацията. Членството в групи, състоянието на устройството и мрежовото разрешение все още се нуждаят от явно съпоставяне, след като потребителят е доказал изискваната идентичност. Връзка, която се удостоверява безупречно и не оторизира нищо, е резултат от политика, а не дефект в метода.