Групповые управляемые учетные записи служб для каждой службы на сервере (рекомендуется?) И длинные имена?

Question

Групповые управляемые учетные записи служб для каждой службы на сервере (рекомендуется?) И длинные имена?

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

Кажется, что в идеале мы должны создать 1 gMSA на службу (например, службу агента SQL) на сервер (например, SQLDEV01).

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

Одним из единственных минусов этого подхода является то, что может быть ОЧЕНЬ МНОГО gMSA для создания. Но с учетом сказанного, как только они будут созданы, нет особой необходимости управлять ими в будущем.

Другая проблема, с которой я сталкиваюсь, - это название gMSA (я думаю, это должно быть не более 15 символов). Кажется чрезвычайно сложным придумать имя, которое означает, что эта учетная запись - gMSA, предназначена для конкретной службы и для конкретного сервера.

Например, родовое имя, следующее типичным соглашениям, может выглядеть так:

gMSA_SQLDEV01_SQLAGT (20 символов)

Это может быть сокращено до чего-то вроде:

gmsaSQLDEV01AGT (15 символов)

Вышеприведенный пример содержит ровно 15 символов, и у него нет места для других потенциально более длинных имен серверов или служб.

Есть ли лучшая практика или способы справиться с этими ситуациями:

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

3

active-directory best-practices service-accounts managed-service-accounts name

Источник

Michael 20 апр '17 в 01:47

1 ответ

Другие вопросы по тегам active-directory best-practices service-accounts managed-service-accounts name

Ryan Bolger 20 апр '17 в 03:52 2017-04-20 03:52 · Answer 1 · 2017-04-20 03:52

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

Что касается длинных имен...

Вы можете легко освободить место, не задавая такой префикс, как gmsa, Хотя он разделяет много общих классов в objectClass атрибут, относящийся к обычным учетным записям пользователей, он также содержит свой уникальный msDS-GroupManagedServiceAccount что облегчает использование в фильтрах, где вы можете включить или исключить их. gMSA также визуально отличаются в инструментах GUI, таких как ADUC и тому подобное. Таким образом, гипотетически, люди не будут путать их с обычными учетными записями пользователей в повседневной деятельности.

Я также заметил еще одну вещь, играя с этим. Хотя New-ADServiceAccount Командлет действительно обеспечивает ограничение в 15 символов для -SamAccountName, создавая msDS-GroupManagedServiceAccount объект вручную с ADSIEdit только устанавливает ограничение в 20 символов.

На самом деле я ничего не тестировал с помощью gMSA длиной 20 символов. Так что я понятия не имею, работает ли это с чем-либо. Но, вероятно, стоит провести дополнительные тесты с вашей стороны, если вы хотите больше передышки в вашем соглашении об именах.