Добавяте скрипт client-connect, който отхвърля всяка връзка, в която common_name се различава от username, и това изглежда като обвързване между сертификат и акаунт. На сървър с включен username-as-common-name това сравнение вече е загубило смисъла си до момента, в който скриптът се изпълни. И двете стойности са един и същ низ, така че проверката минава за сертификат, издаден на съвсем друг човек.

Проверката не е грешна, защото скриптът е лошо написан. Тя е грешна, защото стойността, която той чете, е била заменена по-рано в същата връзка.

Какво сякаш доказва сравнението

Удостоверяването със сертификат и удостоверяването с парола са отделни доказателства и сървърът може да изисква и двете, без да изисква те да принадлежат на един и същ човек. Разликата е реална: валиден сертификат на устройство плюс всеки валиден акаунт е различно твърдение от същия сертификат плюс един конкретен акаунт. Скрипт, който сравнява common_name с username, изглежда като липсващото звено между двете. Би било така, ако common_name все още означаваше това, което казва сертификатът.

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

Какво прави username-as-common-name с името

Когато username-as-common-name е включена, OpenVPN замества общото име на сертификата с удостовереното потребителско име, след като потребителското име и паролата бъдат проверени. Куката за проверка, която се изпълнява по време на тази проверка, все още получава общото име от сертификата, защото замяната още не е настъпила. Всичко след това, включително client-connect, вижда потребителското име. Така по-късното извикване получава една самоличност два пъти и не може да я сравни със сертификата, който е бил представен.

StageWhat common_name holds
Username and password verification hookThe certificate common name, for example bob-device
After the replacementThe authenticated account, alice
client-connect callbackThe account again, alice

Проследете една примерна връзка: сертификат, издаден за bob-device, успешен вход в директорията като alice и включена опция. Етапът на проверка все още може да види два различни низа. Етапът на свързване вижда alice и alice.

Този пример показва защо сравнението е празно. Той не показва, че връзката иначе би била приета, защото проверката на сертификата и проверката на паролата все още работят самостоятелно.

Поставете обвързването там, където и двете самоличности още съществуват

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

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

Не забравяйте, че опцията променя и коя конфигурация за отделния клиент се прилага, защото client-config-dir се индексира по общото име.

Тествайте сдвояването с две валидни удостоверения

Започнете с двойката, която вашата политика позволява, и потвърдете, че се свързва. След това представете същия валиден сертификат с различен, но иначе валиден акаунт: този опит трябва да се провали и трябва да се провали заради правилото за сдвояване, а не заради сгрешена парола. Грешната парола доказва, че проверката на паролата работи, и не казва нищо за правилото за връзка между сертификат и акаунт.

Проверете също пътищата за липсващ и невалиден сертификат и потвърдете коя самоличност използва сървърът за настройките на отделния клиент. Ако единственият начин да накарате сравнението да работи е да изключите username-as-common-name, първо преценете цената на тази промяна, защото тя връща търсенето на конфигурация за всеки клиент обратно към името от сертификата.

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