Accessing Linux Desktop/Server from Windows remotely: using RDP and xRDP

The graphical Remote Desktop Connection is one of the most common methods of working on a Remote Windows based Server or Desktop for Windows users. All Microsoft Windows editions have built-in support for RDP on Windows OS. Doing RDP from a Windows to a Linux environment is easy but requires a few configurations on the remote Linux Server/Desktop.

XRDP: It is a popular Linux open source development that brings several Windows-like features, such as the following:

• Two-way clipboard transfer (text, bitmap, file)
• Audio redirection
• Drive redirection (mount local client drives on remote machine)
• RDP transport is encrypted using TLS by default

The following configuration steps can be used on all RPM based Linux distributions, such as Red Hat, Fedora, CentOS, and Oracle Linux. For this tutorial, we will be using “Rocky Linux 8.4 RC1 (https://rockylinux.org) - An alternative Linux to CentOS”. Please note that this distribution is not ready for production use yet, but the method described here is applicable to all other Linux.

Step-by-step guide:

Suppose the hostname of the Linux Server is “RockyLinux01 – 192.168.0.15”. We want to RDP to this server from a Window 10 Desktop.

• Login as root on the Linux Server/Desktop.

• If the GNOME Desktop Environment has not been installed already, install the GNOME Package using the following command:

   dnf groupinstall 'Server with GUI'

Installing GNOME package

• Enable the EPEL repository for XRDP package:

   dnf install epel-release

• Install the XRDP package:

   dnf install xrdp

• Enable and start the XRDP service:

   systemctl enable xrdp

   systemctl start xrdp

• Add the exec gnome-session to the /etc/xrdp/xrdp.ini. You can open the xrdp.ini file using vi, nano or any other text editor. I use nano:

   nano /etc/xrdp/xrdp.ini

Editing xrdp.ini

• Add a firewall rule to allow the RDP port 3389 to pass through:

   firewall-cmd --add-port=3389/tcp --permanent

   firewall-cmd --reload

• Restart the XRDP service:

   systemctl restart xrdp

• Check if everything is running as expected:

    systemctl status xrdp

    netstat –atnp | grep 3389

 

xrdp service status on Linux

• Open the Windows Remote Desktop Connection app and log on to the server. Following are some screenshots using XRDP.

 Screenshots:

Microsoft RDP

xrdp login window on Linux

Using Microsft RDP to login to a Linux

 References:

• XRDP: http://xrdp.org/
• Rocky Linux: https://rockylinux.org/

Using Managed Service Account with SQL Server Service

MSA is a Managed Active Directory Account which is automatically managed by the Active Directory (AD).  A MSA (domain\account$) is assigned to a Windows Server and the password management is handled by the Windows.

Benefits of MSA: The main benefit of Managed Service Account (MSA) is that the password management is delegated to the Active Directory and Windows Operating System, and thus the MSA reduces the overhead of administrative tasks on service account and simplify service principal’s management in an enterprise.

• Automatic password management.
•  Simplified service principal name (SPN) management.
• Cannot be used to interactively log into Windows.
• Easily control which computers are authorized authenticate MSAs and run code in their context.

There are two types of Managed Service Account (MSA):

1.      sMSA (Standalone Manage Service Account): This type of managed service account (MSA) was introduced in Windows Server 2008 R2 and Windows 7. A sMSA can be used to a single Windows Server.

2.      gMSA (Group Managed Service Account): This type of managed service account (MSA) was introduced in Windows Server 2012 R2. The gMSA can be used multiple times. Failover clusters do not support gMSA. 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.

 sMSA and gMSA support for SQL Server:

• SQL Server 2012: This edition of SQL Server supports only sMSA.
• SQL Server 2014 and up: sMSA and gMSA both are supported

MSA account on the AD

Standalone Managed Service Accounts (sMSA) Prerequisites for SQL Server: To use a sMSA following prerequisites needs to be met:

1. Domain Functional Level of Windows Server 2008 R2 or above.
2. SQL Server 2012 or above.
3. Microsoft Key Distribution Service.
4. Active Directory PowerShell module for management.

Group Managed Service Accounts (gMSA) Prerequisites for SQL Server: To use a gMSA following prerequisites needs to be met:

1. Domain Functional Level of Windows Server 2012 or higher.
2. SQL Server 2014 or above.
3. Window Server 2012 R2 or above.
4. Microsoft Key Distribution Service.
5. Active Directory PowerShell module for management.

Steps to create MSA (sMSA or gMSA):

1. Create the KDS key on the domain controller.
2. Install Active Directory PowerShell Module.
3. Create sMSA or gMSA.
4. On the client, install the sSMA or gMSA.
5. Configure the Windows Service with the MSA.
   

Step-by-Step to create a Standalone Managed Service Account (sMSA): We need to create a Standalone Managed Service Account, say sSQL2012 to use with a SQL Server 2012 which is installed on Windows Server named sql2019 in myhome.net domain.

On The domain controller: Perform the following on the domain controller:

• Check KDS key: if the KDS key is not available then we need to create one. Note that a 10 hours is required to be effective of a KDS key.

     Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))    

