Looked at the code from

./src/main/java/hudson/plugins/active_directory/ActiveDirectorySecurityRealm.java

And the magic can indeed happen:

public ActiveDirectorySecurityRealm(String domain, String site, String bindName, String bindPassword, String server, GroupLookupStrategy groupLookupStrategy) {
this.domain = fixEmpty(domain);
this.site = fixEmpty(site);
this.bindName = fixEmpty(bindName);
this.bindPassword = Secret.fromString(fixEmpty(bindPassword));
this.groupLookupStrategy = groupLookupStrategy;

Scereen shot from enterprise version of the Active Directory plugin, showing both the Bind DN and Password edit fields

What's the 'enterprise version' of AD plugin?

The reason is that these options are only available when Jenkins runs on something other than Windows:

https://github.com/jenkinsci/active-directory-plugin/blob/master/src/main/resources/hudson/plugins/active_directory/ActiveDirectorySecurityRealm/config.jelly

Not sure whether this is deliberate or an oversight, as the plugin uses the Unix implementation when any options are entered IIRC.

Ah! well that makes sense, as I just recall that the person who gave me that attached image is running Jenkins "ver. 1.554.2.2 (Jenkins Enterprise by CloudBees 14.05)" on a Linux machine. I grabbed an eval license to run on my windows machine, and do not see those fields.

I'm wondering if JENKINS-22346 is related to these missing fields.

This is causing an issue for me attempting to stand up a Jenkins instance on Windows 7. If the Jenkins service is running as a local user, even if the machine is joined to a domain, it appears that the Active Directory plugin fails to look up the AD information. I believe we need the ability to specify the bindName, bindPassword, and groupLookupStrategy under the Advanced button, even when running Jenkins on Windows.

Running the service as a domain user has no issues.

This is also causing problems when working across different domains.

All of my users have their credentials in "MyDomain.mycompany.com". However the Jenkins server is hosted in "MyDEVDomain.mycompany.com". With out being able to speicify the BindDN (MyDomain\UserID), it attempts to authenticate against the default AD server in which the server is hosted.

As in the pictures above, I've tested this out by patching the active directory plugin to show Bind DN and Bind Password, regardless of windows or *nix OS. And this works for me.

Fixed as JENKINS-27763.