Insbesondere im Rahmen des aktuellsten Microsoft CVE Patches zu CVE-2022-38023 (siehe unser Blog-Beitrag dazu) erreichen uns immer wieder Fragen von unseren Kunden bezüglich NTLM und Kerberos Authentifizierung bei CIFS Sessions. Meistens sind die Fragen von der Form „Ich sehe NTLM Verbindungen auf meinem System – was soll / kann ich dagegen machen?“

In diesem Beitrag wollen wir ein paar Punkte zusammenstellen, wie man NTLM Verbindungen analysiert und an welchen Stellen man Hand anlegen kann um diese (wenn möglich) auf Kerberos umzustellen.

Hier sind ein paar mögliche Ursachen für NTLM-Verbindungen, sowie Maßnahmen, die man ergreifen kann, um diese Verbindungen auf Kerberos umzustellen:

Falscher oder unvollständiger SPN

Nachdem der CIFS Client ein Ticket für einen Dienst beim KDC anfragt, prüft der KDC, ob in der Anfrage der Hostname (oder die IPv4/v6 Adresse, siehe unten) zum Service Principal Name (SPN) passt, welcher im Ziel-Objekt (Computerkonto) hinterlegt ist.

Auf dem Client würde man in einem Netzwerk-Trace die Meldung KRB5KDC_ERR_S_PRINCAPL_UNKOWN finden.

Wie löse ich das Thema?

  • Der DNS Name muss zur IP des LIFs auf dem ONTAP System passen, über das CIFS bereitgestellt wird. Ein DNS Name kann dabei auch auf mehr IPs verweisen. Vorwärts- und Rückwärts-Auflösung müssen sauber funktionieren.
  • Den SPN ggf. anpassen / Duplikate entfernen: https://kb.netapp.com/onprem/ontap/da/NAS/How_to_set_an_SPN

Zugriff über IP-Adresse anstatt den FQDN / Hostname

Wenn man per IP-Adresse auf ein CIFS Share zugreift, dann benutzen Clients per Default immer NTLM, insbesondere also, auch wenn eine Applikation „hardcoded“ per IP auf z. B. ein Share zugreift.

Wie löse ich das Thema?

Eine Lösung ist im Artikel https://learn.microsoft.com/en-us/windows-server/security/kerberos/configuring-kerberos-over-ip beschrieben:

  1. Registry des Windows Systems anpassen, um auch bei Zugriffen über die IP Kerberos zu verwenden, wenn möglich.
  2. Einen SPN mit der IP Adresse im Computer-Objekt hinzufügen.

Port und/oder Netzwerk-Einschränkungen

Das ONTAP System muss auf die Kerberos Ports des DCs zugreifen können, um eine erfolgreiche Kerberos Authentifizierung zu gewährleisten.

Wie löse ich das Thema?

Folgende Ports müssen freigegeben sein:

Von ONTAP zum Domain-Controller:

  • SMB over IP (TCP: 445)
  • DNS (TCP and UDP: 53)
  • LDAP (TCP: 389) (wenn man LDAP mit SASL oder START_TLS verwendet)
  • LDAPS (TCP: 636) (wenn man LDAPS nutzt)
  • Kerberos (TCP and UDP: 88)
  • Kpasswd (TCP and UDP: 464)

Vom Domain-Controller zum ONTAP System:

  • SMB over IP (TCP: 445) (optional: nur wenn man vom DC aus auf die Shares möchte)

User außerhalb der Domain des CIFS Server

Per Design funktioniert die Kerberos Authentifizierung nur mit Usern, welche sich innerhalb der Domain des CIFS Server befinden, oder in einer Domain die per „Trust“ verbunden ist.

Wie löse ich das Thema?

Gar nicht – works-as-designed.

Hier muss man evtl. einen anderen User nutzen, welcher sich in der gewünschten Domäne befindet, oder einen Domänen-Trust aufbauen

Weiterhin Fragen unbeantwortet? Dann stehen wir gerne zur Verfügung!

Von Michael Drüing

Michael ist Senior System Engineer sowie Solution Architect für Storage bei der Advanced UniByte GmbH am Hauptstandort Metzingen. NetApp NCTA, NCDA 7-mode, NCDA ONTAP, NCIE-SAN 7-mode, NCIE SAN ONTAP, NCIE SAN E-Series, NCIE DP, NCSE, NCSE ONTAP Specialist, NAHSE, NCSIE ONTAP, NAMIE, NAMCIP, NASGIE, FlexPod Design Specialist, FlexPod Implementation and Administration Specialist, NCSA Hybrid Cloud, NCHC-IE, NCHC-Architect, Triple SME. Cisco CCNA, CCNP SP, CCS-SP Core, CCS-Advanced Routing

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert