Managed Service Accounts

There is a way that allows you to find out the administrator password in case any service runs on its behalf.
The account passwords from which the Windows services are started are stored encrypted in the registry (LSA Secrets) along the following paths:

HKEY_LOCAL_MACHINE / Security / Policy / Secrets

There are ways to 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 will specifically indicate the existing domain account (password less than 14 characters).
')


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



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

• Automatic password change. The default password change is once every 30 days.
• Difficult password. Uses a complex automatically generated password of 240 characters in random order (the first half is the letters of the English alphabet, the second half is numbers and other symbols)
• Lack of excess rights
• The ability to use one MSA on multiple servers (gMSA). When it is required that all service instances use the same subject, for example for use in the NLB service
• SPN Management

Automatic update SPN when renaming
- server account
- dnshostname server account properties
- changing the server account addition¬aldnshostname property
- change the additionalsamaccountname property of the server account

Services and 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) levels, 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 want to create and use managed service accounts.

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


3) To bind the MSA to the server, 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 - MSA account name
To check that the operation was completed successfully, go to the Active Directory Users and Computers snap-in, 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 MSA account name
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 MSA account name
Returns True or False
6) Install the MSA service for the Windows service and restart the service.
Be sure to include the $ sign at the end of the MSA name.
The password field must be left blank.


Check the password for the service account using the gsecdump utility


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

Requirements:

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

Enable gMSA in PowerShell
1) Verify that Microsoft Key Distribution Services is enabled
“The key distribution service uses a shared secret to create account keys. These keys change periodically. In addition to the other grouped service account attributes of the domain controller, Windows Server 2012 calculates the password for the key provided by the key distribution services. By accessing a Windows Server 2012 domain controller, Windows Server 2012 and Windows 8 sites can obtain the current and previous password. ”
2) Create a root key
The cmdlet is responsible for creating the Root Key:
Add-KdsRootKey
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 replicates.
You can run the cmdlet:
Add-KdsRootKey –EffectiveTime ((get-date) .addhours (-10))
In this case, the key will be available immediately (-10 hours to start work)
3) Create gMSA
Run cmdlet:
New-ADServiceAccount serviceaccount -DNSHostName test.test.com –PrincipalsAllowedToRetrieveManagedPassword $ test
where serviceaccount is the gMSA account name
test.test.com is the name of the server on which the root key was created
$ test - the name of the server that can contact KDS for information

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


4) Install the managed service account on the local computer
You need to run the cmdlet:
Install-ADServiceAccount -Identity serviceaccount
where serviceaccount is the gMSA account name
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 MSA account name
Returns True or False
6) Install the Windows service as gMSA and restart the service.
Be sure to include the $ sign at the end of the gMSA name .
The password field must be left blank.


Check the password for the service account using the gsecdump utility


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

You can set MSA / gMSA parameters using the Set-ADServiceAccount cmdlet
Setting the password change period:
Set-ADServiceAccount serviceaccount -ManagedPasswordIntervalInDays 60
where serviceaccount is the gMSA account name
60 - the period after which the password will change
Setting Kerberos Crypto Algorithms for MSA
Options: RC4, AES128, AES256
Set-ADServiceAccount serviceaccount -KerberosEncryptionType RC4, AES128, AES256
SPN job
Set-ADServiceAccount serviceaccount -ServicePrincipalNames @ {Add = "added SPN"}

Setting the NetBIOS name for the service (SAMAccountName)
If not specified, Name is used.
If set, the display name in AD will be from Name, and the ID for login from SAMAccountName
Set-ADServiceAccount serviceaccount –SamAccountName test

MSA is another way to improve security.