Обстановката е избрания метод.

RADIUSPicking упълномощаване-TypeAuthenticating

Ето свободното си превод на тази статия, за достоверността не мога да отговоря.

И за всеки случай, аз синхронизиране на условията:

Клиентът в този контекст (по отношение на RADIUS -server) - тази точка за достъп.

Потребител (молител) - някой, който иска да получи достъп до мрежата, използвайки точка за достъп.

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

Нито вие, нито радиус не знае и не се реши на клиента ви изпрати в искането. Отговорността за това, което се съдържа в искането е 100% при клиента.

Radius сървър разглежда искането и казва:

Отговорът на този въпрос зависи от това, какъв тип удостоверяване ви даде възможност на сървъра може да търсите в базата данни, и това, което се съдържа в искането.

В един момент, един от модулите ще каже:

Ако модулът мисли, че има шанс да се разпознае потребителя и все пак, той ще каже:

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

Да предположим, че клиентът е изпратил искане до атрибут от потребителя парола и тате модул е ​​включен в лицензират, в раздела <>. Тогава тате модул ще определи упълномощаване-Type = ПАП.

По този начин, сървърът отново се хареса на модула за попара, но на етапа на идентификация (тя също има своя собствена секция в удостоверяване на конфигурационния <> ), Пап отговор:

Тогава там е сравнение на местната добре известен предварително правилната парола, с тези, въведени от потребителя (присъединили се към молбата). Ето как работи удостоверяване.

"Правилно" парола (по-рано известен правилната парола) е добавен към друг модул. Например, тате модул просто изпълнява PAP удостоверяване и нищо повече. Предимствата на този подход е, че "правилното" паролата може да се добави на искане от страна на потребители на текстов файл. SQL. LDAP. / И т.н. / ако съществува. външни програми и т.н. и т.н. в много широк диапазон.

Например, ако модул LDAP свързан разреши раздел <>. и сървъра обработва заявката, ако модулът намира в профила си с парола (някъде в директорията LDAP), тя ще добави паролата в искането на друг модул на етапа на идентификация може да го използва.

Какво става, ако клиентът изпраща заявка MSCHAP? Какво ще направи радиус сървър за тази заявка?

Но сървъра е изчерпала възможностите, единствената му опция е MSCHAP, защото това е, което клиентът е изпратила искането. MSCHAP модул не може да направи нищо, защото той не е била дадена "правилната" паролата. Ето защо, на сървъра за липсата на възможности за искането е отхвърлено. данни MSCHAP биха могли да бъдат верни, но нямаше начин сървъра, за да се провери това. Така че той е отказал.

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

раздел Методи удостоверяване конфигурирана за удостоверяване <>. Тук е получено искането в модул, който е настроен на упълномощаване-Type атрибут. Въз основа на данните, включени в искането от устройството за съхранение, дори предишната стъпка сравнява атрибут дойде от клиента към атрибутите на съхранение. Въз основа на това сравнение, че е взела решение да разреши или откаже достъп или за изясняване на параметрите на клиента.

Това е концепцията на сървъра радиус в този случай опростен, за да позор.

Съществуващите безжичен рутер TP-Link TL-WR842ND с фабричен фърмуер ние имаме възможност да се използват следните видове защита: WPA2-PSK, WPA2-Enterprise. Други възможности не са били разглеждани поради тяхната ненужност: отворена мрежа, не отговаря на тази цел; WEP - отдавна е компрометирана; WPA-PSK / Enterprise - имат една и съща WPA2 век по-строг подход към криптиране.

WPA2-Enterprise поддържа няколко различни методи за удостоверяване EAP. Window значение за EAP-TLS и EAP-PEAPv0. EAP-TLS - ще облекчи потребителите от въвеждането на потребителско име и парола, но има и друг проблем ще възникне по отношение на разполагането на инфраструктура с публичен ключ и разпространение на сертификати. И изправени пред проблема да инсталирате сертификати на мобилни устройства. Въпреки, че този метод е най-надеждни, но поради сложността на внедряване и поддръжка за нашите нужди, той изчезва.

EAP-PEAPv0 с MS-CHAPv2 - изисква потребителят да се доверите на точка за достъп / сървър и знанията на акорди име / парола. Достоверността на точката за достъп / сървър постигната оценка на сървъра сертификат за съответствие, или деактивиране на тази проверка. Методът се състои в създаване на защитен тунел, в който идентификация на потребителя MS-CHAPv2 метод. Лесно внедряване и поддръжка, особено ако сте сляпо доверие на точка за достъп / сървър. Но тя страда от безопасността на "активните" натрапниците.

