it-swarm.com.de

Wie kann ich 32-Bit-COM-Objekte in classic ASP nach der Installation von Windows Update KB4340558 ordnungsgemäß instanziieren?

Unter Windows Server 2012 R2 können wir nach der Installation von Update KB4340558 (Updateverlauf)/ KB4338424 (installierte Updates) keine .NET .DLLs (Interop) mehr in klassischem ASP im 32-Bit-Modus mit server.createobject. Wir erhalten den Fehler 0x800A01AD "ActiveX-Komponente kann Objekt nicht erstellen"

Wenn wir das Update deinstallieren, verschwindet der Fehler. Trotz aller Bemühungen konnte ich keine alternative Lösung für die Deinstallation finden. Wir würden es vorziehen, das Update erneut zu installieren und alle erforderlichen Änderungen an Windows Server und/oder den DLLs vorzunehmen, damit die COM-Objekte ordnungsgemäß instanziiert werden können. Es gibt keine Hinweise in den Systemprotokollen, keine Hinweise in der CVE-Datenbank und keine Hinweise in den Fehlern, die ASP generiert. Bitte helfen Sie!

30
user2458080

Wir waren auch von mehreren Kunden betroffen.

Ich habe ausgeschlossen, dass unsere Assemblys mit ungültigen starken Namen signiert wurden, da auch die .NET-Assemblys aus dem Framework selbst von diesem Fehler betroffen waren, bei dem der Zugriff verweigert wurde.

Schließlich gelang es mir, das Problem durch Konfiguration zu lösen. Anscheinend muss die authentifizierende Identität der Website nun mit der Identität des App-Pools übereinstimmen. Oder IUSR hat nicht mehr genügend Berechtigungen.

enter image description here

EDIT: 19.07.2018

Warnung! Diese Änderung hat auch einen Nebeneffekt:

Das asp-classic-Ereignis "Session_OnEnd" wurde nicht mehr aufgerufen und Ressourcen konnten daher schließlich nicht mehr freigegeben werden. Aber auch dafür gibt es eine Lösung!

Die ASP-Config-Eigenschaft "system.webServer/asp/runOnEndAnonymously" muss "false" sein, dann wird das Ereignis erneut ausgelöst.

enter image description here

EDIT 2: 23.07.2018

Wie Dijkgraaf hervorhob, betrachtet Microsoft dieses "neue Verhalten" nun als einen Fehler. Ich denke also, meine "Lösung" sollte jetzt als Problemumgehung betrachtet werden, bis ein neuer Patch zur Rettung kommt.

34
keydon

Wir führen unseren Anwendungspool unter einer bestimmten Identität aus, um eine Netzwerkfreigabe und einen Datenbankzugriff zu ermöglichen. Ich dachte auch, wir stecken fest, nachdem wir @ keydons Antwort oben gelesen hatten.

Es gibt jedoch drei Stellen, an denen wir die Identität konfigurieren müssen:

  • Der Anwendungspool - sollte die spezifische Identität verwenden
  • Die Website "Connect As" - sollte die "Application Pool Identity" verwenden
  • Die Option Anonyme Authentifizierung unter der Authentifizierungsfunktion sollte "Anwendungspoolidentität" verwenden.

Das letzte war das, was uns fehlte - Jahre, in denen wir nur die ersten beiden berücksichtigten, bedeuteten, dass wir die oben genannten guten Ratschläge falsch verstanden hatten.

17
TimP

Microsoft ist sich des Problems bewusst und die relevante KB lautet Fehler "Zugriff verweigert" und Anwendungen mit COM-Aktivierung schlagen nach der Installation der Rollup-Updates für Sicherheit und Qualität für .NET Framework vom Juli 2018 fehl

Dies hat Auswirkungen auf BizTalk, SharePoint, IIS mit klassischen ASP= und .NET-Anwendung, die Identitätswechsel verwendet.

Problemumgehungen für Classic ASP lauten wie folgt

IIS Hosted Classic ASP beim Aufrufen von CreateObject for .NET COM-Objekten wird möglicherweise der Fehler "ActiveX-Komponente kann Objekt nicht erstellen" angezeigt:

  • Wenn Ihre Website die anonyme Authentifizierung verwendet: Ändern Sie die Anmeldeinformationen für die anonyme Authentifizierung der Website, um die "Anwendungspoolidentität" zu verwenden.
  • Wenn Ihre Site die Standardauthentifizierung oder die Windows-Authentifizierung verwendet: Melden Sie sich einmal als Anwendungspoolidentität bei der Anwendung an, und erstellen Sie eine Instanz der .NET COM-Komponente. Danach können andere Site-Benutzer die .NET COM-Komponente ohne Fehler aktivieren.
  • Wenn Sie alternativ die Windows-Authentifizierung verwenden und über die Konsole von Windows Server auf die Website zugreifen, auf der die Anwendung ASP) ausgeführt wird: Durch das Erstellen einer Instanz der .NET COM-Komponente wird auch ein Fehler für eine andere Site behoben Benutzer.
8
Dijkgraaf

Dies dient nur zur Bestätigung der von keydon bereitgestellten Lösung, kombiniert mit der von TimP bereitgestellten. Und danke ihnen !!

In unserem Fall haben wir die folgenden 3 Teile geändert (und einen zusätzlichen vierten für neue Berechtigungen):

  1. Eigenschaften der Webserverauthentifizierung: Legen Sie die anonyme Authentifizierung mit "Anwendungspoolidentität" anstelle von "Bestimmter Benutzer" fest.

  2. Eigenschaft "Identität" des Anwendungspools: Auf "ApplicationPoolIdentity" anstelle von "LocalSystem" setzen.

  3. Website "Verbinden als" für physischen Pfad: Wählen Sie "Anwendungsbenutzer (Passthrough-Authentifizierung)" anstelle von "Bestimmter Benutzer".

  4. Fügen Sie dem freigegebenen Ordner, in dem sich die Webanwendungsdateien befinden, Berechtigungen für " Anwendungspoolidentitätsbenutzername " hinzu. Schauen Sie sich https://docs.Microsoft.com/en-us/iis/manage/configuring-security/application-pool-identities#securing-resources an

Vielen Dank!! (Es tut mir leid, dass ich Ihre Lösungen nicht bewerten kann, weil ich Anfänger bin und keinen Ruf habe.)

4
Jose Salort

Wir unterstützen eine klassische ASP Site, die in IIS Anonyme Authentifizierung ausgeführt wird. Die Anwendung instanziiert ein DLL .NET-Objekt, das als COM verfügbar gemacht wird sichtbar.

Nach der Anwendung der letzten Sicherheitsupdates für Windows und dem Neustart des Betriebssystems ist unsere Anwendung mit folgendem Fehler abgestürzt:

Microsoft VBScript runtime error '800a01ad'
ActiveX component can't create object: 'NameOfObjectInDLL'

In unserem Fall hat dieser letzte Rat unsere Probleme behoben.

IIS> Authentifizierung> Anonyme Authentifizierung - Bearbeiten> "Anwendungspoolidentität"

screenshot1

4
support3