Auth-Type:- Отклонить в файле пользователей RADIUS соответствует внутренний запрос туннеля, но отправляет Access-Accept

У меня есть настройка аутентификации WPA2 802.11x EAP с использованием FreeRADIUS 2.1.8 в Ubuntu 10.04.4 для связи с OpenLDAP, и я могу успешно аутентифицироваться с использованием PEAP/MSCHAPv2, TTLS/MSCHAPv2 и TTLS/PAP (как через AP, так и с использованием eapol_test). Сейчас я пытаюсь ограничить доступ к определенным SSID на основе групп LDAP, к которым принадлежит пользователь.

Я настроил проверку членства в группе /etc/freeradius/modules/ldap вот так:

groupname_attribute = cn
groupmembership_filter = "(|(&(objectClass=posixGroup)(memberUid=%{User-Name}))(&(objectClass=posixGroup)(uniquemember=%{User-Name})))"

и я настроил извлечение SSID из Called-Station-Id в Called-Station-SSID на основе вики-страницы Mac Auth. В /etc/freeradius/eap.conf Я включил копирование атрибутов из внешнего туннеля во внутренний туннель и использование ответа внутреннего туннеля во внешнем туннеле (как для PEAP, так и для TTLS). У меня было такое же поведение до изменения этих параметров, однако.

copy_request_to_tunnel = yes
use_tunneled_reply = yes

я бегу eapol_test вот так, чтобы проверить настройки:

eapol_test -c peap-mschapv2.conf -a 172.16.0.16 -s testing123 -N 30:s:01-23-45-67-89-01:Example-EAP

со следующим peap-mschapv2.conf файл:

network={
    ssid="Example-EAP"
    key_mgmt=WPA-EAP
    eap=PEAP
    identity="mgorven"
    anonymous_identity="anonymous"
    password="foobar"
    phase2="autheap=MSCHAPV2"
}

Со следующим в /etc/freeradius/users:

DEFAULT Ldap-Group == "employees"

и работает freeradius-XxЯ вижу, что поиск группы LDAP работает, и что SSID извлечен.

Debug:   [ldap] performing search in dc=example,dc=com, with filter (&(cn=employees)(|(&(objectClass=posixGroup)(memberUid=mgorven))(&(objectClass=posixGroup)(uniquemember=mgorven))))
Debug: rlm_ldap::ldap_groupcmp: User found in group employees
...
Info:        expand: %{7} -> Example-EAP

Далее я пытаюсь разрешить доступ только пользователям в employees группа (независимо от SSID), поэтому я поставил следующее в /etc/freeradius/users:

DEFAULT Ldap-Group == "employees"

DEFAULT Auth-Type := Reject

Но это сразу же отклоняет запрос доступа во внешнем туннеле, потому что anonymous пользователь не в employees группа. Поэтому я модифицирую его так, чтобы он соответствовал только внутренним туннельным запросам, например так:

DEFAULT Ldap-Group == "employees"

DEFAULT FreeRADIUS-Proxied-To == "127.0.0.1"
        Auth-Type := Reject, Reply-Message = "User does not belong to any groups which may access this SSID."

Теперь пользователи, которые находятся в employees группы аутентифицируются, но и пользователи, которых нет в employees группа. Я вижу, что отбракованная запись совпадает, и ответное сообщение установлено, но клиент получает Access-Accept.

Debug: rlm_ldap::ldap_groupcmp: Group employees not found or user is not a member.
Info: [files] users: Matched entry DEFAULT at line 209
Info: ++[files] returns ok
...
Auth: Login OK: [mgorven] (from client test port 0 cli 02-00-00-00-00-01 via TLS tunnel)
Info:   WARNING: Empty section.  Using default return values.
...
Info: [peap] Got tunneled reply code 2
        Auth-Type := Reject
        Reply-Message = "User does not belong to any groups which may access this SSID."
...
Info: [peap] Got tunneled reply RADIUS code 2
        Auth-Type := Reject
        Reply-Message = "User does not belong to any groups which may access this SSID."
...
Info: [peap] Tunneled authentication was successful.
Info: [peap] SUCCESS
Info: [peap] Saving tunneled attributes for later
...
Sending Access-Accept of id 11 to 172.16.2.44 port 60746
        Reply-Message = "User does not belong to any groups which may access this SSID."
        User-Name = "mgorven"

а также eapol_test доклады:

RADIUS message: code=2 (Access-Accept) identifier=11 length=233
   Attribute 18 (Reply-Message) length=64
      Value: 'User does not belong to any groups which may access this SSID.'
   Attribute 1 (User-Name) length=9
      Value: 'mgorven'
...
SUCCESS

Почему запрос не отклоняется, и это правильный способ реализовать это?