WINRM



EN SERVIDOR

Primer Paso: Antes de nada hay que configurar los nombres de maquina a un nombre que sepamos fácil de recordar para tener acceso a esa máquina.
Nuestro servidor se va a llamar Server P, como se ve en la siguiente imagen.

Segundo Paso: Nuestro equipo debe pertenecer o bien a un grupo de red privado o dominio como nuestro equipo no este configurado con ese tipo de redes no vamos a poder realizar la conexión remota.



Tercer paso: Una vez configurado estos dos pasos tendremos que ejecutar la powershell en modo administrador, combinación de tecla Windows+Q.

Cuarto paso: Una vez que tengamos la powershell es habilitar el servicio Winrm, para ello tendremos que ejecutar la siguiente sintaxis, get-service winrm, la que nos dirá el estado del servicio.

Quinto Paso: Una vez que sabemos el estado del servicio y como está corriendo tenemos que forzar con este comando para que arranque y configuré el winrm para ello escribimos la sintaxis enable-PSRemoting –force. Que nos dice como esta ese servicio y si esta disonible.

Sexto Paso: Ahora tenemos que habilitar la maquina cliente en el servidor para que acepte el nombre, para ello escribimos esta sintaxis, winrm set winrm/config/client ‘@{TrustedHosts=”NombreEquipoCliente”}’   , con ese comando habilitaremos y daremos acceso al cliente.

Como vemos incorporo ese nombre a TruestedHosts que es un pc de confianza.
Séptimo Paso: Con el comando winrm quickconfig o winrm qc vemos como está el servicio y si esta configurado.

Octavo Paso: Podemos ver la configuración del winrm estableciendo el siguiente comando winrm get winrm/config lo que permite ver los parámetros de configuración de winrm y podemos coger luego más adelante parámetros necesario para la conexión remota.

Noveno Paso: Podremos modificar cualquier parámetro sabiendo que significa cada línea de código estableciendo el siguiente comando winrm set winrm/ruta ‘@{nombre=”parámetro a insertar”}’, como vemos en la siguiente imagen son como un árbol que están ordenados cada parámetro.

Con estas opciones ya estaría configurado el servidor.

EN CLIENTE

Como habíamos dicho importantísimo establecer nombre de máquina tanto en cliente como en servidor, la que hemos puesto de nombre Pc1.

Segundo paso: Es arrancar la powershell en modo administrador como anteriormente hemos explicado en el servidor. Y pondremos el siguiente comando para ver el estado del servicio get-service winrm.

Como podemos apreciar el servicio está parado así que no podemos realizar conexiones remotas ni configurar el winrm, para ello vamos a forzar el servicio para que se ponga en iniciado con el siguiente comando, enable-PSRemoting –force.

Con esto nos dice que winrm se activó para recibir solicitud y se creó una escucha  winrm en el protocolo HTTP. Si volvemos a poner el comando get-service winrm, podemos ver de nuevo el estado del servicio como cambio a iniciado.

Tercer Paso: Ahora tenemos que añadir el servidor en nuestro archivo de configuración de la máquina cliente para ello escribiremos la siguiente sintaxis winrm set winrm/config/client ‘@{TrustedHosts=”Nombre equipo servidor”}’, con esto ya introducimos el servidor en el cliente.

Cuarto Paso: Ahora pondremos el comando winrm quickconfig o winrm qc para comprobar si está disponible y bien configurado el servicio. Como nos dice que ya está disponible para la administración remota:

Quinto Paso:  Ya estamos listos para la conexión remota e interactuar con el servidor pero antes necesitamos la sintaxis para la realización de ese medio que nos dará el acceso remoto para ello vemos el comando winrs /?.


winrs [-/MODIFICADOR[:VALOR]] COMANDO
COMANDO: cadena que se ejecuta como comando en el
 
MODIFICADORES
===============
(Todos aceptan la forma corta y la larga.
Tanto -r como -remote son válidos).

