proNovell

А не подскажет ли кто-нибудь, как имея BM 3.5 SP3 добиться следующего:
имеется несколько сегментов сети, из них SSL-аутентификация необходима только в одном, а в остальных желательно, чтобы пользователи ничего о ней не знали (идельный вариант, чтобы прокси попросту выдавал им 403 ошибку)

Либо правилами по диапазону IP адресов, либо поиграться с назначением Public и Private интерфесов.

Боюсь, что вряд ли получится - аутентификация включается на уровне всего прокси-сервера, и после её включения Border Manager будет её требовать от всех, независимо от правил и интерфейсов (хотя бы для того, чтобы в логе имя пользователя прописать). Играться можно разве что с разными способами аутентификации - попробовать, например, внедрить SSO через Clntrust.exe, чтобы пользователей лишними вопросами не беспокоить.

Еще можно фмльтрами прикрыть

Как с фильтрами так и с правилами уже "игрались", но ничего не помогает

А если зайти с др стороны, не получается закрыть SSL порт - закрыть Proxy порт.

ИМХО, Константин Ошмян уже все сказал:

внедрить SSO через Clntrust.exe, чтобы пользователей лишними вопросами не беспокоить.

К этому варианту добавить еще отключение SSL - и вы в шоколаде с ног до головы! По этому варианту тот сегмент сети, где будет запускаться clntrust, будет юзить прокси без проблем - даже без ответа на глупые вопросы в окошке SSL-аутентификации. Остальные сегменты не смогут пользоваться прокси даже в том случае, ежели укажут адрес прокси-сервера. Правда, тут проблема м.б. в том, что пользователь из разрешенного сегмента может зайти со своей учеткой в запрещенном сегменте. Обычно clntrust запускается из логин-скрипта. Вдобавок к назначению прав на clntrust на уровне файловой системы необходимо добавить запрет (restriction) на адреса, с которых пользователь может заходить в сеть.

К сожалению, закрыть прокси для сегментов, в которых аутентификация не требуется нельзя, т.к. в этих сегментах юзера должны ходить в Инет без нее (т.е. правила назначаются не по объектам NDS, а по IP-адресам). Что касается аутентификации, то она по некоторым причинам происходит не через clntrust, а через HTML-страничку и поэтому когда юзер из сегмента, в котором не требуется аутентификации, обращается к запрещенному ресурсу, то хотелось бы чтобы эта страничка у него не появлялась (а к примеру сразу выскакивала 403 ошибка).

Блин...
1. Ежели юзверю не надобен прокси - пусть просто галку снимет в осле! Я-то думал - тебе не надо, чтобы из ентих сегментов вообще ходили А тут все наоборот...
2. Если ты правила (или фильтры - не знаю, чем ты там разруливаешь) прописываешь, основываясь на айпишниках - при чем здесь юзвери вообще??? Они в принципе могут просто сесть за любую из машин с разрешенным айпишником и выйти в инет! Никак ты не сможешь это предотвратить.... Единственный способ - гонять их из-за этих машин. Насколько мне ивзестно, комбинированные правила - такие, чтобы учитывали и адрес, и юзверя - на прокси (любом) прописывать нельзя... Хотя здесь я могу и ошибаться - знаком только со сквидом и бордюром. Эти, как встречают первое отрабатывающее правило, остальную цепочку просто игнорируют... Можно, конечно, поставить еще один прокси и авторизовать по цепочке - но это, во-первых, лишняя задержка при обработке, во-вторых - какой именно из проксей ставить первым???

Короче - мне кажется, что никак проблему решить тебе не удастся...

Приветствую!
Похоже, что тут неясность на организацонном уровне. При отсутствии ясного критерия неочевидной становится и истина (с) Ю. Семенов.
Из этого сегмента - ходи через прокси, из другого - ходи без прокси Может, все-таки всем через прокси, не смотря на цвет штанов
Раздавать правила по адресам ... Мне конечно, далеко, но кажется, причина просто в отсутствии системы пользователей и сетевых правил . Если этот так, то создайте их, и вам будет счастье!
С уважением, And

Олег Тоцкий (OlegT) писал(а):К сожалению, закрыть прокси для сегментов, в которых аутентификация не требуется нельзя, т.к. в этих сегментах юзера должны ходить в Инет без нее (т.е. правила назначаются не по объектам NDS, а по IP-адресам). Что касается аутентификации, то она по некоторым причинам происходит не через clntrust, а через HTML-страничку и поэтому когда юзер из сегмента, в котором не требуется аутентификации, обращается к запрещенному ресурсу, то хотелось бы чтобы эта страничка у него не появлялась (а к примеру сразу выскакивала 403 ошибка).

Transparent HTTP Proxy + правила по IP адресам.

А кто сказал, что прокси где-то не нужен? Он нужен во всех сегментах. Только в одном из сегментов от юзеров требуется аутентификация (с помощью SSL + Html form), а в других сегментах пользователи ходят в Инет через прокси, но без аутентификации (т.е. в правилах BM прописан список IP-адресов с которых такое дозволено). В тех же правилах прописаны некоторые сайты, на которые доступ закрыт всем без исключения. В сегменте с аутентификацией при попытке доступа к такому сайту прокси сразу выдает 403 ошибку, а в стальных сегментах прокси сначала требует аутентификации (разумеется, ведь стоит галка "Authenticate only when user attempts to access a restricted page"). Так вот, требуется, чтобы прокси не требовал в этих сегментах аутентификации, а сразу выдавал 403 ошибку.

OlegT писал(а):В сегменте с аутентификацией при попытке доступа к такому сайту прокси сразу выдает 403 ошибку, а в стальных сегментах прокси сначала требует аутентификации (разумеется, ведь стоит галка "Authenticate only when user attempts to access a restricted page").

Именно это я и имел в виду, когда говорил:

Константин Ошмян писал(а):Боюсь, что вряд ли получится - аутентификация включается на уровне всего прокси-сервера, и после её включения Border Manager будет её требовать от всех, независимо от правил и интерфейсов

(эх, приятно себя, любимого, цитировать! )
Т.е. то, что Вы пытаетесь сделать, в Border Manager 3.x не работает - ни в 3.5, ни в 3.6, ни в 3.7. Может быть, будет по-другому, когда сделают версию 4.0, но пока - нет, работает так именно потому, что именно так и сделано (извините за тавтологию).

А раз так, как Вы пытаетесь сделать, не работает, - значит, можно попробовать сделать как-то по-другому. Один из вариантов я предложил - вместо отсутствия аутентификации вообще использовать аутентификацию через CLNTRUST.EXE - для пользователей эффект будет тот же, а для Вас - отличаться тем, что будет работать.