A couple of ideas:
- Allow WordPress authentication via the HTTP Authentication plugin options, and use the standard
wp-login.php form for admin logins. See “Can I configure the plugin to support standard WordPress logins?” on the FAQ page for more information.
- Set the default role for new users to an appropriately low level, and grant your domain user administrative access. When at another user’s computer, use
runas or similar to assume your identity. (Read this thread for more.)
I’m not a Windows person, so the second idea is more theoretical.
2) Would work to assume identity of “authenticateable” user, so I suppose it would do the trick.
As for 1) then that is what I have done without much luck. But I think I got an idea… get back to you…
Yeps, it worked. What I did was this:
1) Set anonymous access for everything instead of only authenticated, i.e. basically set it back to default
2) Made a copy of wp-login.php (called it wp-admlogin.php) and made sure that all post requests in it refer to itself instead og wp-login.php
3) Made wp-login.php authentication only, i.e. no anonymous access
4) Set the logout-path in HTTP-Authentication point to wp-admlogin.php
5) Require login in WordPress to access pages
People will by default be redirected to wp-login.php to be authenticated, where they are being authenticated by your plugin and redirected back to where they entered the site. If they click logout they are referred to the wp-admlogin.php page instead of the default, which is now accessible to anon users, i.e. they can see the form and log in as a WordPress-user og click the HTTP-Authenticate button below it. Works a charm.
Thanks a lot.
Hello yhniels, I’m basically trying to achieve the same configuration as yours
Could you please explains more precisely what you mean by:
Made wp-login.php authentication only, i.e. no anonymous access
Could you please explains more precisely what you mean by:
Jeps. I made a copy of wp-login.php called wp-admlogin.php and in IIS set access to the original to exclude anonymous access. That way, when accessing wp-login.php IIS will require the browser to login and with NTLM enabled in IIS that will make the browser attempt to login first with the current user (on the client) and thus make an AD authentication. The copy, wp-admlogin.php, is accessible to everyone. So, when setting the logout-path to point to wp-admlogin.php, you give the client a possibility to access a login page that does *not* force NTLM validation.
More specifically, you remove IUSR_WHATEVER from the access control list for wp-login.php which effectively removes anonymous access for that file. Activate NTLM in IIS and you should be set to go.
Ok Thanks
Since I’ve a Apache/Unix based implementation, I’l will have to use another aproach to achieve the same results
Apparently the following .htaccess could work for me:
<filesmatch "wp-adminlogin.php$">
Satisfy any
</filesmatch>
AuthName "<my authname here>"
AuthType Basic
AuthBasicProvider ldap
AuthLDAPURL ldap:<my ldap path here>
require valid-user
Yes, the only thing it has to do is require authentication on the original wp-login.php and allow anonymous on the copy.
By the way; the plugin http://ww.wp.xz.cn/extend/plugins/user-switching/ proved to be very useful for this type of setup, because logging in as someone else suddenly becomes a tiny bit tedious. With this plugin an administrator can “Switch” to another user context on the fly. Pretty nifty companion for HTTP-Authentication, in fact.