-r[emote]:EXTREMO                  - El extremo de destino con nombre
                                      NetBIOS o la dirección URL de conexión
                                      estándar: [TRANSPORTE://]DESTINO[:PUERTO].
                                      Si no se especifica, se usa -r:localhost.

-un[encrypted]                    - Especifica que los mensajes al shell remoto
                                      no se cifrarán. Útil para solucionar
                                      problemas, cuando el tráfico de red se
                                      cifra mediante IPsec o cuando se aplica
                                      seguridad física. De forma predeterminada,
                                      los mensajes se cifran con claves Kerberos
                                      o NTLM. Este modificador se omite cuando se
                                      selecciona el transporte HTTPS.

-u[sername]:NOMBRE_DE_USUARIO - Especifica el nombre de usuario en
                                      línea de comandos. Si no se especifica, la
                                      herramienta usará la autenticación Negotiate
                                      o pedirá el nombre. Si se especifica -username,
                                      también se debe indicar -password.

-p[assword]:CONTRASEÑA        - Especifica la contraseña en la línea de
                                      comandos. Si no se especifica -password, pero
                                      sí -username, la herramienta pedirá la
                                      contraseña. Si se especifica -password,
                                      también se debe indicar -user.

-t[imeout]:SEGUNDOS                - Esta opción no se usa.

-d[irectory]:RUTA             - Especifica el directorio de inicio del shell
                                      remoto. Si no se especifica, el shell remoto
                                      se iniciará en el directorio particular del
                                      usuario definido por la variable de entorno
                                      %USERPROFILE%.

-env[ironment]:CADENA=VALOR   - Especifica una variable única de entorno
                                      que se establecerá cuando se inicie el shell,
                                      lo que permite cambiar el entorno
                                      predeterminado para el shell. Se puede usar
                                      este modificador varias veces.

-noe[cho]                            - Especifica que se debe deshabilitar el eco.
                                      Necesario para asegurar que las
                                      respuestas a los mensajes remotos
                                      no se muestren localmente. De forma
                                      predeterminada, el eco se establece en
                                      "on" (habilitado).

-nop[rofile]                         - Especifica que no debe cargarse el perfil del
                                      usuario. El servidor cargará el
                                      perfil de usuario de forma predet.
                                      Si el usuario remoto no es un administrador
                                      local en el sistema de destino, se necesitará
                                      esta opción (el valor predeterminado causará
                                      un error).

-a[llow]d[elegate]               - Especifica que se pueden usar credenciales
                                      de usuario para obtener acceso a un recurso
                                      compartido remoto, por ejemplo, en un equipo
                                      distinto del extremo de destino.

-comp[ression]                    - Activa la compresión. Puede que las
                                      instalaciones anteriores en equipos remotos
                                      no admitan la compresión; por tanto, está
                                      desactivada de forma predeterminada.

-[use]ssl                   - Use una conexión SSL al usar un extremo
                                      remoto. Si especifica esto en lugar del
                                      transporte "https:", se usará el puerto
                                      predeterminado WinRM.







Sexto Paso: Esta es la ayuda del comando WINRS, pero también necesitaremos un puerto ya que es imprescindible para la conexión. Para ver el siguiente puerto tenemos que poner la siguiente sintaxis, winrm get winrm/config.




 Como vemos en el rectángulo tenemos que coger el puerto 5985 que es el que usa el servicio winrs para la conexión remota, también podemos utilizar el otro pero nos va a dar fallos de certificados ya que tenemos que pedir un certificado ya que el https es un protocolo de hipertexto de transmisión segura.
Septimo Paso: una vez que ya sabemos el puerto comenzaremos a interactuar con el servidor poniento la siguiente sintaxis en el cliente, winrs –r:http://ServerP:5985 –u:administrador “comando”.
Una vez que le escribamos nos va a pedir que introduzcamos la contraseña del usuario que hemos especificado en nuestro caso es el administrador.

Pondremos la contraseña y nos conecta con el servidor y podremos interactuar con él por medios de comando.

Ahora para verificar que estamos dentro del servidor podremos poner hostname  para ver el nombre de máquina que nos devuelve.

Podremos crear una carpeta en el servidor y un archivo de texto:

Creamos un documento de texto.

Y ahora vemos si es verdad que esta creado en el servidor. Como vemos en la siguiente imagen




Con esto ya estaría todo comprobado.
¿Pero que hubiese pasado si en el TrustedHosts hubiésemos puesto otra máquina como en la siguiente imagen y ponemos la sintaxis de conexión para el servidor.?

Manda el siguiente error;

Lo que significa que no está bien vinculado el nombre al TrustedHosts o que la base de datos de kerberos no es capaz de resolver ese nombre, del active directory.
¿Pero qué es Kerberos?
Kerberos es un protocolo de autenticación de redes de ordenador creado por el MIT que permite a dos ordenadores en una red insegura demostrar su identidad mutuamente de manera segura. Sus diseñadores se concentraron primeramente en un modelo de cliente-servidor, y brinda autenticación mutua: tanto cliente como servidor verifican la identidad uno del otro.

Active Directory

Active directory
Active Directory es el servicio de directorio de una red Windows. Este servicio de directorio es un servicio de red que almacena información acerca de los recursos de la red y permite el acceso de los usuarios y las aplicaciones a dichos recursos, de forma que se convierte en un medio de organizar, controlar y administrar centralizadamente el acceso a los recursos de la red.
El servicio Active Directory proporciona la capacidad de establecer un único inicio de sesión y un repositorio central de información para toda su infraestructura.

Instalacion y configuración de Active Directory
Antes de comenzar con cualquier configuración hay que tener definidas algunas opciones, pero las más básicas incluyen:
  • Cómo se llamará el Dominio
    Debe seguir las convenciones de nombres de DNS, y es independiente del dominio con el que se tenga prescencia en Internet. Son dos cosas totalmente diferentes “dominio Active Directory” y “dominio de Internet”
    Y para los de habla española, recordar que no incluya vocales acentuadas o la letra “ñ” ya que traen problemas luego
  • Cómo será la convención de nombres para los Controladores de Dominio
  • Qué configuración de red tendrá, que deberá ser ingresada manualmente, y no como cliente de DHCP
Así que lo primero que debemos hacer luego de instalar el servidor es asignarle la configuración IP. Esto variará con cada instalación, yo he elegido la red 192.168.1.0/24 que no es una red recomendable.




Observen que la configuración de servidor DNS está en blanco.

Luego de lo anterior debemos asignarle al servidor que será Controlador de Dominio un nombre adecuado, de acuerdo a la convención de nombres que tengamos.







Y reiniciamos la máquina, ya que es requerido por el cambio de nombre.




Luego del reinicio e iniciando sesión con una cuenta de administrador local procederemos a instalar la funcionalidad de acuerdo a como se muestra en las siguientes pantallas.






Cuando seleccionemos “Active Directory Domain Services” solicitará la instalación de componentes adicionales, que por supuesto lo aceptaremos.







Finalizada la instalación, y ya en el último paso, debemos promover al equipo como Controlador de Dominio configurándolo de acuerdo a la necesidad.



La opción ofrecida por omisión es crear un nuevo Bosque (“Forest”), que es lo que debemos seleccionar cuando estamos creando nuestro primer Dominio Active Directory. Sólo debemos ingresar el nombre del Dominio a crear.



Vamos a detenernos un tiempo en esta pantalla porque hay configuraciones importantes. Salvo que posteriormente vayamos a instalar Controladores de Dominio con versiones anteriores del sistema operativo, no convendrá disminuir los niveles funcionales.
Y es muy importante colocar una contraseña segura de “Directory Service Restore Mode” (DSRM). Esta contraseña es necesaria si tuviéramos que hacer una restauración desde una copia de seguridad del Controlador de Dominio. Esta contraseña no tiene relación con la cuenta de administrador del Dominio, no se sincroniza, y es individual para cada Controlador de Dominio.



Es normal que no pueda efectuar la delegación en el DNS superior, y en nuestro caso sería un problema grave de seguridad si pudiera delegar en un dominio de Internet, nuestro Dominio Active Directory. Así que a ignorar la advertencia y continuar.




Sugiere el nombre NetBIOS del Dominio, que salvo que esté duplicado en la red, siempre será la parte más a la izquierda del nombre de Dominio que hayamos colocado.



Salvo que tengamos en nuestro servidor más de un disco físico y esperemos que nuestro Active Directory sea “muy grande”, no conviene cambiar las ubicaciones de los archivos
Como aclaración: mover la base y los logs es muy sencillo luego, pero cambiar la ubicación de SYSVOL es problemático.




Verificamos si todo lo que seleccionamos es lo que realmente deseamos.




Y vemos que el sistema nos da algunas advertencias. Entiendo que nadie a esta altura tendrá servidores NT 4.0, y por el tema delegación DNS ya lo hemos visto, así que podemos seguir adelante tranquilos.
Observen que informa que se reiniciará la máquina automáticamente al finalizar el proceso.




Luego del reinicio podremos iniciar sesión con el administrador del Dominio, ya no administrador local, aunque su configuración en este caso se ha migrado.




Podemos observar que ya es Controlador de Domino de, en mi caso, “ad.guillermod.com.ar”.

También ya tenemos instaladas las aplicaciones de más uso para administrar nuestro Dominio.



Si abrimos “Active Directory Users and Computers” veremos que está creada la correspondiente cuenta de máquina en la Unidad Organizativa “Domain Controllers”.



También podemos observar que se han creado las correspondientes zonas DNS (en la consola DNS), y se han creado los registros correspondientes. Tanto en la zona con el nombre del Dominio, como en la zona que comienza con “_msdcs.”.



Controlador de dominio segundario.

Infraestructura del bosque.



Debemos disponer de una instalación de Windows Server 2012, no vale una instalación clonada, donde previamente le he asignado el nombre DC2 de acuerdo a lo planificado, y he configurado adecuadamente el direccionamiento IP.

Esto último es simplemente ponerle dirección IP fija (192.168.0.202), y configurar para que use como DNS al servidor ya existente (192.168.0.1).




Luego de esto lo he unido al Dominio existente, y he iniciado sesión como administrador del dominio (ROOT\Administrator).

Se instalará el Rol “Active Directory Domain Services” de igual forma que en la nota anterior, salvo que diferirá en el momento de la configuración, que deberá ser hecha como se indica a continuación.




En este caso, para agregar un Controlador de Dominio adicional en un Dominio existente, elegiremos “Add a domain controller to an existing domain”.
Si hemos iniciado sesión con la cuenta de administrador del Dominio, ya estarán correctos los datos correspondientes al nombre del Dominio, y la cuenta con privilegios suficientes. Si así no fuera, utilizar los botones “Select…” y “Change” para seleccionarlos como muestra la figura.




Vemos, que por omisión, ya nos ofrece que tenga el servicio DNS y que sea Catálogo Global. Como no hemos configurado aún los Sites podemos dejar el valor por omisión. Sólo deberemos ingresar la contraseña correspondiente a “Directory Service Restore Mode” (ver las consideraciones en la nota anterior).





Observen en la siguiente pantalla que podemos seleccionar desde qué Controlador de Dominio se hará la replicación inicial; en nuestro caso no tiene sentido elegir cuál pues tenemos uno sólo
También está la opción IFM (Install From Media), esta opción puede ser útil en algunos casos. Si tuviéramos un Dominio “grande” y fuera a través de un enlace WAN con poco ancho de banda disponible, podríamos hacer una especie de copia de seguridad de Active Directory, transportarla al sitio remoto, y hacer que tome gran parte de la información (no toda) desde esta copia local.



Para el resto, las mismas consideraciones que ya he hecho en la nota anterior.





Cuando finalice, se reinciará el equipo, e iniciaremos sesión con la cuenta de administrador del Dominio (ROOT\Administrator).
Si todo estuvo bien, en pocos minutos, aunque puede demorar hasta 30 minutos, se crearán los “Objetos Conexión” entre los Controladores de Dominio que servirán para la replicación de Active Directory.
Pero como somos “ansiosos” :-D vamos a ver cómo acelerar el proceso.
Vamos a DC1, y abramos “Active Directory Sites and Services” (Sitios y Servicios de Active Directory) y sobre el lado izquierdo despleguemos. Sites / Default-First-Site-Name / Servers / DC1 / NTDS Settings.

Veremos sobre el lado derecho que no está creado el Objeto Conexión para recibir información desde DC2.



Entonces con botón derecho sobre “NTDS Settings” elegiimos “All Tasks / Check Replication Topology”.


Nos informará que debemos refrescar la información, así que sobre Sites pulsamos F5, y volvemos a donde estábamos y veremos el Objeto Conexión que permite la replicación desde DC2 a DC1.



Para confirmar, con botón derecho sobre el Objeto Conexión, elegimos “Replicate Now” y observermos que se replica correctamente.




Si diera algún mensaje que no puede replicar, no asustarse, esperar unos minutos, y nuevamente F5 y “Replicate Now”.
Ahora iniciamos sesión en DC2 y procedemos de forma análoga.




Ya que estamos en DC2, ingresemos a la consola de administración de DNS y observemos que la información de DNS ya fue replicada, que están registrados ambos Controladores de Dominio, y como la zona está integrada en Active Directory, DC2 informa que el SOA es DC2.



Ahora vamos a DC1, y observemos que como cualquiera de los Controladores de Dominio puede efectuar cambios en la zona, DC1 dice que el SOA es DC1.


Noten además, que en ambos DNS, los dos Controladores de Dominio están registrados como NS (Name Servers), o sea que ambos pueden responder en forma autoritaria por la zona,
Como buena y usual costumbre, aunque no es un requerido, es conveniente “cruzar los DNSs”. O sea que DC1 use como DNS preferido a DC2 y a sí mismo como alternativo. 

Y análogamente para DC2, así que los “cruzaré”.

Sobre este tema veré si luego hago una nota adicional para notar las ventajas e inconvenientes en cada caso:
En DC1:



Y en DC2: