SSL Decryption: Hidden Threats no More

Why decrypt network traffic?

PREVIOUS      NEXT

SSL Decryption: Hidden Threats no More

Why decrypt network traffic?

More and more traffic is being encrypted. For this reason, for the firewall to inspect all traffic, it must also decrypt it due to high visibility, control, and protection at the highest levels.

SSL uses symmetric and asymmetric encryption.

  1. The client requires an SSL connection
  2. The server responds to the request by sending its certificate containing its identity and public key
  3. The client checks the certificate by looking for it in the list of known certificates. (PKI)
  4. The client generates a random symmetric key and encrypts it using the server’s public key.
  5. The server uses its private key to decrypt the session key (from step 4).

Types of decryption on Palo Alto Firewall

Palo Alto allows 3 types of decryption:

o SSL Forward Proxy

o SSL Inbound Inspection

o SSL Decryption

 

SSL Forward Proxy

 

SSL Forward Proxy decrypts SSL traffic between a host on your network and a server on the Internet. In this scenario, Palo Alto acts as an SSL Proxy that establishes a connection between your host and Palo Alto and separates (but logically related) communication between Palo Alto and the server on the Internet.

An example in which this type of encryption is helpful is when you allow employees in your network to read the Twitter line in your policies in Palo Alto. Still, you want to prohibit them from sending messages and posting content (tweeting). If SSL decryption is enabled, Palo Alto will easily distinguish within the policy whether Twitter traffic belongs to “reading,” “commenting,” or “chatting” and, based on that, defend or allow traffic. If encryption is not enabled, Palo Alto cannot know what type of application is within the SSL connection.

 

SSL Inbound Inspection

 

SSL Inbound Inspection decrypts traffic coming from external users to your internal services. For this decryption, you must have a server private key and certificate. In this scenario, Palo Alto does not act as a proxy but directly forwards the request to the internal server. For that reason, you need the previously mentioned certificates because the connection is formed directly between the host and the server. Security policies are accepted for traffic so that the firewall can block or allow traffic between the host on the public network and your internal server.

 

SSH Decryption

 

SSH Decryption is used to detect and decrypt incoming and outgoing SSH traffic. If an SSH tunnel is detected, the SSH connection is blocked not to be used to tunnel unauthorized applications and other content.

 

Proxy

 

A proxy is an intermediary in communication between a client and a server. The proxy takes the package from the client and recreates it again towards the client. In the case of encrypted communication, a proxy receives an SSL request from a client and instead sends it to a server on the Internet. The same response is downloaded from the proxy server and sent back to the client in the reverse direction. It provides encrypted communication between the client and the proxy and the proxy and server on the Internet.

 

PKI (Public Key Infrastructure)

 

PKI solves the problems of secure identification of the public key, using a digital certificate to verify the public key owner. You can see the components of PKI in the picture below:

 

 

 

PKI is a set of hardware, software, policies, and standards used to create, manage, distribute a certificate. All this is necessary for the certificate holder to publicly confirm that he/she is what he/she pretends to be.

Root CA (Certified Authority) is the supreme Authority and provides services that authenticate devices, services, people by issuing a certificate that confirms their identity and public key.

The Root CA authorizes the Intermediate CA to certify or authorize other lower CAs. Each CA has a database with active certificates, revoked certificates, issued certificates, etc.

On the side of end devices, the devices are themselves that keep the certificates issued to them and the private key. Users refresh the certificate database themselves or with the help of software. If CA’s certificate is not in the user’s database, it will receive an unreliable warning message about the site they are visiting.

 

Configuring decryption

  1. Create 2 self-signed certificates (trusted and untrusted)
  2. Export the trusted certificate and import it to the end-user (computer)
  3. Create a decryption profile (optional)
  4. Create a decryption policy
  5. Check if the traffic is decrypted

 

  1. Creating self-signed certificates

Device> Certificate Management> Certificates> Generate

 

The image below shows the steps to create a self-signed trusted certificate

 

 

The image below shows the steps to create a self-signed untrusted certificate

 

 

  1. Export of self-signed trusted certificate and installation on a client

The image below shows the steps to export a self-signed trusted certificate

 

 

The image below shows the steps to install a self-signed trusted certificate on a client

 

 

 

 

 

 

 

 

  1. Create a decryption profile

Object> Decryption> Decryption Profile> Add

The image below shows the steps to create a decryption profile. The decryption profile serves to let the firewall know how to treat the traffic being decrypted.

 

 

  1. Creating a decryption policy

Policies> Decryption> Add

The image below shows the steps for creating a decryption policy. The policy determines which traffic will be decrypted. The name, source and destination zone, and traffic action (No Decrypt or Decrypt) are defined.

 

 

 

Defining the source of the traffic to be decrypted

 

 

 

Defining the destination to which the decrypted traffic is going

 

 

Defining the type of services.

 

 

