jueves, 19 de diciembre de 2024

Veamos el funcionamiento de Kerberos y su estructura de tickets más afondo por medio de sus mensajes.

  • KRB_AS_REQ: El cliente solicita al KDC un ticket TGT de autenticación.
  • KRB_AS REP: El KDC con el Authentication Server, verifica los datos del cliente y le envía de regreso un ticket TGT cifrado con la clave krbtgt. (KRBTGT = Clave del KDC)
  • KRB_TGS_REQ: El cliente le envía al KDC el ticket TGT cifrado y el nombre del servicio al que quiere acceder. (SPN)
  • KRB_TGS_REP: El KDC con el Ticket Granting Server, verifica la validez del TGT del cliente y le envía de regreso un ticket TGS para el servicio al que quiere acceder.
  • KRB_AP_REQ: El cliente se autentica al servicio con el ticket TGS que ha recibido del KDC.
  • KRB_AP_REP: El servicio se autentica ante el cliente. (Es opcional)

Captura Wireshark

Cliente: IP 10.0.2.10 Windows

Server: IP 10.0.2.5 Controlador del Dominio

Texto

Descripción generada automáticamente

Inicio de sesión en computadora del dominio.



Fuente:https://gerh4rdt.hashnode.dev/kerberos-en-windows-active-directory-tgt-tgs

 

miércoles, 18 de diciembre de 2024

PROYECTO PORTAL CAUTIVO

Escenario del laboratorio:

  • Server 2019
  • Pfsense
  • Máquina W10




Accederemos desde winscp en la máquina W10 para cambiar los ficheros.



Después de cambiar el archivo .










CONFIGURACIÓN DE TRUENAS



lunes, 25 de noviembre de 2024

Restablecer GPOs por defecto

dcgpofix /ignoreschema /target:DC Default Domain Controllers Policy dcgpofix /ignoreschema /target:Domain Default Domain Policy dcgpofix /ignoreschema /target:BOTH

martes, 19 de noviembre de 2024

ACCESOS REMOTOS

 

Accederemos a un recurso compartido para copiar la documentación y los programas a utilizar.





RELACIÓN DE PRÁCTICAS A ENTREGAR DE MOMENTO

 


ADD ATRIBUTOS (futuro)
FSMO
GPO (Continuación) y Asignación de Unidades de Red
Creación y Configuración de GPOs
AGDLP
Permisos Efectivos
Creación de Dominios Raíz
 
Eliminar un Controlador de Dominio (Subdominio)
Compartir Recursos con un Subdominio
Implementar Subdominio
Actualización de Windows Server 2016 a 2019
DHCP Ámbitos Divididos
Instalación y Configuración de Untangle
DHCP Configuración de Conmutación por Error
Diagnóstico de Errores de Replicación de AD
RSAT
Controlador Adicional de Dominio 
 
IPcop como Servidor DHCP
IPcop
Enrutamiento con Windows Server 2016
Server Windows 2016 con AD, DNS y DHCP
Redes en VMware Workstation
VENTOY



lunes, 11 de noviembre de 2024

Add Atributos AD

Añadir atributos a un objeto de la clase Users












PS C:\Users\Administrador> Get-ADUser kk -Properties dni |Where-Object {($_.dni -like "*T")} 

DistinguishedName : CN=kk1,CN=Users,DC=aso,DC=org dni : 13141004T 
Enabled : True 
GivenName : kk Name : kk1 
ObjectClass : user ObjectGUID : 6a55380d-190c-4c2e-9fef-dcc5c43286a0 
SamAccountName : kk SID : S-1-5-21-1837460305-2229785238-1185557869-1108 
Surname : UserPrincipalName : kk@aso.org 

 PS C:\Users\Administrador> Get-ADUser kk -Properties dni |Where-Object {($_.dni -like "*M")} PS C:\Users\Administrador>

Funciones FSMO de Active Directory en Windows

Descarga aquí el ejercicio

martes, 29 de octubre de 2024

Uso Recomendado de Grupos en Dominios Windows Server

Lo primero a tener en cuenta es que existen dos clases de grupos:

  • Grupos Locales: estos grupos son los que podemos crear en cualquier instalación, salvo que sea Controlador de Dominio
    Se pueden usar para asignar privilegios únicamente en la máquina local
    Si la máquina está en grupo de trabajo, es la única posibilidad
  • Grupos de Dominio: estos grupos los creamos y administramos en los Controladores de Dominio del Dominio, normalmente a través de la consola de administración del Dominio
Hay dos temas importantes a tener en cuenta:
  • ¿Cuándo usamos cada uno? más adelante veremos las características de cada uno, y de ahí veremos el uso recomendado
  • Convención de nombres para los grupos: veamos esto primero
Como todos sabemos los grupos se usan principalmente para la asignación de privilegios (permisos y derechos). Siempre es conveniente asignarlos a grupos y no a cuentas individuales. Podemos ahorrarnos mucho trabajo a futuro en la eventualidad de un cambio, o crecimiento de la estructura
Es muy común que los administradores, en el momento de la creación decidan el nombre, sin seguir ninguna regla en especial (“¿cómo me voy a olvidar para qué lo creé?”)
Pero sin embargo pasado un tiempo, o ante cambio o asingación de nuevos administradores, el tema comienza a complicarse
Un caso típico se da cuando un administrador va a crear un grupo, y no recuerda si ya existe otro, con la membresía que necesita. Ante la duda crea uno nuevo
Y el resultado es: grupos que están duplicados, triplicados, y más :-)
A partir de lo anterior, algún administrador quiere comenzar a poner orden, pero ¿cómo identificar los repetidos? ¿lo podré borrar sin consecuencias? ¿cómo sé quién y para qué lo creó?
Y salta inmediatamente las preguntas “¿Cómo puedo saber si determinado grupo se está usando o no?” o “¿Como puedo saber qué permisos tiene el grupo en la red?”
Ninguna de las dos tiene una respuesta fácil, porque generalmente se usa el anidamiento de grupos (grupos dentro de grupos). Luego cualquier búsqueda debe tener en cuenta este anidamiento que puede tener varios niveles
Así que lo primero a tener en cuenta es que es necesario adoptar una buena convención de nombres para los grupos que creemos, que con sólo ver el nombre sepamos qué tipo de grupo es, para qué se creó, qué cuentas contiene, y qué y dónde tiene permisos ¿estamos de acuerdo supongo?
Volviendo al primer punto, debemos ver cuándo usar cada uno. Nombramos antes los Grupos Locales, pero también tenemos los Grupos de Dominio, y éstos tienen muchas más variantes.
Lo primero a tener en cuenta es el tipo, ya que pueden ser de dos diferentes:
  • Grupos de Distribución: no se pueden usar para asignar privilegios. Simplemente si tenemos una aplicación de correo integrada a Active Directory (Exchange) y habilitamos al grupo, podremos enviarle un correo al grupo y lo recibirán todos los miembros
  • Grupos de Seguridad: tienen la misma característica que el anterior con respecto al envío de correos, pero además estos sí los podemos usar para asignar privilegios
Los grupos de Dominio, además del tipo, tienen algo que se llama “Alcance” (Scope) y de acuerdo a éste tienen diferentes características tanto de membresía como del visibilidad (dónde los voy a poder usar para asignarle permisos)
Pongamos una tabla resumen porque escribir uno por uno sería muy largo, y además es interesante verlos comparativamente
Grupos
Hay dos puntos importantes a tener en cuenta:
  • Qué puede contener: ya que esto me dice qué cuentas puedo poner en el grupo (Ver las tres primeras columnas de datos)
  • Dónde lo puedo ver: es decir, dónde lo puedo usar para asignar privilegios
La asignación de privilegios en ambiente Microsoft, tiene algo muy bueno, es sumamente flexible e intuitiva, per esto mismo se puede volver en contra, porque permite hacer casi cualquier cosa sin ninguna planificación
Supongamos situaciones, si alguien no usa grupos y asigna todos los privilegios cuenta por cuenta ¿funcionará? si, por supuesto que lo hará.
Y si sólo agrupo cuentas en Grupos Globales ¿funcionará? si, también lo hará. No voy a seguir repitiendo pero funciona con cualquiera de los ámbitos de grupo, sólo limitará la membresía y el alcance
Pero por supuesto hay ventajas importantes usándolos de una forma planificada, y también teniendo en cuenta el tamaño de la organización y su crecimiento futuro. Es fácil ver que no es lo mismo un ambiente de por ejemplo 20 usuarios, que uno de 500, que de 5000, o de 50000
En un ambiente “pequeño” seguramente no utilizaremos anidamiento de grupos, a diferencia de el uso en organizaciones más grandes. Y análogamente los requerimientos de una organización con varios miles de usuarios repartidos entre varios Dominios en diferentes sitios geográficos  no serán los mismos que los de una pequeña empresa
Voy a centrarme en una empresa mediana, o chica pero que se puede esperar crecimiento a futuro. Cuidado que lo que hoy es una pequeña empresa en un tiempo puede comenzar a ser una mediana empresa, y si nuestra base no está bien hecha comenzarán los problemas de re-organizar todo, que da bastante trabajo.
Sin entrar en una gran disquisición de los motivos, pero créanme que tiene su fundamento, Microsoft recomienda el uso para cada uno de los alcances de grupos
Grupos Locales: única alternativa en ambiente de grupo de trabajo. En ambiente de Dominio, sólo en casos que se necesiten asignar privilegios específicos locales. Ejemplos: que un grupo del Dominio sea administrador local de la máquina, o que un grupo de Dominio pueda ejecutar copias de seguridad o recuperación en un equipo en particular
Grupos Globales: se recomienda utilizarlos para agrupar cuentas con función similar. Por ejemplo, un sector, un cargo, etc.
Grupos Locales de Dominio: se recomienda utilizarlos para asignar privilegios (permisos y derechos)
Grupos Universales: se recomienda la utilización cuando se requiere agrupar Grupos Globales de diferentes Dominios
Resumiendo, para una empresa mediana, la preferencia es:
  • Agrupar por función: cuentas –> Globales (Accounts –> Global Groups)
  • Agrupar por permisos: Grupos Locales de Dominio <– Permisos (DL <– Permissiones
Más resumido: Cuentas –> Grupos Globales –> Grupos Locales de Dominio <– Permisos
O aún más: A–>GG–>DLG<–P
Respecto al uso de Grupos Universales, son muy flexibles pero hay que usarlos con cuidado, ya que bajo determinadas circunstancias pueden aumentar considerablemente el tráfico de red. Básicamente el motivo es porque no sólo el nombre, sino además la membresía será replicada a todos los Catálogos Globales del Bosque.
Y ahora sí, finalmente, si usamos lo anterior podemos pensar en una buena convención de nombres que nos sea útil a nuestras necesidades
Por ejemplo pongo una que he utilizado más de una vez y expongo algunos motivos:
  • En un ambiente multidominio, como la visibilidad puede abarcar a todos ellos sería bueno poner un prefijo que indique en qué dominio se ha creado
  • Como a primera vista no se diferencia si un grupo es Local de Dominio, o Global o Universal, sería bueno que el nombre lo indique
  • Los grupos Globales deberían indicar claramente quiénes son los miembros
  • Los grupos Locales de Dominio deberían indicar claramente sobre qué recurso y qué permisos se le han otorgado
Entonces suponiendo que tuviéramos el Dominio que típicamente usa Microsoft para su demostraciones y cursos que se llama Contoso, una posibilidad de definir nombres de grupos podría ser:
CON-GG-HR_Central
Creo que es fácil deducir que está creado en el Dominio “Contoso” (CON), que es de tipo Global (GG), y que contiene al personal de recursos humanos (HR) del sitio central (Central)
Fácilmente podría distinguir el anterior de uno que se llame SUB-GG-Mkt_Pers
Y como los Locales de Dominio se utilizarán para dar permisos entonces se podría hacer algo así:
CON-DL-Prod_DB-R
Le agrego la sigla de dominio (CON) sólo para ser consistente ya que estos grupos no podrán ser vistos en otros Dominios, DL me indica que es un grupo Local de Dominio (Domain Local), que tiene permisos sobre la base de producción (Prod_DB) y el permiso es de lectura (R=Read)
Para crear un grupo que necesite permiso de cambios sobre el recurso, utilizaría por ejemplo: CON-DL-Prod_DB-CH (CH=Change)
Y todavía podemos agregar un par más de consideraciones. Primero, recordemos que aunque podemos extendernos, serán visibles los primeros 20 caracters de los nombres de un grupo.
Y segundo, recordemos que en las propiedades de cada grupo tenemos dos campos disponibles que podemos usar a nuestra conveniencia: Descripción y Notas

Práctica de estrategia de grupos AGDLP

Resolución