Managed Service Accounts

There is a way that allows you to find out the administrator password in case any service is launched on its behalf.
The passwords of the accounts from which Windows services are launched are stored in an encrypted form in the registry (LSA Secrets) along the path:

HKEY_LOCAL_MACHINE / Security / Policy / Secrets

There are ways that can extract passwords from LSA Secrets:

• Copy the registry path to a temporary path, and then decrypt the encrypted passwords
• Use shadow copies
• Use special utilities to work with the lsass.exe process

Let's try to get the password from the account under which the SQL Server service is running.
There is:
Domain controller on Windows Server 2012 R2
SQL Server Express 2012
When installing SQL Server, to start the service, we specially indicate the existing domain account (password is less than 14 characters).



We will use the gsecdump utility to extract passwords.
Run PowerShell as an administrator and run the command: gsecdump-v2b5.exe -l
Result:



To protect against this type of attack in Windows Server 2008 R2, the Managed Service Accounts mechanism was invented.
Managed Service Accounts are managed domain accounts that provide automatic password management and simplified management of member service names, including delegation of management to other administrators.
Benefits of Managed Service Accounts:

• Automatic password change. The default password change is once every 30 days.
• Password is complicated. A complex, automatically generated password of 240 characters is used in random order (the first half is the letters of the English alphabet, the second half is numbers and other characters)
• Lack of redundant rights
• Ability to use one MSA on multiple servers (gMSA). In the case where it is required that all service instances use the same subject, for example for use in the NLB service
• SPN Management

Automatically updating the SPN when renaming
- server account
- dnshostname property of the server account
- changing the addition¬aldnshostname property of the server account
- changing the additionalsam¬accountname property of the server account

Services that support MSA:

• IIS
• AD LDS
• SQL Server 2008 R2 SP1, 2012
• MS Exchange 2010, 2013

MSA requirements:

• Domain and Forest Level - Windows Server 2008 R2
• Windows Server 2008 R2, Windows 7 (Professional, Enterprise, Ultimate)
• .Net Framework 3.5x
• Active Directory Administration Module for PowerShell
• Installed patch 2494158

If the forest and domain do not have 2008 R2 (MSA) and 2012 (gMSA) level, you need to raise the forest level with the command:
adprep / forestprep
AND the domain level with the command:
adprep / domainprep in each domain in which you need to create and use managed service accounts.

Enabling MSA in PowerShell
1) Run the cmdlet: Import-Module ActiveDirectory
2) To create an MSA account you need to run the cmdlet:
New-ADServiceAccount serviceaccount –RestrictToSingleComputer
where serviceaccount is the name of the MSA account
RestrictToSingleComputer - the parameter means that the MSA will be bound to only one server .
You can go into Active Directory Users and Computers and make sure that the MSA has been created (for the Managed Service Accounts section to appear, you need to enable View - Advanced Features in the snap-in).


3) To bind the MSA to the server, you need to run the cmdlet:
Add-ADComputerServiceAccount -Identity server -ServiceAccount serviceaccount
where server is the name of the server that will be
associated with the MSA serviceaccount is the name of the MSA account
To verify that the operation is successful, go to the Active snap-in Directory Users and Computers, go to the server properties and see the msDS-HostServiceAccount attribute


4) Install the managed service account on the local computer
You need to run the cmdlet:
Install-ADServiceAccount -Identity serviceaccount
where serviceaccount is the name of the MSA account
5) Testing MSA (Windows 8.1, Windows PowerShell 4.0, Windows Server 2012 R2)
You need to run the cmdlet:
Test-ADServiceAccount serviceaccount
where serviceaccount is the name of the MSA account
Returns True or False
6) Set the Windows service to start on behalf of the MSA and restart the service.
At the end of the MSA name, be sure to include the $ sign.
The password field must be left blank.


Using the gsecdump utility, verify the password for the service account.


Group Managed Service Accounts appeared in Windows Server 2012.
They allow you to bind a managed account not to one server, but to several.
This may be required, for example, for use in a network load balancing service.

Requirements:

• Schema Level - Windows Server 2012
• Windows Server 2012 (R2) domain controller running Microsoft Key Distribution Service
• Windows Server 2012, 2012 R2, 8, 8.1
• Active Directory Administration Module for PowerShell

Enabling gMSA in PowerShell
1) Verify that Microsoft Key Distribution Services is turned on
“The key distribution service uses a shared secret to create account keys. These keys are periodically changed. In addition to the other attributes of group managed service accounts, the Windows Server 2012 domain controller calculates the password for the key provided by the key distribution services. Turning to the Windows Server 2012 domain controller, the Windows Server 2012 and Windows 8 nodes can get the current and previous password. ”
2) Create the Root Key
The cmdlet:
Add-KdsRootKey is responsible for creating the Root Key .
To create a new Root Key, you need to run the cmdlet:
Add-KdsRootKey –EffectiveImmediately
In this case, the key will be available after 10 hours until it is replicated.
You can run the cmdlet:
Add-KdsRootKey –EffectiveTime ((get-date) .addhours (-10))
In this case, the key will be available immediately (-10 hours to get started)
3) Create a gMSA
Run the cmdlet:
New-ADServiceAccount serviceaccount -DNSHostName test.test.com –PrincipalsAllowedToRetrieveManagedPassword $ test
where serviceaccount is the name of the gMSA account
test.test.com is the name of the server on which Root was created. Key
$ test is the name of the server that can contact KDS for information

You can go into Active Directory Users and Computers and make sure that gMSA has been created (for the Managed Service Accounts section to appear, you need to enable View - Advanced Features in the snap-in).


4) Installing a managed service account on the local computer
You need to run the cmdlet:
Install-ADServiceAccount -Identity serviceaccount
where serviceaccount is the name of your gMSA account
5) MSA testing (Windows 8.1, Windows PowerShell 4.0, Windows Server 2012 R2)
You need to run the cmdlet:
Test- ADServiceAccount serviceaccount
where serviceaccount is the name of the MSA account.
Returns True or False.
6) Set the Windows service to run as gMSA and restart the service.
At the end of the gMSA name, be sure to include the $ sign .
The password field must be left blank.


Using the gsecdump utility, we can verify the password for the service account


Remove MSA / gMSA using the Uninstall-ADServiceAccount cmdlet You can

set the MSA / gMSA parameters using the Set-ADServiceAccount cmdlet
Setting the password change period:
Set-ADServiceAccount serviceaccount -ManagedPasswordIntervalInDays 60
where service gMSA
60 records - the period after which the password will be changed
Setting Kerberos cryptographic algorithms for using MSA
Options: RC4, AES128, AES256
Set-ADServiceAccount serviceaccount -KerberosEncryptionType RC4, AES128, AES256
SPN job
Set-ADServiceAccount serviceaccount -ServicePrincipalNames @ {Add = "added SPN"}

NetBIOS job name for the service (SAMAccountName)
If no
name is specified, the identifier is used, it is used will be from Name, and the identifier for the login from SAMAccountName
Set-ADServiceAccount serviceaccount –SamAccountName test

MSA is another way to improve security.