Defining the action to be applied to the decrypted traffic as well as the type of decryption and the decryption profile.

 

Find and check decrypted traffic in the log section.

PREVIOUS      NEXT

Before you continue...
Subscribe to our monthly content digest and stay up-to-date on everything industry related!

SSL Decryption: Hidden Threats no More

Why decrypt network traffic?

PREVIOUS      NEXT

SSL Decryption: Hidden Threats no More

Why decrypt network traffic?

More and more traffic is being encrypted. For this reason, for the firewall to inspect all traffic, it must also decrypt it due to high visibility, control, and protection at the highest levels.

SSL uses symmetric and asymmetric encryption.

  1. The client requires an SSL connection
  2. The server responds to the request by sending its certificate containing its identity and public key
  3. The client checks the certificate by looking for it in the list of known certificates. (PKI)
  4. The client generates a random symmetric key and encrypts it using the server’s public key.
  5. The server uses its private key to decrypt the session key (from step 4).

Types of decryption on Palo Alto Firewall

Palo Alto allows 3 types of decryption:

o SSL Forward Proxy

o SSL Inbound Inspection

o SSL Decryption

 

SSL Forward Proxy

 

SSL Forward Proxy decrypts SSL traffic between a host on your network and a server on the Internet. In this scenario, Palo Alto acts as an SSL Proxy that establishes a connection between your host and Palo Alto and separates (but logically related) communication between Palo Alto and the server on the Internet.

An example in which this type of encryption is helpful is when you allow employees in your network to read the Twitter line in your policies in Palo Alto. Still, you want to prohibit them from sending messages and posting content (tweeting). If SSL decryption is enabled, Palo Alto will easily distinguish within the policy whether Twitter traffic belongs to “reading,” “commenting,” or “chatting” and, based on that, defend or allow traffic. If encryption is not enabled, Palo Alto cannot know what type of application is within the SSL connection.

 

SSL Inbound Inspection

 

SSL Inbound Inspection decrypts traffic coming from external users to your internal services. For this decryption, you must have a server private key and certificate. In this scenario, Palo Alto does not act as a proxy but directly forwards the request to the internal server. For that reason, you need the previously mentioned certificates because the connection is formed directly between the host and the server. Security policies are accepted for traffic so that the firewall can block or allow traffic between the host on the public network and your internal server.

 

SSH Decryption

 

SSH Decryption is used to detect and decrypt incoming and outgoing SSH traffic. If an SSH tunnel is detected, the SSH connection is blocked not to be used to tunnel unauthorized applications and other content.

 

Proxy

 

A proxy is an intermediary in communication between a client and a server. The proxy takes the package from the client and recreates it again towards the client. In the case of encrypted communication, a proxy receives an SSL request from a client and instead sends it to a server on the Internet. The same response is downloaded from the proxy server and sent back to the client in the reverse direction. It provides encrypted communication between the client and the proxy and the proxy and server on the Internet.

 

PKI (Public Key Infrastructure)

 

PKI solves the problems of secure identification of the public key, using a digital certificate to verify the public key owner. You can see the components of PKI in the picture below:

 

 

 

PKI is a set of hardware, software, policies, and standards used to create, manage, distribute a certificate. All this is necessary for the certificate holder to publicly confirm that he/she is what he/she pretends to be.

Root CA (Certified Authority) is the supreme Authority and provides services that authenticate devices, services, people by issuing a certificate that confirms their identity and public key.

The Root CA authorizes the Intermediate CA to certify or authorize other lower CAs. Each CA has a database with active certificates, revoked certificates, issued certificates, etc.

On the side of end devices, the devices are themselves that keep the certificates issued to them and the private key. Users refresh the certificate database themselves or with the help of software. If CA’s certificate is not in the user’s database, it will receive an unreliable warning message about the site they are visiting.

 

Configuring decryption

  1. Create 2 self-signed certificates (trusted and untrusted)
  2. Export the trusted certificate and import it to the end-user (computer)
  3. Create a decryption profile (optional)
  4. Create a decryption policy
  5. Check if the traffic is decrypted

 

  1. Creating self-signed certificates

Device> Certificate Management> Certificates> Generate

 

The image below shows the steps to create a self-signed trusted certificate

 

 

The image below shows the steps to create a self-signed untrusted certificate

 

 

  1. Export of self-signed trusted certificate and installation on a client

The image below shows the steps to export a self-signed trusted certificate

 

 

The image below shows the steps to install a self-signed trusted certificate on a client

 

 

 

 

 

 

 

 

  1. Create a decryption profile

Object> Decryption> Decryption Profile> Add

The image below shows the steps to create a decryption profile. The decryption profile serves to let the firewall know how to treat the traffic being decrypted.

 

 

  1. Creating a decryption policy

Policies> Decryption> Add

The image below shows the steps for creating a decryption policy. The policy determines which traffic will be decrypted. The name, source and destination zone, and traffic action (No Decrypt or Decrypt) are defined.

 

 

 

