Konfigurowanie RADIUS + LDAP dla WPA2 na Ubuntu

Konfiguruję sieć bezprzewodową dla ~ 150 użytkowników. Krótko mówiąc, szukam przewodnika, aby ustawić serwer RADIUS do uwierzytelniania WPA2 względem LDAP. Na Ubuntu.

• Mam działający LDAP, ale ponieważ nie jest on wykorzystywany w produkcji, można go bardzo łatwo dostosować do wszelkich zmian, których może wymagać ten projekt.
• Patrzyłem na FreeRADIUS, ale zrobi to każdy serwer RADIUS.
• Mamy oddzielną fizyczną sieć tylko dla Wi-Fi, więc nie ma zbyt wielu obaw o bezpieczeństwo na tym froncie.
• Nasze AP to produkty HP klasy korporacyjnej - wydają się obsługiwać wszystko, co tylko możesz wymyślić.
• Wszystkie serwery Ubuntu, kochanie!

I złe wieści:

• Teraz ktoś mniej kompetentny ode mnie w końcu przejmie administrację, więc konfiguracja musi być jak najbardziej „trywialna”.
• Jak dotąd nasza konfiguracja oparta jest wyłącznie na oprogramowaniu z repozytoriów Ubuntu, z wyjątkiem naszej administracyjnej aplikacji internetowej LDAP i kilku małych specjalnych skryptów. Więc nie "pobierz pakietu X, untar, ./configure"-things, jeśli można tego uniknąć.

AKTUALIZACJA 18.08.2009:

Chociaż znalazłem kilka przydatnych zasobów, jest jedna poważna przeszkoda:

Ignoring EAP-Type/tls because we do not have OpenSSL support.
Ignoring EAP-Type/ttls because we do not have OpenSSL support.
Ignoring EAP-Type/peap because we do not have OpenSSL support.

Zasadniczo wersja FreeRADIUS Ubuntu nie obsługuje SSL ( błąd 183840 ), co czyni wszystkie bezpieczne typy EAP bezużytecznymi. Porażka.

Ale przydatna dokumentacja dla wszystkich zainteresowanych:

• http://vuksan.com/linux/dot1x/802-1x-LDAP.html
• http://tldp.org/HOWTO/html_single/8021X-HOWTO/#confradius

AKTUALIZACJA 2009-08-19:

Wczoraj wieczorem skończyłem kompilowanie własnego pakietu FreeRADIUS - istnieje naprawdę dobry przepis na stronie http://www.linuxinsight.com/building-debian-freeradius-package-with-eap-tls-ttls-peap-support.html (zobacz komentarze do wpisu zawierające zaktualizowane instrukcje).

Mam certyfikat z http://CACert.org (prawdopodobnie powinieneś dostać „prawdziwy” certyfikat, jeśli to możliwe)

Następnie postępowałem zgodnie z instrukcjami na stronie http://vuksan.com/linux/dot1x/802-1x-LDAP.html . To łącze do http://tldp.org/HOWTO/html_single/8021X-HOWTO/ , które jest bardzo przydatne, jeśli chcesz wiedzieć, jak działa bezpieczeństwo Wi-Fi.

AKTUALIZACJA 27.08.2009:

Po wykonaniu powyższego przewodnika udało mi się przekonać FreeRADIUS do rozmowy z LDAP:

Utworzyłem użytkownika testowego w LDAP z hasłem mr2Yx36M- daje to wpis LDAP w przybliżeniu:

uid: testuser
sambaLMPassword: CF3D6F8A92967E0FE72C57EF50F76A05
sambaNTPassword: DA44187ECA97B7C14A22F29F52BEBD90
userPassword: {SSHA}Z0SwaKO5tuGxgxtceRDjiDGFy6bRL6ja

Podczas używania radtestmogę dobrze połączyć:

