Implantación de Sistemas Operativos : abril 2020

martes, 28 de abril de 2020

Instalación de dos distros de LINUX

[ Práctica a realizar para los días 27/04/2020-30/04/2020 ]

Puesto que nos llegó la hora de reforzar conocimiento con LINUX he propuesto en la clase dos instalaciones de distribuciones de LINUX.
Podéis instalar las que queráis, propongo LINUX MINT Y MANJARO .Pero podría ser cualquiera .
Las instalaciones no LIVE si no como máquina virtual .
La segunda práctica sería instalar un servidor SSH,FTP...en cada una de las distribuciones . Por supuesto desde una máquina Windows y un cliente comprobar qué funciona.
Si queréis instalar algún programa interesante estaría genial, tal como Virtual Box en Linux Mint o VMWARE en Linux Mint.
Nos vemos en la clase del Viernes !!!

jueves, 23 de abril de 2020

Join Ubuntu 18.04 to Active Directory

[ Práctica a realizar para los días 23/04/2020-24/04/2020 ]

Desde este enlace el resumen .

Bibliografía :
https://computingforgeeks.com/join-ubuntu-debian-to-active-directory-ad-domain/
https://elbinario.net/2019/02/13/integrando-ubuntu-desktop-18-04-en-dominio-active-directory/

lunes, 6 de abril de 2020

Qué son los FSMO?

Los FSMO (Flexible Single Master Operations, por sus siglas en inglés) son una serie de operaciones realizadas por los controladores de dominio en torno a la replicación MultiMaster que estos realizan con los diferentes controladores de dominio tanto del bosque como del dominio, estas operaciones son únicas, es decir, no pueden realizarse por más de un controlador de dominio. Por defecto, el que mantiene estas operaciones de Single Master es el primer controlador de dominio que instalamos en un bosque.

Para ver los distintos FSMO podemos ejecutar el siguiente comando:

netdom query FSMO

netdomfsmo — Consulta de los FSMO con NETDOM

Podemos observar en la imagen los distintos Roles de Single Master que existen y el respectivo controlador de dominio que realiza dicha tarea. Más adelante hablaremos un poco de qué tarea realiza cada uno.

O también desde el modo interactivo del comando NTDSUTIL:

ntdsutil roles connections “connect to server %nombre_servidor%” quit “select operation target” “List roles for connected server” quit quit quit

Aquí tenemos una imagen del comando ejecutándose en el controlador de dominio denominado LON-DC1.

*IMPORTANTE: Cambiar %nombre_servidor% por el nombre del controlador de dominio a consultar.

ntdsutil — Consulta FSMO con el comando NTDSUTIL

En la imagen observamos una nomenclatura LDAP, en dónde se nos indica la ruta a la partición de la base de datos de nuestro Directorio Activo (ntds.dit) y en qué servidor se encuentran cada uno de estos roles, como vemos los servidores se almacenan en la partición de Configuration.

Desde ADSI Edit podemos dirigirnos hasta la ruta:

Vemos que tenemos dos controladores de dominio señalados con un circulito verde, la partición que hemos cargado es la de Configuration y podemos dirigirnos hasta la ruta:

CN=NTDS Settings,CN=LON-DC1,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=adatum,DC=com

También podríamos ver cada FSMO desde el entorno gráfico:

Desde la consola de “Usuarios y Equipos de Directorio Activo” (dsa.msc) clic derecho en el servidor -> Operations Master. En esta ventana podremos ver 3 de los 5 maestro de operaciones.

properties — Menú contextual del servidor de la consola DSA.MSC

Mediante el botón “Change” podremos mover los distintos Singles Masters entre los distintos controladores de dominios existentes, siempre que sean de escritura/lectura, no podemos mover un Single Master a un controlador de dominio de sólo lectura (RODC).

Desde la consola de Dominios y Confianzas del Directorio Activo (domain.msc) podemos acceder a otro Single Master:

properties2 — Menú contextual de la consola DOMAIN.MSC

Para poder visualizar el último de los Single Master es necesario cargar una librería, se cargaría con el siguiente comando:

regsvr32 schmmgmt.dll