Defining the source of the traffic to be decrypted

 

 

 

Defining the destination to which the decrypted traffic is going

 

 

Defining the type of services.

 

 

Defining the action to be applied to the decrypted traffic as well as the type of decryption and the decryption profile.

 

Find and check decrypted traffic in the log section.

PREVIOUS      NEXT

Before you continue...
Subscribe to our monthly content digest and stay up-to-date on everything industry related!

Cost of having it easier – is it worth it?

Microsoft Local Administrator Password Solution - LAPS

PREVIOUS      NEXT

Cost of having it easier – is it worth it?

Microsoft Local Administrator Password Solution - LAPS

Recognizing the problem

In most companies, there is a serious flaw that could compromise IT infrastructure easier than you think…

When you install a fresh copy of Windows 10, you probably noticed that the local Administrator account is disabled by default. Do you know why it is like that?
Maybe someone gave you the task to manage passwords for local accounts on domain computers using GPO, but you noticed that option is greyed out. Is it disabled by purpose? For the same reason?

Yes. It is.

 

People with bad intentions (at least for you), let us call them Hackers, found a significant flaw in the GPO password distribution process. Although Windows encrypted the distributed password, Microsoft released the encryption key in their technical documentation, so finding out the password was a child’s play.
Microsoft recognized this huge vulnerability and decided to disable the option to set a password in GPO, but if you already have and use this policy, it still works. You are just unable to change it anymore…

But why did Microsoft disabled the built-in administrator account by default?
Although the built-in administrator is disabled by default, it is still widely used in IT organizations.
How does this happen, and why?

Every computer in your company needs a local administrator account.
This local administrator account is mostly irrelevant to managing workstations and servers within an enterprise environment, because the right thing to do (which you probably already did) in the enterprise environment is to set up domain-level groups with restricted privileges under the local Administrators group, but… If your computer does not connect to any domain controller (for numerous reasons), or maybe your network is down, a local administrator account is necessary.
In that case, it will be used by administrators or technicians from the Help desk to access workstations and servers and resolve any issues.

Since administrators and Help desk technicians need to maintain many computers, it is easier and more convenient for them to have the same account and password on every one of them.
Also, most companies deploy Windows client OS on workstations for the first time as a copy of the Windows 10 image. Administrators often re-enable local administrators in Windows 10 because they need local access to their computers in the event of a disaster. If they configure their Windows 10 computers with an image where the local administrator account is enabled, then every computer provisioned via that image will have the same credentials.

In short, one password can be used to access every workstation.
For convenience and ease of use (more often than not), they have been given easily guessable passwords, and sometimes, that same password is used across large parts of the domain.

The fact that every computer in your network can be accessed with the same username and password is discoverable to a malicious user or attacker.
Using their local SAM account or tools such as mimikatz or impacket, an attacker or malicious user could discover their own local administrator password. Since many attackers know about this potential vulnerability, it will not take them long to try the password on every other computer in your network.
Infecting and compromising only one workstation, stealing that unique password is all they need to access everything. I mean EVERYTHING!

As things start to happen in front of your eyes, and you see the damage being done, you realize the true cost of having it easy…

 

The nightmare unfolds

 

That attack looks something like this:

  1. Attacker targets workstations simultaneously, all at once.
  2. User running as local admin compromised, attacker harvests credentials.
  3. Attacker starts “credentials crabwalk.”
  4. Attacker finds host with domain privileged credentials, steals them, and elevates privileges.
  5. Attacker owns the network. Now he can harvest whatever he wants.
  6. You realize that you can’t wake up from this nightmare…

 

 

Even if the local administrator is disabled for network operations and local administrators can be used only when accessing the local machine directly, it is still a significant security risk. Attackers will use this vulnerability for privilege escalation. They simply log in with any other account remotely and then “run as” the local administrator to gain administrative privileges.

 

Preventing this from happening. How hard can it be?

 

Keeping the local administrator account secure requires a lot of maintenance. It doesn’t matter which approach you take.
The system administrators must ensure that passwords are unique on every computer object, not to be too simple, obvious, or reused anywhere else. It also needs to be applied after deploying machines from a template or when you deploy them manually.
Backsliding is very easy and likely to happen.
Reusing the same passwords is so much easier from a maintenance perspective that people forget about the security angle.
Discovering the problematic computers is an issue on its own… If you have hundreds or thousands of computer objects in your organization, some might have weak, reused passwords, and some don’t. It is most likely the case since machines are probably deployed over a significant period in batches and by different people.

 

Here is how to avoid it.

 

The obvious way to avoid problems with the local administrator is to disable it entirely, but that leads you to other issues, in cases such as when the network becomes unavailable.

You could also create a unique password for every workstation/server. It may be a sisyphean task, especially if you have hundreds or thousands of computers.

