|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #60787 Windows Authentication + PHP = 500 errors since PHP 5.3.7
Submitted: 2012-01-18 10:44 UTC Modified: 2013-02-18 00:35 UTC
Avg. Score:5.0 ± 0.0
Reproduced:1 of 1 (100.0%)
Same Version:0 (0.0%)
Same OS:1 (100.0%)
From: test1 at breakin dot in Assigned:
Status: No Feedback Package: IIS related
PHP Version: 5.3.9 OS: Windows Server 2008 R2 Enterpris
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: test1 at breakin dot in
New email:
PHP Version: OS:


 [2012-01-18 10:44 UTC] test1 at breakin dot in
On a server where everything was working as expected with PHP 5.3.6, I upgraded PHP to 5.3.9 (latest official release, non-thread-safe). I run WordPress on IIS 7.5 / Windows Server 2008 R2. All versions of PHP after 5.3.7 are exhibiting problems with some WordPress plugins, where 500 errors are thrown and no PHP log is generated, when using Windows Authentication to protect sites (anonymous authentication disabled).

If I roll back to PHP 5.3.6 or earlier, the problems resolve.

If I turn off Windows Authentication while using PHP 5.3.7 or newer, the sites and plugins work as expected.

The problem is the specific combination of Windows Authentication, some WordPress plugins, and PHP 5.3.7 or newer.

An example plugin problem: I get 500 errors when using WP Super Cache with WordPress on PHP 5.3.7 or newer. If I roll PHP back to 5.3.6, the plugin again works as expected. 

Test script:

Expected result:
I expect the WordPress plugin to work as designed.

Actual result:
I receive a 500 error when using the WordPress plugin on a site with Windows Authentication running PHP 5.3.7 or newer.


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2012-01-18 17:08 UTC]
-Status: Open +Status: Feedback
 [2012-01-18 17:08 UTC]
Thank you for this bug report. To properly diagnose the problem, we
need a short but complete example script to be able to reproduce
this bug ourselves. 

A proper reproducing script starts with <?php and ends with ?>,
is max. 10-20 lines long and does not require any external 
resources such as databases, etc. If the script requires a 
database to demonstrate the issue, please make sure it creates 
all necessary tables, stored procedures etc.

Please avoid embedding huge scripts into the report.

 [2012-01-18 22:34 UTC] test1 at breakin dot in
Alas, I don't have a specific script; the error I am seeing occurs within a particular setup on WordPress + some plugins. 

The bug clearly presents itself when rolling to PHP 5.3.7 or newer, and disappears when rolling back to PHP 5.3.0 - 5.3.6. However, I don't have a simple test case; it requires WordPress + plugins (such as WP Super Cache) as described in the original report.
 [2012-01-19 17:28 UTC]
I have no idea about supercache or WP in general (well, to actually know what you 
are referring to).

But what's your configuration? Do you use impersonation? run php as a given user?
 [2012-01-20 06:08 UTC] test1 at breakin dot in
Thanks so much for your quick response!

The WordPress installations in question are set up on the following:

Windows Server 2008 R2 / IIS 7.5
PHP 5.3.9 running via FastCGI (php-cgi.exe)
URL ReWrite from 
WinCache extension for PHP from

The following non-default settings are in php.ini:
        open_basedir = "c:\inetpub"
	expose_php = Off
	max_execution_time = 300
	error_log = php_errors.log
	extension_dir = "ext"
	cgi.force_redirect = 0
	fastcgi.impersonate = 1;
	fastcgi.logging = 0
	upload_tmp_dir = "c:/inetpub/wwwroot/sites/_phptemp/" 
	upload_max_filesize = 8M
	allow_url_fopen = Off
        date.timezone = America/Chicago
	SMTP = localhost
	smtp_port = 9909
	session.save_path = "c:\inetpub\wwwroot\sites\_phpsessions" 


Each site has a unique Application Pool. The sites are set up so that, if Anonymous Authentication were allowed, all users would appear as the site's Application Pool identity. In this case, the plugins work with no problems, as expected.

However, when Windows Authentication is turned on and Anonymous Authentication is turned off, that's when the 500 errors occur. In this case, when using SysInternals Process Monitor, it looks like some requests are being made under the authenticated user's identity, and some are being made under the Application Pool identity.

So, the scenarios:
- If PHP 5.3.6 or older, WordPress and plugins work as expected with any authentication setting.
- If PHP 5.3.7 or newer, WP and plugins work as expected with Anonymous Authentication only.
- If PHP 5.3.7 or newer, WP and plugins fail with 500 errors with Windows Authentication.
 [2013-02-18 00:35 UTC] php-bugs at lists dot php dot net
No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Sat Apr 20 21:01:27 2024 UTC