7.1. RPC-über-HTTP-Funktionalität in IDERI note

Der IDERI note Server verwendet MS RPC (Microsoft Remote Procedure Calls) als Middleware, die es Anwendungen wie dem IDERI note Client oder dem IDERI note Administrator ermöglicht, sich auf sichere und authentifizierte Weise mit ihm zu verbinden. Die Verwendung von RPC gestattet die Auswahl zwischen einer Vielzahl von Protokollen, die sowohl historisch sind (IPX/SPX sowohl verbindungsorientiert als auch datagrammorientiert, NetBEUI, NetBIOS über TCP) als auch in einem typischen Active Directory® täglich verwendet werden (Named Pipes, TCP, HTTP). Bis zur Version 3.11 von IDERI note wurden nur Named Pipes und dedizierte TCP-Ports als Protokolle innerhalb der Middleware-Schicht von IDERI note verwendet. Ab Version 4.0 von IDERI note wird HTTP zu dieser Protokollsuite hinzugefügt, die es Anwendungen ermöglicht, sich mit dem IDERI note Server zu verbinden. Die Verwendung des Begriffs „HTTP“ könnte in diesem Kontext irreführend sein, da heute für RPC-über-HTTP statt HTTP tatsächlich HTTPS verwendet wird, wodurch der Datenverkehr, der die Computer mit RPC-über-HTTP verlässt, durch Transport Layer Security (TLS) verschlüsselt wird. Dennoch wird im Rahmen dieser Dokumentation der Begriff RPC-über-HTTP verwendet, da er sich historisch etabliert hat. Es gibt zwei Versionen von RPC-über-HTTP, die für MS RPC veröffentlicht wurden: Version 1 und Version 2. IDERI note unterstützt nur die neueste Version, also Version 2.

Außer dem IDERI note Server selbst unterstützt IDERI note mit der RPC-über-HTTP-Funktion zwei wesentliche Komponenten der IDERI note Produktreihe: Den IDERI note Client und den IDERI note Administrator. Die Unterstützung für dieses Protokoll ist jedoch für beide Komponenten etwas unterschiedlich. Nach einem einführenden Absatz, der die grundlegende Architektur von RPC-über-HTTP und seine Einordnung in die IDERI note Produktreihe behandelt, werden in den nachfolgenden Absätzen dieses Abschnitts die Unterschiede zwischen der Verwendung von RPC-über-HTTP in diesen beiden Komponenten hervorgehoben. Im Rest dieses Abschnitts werden dann Empfehlungen in Bezug auf Gruppenrichtlinieneinstellungen erörtert, die diese Funktionalität beeinflussen könnten, sowie die Einschränkungen, die diese Funktionalität anderen Funktionalitäten von IDERI note auferlegt.

7.1.1. Überblick über die Architektur von RPC-über-HTTP

Während andere Protokolle innerhalb von RPC eine direkte Netzwerkverbindung zwischen einem Client und einem Server verwenden, erfordert RPC-über-HTTP einen speziellen Server, der als Vermittler zwischen diesen beiden Rollen in der Client-Server-Kommunikation fungiert. Dieser spezielle Server wird als RPC-über-HTTP-Proxy bezeichnet. Ein RPC-über-HTTP-Proxy ist normalerweise eine Windows Server-Installation, bei der sowohl IIS (Internet Information Services) als auch die RPC-über-HTTP-Betriebssystemfunktion aktiviert sind, beispielsweise über den Assistenten „Rollen und Features hinzufügen“, der über das Dashboard des Server-Managers gestartet werden kann.

Abbildung 7.1 zeigt eine Übersicht über den Nachrichtenfluss in IDERI note zwischen einer Client-Anwendung (IDERI note Administrator oder IDERI note Client) und dem IDERI note Server bei Verwendung von RPC-über-HTTP als Protokoll.

Übersichtsdiagramm RPC-über-HTTP

Abb. 7.1 Übersichtsdiagramm RPC-über-HTTP

Auf der linken Seite der Abbildung 7.1 ist ein Client-Computer dargestellt, der sich in einem Netzwerk befindet, das über eine Firewall/Router mit dem öffentlichen Internet verbunden ist. Dies könnte das Heimnetzwerk eines Mitarbeiters oder auch ein öffentlicher Internet-Hotspot sein. Auf der rechten Seite dieses Diagramms ist das Unternehmensnetzwerk mit dem IDERI note Server und einem RPC-über-HTTP-Proxyserver in einem großen Dreieck dargestellt. Der Nachrichtenfluss zwischen dem Client-Computer und dem IDERI note Server kann nun wie folgt beschrieben werden:

  1. Eine Client-Anwendung (IDERI note Administrator oder IDERI note Client) auf dem Client-Computer führt einen Remote Procedure Call aus. Diese Netzwerkanfrage wird an den Internet-Router/-Firewall des Clients weitergeleitet.

  2. Der Internet-Router/-Firewall des Clients sendet den Remote Procedure Call über das öffentliche Internet an das Netzwerk des IDERI note Servers.

  3. Die Netzwerk-Firewall im Netzwerk des IDERI note Servers empfängt den Remote Procedure Call.

  4. Die Netzwerk-Firewall sendet den Aufruf an den IIS-Server, der auf dem RPC-über-HTTP-Proxy läuft.

  5. Der IIS-Server, der auf dem RPC-über-HTTP-Proxy läuft, sendet den Remote Procedure Call an den IDERI note Server.

  6. Der IDERI note Server führt den Aufruf aus und sendet seine Antwort an den IIS-Server, der auf dem RPC-über-HTTP-Proxy läuft.

  7. Der IIS-Server, der auf dem RPC-über-HTTP-Proxy läuft, leitet die Antwort an die Netzwerk-Firewall weiter.

  8. Die Netzwerk-Firewall im Netzwerk des IDERI note Servers leitet die Antwort über das öffentliche Internet an den Internet-Router/-Firewall des Clients weiter.

  9. Der Internet-Router/-Firewall des Clients empfängt die Antwort.

  10. Der Internet-Router/-Firewall des Clients sendet die Antwort des IDERI note Servers an die Client-Anwendung (IDERI note Administrator oder IDERI note Client).

Der nächste Abschnitt beleuchtet die richtige Konfiguration des IDERI note Servers und des RPC-über-HTTP-Proxyservers, damit diese erfolgreich zusammenarbeiten können.

7.1.2. Konfiguration des IDERI note Servers für RPC-über-HTTP

Nach einer Erstinstallation lässt der IDERI note Server nur Verbindungen von Client-Anwendungen wie IDERI note Administrator oder IDERI note Client zu, die Named Pipes als Protokoll verwenden. Darüber hinaus können dedizierte TCP-Ports für die Administrationsschnittstelle und die Client-Schnittstelle mithilfe des Systemsteuerungs-Applets der IDERI note Serverinstallation konfiguriert werden. Um eingehende Verbindungen über RPC-über-HTTP von einem RPC-über-HTTP-Proxy-Server zuzulassen, müssen mithilfe des Systemsteuerungs-Applets zwei zusätzliche Ports konfiguriert werden, einer für den Zugriff auf die Administrationsschnittstelle über RPC-über-HTTP und ein weiterer für den Zugriff auf die Client-Schnittstelle über RPC-über-HTTP.

7.1.3. Konfiguration des RPC-über-HTTP-Proxy-Servers

Aus den vorangegangenen Absätzen sollte klar sein, dass für die ordnungsgemäße Ausführung von RPC-über-HTTP sowohl die IIS-Komponente als auch die RPC-über-HTTP-Betriebssystemfunktion auf einem RPC-über-HTTP-Proxyserver installiert sein müssen. Nach einer Standardinstallation beider Komponenten sollten zwei virtuelle Verzeichnisse mit den Namen „Rpc“ und „RpcWithCert“ unter der Standardwebsite des Servers im IIS-Konfigurations-MMC-Snap-In vorhanden sein. Damit RPC-über-HTTP mit Transport Layer Security funktioniert, muss eine zusätzliche Bindung für diese Site mit einem Serverzertifikat konfiguriert werden, das auf dem Clientcomputer als gültig angesehen wird. Diese neue Bindung für https (TLS) kann jeden freien Port auf dem RPC-über-HTTP-Proxyserver verwenden, aber für maximale Kompatibilität für Clients, die Verbindungen über Netzwerke herstellen, die nicht-standardmäßige Ports herausfiltern, ist 443 naturgemäß die beste Wahl. Außerdem ist es erforderlich, integrierte Windows-Authentifizierung im virtuellen Verzeichnis mit dem Namen „Rpc“ zu aktivieren. Zusätzlich empfiehlt es sich, anonymen Zugriff zu deaktivieren.

Ein weiterer wichtiger Konfigurationsaspekt eines RPC-über-HTTP-Proxyservers, um eine Verbindung zu einem IDERI note Server herstellen zu können, ist das Hinzufügen des IDERI note Servers zum Registrierungswert „ValidPorts“ im Schlüssel HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Rpc\RpcProxy auf dem RPC-über-HTTP-Proxyserver. Dies geschieht, indem der Name des IDERI note Servers und die Portnummer, die er zum Empfangen eingehender Anfragen für RPC-über-HTTP verwendet, durch einen Doppelpunkt getrennt, an die durch Semikola getrennte Liste in diesem Registrierungswert angehängt werden. Dieser Port, den der IDERI note Server zum Empfang eingehender Anfragen über RPC-über-HTTP verwendet, sollte nicht mit dem Port verwechselt werden, den der IDERI note Server zum Empfang eingehender Anfragen über TCP verwendet. Er sollte auch nicht mit dem Port (z. B. 443) verwechselt werden, den der RPC-über-HTTP-Proxyserver zum Empfang eingehender Anfragen aus dem Internet verwendet.

7.1.4. Testen einer RPC-über-HTTP-Konfiguration mit IDERI note und rpcping

Vor der Bereitstellung des IDERI note Clients oder IDERI note Administrators kann nach erfolgter Installation und Konfiguration des IDERI note Servers (s.o.) die Konnektivität auf einfache Weise mit einem integrierten Betriebssystem-Befehlszeilentool namens rpcping getestet werden. Nehmen wir für unseren Zweck an, dass der Domänenbenutzer note\albert.tross aus den vorhergehenden Kapiteln auf einer Domänen-Workstation angemeldet ist und wir die Konnektivität von der Domänen-Workstation, die albert.tross verwendet, mit der Client-Schnittstelle des IDERI note Servers über RPC-über-HTTP testen möchten. Wir nehmen außerdem an, dass der Name des IDERI note Servers note-srv01.note.local ist und dass er auf Port 1027 auf eingehende Verbindungen über RPC-über-HTTP auf seiner Client-Schnittstelle wartet. Der Name des von uns verwendeten RPC-über-HTTP-Proxyservers ist dabei srvrpchttp.example.com und er wartet auf Port 444 auf eingehende Verbindungen. In diesem Fall kann von albert.tross der folgende Befehl verwendet werden, um eine funktionierende Verbindung über RPC-über-HTTP zum IDERI note Server zu überprüfen (achten Sie darauf, diesen Befehl in einer einzigen Zeile anzugeben):

rpcping /t ncacn_http /s note-srv01.note.local /e 1027 /o RpcProxy=srvrpchttp.example.com:444 /H 2 /u 10 /a privacy /F 3

Wenn dieser Befehl erfolgreich ist, wird auf stdout in etwa Folgendes ausgegeben, andernfalls ist ein Fehler aufgetreten:

Es wurden 1 Aufrufe in 157 ms
6 T/S oder 157.000 ms/T abgeschlossen.

Es ist wichtig, an dieser Stelle zu verstehen, dass der Name des IDERI note Servers, der in diesem Beispiel note-srv01.note.local ist, auf dem Client-Computer nicht aufgelöst werden muss, damit dieser Aufruf erfolgreich ist. Daher benötigt der Client keinen DNS-Server, der note-srv01.note.local auflösen kann, da es sich um einen DNS-Namen handelt, der nur von Clients aufgelöst werden kann, die direkt mit dem Unternehmensnetzwerk verbunden sind, in dem sich note-srv01.note.local befindet. Der einzige Servername, der auf dem Client-Computer erfolgreich aufgelöst werden muss, ist der des RPC-über-HTTP-Proxyservers, in unserem Fall srvrpchttp.example.com. Die Informationen darüber, mit welchem IDERI note Server eine Verbindung hergestellt werden soll, sind in der Anfrage enthalten, die an den RPC-über-HTTP-Proxyserver gesendet wird, und dieser Server ist dafür verantwortlich, dass dieser Name von seinem DNS-Server aufgelöst wird.

Das Werkzeug rpcping kann auch von einem Clientcomputer verwendet werden, der nicht zur Domäne gehört. Damit dies jedoch funktioniert, müssen die Anmeldeinformationen des Benutzers albert.tross in der Befehlszeile angegeben werden. Um die Konnektivität auf diese Weise festzustellen, kann folgende Kommandozeile eingegeben werden (achten Sie auch hier darauf, diesen Befehl in einer einzigen Zeile anzugeben):

rpcping /t ncacn_http /s note-srv01.note.local /e 1026 /o RpcProxy=srvrpchttp.example.com:444 /P albert.tross,note,* /H 2 /u 10 /a privacy /F 3 /I albert.tross,note,*

Nach Eingabe dieses Kommandos erscheint zweimal eine Aufforderung, das Passwort von albert.tross einzugeben, zuerst für die Authentifizierung am IDERI note Server und anschließend für die Authentifizierung am RPC-über-HTTP-Proxyserver.

Beachten Sie, dass das erste Beispiel in diesem Abschnitt, bei dem albert.tross auf einem Domänencomputer angemeldet ist, nicht funktioniert, wenn die Gruppenrichtlinie „Netzwerksicherheit: NTLM einschränken: Ausgehender NTLM-Datenverkehr zu Remoteservern“ für den Clientcomputer auf „Alle verweigern“ eingestellt ist. Weitere Informationen zu Gruppenrichtlinien in Bezug auf NTLM und RPC-über-HTTP finden Sie in Abschnitt 7.1.7.

7.1.5. Unterstützung von RPC-über-HTTP im IDERI note Client

Der IDERI note Client bietet zwei Unterstützungsmodi für RPC-über-HTTP:

  • Verwendung von Named Pipes oder TCP als primäres Protokoll und RPC-über-HTTP als Fallback-Protokoll

  • Verwendung von RPC-über-HTTP als einziges Protokoll

Im ersten Modus versucht der IDERI note Client, eine Verbindung zu seinem IDERI note Server herzustellen, wobei er entweder Named Pipes oder TCP als primäres Protokoll verwendet. Falls diese Verbindungsmethode fehlschlägt, weil der IDERI note Server nicht erreichbar ist, versucht der Client, sich erneut mit dem IDERI note Server zu verbinden, indem er RPC-über-HTTP verwendet und diese Verbindung aufrechterhält, bis eine erfolgreiche Verbindung mit dem primären Protokoll (Named Pipes oder TCP) wieder möglich ist. Dies ermöglicht ein nahtloses Umschalten von Clients wie Firmenlaptops, die während der Arbeitszeit mit dem Firmennetzwerk verbunden sind, von TCP oder Named Pipes auf RPC-über-HTTP, nachdem der Computer das Firmennetzwerk verlassen hat und schließlich wieder Zugriff auf das öffentliche Internet hat.

Im zweiten Modus versucht der Client, nur über RPC-über-HTTP eine Verbindung herzustellen.

Es versteht sich von selbst, dass beide Modi über Kommandozeilenparameter für inotecln.exe (siehe Abschnitt 9.1) und MSI-Eigenschaften für intclnt.msi (siehe Abschnitt 8.3) gesteuert werden.

7.1.6. Unterstützung von RPC-über-HTTP in IDERI note Administrator und IDERI note QuickAdmin

IDERI note Administrator und IDERI note QuickAdmin verwenden kein aufwendiges Fallback-Schema wie der IDERI note Client. Diese Anwendungen ermöglichen es dem Benutzer stattdessen, zwischen einer lokalen Anmeldung oder Remote-Anmeldungen über Named Pipes, TCP oder RPC-über-HTTP zu wählen. Dies kann entweder über den Anmeldedialog (siehe Abbildung 3.16) oder über Befehlszeilenoptionen (siehe Abschnitte 9.3 und 9.4) erfolgen.

Es ist wichtig, an dieser Stelle festzuhalten, dass für eine erfolgreiche Verwendung von RPC-über-HTTP in diesen Anwendungen der Name des RPC-über-HTTP-Proxyservers und der von ihm verwendete Port durch eine Verkettung des DNS-Namens des RPC-über-HTTP-Proxyservers und ebendieser Portnummer, getrennt durch einen Doppelpunkt, angegeben werden müssen.

7.1.7. Gruppenrichtlinieneinstellungen für RPC-über-HTTP und Kerberos/NTLM

Bis zur Einführung von Active Directory® mit Windows 2000 war NTLM das in Windows-NT-Netzwerken verwendete Authentifizierungsprotokoll. Windows 2000 ersetzte dann NTLM durch Kerberos als bevorzugtes Authentifizierungsprotokoll, und NTLM wurde als veraltetes Protokoll angesehen. NTLM hat im Vergleich zu Kerberos eine Reihe schwerwiegender Nachteile, von denen der Mangel an gegenseitiger Authentifizierung der auffälligste ist. Bei NTLM wird ein Server, mit dem sich ein Client verbindet, nicht wie bei Kerberos gegenüber dem Client authentifiziert, sondern nur der Client gegenüber dem Server. Man könnte jedoch argumentieren, dass dieser Nachteil dadurch gemildert wird, dass RPC-über-HTTP als Beispiel einer Netzwerkanwendung, die NTLM verwendet, heute Transport Layer Security (TLS) verwendet, das die Authentifizierung des RPC-über-HTTP-Proxyservers gegenüber dem Client durch die Natur von TLS als Protokoll ermöglicht, das den Server gegenüber dem Client authentifiziert. NTLM hat im Laufe seiner Existenzjahre ebenfalls eine beträchtliche Weiterentwicklung erfahren, die in der Entfernung von NTLMv1 in Windows 11 und Windows Server 2025 gipfelte. Beachten Sie, dass IDERI note mit RPC-über-HTTP und NTLMv2 auf beiden dieser Betriebssysteme mit Standardeinstellungen für Gruppenrichtlinien funktioniert.

Damit RPC-über-HTTP funktioniert, ist NTLM weiterhin erforderlich, da es hierfür derzeit keine Ersatzoption von Microsoft gibt. Bitte beachten Sie, dass mit den heutigen Standardkonfigurationseinstellungen eines Active Directory® die RPC-über-HTTP-Unterstützung in IDERI note sofort einsatzbereit ist.

Damit NTLM und damit RPC-über-HTTP jedoch in einer ansonsten vollständig kerberisierten Umgebung funktionsfähig sind, sind zwei Gruppenrichtlinieneinstellungen wichtig:

  • Netzwerksicherheit: Beschränken von NTLM: Ausgehender NTLM-Datenverkehr zu Remoteservern

    Wenn diese Option auf „Alle verweigern“ eingestellt ist, kann keine Client-Anwendung auf dem Computer eine ausgehende Verbindung mit NTLM herstellen, sofern keine Ausnahmen definiert sind. Wenn also eine Client-Verbindung über RPC-über-HTTP fehlschlägt und diese Richtlinie auf „Alle verweigern“ eingestellt ist und Sie RPC-über-HTTP verwenden möchten, müssen Sie eine Ausnahme sowohl für Ihren IDERI note Server als auch für Ihren RPC-über-HTTP-Proxyserver definieren.

  • Netzwerksicherheit: Beschränken von NTLM: Remoteserverausnahmen für die NTLM-Authentifizierung hinzufügen

    Mit dieser Richtlinieneinstellung können Sie eine Liste von Servern in Ihrer Organisation angeben, mit denen sich Clients über NTLM verbinden dürfen. Für IDERI note mit RPC-über-HTTP müssen Sie sowohl den IDERI note Server als auch den RPC-über-HTTP-Proxyserver angeben. In den obigen Beispielen für das Dienstprogramm rpcping wäre dies note-srv01.note.local (der IDERI note Server) und srvrpchttp.example.com (der RPC-über-HTTP-Proxyserver).

7.1.8. Einschränkungen beim Betrieb von IDERI note mit RPC-über-HTTP

Da RPC-über-HTTP NTLM als Authentifizierungsprotokoll verwendet, sollten integrierte Konfigurationsoptionen wie der REG_DWORD-Wert „KerberosOnly“ (siehe Abschnitt 10.1) und die entsprechende MSI-Eigenschaft „FORCE_KERBEROS“ (siehe Abschnitt 8.3) für den IDERI note Client auf 0 gesetzt werden, da der IDERI note Client andernfalls die Verbindung zu seinem Server verweigert.

Um in IDERI note einen Alarm an Clients zu pushen, ist eine Verbindung zwischen dem IDERI note Server und dem IDERI note Client unter Verwendung von Named Pipes erforderlich. Da bei Verwendung von RPC-über-HTTP normalerweise keine direkte Verbindung zwischen einem IDERI note Client und seinem Server besteht, ist diese Funktion für Clients, die sich über RPC-über-HTTP verbinden, nicht verfügbar. Aus einem ähnlichen Grund funktioniert die Neusynchronisation mit dem Active Directory® (siehe Abschnitt 7.12) nicht für Clients, die über RPC-über-HTTP mit ihrem Server verbunden sind, da hierfür eine direkte Verbindung vom IDERI note Client zu seinem Domänencontroller erforderlich ist, damit der Client seinen Kerberos-Ticket-Cache leeren und sich unter Verwendung aktueller Gruppenmitgliedschaftsinformationen erneut mit dem IDERI note Server verbinden kann.

Ein weiterer Bereich, in dem RPC-über-HTTP nicht funktioniert, ist die automatische Servererkennung mit einer Abfrage ans Active Directory® nach einem IDERI note Service Connection Point (siehe Abschnitt 2.3). Eine solche Abfrage ans Active Directory® verwendet im Hintergrund Named Pipes, um eine Verbindung zum Domänencontroller herzustellen, was aber in den meisten Fällen, in denen RPC-über-HTTP anwendbar ist, nicht möglich ist.

7.1.9. Betrieb eines RPC-über-HTTP-Proxyservers auf einem IDERI note Gateway Server

Um die Verbindung von Mobilgeräten mit einer IDERI note Infrastruktur zu ermöglichen, ist die Verwendung einer dedizierten Serverinstanz erforderlich, auf der der IDERI note Gateway Service installiert ist (siehe Abschnitt 7.33). Dieser Server kann auch für die Verwendung als RPC-über-HTTP-Proxyserver konfiguriert werden. Wenn jedoch beide Funktionalitäten auf demselben Server betrieben werden sollen, muss eine Auswahl von unterschiedlichen zu verwendenden Ports für beide Serveranwendungen getroffen werden. Das bedeutet: Es ist nicht möglich, den IDERI note Gateway Service mit dem Standardport 443 zu betreiben und zusätzlich die RPC-über-HTTP-Proxyserverfunktionalität auch auf Port 443 zur Verfügung zu stellen, es muss dann ein anderer Port als 443 für die RPC-über-HTTP-Proxyserverfunktionalität verwendet werden.