Fortunately, Microsoft released a tool that will create random local administrator passwords using the GPO and then store them encrypted in Active Directory.
Hackers and malicious users can still steal credentials, but it would take a lot, A LOT more work to compromise workstations or servers.

 

Having it easy, but at the same time secure? It’s possible!

 

Here is an overview of the solution:

 

 

    • Local admin passwords are stored encrypted in Active Directory.
    • Computer accounts can only write passwords. They cannot read them (in case it gets compromised).
    • The solution addresses only local accounts.
    • Single installer contains:
      • Group Policy Client Side Extension (CSE)
      • ADM/ADMX templates for GPO management
      • Powershell module
      • Password Decryption Service (PDS)
      • Fat client UI for reading/resetting passwords

The core of the LAPS solution is a GPO client-side extension (CSE) that performs the following tasks and can enforce the following actions during a GPO update:

    • Checks whether the password of the local Administrator account has expired.
    • Generates a new password when the old password is expired or required to be changed before expiration.
    • Validates the new password against the password policy.
    • Reports the password to Active Directory, storing it with a confidential attribute with the computer account in Active Directory.
    • Reports the next expiration time for the password to Active Directory, storing it with an attribute with the computer account in Active Directory.
    • Changes the password of the Administrator account.

The password then can be read from Active Directory by users who are allowed to do so. Eligible users can request a password change for a computer.

 

Installation

 

  • On dedicated LAPS management server, install all available options presented in the install file:
    • GPO extension, so computer objects could be managed by LAPS.
    • Fat client UI to view passwords.
    • Powershell module for completing and configuring the solution.
    • GPO templates for configuring LAPS settings in AD GPO.
    • PDS service.
AD preparation

Extending AD schema is required since the three new attributes are added:

    • ms-MCS-AdmPwd (stores the built-in local administrator password in an encrypted way)
    • ms-MCS-AdmPwdExpirationTime (stores the time to reset the password)
    • ms-MCS-AdmPwdHistory (needed in case of restoring a backup)

It is executed with two commands (must be Schema Admin to run them) and my advice to you is to test AD replication and make sure it works without any issues before executing commands:

Import-module AdmPwd.PS – imports the modules for LAPS management.
Update-AdmPwdADSchema – extend the schema for the new attributes.

 

Delegation of permissions

Three roles need to be implemented:

Password Decryption Service role – has permission to interact with AD directly
Password Reader role – has permission to read admin passwords via PDS
Password Reset role – has permission to reset admin passwords via PDS

The best practice is to implement those roles by AD groups, so three types of groups need to be created and membership populated.

 

Service account permissions:

Managed machines access Active Directory using special well-known account SELF, so necessary permissions must be added to the SELF well-known account. It is required to update the password and expiration timestamp of its own built-in Administrator password on its own computer accounts in AD.
PowerShell cmdlet for granting permissions to the Password decryption service to read and write information to Active Directory:
Set-AdmPwdServiceAccountPermission –Identity <name of the OU to delegate permissions> -AllowedPrincipals <name of Password Decryption Group>

 

Self-permissions:

Managed machines access Active Directory using special well-known account SELF, so necessary permissions must be added to the SELF well-known account. It is required so the machine can update the password and expiration timestamp of its own built-in Administrator password on its own computer accounts in AD.
Set-AdmPwdComputerSelfPermission -Identity <name of the OU to delegate permissions>

 

User Rights to read passwords:

Add the extended permission Read Local Admin Password to the group that will be allowed to read the local administrator’s password for managed computers. It is done using PowerShell.  You may need to run Import-module AdmPwd.PS if this is a new window.
Set-AdmPwdReadPasswordPermission -Identity <name of the OU to delegate permissions> -AllowedPrincipals <name of Password Readers Group>

 

User Rights to reset passwords:

Add the extended permission Reset Local Admin Password to the group that will be allowed to reset the local admin account’s password for managed computers.  It is done using PowerShell.  You may need to run Import-module AdmPwd.PS if this is a new window.
Set-AdmPwdResetPasswordPermission
-Identity <name of the OU to delegate permissions> -AllowedPrincipals <name of Password Resetters Group>

 

PDS Server installation

 

PDS is responsible for creating and maintaining key pairs used for password encryption and decryption, communication with the Active Directory, auditing of requests of users for password reads/resets, and registration/maintenance of DNS SRV record used for discovery of service by clients.
Password Decryption Service is thus handling some interactions with AD infrastructure.
Computers do not directly read from Active Directory; they only directly write. Password Decryption Service maintains the decryption keys and is responsible for password reads, decrypts, and password resets.

 

Key pair

To store encrypted passwords in Active Directory, a key pair must be created. For security, only the Key Admin role can generate a new key pair. (By default, the Key Admin role is defined as an Enterprise Admin).

Keypairs are generated using PowerShell.  Upon request to create keys, two files will be made in the configured location:

One file contains a public key, and it should be distributed to managed machines via GPO
One file contains a private key and is used by the Password Decryption machine(s)

