This reference topic for IT professionals describes the default local user accounts for servers, including how to manage these built-in accounts on a member or standalone server.
About local user accounts
Local user accounts are stored locally on the server. These accounts can be assigned rights and permissions on a particular server, but on that server only. Local user accounts are security principals that are used to secure and manage access to the resources on a standalone or member server for services or users.
This topic describes the following:
For information about security principals, see Security Principals.
Default local user accounts
The default local user accounts are built-in accounts that are created automatically when you install Windows.
After Windows is installed, the default local user accounts cannot be removed or deleted. In addition, default local user accounts do not provide access to network resources.
Default local user accounts are used to manage access to the local server’s resources based on the rights and permissions that are assigned to the account. The default local user accounts, and the local user accounts that you create, are located in the Users folder. The Users folder is located in the Local Users and Groups folder in the local Computer Management Microsoft Management Console (MMC). Computer Management is a collection of administrative tools that you can use to manage a single local or remote computer. For more information, see How to manage local accounts later in this topic.
Default local user accounts are described in the following sections.
Administrator account
The default local Administrator account is a user account for the system administrator. Every computer has an Administrator account (SID S-1-5-domain-500, display name Administrator). The Administrator account is the first account that is created during the Windows installation.
The Administrator account has full control of the files, directories, services, and other resources on the local computer. The Administrator account can create other local users, assign user rights, and assign permissions. The Administrator account can take control of local resources at any time simply by changing the user rights and permissions.
The default Administrator account cannot be deleted or locked out, but it can be renamed or disabled.
In Windows 10 and Windows Server 2016, Windows setup disables the built-in Administrator account and creates another local account that is a member of the Administrators group. Members of the Administrators groups can run apps with elevated permissions without using the Run as Administrator option. Fast User Switching is more secure than using Runas or different-user elevation.
Account group membership
By default, the Administrator account is installed as a member of the Administrators group on the server. It is a best practice to limit the number of users in the Administrators group because members of the Administrators group on a local server have Full Control permissions on that computer.
The Administrator account cannot be deleted or removed from the Administrators group, but it can be renamed.
Security considerations
Because the Administrator account is known to exist on many versions of the Windows operating system, it is a best practice to disable the Administrator account when possible to make it more difficult for malicious users to gain access to the server or client computer.
You can rename the Administrator account. However, a renamed Administrator account continues to use the same automatically assigned security identifier (SID), which can be discovered by malicious users. For more information about how to rename or disable a user account, see Disable or activate a local user account and Rename a local user account.
As a security best practice, use your local (non-Administrator) account to sign in and then use Run as administrator to accomplish tasks that require a higher level of rights than a standard user account. Do not use the Administrator account to sign in to your computer unless it is entirely necessary. For more information, see Run a program with administrative credentials.
In comparison, on the Windows client operating system, a user with a local user account that has Administrator rights is considered the system administrator of the client computer. The first local user account that is created during installation is placed in the local Administrators group. However, when multiple users run as local administrators, the IT staff has no control over these users or their client computers.
In this case, Group Policy can be used to enable secure settings that can control the use of the local Administrators group automatically on every server or client computer. For more information about Group Policy, see Group Policy Overview.
NoteВ В Blank passwords are not allowed in the versions designated in the Applies To list at the beginning of this topic.
ImportantВ В Even when the Administrator account has been disabled, it can still be used to gain access to a computer by using safe mode. In the Recovery Console or in safe mode, the Administrator account is automatically enabled. When normal operations are resumed, it is disabled.
Guest account
The Guest account is disabled by default on installation. The Guest account lets occasional or one-time users, who do not have an account on the computer, temporarily sign in to the local server or client computer with limited user rights. By default, the Guest account has a blank password. Because the Guest account can provide anonymous access, it is a security risk. For this reason, it is a best practice to leave the Guest account disabled, unless its use is entirely necessary.
Account group membership
By default, the Guest account is the only member of the default Guests group (SID S-1-5-32-546), which lets a user sign in to a server. On occasion, an administrator who is a member of the Administrators group can set up a user with a Guest account on one or more computers.
Security considerations
When enabling the Guest account, only grant limited rights and permissions. For security reasons, the Guest account should not be used over the network and made accessible to other computers.
In addition, the guest user in the Guest account should not be able to view the event logs. After the Guest account is enabled, it is a best practice to monitor the Guest account frequently to ensure that other users cannot use services and other resources, such as resources that were unintentionally left available by a previous user.
HelpAssistant account (installed with a Remote Assistance session)
The HelpAssistant account is a default local account that is enabled when a Remote Assistance session is run. This account is automatically disabled when no Remote Assistance requests are pending.
HelpAssistant is the primary account that is used to establish a Remote Assistance session. The Remote Assistance session is used to connect to another computer running the Windows operating system, and it is initiated by invitation. For solicited remote assistance, a user sends an invitation from their computer, through e-mail or as a file, to a person who can provide assistance. After the user’s invitation for a Remote Assistance session is accepted, the default HelpAssistant account is automatically created to give the person who provides assistance limited access to the computer. The HelpAssistant account is managed by the Remote Desktop Help Session Manager service.
Security considerations
The SIDs that pertain to the default HelpAssistant account include:
SID: S-1-5- -13, display name Terminal Server User. This group includes all users who sign in to a server with Remote Desktop Services enabled. Note that, in Windows Server 2008, Remote Desktop Services are called Terminal Services.
SID: S-1-5- -14, display name Remote Interactive Logon. This group includes all users who connect to the computer by using a remote desktop connection. This group is a subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.
For the Windows Server operating system, Remote Assistance is an optional component that is not installed by default. You must install Remote Assistance before it can be used.
For details about the HelpAssistant account attributes, see the following table.
HelpAssistant account attributes
Attribute
Value
S-1-5- -13 (Terminal Server User), S-1-5- -14 (Remote Interactive Logon)
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.
Управляемые учётные записи служб (Managed Service Accounts)
Есть способ, который позволяет узнать пароль администратора в случае, если какая-либо служба запускается от его имени. Пароли учетных записей, от которых запускаются службы Windows, хранятся в зашифрованном виде в реестре (LSA Secrets) по пути:
Существуют способы, которые позволяют извлечь пароли из LSA Secrets:
Скопировать путь реестра во временный путь, а затем расшифровать зашифрованные пароли
Использовать теневые копии
Использовать специальные утилиты для работы с процессом lsass.exe
Попробуем получить пароль от учетной записи под которой запускается служба SQL Server. Имеется: Контроллер домена на Windows Server 2012 R2 SQL Server Express 2012 При установке SQL Server, для запуска службы, специально укажем существующую доменную учётную запись (пароль меньше 14 символов).
Воспользуемся утилитой gsecdump для извлечения паролей. Запустим PowerShell от имени администратора и выполним команду: gsecdump-v2b5.exe -l Результат:
Чтобы защититься от такого рода атак в Windows Server 2008 R2 был придуман механизм Managed Service Accounts. Managed Service Accounts являются управляемыми учетными записями в домене, которые обеспечивают автоматическое управление паролями и упрощенное управление именами служб-участников, включая делегирование управления другим администраторам. Преимущества управляемых учетных записей служб:
Автоматическая смена паролей. По умолчанию смена пароля – раз в 30 дней
Сложный пароль. Используется комплексный автоматически генерируемый пароль из 240 символов в случайном порядке (первая половина — буквы английского алфавита, вторая половина — цифры и другие символы)
Отсутствие избыточных прав
Возможность использования одного MSA на нескольких серверах (gMSA). В случае, когда требуется, чтобы все экземпляры служб использовали один и тот же субъект, например для использования в службе NLB
Управление SPN
Автоматическое обновление SPN при переименовании — учетной записи сервера — свойства dnshostname учетной записи сервера — изменении свойства addition¬aldnshostname учетной записи сервера — изменении свойства additionalsam¬accountname учетной записи сервера
Сервисы и службы, которые поддерживают MSA:
IIS
AD LDS
SQL Server 2008 R2 SP1, 2012
MS Exchange 2010, 2013
Требования MSA:
Уровень домена и леса – Windows Server 2008 R2
Windows Server 2008 R2, Windows 7 (Professional, Enterprise, Ultimate)
.Net Framework 3.5x
Модуль администрирования Active Directory для PowerShell
Установленный патч 2494158
Если лес и домен не имеют уровень 2008 R2 (MSA) и 2012 (gMSA) нужно поднять уровень леса командой: adprep /forestprep И уровень домена, командой: adprep /domainprep в каждом домене, в котором необходимо создать и использовать управляемые учетные записи службы.
Включение MSA в PowerShell 1) Выполнить командлет: Import-Module ActiveDirectory 2) Чтобы создать учётную запись MSA нужно выполнить командлет: New-ADServiceAccount serviceaccount –RestrictToSingleComputer где serviceaccount – имя учетной записи MSA RestrictToSingleComputer – параметр означает, что MSA будет привязан только к одному серверу. Можно зайти в Active Directory Users and Computers и убедиться, что MSA был создан (чтобы появился раздел Managed Service Accounts, нужно включить в оснастке View — Advanced Features).
3) Чтобы привязать MSA к серверу нужно выполнить командлет: Add-ADComputerServiceAccount -Identity server -ServiceAccount serviceaccount где server – имя сервера, который будет соотнесён с MSA serviceaccount – имя учетной записи MSA Чтобы проверить, что операция выполнена успешно, нужно зайти в оснастку Active Directory Users and Computers, перейти в свойства сервера и посмотреть атрибут msDS-HostServiceAccount
4) Установка управляемой учетной записи службы на локальном компьютере Нужно выполнить командлет: Install-ADServiceAccount -Identity serviceaccount где serviceaccount – имя учетной записи MSA 5) Тестирование MSA (Windows 8.1, Windows PowerShell 4.0, Windows Server 2012 R2) Нужно выполнить командлет: Test-ADServiceAccount serviceaccount где serviceaccount – имя учетной записи MSA Вернёт значение True или False 6) Установить для службы Windows запуск от имени MSA и перезапустить службу. В конце имени MSA не забудьте указать знак $ Поле пароль нужно оставить пустым.
Проверим с помощью утилиты gsecdump пароль для учётной записи службы
В Windows Server 2012 появились Групповые управляемые учетные записи служб (Group Managed Service Accounts). Они позволяют привязывать управляемую учетную запись не к одному серверу, а к нескольким. Это может потребоваться, например, для использования в службе балансировки сетевой нагрузки.
Требования:
Уровень схемы – Windows Server 2012
Контроллер домена Windows Server 2012 (R2) на котором запущена служба Microsoft Key Distribution Service
Windows Server 2012, 2012 R2, 8, 8.1
Модуль администрирования Active Directory для PowerShell
Включение gMSA в PowerShell 1) Проверить, что включена служба Microsoft Key Distribution Services “Служба распространения ключей использует общий секрет для создания ключей учетной записи. Эти ключи периодически изменяются. В дополнение к прочим атрибутам групповых управляемых учетных записей служб контроллер домена Windows Server 2012 вычисляет пароль для ключа, предоставленного службами распространения ключей. Обратившись к контроллеру домена Windows Server 2012, узлы Windows Server 2012 и Windows 8 могут получить текущий и предыдущий пароль.” 2) Создать Root Key За создание Root Key отвечает командлет: Add-KdsRootKey Чтобы создать новый Root Key нужно выполнить командлет: Add-KdsRootKey –EffectiveImmediately В таком случае ключ будет доступен через 10 часов, пока не среплицируется. Можно выполнить командлет: Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10)) В таком случае, ключ будет доступен сразу (-10 часов начала работы) 3) Создать gMSA Выполнить командлет: New-ADServiceAccount serviceaccount -DNSHostName test.test.com –PrincipalsAllowedToRetrieveManagedPassword $test где serviceaccount – имя учетной записи gMSA test.test.com – имя сервера, на котором был создан Root Key $test – имя сервера, который может обращаться к KDS для получения информации
Можно зайти в Active Directory Users and Computers и убедиться, что gMSA был создан (чтобы появился раздел Managed Service Accounts, нужно включить в оснастке View — Advanced Features).
4) Установка управляемой учетной записи службы на локальном компьютере Нужно выполнить командлет: Install-ADServiceAccount -Identity serviceaccount где serviceaccount – имя учетной записи gMSA 5) Тестирование MSA (Windows 8.1, Windows PowerShell 4.0, Windows Server 2012 R2) Нужно выполнить командлет: Test-ADServiceAccount serviceaccount где serviceaccount – имя учетной записи MSA Вернёт значение True или False 6) Установить для службы Windows запуск от имени gMSA и перезапустить службу. В конце имени gMSA не забудьте указать знак $ Поле пароль нужно оставить пустым.
Проверим с помощью утилиты gsecdump пароль для учётной записи службы
Удалить MSA/gMSA можно с помощью командлета Uninstall-ADServiceAccount
Задавать параметры MSA/gMSA можно с помощью командлета Set-ADServiceAccount Задание периода смены пароля: Set-ADServiceAccount serviceaccount -ManagedPasswordIntervalInDays 60 где serviceaccount – имя учетной записи gMSA 60 – период, через который сменится пароль Задание криптоалгоритмов Kerberos для использования MSA Варианты: RC4, AES128, AES256 Set-ADServiceAccount serviceaccount -KerberosEncryptionType RC4, AES128, AES256 Задание SPN Set-ADServiceAccount serviceaccount -ServicePrincipalNames @
Задание NetBIOS имени для сервиса (SAMAccountName) Если не задано, используется идентификатор Name Если задано, имя отображения в AD будет из Name, а идентификатор для логина из SAMAccountName Set-ADServiceAccount serviceaccount –SamAccountName test
MSA – это ещё один способ, который позволяет повысить безопасность.
