Qué están haciendo y qué pueden afirmar
Su investigación evalúa una arquitectura IAM experimental en un entorno universitario simulado. Integra un directorio Samba Active Directory, permisos basados en roles (RBAC) y automatización declarativa con Ansible. La evaluación contempla cinco dimensiones: centralización, administración de accesos, control de permisos, automatización y trazabilidad.
La metodología JUDC 2026 permite informes en proceso. Se debe indicar con transparencia el alcance ejecutado, las dificultades y los pasos pendientes.
Inconsistencia por resolver: el expediente menciona 2,000 identidades como escala objetivo y 40 identidades en apartados de pruebas. Deben explicar si 40 es una muestra piloto y 2,000 es la carga prevista, o corregir ambos valores conforme al protocolo real; asimismo, especificar si se cuentan cuentas de usuarios, equipos o ambos.
Qué producir, cómo nombrarlo y dónde guardarlo
Trabajen en la carpeta oficial del expediente: Abrir Google Drive del proyecto ↗. Conserven intactas las versiones históricas de la tesis. Creen una carpeta adicional 05 - JUDC 2026 y preparen los entregables de la participación.
| Producto | Qué debe contener | Validación del tutor |
|---|---|---|
| Informe JUDC V01 | Secciones oficiales, datos de autores, avances y referencias | Coherencia científica y redacción |
| Matriz de trazabilidad | Objetivo → actividad → resultado → evidencia → estado | Nada se declara completado sin respaldo |
| Diseño IAM | Topología, IP, DNS, equipos, servicios, relaciones | Coherencia y factibilidad |
| Modelo RBAC | 8 roles, 24 grupos, 40 permisos, 10 recursos, 20 políticas: estado real y mapeos | Menor privilegio y reglas comprobables |
| Registro de pruebas | Procedimiento, resultado esperado, obtenido, evidencia, fecha | Reproducibilidad y cálculo correcto |
Cómo completar cada sección del informe
Respetar la secuencia de la estructura adjunta JUDC. Formato: Times New Roman 12, interlineado 1.5, alineación justificada donde corresponde; portada con los datos institucionales y ORCID de cada autor; título entre 15 y 20 palabras.
Incluir marca institucional, Área de Conocimiento, departamento, carrera, título, autores, ORCID, tutor y fecha real de presentación. Crear índice automático de Word; no reutilizar el índice de la tesis.
Un solo texto que presente: contexto/problema (2–3 frases), objetivo, diseño metodológico, avances verificables, resultados preliminares si existen, limitaciones y cierre provisional. Sin citas, tablas, figuras ni abreviaturas sin desarrollar. Redactarlo al final, después de recopilar los resultados.
De lo general a lo particular: identidades dispersas → problemas de administración/seguridad → necesidad de IAM → arquitectura propuesta → entorno universitario simulado. Describir beneficiarios potenciales sin afirmar impacto institucional medido.
Para cada antecedente: autor/año, problema, método, hallazgo verificable y aporte/contraste con la investigación. Comprobar datos bibliográficos en la publicación original; no afirmar que la propuesta “supera” a otra tecnología sin comparación experimental.
Conservar el objetivo general aprobado y los cuatro específicos: (1) analizar requerimientos, (2) diseñar arquitectura, (3) desarrollar prototipo, (4) evaluar mediante escenarios e indicadores. Identificar cuáles tienen evidencias completadas.
Definir IAM, ciclo de vida de identidades, autenticación vs. autorización, LDAP/Kerberos/DNS, Samba AD, RBAC, Ansible, idempotencia, virtualización, auditoría y trazabilidad. Explicar cómo cada concepto se aplica al experimento; citar APA 7.
Conservar hipótesis únicamente si el diseño realmente permite contrastarlas mediante criterios explícitos. No confundir “porcentaje observado” con prueba estadística de hipótesis. Si se utiliza un umbral de aceptación, acordarlo y justificarlo antes de las mediciones.
Tabla de cinco dimensiones con definición operativa, unidad observada, indicador, fórmula, herramienta y evidencia. Especificar tamaño de muestra, universo, unidades de análisis y criterios para contar éxitos/fallos.
Precisar enfoque, alcance, entorno controlado, recursos físicos, población/muestra, procedimiento piloto, pruebas definitivas, instrumentos, método de análisis descriptivo y controles para repetir las pruebas.
Organizar por objetivos: requisitos definidos, arquitectura documentada, prototipo efectivamente configurado, ensayos medidos. Incluir tablas de resultados reales, errores, limitaciones y contraste con antecedentes. Si no existen resultados, escribir “avance de diseño/metodología” y declarar pendiente su evaluación.
Conclusiones parciales estrictamente relacionadas con objetivos cumplidos y evidencia. Recomendaciones como tareas científicas y técnicas pendientes, no promesas de efectos no comprobados.
APA 7, citas que coincidan con las fuentes reales. En anexos: diagramas, tablas RBAC, fichas de pruebas, reportes y bitácoras que permitan corroborar resultados; proteger nombres reales, contraseñas, claves y tokens.
Arquitectura IAM: del diagrama al laboratorio funcional
La tesis plantea Proxmox VE, VMware ESXi, Samba Active Directory, Ansible y servicios WEB01, DB01, MOODLE01, LAB1 y LAB2. Estos nombres son parte del diseño; el equipo debe demostrar cuáles componentes realmente existen y están conectados.
| Etapa | Qué hacer | Cómo comprobarlo | Evidencia |
|---|---|---|---|
| 1. Infraestructura | Actualizar inventario de PC1/PC2, CPU, RAM, discos, hipervisores, virtuales, redes y direccionamiento | Capturas de paneles y comandos de sistema | EV-INF-01 |
| 2. Conectividad | Definir segmento de laboratorio, puerta de enlace, DNS, rutas, nombres y reglas de firewall | ip a, ip route, ping, dig (si aplica) | EV-NET-01 |
| 3. Dominio | Instalar y configurar Samba AD DC en VM aislada; verificar servicio de DNS y Kerberos | samba-tool domain info 127.0.0.1, dig registros SRV | EV-AD-01 |
| 4. Directorio | Crear estructura OU, cuentas sintéticas y grupos según diseño aprobado | samba-tool user list, samba-tool group list, consultas LDAP | EV-AD-02 |
| 5. RBAC | Aplicar membresías y reglas de acceso reales en recursos; documentar la capa que hace cumplir cada permiso | Intentos permitidos y denegados por rol | EV-RBAC-01 |
| 6. Ansible | Crear inventario de hosts, variables, playbooks con verificaciones y control de versiones | Ejecución inicial, repetida y tras modificación autorizada | EV-ANS-01 |
| 7. Auditoría | Activar registros relevantes, sincronizar reloj y correlacionar operación, actor, objeto y resultado | Bitácoras del controlador, recursos y automatización | EV-AUD-01 |
| 8. Evaluación | Ejecutar escenarios reproducibles con datos de prueba y registrar fallos además de aciertos | Matriz + métricas + evidencia | EV-PRU-01 |
Comprobaciones técnicas ilustrativas
# En el controlador de dominio (comandos de lectura) samba-tool domain level show samba-tool user list samba-tool group list samba-tool group listmembers GG-Docentes # Sustituir campus.lan por el dominio REAL del laboratorio dig @IP_DEL_DNS _ldap._tcp.campus.lan SRV dig @IP_DEL_DNS _kerberos._udp.campus.lan SRV # En nodo de automatización ansible-inventory --graph ansible-playbook --syntax-check iam.yml ansible-playbook -i inventario.ini iam.yml --check
--check anticipa cambios, no prueba que la ejecución real funcionó. Cada módulo y cada recurso puede tener distinta compatibilidad con el modo de comprobación. Usar identidades sintéticas y ejecutar cambios únicamente en máquinas autorizadas de laboratorio. Nunca publicar contraseñas o secretos en el sitio o los anexos.Pregunta que deben responder antes de avanzar
¿En qué servicio se aplica realmente cada permiso? Samba AD puede centralizar identidades y grupos, pero no convierte automáticamente a WEB01, DB01, Moodle, ESXi o Proxmox en servicios gobernados por RBAC. Cada integración necesita un mecanismo de autenticación/autorización comprobable y un responsable de implementación.
RBAC, objetos y políticas: convertir la hoja en reglas verificables
La hoja existente propone 8 roles, 24 grupos, 40 permisos, 10 recursos y 20 políticas. Son magnitudes de diseño, no logros de funcionamiento. Completar la relación formal entre roles, permisos y recursos.
| Rol | Grupo de referencia | Operación esperada | Prueba negativa |
|---|---|---|---|
| Docente | GG-Docentes | Acceder al recurso académico autorizado | Denegar administración del servidor DB01 |
| Estudiante | GG-Estudiantes | Usar recurso de laboratorio permitido | Denegar edición de grupos administrativos |
| Admin Web | GG-Admin-Web | Administrar WEB01 | Denegar administración de DB01 |
| Admin BD | GG-Admin-BD | Administrar DB01 | Denegar administración de WEB01 |
La tabla presenta casos propuestos para orientar el diseño; deben validarse contra el alcance real, la matriz oficial y los mecanismos disponibles.
Matriz que deben construir
Campos mínimos: ID_prueba · rol · usuario_sintético · grupo · recurso · acción · decisión_esperada · decisión_obtenida · mecanismo_de_control · evidencia · estado. Las autorizaciones deben probarse tanto con accesos permitidos como con denegaciones.
Revisión de las 20 políticas
Cada política debe pasar de nombre genérico a regla comprobable: código, objetivo, condición, ámbito, forma de implementación y caso de prueba. Las configuraciones de contraseña, expiración y bloqueo propuestas en el inventario no deben tratarse como estándares recomendados por defecto; deben justificarse según el contexto y las normas aplicables.
Cómo ejecutar y documentar las pruebas
Antes de cada medición: identificar versión de configuración, hora sincronizada, VM, usuario sintético, condiciones iniciales y resultado esperado. Repetir cada caso bajo el mismo protocolo; documentar las incidencias.
| Dimensión | Prueba mínima útil | Qué registrar | Cómo confirmar |
|---|---|---|---|
| Centralización | Consultar una muestra definida de identidades, validar atributos, grupos y estado | N evaluadas, N correctas, causa de errores | LDAP / samba-tool |
| Administración | Alta, modificación, deshabilitación y revocación de una cuenta sintética | Operaciones y estados antes/después | Consultas independientes al directorio |
| RBAC | Acceso autorizado y no autorizado por cada rol seleccionado | Decisión esperada vs. observada | Respuesta del recurso y sus logs |
| Automatización | Ejecutar playbook, verificar cambios, repetir sin modificar entradas | Tiempos, éxito/fallo, número de cambios en segunda ejecución | Salida Ansible y estado final |
| Trazabilidad | Generar eventos controlados: alta, baja, cambio de grupo y acceso | Actor, objeto, acción, hora, resultado e ID de prueba | Registros correlacionables |
Ficha individual de ensayo
ID: PR-RBAC-001 Objetivo específico: OE4 Dimensión: RBAC Fecha y hora: [registrar] Versión de laboratorio: [registrar] Actor/cuenta sintética: [registrar] Recurso: [registrar] Precondición: [estado comprobado] Procedimiento: [pasos exactos] Esperado: ACCESO DENEGADO Observado: [registrar sin alteraciones] Estado: CORRECTO / INCORRECTO / NO EJECUTADO Registro o captura: [ruta/enlace] Incidencias: [registrar] Verificador: [nombre del responsable]
Fórmulas y calculadora de resultados
Las cinco fórmulas porcentuales y la comparación temporal provienen del planteamiento metodológico actual de la tesis. Solo se calculan sobre datos efectivamente observados, indicando muestra, denominador y fecha. La calculadora de esta página sirve para comprobar operaciones, no almacena resultados oficiales.
| Dimensión | Indicador | Numerador / denominador |
|---|---|---|
| Centralización | Identidades correctas (%) | Identidades que cumplen todos los criterios / identidades evaluadas |
| Administración | Operaciones correctas (%) | Operaciones que produjeron el estado esperado / operaciones ejecutadas |
| RBAC | Decisiones correctas (%) | Autorizaciones o denegaciones acertadas / pruebas de autorización |
| Automatización | Automatización correcta (%) | Operaciones automatizables completadas correctamente / operaciones automatizables evaluadas |
| Trazabilidad | Eventos trazables (%) | Eventos con todos los criterios exigidos / eventos generados |
Ingrese conteos reales (o explore ejemplos sin copiarlos como resultados).
Valor positivo: reducción del tiempo; negativo: aumento del tiempo.
Comparación temporal
Idempotencia y consistencia
Para Ansible, verificar el estado final tras ejecutar una tarea y luego repetir el playbook con entradas idénticas. Si la segunda ejecución reporta cambios, investigarlos. Un indicador auxiliar propuesto (no presente como indicador formal en la tesis) podría ser:
Definir previamente qué se considera “cambio inesperado”; usar esta métrica como apoyo técnico, sin sustituir los cinco indicadores formales del estudio. Para tiempos, registrar varias repeticiones, promedio y dispersión descriptiva, distinguiendo ejecución en frío y en caliente.
Fórmulas de hoja de cálculo
Excel / Google Sheets (configuración regional con comas): =IFERROR(C2/D2*100,"") =IFERROR((E2-F2)/E2*100,"") =AVERAGE(G2:G11) =STDEV.S(G2:G11) Columnas sugeridas: A: ID_prueba | B: Dimensión | C: Correctos | D: Total E: Tiempo_manual_s | F: Tiempo_Ansible_s | G: Repetición_s
Si su configuración regional usa punto y coma, sustituyan los separadores de argumentos. El valor vacío indica que no hay denominador válido, no que el resultado es 0%.
Cómo convertir evidencias en resultados científicos
Cada ensayo debe registrar hora, entorno, identificador, dato esperado, observado y localización de logs o captura. Incluyan también pruebas fallidas.
Agrupar ensayos ejecutados por dimensión y calcular denominadores únicamente con pruebas válidas realizadas. Los no ejecutados se reportan aparte.
Para cada tabla: qué muestra, qué se esperaba, qué ocurrió, qué falló y qué factores pudieron influir. Diferenciar interpretación técnica de observación directa.
Comparar hallazgos propios con antecedentes realmente verificados. No alegar mejoras frente a Keycloak, Entra ID o soluciones comerciales si no se diseñó un experimento comparativo.
Si la evidencia solo prueba creación de OU y grupos, concluir que la estructura de directorio fue preparada; todavía no concluir que la política RBAC funciona o que el sistema escala a 2,000 identidades.
Matriz de trazabilidad por objetivo
| Objetivo | Producto demostrable | Evidencia exigida |
|---|---|---|
| OE1 · Requisitos | Requisitos técnicos y criterios | Tabla de necesidades, criterios y justificación |
| OE2 · Diseño | Arquitectura IAM y modelo de objetos | Diagrama, inventario, matrices, políticas |
| OE3 · Desarrollo | Instalación y configuración real | Versiones, salidas, scripts, capturas y configuración |
| OE4 · Evaluación | Pruebas y resultados cuantitativos | Protocolos, datos crudos, cálculos, análisis |
Cuándo avanzar y qué desbloquea el siguiente paso
Se propone una secuencia de ejecución, no un calendario oficial. Las fechas de cada entrega deberán ser fijadas por el tutor de acuerdo con el cronograma institucional de la JUDC.
Hito 1 · Alineación documental
Resolver contradicción 40/2,000, depurar objetivos/hipótesis e inventario. Salida: metodología corregida y matriz de trazabilidad.
Hito 2 · Diseño técnico completo
Entregar topología versionada, OU, roles, grupos, matriz rol–recurso–permiso y políticas verificables. Salida: diseño aprobable antes de pruebas.
Hito 3 · Prototipo verificable
Demostrar conectividad, dominio, identidades y autorización efectiva donde se haya integrado. Salida: configuración y evidencias de funcionamiento.
Hito 4 · Automatización y pruebas
Ejecutar casos de Ansible, acceso y auditoría; medir y registrar todos los resultados. Salida: matriz de pruebas validada.
Hito 5 · Informe JUDC
Redactar secciones oficiales y resumen final basados en evidencias. Salida: V01 para observaciones, V02 corregida y versión autorizada para presentación.
Lista de verificación antes de entregar
Marquen únicamente lo comprobado. El avance se almacena solo en este navegador; no se transmite al docente, no modifica Google Drive ni constituye evidencia académica.
Fuentes que deben consultar
Documentos institucionales adjuntos por el tutor: Documento Base JUDC 2026_Ultima_VersiónRevision2.docx (metodología XLIV JUDC, octubre 2026) y Estructura para informe de investigación.docx. El segundo establece el orden y formato oficial del informe; el primero reconoce los informes en proceso y contiene disposiciones sobre el uso ético de IA.
Expediente: carpeta oficial, especialmente General_Tesis_12-10-2026.docx, Justificación Identidades.docx y Objetos de directorio parte1.xlsx.
Guía académica de trabajo · Expediente MG-TEL-20260812-001 · Edición inicial 16/10/2026 · Sitio estático sin servicios externos ni recopilación de datos.