New-AdmPwdKeyPair -KeySize <Keysize of 1024, 2048 or 4096>
Get-AdmPwdPublicKey

Keys are stored in C:\Program Files\AdmPwd\Svc\CryptoKeyStorage.

 

Group policy settings

 

Group Policy is used to enable the local admin password solution and to configure various settings.
For GPO maintenance, the ADMX template needs to be installed on the machine on which Group Policy Management Console (GPMC) is running.
In GPO UI, all configuration settings related to CSE configuration are located under “Computer configuration/Policies/Administrative Templates/AdmPwd/Managed Clients” path.

Following configuration values are supported:

 

 

Auditing

 

 

The Password Decryption Service (PDS) logs its activity into a dedicated Windows Event log.
Auditing for users who query for a computer’s local administrator password can be accomplished by reviewing the LAPS Service Event log located under Applications and Services Logs.

 

Client installation

 

Installing CSE does not initiate the management of the password. GPO settings must be enabled for password management.
For the GPO to be applied on Servers or Workstations and LAPS solution to work, each managed computer should be installed LAPS client.
These can be installed/updated/uninstalled on clients using various methods, including the software Installation feature of Group Policy, SCCM, login script, manual install, etc.

 

Using LAPS to retrieve password

 

To retrieve a computer object’s password, all you need to do is install “Fat client UI” on workstation you use to administer your infrastructure and select the computer object for which you need the local admin password retrieved.

 

Conclusion

 

As always, recognizing the problem is the first step in resolving it.
Ignoring it could have enormous, potentially unrecoverable consequences.

Security in IT is always about compromises. Searching for that thin line that separates ease of use, comfort, and improved security.

Luckily, Microsoft created the solution for a scenario described in this post, which favors ease of use in large organizations while equally improving its security.

People with bad intentions won’t be able to take advantage of you… At least, not that easily…

 

PREVIOUS      NEXT

Before you continue...
Subscribe to our monthly content digest and stay up-to-date on everything industry related!

Cost of having it easier – is it worth it?

Microsoft Local Administrator Password Solution - LAPS

PREVIOUS      NEXT

Cost of having it easier – is it worth it?

Microsoft Local Administrator Password Solution - LAPS

Recognizing the problem

In most companies, there is a serious flaw that could compromise IT infrastructure easier than you think…

When you install a fresh copy of Windows 10, you probably noticed that the local Administrator account is disabled by default. Do you know why it is like that?
Maybe someone gave you the task to manage passwords for local accounts on domain computers using GPO, but you noticed that option is greyed out. Is it disabled by purpose? For the same reason?

Yes. It is.

 

People with bad intentions (at least for you), let us call them Hackers, found a significant flaw in the GPO password distribution process. Although Windows encrypted the distributed password, Microsoft released the encryption key in their technical documentation, so finding out the password was a child’s play.
Microsoft recognized this huge vulnerability and decided to disable the option to set a password in GPO, but if you already have and use this policy, it still works. You are just unable to change it anymore…

But why did Microsoft disabled the built-in administrator account by default?
Although the built-in administrator is disabled by default, it is still widely used in IT organizations.
How does this happen, and why?

Every computer in your company needs a local administrator account.
This local administrator account is mostly irrelevant to managing workstations and servers within an enterprise environment, because the right thing to do (which you probably already did) in the enterprise environment is to set up domain-level groups with restricted privileges under the local Administrators group, but… If your computer does not connect to any domain controller (for numerous reasons), or maybe your network is down, a local administrator account is necessary.
In that case, it will be used by administrators or technicians from the Help desk to access workstations and servers and resolve any issues.

Since administrators and Help desk technicians need to maintain many computers, it is easier and more convenient for them to have the same account and password on every one of them.
Also, most companies deploy Windows client OS on workstations for the first time as a copy of the Windows 10 image. Administrators often re-enable local administrators in Windows 10 because they need local access to their computers in the event of a disaster. If they configure their Windows 10 computers with an image where the local administrator account is enabled, then every computer provisioned via that image will have the same credentials.

In short, one password can be used to access every workstation.
For convenience and ease of use (more often than not), they have been given easily guessable passwords, and sometimes, that same password is used across large parts of the domain.

The fact that every computer in your network can be accessed with the same username and password is discoverable to a malicious user or attacker.
Using their local SAM account or tools such as mimikatz or impacket, an attacker or malicious user could discover their own local administrator password. Since many attackers know about this potential vulnerability, it will not take them long to try the password on every other computer in your network.
Infecting and compromising only one workstation, stealing that unique password is all they need to access everything. I mean EVERYTHING!

As things start to happen in front of your eyes, and you see the damage being done, you realize the true cost of having it easy…

 

The nightmare unfolds

 

