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

Question

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

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

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

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

Edit: AD может содержать 500 пользователей, он может содержать 200000 пользователей - это зависит от клиента, и на вершине, что сколько групп средний пользователь является членом

Answer 1

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

Answer 2

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

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

E.g.

 EventLog myLog = new EventLog("Security"); 

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

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

Answer 3

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

Не все события поддержки/обеспечения поддержки, но они поддерживают отслеживание изменений и их распространение: это не большое дело, создавая решения для принятия решений поверх этих возможностей.

Microsoft имеет Identity Integration Server (MISS), который переупаковывается как часть Identity Lifecycle Manager. Он был первоначально построен на более общем мета/мастерском управлении данными, но он работоспособен. IBM имеет Tivoli Directory Integrator (но вам нужно идти в ногу с изменениями в бийерли!). Oracle имеет Oracle Identity Manager, а Sun - Identity Manager. Большинство из них - это ведущие продукты, которые покупают крупные игроки, чтобы заполнить пробел в своих портфелях.

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