Dynamic Password Solution for Service Accounts

Dynamic Password Solution for Service Accounts

Service Accounts: -

          Service Accounts are typical User Account in AD, managing this account are quite complex then regular accounts, unlike the normal accounts this service account, have some special delegation value to perform some task on infrastructure like service, schedule task etc. with high privileges, Kerberos delegation and exception from the company password policy. Hence, the accounts do not have options to update their credentials on regular biases, if credentials manually updated by administrators, there is possibility to interrupt the respective service, so we normally do not update this credential on regular basis due to the service availability. This lead, company security threat or misplace service account credentials details. To solve this issue, Microsoft provided solution to manage such service by using MSA / gMSA.

Managed Service Accounts (MSA): -

After considering all the above challenges Microsoft has introduced Managed Service Accounts on windows server 2008 R2. However, one managed service accounts only can use with one computer. When there are operation requirements which required to share same service account in multiple hosts, MSA do not support it.

Group Managed Service Accounts (gMSA): -

Group Managed service accounts provides the same functionalities as managed service accounts, but it extends its capabilities to host the account in multiple servers. This feature has been introduced in windows server 2012. Although, gMSA is one of the Active Directory Account, the account has various feature which is currently does not have regular NETID account.

Features of Group Managed Service Accounts: -

• Automatic Password Management.
• Strong Password around 120 Characters, (MS TechNet info about the password, MSA’s, like computers, do not observe domain or fine-grained password policies. MSA’s use a complex, automatically generated password (240 bytes, which is 120 characters, and cryptographically random). MSA’s cannot be locked out and cannot perform interactive logons. Administrators can set an MSA password to a known value, although there’s ordinarily no justifiable reason).
• Password unknown to any person. 
• A single Service Account can install multiple servers. 
• Account Support Schedule Task.  
• Service Account password change every 30days during computer account password renewal. (This can be controlled – just like a computer’s password – with the following two DWORD Values:HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesNetLogonParameters

DisablePasswordChange = [0 or 1, default if value name does not exist is 0]
MaximumPasswordAge = [1-1,000,000 in days, default if value name does not exist is 30]).

• Application Automatically pick the password changes, does not required to restart service / process. 
• Automatically manage Service Principle names. 
• While configuring the service account, we don’t need password the account, instead password field can be leave as blank. The system detects its gMSA accounts.
• It uses Microsoft Key Distribution Service (KDS) to create and manage password for gMSA.

Schema Extension for gMSA: - 

Microsoft has introduced couple of new schema class for gMSA in windows server 2012, let’s have look.

• MSDS-GroupManagedServiceAccount: - its derived from computer class with five additional attributes.  
• MSDS-GroupMSAMembership: - attribute governs which computer or group of computers can retrieve gMSA password.
• MSDS-ManagedPassword:- attribute would hold current and previous password and password change interval.
• MSDS-ManagedPasswordInterval: - attribute will determines how often the gMSA password must change. 
• MSDS-ManagedPasswordID: - attribute will be used by Key distribution service (KDS) to generate current password. 
• MSDS-ManagedPasswordPreviousID: - attribute will be used to identify previous password.

Prerequisites: -

                gMSA concept to manage password dynamically, hence while service account password renewed all other domain controller must receive this update. 

• If your domain is Windows Server 2008 R2 functional level, automatic passwords and SPN management will work.
• If your domain is less than Windows Server 2008 R2 Domain Functional Level, automatic passwords will work. Automatic SPN management will not work, and SPN’s will have to be maintained by administrators
• Widows server 2012 or higher domain member servers.
• PowerShell command to manage gMSA.
• Create a KDS root key is required for the domain controller to retrieve the gMSA password when a server request it.

KDSRootKey, Provisioning, Deprovisioning and Managing gMSA.

Generate KDS Root Key: -

Create KDS root key, this is used by KDC service on domain controller to generate password.

Add-KDSrootkey -effectiveimmediately. (default 10 hours we must wait for the replication)

Add-KDSRootKey -EffectiveTime ((get-date).addhours(-10)) (the following command will take immediate effect, however for production do not use it)

Once KDS Root key created, verify the key created successfully and enabled on domain controller.

Provisioning gMSA Service Accounts: -

Before we create gMSA, define the usage of Service Account, if account has to be installed multiple servers, create Security Group gl-gMSA-WebApp in Active Directory and add the desired servers’ objects into Group.  Managing this computer over the security group would give more administrative flexibility, in my lab S-gMSA-WebApp is the service account and server1.lab.local is the FQDN of the server.

New-ADServiceAccount -name S-gMSA-WebApp -DNSHostName Server1.lab.local -PrincipalsAllowedToRetrieveManagedPassword gl-gMSA-WebApp (If we are going to install same service account on multiple servers, add servers into gl-gMSA-WebApp group to retrieve password).

Unlike the regular NETID, the service account has default container, when you create account the account will create automatically below locations.

Once the service account is created, let’s associate it with host machine, which is called Server1.

Ok, now let’s install the gMSA account in Server1, by using Install-ADServiceaccount powershell CMDlets, by default this powershell module does not available in server, hence we need Active Directory powershell module on the server.

Once powershell module has been installed, now we shall run the below command to install the service account.

Ok so for so good, lets test our account by configuring any service to validate the functionality.

This warning quite expected, once you passed account information, account will automatically be added to your local security policy Log on as service.  

If all look good, the service will accept gMSA credentials and service will move running state, wow!...

 

After you have configured service accounts, the specific service logon option would be grayed out like above. To regain control, we need to reset the service property which associates it with a managed account.

Run the below command as an administrator

SC Managedaccount ADAM_instance1 false

Once the command completed, the service log option will become previous state as regular service.

Ok, finally the service account has been fully come to production and the service moved to running state and password will be managed domain controllers.

Configuring the gMSA for Schedule task: -

              
gMSA can be also used to configure Scheduled task, however there functional limitation, the task manager does not have option to pass our gMSA account, hence we must use PowerShell CLI instead of GUI.

            Before create schedule task via powershell, we must do some prework to configure scheduled task, lets prepare.

$Action= New-ScheduledTaskAction “c:\temp\service.bat” (What action you are going to perform, for the testing purpose I am trying to restart my custom service)

$Trigger=New-ScheduledTaskTrigger -AT 22:00 -daily

$principal = New-ScheduledTaskPrincipal -userid lab\S-gMSA-WebApp$ -logontype password (the password is not actual password; Scheduled task automatically retrieve it from DC)

Now contract the variable to configure the schedule task.

 Register-ScheduledTask LDSServiceRestart -Action $Action -Trigger $trigger -principal $principal

By using the same gMSA account, I have created another task on same server, now the gMSA account has been configured as multipurpose.

Manage GMSA Password: -

When Administrator required to troubleshoot Service account, if they required to validate the account state or password consistence, how come administrator retrieve the password, typically we all know the gMSA credentials managed by Active Directory, so there is no direct way to retrieve the password in AD, let have look how to retrieve them Reference.

Delegate password Management: -

            Now you might be understood why we created Active Directory Group and granted permission to retrieve password.

Once we granted permissions to user account, now account have elevated permissions to retrieve the password.

            As discussed, schema attributes in initial post, all passwords are stored in MSDS-ManagedPasswordID. The password is serios of encrypted binary format.

Ok, lets try to decrypt the result by using DSInternals and convert them to use for human readable format.

Oh! The dsinternals retrieved the password but the password is not like our regular NETID account, lets copy the password and test the credentials.

The account successfully authenticated with the current password😊

*********Happy Learning***********

Secure Remote Desktop Connection

                       Remote Desktop Service is one of the best features, to Administrate the server via remotely for IT administrators and developers to perform their day to day activity. However, while login the server remotely, we are using our High privileged accounts. When there is attack on server, there is possibility to lose our credentials.

                    Microsoft offer a new solution RestrictedAdmin mode, it has been introduced on Windows server 2012 R2 onwards, and it was designed to help protect administrator accounts by ensuring that reusable credentials are not stored in memory on the remote server or computer. This includes scenarios when server administrators use admin credentials for remote PC support or when domain admin accounts are used to connect remotely to member servers. Their credentials will not be available, for any malicious or malware to attack. 

How Typical RDP process works:

            By default, Remote Desktop is using Remote Interactive logon process to authenticate: while RDP to the server, the user’s credentials are sent (over a secure channel) to the remote device and if the login successful then the user can access the remote desktop.

Once User RDP the server, the server will register successful logon event with Logon type: 10 (Type 10 means Remote Interactive logon).

If you check the server cached credentials, you could see the NTLM hash on the memory. Even if we leave the server and our session become stale, the hash won’t leave the server. Rebooting the target device after use is the only way to ensure that credentials from stale or leaked logon sessions are removed completely from memory.

How RestrictedAdmin RDP connection works:

Microsoft introduced new feature restrictedadmin from window server 2012 R2 onwards. Using restrictedadmin mode, RDP is using a network logon process, instead of remote interactive. Using network logon ensures that the user’s credentials are never sent to the target device, therefore they are not available for theft.