• Create service account named sSQL2012:

New-ADServiceAccount sSQL2012 `

    -DisplayName "sql2012 MSA Service" `

    -DNSHostName sql2019.myhome.net

• Set which server can retrieve the password from the Active Directory:

Set-ADServiceAccount sSQL2012 `

    -PrincipalsAllowedToRetrieveManagedPassword sql2019$

• Set the encryption type for the account:

Set-ADServiceAccount `

    -Identity sSQL2012 `

    -KerberosEncryptionType AES128,AES256

 

On the Client Server (server: SQL2019): Logon to the client server, in our example the server name is SQL2019 and then execute the following commands:

•  Install and import the Active Directory PowerShell Module.

Add-WindowsFeature RSAT-AD-PowerShell

Import-Module ActiveDirectory

•  Install the newly created Managed Service Account sSQL2012:

    Install-ADServiceAccount -Identity sSQL2012

• Test and validate the account:

    Test-ADServiceAccount -Identity sSQL2012

 If everything went well, then the testing result will be as follows:

•  Now open the SQL Server Configuration Manager and then change the service account. In my case, the new service account is myhome\sSQL2012$.

Step-by-Step to create a Group Managed Service Account (gMSA): We need to create a Group Managed Service Account, say gMSAsqlSvc to use with multiple SQL Server instances starting with edition SQL 2014. Let’s assume that the Windows Servers are Sql2104, Sql2016, sql2017 and sql2019. All these Windows server resides in myhome.net domain.

A gMSA creation can be done in two different ways, using AD Group Account or without using an AD Group.

Creating gMSA Using AD Group: On The domain controller:

• Check KDS key: if the KDS key is not available then we need to create one. Note that a 10 hours is required to be effective of a KDS key.

    Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)) 

• Create an AD Group as SQLSvcGroup:

    New-ADGroup "SQLSvcGroup" `

    -GroupCategory Security `

    -GroupScope Global `

    -PassThru `

    –Verbose

• Add two servers to the newly created AD Group. Make sure you have added $ at the of each computer name:

    Add-AdGroupMember `

    -Identity "SQLSvcGroup" `

    -Members sql2014$, sql2016$

• Verify the SQLSvcSvr Group:

    Get-AdGroupMember -Identity "SQLSvcGroup"

•  Create a group service account as gMSAsqlSvc:

New-ADServiceAccount `

    -Name gMSAsqlSvc `

    -PrincipalsAllowedToRetrieveManagedPassword SQLSvcGroup `

    -Enabled:$true `

    -DNSHostName gMSAsqlSvc.myhome.net `

    -SamAccountName gMSAsqlSvc `

    -ManagedPasswordIntervalInDays 30

Creating gMSA Without AD Group: On The domain controller:

• Check KDS key: if the KDS key is not available then we need to create one. Note that a 10 hours is required to be effective of a KDS key.

     Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10)) 

• Craete a group service account as gMSAsqlSvc, include the two servers:

    New-ADServiceAccount -Name gMSAsqlSvc `

   -DNSHostName gMSAsqlSvc.myhome.net `

   -PrincipalsAllowedToRetrieveManagedPassword sql2014$,sql2016$ `

   -ManagedPasswordIntervalInDays 30

•  If you need to add more server to the group service account then, use the following command for each server which needs to be added to managed service account:

Add-ADComputerServiceAccount `

    -ServiceAccount gMSAsqlSvc `

    -Computer sql2019

 

Set-ADServiceAccount `

    -Identity gMSAsqlSvc `

    -PrincipalsAllowedToRetrieveManagedPassword sql2019$

 

On the Client Server (Server name: SQL2014, SQL2016): Logon to the client server, in our example the server name is SQL2014 and then execute the following commands:

•  Install and import the Active Directory PowerShell Module.

    Add-WindowsFeature RSAT-AD-PowerShell 

    Import-Module ActiveDirectory

•  Install the newly created Managed Service Account sSQL2012:

    Install-ADServiceAccount -Identity gMSAsqlSvc

•  Test and validate the account:

    Test-ADServiceAccount -Identity gMSAsqlSvc

If everything went well, then the testing result will be as follows:

• Now open the SQL Server Configuration Manager and then change the service account. In my case, the new service account is myhome\gMSAsqlSvc$.

 

Using a MSA: To use a sMSA or gMSA account with SQL Server Service, navigate “SQL Server Configuration Manager” and then use DOMAIN\<msa name>$. Please note that the MSA needs a $ at the end. We don’t need to provide the password for MSA, Windows will automatically retrieve the password from the AD.

References:

• Running Assessments with Managed Service Accounts: https://docs.microsoft.com/en-us/services-hub/health/kb-running-assessments-with-msas

• Configure Windows Service Accounts and Permissions: https://docs.microsoft.com/en-us/sql/database-engine/configure-windows/configure-windows-service-accounts-and-permissions?view=sql-server-ver15

• Group Managed Service Accounts Overview: https://docs.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview