How do I properly instantiate 32-bit COM objects in classic ASP after installing Windows Update KB4340558?

Question

On Windows Server 2012 R2, after installing update KB4340558 (update history) / KB4338424 (installed updates) we can no longer instantiate .NET .DLLs (interop) in classic ASP in 32-bit mode using server.createobject. We receive the error 0x800A01AD "ActiveX component can't create object"

When we uninstall the update, the error disappears. Despite my best efforts, I was unable to find an alternate solution to uninstalling. We would prefer to reinstall the update and make whatever changes were necessary to Windows Server and/or the DLL's to allow the COM objects to be instantiated properly. There are no clues in the system logs, no clues in the CVE database, and no clues in the errors ASP is generating. Please help!

Carolecarolee

Does it change anything if you use plain CreateObject instead of Server.CreateObject? – Sabrinasabsay

Same result using plain CreateObject. – Carolecarolee

Is Enable 32-bit Applications set to True in the app pool configuration? – Simonasimonds

Yes. The issue is a result of installing a .NET security rollup that came out yesterday (7/10/2018). The control worked fine prior to installing the update, and again after uninstalling the update. The KB articles and CVE database didn't directly address any changes that the rollup fixed that might cause this error-- or if they did I missed them. – Carolecarolee

The two are urgent security patches to address recent disclosed security vulnerability. I assume that while fixing issues the patch did not pass more compatibility testing, like your case. Thus, your only hope is to come after Microsoft via its support services, so that they release a better patch than the current version. This site won't help you much. – Slider

May also be worth leaving this here - IISRESET results in W3SVC stuck in stopping status after July 2018 patches. – Trever

The authentication changes have not worked in my environment where we are accessing network files. Microsoft has acknowledged the issue and are actively working on a solution. support.microsoft.com/am-et/help/4345913/… – Noenoel

Some more info here: blogs.msdn.microsoft.com/dotnet/2018/07/20/… – Sabrinasabsay

Answer 1

We were affected with multiple customers too.

I ruled out invalid strong-name signing of our assemblies, since the .NET Assemblies from the Framework itself were affected by that access-denied error too.

Finally I managed to solve the issue by configuration. Apparently the authenticating identity of the website has now to match the identity of the app-pool. Or IUSR has no longer enough permissions.

EDIT: 19.07.2018

Warning! This change also has a side-effect:

The asp-classic event "Session_OnEnd" was no longer called and therefore resources eventually could no longer be freed. But there is a fix for that, too!

The ASP-Config-Property "system.webServer/asp/runOnEndAnonymously" has to be "false", then the event fires again.

EDIT 2: 23.07.2018

As Dijkgraaf pointed out, Microsoft now considers this "new behaviour" a bug. So i guess my "solution" should now be considered a workaround until a new patch comes to rescue.

Collard

Translating that screenshot to English: Select your website in the left-hand pane, click Authentication in the right-hand pane, select Anonymous Authentication, click Edit, then select Application Pool Identity. – Badr

In our case the application pools are running under the OS's NetworkService account. My only concern would be introducing any unintended security vulnerabilities running IIS under this account. I can't think of any off of the top of my head though... Thoughts? – Carolecarolee

BTW, aligning the IIS user with the App Pool user worked to get things moving along again with the patch installed. I would still love thoughts on the security implications. – Carolecarolee

This doesn't work if you have to use a specific Windows user to execute the pool. – Linnell

@Linnell you should be using ApplicationPoolIdentity, if you have to specify a particular user account than you need to reassess the web application security and why it needs to be like that. – Trever

@Lankymart "why it needs to be like that" ... that's a legacy website that access files over the network. it has to be like that because noone will ever touch the architecture of that website; it will be dismissed before you can redesign everything... The AppPool is executed as a specific user, the website has the same user as "Connect as...". – Linnell

@Lankymart In my particular case, I need to do double hop auth with kerberos. To the best of my knowledge, this requires the site to run under a domain account. – Strachan

@BryanSlatner in which case set the AppPool to use the domain account and set the anonymous account to ApplicationPoolIdentity and you are golden. – Trever

@Lankymart I actually have Anonymous disabled. I've noticed a very interesting quirk here. With the setup as you've described, non-admin users who access the app when it's "cold" -- i.e., need a new worker process -- get the error. As soon as I, or any other admin, access the app, the component loads just fine and then continues to load fine for everyone until the worker process recycles. I think I have to start experimenting with permissions. – Strachan

Answer 2

We run our application pool under a specific identity, to enable a network share and database access. I too thought we were stuck after reading @keydon's answer above.

However, there are three places that we must configure the identity:

• The Application Pool - should use the specific identity
• The Website "Connect As" - should use the "Application pool identity"
• The Anonymous Authentication option, under the Authentication feature - should use "Application pool identity"

That last one was the thing that we were missing - years of considering only the first two meant that we mis-read the great advice above.

Sima

No need to apologise, this answers the question and provides extra information besides. You have every right to post it. – Trever

Answer 3

Microsoft is aware of the issue and the relevant KB is "Access Denied" errors and applications with COM activation fail after installing July 2018 Security and Quality Rollup updates for .NET Framework

This has impacted BizTalk, SharePoint, IIS with classic ASP and .NET application that uses impersonation.

Workarounds for Classic ASP are as follows

IIS Hosted Classic ASP calling CreateObject for .NET COM objects may receive an "ActiveX component can't create object" error:

• If your web site uses Anonymous Authentication: Change the Web Site Anonymous Authentication credentials to use the "Application pool identity".
• If your site uses Basic Authentication or Windows Authentication: Log into the application once as the application pool identity, then create an instance of the .NET COM component. Afterwards other site users will be able to active the .NET COM component without the failure.
• Alternatively, if you are using Windows Authentication and accessing the web site from the console of the Windows Server where the ASP application runs: Creating an instance of the .NET COM component also resolves error for other site users.

Apostil

Answer 4

We support a Classic ASP site running in IIS Anonymous Authentication. The application instantiates a DLL .NET object exposed as COM visible.

After applying recent security Windows Updates and reboot OS our application crashed with following error:

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

In our case, this last advice fixed our problems.

IIS > Authentication > Anonymous Authentication - Edit > "Application pool identity"

screenshot1

Tourneur

This workaround did not work for us. Besides, we can no longer restart the www service after we installed the July Windows Update. The service locks in "stopping" mode forever and we have to restart the server.We had to uninstall all KB's from the July Windows Update. – Fem

The www service restart issue I related in my previous comment seems to be related to this problem. Please check this thread: forums.iis.net/t/… – Fem

Answer 5

This is only to confirm the solution provided by keydon, combined by the one provided by TimP. And give them thanks!!

In our case we've changed the following 3 parts (and an additional 4th for new permissions):

1. Web server Authentication properties: set Anonymous Authentication with "Application pool identity" instead of "Specific User".

2. Application Pool "Identity" property: set to "ApplicationPoolIdentity" instead of "LocalSystem".

3. Web Site "Connect As" for physical path: set to "Application user (pass-through authentication)" instead of "Specific User".

4. Add permissions for "Application Pool Identity user name" in the shared folder where the web application files are. Have a look to https://learn.microsoft.com/en-us/iis/manage/configuring-security/application-pool-identities#securing-resources

Overdraw