Kategorie szkoleń | Egzaminy | Kontakt
  • 1
  • 0
  • 91

Chciałem autoryzować użytkowników WiFi przy wykorzystaniu kont w AD.

Access Point -> WPA2 Enterprise -- RHEL7 FreeRadius (MSCHAPv2 PEAP) -> Active Directory.

Wykorzystuje mechanizm ntlm_auth chciałem jednak, żeby używany do tego była nazwa użytkownika UserPrincipalName (nazwa@domena).

Wygląda jednak na to, że ten mechanizm kiepsko sobie radzi z UserPrincipalName, natomiast nie ma problemów z SamAccountName.

Mogę dopisać odpowiednie "REALMY"  w /etc/raddb/proxy.conf i jeżeli UserPrincipalName będzie zgodny z SamAccountName + @domena to przejdzie.

Co jednak w przypadku kiedy będę miał w systemie dwóch użytkowników np user1@departmant1.company.local i user1@departmant2.company.local mających jednak różne SamAccountName?

Oczywiście mogę dodać dwa "REALMY" np:

 

realm departman1.company.local {

authhost = LOCAL

accthost = LOCAL

}

realm departman2.company.local {

authhost = LOCAL

accthost = LOCAL

}

Ale wtedy autoryzuje mi tylko użytkownika o SamAccountName user1 (po prostu będzie do niego dopisywał departmant1.company.local lub departmant2.company.local).

Domyślnie w pliku /etc/raddb/mods-enabled/mschap mamy wpisane użycie ntlm_auth w następujący sposób:

 

ntlm_auth = "/usr/bin/ntlm_auth --request-nt-key --username=%{%{Stripped-User-Name}:-%{%{User-Name}:-None}} --challenge=%{%{mschap:Challenge}:-00} --nt-response=%{%{mschap:NT-Response}:-00}"

 

A mechanizm niezależnie od radiusa możemy użyć tak:

 

ntlm_auth --request_nt-key --domain=company.local --username=userad.

 

Czy możemy tak zrobić aby był sprawdzany użytkownik z AD po UserPrincipalName zamiast SamAccountName?

ghost
  • Zapytał
  • @ ghost | 05.02.2016
    • 0
    • 1
    • 12

Odpowiedź (1)

  • 0

Możliwe, że filtracja w sekcji ldap w konfiguracji radiusa pomoże - patrzył Pan w te okolice konfiguracji?

  • Odpowiedział
  • @ | 24.02.2016
  • TRENER MODERATOR ALTKOM AKADEMII