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.

 

 


Habilitar Administración Remota mediante Política de Grupo (GPO - WinRM)

Para permitir la administración remota a equipos dentro del dominio podemos definir una Política de Grupo:

Configuración del Equipo - Directivas - Plantillas administrativas - Componentes de Windows - Administración remota de Windows (WinRM) - Servicio WinRM

 

Configuración del equipo - Directivas - Plantillas administrativas - Red - Conexiones de red - Firewall de Windows - Perfil de dominio

Habilitamos "Firewall de Windows: Permitir excepción de administración remota entrante" e indicamos la IP desde la que se puede gestionar o asterisco "*" para cualquiera

Por último añadimos una regla en el firewall: Configuración del equipo - Configuración de Windows - Configuración de seguridad - Firewall de Windows con Seguridad Avanzada - Reglas de entrada

Añadimos una nueva predefinida: "Administración remota de windows"

Configuración de equipo - Preferencias - Configuración del Panel de control - Servicios

Nos aseguramos que "WinRM" se inicie con el sistema:

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

 

Funciones personalizadas en expresiones LINQ

En las últimas versiones de Entity Framework ciertos métodos que antes si eran aceptados, como también se podía realizar en SQL, han dejado de estar disponibles. Aquellas funciones heredadas directamente de SQL han quedado englobadas en la misma clase. Algo que antes era habitual pero no precisamente una buena forma de solucionar... las conversiones de tipos de datos, ¿quien no ha convertido un string en entero en SQL?

LINQ to Entities does not recognize the method 'XXXXXXX' method, and this method cannot be translated into a store expression

Si hablamos con propiedad y utilizando todo el potencial de los ORM no es una buena práctica, debemos revisar y guardar los datos con el tipo más apropiado, pero si nos vemos forzados a utilizarlas... podemos personalizar funciones dentro de nuestro modelo de datos.

Abrimos nuestro EDMX y definimos la función:

    <edmx:ConceptualModels>
      <Schema Namespace="NombreDeMiModelo" Alias="Self" annotation:UseStrongSpatialTypes="false" xmlns:annotation="http://schemas.microsoft.com/ado/2009/02/edm/annotation" xmlns:customannotation="http://schemas.microsoft.com/ado/2013/11/edm/customannotation" xmlns="http://schemas.microsoft.com/ado/2009/11/edm">
        <Function Name="convertirDouble" ReturnType="Edm.Double"> 
        <Parameter Name="stringvalue" Type="Edm.String" /> 
        <DefiningExpression> 
            cast(stringvalue as Edm.Double)
        </DefiningExpression> 
        </Function>
...       

Definimos en nuestra clase la función:

using System;
using System.Data.Entity;
using System.Data.Objects.DataClasses;

public partial class MiModeloContext
{
    /// <summary>
    ///     Este método existe para poder ser usando dentro de expresiones LINQ
    ///     convierte un texto en número (Double)
    /// </summary>

    [DbFunction("NombreDeMiModelo", "convertirDouble")]
    public static double convertirDouble(string stringvalue)
    {
        return Double.Parse(stringvalue);
    }
}

 Ya podemos utilizar la función dentro de las expresiones:

datos = miEntidad.miDato.Where(x => SqlFunctions.IsNumeric(x.aux) > 0 &&
MiModeloContext.ParseDouble(x.aux) > numero)
.FirstOrDefault();

 

Aunque deberemos revisar si realmente nuestro modelo de datos es coherente...

Referencia: Calling Functions in LINQ to Entities Queries

ResolveUR: Error durante la instalación

La extensión ResolveUR todavía no tiene el archivo de instalación adaptador a Visual Studio 2019 pero funciona como en versiones anteriores, deberemos adaptar el fichero de instalación VSIX

This extension cannot be installed because the following references are missing: Microsoft.VisualStudio.Component.CoreEditor

Dentro del fichero catalog.json sustituimos:

"Microsoft.VisualStudio.Component.CoreEditor":"[15.0.26208.0,16.0)"}

Por la versión de VS2019:

"Microsoft.VisualStudio.Component.CoreEditor":"[15.0,17.0)"}

Continuará con la ejecución como en versiones anteriores:

Descargar ResolveUR_MOD_VS2019.zip (46,35 kb)