Ahora o podemos abrir una MMC y buscar la consola de último Single Master:

Hacemos clic derecho en la consola:

schema — Menú contextual de la consola AD SCHEMA

Ya sabemos cómo podemos acceder a los distintos FSMO, ahora vamos a conocer que hace cada uno de ellos y de qué tarea se encarga, pero antes decir que existe una separación entre estos roles, dos de ellos son únicos a nivel de bosque (FOREST-WIDE FSMO) y los restantes son únicos a nivel de dominio (DOMAIN-WIDE FSMO):

FOREST-WIDE FSMO:

Domain Naming Server/Master: Tenemos que contactar con este FSMO cuando vamos añadir un nuevo dominio al bosque. También necesitamos que esté accesible cuando vamos a crear una nueva Partición de Aplicación (naming context) en el AD. Almacena la lista de dominios que hay creados y las relaciones que hay entre ellos.
Schema Master: Guarda una copia de lectura/escritura del esquema. El resto de copias son de sólo lectura. Para cualquier cambio en el esquema debemos tener acceso al Schema Master.

DOMAIN-WIDE FSMO:

RID Master: Cualquier objeto que creamos en el Directorio Activo tiene un identificador único que se denomina SID (Security Identifier). Esto es lo que identifica un objeto en el dominio. (S-1-0-5-1234-23874837…-354). La parte del principio (hasta el número del último guión) es una parte fija en cada tipo de objeto, y los últimos tres números serán diferentes en un mismo tipo de objeto y se lo que se denomina RID (Realative Identifier). No puede permitir duplicación de SID sobre un mismo objeto. El RID Master asigna a cada DC una pila de RIDs para evitar duplicaciones de SID al crear objetos. No es necesario que esté en pie cuando creamos un objeto ya que a cada DC le da una pila de RIDs para que este DC se los asigne, claramente si se le agota los RIDs a ese DC necesita contactar con el RID Master para que le asigne una nueva pila de RIDs.
Infrastructure Master: Sabe dónde está localizado los controladores de dominio (almacena la estructura física del dominio), para que una máquina o un usuario cuando vaya a iniciar sesión se conecte al controlador más cercano. Controla en qué dominio se encuentra cada objeto. Los objetos en el AD pueden hacer referencia a objetos de múltiples dominios. El Infrastructure Master debe estar accesible siempre que haya cambios en objetos referenciados de otros dominios.
PDC Emulator (Primary Domain Controller): Cumple varias funciones en el dominio:

Se encarga de la replicación rápida de los cambios de contraseñas en el dominio.
Compatibilidad con versiones anteriores a Windows Server 2003.
Origen de tiempos en el dominio. Sincronizar los relojes de los equipos del dominio.
Debe estar accesible cuando vamos a promocionar a DC un equipo.
Es quien crea la estructura de navegación en el dominio. Establece la estructura de recursos a la que podemos acceder desde el nodo Network en File Explorer.
Es quien controla la creación de GPOs.

Fuente: https://administradoresit.wordpress.com/2015/02/22/que-son-los-fsmo/

DHCP con conmutación por error

[ Práctica para realizar el lunes 17/09/2021 ]

Escenario:

Máquina virtual Server 2016 con directorio activo.

Máquina virtual Server 2016 .

Máquina virtual Windows 10.

En Windows Server 2016 se puede configurar un DHCP con conmutación por error y/o balanceo de carga de trabajo. Para hacerlo, necesitamos dos servidores con el rol de DHCP instalado. Sí, pueden ser los dos controladores de Active Directory si tienen capacidad suficiente para hacerlo, no se desplegará ningún clúster ni balanceador de red.

Para hacerlo más sencillo todo, utilizamos una única consola de administración de DHCP para administrar los dos servidores a la vez. Con la consola de administración de DHCP abierta, botón derecho sobre el nombre DHCP y hacer clic en Agregar servidor.

No encontraremos el otro servidor en el listado de servidores DHCP autorizados hasta que no se autorice. No pasa nada, seleccionar este servidor y introducimos el nombre del servidor con el dominio que se resuelva correctamente. Hacer clic en el botón Aceptar.

