Comment instancier correctement des objets COM 32 bits dans classic ASP après l'installation de Windows Update KB4340558?
Sous Windows Server 2012 R2, après l’installation de la mise à jour KB4340558 (historique des mises à jour)/ KB4338424 (mises à jour installées), nous ne pouvons plus instancier .NET .DLLs (interop) en classic ASP en mode 32 bits avec server.createobject. Nous recevons l'erreur 0x800A01AD "Le composant ActiveX ne peut pas créer d'objet"
Lorsque nous désinstallons la mise à jour, l'erreur disparaît. Malgré tous mes efforts, je n’ai pas trouvé de solution de rechange à la désinstallation. Nous préférerions réinstaller la mise à jour et apporter les modifications nécessaires à Windows Server et/ou à la DLL pour permettre l’instanciation correcte des objets COM. Il n'y a aucun indice dans les journaux système, aucun indice dans la base de données CVE et aucun indice dans les erreurs générées par ASP. S'il vous plaît aider!
Nous avons également été touchés par plusieurs clients.
J'ai exclu la signature invalide de nom fort de nos assemblys, car les assemblages .NET du Framework lui-même étaient également affectés par cette erreur d'accès refusé.
Enfin, j'ai réussi à résoudre le problème par configuration. Apparemment, l'identité d'authentification du site Web doit maintenant correspondre à l'identité du pool d'applications. Ou IUSR n'a plus assez d'autorisations.
EDIT: 19.07.2018
Attention! Ce changement a également un effet secondaire:
L'événement classique "Session_OnEnd" n'est plus appelé et les ressources ne peuvent donc plus être libérées. Mais il y a un correctif pour ça aussi!
La propriété ASP-Config-Property "system.webServer/asp/runOnEndAnonymously" doit être "false", puis l'événement est déclenché à nouveau.
EDIT 2: 23.07.2018
Comme Dijkgraaf l'a souligné, Microsoft considère maintenant ce "nouveau comportement" comme un bogue. Donc, je suppose que ma "solution" devrait maintenant être considérée comme une solution de contournement jusqu'à ce qu'un nouveau correctif arrive au secours.
Nous exécutons notre pool d'applications sous une identité spécifique, afin de permettre un partage réseau et un accès à une base de données. Moi aussi, je pensais que nous étions coincés après avoir lu @ keydon réponse ci-dessus.
Cependant, il y a trois endroits où nous devons configurer l'identité:
- Le pool d'applications - doit utiliser l'identité spécifique
- Le site Web "Connecter en tant que" - doit utiliser "l'identité du pool d'applications"
- L'option Authentification anonyme, sous la fonctionnalité Authentification - doit utiliser "Identité du pool d'applications".
Ce dernier point était ce qui nous manquait: des années consacrées à considérer les deux premiers seulement nous avaient mal interprété le bon conseil ci-dessus.
Microsoft est au courant du problème et la base de connaissances pertinente est les erreurs "Accès refusé" et les applications activées par COM échouent après l'installation des mises à jour de sécurité et de synthèse de la qualité de juillet 2018 pour .NET Framework
Cela a eu un impact sur BizTalk, SharePoint, IIS avec Classic ASP et l'application .NET qui utilise l'emprunt d'identité).
Les solutions de contournement pour Classic ASP sont les suivantes
IIS Hosted Classic ASP appelant des objets CreateObject pour .NET COM peut recevoir l'erreur "Le composant ActiveX ne peut pas créer d'objet":
- Si votre site Web utilise l'authentification anonyme: Modifiez les informations d'identification de l'authentification anonyme du site Web pour utiliser "Identité du pool d'applications".
- Si votre site utilise l'authentification de base ou l'authentification Windows: connectez-vous une fois à l'application en tant qu'identité de pool d'applications, puis créez une instance du composant COM .NET. Ensuite, les autres utilisateurs du site pourront activer le composant .NET COM sans échec.
- Si vous utilisez l'authentification Windows et accédez au site Web à partir de la console du serveur Windows où l'application ASP est exécutée): la création d'une instance du composant COM .NET corrige également l'erreur pour un autre site. utilisateurs.
Ceci ne sert qu'à confirmer la solution fournie par keydon, combinée à celle fournie par TimP. Et leur dire merci !!
Dans notre cas, nous avons modifié les 3 parties suivantes (et une quatrième supplémentaire pour les nouvelles autorisations):
Propriétés d'authentification du serveur Web: définissez l'authentification anonyme avec "Identité du pool d'applications" au lieu de "Utilisateur spécifique".
Propriété "Identity" du pool d'applications: définie sur "ApplicationPoolIdentity" au lieu de "LocalSystem".
Site Web "Connecter en tant que" pour le chemin physique: paramétré sur "Utilisateur de l'application (authentification unique)" au lieu de "Utilisateur spécifique".
Ajoutez des autorisations pour " nom d'utilisateur d'identité de pool d'applications " dans le dossier partagé contenant les fichiers de l'application Web. Jetez un œil à https://docs.Microsoft.com/en-us/iis/manage/configuring-security/application-pool-identities#securing-resources
Merci!! (Je suis désolé je ne peux pas voter vos solutions parce que je suis starter et que je n'ai aucune réputation)
Nous prenons en charge un site classique ASP exécuté sous IIS Authentification anonyme. L'application instancie un objet DLL .NET. Exposé en tant que COM. visible.
Après l'application des dernières mises à jour de sécurité Windows et le redémarrage du système d'exploitation, notre application s'est bloquée avec l'erreur suivante:
Microsoft VBScript runtime error '800a01ad'
ActiveX component can't create object: 'NameOfObjectInDLL'
Dans notre cas, ce dernier conseil a réglé nos problèmes.
IIS> Authentification> Authentification anonyme - Édition> "Identité du pool d'applications"