Назад | Перейти на главную страницу

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

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

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

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

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

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

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

Его можно было бы сократить до примерно такого:

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

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

  1. групповые управляемые сервисные аккаунты с разделением ответственности?
  2. группировать управляемые учетные записи служб с длинными именами?

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

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

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

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

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