That attack looks something like this:

  1. Attacker targets workstations simultaneously, all at once.
  2. User running as local admin compromised, attacker harvests credentials.
  3. Attacker starts “credentials crabwalk.”
  4. Attacker finds host with domain privileged credentials, steals them, and elevates privileges.
  5. Attacker owns the network. Now he can harvest whatever he wants.
  6. You realize that you can’t wake up from this nightmare…

 

 

Even if the local administrator is disabled for network operations and local administrators can be used only when accessing the local machine directly, it is still a significant security risk. Attackers will use this vulnerability for privilege escalation. They simply log in with any other account remotely and then “run as” the local administrator to gain administrative privileges.

 

Preventing this from happening. How hard can it be?

 

Keeping the local administrator account secure requires a lot of maintenance. It doesn’t matter which approach you take.
The system administrators must ensure that passwords are unique on every computer object, not to be too simple, obvious, or reused anywhere else. It also needs to be applied after deploying machines from a template or when you deploy them manually.
Backsliding is very easy and likely to happen.
Reusing the same passwords is so much easier from a maintenance perspective that people forget about the security angle.
Discovering the problematic computers is an issue on its own… If you have hundreds or thousands of computer objects in your organization, some might have weak, reused passwords, and some don’t. It is most likely the case since machines are probably deployed over a significant period in batches and by different people.

 

Here is how to avoid it.

 

The obvious way to avoid problems with the local administrator is to disable it entirely, but that leads you to other issues, in cases such as when the network becomes unavailable.

You could also create a unique password for every workstation/server. It may be a sisyphean task, especially if you have hundreds or thousands of computers.

Fortunately, Microsoft released a tool that will create random local administrator passwords using the GPO and then store them encrypted in Active Directory.
Hackers and malicious users can still steal credentials, but it would take a lot, A LOT more work to compromise workstations or servers.

 

Having it easy, but at the same time secure? It’s possible!

 

Here is an overview of the solution:

 

 

    • Local admin passwords are stored encrypted in Active Directory.
    • Computer accounts can only write passwords. They cannot read them (in case it gets compromised).
    • The solution addresses only local accounts.
    • Single installer contains:
      • Group Policy Client Side Extension (CSE)
      • ADM/ADMX templates for GPO management
      • Powershell module
      • Password Decryption Service (PDS)
      • Fat client UI for reading/resetting passwords

The core of the LAPS solution is a GPO client-side extension (CSE) that performs the following tasks and can enforce the following actions during a GPO update:

    • Checks whether the password of the local Administrator account has expired.
    • Generates a new password when the old password is expired or required to be changed before expiration.
    • Validates the new password against the password policy.
    • Reports the password to Active Directory, storing it with a confidential attribute with the computer account in Active Directory.
    • Reports the next expiration time for the password to Active Directory, storing it with an attribute with the computer account in Active Directory.
    • Changes the password of the Administrator account.

The password then can be read from Active Directory by users who are allowed to do so. Eligible users can request a password change for a computer.

 

Installation

 

  • On dedicated LAPS management server, install all available options presented in the install file:
    • GPO extension, so computer objects could be managed by LAPS.
    • Fat client UI to view passwords.
    • Powershell module for completing and configuring the solution.
    • GPO templates for configuring LAPS settings in AD GPO.
    • PDS service.
AD preparation

Extending AD schema is required since the three new attributes are added:

    • ms-MCS-AdmPwd (stores the built-in local administrator password in an encrypted way)
    • ms-MCS-AdmPwdExpirationTime (stores the time to reset the password)
    • ms-MCS-AdmPwdHistory (needed in case of restoring a backup)

It is executed with two commands (must be Schema Admin to run them) and my advice to you is to test AD replication and make sure it works without any issues before executing commands:

Import-module AdmPwd.PS – imports the modules for LAPS management.
Update-AdmPwdADSchema – extend the schema for the new attributes.

 

Delegation of permissions

Three roles need to be implemented:

Password Decryption Service role – has permission to interact with AD directly
Password Reader role – has permission to read admin passwords via PDS
Password Reset role – has permission to reset admin passwords via PDS

The best practice is to implement those roles by AD groups, so three types of groups need to be created and membership populated.

 

Service account permissions:

Managed machines access Active Directory using special well-known account SELF, so necessary permissions must be added to the SELF well-known account. It is required to update the password and expiration timestamp of its own built-in Administrator password on its own computer accounts in AD.
PowerShell cmdlet for granting permissions to the Password decryption service to read and write information to Active Directory:
Set-AdmPwdServiceAccountPermission –Identity <name of the OU to delegate permissions> -AllowedPrincipals <name of Password Decryption Group>

 

Self-permissions:

Managed machines access Active Directory using special well-known account SELF, so necessary permissions must be added to the SELF well-known account. It is required so the machine can update the password and expiration timestamp of its own built-in Administrator password on its own computer accounts in AD.
Set-AdmPwdComputerSelfPermission -Identity <name of the OU to delegate permissions>

 

User Rights to read passwords:

Add the extended permission Read Local Admin Password to the group that will be allowed to read the local administrator’s password for managed computers. It is done using PowerShell.  You may need to run Import-module AdmPwd.PS if this is a new window.
Set-AdmPwdReadPasswordPermission -Identity <name of the OU to delegate permissions> -AllowedPrincipals <name of Password Readers Group>

 

User Rights to reset passwords:

Add the extended permission Reset Local Admin Password to the group that will be allowed to reset the local admin account’s password for managed computers.  It is done using PowerShell.  You may need to run Import-module AdmPwd.PS if this is a new window.
Set-AdmPwdResetPasswordPermission
-Identity <name of the OU to delegate permissions> -AllowedPrincipals <name of Password Resetters Group>

 

PDS Server installation

 

PDS is responsible for creating and maintaining key pairs used for password encryption and decryption, communication with the Active Directory, auditing of requests of users for password reads/resets, and registration/maintenance of DNS SRV record used for discovery of service by clients.
Password Decryption Service is thus handling some interactions with AD infrastructure.
Computers do not directly read from Active Directory; they only directly write. Password Decryption Service maintains the decryption keys and is responsible for password reads, decrypts, and password resets.

 

Key pair

To store encrypted passwords in Active Directory, a key pair must be created. For security, only the Key Admin role can generate a new key pair. (By default, the Key Admin role is defined as an Enterprise Admin).

Keypairs are generated using PowerShell.  Upon request to create keys, two files will be made in the configured location:

One file contains a public key, and it should be distributed to managed machines via GPO
One file contains a private key and is used by the Password Decryption machine(s)

New-AdmPwdKeyPair -KeySize <Keysize of 1024, 2048 or 4096>
Get-AdmPwdPublicKey

Keys are stored in C:\Program Files\AdmPwd\Svc\CryptoKeyStorage.

 

Group policy settings

 

Group Policy is used to enable the local admin password solution and to configure various settings.
For GPO maintenance, the ADMX template needs to be installed on the machine on which Group Policy Management Console (GPMC) is running.
In GPO UI, all configuration settings related to CSE configuration are located under “Computer configuration/Policies/Administrative Templates/AdmPwd/Managed Clients” path.

Following configuration values are supported:

 

 

Auditing

 

 

The Password Decryption Service (PDS) logs its activity into a dedicated Windows Event log.
Auditing for users who query for a computer’s local administrator password can be accomplished by reviewing the LAPS Service Event log located under Applications and Services Logs.

 

Client installation

 

Installing CSE does not initiate the management of the password. GPO settings must be enabled for password management.
For the GPO to be applied on Servers or Workstations and LAPS solution to work, each managed computer should be installed LAPS client.
These can be installed/updated/uninstalled on clients using various methods, including the software Installation feature of Group Policy, SCCM, login script, manual install, etc.

 

Using LAPS to retrieve password

 

To retrieve a computer object’s password, all you need to do is install “Fat client UI” on workstation you use to administer your infrastructure and select the computer object for which you need the local admin password retrieved.

 

Conclusion

 

As always, recognizing the problem is the first step in resolving it.
Ignoring it could have enormous, potentially unrecoverable consequences.

Security in IT is always about compromises. Searching for that thin line that separates ease of use, comfort, and improved security.

Luckily, Microsoft created the solution for a scenario described in this post, which favors ease of use in large organizations while equally improving its security.

People with bad intentions won’t be able to take advantage of you… At least, not that easily…

 

PREVIOUS      NEXT

Before you continue...
Subscribe to our monthly content digest and stay up-to-date on everything industry related!

How Desktop Virtualization Works

End-User Computing – Simple and Secure

PREVIOUS      NEXT

How Desktop Virtualization Works

End-User Computing – Simple and Secure

Introduction

Desktop virtualization is one of the most effective ways for end-user environment optimization and control. Key benefits of virtualization are:

  • centralized resource management
  • easy administration
  • enhanced security
  • high availability
  • scalability and flexibility

VDI relies on the following components:

  1. Hardware – hyperconverged infrastructure consisting of vSAN Ready All-flash rack-mounted servers
  2. Software – VMware vSphere/vSAN environment combined with VMware Horizon 7 platform for centralized VDI management.

Hardware

Base

The hardware base consists of standard industrial rack-mounted servers capable of supporting vSAN storage virtualization (vSAN Ready Nodes). It offers excellent flexibility and reliability combined with easy implementation and maintenance. It also lowers capital and operational expenses because infrastructure is based on standard servers and their disks, so a separate storage system is not required. Since end-user experience is critical for VDI, performance is guaranteed by using SSD drives only.

Cluster Parameters

The minimum vSAN cluster consists of three nodes. The number of nodes, as well as their specifications (CPU, RAM, disk capacity, etc.), is determined by multiple factors:

  • number of users and type of work
  • VLAN configuration
  • estimated infrastructure growth
  • current IT environment
  • client-specific requests
