Действия Logging AD пользователей (с удаленными пользователями)

голоса
3

Мы собираемся перенести веб-приложение интрасети с помощью защиты собственности на основе форм в Active Directory. Приложение регистрирует различные действия пользователя, и существует значительное количество данных, связанных с учетными записями пользователей. Наш план состоял в том, чтобы перенести все эти USERID столбцов в различных таблицах: от внешнего ключа, соединяющего собственной системы, с GUID Active Directory. Вход имена идентичны между двумя системами, поэтому миграция не является проблемой.

Тем не менее, мы определили одну главную проблему: Наша политика безопасности диктует, что неактивные пользователи должны быть удалены из Active Directory. Сиротое GUID в наших журналах безопасности делает записи довольно бессмысленными для любого просмотра их.

Как приложение может поддерживать удобочитаемых основы (имя, Логин и т.д.) о GUID, который был удален из Active Directory?

Мы рассмотрели следующие варианты. Одним из таких вариантов может оказаться оптимальным, но мы хотим, чтобы попробовать лучше:

  • Денормализовать таблицы журнала и название магазина / логин вместо GUID (хорошо для журналов, не так много для активных данных.)
  • Поддерживать «кэш» информации объекта AD, где записи никогда не удаляются
  • Ведение учетной записи AD, но деактивация / блокировки вниз
Задан 19/05/2009 в 12:46
источник пользователем
На других языках...                            


3 ответов

голоса
0

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

Ответил 19/05/2009 в 12:52
источник пользователем

голоса
1

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

Ответил 19/05/2009 в 13:07
источник пользователем

голоса
0

Мы решили использовать «кэш» таблицу, которая будет хранить словарь GUIDs, отображающий дружественную пользовательской информацию. Для этого потребуется представление, абстрагирует список пользователей AD и срастается недостающие записи из кэша.

Ответил 20/05/2009 в 18:14
источник пользователем

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more