> radtest testuser "mr2Yx36N" sbhr.dk 0 radius-private-password
Sending Access-Request of id 215 to 130.225.235.6 port 1812
    User-Name = "msiebuhr"
    User-Password = "mr2Yx36N"
    NAS-IP-Address = 127.0.1.1
    NAS-Port = 0
rad_recv: Access-Accept packet from host 130.225.235.6 port 1812, id=215, length=20
> 

Ale kiedy próbuję przez AP, nie leci - podczas gdy potwierdza, że ​​rozpoznaje hasła NT i LM:

...
rlm_ldap: sambaNTPassword -> NT-Password == 0x4441343431383745434139374237433134413232463239463532424542443930
rlm_ldap: sambaLMPassword -> LM-Password == 0x4346334436463841393239363745304645373243353745463530463736413035
[ldap] looking for reply items in directory...
WARNING: No "known good" password was found in LDAP.  Are you sure that the user is configured correctly?
[ldap] user testuser authorized to use remote access
rlm_ldap: ldap_release_conn: Release Id: 0
++[ldap] returns ok
++[expiration] returns noop
++[logintime] returns noop
[pap] Normalizing NT-Password from hex encoding
[pap] Normalizing LM-Password from hex encoding
...

Oczywiste jest, że hasła NT i LM różnią się od powyższych, ale komunikat [ldap] user testuser authorized to use remote access- a użytkownik zostanie później odrzucony ...

Spróbuję odpowiedzieć na pytanie LDAP tutaj.

Oto krótka odpowiedź: upewnij się, że ldapmoduł został usunięty z authenticatesekcji i upewnij się, że mschapmoduł jest obecny zarówno authorizew authenticatesekcji, jak i w sekcji. I po prostu zignoruj ​​hasło „Nie„ znane ”dobre hasło”.

A oto (bardzo) długa odpowiedź.

Jak działa moduł LDAP?

Gdy aktywujesz ldapmoduł w authorizesekcji, dzieje się tak, gdy FreeRADIUS odbiera pakiet RADIUS:

1. próbuje połączyć się z serwerem LDAP (jako użytkownik-gość lub przy użyciu podanej tożsamości, jeśli jest skonfigurowany ldap.conf)
2. szuka wpisu nazwy użytkownika za pomocą filtra pod podstawową nazwą wyróżniającą (skonfigurowaną w ldap.conf).
3. pobiera wszystkie atrybuty LDAP, które może uzyskać spośród skonfigurowanych ldap.attrmap, i konwertuje je na atrybuty RADIUS.
4. dodaje te atrybuty do listy elementów kontrolnych pakietu RADIUS.

Gdy aktywujesz ldapmoduł w authenticatesekcji, to właśnie robi FreeRADIUS:

1. próbuje połączyć się z serwerem LDAP jako użytkownik .
2. jeśli może się powiązać, oznacza to, że uwierzytelnienie zakończyło się powodzeniem, a Radius-Acceptpakiet zostanie odesłany z powrotem do klienta, w przeciwnym razie jest to błąd prowadzący do Radius-Rejectpakietu.

Jak więc skonfigurować FreeRADIUS, aby PEAP / MS-CHAP-v2 działał z LDAP?

Ważną kwestią jest to, że wiązanie, ponieważ użytkownik będzie działał tylko wtedy, gdy serwer FreeRADIUS będzie mógł pobrać hasło użytkownika w postaci jawnego tekstu z otrzymanego pakietu RADIUS. Dzieje się tak tylko wtedy, gdy stosowane są metody uwierzytelniania PAP lub TTLS / PAP (i ewentualnie także EAP / GTC). Tylko metoda TTLS / PAP jest naprawdę bezpieczna i domyślnie nie jest dostępna w systemie Windows. Jeśli chcesz, aby Twoi użytkownicy łączyli się z TTLS / PAP, musisz poprosić ich o zainstalowanie oprogramowania suplikanta TTLS, co rzadko jest opcją. Przez większość czasu, gdy wdrażasz WiFi z WPA Enterprise securiy, PEAP / MS-CHAP-v2 jest jedyną rozsądną opcją.

