Efectuați setarea metodei selectate.
RADIUSPrivind autentificarea de tip Auth
Aici este traducerea gratuită a acestui articol, nu pot garanta fiabilitatea.
Și în caz, eu sincronizează termenii:
Clientul în acest context (din punctul de vedere al serverului RADIUS) este un punct de acces.
Utilizatorul (supplicant) este cel care dorește să acceseze rețeaua utilizând un punct de acces.
Cele mai multe probleme de configurare se datorează lipsei de înțelegere a conceptului FreeRADIUS. Editarea fișierelor de configurare și sortarea opțiunilor posibile nu vor ajuta la înțelegerea conceptului.
Nici dvs., nici raza nu știți și decide ce va trimite clientul în cerere. Responsabilitatea pentru conținutul solicitării este 100% pentru client.
Serverul de rază analizează interogarea și spune:
Răspunsul la această întrebare depinde de tipurile de autentificare pe care le-ați inclus, de ce poate găsi serverul în baza de date și de conținutul interogării.
La un moment dat, unul dintre module va spune:
Dacă modulul crede că are șansa de a autentifica utilizatorul, el va spune:
Dacă modulul nu recunoaște nimic sau știe că nu este nevoie să căutați ceva, atunci pur și simplu nu face nimic.
Să presupunem că clientul a trimis o solicitare cu atributul User-Password, iar modulul pap este inclus în secțiunea de autorizare <>. Apoi, modulul pap va stabili Auth-Type = pap.
Astfel, serverul va accesa din nou modulul pap, dar la etapa de autentificare (are, de asemenea, o secțiune proprie în autentificare <> ), pap va răspunde:
Deci, atunci există o comparație a parolei locale pre-cunoscute corecte cu cea pe care utilizatorul a introdus-o (a venit în cerere). Acesta este modul în care funcționează autentificarea.
Parola "corectă" (parola cunoscută era cunoscută în prealabil) a fost adăugată de un alt modul. De exemplu, modulul pap efectuează pur și simplu autentificarea PAP și nimic mai mult. Avantajele acestei abordări sunt că parola "corectă" poate fi adăugată interogării de la utilizatorii de fișiere text. SQL. LDAP. / etc / passwd. program extern, etc. și altele asemenea. într-o gamă foarte largă.
De exemplu, dacă un modul LDAP este conectat în secțiunea de autorizare <>. iar serverul procesează cererea, dacă modulul găsește o intrare de parolă (undeva în directorul LDAP), va adăuga această parolă la cerere, astfel încât celălalt modul să o poată utiliza în etapa de autentificare.
Ce se întâmplă dacă clientul trimite o solicitare MSCHAP? Ce va face raza serverului cu această solicitare?
Dar serverul a epuizat deja opțiunile, singura opțiune fiind mschap, deoarece acesta este ceea ce clientul a trimis în cerere. Modulul Mschap nu a putut face nimic deoarece nu i sa dat o parolă "corectă". Astfel, serverul respinge cererea de lipsă de opțiuni. Datele MSCHAP ar putea fi corecte, dar serverul nu a avut nici o modalitate de a verifica acest lucru. Prin urmare, a refuzat.
FreeRADIUS este organizat pe bază modulară. Pentru ca FreeRADIUS să susțină un anumit protocol, trebuie să activați / dezactivați modulul în configurație. Multe module, dacă nu toate, au o configurație proprie în configurația generală.
Metodele de autentificare sunt configurate în secțiunea de autentificare <>. Aici, cererea merge la modul, care este specificat în atributul Auth-Type. Pe baza datelor introduse în interogarea din modulul de stocare, chiar și în stadiul anterior, există o comparație a atributelor care provin de la client cu atributele din depozit. Pe baza acestei comparații, se ia deja o decizie pentru a permite sau a refuza accesul sau pentru a rafina parametrii pentru client.
Aici este un concept pentru un server radius, în acest caz este simplificat într-o rușine.
Pe routerele existente TP-Link TL-WR842ND cu firmware-ul din fabrică, avem capacitatea de a utiliza următoarele tipuri de protecție: WPA2-PSK, WPA2-Enterprise. Opțiunile rămase nu au fost considerate din cauza irelevanței lor: o rețea deschisă nu îndeplinește obiectivul; WEP - a fost compromis de mult timp; WPA-PSK / Enterprise - există WPA2 cu o abordare mai riguroasă pentru criptare.
WPA2-Enterprise suportă o serie de metode de autentificare EAP. EAP-TLS și EAP-PEAPv0 sunt relevante pentru Window. EAP-TLS - vă va ajuta să salvați utilizatorul de introducerea unui nume de utilizator și a unei parole, însă va exista o altă sarcină pentru implementarea infrastructurii cheilor publice și distribuirea certificatelor. Și va exista o problemă de instalare a certificatelor pe dispozitive mobile. Deși această metodă este cea mai fiabilă, dar din cauza complexității implementării și întreținerii pentru nevoile noastre, dispare.
EAP-PEAPv0 cu MS-CHAPv2 - utilizatorul are nevoie de încredere în punctul de acces / server și cunoașterea legăturii de conectare / parolă. Încrederea acordată punctului de acces / serverului este obținută prin verificarea certificatului prezentat de server sau prin dezactivarea acestei verificări. Esența metodei este de a crea un tunel securizat în interiorul căruia utilizatorul se autentifică utilizând metoda MS-CHAPv2. Implementare și întreținere ușoară, mai ales dacă aveți încredere orb în punctul de acces / server. Dar securitatea intrușilor "activi" suferă.
Trebuie remarcat faptul că aceste comenzi și fragmente de configurare au fost testate pe Debian 7.5 cu FreeRADIUS 2.1.12 + dfsg-1.2
2.1 Crearea certificatelor de producție
Deoarece cele mai multe metode WPA2 necesită un certificat și o cheie privată cel puțin pe server, va trebui să-l creați. Pentru a crea un certificat cu auto-semnare, avem nevoie de un certificat și de o cheie privată a centrului propriu de certificare, pe care trebuie, de asemenea, să-l creăm.
Instrumentele pentru crearea certificatelor Freeradius necesare din Debian sunt în calea / usr / share / doc / freeradius / examples / certs. Conținutul acestui director trebuie copiat în / etc / freeradius / certs. Fișiere necesare:
Și, de asemenea, puteți copia README, în care este pictat ce și de ce aveți nevoie și cum să îl utilizați, astfel încât comenzile necesare vor continua cu explicații scurte, pentru informații mai detaliate în README.
Pentru a rula scripturile, aveți nevoie de openssl și faceți.
Creați un fișier cu parametrii Diffie-Hellman dacă este brusc absent în directorul / etc / freeradius / certs:
Rezultatul muncii: fișier dh
Creați un certificat rădăcină sau un certificat al centrului de certificare. Dacă înainte de a exista deja unele certificate (de obicei, test), atunci ștergem:
Să editați fișierul ca.cnf. Notă default_md = MD5 (mai bine pentru a pune SHA1), default_days = 365 (nu ar putea dori să genereze un nou certificat într-un an, atunci este mai bine pentru a pune un pic mai mult), input_password / output_password și doriți să editați sub el întreaga secțiune [CERTIFICATE_AUTHORITY].
Rezultatele muncii: ca.pem. ca.key și ca.der - certificatul centrului de certificare, cheia privată și certificatul într-un format ușor de înțeles pentru Windows.
Creați un certificat de server. Putem edita fișierul server.cnf pentru dvs. Notă default_md = MD5 (mai bine pentru a pune SHA1), default_days = 365 (nu ar putea dori să genereze un nou certificat într-un an, atunci este mai bine pentru a pune un pic mai mult), input_password / output_password și doriți să editați sub el întreaga secțiune [serverul]. Este important ca valoarea commonName să fie diferită de certificatul corespunzător al centrului de certificare.
Rezultatul lucrării: printre alte fișiere server.pem și server.key sunt certificatul și cheia privată a serverului.
În configurația căii spre certificatele generate în directorul / etc / freeradius / certs sunt înregistrate în mod implicit.
2.2 Descrieți clienții RADIUS (puncte de acces)
Adăugați următoarele în fișierul /etc/freeradius/clietns.conf:
2.3 Am creat acreditări pentru autentificare prin login și parola
În fișierul / etc / freeradius / utilizatori adăugăm prima linie a următorului conținut:
Pentru a solicita o parolă de utilizator nume de utilizator va fi verificat și comparat atributul Calling-Station-Id. Pentru ca aceasta să funcționeze în cazul EAP-PEAP ar trebui să fie fișier /etc/freeradius/eap.conf setat sopy_request_to_tunnel = yes în secțiunea de mai jos:
Este suficient să adăugați utilizatorii la fișierul utilizatorilor la început cu parametrul Calling Station-Id. dacă acreditările sunt aceleași, le puteți repeta pur și simplu, de exemplu:
Trebuie remarcat faptul că atributul Calling-Station-Id specificat în fișierul utilizatorilor pentru o anumită pereche de login / parolă va funcționa, de asemenea, dar va fi verificat în stadiul care trece mai târziu. Deci, dacă vine un apel cu o valoare a Calling-Station-Id. care nu sunt specificate în fișierul authorized_macs, această solicitare va fi respinsă imediat, indiferent de ce este specificat în fișierul utilizatorilor.
Dacă schimbați fișierele de configurare, inclusiv utilizatorii și fișierele authorized_macs, trebuie să forțați configurația să redea citirea semnalului SIGHUP.
Dacă schimbați configurația radiusd.conf, este mai bine să reporniți daemonul:
Pentru a testa configurația, executați daemonul în modul de depanare:
Cu această pornire, puteți vedea modul în care freeradius a analizat configurația și a văzut cum rezolvă cererile. Ajută foarte mult la găsirea de diverse probleme sau la explicarea comportamentului neașteptat.
În kit vine un utilitar utilitar radtest - un simplu client RADIUS. Cu aceasta puteți efectua câteva teste simple pentru a verifica configurația. Un exemplu de utilizare posibil (testarea autentificării intranet prin portul 18120):
Pentru a afișa informații despre încercările de autentificare în jurnale, includeți următorii parametri în radiusd.conf.
Trimiteți-le prietenilor: