Allows WordPress to authenticate, authorize, create and update users against Active Directory
Yes, this works. But you have to add the line
TLS_REQCERT never to your ldap.conf on your web server.
If yout don't already have one create it. On Windows systems the path should be
Another and even simpler way is to add LDAPTLS_REQCERT=never to your environment settings.
Yes, you can. Just put "ldaps://" in front of the server in the option labeled "Domain Controller" (e.g. "ldaps://dc.domain.tld"), enter 636 as port and deactivate the option "Use TLS". But have in mind, that
Yes. Since 1.0-RC1 you get more informations from the Test Tool by setting WordPress into debug mode. Simply add DEFINE('WP_DEBUG',true); to your wp-config.php.
If you activate "Automatic User Creation" and "Automatic User Update" you may store any AD attribute to the table wp_usermeta. You can set the meta key as you like or use the default behavior, where the meta key is set to
adi_physicaldeliveryofficename for the Office attribute). You can find a list of common attributes on the "User Meta" tab.
Yes. You'll find the bug tracker at http://bt.ecw.de/. You can report issues anonymously but it is recommended to create an account. This is also the right place for feature requests.
A common mistake is that the Base DN is set to a wrong value. If the user resides in an Organizational Unit (OU) that is not "below" the Base DN the groups the user belongs to can not be determined. A quick solution is to set the Base DN to something like
dc=mydomain,dc=local without any OU.
Another common mistake is to use
ou=users,dc=mydomain,dc=local instead of
cn=users,dc=mydomain,dc=local as Base DN. Do you see the difference? I recommend to use tools like ADSIedit to learn more about your Active Directory.
You must give your users the permission to change their own attributes in Active Directory. To do so, you must give write permission on "SELF" (internal security principal). Run ADSIedit.msc, right click the OU or CN all your users belong to, choose "Properties", go on tab "Security", add the user "SELF" and give him the permission to write.
Not all attribute types from the Active Directory schema are supported and there are some special types. Types marked as SyncBack can be synced back to AD (if the attribute is writeable).
Here we have a special problem with the builtin security group "Domain Users". In detail: the security group "Domain Users" is usually the primary group of all users. In this case the members of this security group are not listed in the members attribute of the group. To import all users of the security group "Domain Users" you must set the option "Import members of security groups" to "Domain Users;id:513". The part "id:513" means "Import all users whos primaryGroupID is 513." And as you might have guessed, 513 is the ID of the security group "Domain Users".
Requires: 3.0 or higher
Compatible up to: 3.5.2
Last Updated: 2013-2-20
1 of 10 support threads in the last two months have been resolved.
Got something to say? Need help?