Трябва да се отбележи, че горните конфигурацията команди и фрагменти бяха тествани за Debian 7.5 в FreeRADIUS 2.1.12 + dfsg-1.2

2.1 Създаване на производствени сертификати

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

Инструменти за създаване на необходимите сертификати от Debian freeradius лъжа по пътя на / ЮЕсАр / акции / DOC / freeradius / примери / от сертифициращ. Съдържанието на тази директория трябва да се копират в / и т.н. / freeradius / от сертифициращ. Необходими файлове:

И вие можете също да копирате README, който е боядисан като това, което трябва и как да го използвате, толкова по отида необходимите команди с кратки обяснения, в продължение на повече infoy в README.

За работещи скриптове нужда OpenSSL и да направи.

Създайте файл с параметрите на Diffie-Hellman, ако той изведнъж не съществува в директорията / и т.н. / freeradius / CERT,:

Резултатът от: DH файл

Създаване на основен сертификат или сертификат сертифициращия център. Ако вече е имал някои сертификати (обикновено изпитване), а след това да го премахнете:

Редактиране от само себе си ca.cnf файл. Обърнете внимание на default_md = md5 (по-добре да се сложи sha1), default_days = 365 (може да не искат да се генерира нов сертификат за една година, тогава е по-добре да се сложи малко повече), input_password / output_password и искате да редактирате под него целия раздел [CERTIFICATE_AUTHORITY].

Резултатите: ca.pem. ca.key и ca.der - център сертификат за сертифицирането, неговия личен ключ и сертификат по разбираем формат за Windows, съответно.

Създаване на сертификат за сървър. Редактиране от само себе си server.cnf файл. Обърнете внимание на default_md = md5 (по-добре да се сложи sha1), default_days = 365 (може да не искат да се генерира нов сертификат за една година, тогава е по-добре да се сложи малко повече), input_password / output_password и искате да редактирате под него целия раздел [сървъра]. Важно е да ценим COMMONNAME се различават от съответните сертификат сертифициращия център.

Резултат: наред с други файлове server.pem и server.key - сертификата и частния ключ на сървъра.

В конфигурацията на пътя към сертификатите, генерирани в папка / и т.н. / freeradius / от сертифициращ са регистрирани по подразбиране.

2.2 Ние описват RADIUS-клиенти (точка за достъп)

/etc/freeradius/clietns.conf добавите във файл, както следва:

2.3 Настройка на пълномощията за заверка от потребителско име и парола

В файл / и т.н. / freeradius / потребителите да добавят първия ред, както следва:

За да поискате потребителско име парола потребителят ще бъде проверена и сравнение атрибут Calling-гара-Id. За да стане това, в случай на EAP-PEAP трябва да бъде /etc/freeradius/eap.conf файл зададете sopy_request_to_tunnel = да в секцията по-долу:

Достатъчно в потребителите подават в самото му начало, за да добавите желаните потребителите от параметъра Calling-гара-Id. ако имате нужда от същите идентификационни данни, можете просто да се повтаря, като например:

Трябва да се отбележи, че атрибутът Calling-гара-, указан в основния потребител подаде за конкретно име / парола и ще действа, но проверката ще се извършва на сцената, който се провежда по-късно. Така че, ако ще бъдете подканени със стойност Calling-гара-Id. Неизвестна да authorized_macs файл, искането се отхвърля незабавно, независимо от това, което е посочено в досието на потребителите.

Когато промените конфигурационните файлове, включително файлове и потребителите се нуждаят authorized_macs принудени да препрочитам SIGHUP конфигурационния сигнал.

С промени в конфигурационния radiusd.conf по-добре, за да рестартирате демона:

За да проверите конфигурацията, трябва да работи с демон в режим на отстраняване на грешки:

С това нововъведение може да видите как freeradius разбор на довереник и да видят как се справя с искания. Много полезна при намирането на различни проблеми и при разясняването неочаквано поведение.

Той идва с полезна програма radtest - просто RADIUS-клиент. Тъй като е възможно да се извърши на няколко прости тестове за проверка на конфигурацията. Един възможен пример за използване (тестване vnutritunnelnoy удостоверяване на пристанището 18 120):

За да се покаже в дневника на опитите за удостоверяване на информацията трябва да включва следните параметри в radiusd.conf.