We rise up for the things we believe in over and over again
Что такое WebMarshal? Это контент-фильтр, работающий в паре с прокси-сервером, хотя и сам может выступать в роли последнего. Его задача - более детальное исследование трафика, который идет в Интернет и оттуда, с целью отсечения нежелательного материала. Отличие от обычного прокси в том, что контент-фильтрация режет пользователей не только и не столько по адресам, а по содержанию тех страниц, что пользователи пытаются посетить.
Поработав немного с этой программой и вникнув в ее логику построения правил, нашел ее очень удобной, но есть одна ошибка, которая в последнюю неделю мне попортила изрядное количество крови. Суть ее в следующем.
В своей работе WebMarshal может использовать как свою собственную базу пользователей, так и базу Active Directory. Последнее весьма удобно, не нужно "плодить сущности", как многие говорят. Не буду вдаваться в тонкости организации этой структуры, перейду сразу к делу.
Если пользователь, будучи уже импортированным из Active Directory меняет свое расположение в структуре OU (организационных единиц - читай, в другую перекинули его), при следующем же сеансе обновления информации из Active Directory WebMarshal такого пользователя не найдет. Он упорно будет пытаться найти его в старой OU. Эта ситуация разобрана на самом сайте WebMarshal - вот ссылка на страницу:
Moving Active Directory users between OUs - Клац!
В статье указывается, что проблема эта была решена в версии программы 6.1.6. Не подтверждаю. Используется версия 6.1.7 - ошибка сохраняется. В качестве решения предлагается связаться с технической поддержкой WebMarshal.
Что ж, разумно. В конце концов, тех. поддержка на то и нужна, чтобы решать такие вопросы. Но ведь хочется самому понять, в чем неприятность.
А неприятность заключается в следующем. WebMarshal не работает напрямую с учетными записями в Active Directory. Он создает их реплику в собственной базе. И именно эту реплику он каждый раз обновляет во время синхронизации с Active Directory. Вот только почему-то если WebMarshal видит, что запись в AD обновлена, у себя он не изменяет существующую запись, а создает новую. И все бы ничего, но если попытаться показать список группы, которая содержит переехавшую учетку, это приведет к чтению базы из WebMarshal с ее одновременным обновлением из AD. А в базе WebMarshal будет прочитан сбойный элемент, которого в AD уже нет на старом месте. После чего программа впадает в ступор и выкидывает сообщение об ошибке.
Ручная очистка базы из консоли WebMarshal нужного результата не дает. Сбойная запись по-прежнему где-то сидит и мешает жить. Наконец, было принято решение на свой страх и риск залезть напрямую в SQL базу. Найдя там таблицу dbo.User и открыв ее, я пришел в ужас. Сколько раз была добавлена та учетка, будучи в разных OU, столько раз она и содержалась в базе, несмотря на все сеансы очистки из консоли. Дальнейшее уже тривиально. Смоделировать еще раз ошибочную ситуацию, выписать ID той записи, что сбоит, и грохнуть ее из всех таблиц, которые к этой записи могут относиться.
Согласен, метод весьма жесткий, но иногда приходится действовать и так.
UPD. Только сейчас пришло в голову, что можно и не удалять сбойную запись, а всего лишь выправить значение в поле Name, там, где указывается DN этой записи. В итоге исправление нужно будет вносить только в одной таблице. А это уже куда проще и приятнее для базы в целом.