...
- При первом подключении клиента (ISE ничего о нем не знает, ТД тоже), ТД пытается пройти MAB авторизацию на NAC сервере, подставляя MAC адрес клиента в атрибуты User-Name и User-Password запроса access-request к Radius серверу. Так-как ISE ничего не знает о данном клиенте, он присылает access-reject
- После того как ТД получила access-reject она отправляет клиенту ссылку редиректа на гостевой портал ISE (который был в ТД прописан при настройки SSID) формата: https://100.110.0.161:8443/portal/PortalSetup.action?portal=f09aaac2-f101-45ed-832f-fda201ab7639?action_url=http%3A%2F%2Fredirect%2Eloc%3A10081%2F&redirect=http%3A%2F%2Fconnectivitycheck%2Egstatic%2Ecom%2Fgenerate%5F204&ap_mac=68%3A13%3AE2%3AC2%3A19%3A70 при при этом навешивая ACL, с доступом только до гостевого портала.
- После саморегистрации пользователя на гостевом портале и успешного логина через форму портала, по присланному логину и паролю, информация об устройстве как устройство MAB заносится в базу Endpoins, в которой содержится в том числе мак клиента. А клиенту возвращается ссылка редиректа на proxy сервис ТД, содержащая в себе адрес сайта, на который клиент хотел попасть изначально, логин и пароль, под которым клиент успешно залогинился на гостевом портале. Ссылка вида: http://redirect.loc:10081/?token=CYO1UK0IE1KI8BIWVNBJYR8WTNGAK1TP&buttonClicked=4&err_flag=0&err_msg=&info_flag=0&info_msg=&redirect_url=http%3A%2F%2Fconnectivitycheck. gstatic.com%2Fgenerate_204&username=Gena&password=Password414
- Когда клиент переходит по этой ссылке ТД вычитывает из нее логин и пароль и подставляет в атрибуты User-Name и User-Password запроса access-request , radius успешно авторизует клиента и ТД снимает ACL на доступ клиента и редиректит на изначально запрашиваемый пользователем портал.
- После отключения от SSID и подключения заново или подключения к другой ТД (к тому же SSID), авторизация будет проходить по mac адресу (так-как этот сценарий реализован в логике ТД "external portal" и срабатывает при подключении к SSID, если ТД не "помнит" клиента). И редиректа пользователя на портал происходить не будет, до тех пор, пока endpoint клиента не будет удален из базы, в ручную или автоматически (по какой-то настроенной логике)
...
Проверил сценарий портальной авторизации согласно логики зашитой в ТД "Cisco-Like". Работает:
В котором ТД известного клиента сначала аутентифицирует через Radius по mac, затем получив access-reject, редиректит на портал cisco ISE, после регистрации пользователя на портале и получения пользователям ссылки редиректа вида http://redirect.loc:10081/?token=CYO1UK0IE1KI8BIWVNBJYR8WTNGAK1TP&buttonClicked=4&err_flag=0&err_msg=&info_flag=0&info_msg=&redirect_url=http%3A%2F%2Fconnectivitycheck.gstatic.com%2Fgenerate_204&username=Gena&password=Password414
Перехода
перехода клиента по данной ссылке, авторизует через Radius, по выданному порталом логину и паролю (которые портал включил в ссылку редиректа, в виде объектов &username=Gena&password=Password414).
При отключении клиента от ТД и повторном подключении (через промежуток превышающий параметр age-timeout , указанный на ТД) или подключении к другой ТД вещающей ту же WIFI сеть, ТД авторизует клиента по mac адресу (так-как Cisco ISE уже знает клиента и занесла его mac адрес в базу EndPoints).
...
Dump файл Radius обмена ТД и Cisco ISE dump-ise-radius.pcap
Для более продвинутых сценариев гостевого доступа, необходимо так-же реализовать:
...