Managed service accounts в windows server 2016
Пошаговые руководства, шпаргалки, полезные ссылки.
Инструменты пользователя
Инструменты сайта
Боковая панель
Содержание
Создание учётных записей MSA и gMSA
Создание Managed Service Account
При необходимости создать учётную запись Managed Service Account, которая будет ограничена действием только в рамках одного компьютера, то есть учётную запись типа msDS-ManagedServiceAccount, достаточно выполнить команду типа:
-Name – имя создаваемой учётной записи MSA.
Обратите внимание на то, что имя имеет ограничение в 15 символов.
-RestrictToSingleComputer – наличие этого параметра говорит о том, что нужно создать именно учётную запись MSA (не gMSA) действие которой ограничено одним каким-либо сервером.
После успешного выполнения командлета убедимся в наличии объекта класса msDS-ManagedServiceAccount в указанном OU в домене.
С помощью PowerShell можем запросить информацию о созданной учётной записи MSA командлетом Get-ADServiceAccount.
Командлет New-ADServiceAccount имеет ряд других интересных параметров, узнать о которых можно, например, в онлайн справке.
В последствии созданную учётную запись можно будет привязать только к одному серверу.
Создание Group Managed Service Account
При необходимости создать групповую учётную запись Group Managed Service Account (класса msDS-GroupManagedServiceAccount), которую можно будет использовать в рамках нескольких компьютеров, например, на нескольких узлах какого-либо кластера, выполняем команду типа:
-Name – имя создаваемой учётной записи gMSA
После успешного выполнения командлета убедимся в наличии объекта класса msDS-GroupManagedServiceAccount в указанном OU в домене
Замечания
Создавая учётные записи MSA/gMSA лучше руководствоваться принципом «отдельный сервис – отдельная учётная запись» и не пытаться использовать одну учётную запись MSA/gMSA для разных служб, так как это понижает уровень безопасности всех служб/приложений, совместно использующих одну и туже учётную запись. К тому же даже с точки зрения отладки работы служб и приложений использование разных учётных записей может дать свои преимущества.
Проверено на следующих конфигурациях:
Автор первичной редакции:
Алексей Максимов
Время публикации: 30.10.2018 17:21
Group Managed Service Accounts Overview Group Managed Service Accounts Overview
Область применения. Windows Server (Semi-Annual Channel), Windows Server 2016 Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016
В этом разделе для ИТ Professional представлена групповая управляемая учетная запись службы с описанием практических приложений, изменений в реализации Майкрософт и требований к оборудованию и программному обеспечению. This topic for the IT professional introduces the group Managed Service Account by describing practical applications, changes in Microsoft’s implementation, and hardware and software requirements.
Описание функции Feature description
Автономная управляемая учетная запись службы (sMSA) — это управляемая Доменная учетная запись, которая обеспечивает автоматическое управление паролями, упрощенное управление именами участников-служб и возможность делегирования управления другим администраторам. A standalone Managed Service Account (sMSA) is a managed domain account that provides automatic password management, simplified service principal name (SPN) management and the ability to delegate the management to other administrators. Такой тип управляемой учетной записи службы реализован в ОС Windows Server 2008 R2 и Windows 7. This type of managed service account (MSA) was introduced in Windows Server 2008 R2 and Windows 7.
Групповая управляемая учетная запись службы (gMSA) предоставляет те же функции в домене, но также расширяет эту функциональность на нескольких серверах. The group Managed Service Account (gMSA) provides the same functionality within the domain but also extends that functionality over multiple servers. При подключении к службе, размещенной в ферме серверов, такой как решение с балансировкой сетевой нагрузки, протоколы проверки подлинности, поддерживающие взаимную проверку подлинности, должны использовать один и тот же субъект для всех экземпляров служб. When connecting to a service hosted on a server farm, such as Network Load Balanced solution, the authentication protocols supporting mutual authentication require that all instances of the services use the same principal. Если в качестве субъектов-служб используется gMSA, операционная система Windows управляет паролем для учетной записи, а не полагается на администратора для управления паролем. When a gMSA is used as service principals, the Windows operating system manages the password for the account instead of relying on the administrator to manage the password.
Служба распространения ключей (Майкрософт) (kdssvc.dll) предоставляет механизм для безопасного получения последнего ключа или определенного ключа с идентификатором ключа для учетной записи Active Directory. The Microsoft Key Distribution Service (kdssvc.dll) provides the mechanism to securely obtain the latest key or a specific key with a key identifier for an Active Directory account. Служба распространения ключей использует общий секрет для создания ключей учетной записи. The Key Distribution Service shares a secret which is used to create keys for the account. Эти ключи периодически изменяются. These keys are periodically changed. Для gMSA контроллер домена определяет пароль для ключа, предоставляемого службами распространения ключей, в дополнение к другим атрибутам gMSA. For a gMSA the domain controller computes the password on the key provided by the Key Distribution Services, in addition to other attributes of the gMSA. Узлы-члены могут получить текущие и предшествующие значения пароля, обратившись к контроллеру домена. Member hosts can obtain the current and preceding password values by contacting a domain controller.
Практическое применение Practical applications
Gmsa предоставляют единое решение идентификации для служб, работающих на ферме серверов, или для систем, использующих сетевые Load Balancer. gMSAs provide a single identity solution for services running on a server farm, or on systems behind Network Load Balancer. Предоставляя решение gMSA, можно настроить службы для нового субъекта gMSA, а управление паролями будет обрабатываться Windows. By providing a gMSA solution, services can be configured for the new gMSA principal and the password management is handled by Windows.
Использование gMSA, служб или администраторов служб не требует управления синхронизацией паролей между экземплярами службы. Using a gMSA, services or service administrators do not need to manage password synchronization between service instances. GMSA поддерживает узлы, которые хранятся в автономном режиме в течение расширенного периода времени, а также Управление узлами участников для всех экземпляров службы. The gMSA supports hosts that are kept offline for an extended time period, and management of member hosts for all instances of a service. Это означает, что можно развертывать ферму серверов, поддерживающую единое удостоверение, по которому существующие клиентские компьютеры могут проверять подлинность без идентификации экземпляра службы, к которому они подключаются. This means you can deploy a server farm that supports a single identity to which existing client computers can authenticate without knowing the instance of the service to which they are connecting.
Отказоустойчивые кластеры не поддерживают групповые управляемые учетные записи служб. Failover clusters do not support gMSAs. При этом групповую или автономную учетную запись службы могут использовать службы, работающие поверх службы кластеров и представляющие собой службу Windows, пул приложений или назначенную задачу либо поддерживающие такие учетные записи изначально. However, services that run on top of the Cluster service can use a gMSA or a sMSA if they are a Windows service, an App pool, a scheduled task, or natively support gMSA or sMSA.
Требования к программному обеспечению Software requirements
-Для выполнения команд Windows PowerShell, которые используются для администрирования gmsa, требуется битовая архитектура 64. A 64-bit architecture is required to run the Windows PowerShell commands which are used to administer gMSAs.
Начиная с версии Windows Server 2008 R2, стандарт DES отключен по умолчанию. Beginning with Windows Server 2008 R2, DES is disabled by default. Дополнительные сведения о поддерживаемых типах шифрования см. в статье Изменения в проверке подлинности Kerberos. For more information about supported encryption types, see Changes in Kerberos Authentication.
Gmsa не применимы к операционным системам Windows до Windows Server 2012. gMSAs are not applicable to Windows operating systems prior to Windows Server 2012.
Сведения о диспетчере сервера Server Manager information
См. также See also
В следующей таблице представлены ссылки на дополнительные ресурсы, связанные с управляемыми учетными записями служб и групповыми управляемыми учетными записями служб. The following table provides links to additional resources related to Managed Service Accounts and group Managed Service Accounts.
Group Managed Service Accounts Overview
Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016
This topic for the IT professional introduces the group Managed Service Account by describing practical applications, changes in Microsoft’s implementation, and hardware and software requirements.
Feature description
A standalone Managed Service Account (sMSA) is a managed domain account that provides automatic password management, simplified service principal name (SPN) management and the ability to delegate the management to other administrators. This type of managed service account (MSA) was introduced in Windows Server 2008 R2 and Windows 7.
The group Managed Service Account (gMSA) provides the same functionality within the domain but also extends that functionality over multiple servers. When connecting to a service hosted on a server farm, such as Network Load Balanced solution, the authentication protocols supporting mutual authentication require that all instances of the services use the same principal. When a gMSA is used as service principals, the Windows operating system manages the password for the account instead of relying on the administrator to manage the password.
The Microsoft Key Distribution Service (kdssvc.dll) provides the mechanism to securely obtain the latest key or a specific key with a key identifier for an Active Directory account. The Key Distribution Service shares a secret which is used to create keys for the account. These keys are periodically changed. For a gMSA the domain controller computes the password on the key provided by the Key Distribution Services, in addition to other attributes of the gMSA. Member hosts can obtain the current and preceding password values by contacting a domain controller.
Practical applications
gMSAs provide a single identity solution for services running on a server farm, or on systems behind Network Load Balancer. By providing a gMSA solution, services can be configured for the new gMSA principal and the password management is handled by Windows.
Using a gMSA, services or service administrators do not need to manage password synchronization between service instances. The gMSA supports hosts that are kept offline for an extended time period, and management of member hosts for all instances of a service. This means you can deploy a server farm that supports a single identity to which existing client computers can authenticate without knowing the instance of the service to which they are connecting.
Failover clusters do not support gMSAs. However, services that run on top of the Cluster service can use a gMSA or a sMSA if they are a Windows service, an App pool, a scheduled task, or natively support gMSA or sMSA.
Software requirements
A 64-bit architecture is required to run the Windows PowerShell commands which are used to administer gMSAs.
A managed service account is dependent upon Kerberos supported encryption types.When a client computer authenticates to a server using Kerberos the DC creates a Kerberos service ticket protected with encryption both the DC and server supports. The DC uses the account’s msDS-SupportedEncryptionTypes attribute to determine what encryption the server supports and, if there is no attribute, it assumes the client computer does not support stronger encryption types. If the host is configured to not support RC4, then authentication will always fail. For this reason, AES should always be explicitly configured for MSAs.
Beginning with Windows Server 2008 R2, DES is disabled by default. For more information about supported encryption types, see Changes in Kerberos Authentication.
gMSAs are not applicable to Windows operating systems prior to Windows Server 2012.
Server Manager information
There are no configuration steps necessary to implement MSA and gMSA using Server Manager or the Install-WindowsFeature cmdlet.
See also
The following table provides links to additional resources related to Managed Service Accounts and group Managed Service Accounts.
How To Configure Managed Service Accounts Windows Server 2016
In this article, I’ll show you how to deploy and configure Managed Service Accounts with Windows Server 2016 and Active Directory.
Managed Service Account (MSA) Is a new type of Active Directory Account type where AD responsible for changing the account password every 30 days.
With MSA no one needs to set up the account password or even know it, the entire password management process Is managed by Active Directory.
In my example, I’ll use the Managed Service Account to run my IIS Application Pool.
Requirements
To use MSA, Active Directory forest level will have to be set to Windows Server 2012 at a minimum.
You will need Active Directory Management Tools to run the cmdlets In this post
Before we start
I have to say that before I wrote this article I visited a few blogs and most of them overcomplicated the process, This post will show you how to deploy MSA In 10 minutes.
Just make sure to test it in the lab before deploying Into production.
Master Root key
The first step In the MSA deployment process Is to create a Master root Key using the cmdlet below.
Create a Service Account
To create and configure the service. I’ll use 4 cmdlets.
The first cmdlet will create the account and also create a DNS name for the account.
Once the account has been created, I will grant the Server (WDS) access to it, which mean the Server (WDS) will have permission to request a password reset every 30 days from Active Directory.
I could add multiple server names If needed.
With the cmdlet below, I can test the account (return result should be true).
And the final cmdlet will Install the Service Account on the WDS Server.
Set Windows Service
To setup Windows Server service to use the managed Service account, I’ll open the service and use the format below
Test\sms$ without typing the password.
If the account needs the log in as a service right you will see the prompt below.
Once configured, I can start the service
Just remember that If the service account needs to be part of the Domain Admins group or any other group you will need to add the service to the group as well.
SET IIS Application Pool
Next, I’ll configure the IIS Application Pool to use the Service Account.
Using the Application Pools menu and right-click on the DefaultAppPool
Select Advanced Settings
No need to type the password
As you can see below, The Application Pool started and Is using the Service Account.
Rollback
To remove the Service Account from Active Directory, I’ll use the cmdlet below:
To remove the account from a Windows service, I’ll run the line below (from the command line) with the service name
Настройка домена для групповых управляемых учетных записей служб (gMSA) Configure a domain for Group Managed Service Accounts (gMSA) scenario
Эта статья относится только к MIM 2016 с пакетом обновления 2 (SP2). This article applies to MIM 2016 SP2 only.
Microsoft Identity Manger (MIM) работает с доменом Active Directory (AD). Microsoft Identity Manger (MIM) works with your Active Directory (AD) domain. Служба AD должна быть уже установлена. Кроме того, в вашей среде должен быть контроллер для домена, которым вы можете управлять. You should already have AD installed, and make sure you have a domain controller in your environment for a domain that you are able to administer. В этой статье описывается настройка групповых управляемых учетных записей служб в домене для использования в MIM. This article describes how to set up Group Managed Service Accounts in that domain for use by MIM.
Overview Overview
Групповые управляемые учетные записи служб позволяют исключить необходимость периодически менять пароли для учетной записи службы. Group Managed Service Accounts eliminate the need to periodically change service account passwords. В выпуске MIM 2016 с пакетом обновления 2 (SP2) вы можете в процессе установки настроить использование учетных записей gMSA для следующих компонентов: With the release of MIM 2016 SP2, the following MIM components can have gMSA accounts configured to be used during the installation process:
Следующие компоненты MIM не поддерживают работу под учетными записями gMSA: The following MIM components do not support running as gMSA accounts:
Дополнительные сведения об учетных записях gMSA можно найти в следующих статьях: More information about gMSA can be found in these articles:
Создание учетных записей пользователей и групп Create user accounts and groups
Всем компонентам развертывания MIM требуются собственные удостоверения в домене. All the components of your MIM deployment need their own identities in the domain. Сюда входят такие компоненты MIM, как служба и модуль синхронизации, а также SharePoint и SQL. This includes the MIM components like Service and Sync, as well as SharePoint and SQL.
В этом пошаговом руководстве используются примеры имен и значений для компании Contoso. This walkthrough uses sample names and values from a company called Contoso. Замените их своими значениями. Replace these with your own. Пример. For example:
Войдите в контроллер домена в качестве администратора (например Contoso\Administrator). Sign in to the domain controller as the domain administrator (e. g. Contoso\Administrator).
Создайте следующие учетные записи пользователей для служб MIM: Create the following user accounts for MIM services. Запустите PowerShell и введите следующий сценарий PowerShell, чтобы создать новых пользователей домена Active Directory (не все учетные записи являются обязательными; хотя сценарий предоставляется только в информационных целях, для процесса установки MIM и SharePoint рекомендуется использовать выделенную учетную запись MIMAdmin). Start PowerShell and type the following PowerShell script to create new AD domain users (not all accounts are mandatory, although the script is provided for informational purposes only, it is a best practice to use a dedicated MIMAdmin account for MIM and SharePoint install process).
Создайте группы безопасности во всех группах. Create security groups to all the groups.
Добавление имен субъектов-служб для включения проверки подлинности Kerberos для учетных записей служб Add SPNs to enable Kerberos authentication for service accounts
Обязательно зарегистрируйте следующие А-записи DNS для корректного разрешения имен (предполагается, что служба и портал MIM, а также веб-сайты сброса и регистрации паролей будут размещены на одном компьютере). Make sure to register the following DNS ‘A’ records for proper name resolution (assuming that MIM Service, MIM Portal, Password Reset and Password Registration web sites will be hosted on the same machine)
Создание корневого ключа службы распространения ключей Create Key Distribution Service Root Key
Для подготовки службы группового распространения ключей необходимо войти на контроллер домена от имени администратора. Ensure that you are signed into your domain controller as an administrator to prepare the group key distribution service.
Если корневой ключ для домена уже существует (проверьте с помощью Get-KdsRootKey), перейдите к следующему разделу. If there is already a root key for the domain (use Get-KdsRootKey to check), then continue to the next section.
Создайте корневой ключ службы распространения ключей (KDS), если это необходимо. Это делается только один раз для каждого домена. Create the Key Distribution Services (KDS) Root Key (only once per domain) if needed. Корневой ключ (в сочетании с другими сведениями) используется службой KDS на контроллерах домена для создания паролей. Root Key is used by the KDS service on domain controllers (along with other information) to generate passwords. Введите следующую команду PowerShell от имени администратора домена: As a domain administrator, type the following PowerShell command:
При использовании -EffectiveImmediately возможна задержка длительностью до
10 часов, так как требуется выполнить репликацию на все контроллеры домена. –EffectiveImmediately may require a delay of up to
10 hours as it will need to replicate to all domain controllers. Для двух контроллеров домена эта задержка составляет примерно 1 час. This delay was approximately 1 hour for two domain controllers.
Создание учетной записи, группы и субъекта-службы для службы синхронизации MIM Create MIM Synchronization Service account, group and service principal
Убедитесь, что все учетные записи для компьютеров, на которых нужно установить программное обеспечение MIM, уже присоединены к домену. Ensure that all the computer accounts for computers where MIM software is to be installed are already joined to the domain. Затем выполните в PowerShell следующие действия от имени администратора домена. Then, perform these steps in PowerShell as a domain administrator.
Создайте учетную запись gMSA для службы синхронизации MIM. Create MIM Synchronization Service gMSA. Введите следующий код PowerShell. Type the following PowerShell.
Проверьте сведения о созданной учетной записи gMSA, выполнив PowerShell-команду Get-ADServiceAccount: Check details of the GSMA created by executing Get-ADServiceAccount PowerShell command:
Если вы планируете использовать службу уведомления о смене паролей, зарегистрируйте имя субъекта-службы, выполнив следующую команду PowerShell: If you plan to run Password Change Notification Service, you need to register Service Principal Name by executing this PowerShell command:
Перезагрузите сервер синхронизации MIM, чтобы обновить связанный с ним токен Kerberos, так как членство в группе MIMSync_Server изменилось. Reboot your MIM Synchronization server to refresh a Kerberos token associated with the server as the «MIMSync_Server» group membership has changed.
Создание учетной записи службы для агента управления службы MIM Create MIM Service Management Agent service account
Использовать групповую управляемую учетную запись для службы синхронизации MIM и не создавать отдельную учетную запись Use MIM Synchronization Service group managed service account and do not create a separate account
Не включайте параметр «Запретить вход из сети» для учетной записи gMSA службы синхронизации MIM, так как учетная запись MIM MA требует разрешения «Разрешить вход в сеть». Do not enable ‘Deny Logon from Network’ for the MIM Synchronization Service gMSA as MIM MA account requires ‘Allow Network Logon’ permission.
Использовать обычную учетную запись службы для агента управления службы MIM Use a regular service account for the MIM Service Management Agent service account
Запустите PowerShell от имени администратора домена и введите следующий код для создания пользователя домена AD: Start PowerShell as domain administrator and type the following to create new AD domain user:
Не включайте параметр «Запретить вход из сети» для учетной записи MIM MA, так как она требует разрешения «Разрешить вход в сеть». Do not enable ‘Deny Logon from Network’ for the MIM MA account as it requires ‘Allow Network Logon’ permission.
Создание учетных записей, групп и субъекта-службы для службы MIM Create MIM Service accounts, groups and service principal
Продолжайте использовать PowerShell от имени администратора домена. Continue using PowerShell as a domain admin.
Создайте учетную запись gMSA для службы MIM. Create MIM Service gMSA.
Зарегистрируйте имя субъекта-службы и включите делегирование Kerberos, выполнив следующую PowerShell-команду: Register Service Principal Name and enable Kerberos delegation by executing this PowerShell command:
Для реализации сценариев SSPR учетная запись службы MIM должна взаимодействовать со службой синхронизации MIM, поэтому нужно включить ее в группу MIMSyncAdministrators или в группу просмотра и сброса паролей службы синхронизации MIM. For SSPR scenarios you need MIM Service Account be able to communicate with MIM Synchronization Service, therefore MIM Service account must be either a member of MIMSyncAdministrators or MIM Sync Password Reset and Browse groups:
Перезагрузите сервер службы MIM, чтобы обновить связанный с ним токен Kerberos, так как членство в группе MIMService_Servers изменилось. Reboot your MIM Service server to refresh a Kerberos token associated with the server as the «MIMService_Servers» group membership has changed.
Создание других учетных записей и групп MIM (при необходимости) Create other MIM accounts and groups if needed
Если вы настраиваете SSPR для MIM, то, следуя вышеприведенным указаниям для службы синхронизации MIM и службы MIM, вы можете создать другие учетные записи gMSA для следующих компонентов: If you are configuring MIM SSPR, then following the same guidelines as described above for the MIM Synchronization Service and MIM Service, you can create other gMSA for:
Если вы настраиваете PAM для MIM, то, следуя вышеприведенным указаниям для службы синхронизации MIM и службы MIM, вы можете создать другие учетные записи gMSA для следующих компонентов: If you are configuring MIM PAM, then following the same guidelines as described above for the MIM Synchronization Service and MIM Service, you can create other gMSA for: