NAV 2009 R2 - Sicher ist sicher: Der Service Principal Name und der DotNet-Datetyp (RunOnClient)

NAV 2009 R2 - Sicher ist sicher: Der Service Principal Name und der DotNet-Datetyp (RunOnClient)

  • Comments 3

Im Dezember habe ich in einem Artikel über die Nutzung des DotNet-Datentyps anstatt der Tabelle “File” veröffentlicht. Dieser fokussierte auf die Instantiierung der .NET-Klassen auf dem Service-Tier. Dieses Vorgehen ist aus Sicherheitsgründen von Microsoft empfohlen, da ein Server als sicherer gilt als ein Client. Server werden im Allgemeinen in einem Bereich betrieben, dessen physikalischer Zutritt begrenzt ist. Client-Rechner dagegen stehen gerne mal ungesichert in Büroräumen herum oder werden im Flur mit Administrator-Anmeldung vergessen.

Was möchte ich mit dieser etwas provokanten Aussage andeuten? Ich möchte damit einerseits das Bewusstsein für Sicherheit schärfen, als auch bewusst machen, dass es oftmals nicht nur um Funktionalität geht, sondern in vielen Fällen auch um Sicherheit. Leider wird Sicherheit oft genug als hinderlich empfunden. Ich selbst ertappe mich gelegentlich dabei, auf Sicherheitsfeatures zu schimpfen. Die Realität allerdings zeigt uns täglich auf Neue, dass Sicherheit den gleichen Gesetzmäßigkeiten folgt, wie die Menge an Hauptspeicher: Sicherheit ist durch nichts zu ersetzen, abgesehen von noch mehr Sicherheit! Aber genug der Vorrede:

Wird ein DotNet-Datentyp mit der Eigenschaft RunOnClient=Yes auf dem RTC ausgeführt, dann erscheint beim Aufruf, einmalig in jeder Sitzung des Clients, ein Auswahldialog, der zur Bestätigung auffordert:

image

Aus Sicherheitsgründen (da war sie wieder, die Sicherheit) erlauben wir bei der Ausführung nicht, die DotNet-Instanz immer auszuführen sondern jeweils nur für die aktuelle Sitzung. Nach dem Neustart des Client erscheint der Dialog abermals. Möglicherweise verbindet sich der Client ja beim nächsten Start mit einem anderen Dienst in der genau die gleiche Komponente zu anderen, möglicherweise fragwürdigen, Zwecken eingesetzt wird. Aus diesem Grund kann für die Sicherheit der Verbindung und der gelieferten Objekte nicht garantiert werden.

Um dies allerdings zu tun, um also Sicherheit zu “garantieren”, die jeweilige DotNot-Komponente als sicher einzustufen und damit den Dialog zu unterdrücken, muss das Objekt von einem als vertrauenswürdig eingestuften Server geliefert werden. Doch wie stufe ich einen Server als vertrauenswürdig ein? Für den Server bzw. den Server-Dienst muss ein Service Principal Name (SPN) definiert sein. Anleitungen dazu finden Sie sowohl unter How To: Set Up Delegation als auch unter Walkthrough: Installing the Three Tiers on Three Computers zur Einrichtung einer 3-Tier Umgebung. Da nur Administratoren einen SPN setzen können und damit auch nur diese einen Server-Dienst als vertrauenswürdig deklarieren können, wird darüber der Dienst dann als vertrauenswürdig und sicher eingestuft.

Zum Zweiten muss der RTC so konfiguriert sein, dass er nur Verbindungen zu einem mit einem Service Principal Name ausgestatteten Service zulässt. Das erreichen Sie über das Setzen des Schlüssels ServicePrincipalNameRequired auf True in der Client-Konfigurationsdatei in Ihrem Benutzerprofil unter “%LOCALAPPDATA%\Microsoft\Microsoft Dynamics NAV\ClientUserSettings.config”:

image

Nach obiger Konfiguration und dem Neustart des Service-Dienstes und/oder Clients mit Verbindung zu dem vertrauenswürdigen Middle-Tier, werden lokale DotNet-Instanzen ohne den Bestätigungsdialog ausgeführt.

Wichtig ist noch zu erwähnen, dass eine Single Server- bzw. Developer-Installation, unabhängig von einem Service Principal Name, aus Anwendersicht als sicher eingestuft wird, da eine solche Umgebung, wie der Name schon stark vermuten lässt, nur für Entwicklungszwecke herangezogen wird, diese sich aber weitestgehend ähnlich einer Live-Umgebung verhalten soll.

Vielen Dank an Bodo, der mich erst auf diese Möglichkeit hingewiesen hat und mich veranlasste, ein wenig bei meinen Kollegen in Dänemark zu bohren. Smile 

Immer am Ball und auf jeden Fall munter bleiben…

Carsten Scholling

Microsoft Dynamics Germany
Microsoft Customer Service und Support (CSS) EMEA

Email: cschol@microsoft.com
Online Support: www.microsoft.com/support
Sicherheitsupdates: http://www.microsoft.com/germany/athome/security

Microsoft Deutschland GmbH
Konrad-Zuse-Straße 1, D - 85716 Unterschleißheim
http://www.microsoft.com/germany

Leave a Comment
  • Please add 6 and 7 and type the answer here:
  • Post
  • Sehr geehrter Herr Scholling,

    vielen Dank für den Tipp und die Hinweise für die Verwendung der DotNet Variable. Zwei Sachen möchte ich dazu anmerken. Sicherheit ist recht und gut aber:

    Diese Abfrage erscheint nicht wenn man eine Automation verwendet! Eigentlich sind doch Automations meiner Meinung nach doch viel Risikoreicher als der DotNet Datentype oder? Der RTC basiert doch auch dem .Net Framework warum soll dann der in Dynamics NAV programmierte Code Risikoreicher sein?

    Die nächste Anmerkung wäre, woher soll der Anwender einschätzen ob diese externe Komponente gefährlich ist? Es erscheint nicht mal der Name der Komponente die ausgeführt werden soll.

    Der nächste Punkt ist, wenn der Anwender die Ausführung nicht zulässt, funktioniert ja die Funktion nicht oder nur unvollständig.

  • Hallo Markus,

    vielen Dank für Ihre Hinweise, ich möchte im Folgenden darauf eingehen:

    Auch für Automations erscheint eine Abfrage zur Ausführung, sofern die Instanz auf dem Client erzeugt wird.

    Für DotNet Datentypen wird in den Eigenschaften der Variable festgelegt, ob die erzeugte Instanz auf dem Client oder dem Server erzeugt werden soll (RunOnClient), während für Automations der Befehl CREATE selbst, und zwar der dritte Parameter (OnClient), darüber entscheidet, ob eine Instanz auf dem Server oder Client erzeugt werden muss. Die Signatur der CREATE-Funktion:

    [Ok :=] CREATE(Automation [,NewServer] [,OnClient])

    Dabei gilt, sowohl für DotNet- als auch Automation-Datentypen, dass eine Instanz, auf dem Server erzeugt, keine Sicherheitsabfrage zur Folge hat. Auf dem Client dagegen instanziiert, wird eine Meldung in beiden Fällen angezeigt. Die Ausnahme ist, Sie setzen wie von mir im Artikel beschrieben, den Parameter "ServicePrincipalNameRequired" auf "True", um diese für DotNet-Datentypen auszuschalten. Auf lokale Automation-Instanzen hat diese Einstellung keine Auswirkung, diese zeigen weiterhin die Sicherheitsabfrage an, sofern diese nicht mit der "Immer erlauben"-Option für "immer" abgeschaltet wurde.

    Aktuell wird der von Ihnen angesprochenen Unsicherheit von Automations genau auf diese Weise Rechnung getragen.

    BTW: Eine solche Benutzer-Entscheidung kann durch die Funktion "Anpassungseinstellungen löschen" wieder rückgängig gemacht werden, indem Sie im erscheinenden Fenster "Automatisierungseinstellungen zurücksetzen" auswählen.

    Eine Anzeige des Komponentennamens in der Meldung wäre für DotNet-Instanzen auf dem Client sinnvoll, da gebe ich Ihnen Recht. Ein Entwickler könnte diese Meldung interpretieren. Für einen Anwender ist es aber, auch bei Nennung des Komponentennamens, oftmals schwierig bis beinahe unmöglich zu ermitteln, ob eine aufgerufene Komponente sicher, unsicher, wichtig oder unwichtig ist. Möglicherweise wird sich am Design dieses Punktes zukünftig etwas verändern.

    Sofern ein Anwender die Ausführung von DotNet-Komponenten nicht erlaubt, dann stehen möglicherweise einige Funktionen nicht zur Verfügung. Dieser Hinweis wird in der entsprechenden Meldung gegeben. Meiner meinung nach wäre für den Automation-Sicherheitshinweis diese Information ebenfalls sinnvoll.

    Ich hoffe alle Ihre Fragen beantwortet zu haben.

    Viele Grüße,

    Carsten Scholling

  • Hallo Herr Scholling,

    vielen Dank für die Antworten. Dies hat meine Fragen soweit beantwortet.

    Mit freundlichen Grüßen

Page 1 of 1 (3 items)