Podsumowując, jeśli nie używasz PAP lub TTLS / PAP, możesz bezpiecznie usunąć ldapmoduł z authenticatesekcji, a właściwie powinieneś: powiązać, ponieważ użytkownik nie będzie działał.

Jeśli twój test działa, gdy go używasz radtest, prawdopodobnie oznacza to, że ldapmoduł został aktywowany w authenticatesekcji: spróbuje się połączyć jako użytkownik, a ponieważ radtest używa uwierzytelnienia PAP, powiedzie się. Ale nie powiedzie się, jeśli spróbujesz połączyć się przez punkt dostępu, ponieważ używasz PEAP / MS-CHAP-v2.

Co należy zrobić, to usunąć ldapmoduł z authenticatesekcji i upewnij się, że aktywowałeś mschapmoduł zarówno authorizew authenticatesekcji, jak i w sekcji. Stanie się tak, że mschapmoduł zajmie się uwierzytelnianiem za pomocą NT-Passwordatrybutu, który jest pobierany z serwera LDAP podczas authorizefazy.

Oto jak sites-enabled/defaultpowinien wyglądać Twój plik (bez wszystkich komentarzy):

    ...
    authorize {
        preprocess
        suffix
        eap {
            ok = return
        }
        expiration
        logintime
    }
    authenticate {
        eap
    }
    ...

A oto jak sites-enabled/inner-tunnelpowinien wyglądać twój plik:

    ...
    authorize {
        mschap
        suffix
        update control {
               Proxy-To-Realm := LOCAL
        }
        eap {
            ok = return
        }
        ldap
        expiration
        logintime
    }
    authenticate {
        Auth-Type MS-CHAP {
            mschap
        }
        eap
    }
    ...

Co powiesz na ostrzeżenie „Brak„ dobrego ”hasła?

Cóż, możesz to bezpiecznie zignorować. Po prostu dlatego, że ldapmoduł nie mógł znaleźć UserPasswordatrybutu, gdy pobierał dane użytkownika z serwera LDAP podczas authorizefazy. W twoim przypadku masz ten NT-Passwordatrybut, i to doskonale nadaje się do PEAP/MS-CHAP-v2uwierzytelnienia.

Wydaje mi się, że ostrzeżenie istnieje, ponieważ kiedy ldapmoduł został zaprojektowany, PEAP/MS-CHAP-v2jeszcze nie istniał, więc jedyną rzeczą, która wydawała się wtedy sensowna, było pobranie atrybutu UserPassword z serwera LDAP, aby użyć PAP, CHAP, EAP / MD5 lub takie metody uwierzytelniania.

Spróbuję odpowiedzieć na pytanie OpenSSL tutaj: krótką odpowiedzią jest użycie FreeRADIUS 2.1.8 lub nowszej, która obejmuje OpenSSL . Jest dostępny w backportach Ubuntu Lucid i Debian Lenny (i prawdopodobnie znajdzie się również w backportach Ubuntu Karmic).

Oto długa odpowiedź:

Niestety, licencja OpenSSL była (nieco) niezgodna z licencją FreeRADIUS. Dlatego ludzie Ubuntu zdecydował się zapewnić binarny freeradius nie połączony z OpenSSL. Jeśli chciał EAP / TLS, PEAP lub TTLS, to miał dostać źródła i skompilować je z --with-opensslopcją (jak przepis użyłeś wyjaśnia).

Ale ostatnio problem z licencjonowaniem został naprawiony . FreeRADIUS w wersji 2.1.8 lub nowszej może być kompilowany i dystrybuowany za pomocą OpenSSL. Zła wiadomość jest taka, że ​​najnowsza stabilna dystrybucja Ubuntu (Karmic Koala) zawiera tylko FreeRADIUS 2.1.0, bez OpenSSL (to samo dotyczy Debiana, ponieważ Lenny zawiera tylko FreeRADIUS 2.0.4). Sprawdziłem backporty Karmic, ale wygląda na to, że FreeRADIUS 2.1.8 lub wyższy nie został jeszcze tam przesłany (ale można go wkrótce dodać, sprawdź tutaj). Na razie musisz przełączyć się na Ubuntu Lucid (który zawiera FreeRADIUS 2.1.8) lub trzymać się kompilacji. Dla użytkowników Debiana sprawy są nieco jaśniejsze: backports Lenny'ego obejmuje FreeRADIUS 2.1.8. Więc jeśli chcesz czegoś bardzo stabilnego, łatwego w instalacji i utrzymaniu, proponuję wdrożyć serwer z Debianem Lennym i zainstalować backportowany pakiet FreeRADIUS (daje również możliwość pisania modułów python za darmo, bez konieczności ponownej kompilacji z wszystkie moduły eksperymentalne).

Mam certyfikat z http://CACert.org (prawdopodobnie powinieneś dostać „prawdziwy” certyfikat, jeśli to możliwe)

Jest jedna „gotcha” z „prawdziwymi” certyfikatami (w przeciwieństwie do certyfikatów z podpisem własnym).

Użyłem jednego podpisanego przez Thawte. Działa dobrze, a użytkownicy widzą piękny „ważny” certyfikat o nazwie coś w rodzaju www.my-web-site.com. Kiedy użytkownik akceptuje certyfikat, jego komputer w rzeczywistości rozumie, że wszystkie certyfikaty wydane przez ten sam urząd certyfikacji powinny być zaufane (przetestowałem to w systemie Windows Vista i MacOSX Snow Leopard)! Więc w moim przypadku, jeśli haker ma certyfikat, powiedzmy, www.some-other-web-site.compodpisany również przez Thawte, może łatwo przeprowadzić atak Man-in-the-middle, bez wyświetlania ostrzeżenia na komputerze użytkownika!

Rozwiązanie tego leży głęboko w konfiguracji sieci komputera użytkownika, aby konkretnie określić, że należy ufać tylko „www.my-web-site.com”. To zajmuje tylko minutę, ale większość użytkowników nie będzie wiedziała, gdzie to skonfigurować, chyba że dasz im jasną procedurę i upewnisz się, że każdy użytkownik postępuje zgodnie z nią. Nadal używam „ważnych” certyfikatów, ale szczerze mówiąc, rozczarowujące jest to, że zarówno Windows, jak i MacOSX udostępniają ten „błąd”: ufanie urzędowi certyfikacji zamiast konkretnego certyfikatu. Auć...

Według raportu o błędzie prosta przebudowa FreeRADIUS powinna naprawić problem obsługi OpenSSH. Trzeba to zrobić tylko raz.

Nie jestem pewien, co łatwość administracji ma wspólnego z konfiguracją. Często im bardziej zaangażowana i szczegółowa jest konfiguracja, tym łatwiej jest nią administrować, ponieważ konfiguracja obejmowała wszystkie podstawy. Czy masz na myśli, że konfigurację należy łatwo usunąć na inne serwery? Ile bezprzewodowych sieci LAN konfigurujesz?

Po skonfigurowaniu administracja powinna ograniczać się do dodawania, usuwania i modyfikowania przez użytkownika LDAP. Powinny one być łatwe do skryptu za pomocą ldapmodify (i in.) Lub znalezienia przyzwoitego graficznego interfejsu użytkownika LDAP i udokumentowania procesów za pomocą zrzutów ekranu.

Natrafiłem na ten sam problem. Musiałem pobrać źródła RADIUS i sam je skompilować.

Możesz użyć FreeRADIUS2 (z OpenSSL) + EAP-TLS + WPA2-Enterprice. Oto bardzo szczegółowe instrukcje . Windows XP SP3 ma natywną obsługę, a także Windows 7, Android 2.3, iPhone, Symbian. Ale nie wiem o kompatybilności z SLDAP w takim schemacie.