Запрос доступа к Radius-серверу после запросив предыдущий (успешный) доступ к другому серверу Radius
Я не знаю, бессмысленна ли эта идея, но мне было интересно, возможно ли это. У меня есть сервер FreeRadius, поддерживаемый сервером LDAP, с использованием EAP-TTLS (то есть имя пользователя + пароль) для аутентификации. Таким образом, когда пользователи подключаются к коммутатору 802.1x, им предоставляется доступ путем запроса запрашивающего соединения имени пользователя и пароля с теми, которые находятся на сервере LDAP. Эта часть в порядке.
Но что я хочу, так это после того, как этот пользователь будет предоставлен, чтобы различать "обычных" пользователей и "администраторов" с помощью сертификата клиента, на который сервер LDAP будет ссылаться как на атрибут для могут быть загружены из любого подходящего места (например, с сервера NFS), но только если этот пользователь относится к типу «admin». Затем этот сертификат клиента будет использоваться (я не знаю, как, вот в чем вопрос), чтобы запросить доступ к другому серверу FreeRadius, который в данном случае будет использовать метод EAP-TLS, чтобы пользователи-администраторы были предоставлены другому часть сети (где были бы другие толковые серверы)а «обычные» пользователи - нет.
Вкратце: я хочу иметь сервер FreeRadius для предоставления пользователям доступа к первому «просмотру» локальной сети, а также другой сервер FreeRadius (проксируемый первым?), Который предоставил бы доступ к другой «более секретной» зоне на Лан в зависимости от пользователя. Возможно ли это?
Большое спасибо !!
В идеальном мире вы бы сделали то, что вы описываете, используя метод EAP, например TEAP, который поддерживает внутриполосную подготовку учетные данные (например, сертификаты X509). К сожалению, EAP-TEAP и его предшественник EAP-FAST не получили широкого распространения.
Я знаю, что вы использовали это только в качестве примера, но я определенно не стал бы использовать NFS. Даже если на запрашивающем хосте поддерживается NFS, потребуется ручная настройка. Я бы сказал, что HTTP (S) - более очевидный выбор для получения доступа к сертификатам, учитывая его широкую поддержку и знакомство пользователей.
Попытка создать какой-то механизм обеспечения пост-аутентификации будет довольно трудной. Достаточно тривиально идентифицировать администратора, входящего в систему с учетными данными, и назначить им VLAN, которая обеспечивает доступ только к огороженному саду (где они могут загрузить свой сертификат администратора). Проблема в том, что сами огороженные стеной сады становятся все более проблематичными.
Все больше веб-сайтов переходят на «безопасный по умолчанию», что означает, что первоначальная попытка подключения, которую делает пользователь, скорее всего, будет осуществляться через https. Невозможно перенаправить / перезаписать https-трафик так же, как http-трафик, поэтому сложно перенаправить пользователей на целевую страницу огороженного сада без проблем. Если вы действительно хотите попробовать огороженный сад, вам нужно будет убедиться, что он работает правильно для проводных соединений на вашей целевой ОС.
Что касается использования разных серверов RADIUS для разных методов EAP, это не обязательно. EAP предоставляет механизм для согласования методов. Тот же модуль EAP в FreeRADIUS может запускать EAP-TTLS или EAP-TLS. Если модуль EAP запрашивает EAP-TLS по умолчанию, и у соискателя есть доступный сертификат и настроен EAP-TLS, то EAP-TLS будет запущен, в противном случае соискатель будет согласовывать EAP-TTLS, и вместо этого будет запущен EAP-TTLS.
Однако, честно говоря, предоставление учетных данных после первоначальной аутентификации кажется кошмаром для службы поддержки. Даже если администратору удастся получить доступ, загрузить и импортировать свой сертификат, ему придется вручную перенастроить своего соискателя, чтобы использовать его.
Если бы я реализовал это, я бы полностью отказался от аутентификации на основе имени пользователя и пароля и вместо этого использовал бы один из растворяемых установщиков, предлагаемых cloudpath (теперь Ruckus) и другие. Эти временные приложения могут предоставлять сертификаты пользователей и настраивать профили безопасности для сетевых интерфейсов в рамках одной операции. Вы можете предложить растворяемый установщик через общедоступный веб-сайт и направить пользователей на него во время адаптации.
Все пользователи будут иметь одинаковый опыт адаптации, но администраторы могут получить сертификат, который идентифицирует их как таковых, либо через специальный OID или с использованием другого посредника CA.