Upgrade auf v0.0.3

Synit ADProxy v0.0.3 ersetzt den globalen Entwicklungsmodus durch einzelne, klar begrenzte Sicherheitsoptionen. Prüfen und validieren Sie jede HCL-Datei vor dem Rollout.

Entfernte Blöcke und Felder

Diese Konfiguration wird nicht mehr akzeptiert:

dev {
  insecure = true
}

tls {
  cert_file      = "/etc/adproxy/tls/server.crt"
  key_file       = "/etc/adproxy/tls/server.key"
  client_ca_file = "/etc/adproxy/tls/client-ca.crt"
}

Auch server.allow_anonymous ist entfernt. Der Loader bricht bei diesen alten Optionen mit einem Migrationshinweis ab.

Authentifizierung ist immer erforderlich

adproxy-server startet nur mit server.auth_token oder mindestens einem benannten server.auth_token Block. Anonyme API-Zugriffe sind nicht mehr möglich. Nur der Readiness-Endpunkt /readyz bleibt ohne Authentifizierung erreichbar.

Nutzen Sie für benannte Clients bevorzugt secret_ref:

server {
  listen_addr = "127.0.0.1:8765"

  auth_token "workflow-reader" {
    secret_ref = "env:ADPROXY_API_READ_TOKEN"
    access     = "read-only"
  }
}

Plain HTTP bleibt lokal

Ohne server.tls muss server.listen_addr auf localhost oder eine Loopback-IP zeigen. Für andere Bind-Adressen konfigurieren Sie HTTPS direkt:

server {
  listen_addr = "0.0.0.0:8765"

  tls {
    cert_file  = "/etc/adproxy/tls/server.crt"
    key_file   = "/etc/adproxy/tls/server.key"
    chain_file = "/etc/adproxy/tls/intermediate-chain.crt" # optional
  }

  auth_token "workflow-writer" {
    secret_ref = "env:ADPROXY_API_WRITE_TOKEN"
    access     = "read-write"
  }
}

chain_file enthält PEM-kodierte Zwischenzertifikate. Zertifikat, Key und Chain werden beim Start geladen. Nach einer Zertifikatsrotation muss der Service neu gestartet werden. Client-Zertifikat-Authentifizierung ist nicht implementiert; HTTP-Tokens bleiben Pflicht.

LDAPS-Prüfung gezielt steuern

Die normale LDAPS-Zertifikatsprüfung bleibt aktiv. Eine interne CA und ein abweichender Zertifikatsname werden weiterhin explizit konfiguriert:

directory {
  tls {
    ca_file     = "/etc/adproxy/tls/ad-ca.pem"
    server_name = "dc1.example.test"
  }
}

Wenn eine kontrollierte Ausnahme nötig ist, kann directory.tls.insecure_skip_verify = true unabhängig von einem Entwicklungsmodus gesetzt werden. ADProxy protokolliert beim Start eine Warnung. Die Ausnahme sollte zeitlich begrenzt und im Betriebsprozess dokumentiert sein.

Vor dem Rollout prüfen

1. Alle dev und Top-Level-tls Blöcke entfernen.
2. server.allow_anonymous entfernen und mindestens ein HTTP-Token konfigurieren.
3. Nicht lokale Listener mit server.tls absichern.
4. Optionale Zwischenzertifikate über server.tls.chain_file bereitstellen.
5. LDAPS-Ausnahmen ausschließlich über directory.tls.insecure_skip_verify setzen.
6. adproxy-server validate-config -config <pfad> ausführen.

Die vollständigen Felder stehen in der Konfigurationsreferenz. Änderungen für den separaten MCP-Prozess stehen im AD MCP Upgrade auf v0.0.3.