Models and Structure

Interlock contains many models, of which most are not saved in the DRF (Django Rest Framework) Database, but rather used as a passthrough for data-parsing and transformation.

Base Model

File: core/models/base.py

This model should be inherited by any internal DRF models, although it is currently being used only for the User Model as no other local data needs to be saved in the database.

It contains the ability to do both logical and physical deletions of files.

User Model

File: core/models/user.py

The User Model in Interlock’s Django Back-end contains the following fields:

  • id
  • username
  • password (SAVED WITH STANDARD DJANGO HASHING)
  • encryptedPassword (FERNET ENCRYPTED PASSWORD)
  • last_login
  • is_staff
  • is_superuser
  • dn (DistinguishedName)
  • first_name
  • last_name
  • email
  • is_local

Logs

File: core/models/log.py

Logs are a basic model, completely separate from the established Base Model in core/models/base.py, changing specific fields like deleted_at to rotated_at.

DNS Records

Files:

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

For information on how LDAP and ADDS Servers store DNS Records, you can check out the official Microsoft Documentation (Open Specs):

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

Record Types

DNS Records have been mapped according to LDAP RFC Standards and are the following:

  • 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 (Deprecated by RFC) → 7
  • DNS_RECORD_TYPE_MR (Deprecated by RFC) → 9
  • DNS_RECORD_TYPE_MG (Deprecated by RFC) → 8
  • DNS_RECORD_TYPE_MD (Deprecated by RFC) → 3
  • DNS_RECORD_TYPE_MF (Deprecated by 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

Record Field Validators

DNS Records are validated on the Back-end before reaching the LDAP Server with functions in the core/models/dnsRecordFieldValidators.py file.

The following REGEX Validators are being used:

  • natural_validator → Validates Natural Numbers
  • canonicalHostname_validator → Validates TLD Names in Canonical form (with the dot at the end)
  • domain_validator → Validates TLD Names
  • ip_validator → Validates IPv4 Addresses
  • ascii_validator → Validates only ASCII Readable Characters

Record Classes

In the core/models/dnsRecordClasses.py you’ll be able to find all the DNS Record Types and their Byte Data Structures. Some of these have been directly pulled from dirkjanm’s krbxrelay Repository (Github), whilst others have been created and expanded for Interlock’s implementation.

The base of this work would not have been possible without his initial research and implementation, so I’d like to give him special thanks for it.

To know the specs for these data structures refer to the Microsoft Documentation above.

I decided to map these Records, their fields, and display name in the same dictionary for easy access.

Unsupported Records

  • DNS_RECORD_TYPE_SIG
  • DNS_RECORD_TYPE_KEY
  • DNS_RECORD_TYPE_AAAA (IPv6) (Could be supported if requested)
  • DNS_RECORD_TYPE_SIG
  • DNS_RECORD_TYPE_WINS

LDAP Tree

Interlock has two main abstractions, the LDAP Object and the LDAP Tree. They both require a connection to be fetched, but the LDAP Tree is more generic and supports Recursive Searching and data construction for the front-end to consume.

It requires the following arguments to be initialized in a kwargs dictionary:

  • connection [Object] | The LDAP Connection Object
  • recursive [Boolean] | Whether the Tree Data should be fetched recursively
  • ldapFilter [String] | The LDAP Filter to find the Object in the Directory
  • ldapAttributes [List/Array] | The LDAP Attributes to fetch and parse

LDAP Objects

The LDAP Object is an abstraction made to support single object fetching from the LDAP Server(s).

It requires the following arguments to be initialized in a kwargs dictionary:

  • connection [Object] | The LDAP Connection Object
  • ldapFilter [String] | The LDAP Filter to find the Object in the Directory
  • ldapAttributes [List/Array] | The LDAP Attributes to fetch and parse

LDAP Setting

The LDAP Settings Class is an abstraction to support Database saved parametrization.

  • id | (Primary Key), UNIQUE, Auto-incremented
  • name | Internal Name
  • type | Type based on CMAPS Mapping (see core.models.ldap_settings)
  • preset | (Foreign Key to Preset ID)

The following values are only used if the parameter is of the subtype in question.

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

LDAP Preset

  • id | (Primary Key), UNIQUE, Auto-incremented
  • name | Internal Name, UNIQUE, derived from Label
  • label | Admin-User defined Label
  • active | Whether the Preset is active, UNIQUE (only one preset active at any given time), Null/None used if not active.
Last modified at Apr 4, 2024
← Installing the Front-end from Source
Viewsets →