Modelos y Estructura

Interlock contiene muchos modelos, de los cuales la mayoría no son guardados en la BB.DD. de DRF (Django Rest Framework), sino utilizados para pasaje y transformación de datos.

Modelo Base

Archivo: core/models/base.py

Este modelo debería ser heredado por cualquier modelo interno de DRF, aunque actualmente solo se utiliza para el Modelo de Usuario ya que no se guarda ningún otro dato localmente en la Base de Datos.

Contiene la habilidad de borrarse lógica y físicamente de los archivos.

Modelo de Usuario

Archivo: core/models/user.py

El Modelo de Usuario en el Back-end de Django de Interlock contiene los siguientes campos:

  • id
  • username
  • password (GUARDADO CON EL HASHING DE DJANGO)
  • encryptedPassword (ENCRIPTADA CON FERNET)
  • last_login
  • is_staff
  • is_superuser
  • dn (DistinguishedName)
  • first_name
  • last_name
  • email
  • is_local

Eventos

Archivo: core/models/log.py

Los Logs (Registros de Eventos) son un modelo básico, completamente separado del Modelo Base establecido en core/models/base.py, cambiando campos específicos como deleted_at a rotated_at.

Registros de DNS

Archivos:

  • core/models/dnsRecordClasses.py
  • core/models/dnsRecordFieldValidators.py
  • core/models/dnsRecordTypes.py

Para informarse sobre como guardan Registros de DNS los servidores LDAP/ADDS puede ver la Documentación Oficial de Microsoft (Open Specs):

[MS-DNSP]: Domain Name Service (DNS) Server Management Protocol

Tipos de Registros

Los Registros de DNS fueron mappeados acorde a los estándares de RFC LDAP y son los siguientes:

  • DNS_RECORD_TYPE_ZERO → 0
  • DNS_RECORD_TYPE_A → 1
  • DNS_RECORD_TYPE_NS → 2
  • DNS_RECORD_TYPE_CNAME → 5
  • DNS_RECORD_TYPE_DNAME → 39
  • DNS_RECORD_TYPE_MB (Deprecado por RFC) → 7
  • DNS_RECORD_TYPE_MR (Deprecado por RFC) → 9
  • DNS_RECORD_TYPE_MG (Deprecado por RFC) → 8
  • DNS_RECORD_TYPE_MD (Deprecado por RFC) → 3
  • DNS_RECORD_TYPE_MF (Deprecado por RFC) → 4
  • DNS_RECORD_TYPE_SOA → 6
  • DNS_RECORD_TYPE_TXT → 16
  • DNS_RECORD_TYPE_X25 → 19
  • DNS_RECORD_TYPE_ISDN → 20
  • DNS_RECORD_TYPE_LOC → 29
  • DNS_RECORD_TYPE_HINFO → 13
  • DNS_RECORD_TYPE_MX → 15
  • DNS_RECORD_TYPE_SIG → 18
  • DNS_RECORD_TYPE_KEY → 19
  • DNS_RECORD_TYPE_AAAA → 28
  • DNS_RECORD_TYPE_SRV → 33
  • DNS_RECORD_TYPE_PTR → 35
  • DNS_RECORD_TYPE_WINS → 65281

Validadores de Campo de Registros

Los Registros de DNS son validados en el Back-end antes de llegar al Server LDAP con funciones en el archivo core/models/dnsRecordFieldValidators.py.

Los siguientes validadores REGEX son utilizados:

  • natural_validator → Valida Números Naturales
  • canonicalHostname_validator → Valida Nombres NSG (TLD) en forma canónica (con un punto al final)
  • domain_validator → Valida nombres NSG (TLD)
  • ip_validator → Valida direcciones IPv4
  • ascii_validator → Valida solo Caracteres Legibles en ASCII

Clases de Registro

En core/models/dnsRecordClasses.py podrá encontrar los tipos de Registro de DNS y sus Estructuras de Datos en Bytes. Algunos de estos han sido obtenidos directamente del Repositorio de krbrelayx (Github) de dirkjanm mientras que otros han sido creados y expandidos para la implementacion de Interlock.

La base de este trabajo habría sido imposible sin su investigación e implementación inicial, así que quisiera darle un agradecimiento especial.

Para conocer las especificaciones de estas estructuras de datos, refiérase a la Documentación de Microsoft.

Decidí mappear estos Registros, sus campos, y nombre visible en el mismo diccionario para fácil acceso.

Registros No Soportados

  • DNS_RECORD_TYPE_SIG
  • DNS_RECORD_TYPE_KEY
  • DNS_RECORD_TYPE_AAAA (IPv6) (Puede ser soportado si se lo pide)
  • DNS_RECORD_TYPE_SIG
  • DNS_RECORD_TYPE_WINS

Árbol de LDAP

Interlock tiene dos abstracciones primarias, el Objeto LDAP y el Árbol LDAP. Ambos requieren una conexión para funcionar pero el Árbol LDAP es más genérico y soporta búsqueda Recursiva y Construcción de datos para ser consumidos por el Front-end.

Requiere los siguientes argumentos inicializados en un diccionario de kwargs:

  • connection [Objeto] | El Objeto de Conexión LDAP
  • recursive [Boolean] | Si deben obtenerse los datos del Árbol en forma recursiva
  • ldapFilter [String] | El Filtro LDAP para encontrar el Objeto en el directorio
  • ldapAttributes [Lista] | Los atributos de LDAP a obtener y parsear

Objetos LDAP

El Objeto LDAP es una abstracción hecha para soportar obtención individual de objetos de los Servidores LDAP.

Requiere los siguientes argumentos inicializados en un diccionario de kwargs:

  • connection [Objeto] | El Objeto de Conexión LDAP
  • ldapFilter [String] | El Filtro LDAP para encontrar el Objeto en el directorio
  • ldapAttributes [Lista] | Los atributos de LDAP a obtener y parsear

LDAP Setting

La Clase LDAP Setting es una abstracción para permitir parametrización guardada en base de datos.

  • id | (Clave Primaria), ÚNICO, Auto-incrementado
  • name | Nombre Interno
  • type | Tipo dependiente respecto del Mappeo en CMAPS (véase core.models.ldap_settings)
  • preset | (Clave Foránea al ID del Preset)

Los siguientes parámetros/columnas solo se utilizan si el parámetro es del sub-tipo correspondiente.

  • v_string
  • v_password
  • v_bool
  • v_json
  • v_integer
  • v_tls
  • v_ldap_uri

LDAP Preset

  • id | (Primary Key), ÚNICO, Auto-incrementado
  • name | Nombre Interno, derivado de la etiqueta
  • label | Etiqueta definida por el Usuario Admin.
  • active | Si el Preset está activo, ÚNICO (Solo un Preset a la vez puede estar activo), Null/None es utilizado si está inactivo.