I have not used Azure AD, but …
Can you have one of the failing users try the Test Tool?
What do you have as your Base DN? Is it close enough to the [root]?
Have you set “Authorize by group membership”, and if yes to what?
Have you set “Automatic Password Update”, or not?
I’ll try and get someone to use the test tool.
I am using the root dc no ou filtering, I believe this is working because at first bulk import was not importing anything, so I changed this to the root and then bulk import was able to get all the users.
“Authorize by Group” is not set and “Automatic Password Update” is checked.
I’ve thought about temporarily checking “Fallback to WordPress Password” to see if the Bulk Import is importing the current user/password, but the LDAP auth is failing for the user. I know that’s not a good long term fix though.
Thanks for the response! I appreciate being able to at talk it out.
Testing “local fallback” seems like a good test. We however have it turned on on our Intranet, simply because we do not want to be dependent on the DC:s. Being our Intranet we saw very little security risk with keeping this on.
We use “Auth by group” and we created a AD-group called “wp-subscribers” and made all Employees members of this group. That way we effectively block all non-employee AD accounts, would the password for any of them fall into the wrong hands. At least as a test I would recommend trying it.
Later we created other AD-groups for WP so we could start using “Role Equivalent Groups”, and this has really made life easier for us so I do recommend using it.
What have you configured for: “Account Suffix”, “Append account suffix …” and “Set local password on first successful login”? We have all our email domain suffixes listed , just in case. We do not append the suffix since this created problems for us. We do set the local password, so that we can use local fallback.
I just want to mention that Azure AD DS should work but at the moment we do not officially support this cloud service.