La consola de administración del DHCP ahora visualiza los dos servidores, el primero, que ya tenemos configurado, y el nuevo, que aún está por autorizar y configurar.

La configuración del DHCP con conmutación por error se hace para cada ámbito. En el servidor primario, desplegar la opción de IPv4 o IPv6, según corresponda. Botón derecho con el ratón y, en el menú, hacer clic en Configurar conmutación por error.

Se inicia un asistente para la configuración de la conmutación por error, pidiendo el ámbito o ámbitos que quieren ofrecer la conmutación por error. Marcar el checkbox Seleccionar todo o bien seleccionar el ámbito concreto. Hacer clic en el botón Siguiente para continuar.

Indicar el servidor DHCP con conmutación por error secundario. Hacer clic en el botón Agregar servidor.

Al igual que se ha hecho para añadir el servidor a la consola de administración de DHCP, añadir el nombre del servidor y hacer clic en Aceptar.

Con el servidor secundario seleccionado, hacer clic en el botón Siguiente para continuar.

Indicar el nombre de la relación para la conmutación de error y el modo de funcionamiento:

Equilibrio de carga. Funcionan los dos servidores a la vez, repartiéndose la carga de trabajo según se indique en la configuración. Se puede dejar perfectamente un 50%. Si se quiere hacer un “semi activo pasivo” pondría una configuración de 75% y 25%.

Espera activa. El otro servidor sólo está al acecho por si pasa algo.

No marcar el checkbox de autenticación de mensajes y establecer un secreto compartido para hacer la relación entre los dos servidores. Hacer clic en el botón Siguiente.

Resumen de la configuración del DHCP con conmutación por error. Hacer clic en el botón Finalizar si todo está correcto.

El asistente aplica la configuración a los dos servidores. Comprobar que todo se haya hecho correctamente. Cerrar la ventana haciendo clic en el botón Cerrar.

Si se observa el servidor de DHCP secundario se puede ver como se han creado los mismos ámbitos que tenemos en el servidor primario. Sin embargo, si el servidor no estaba autorizado no sirve direcciones IP.

Botón derecho encima del nombre del servidor DHCP secundario, hacer clic en la opción Autorizar.

Refrescar la pantalla de configuración pulsando la tecla F5. Ahora ya se ve el IPv4 y IPv6 con el símbolo verde, indicando que todo está funcionando correctamente.

Probando el DHCP con conmutación por error y balanceo de carga de trabajo

Con los servidores DHCP en pleno funcionamiento, iniciamos una nueva máquina en la red. Si se comprueba su configuración IP, en el ejemplo, se observa que el servidor DHCP 192.168.0.2 le ha asignado la dirección IP 192.168.0.201. Desde la consola de sistema, ejecutar el comando:

ipconfig /all

Detener el servicio del servidor DHCP que ha hecho la asignación a la nueva máquina, simulando una caída del servicio. En la consola de administración del DHCP, botón derecho sobre el nombre del servidor, hacer clic en Todas las tareas y Detener.

El equipo anterior, como que ya ha obtenido la dirección IP, la mantiene. ¿Pero que pasa si le hacemos olvidar la dirección IP y renovar de nuevo? Desde la consola de sistema, con privilegios de administrador, ejecutar los comandos.

ipconfig /release && ipconfig /renew

Ha renovado la misma dirección IP que tenía, la 192.168.0.201. ¿Como es posible si el servidor está detenido? Si se mira con detalle de donde ha obtenido esta dirección IP, de nuevo desde la consola del sistema, ejecutar el comando:

ipconfig /all

El servidor DHCP es diferente, ¡es el secundario! Ha hecho lo que esperábamos que hiciera. Con el servidor primario caído, la relación de direcciones IP se mantiene, pero asignándolas al servidor secundario, dando por validada la configuración del DHCP con conmutación por error.

Volviendo todo el sistema a una operativa normal, en la consola de administración del servicio de DHCP, volvemos a arrancar el servicio del DHCP. Botón derecho sobre el nombre del servidor parado, hacer clic en Todas las tareas y Iniciar.