Network Resources

For vSAN implementation, the proper network infrastructure is the crucial component. Due to distributed nature of vSAN, consisting of many local disks, it is necessary to make the connection between them quick and reliable. Therefore, each ESXi host needs to have a dedicated vSAN network, properly configured, with the following prerequisites:

  • Minimum 1 Gbps for hybrid configurations and 10 Gbps for All-flash
  • Each host must have a dedicated vmkernel adapter for vSAN traffic and be connected to the vSAN network. This is required even if specific host’s disks do not participate in total vSAN capacity
  • The maximum latency between any two hosts for the standard vSAN cluster is 1 ms.

For full redundancy, it is recommended that each host has two network adapters dedicated to vSAN. If 10 Gbps cards are used, vSAN traffic can share resources with other system traffic types (vMotion, HA, VM…). In that case, it is a good idea to guarantee bandwidth for vSAN using Network I/O control options on the distributed switch. Besides that, vSAN traffic can be prioritized with high CoS parameter values (Class of Service).

 

Figure 1. vSAN Ready Node

 

Disks

As mentioned, only SSD drives are considered. Choosing appropriate vendor and device parameters depends on a specific implementation. Each vSAN cluster consists of multiple disk groups, each having separate disks for caching and data store purposes (cache/capacity tear). In All-flash configuration, cache is used as a write buffer only because there is no need for caching during read operations.

Intel Optane

High-performance systems, requiring high bandwidth and low latency, caching tier can be configured with non-standard SSD drives based on Intel Optane solution. It is a new way of storing data, separate from standard floating-gate MOSFET technology.

With traditional flash memories, basic capacity units are cells, and their state is defined by the charge they hold, which is controlled by transistors and capacitors. Intel Optane uses the change of the material’s electric parameters, which results in cell resistance change. It enables much faster state changes. Also, cells can be organized into 3D structures (3D XPoint – Figure 2), which provides greater density and capacity.

In the vSAN environment, caching tier is heavily hit by write operations, so it is necessary to use highly reliable disks. On the other hand, capacity tier usually gets read requests with occasional write requests from caching tier. Therefore, it can contain less reliable and cheaper disks. Figure 3 shows typical Intel Optane use within the vSAN cluster.

 

Figure 2. Intel Optane 3D XPoint

Figure 3. Intel Optane vSAN Cluster

 

Software

Base

The software base consists of VMware vSphere infrastructure with vSAN as a storage solution. The main component for implementation, management, and monitoring of VDI is VMware Horizon 7 platform. Basic configuration and most common use cases assume that users access virtual machines using PCoIP, Blast Extreme, or RDP protocols. Besides that, it can be used to connect to physical machines and utilize Microsoft Remote Desktop Services (RDS). Application virtualization (ThinApp) and distribution by virtual disks (App Volumes) are additional features, simplifying implementation, migration, and lifecycle management.

 

Figure 4. vSphere/vSAN Environment

Figure 5. VDI Logical Scheme

 

Editions and Licensing

Available features depend on the Horizon 7 edition: Standard, Advanced, or Enterprise. There is also an edition for Linux users – Horizon for Linux.

Tables 1 and 2 contain specific components that makeup Horizon 7 platform. Some editions also include vSphere/vSAN licenses, but most of the components can be separately licensed based on client needs. Table 3 contains more license details for all editions.

For clients already having vSphere/vSAN infrastructure implemented, Horizon Add-On packages offer only licenses for desktop virtualization (Table 4).

There are two licensing models inside Horizon 7:

  • Per named user (NU) – suitable for environments that require dedicated user machines. Each user requires one license. This licensing model is not available for Standard and Horizon for Linux editions.
  • Perpetual per concurrent connection (CCU) – suitable for larger environments with multiple users sharing virtual machines during the day (e.g., students or shift workers). In this case, the main parameter is the number of users concurrently using the system at any time. For instance, 200 users working in two shifts (100 in each) would require 100 licenses.ž

 

Table 1. Horizon 7 Components (1/2)

Table 2. Horizon 7 Components (2/2)

Table 3. License Packages

Table 4. Horizon 7 Add-On Packages

 

Specific implementation depends on client needs and capabilities, as well as the overall IT infrastructure condition. In the case of significant user growth, the vSAN environment enables simple to scale up/out to meet the demands. Horizon 7 edition and licensing model is defined by available features described in the above tables.

It is essential to notice that the Named licensing model does not support NSX. Therefore, if the client plans to virtualize network resources, it is recommended to use the CCU licensing model.

 

Read in our next blog: Client access, profile management, and more…

 

For any additional information or question, please contact us at office@braineering.rs

 

PREVIOUS      NEXT

Before you continue...
Subscribe to our monthly content digest and stay up-to-date on everything industry related!

PREVIOUS      NEXT

PREVIOUS      NEXT

Before you continue...
Subscribe to our monthly content digest and stay up-to-date on everything industry related!