В целом, с Active Directory, что большинство компаний используют в качестве уникального идентификатора для людей? - PullRequest
0 голосов
/ 20 января 2019

Я пытаюсь создать базу данных, в которой хранятся записи Active-Directory для пользователей / сотрудников.

  1. Безопасно ли предполагать, что запросить: (objectClass=person)

  2. Какой атрибут я должен хранить как уникальный идентификатор, который не является DN?например, я должен использовать mail или uid

Также, когда сотрудник деактивируется, есть ли новый атрибут, который добавляется, или они просто полностью удаляются из AD?

1 Ответ

0 голосов
/ 21 января 2019

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

  1. Это так?безопасно предположить, что запросить: (objectClass = person)?

Все созданные пользователи попадают под категорию (objectClass=person).Но затем, если вы создадите универсального пользователя для доступа к общей папке в системе (через ADUC (dsa.msc) / powershell / C # и т. Д.), Который не будет сотрудником, то в этом случае он будет нарушать ваш поисксостояние, несмотря на то, что человек класса.Я могу вспомнить очень много других сценариев, в которых было бы невозможно избежать создания универсальных пользователей (которые опять-таки будут принадлежать объектному классу), по крайней мере, с точки зрения компании среднего размера и выше.

Следовательно,в таких случаях лучше следовать соглашению об именах в вашей среде, чтобы избежать такой путаницы.В качестве примера можно привести, например, установку имени участника-пользователя / sAMAccountName для пользователей, не являющихся сотрудниками, для запуска с genXXXX, и в дальнейшем вы сможете легко выполнять поиск всех пользователей-сотрудников.

Какой атрибут я должен хранить как уникальный идентификатор, который не является DN?например, я должен использовать почту или uid?

В AD уже есть уникальные идентификаторы, такие как objectGUID и objectSid.В домене значения sAMAccountName / UPN также являются уникальными.Но вы не можете полагаться на это при поиске на уровне леса.

objectSid для пользователя может измениться при переносе пользователя в другой домен, но objectGUID никогда не изменится.Подробнее о SID и GUID можно прочитать здесь .

Также, когда сотрудник деактивируется, появляется ли новый атрибут, который добавляется, или они просто полностью удаляются из AD?

На стороне AD автоматический триггер отсутствует.Существует атрибут под названием lastLogontimeStamp, который помогает отслеживать, когда учетная запись пользователя или компьютера вошла в домен (не прямой сценарий, а недавний - в зависимости от того, правильно ли он обновляется).

Кто-то должен вручную отключить / удалить учетную запись, если сотрудник / пользователь покидает организацию.В компаниях предусмотрена настройка процессов для решения этого сценария, когда решения Access Management связаны с модулями AD, а также занимаются входом и выходом пользователей и выполняют соответствующие действия в AD.


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

...