Se puede hacer la prueba invirtiendo los servidores parados y comprobar de nuevo que el servidor DHCP que asigna la dirección IP es el mismo y ofrece la misma dirección IP al equipo que la pide. El resultado vuelve a ser satisfactorio.

Fuente :https://www.jmsolanes.net/es/dhcp-con-conmutacion-por-error/

viernes, 3 de abril de 2020

Unidades Organizativas

[ Teoría a estudiar para desarrollar la práctica de UOs ]

¿Qué es una Unidad Organizativa (Organizational Unit OU)?

Una OU es, al fin y al cabo, un tipo particular y útil objeto de Active Directory contenido en un dominio. Las OUs son útiles porque pueden usarse para organizar cientos de objetos en el directorio dentro de unidades administrables. Usaremos las OUs para agrupar y organizar objetos con propósitos administrativos, como delegar derechos administrativos y asignar políticas para una colección de objetos como una unidad simple.

En un primer resumen:

-Permiten organizar objetos en un dominio

- Nos permiten delegar control administrativo

- Simplifican la administración de los recursos comúnmente agrupados.

Organiza objetos en un dominio:

- Las OUs contienen los objetos del dominio, como cuentas de usuario, equipo y grupos. Archivos e impresoras compartidas publicados en AD también pueden estar dentro de una OU.

Delegar control administrativo:

- Podemos asignar control administrativo, como el control total de permisos sobre objetos de la OU, o de forma limitada a modificar la información de correo electrónico de los usuariosde la OU. Para delegar control administrativo podemos especificar permisos en la propia OU y los objetos que contiene para uno o varios usuarios y grupos.

Simplifican la administración de recursos comúnmente agrupados:

- Podemos delegar privilegios administrativos sobre atributos individuales en objetos individuales de AD, pero normalmente usaremos las OU para delegar esa autoridad administrativa. Un usuario puede tener privilegios administrativos sobre una OU o toas las OUs de un dominio. Utilizándolas podemos crear contenedores que dentro del dominio representen la jerarquía o las estructuras lógicas de la empresa. Podemos entonces administrar la configuración y uso de las cuentas y recursos basándonos en nuestro modelo de organización.

Nombres asociados a las OU:

Distinguimos tres tipos de nombres, nombre completo relativo, nombre completo y nombre canónico, es importante entender la sintaxis de LDAP para cuando usemos scripts para cosulta y administración de AD.

El nombre completo relativo de LDAP identifica unívocamente al objeto dentro su contenedor principal. Por ejemplo, el nombre completo relativo de LDAP correspondiente a una unidad organizativa llamada miOU sería OU=miOU.

El nombre completo de LDAP es globalmente único. Por ejemplo, el nombre completo de una unidad organizativa llamada MiUnidadOrganizativa del dominio microsoft.com sería OU=MiUnidadOrganizativa, DC=microsoft, DC=com.

El nombre canónico se crea de la misma manera que el nombre completo, pero se representa con una notación diferente. El nombre canónico de la OU del ejemplo anterior sería Microsoft.com/MiUnidadOrganizativa.

¿Cómo creamos las OUs?

Abriremos el snap-in de Equipos y usuarios de Active Directory (Active Directory Users and Computers), desde herramientas administrativas o, si la hemos creado, desde una consola MMC en la que tengamos dicho snap-in. Expandimos el nodo del dominio, clic derecho (también podemos hacerlo dentro de la carpeta donde queremos añadir la OU) sobre el nodo del dominio, pulsamos en nuevo y seleccionamos Unidad Organizativa, en el cuadro de diálogo siguiente le damos un nombre a la OU y pulsamos en Aceptar.

Podemos hacerlo también desde la línea de comandos con 'dsadd' si instalamos las windows tools desde el cd de w2k3, directorio support y, podemos ver su uso y parámetros tecleando dsadd /? en una ventana de comandos. En este caso utilizaríamos dsadd ou nombreou <resto parámetros>.

NOTA: Para este procedimiento debemos ser miembros del grupo de Administradores del Dominio o tener delegada correctamente la autoridad apropiada. (Una buena práctica segura es utilizar el comando Run As para hacerlo)