Teletrabajo con entornos Windows y coronavirus

Si bien algunas empresas están ya habituadas a permitir a sus empleados realizar trabajo en remoto, con la pandemia del coronavirus muchas otras se han visto forzadas a utilizar recursos limitados para un gran número de trabajadores.

Lo primero de todo, debemos tener en cuenta los servicios nativos cloud, los cuales permiten realizar tareas desde cualquier sitio de forma habitual. Por otro lado, el acceso a recursos locales dentro de la empresa debe asegurarse de diferentes formas:

  • Sistemas de alimentación ininterrumpida deben proveer corriente a los servidores o equipos con disponibilidad, algo básico pero necesario.
  • Seguridad de red activa, abrir un puerto o varios para permitir un servicio (por ejemplo de conexión remota) debe conllevar su monitorización activa en busca de patrones o usos inadeacuados. Firewall dedicados o Azure Bastion por ejemplo.
  • Autenticación de doble factor, donde sea posible y factible, como punto de verificación de identidad de humanos frente a máquinas.
  • Sistemas operativos y antivirus actualizados, no debería llegar una pandemia para tener este punto mínimo cubierto.

Dentro de los entornos corporativos con recursos limitados, se han habilitado ordenadores para su acceso por escritorio remoto, si bien las soluciones RDS/VDI/WVD son muy capaces, para PYMES puede no ser una opción asequible en todos los casos. Por ello debemos tener en cuenta cuando habilitamos el acceso remoto:

  • Separar y securizar redes según los perfiles y requisitos de acceso
  • Establecer directivas de red suficientes
  • Monitorizar y controlar los usuarios permitidos

Si llegados a este punto permitimos el acceso remoto al puesto de trabajo habitual de un trabajador, deberemos tener en cuenta adicionalmente:

Debemos estar seguros lo que supone introducir un ordenador dentro de la red corporativa, así como tener en mente primero a las personas y luego a las máquinas.

 

 

Identificar \Device\Harddisk# en Windows

Algunos de los registros de eventos de Windows utilizan identificadores internos diferentes, para conocer la relación de posible nombres del objeto al que se refieren:

Podemos utilizar la utilidad WinObj de Sysinternals para obtener la relación, desde la carpeta «Device»:

O desde la carpeta «GLOBAL??» ordenando por «Symlink» hasta llegar a los dispositivos de disco duro en «\Device\Harddisk…»

Mediante Powershell, donde el DeviceID corresponde con HardDisk#

Get-PhysicalDisk | Select -Prop DeviceId,FriendlyName,SerialNumber

En el registro de Windows dentro la clave:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\disk\Enum

Mediante el listado de drivers instalados:

wmic /output:c:\drivers.txt path Win32_PnPSignedDriver

 

Activar escritorio remoto mediante Powershell

Por defecto la conexión por escritorio remoto aparece deshabilitada en los equipos con Windows Pro, en una red de dominio es posible establecer mediante políticas de grupo los permisos necesarios:

– Configuración de Equipo \ Directivas \ Plantillas Administrativas
— Componentes de Windows \ Servicios de escritorio remoto \ Host de sesión de Escritorio remoto \ Conexiones \ Permitir que los usuarios se conecten de forma remota mediante Servicios de Escritorio Remoto

— Red \ Conexiones de red \ Firewall de Windows \ Perfil de dominio \ Firewall de Windows: permitir excepciones de Escritorio remoto entrantes

Igualmente podemos echar mano de un Script para powershell escrito por Sitaram Pamarthi en 2013, que mediante WMI nos facilita acciones puntuales:

[cmdletbinding()]
param(
	[parameter(ValueFromPipeline=$true,ValueFromPipelineByPropertyName=$true)]
	[string[]]$ComputerName = $env:computername,
	[ValidateScript({Test-Path $_})]
	[string]$OutFolder = "c:\"
)

begin {
$SuccessComps = Join-Path $OutFolder "Successcomps.txt"
$FailedComps = Join-Path $OutFolder "FailedComps.txt"
}

process {
	foreach($Computer in $ComputerName) {

		try {
			$RDP = Get-WmiObject -Class Win32_TerminalServiceSetting `
								-Namespace root\CIMV2\TerminalServices `
								-Computer $Computer `
								-Authentication 6 `
								-ErrorAction Stop
								
		} catch {
			Write-Host "$Computer : WMIQueryFailed"
			"$Computer : WMIQueryFailed" | Out-File -FilePath $FailedComps -Append
			continue
		}
		
		if($RDP.AllowTSConnections -eq 1) {
			Write-Host "$Computer : RDP Already Enabled"
			"$Computer : RDP Already Enabled" | Out-File -FilePath $SuccessComps -Append
			continue
		} else {
			try {
				$result = $RDP.SetAllowTsConnections(1,1)
				if($result.ReturnValue -eq 0) {
					Write-Host "$Computer : Enabled RDP Successfully"
					"$Computer : RDP Enabled Successfully" | Out-File -FilePath $SuccessComps -Append
				} else {
					Write-Host "$Computer : Failed to enabled RDP"
					"$Computer : Failed to enable RDP" | Out-File -FilePath $FailedComps -Append

				}
			
			} catch {
				Write-Host "$computer : Failed to enabled RDP"
				"$Computer : Failed to enable RDP" | Out-File -FilePath $FailedComps -Append
			}
		}
	}

}

end {}

Su utilización para un equipo concreto:

.\Enable-RDPAccess.ps1 -ComputerName <computer name>

 Si obtenemos errores al ejectuarlo, debemos comprobar que tenemos acceso mediante WMI o activarlo mediante GPO:

– Configuración del equipo \ Directivas \ Configuración de Windows \ Configuración de seguridad \ Firewall de Windows con seguridad avanzada \ Reglas de Entrada

Almacén central de políticas de grupo

Los controladores de Directorio activo de forma prederminada no replican el contenido de la carpeta de definición de políticas de grupo para Windows c:\Windows\PolicyDefinitions Esta carpeta contine los ficheros necesarios para crear políticas de grupo de acuerdo al nivel funcional del dominio.

Si queremos ampliar estas características con más plantillas o actualizaciones de las mismas, por ejemplo administrar una nueva característica de Windows 10 desde un directorio con nivel funcional Windows Server 2012, debemos mantener actualizada esta carpeta en todos los servidores.

Debemos copiar (importante COPIAR, no mover) desde el directorio predeterminado del servidor a la carpeta SYVOL disponible y sincronizada

Copiamos la carpeta C:\Windows\PolicyDefinitions al nuevo destino: C:\Windows\SYSVOL\domain\Policies\PolicyDefinitions

De tal manera que seguiremos disponiendo de los plantillas actuales, a las que podremos añadir nuevas ADMX para gestionar software nuevo o actualizado:

Con los ficheros ADMX de Office 2016 dentro de nuestra carpeta compartida nos aparecerían las nuevas opciones de administración:

Con los ficheros ADMX para Google Chrome:

Ocultar unidades de Mi PC

En ocasiones por seguridad y/o dificultar el acceso no autorizado a ciertos accesos es conveniente no mostrar algunas de las unidades. En este caso mostraremos como mediante política de grupo, aplicar esta restricción.

Creamos una nueva directiva:

Configuración de usuario -> Directivas -> Plantillas administrativas -> Componentes de Windows -> Explorador de archivos

Seleccionamos la opción «Ocultar estas unidades especificadas en Mi PC»

Podemos elegir entre diferentes opciones. Recordar que aunque no se muestren es posible acceder dependiendo del resto de directivas y acceso a programas, lo que no invalida tener que aplicar los permisos limitados a las carpetas, programas, configuraciones…