To use restrictedadmin mode the remote target, need to support it and the below switch will take to the restrictedadmin console. 

mstsc /v:<server name> /restirctedAdmin

A view from the security event log after using restirctedAdmin switch:

And now if we capture the Server credentials dump, system reveals that the user token is there, but it’s populated with the target device computer account details!

When we are trying to access other network resources while connected to the remote session we can see “access denied” errors, and that’s because we are authenticating (and try to access resources) using the computer account, not the user account.

Restricted admin is disabled by default, and you need to explicitly add the switch /restrictedAdmin to mstsc command line and enable it on the target device.

 Remote Credential Guard

Remote Credential Guard enables you to protect your privileged credentials and access network resources from within the remote session.

To use the remote Credential Guard mode the remote target, and you need to use the following command line:

mstsc /v:<server name> /remoteguard

Windows Defender Remote Credential Guard blocks NTLM (allowing only Kerberos), prevents Pass-the-Hash (PtH) attacks, and prevents use of credentials after disconnection.

Comparison between Remote Desktop security modes:

Pre Requires for Client Computers:

When we are trying to open RDP on client computer to perform remote administration, by default RDP connection will initialize. So, if we want to force Client RDP request to use /RestrictedAdmin mode, enable the below GPO to enforce the settings.

GPO setting is located under the Administrative Templates under Computer Configuration > System > Credential Delegation > Restrict delegation of credentials to remote servers. Enable the Policy.

How to Enable RDP on Target Server:

Once client initializes the secure RDP session, our target device should accept the request, in which the below registry key must be pushed to the servers. Either manually or GPO.

Browse to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa
Add Registry Key DisableRestrictedAdmin Type: REG_DWORD Value: 0

Limitation of Secure RDP session:

Rstrictedadmin mode you can’t connect to other network resources as its not passing the credentials.

Ref: The below Article help us to compare all RDP sessions feature and implementations. Please have them check to understand more about the Secure RDP.

https://docs.microsoft.com/en-us/windows/security/identity-protection/remote-credential-guard#helpdesk

https://blogs.technet.microsoft.com/motiba/2017/09/21/securing-remote-connections/

https://social.technet.microsoft.com/wiki/contents/articles/32905.remote-desktop-services-enable-restricted-admin-mode.aspx

**********************Happy Learning********************

Secure Your Privilege Account by using Authentication Policy and Silo

Secure Your Privilege Account by using Authentication Policy and Silo

As discussed, previous post the protected user group is one of the great features in 2012 R2, to improve privilege account security and provide better protection against legacy protocol and enforce privilege accounts to use newer Kerberos protocol and play well against credentials caching. Protected Users group has a pre-defined scope, what if I wanted to change the configuration.  

for example, the default TGT lifetime about 4 hours, what if we wanted to customize them based on my company policy. Adding Service Accounts & Computer Accounts in protected user group is not advisable and it may lead the authentication failure, what if I wanted to improve security for service and computer account.

Authentication Policy and Authentication Silo is another way to secure an Active Directory based environment. This provides a more robust method, beyond configuring logon restrictions, and

restricting which accounts can access specific servers in your environment. Protected Users group has a Pre-defined scope, where as authentication policy and silo do not.

Authentication Policy and Silos:

Authentication Polices and authentication policies Silo leverage the existing Windows authentication infrastructure and the use of the NTLM protocol is rejected, and the Kerberos protocol with newer encryption types is used.

In contrast to the limited Log on to: previous versions of Windows. By using Authentication Policies and Authentication Policy Silos you can create a group of computers to which a (group of) user(s) can log on to.

Authentication policies allow you to configure settings, such as TGT lifetime and access control conditions, which specify conditions that must be met before a user can sign in to a computer. For example, you might configure an authentication policy that specifies a TGT lifetime of 120 minutes and limit a user account so that users can only use it with specific devices.

Authentication policies are enforced during the Kerberos protocol authentication service (AS) or ticket-granting service (TGS) exchange.

The cool thing about Authentication Policies and Authentication Policy Silos, is that unless computer or user account objects meet the criteria in the rules, a Ticket Granting Ticket (TGT) will not be issued. At all.

The combination of Authentication policies and the Protected Users security group by providing a way to apply configurable restrictions to user, services and computers accounts.

You configure Authentication Policies and Authentication Policy Silos using

Active Directory Administrative Center or powershell.

How the Kerberos protocol is used with authentication policy silos and policies

I referred the below article to understand this new feature, please read them, it would help us to understand how the policy will enforce while login user account into device.

https://github.com/MicrosoftDocs/windowsserverdocs/blob/master/WindowsServerDocs/identity/ad-ds/manage/How-to-Configure-Protected-Accounts.md

https://docs.microsoft.com/en-us/windows-server/security/credentials-protection-and-management/authentication-policies-and-authentication-policy-silos

https://dirteam.com/sander/2014/12/23/new-features-in-active-directory-domain-services-in-windows-server-2012-r2-part-3-authentication-policies-and-authentication-policy-silos/

When a domain account is linked to an authentication policy silo, and the user signs in, the Security Accounts Manager adds the claim type of Authentication Policy Silo that includes the silo as the value. This claim on the account provides the access to the targeted silo.

When an authentication policy is enforced and the authentication service request for a domain account is received on the domain controller, the domain controller returns a non-renewable TGT with the configured lifetime.

When an authentication policy is enforced and the authentication service is armored, the authentication service request for a domain account is received on the domain controller, the domain controller checks if authentication is allowed for the device. If it fails, the domain controller returns an error message and logs an event.

You can use a single authentication policy for all members of a silo, or you can use separate policies for users, computers, and managed service accounts.

Prerequisites:

Ø  All domain controllers in the domain must be based on Windows Server 2012 R2 and above.

Ø  The domain functional level must be Windows Server 2012 R2 and above.

Ø  Domain controllers must be configured to support Dynamic Access Control.

Ø  Windows 8, Windows 8.1, Windows Server 2012, and Windows Server 2012 R2 domain members must be configured to support DAC, including Kerberos compound claims (device claims)

Let’s Setup Policy for Domain Admins and Enforce them to use only domain controllers.

Prerequires to setup Authentication Policy and Authentication Silo.

Step 1: Before Authentication policy creation, our domain controller should support claims and compound authentication for Dynamic Access Control and Kerberos armoring, do this by enabling the following group policy setting on “Default Domain Controller” policy.

Expand out the following location, Computer Configuration\Policies\Administrative Templates\System\KDC and Enable the below policy.

Step 2: Configure the client computers to request claims, provide information required to create compounded authentication and armor Kerberos messages.

This setting will need to be enabled on the client systems in the domain, hence I enabled this policy on “Default Domain Policy” on following location, Computer Configuration\Policies\Administrative Templates\System\Kerberos

So, all the prerequisites are set, now we will setup Authentication Policy and Authentication policy Silo.

Setup Authentication Policy and Silo

Step 1:

Open Active Directory Administration Center and you could see there is two new containers Authentication Polices and Authentication policy Silo.

Note: You can create Authentication Policy without Silo; however, you cannot create Authentication policy Silo without Authentication Policy.

Authentication Policy: An Authentication Policy defines TGT Lifetime, and Authentication Access Control Conditions.

Authentication Policy Silo: An authentication policy silo controls which accounts can be restricted by the silo and defines the authentication policies to apply to the members.

Step 2:  Create Authentication Polices

     Use appropriate name while configuring Policy Name which you want to set and update description fields and define the rules. 

I have restricted my Domain Admins TGT value 120 minutes.

Step 3: Create Authentication Policy Silos

Use appropriate Name while configuring Policy Name with respective of their role and fill the description.

Apply the Authentication Policy, which we created in a previous step 2.

OK now time to add our domain admins accounts and domain controller we wish to allow them for access.

We added our domain admins and domain controllers, however the policy not yet assigned to those objects. See the above screenshot Assigned and we don’t see any policy pushed yet.

Step 4: Let’s push the policy:

Select each object and double click and assign Authentication Policy Silos which we create now.

And repeat the same step for Computer Account also.

Good to see now our policy has been assigned to both objects.

Step 5: Enable Access Control conditions

                              Ok now all set, there is final step to complete the configuration. Create Access Control condition, where we created our authentication policy “Restrict DomainAdmins” under the User Sign on section, specify access control conditions that restrict devices that can request a Ticket Granting Ticket for the user accounts assigned to this policy.

Specify Access Control condition below.

Validate the Configuration.

1)     Login domain controller by using PA-User1 and check TGT Lifetime.

By using PA-User1, I can login Domain Controller DC1 and my TGT life time is default 10 hours.

2)     Login domain controller by using PA-User2 and check TGT Lifetime.

In contrast, when I login the DC1, by using PA-User2, my TGT lifetime is shorter and it only 2 hours. 

3)     Login PA-User2 one of the member server.

When a user assigned an authentication policy attempts to log on to a machine to which he/she is

not allowed access, the attempt fails with the following error will occur.

The DC will register corresponding event log below.

*************Happy Learning*******************