Более эффективный мониторинг членства в группах в Active Directory (C # .NET)

Question

У меня есть инструмент синхронизации Active Directory (.NET 2.0 / C #), написанный как служба Windows, над которым я некоторое время работал, и недавно мне было поручено добавить возможность управлять событиями на основе изменений в членстве в группе.Базовый сценарий заключается в том, что пользователи синхронизируются с базой данных безопасности, и при изменении членства в группе пользователям необходимо изменить свои права доступа (т.е.если я теперь являюсь членом "ИТ-персонала", то я должен автоматически получать доступ к серверной комнате, если я удален из этой группы, то я должен автоматически потерять доступ к серверной комнате).

Проблема в том, что при выполнении DirectorySynchronization для групп вы получаете обратно группу, в которую был добавлен / удален участник, и оттуда, когда вы захватываете список участников, вы получаете обратно список всех участников в этой группе в данный момент, а не только участников, которые были добавлены или удалены.Это приводит меня к довольно серьезной проблеме эффективности - поскольку для того, чтобы узнать, был ли добавлен или удален пользователь, мне нужно будет хранить локально список каждой группы и всех участников и сравнивать его с текущим списком, чтобы увидеть, кто был добавлен (не в локальный список), а кто был удален (в локальный список, не в список текущих участников).

Я обсуждаю возможность простого сохранения сведений о членстве в группе в наборе данных в памяти и записи на диск каждый раз, когда я обрабатываю новые изменения членства.Таким образом, если служба остановится / выйдет из строя или компьютер будет перезагружен, я все равно смогу получить информацию о текущем состоянии Active Directory в базе данных безопасности, сравнив последнюю информацию на диске с информацией из текущего списка участников группы.Однако это кажется ужасно неэффективным - перебирать каждого участника в группе для сравнения с тем, что есть в наборе данных, а затем записывать изменения на диск каждый раз, когда в списке появляются изменения.

Кто-нибудь сталкивался с этим сценарием раньше?Есть ли какой-нибудь способ, который я не нашел, чтобы получить только дельту членов группы?Что бы вы сделали в этой ситуации, чтобы гарантировать, что вы никогда не пропустите никаких изменений при минимально возможном снижении производительности?

Редактировать: В объявлении может быть 500 пользователей, в нем может быть 200 000 пользователей - это зависит от заказчика и, кроме того, от количества групп, в которых состоит средний пользователь

Answer 1

Я бы сказал, что это зависит от того, сколько объектов active Directory вам нужно отслеживать.Если это небольшое число (менее 1000 пользователей), вы, вероятно, сможете сериализовать данные о своем состоянии на диск с незначительным снижением производительности.Если вы имеете дело с очень большим количеством объектов, возможно, было бы эффективнее создать простую схему сохранения в чем-то вроде SQL Express и использовать ее.

Answer 2

Вы можете настроить аудит успешности внесения изменений в учетную запись в редакторе групповой политики

Затем вы можете отслеживать записи в журнале безопасности и обрабатывать записи в журнале изменений учетной записи.

Например.

        EventLog myLog = new EventLog("Security");

        // set event handler
        myLog.EntryWritten += new EntryWrittenEventHandler(OnEntryWritten);
        myLog.EnableRaisingEvents = true;

Убедитесь, что у вас есть права доступа к журналу событий безопасности http://support.microsoft.com/kb/323076

Answer 3

Вы знаете, что существуют продукты, которые помогают вам с синхронизацией каталогов и подготовкой пользователей (погуглите эти термины)?Изобретено не здесь и все такое, и вам, возможно, придется оправдывать инвестиции в нынешних условиях, но разработка и сопровождение кода, для которого уже существует коммерческое решение, не всегда является, скажем так, самым рентабельным способом в долгосрочной перспективе.

Не все поддерживают eventing / provisioning, но они поддерживают отслеживание изменений и их распространение:нет ничего сложного в создании решений для проведения соревнований поверх этих возможностей.

У Microsoft есть Сервер интеграции идентификационных данных (MISS), который переупаковывается как часть Менеджер жизненного цикла идентификационных данных.Первоначально он был построен на более общем продукте для управления мета / основными данными, но вполне работоспособен.IBM обладает Интегратор каталогов Tivoli (но вам нужно следить за изменениями названия раз в два года!).У Oracle есть Oracle Identity Manager - Менеджер идентификации, и Солнце , и Менеджер идентификации.Большинство из них являются ведущими продуктами, приобретаемыми крупными игроками, чтобы заполнить пробел в своих портфелях.

Конечно, это продукты корпоративного класса, то есть большие и дорогие, но в целом довольно перспективные и расширяемые.Если вам не нужна их полная мощность (пока!), вам нужно будет подумать о том, чтобы сохранить копию для себя.В таком случае, рассматривали ли вы возможность сохранения вашей копии последнего известного дерева объявлений с использованием Рекламные СПД (ранее AD/AM)?Это не оптимальный формат для сравнения различий, но база данных каталогов будет достаточно хорошо масштабироваться, даже самая легкая.