Не знаю, бессмысленна ли эта идея, но мне было интересно, возможно ли это. У меня есть сервер 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.
Честно говоря, предоставление учетных данных после начальной аутентификации кажется кошмаром для службы поддержки. Даже если администратору удастся получить доступ, загрузить и импортировать свой сертификат, ему придется вручную перенастроить своего соискателя, чтобы использовать его.
Если бы я реализовал это, я бы полностью отказался от аутентификации на основе имени пользователя и пароля и вместо этого использовал бы один из растворимых установщиков, предлагаемых облачный путь (теперь Ruckus) и другие. Эти временные приложения могут предоставлять сертификаты пользователей и настраивать профили безопасности для сетевых интерфейсов в рамках одной операции. Вы можете предложить растворимый установщик через общедоступный веб-сайт и указать пользователям на него во время адаптации.
У всех пользователей будет одинаковый опыт подключения, но администраторам может быть предоставлен сертификат, который идентифицирует их как таковых, либо через специальный OID, либо с помощью другого промежуточного центра сертификации.