Определение определенных учетных записей Active Directory как "IsHuman"
Я хотел бы отметить определенные учетные записи Active Directory, чтобы указать, что они представляют отдельных физических лиц, а не группы, учетные записи служб, встроенные учетные записи и т. Д. Это может быть с помощью настраиваемого или встроенного атрибута, группы и т. Д.
В идеале решение будет:
- Упростите добавление атрибута к нескольким учетным записям одновременно
- Не нужно добавлять в каждый аккаунт
- Укажите некоторые признаки (визуальные и т. Д.), Которые, возможно, потребуется установить при создании учетной записи.
3 ответа
Группы - это другой тип объектов, чем у пользователей, поэтому дифференцировать их уже возможно, даже легко. Встроенные учетные записи обычно остаются в контейнере "Пользователи", в то время как учетные записи пользователей и учетные записи служб обычно сортируются в отдельные подразделения либо в контейнере "Пользователи", либо вне контейнера "Пользователи". В любом случае, сортировка по OU будет визуальной индикацией в графическом интерфейсе, а также будет легко доступна для поиска и сортировки другими приложениями, командами powershell, поисками и т. Д.
Так что просто рассортируйте пользователей по разным подразделениям по типу пользователя. Возможно, вы также захотите создать дерево подразделений для более детальной сортировки пользователей, например, вы можете отсортировать их по отделам в отдельные подразделения. Или вы могли бы отсортировать их по месту нахождения офиса или тому, что имеет смысл в бизнесе. Таким образом, у вас есть несколько способов различать пользователей с разными потребностями.
Мне также нравится сортировать все группы по подразделениям. Либо я делаю OU групп и сортирую все группы внутри него, но даже создаю древовидную структуру OU, чтобы отличать группы пользователей от групп ресурсов от групп рассылки, или я включаю группы рядом с пользователями в соответствующие OU пользователя.
Если вы не разбираете свои объекты AD в OU, вы упускаете основную функцию Active Directory.
В дополнение к использованию подразделений, вы могли (действительно должны) использовать членство в группах. Как правило, существуют причины для создания одной или нескольких групп пользователей и рассылки, которые включают в себя весь персонал организации, но не включают какие-либо встроенные или служебные учетные записи. Вы также можете создать группу рассылки и / или пользователей для всех учетных записей служб (возможно, вы сможете назначить соответствующие права для учетных записей служб группам). Группа рассылки полностью предназначена для сортировки пользователей практически ни для каких других целей (особенно если вы не используете Exchange), поэтому это идеальный механизм для группировки учетных записей для различных целей.
Если у вас есть Exchange, то вы добавили в Active Directory все виды расширений схемы, которые вы можете использовать, чтобы различать почтовые ящики пользователей и общие почтовые ящики и т. Д.
Наконец, что касается учетных записей служб, вы можете подумать о том, что требуется для различных учетных записей служб. Если у вас есть служба, для которой требуется настраиваемая учетная запись, но не требуется доступ к каким-либо сетевым ресурсам, вы можете просто создать локальную учетную запись для этой службы и предоставить ей необходимые права на локальном компьютере. Это на одну учетную запись меньше службы, загромождающей вашу рекламу.
В дополнение к @Todd Wilcoxотличный ответ, я хотел бы добавить идею соглашения об именах для объектов в AD.
Определенные аспекты "атрибутов", которые вы хотите создать для пользователей / групп, могут быть по своей природе применены при наличии очень строгого соглашения об именах для объектов и инфраструктуры, а не отклонения от него.
пользователей
Обычные имена пользователей должны быть <FirstName>.<LastName>, или же <lastName><FirstInitial>в то время как их отображаемые имена будут <LastName>, <FirstName> (<Department>), Или все, что работает для вашей компании. В любом случае, они должны быть воспроизводимы и отформатированы таким образом, чтобы, если вы знаете определенный элемент для пользователя, вы знали, как узнать о них больше, потому что вы знаете, что искать.
Real Name Department Display name User Name
John Doe IT Doe, John (IT) John.Doe
Jane Doe Finance Doe, Jane (FIN) Jane.Doe
James Doe Human Resources Doe, James (HR) James.Doe
Сервисные учетные записи должны также следовать стандартному соглашению, но отличаться от того, что используется для обычных пользователей. Это также относится к "общим" аккаунтам, но я бы все равно держался от них подальше. Мой предпочтительный формат sa.<vendor>.<product>, так что их довольно легко сгруппировать и найти для последующего повторного использования.
Vendor Product Display Name Username
VMware vSphere (SA) VMware - vSphere sa.vmware.vsphere
Microsoft SQL Server (SA) Microsoft - SQL Server sa.microsoft.sqlserver
Microsoft Exchange (SA) Microsoft - Exchange sa.microsoft.exchange
IBM Tivoli Storage Manager (SA) IBM - Tivoli Storage Manager sa.ibm.tsm
группы
Группы безопасности должны называться в зависимости от того, что они делают, и того, что они применяют, но опять-таки, следуя стандартному шаблону, чтобы можно было легко найти группы с аналогичным назначением.
Общие файловые ресурсы могут быть названы по имени общего ресурса и разрешениям, которые они предоставляют, в то время как сервер / путь для этого общего ресурса находится в описании (SHR_<ShareName>_R для чтения, SHR_<ShareName>_M для изменения).
Общие группы доступа к почтовым ящикам, могут содержать имя почтового ящика и права (GM_<SMTPAddress>_FMR для полного доступа, GM_<SMTPAddress>_SA для отправки как).
AD / server Delagation groups может быть названием команды (DLG AD DevOps), DLG SRV BackupAndStorage, так далее..)
Списки рассылки являются единственными странными списками, которые, скорее всего, будут называться более или менее независимо от того, что вложено, потому что люди захотят этого. Но даже тогда вы можете установить стандарты для них, которые работают для вашей организации.
Большинство сред, в которых я работал, не делают этого с атрибутами в учетных записях. Они делают это через организацию OU и / или стандарты именования. Упрощенный пример может быть:
- (корень домена)
- Все аккаунты
- Люди
- Общие счета
- Сервисные аккаунты
- Все аккаунты
Вы можете подразделить различные типы учетных записей, если это имеет смысл. Но в большинстве случаев членство в группах - это все, что вам нужно для дальнейшего разделения... групп... людей. Добавление стандартного префикса / суффикса к типам учетных записей, не относящихся к человеку, также может с первого взгляда упростить просмотр и управление. Например, все учетные записи служб могут начинаться с "svc.".