Due to some maintenance issues, this service has been switched in read-only mode, you can find more information about the why

and how to migrate your plugin documentation in this blogpost

Skip to end of metadata
Go to start of metadata

Plugin Information

View Active Directory on the plugin site for more information.

Older versions of this plugin may not be safe to use. Please review the following warnings before using an older version:

With this plugin, you can configure Jenkins to authenticate the username and the password through Active Directory.This plugin internally uses two very different implementations, depending on whether Jenkins is running on Windows or non-Windows and if you specify a domain.

  • If Jenkins is running on a Windows machine and you do not specify a domain, that machine must be a member of the domain you wish to authenticate against. Jenkins uses ADSI to figure out all the details, so no additional configuration is required.
  • If Jenkins is running on a non-Windows machine (or you specify one or more domains), then you need to tell Jenkins the name of Active Directory domain(s) to authenticate with. Jenkins then uses DNS SRV records and LDAP service of Active Directory to authenticate users.

Jenkins recognizes all the groups in Active Directory that the user belongs to, so you can use those to make authorization decisions (for example, you can choose the matrix-based security as the authorization strategy and perhaps allow "Domain Admins" to administer Jenkins).

Active Directory Health Status

Since the version 2.5 the AD plugin adds a ManagementLink to report a Health Status about the Domain and Domain controllers. In order to correctly use this feature, you should be logged-in into the instance and the cache should be disabled. Then, you will get:

  • The Domain health
    • DNS resolution
    • Global Catalog
    • Ldap Catalog
  • The Domain Controller Health
    • If the user can login into the DC
    • The Connection time
    • The total time in the lookup process

Fall-back user

Since the version 2.5 of the AD plugin, you can define a user to fall back in case there is a communication issue between Jenkins and the AD server. On this way, this admin user can be used to continue administering Jenkins in case of communication issues, where usually you were following the link Disable security. The password of this user is automatically synced with the Jenkins Internal Database by this feature. In order to configure this new feature you should enable *Use Jenkins Internal Database* in the AD configuration under Manage Jenkins → Configure Global Security and specify a SINGLE user by its username.

SECURITY-251 Active Directory Plugin did not verify certificate of AD server

From versions < 2.3 the Active Directory Plugin did not verify certificates of the Active Directory server, thereby enabling Man-in-the-Middle attacks. From version 2.3 the plugin allows to choose between a secured option and continue trusting all the certificated.

In case there was an Active Directory configured previously on the instance after upgrading the plugin the following Administrative Monitor will appear.

To avoid this message to appear again in case you would like to continue trusting all the certificates, the only thing you need to do is to go to Manage Jenkins -> Configure Global Security and hit the button saved. Then, the Administrative Monitor should not appear anymore as you acknowledge that you are fine by continuing on this TrustAllCertificated mode.

However, for security reasons the recommendation is to move to the secured option. This can be done on the Active Directory configuration under the Advanced button by selecting TLS configuration: JDK TrustStore.When this option is enabled notice that then in case your Active Directory server is using a self sing certificate, which usually is the case, you must then:

1. Export the certificate from your AD server
2. Create a custom keystore from the JVM keystore

For Unix:

cp $JAVA_HOME/jre/lib/security/cacerts $CUSTOM_KEYSTORE

For Windows:

copy %JAVA_HOME%\jre\lib\security\cacerts %CUSTOM_KEYSTORE%

3. Import your certificate

For Unix:

$JAVA_HOME/bin/keytool -keystore $JENKINS_HOME/.keystore/cacerts \
  -import -alias <YOUR_ALIAS_HERE> -file <YOUR_CA_FILE>

For Windows:

%JAVA_HOME%\bin\keytool -keystore %JENKINS_HOME%\.keystore\cacerts -import -alias <YOUR_ALIAS_HERE> -file <YOUR_CA_FILE>

4. Add the certificate to the Jenkins startup parameters:

The following JAVA properties should be added depending on your OS:

For Unix:

-Djavax.net.ssl.trustStore=$JENKINS_HOME/.keystore/cacerts \

For Windows:


5. Follow section Securing access to Active Directory servers to enable LDAPS

Disaster recover: In case that after all of this you cannot login anymore, you should enable the logging on the plugin to understand why it is failing. In case that after you enable the secured option you cannot login on the instance anymore, you might want to quickly fallback to the previous status specially on production environments. You can easily do this by going to $JENKINS_HOME/config.xml and under the section <securityRealm class="hudson.plugins.active_directory.ActiveDirectorySecurityRealm" revert the tlsConfiguration to the previous status. A restart is needed.


IMPORTANT Active Directory 2.0 - Better multi-domains support

The latest release of the Active Directory plugin provides you a better multi-domains support.

Users running Active Directory plugin 1.49 might be locked in case they were using Multiple Domains with Multiple Domains Controllers - this is the side effect of fixing the possibility of locking an account when not using Domain Controllers by a simple password mistake. The problematic PR is here.

In case this is the case and you are locked, you just need to go to $JENKINS_HOME/config.xml and modify the <servers> section deleting the ones which are not a member of the corresponded domain.

<securityRealm class="hudson.plugins.active_directory.ActiveDirectorySecurityRealm" plugin="active-directory@2.0">

A restart of the instance is needed after this.

Securing access to Active Directory servers

There are two possible options for securing access to Active Directory:

A.- LDAP + StartTLS (by default) 

Active Directory plugin performs TLS upgrade (StartTLS),  it connects to domain controllers through insecure LDAP, then from within the LDAP protocol it "upgrades" the connection to use TLS, achieving the same degree of confidentiality and server authentication as LDAPS does.

As the server needs to have a valid X509 certificate for this to function, if the server fails to do TLS upgrade, the communication continues to happen over insecure LDAP. In other words, in the environment that the server supports this, it'll automatically use a properly secure connection. See TechNet article for how to install a certificate on your AD domain controllers to enable this feature.

To verify if the connection is upgraded or not, see Logging and adds a logger to hudson.plugins.active_directory.ActiveDirectorySecurityRealm for FINE or above. Search for "TLS" in the log messages. 


On the other hand, if you wish on using LDAPS, you should set:

  • System property -Dhudson.plugins.active_directory.ActiveDirectorySecurityRealm.forceLdaps=true as a startup parameter to force Jenkins to start a connection with LDAPS. 
  • Use secured port is defined 636 or 3269 (your.hostname.com[|:636|:3269])

 Note that -Dhudson.plugins.active_directory.ActiveDirectorySecurityRealm.forceLdaps=true skips the default  LDAP + TLS upgrade.

Override domain controllers

This plugin follows the standard lookup procedure to determine the list of candidate Active Directory domain controllers, and this should be sufficient for the normal circumstances. But if for some reasons it isn't, you can manually override and provide the list of domain controllers by specifying the "Domain controller" field in the advanced section with the value of the format "host:port,host:port,...". The port should normally be 3269 (for global catalog over SSL), 636 (LDAP over SSL), 3268 (for global catalog), or 389 (LDAP).

For historical reasons, the system property "hudson.plugins.active_directory.ActiveDirectorySecurityRealm.domainControllers" for this purpose is still supported, but starting with 1.28, the configuration in the UI is preferred.

If you have multiple AD domains federated into a forest, be sure to use a global catalog, or else you will fail to find group memberships that are defined in other domains.

Group Names

If you have added a group and it appears in the list with a red stop sign, Jenkins cannot find it. Remove it and investigate why.

If you are not sure what the notation for a group name is, try the following procedure:

  1. Grant full access to anonymous user (in case you have to reconfigure security having logged out)
  2. Configure the AD server, test it, and save the configuration
  3. Log in using the AD user. Click your name to see a page listing the groups you were found in
  4. Add the relevant groups found to the security matrix with appropriate permissions
  5. Do not forget to withdraw permissions from the anonymous user, taking into consideration the Overall:Read permission (hover over the column header for detail)


Create/Update a dedicated Logs Recorder

If you think you've configured everything correctly but still not being able to login (or any other problems), please enable Logging and configure logging level for "hudson.plugins.active_directory" to ALL. Attempt a login and then file a ticket with the log output.

Also, it might be useful to enable:

hudson.security = ALL
jenkins.security = ALL
org.acegisecurity.ldap = ALL
org.acegisecurity.providers.ldap = ALL

Use a tool like 'ldapsearch' to validate credentials and authentication settings

Take care to escape special character with `\` in case it is necessary.

For TLS end-points:

ldapsearch -LLL -H ldaps://<DOMAIN_NAME_> -M -b "<searchbase>" -D "<binddn>" -w "<passwd>" "(<userid>)"

For non-TLS end-points:

ldapsearch -LLL -H ldap://<DOMAIN_NAME> -M -b "<searchbase>" -D "<binddn>" -w "<passwd>" "(<userid>)"

In case you don't want to show your password, you might want to use the command below instead - to be prompted for it.

ldapsearch -LLL -H ldap://<DOMAIN_NAME> -M -b "<searchbase>" -D "<binddn>" -W "(<userid>)"

All these fields should match with the following fields in the AD plugin configuration:

  • <DOMAIN_NAME> -> Domain Name: support-cloudbees.com
  • <searchbase> -> Organization Unit we want to look into. In the example, it is OU=Support, DC=support-cloudbees, DC=com
  • <binddn> -> Bind DN. In the exaple, CN=felix, OU=Support, DC=support-cloudbees, DC=com
  • <passwd> -> Bind Password
  • <userid> -> User we want to look for. We can look for the managerDN itself or for a different user on the tree. In the example, this can be set-up for example to CN=felix, OU=Support, DC=support-cloudbees, DC=com.

If using Domain controller check that all servers on the farm are working correctly

In case, we are using a Domain Controller like in the example below we might want to list all the AD servers in the farm by using:


It might happen that one of the servers in the farm is incorrectly replicated and the ad-plugin is sticky with this one, so we might want to check with ldapsearch command or the Test button in the GUI that all the servers are working correctly trying to look for an user on the tree.

If using Domain controller check that all servers on the farm are working correctly

You can check this by using:

nslookup -q=SRV _ldap._tcp.<DOMAIN_NAME>

nslookup -q=SRV _gc._tcp.<DOMAIN_NAME>

Warning for 1.37

Be careful if you intend to install version 1.37. It has been known to cause excessive load on Active Directory authentication servers. If you install this version you should carefully monitor traffic on relevant ports, e.g.: tcpdump port 389 or 3268.


Version 2.16 (2019/05/23)

  • Reverts 2.15 since it breaks all the installations on Windows Server  JENKINS-55813 - Getting issue details... STATUS

Version 2.15 (2019/05/20)

  • Improve AD/LDAP attribute analysis for locked accounts  JENKINS-55813 - Getting issue details... STATUS

Version 2.14 (2019/05/06)

  • Some Exceptions launched by startTLS might break the log-in  JENKINS-44787 - Getting issue details... STATUS

Version 2.13 (2019/04/01)

  • Java 11 readiness: also build recommended configurations

Version 2.12 (2019/02/08)

  • Remove the problematic Administrative Monitor  JENKINS-56047 - Getting issue details... STATUS   JENKINS-55852 - Getting issue details... STATUS

Version 2.11 (2019/01/28)

Version 2.10 (2018/11/5)

  • TlsConfigurationAdministrativeMonitor is missing its name -   JENKINS-54267 - Getting issue details... STATUS

Version 2.9 (2018/10/19)

  • Configuration-as-Code compatibility -   JENKINS-53576 - Getting issue details... STATUS

Version 2.8 (2017/06/23) FIXING REGRESSION IN 2.7

  • Advanced configuration missing on Configure Global Security (The plugin did not work correctly on Windows Servers)  JENKINS-52045 - Getting issue details... STATUS  

Version 2.7 (2017/06/18)

  • AD recognizes groups by CN and sAMAccount when authorities only works with CN  JENKINS-45576 - Getting issue details... STATUS
  • ActiveDirectorySecurityRealm constructor ignores TlsConfiguration  JENKINS-45816 - Getting issue details... STATUS

  • The help button for Domain does not correctly explain how to add multiple-domains  JENKINS-46228 - Getting issue details... STATUS

Version 2.6 (2017/06/22)

  • If getRecordFromDomain returns null report the problems -  JENKINS-45009 - Getting issue details... STATUS

Version 2.5 (2017/06/20)

  • Fail-over user to fallback when there are authentication issues -  JENKINS-39065 - Getting issue details... STATUS
  • ManagementLink to improve the supportability of the AD plugin -  JENKINS-41744 - Getting issue details... STATUS

Version 2.4 (2017/03/24)

  • Guice failing on terminating ActiveDirectorySecurityRealm.shutDownthreadPoolExecutors - (JENKINS-43091)

Version 2.3 (2017/03/20)

Version 2.2 (2017/03/15)

Version 2.1 (2017/03/13)

Version 2.0 (2016/10/03)

  • Much better support for multiple domain controllers - (JENKINS-32033). This version might lock the access to your instance, although this will only happen in a very small quantity of cases. See IMPORTANT Active Directory 2.0 - Better multi-domains support section for more information.

Version 1.49 (2016/09/17)

  • Add a warning when displayed name is not used with several domains - (JENKINS-38294)
  • Trim the domains so a space after comma does not get introduced - (JENKINS-38294)
  • System Property to be able to ignore referrals - (JENKINS-38290)
  • Support for multiple domain controllers - (JENKINS-32033)
  • Not return null inside the cache - (JENKINS-37582)

Version 1.48 (2016/09/09)

  • Provide an ultimate speed option based on Security Groups - (JENKINS-36248)
  • Not serialize userCache, neither groupCache - (JENKINS-36212)
  • Return null inside the cache block is not allowed - (JENKINS-37582)

Version 1.47 (2016/06/06)

Version 1.46 (2016/05/19)

Version 1.45 (2016/04/27)

  • LDAP users and groups cannot be verified anymore (JENKINS-34426)
  • Test button is reporting managerDN binding is successful but was not able to find any user on the tree (JENKINS-34444)

Version 1.44 (2016/04/20) This version is broken by JENKINS-34426 - which is fixed in 1.45

  • Test Active Directory connection button reports success if the search operation doesn't have any result (JENKINS-34143)
  • Optional cache for users and groups (JENKINS-21297)

Version 1.43 (2016/04/07)

Version 1.42 (2016/03/02)

  • Correct FindBugs issues
  • Chrome browser username autofill adds username as bindName in LDAP (JENKINS-29280)
  • "Automatic" group lookup strategy is not so automatic (JENKINS-28857)
  • TimeLimitExceededException produces "Automatic" group lookup strategy not to work correctly (JENKINS-33213)
  • Active Directory Plugin - Credential exception tying to authenticate with special characters like / or # (JENKINS-16257)

Version 1.40 (2015/04/06)

  • De-emphasize custom domain setting in the ADSI mode, but once that's selected, expose a full set of options (JENKINS-27763)

Version 1.39 (2014/11/17)

  • A hack-ish switch to enable faster group lookup (JENKINS-24195)
  • Login based on userPrincipalName (which looks like an email address) was not working

Version 1.38 (2014/06/03)

  • Apparently the "improvement" in 1.37 backfired for some users. Providing an option for them to select the algorithm as a fallback (JENKINS-22830)

Version 1.37 (2014/04/15)

  • Drastically speed up the recursive group membership search through the use of a Microsoft extension in the LDAP filter expression.

Version 1.36 (2014/03/27)

  • Fixed a thread leak problem when running on Windows (JENKINS-16429)

Version 1.35 (2014/03/11)

  • Implemented "remember me" support in conjunction with upcoming Jenkins 1.556. (JENKINS-9258)

Version 1.34 (2014/03/10)

  • Make test-button work for multi-domain configurations (Pull request #7)
  • Fix forceLDAPs system property and fix ports when using the system property (JENKINS-21073)
  • Added form validation check to the ADSI codepath (JENKINS-17923)

Version 1.33 (2013/05/06)

  • Fixed a show-stopper that broke most ADSI deployments (JENKINS-17676)

Version 1.32 (2013/05/01)

  • Fixed a regression in 1.31 that caused encoding problems with ADSI (JENKINS-17692)

Version 1.31 (2013/04/18)

  • Performance improvement.
  • Fixed a bug in handling OU that contains tricky characters like '/'.
  • Ignore the lookup failure for the memberOf group as it's possible that the authenticating user doesn't have permissions to access the group (JENKINS-16205)

Version 1.30 (2012/11/06)

  • NullPointerException encountered while testing connection.

Version 1.29 (2012/06/06)

  • Added additional logging statements for diagnosis.

Version 1.28 (2012/05/07)

  • Fixed a regression in 1.27 JENKINS-13650
  • If an authentication fails (as opposed to a communication problem), don't fallback to other domain controllers to prevent a cascade of login failures, which can result in an account lock out.

Version 1.27 (2012/04/26)

  • Started caching group definitions to reduce the traffic to domain controllers
  • ADSI implementation now more eagerly releases COM objects without waiting for GC
  • Removed bogus error message when an user wasn't found (JENKINS-12619)
  • When attempting anonymous bind, don't pass in the user name to prevent it from counted as a failure in case anonymous bind is disabled (JENKINS-13595)
  • Fixed a bug that broke the handling of exotic group names (JENKINS-12907)
  • Canonicalize the user name as per writtein AD, instead of using what the user gave us (JENKINS-12607)
  • Updated com4j to use ADSI even on 64bit Windows JVMs (JENKINS-11719)

Version 1.26 (2012/01/27)

  • Improved caching on group information (pull #3)
  • The "Test" button in the config page now supports multi-domain test. (pull #2)
  • Honor LDAP timeout setting when talking to domain controllers (pull #1)

Version 1.25 (2012/01/24)

  • Fixed a security vulnerability that affects AD with anonymoud binding enabled.

Version 1.24 (2012/01/05)

  • Fixed a bug in server lookup. We should still consider lower-priority servers if higher priority ones are unreachable
  • Supported group lookup by name
  • Report all attempted authentication when trying to authenticate against multiple domains (JENKINS-11948)

Version 1.23 (2011/11/29)

  • Fixed a poor interaction with the matrix security form check (JENKINS-11720)
  • Fixed a regression in 1.22 that broke the distribution group lookup (JENKINS-11668)

Version 1.22 (2011/11/8)

Version 1.21 (2011/11/4)

  • Plugin shouldn't require a record on the domain
  • Fixed a bug in the TLS upgrade (JENKINS-8132)
  • Plugin was not recognizing the user's primary group ("Domain Users" most typically)
  • E-mail and full name are now propagated to Jenkins (JENKINS-6648)
  • Made to correctly work with CLI username/password authentication (JENKINS-7995)

Version 1.20 (2011/10/19)

  • Fixed a security vulnerability (SECURITY-18)

Version 1.19

  • If we fail to check the account disabled flag, assume it's enabled (JENKINS-10086)
  • If/when the socket factory is given, JRE appears to automatically try to connect via SSL, so we can only do so during StartTLS call.
  • Error only if there's no server (either configured or discovered.)
  • Added the preferred Server functionality back

Version 1.18 (2011/03/20)

  • Add a preferred server in configuration options
  • Update for Jenkins

Version 1.17 (2010/11/16)

  • Look up is now done via LDAPS instead of LDAP (although there's no certificate check done now.)
  • The plugin now talks to the global catalog for efficiency, as opposed to a domain, if that's available.
  • Some DNS returns '.' at the end of the host name. Handle it correctly (JENKINS-2647)
  • Fixed a possible LDAP injection problem (JENKINS-3118)
  • Try all the available servers before giving up. Useful when some of your domain controllers aren't working properly. (JENKINS-4268)
  • Added the site support (JENKINS-4203)
  • Cleaned up the help text that incorrectly stated that this doesn't work on Unix. It works. (JENKINS-2500)

Version 1.16 (2009/12/8)

  • Added a workaround for WebSphere in doing DNS lookup via JNDI (JENKINS-5045)

Version 1.15 (2009/06/10)

  • Fix bug introduced with 1.14 where an AD setup with circular group references would cause a stack overflow.

Version 1.14 (2009/06/02)

  • Support nested groups (via the Unix provider) (JENKINS-3071)
  • Fixed a bug that prevented the "authenticated" role being honoured (JENKINS-3735)
  • Support authenticting against multiple domains (JENKINS-3576)

Version 1.13 (2009/05/19)

  • Fixed a bug that degraded Windows support (which forces you to enter the domain name.)
  • Implementation of group recognition (for displaying group icon in matrix for instance.)

Version 1.12 (2009/04/08)

  • Some DNS returns '.' at the end of the host name. Handle it correctly (JENKINS-2647) (not correctly fixed until 1.17)
  • Fixed NPE in the form field validation when a group name was added (JENKINS-3344)
  • Lookup fails for members of groups with special characters in the name (like '/') (JENKINS-3249)

Version 1.11 (2009/03/25)

  • No change. This is a re-release since 1.10 didn't hit the update center.

Version 1.10 (2009/03/20)

  • On Windows, specifying the domain name in the "advanced" section wasn't taking effect.

Version 1.9 (2009/02/17)

  • Modified to work with 64bit Winddows (report)

Version 1.8 (2009/02/13)

  • Hudson honors the priority in the SRV entries (patch)

Version 1.7 (2009/01/15)

  • Fixed a bug in handling alternative UPN suffix. (discussion)

Version 1.6 (2009/01/12)

  • Fixed a bug in handling "referrals" (which I believe happens when you run AD forest.)

Version 1.5 (2008/06/24)

  • Windows users can now also use the LDAP-based AD authentication (the same code used on Unix.) This is apparently necessary when Hudson runs as a local user instead of a domain user (discussion)

Version 1.4 (2008/06/11)

  • Fixed a bug where the configuration page doesn't show the configured AD domain name
  • Fixed a bug that prevented this from working with user-defined containers

Version 1.3 (2008/06/09)

  • Supported authentication from Hudson running on non-Windows machines

Version 1.2 (2008/02/27)

  • Fixed IllegalArgumentException in remember-me implementation (JENKINS-1229)

Version 1.0 (2007/01/09)

  • Initial version


  1. Unknown User (shadowspires)

    A thousand thank yous for getting this to work on non-windows systems.  It is excruciatingly painful to get our linux systems to talk to our AD.  LDAP is so limited and tricky.  This was a big win for me.  Works beautifully!

  2. Unknown User (areplogle)

    Has anyone got the "groups" side of user/groups AD permissions working? I've tried adding a security group and a global group and when someone who logs in that belongs to either of those, it doesn't give them the permissions that the group is setup for.

    Is it possible to get the source for this plugin or is it not opensource?



  3. Unknown User (fred.hoare@redprairie.com)

    Our active directory setup does not allow anonymous requests.  If I am running hudson as a non-domain user is there any way I can specify a username and password for the binding to the AD server?

    1. Unknown User (landoltjp)

      I had the same trouble.  There actually IS a Bind DN and Bind password field, but it's only seen if you run jenkins on a non-windows (i.e. Unix) machine.

      What I had to do was go into one of the UI config files and expose the fields for windows.  Then I could put in the values.

      I opened ticket JENKINS-24248 on this but It got closed out, and I'm not sure it will get fixed.

  4. Unknown User (jorge.matos@callawaygolf.com)

    I noticed that the plugin doesn't seem to work if you specify an AD group that has spaces in it.

    Is there a way to specify an AD group that contains spaces in the name?

    1. Unknown User (madmanbeck)

      I'm also experiencing this issue. Is there a way to escape the space, use quotes, or specify the GID?

    2. Unknown User (landoltjp)

      I THINK you can prepend the space with a backslash.  e.g. "group\ name".

      give that a spin.

  5. Unknown User (carter_scott@emc.com)

    Is it possible to bind to multiple domains?  I have two domains and need hudson to be able to authenticate with both of them but the plugin does not offer an alternate domain to use.  In the active directory box I want to be able to put



    I had thought of setting up a LDAP server and pulling all the information from both domains and storing it all in one but i could not figure that out.

  6. Unknown User (joti)

    I use this Plugin to secure my Hudson, it works at first try and flawless. Huge thanks for that! (big grin)

    Nevertheless it would be *really* nice if the Plugin or another Plugin using AD as well could provide

    • EMail-Adresses, assembled according to a pattern given by the user  (in case an email-Address does not just resemble the username or EMail-Name)
    • maybe fill the Jabber-Contact-Field in the same pattern powered way.
    • the Full Name

    for the AD retrieved users.

  7. Unknown User (cangove)

    The plugin is great, but it does not work in my current configuration.  In my config we have different AD boxes serving our different subnets, which may be in the same domain (same issue as illustrated in issue #4203).  Plus we have some test AD machines that see, to get in the way. So many times the plugin gets the right server, but when it does not the login fails.  So looking through the open issues I think a fix for 4268, 4203 or 4191 would get us moving.   Are any of these on the plate for fixing?  If so any ideas on a release? 

  8. Unknown User (dale@hoshooley.com)

    We are planing on using this plugin to secure our Hudson installation.  Our organization has mutliple domains and domain controllers and it would be nice to have an option to have the plug-in connect to the directory's global catalog (port 3268 / 3269 for SSL).

    Is there a way to specify the port the plug-in should use when trying to connect to the AD server?

  9. Unknown User (animesh)

    Is is possible for this plugin to determine the email addresses of users and use them in email notifications? If so, does it require any further configuration on my end? If not I'd like to suggest this feature be implemented as a useful alternative to having to configure LDAP Email Plugin as a helper to get this working properly which admittedly defeats the whole purpose of having a nice simple AD plugin so we don't have to deal with the nightmare of configuring LDAP against AD.

  10. Unknown User (gaurav.tiwari@sunlife.com)

    I have to manage authentication for Hudson using multiple LDAP domains. Although I can mention them all in the server field seperating them with commas, the problem I have is that the functional user account (bind DN or manager DN)we would need to access those servers would be different for each domain.

    Is there a way to ensure LDAP authentication of this kind?

  11. Unknown User (nele_lav@yahoo.ca)

    We are using this plug in to secure our org.'s hudson. We have noticed a bug that when a user logs in, the system said that user has invalid login information and advised to try again but he/she was already login since the user name already appeared in the upper right side of the system page beside the search area as logged in. This has been an intermittent  problem. I am using matrix based security on authorization.

  12. Unknown User (mark1900)

    I am really looking for to the upcoming release version 1.17 to address some issues we have been having with our Hudson instance.

    Any chance of getting a timeline or estimate for this release?

    My issues:

    * http://issues.jenkins-ci.org/browse/JENKINS-4268

    * http://issues.jenkins-ci.org/browse/JENKINS-3356

  13. Unknown User (minw83.kim)

    I try to get the code building and installing this plug-in. But is not working ADLDAP at linux system.

    Please let me know your next updating plan?

  14. Unknown User (bernhard.merkle@googlemail.com)

    is there a timefrage for a 1.17 release ?
    or how can I build the plugin myself ?

  15. Unknown User (vigoo)

    The latest build changed LDAP access to LDAPS without providing an option to set it back. I was using it on a small internal network where LDAPS is not available, so this update completely broke my hudson installation.
    Could you add a system property maybe allowing the user to switch back to LDAP without SSL?

    1. Unknown User (xyu)

      I got the same problem in my network.

    2. Unknown User (jadivine)

      Same problem here.

  16. Unknown User (yamo)

    Appears we are running into the ldaps issue as well.

    1. Unknown User (rcobb1)

      Same here... had to revert back to the 1.16 plugin to keep things functional

  17. Unknown User (trinition)

    I reverted to 1.16 after 1.18 failed to connect since I don't have LDAPS set up (it's all internal to our network).  Is there a way to configure any version since 1.17 to use non-SSL connections?  I'm unclear if setting the system property with a port that is by convention typically non-secure would work.

  18. 1.16 worked for me with Active Directory whilst running Hudson on Red Hat Linux under tomcat.  Upgraded to Jenkins and changed to 1.18 and it all stopped.  Moved back to 1.16 and life is ok again.  1.18 'tested' ok - but needs more comprehensive checks that it will authenticate users.

  19. Unknown User (mjshi)

    This is superb plugin.  Install it and works, very simple.  Thank you for the great work!

  20. Unknown User (kstarling)

    Just opened https://issues.jenkins-ci.org/browse/JENKINS-13674 for this plugin due to the fact that it no longer functions correctly to use usernames in authorization strategies since Jenkins appears to be comparing against the LDAP full name rather than the username. 

  21. Unknown User (smallrise)

    I installed a new Jenkins(1.462) and active-directory-plugin(1.26). But in the configuration of configure system, there is no "Site", "Bind DN", "Bind Password" and the "Test" button. So i can not connect the Jenkins to my domain. But for my previous Jenkins, the ADP plugin works and we can test my domain account.

  22. Unknown User (_roc)

    hello - are there any known issues with this plugin (1.28) against windows 2008 R2 based domain controllers??

  23. Unknown User (gadgetvirtuoso)

    Running Win2k8 R2 for our DC. Users can login however, groups are not working except for the built-in authenticated user. Anyone have any success with group permissions?

  24. Unknown User (ally_r)

    I too am having issues getting groups to work. Colleague is using it successfully at job level on another build server but I can't use groups at server/jenkins level. 

  25. Unknown User (andrewsumner)

    Is there any way to enable single signon with this plugin so that users are required to enter a password?

  26. Unknown User (michael_scholz)

    Are multiple domain names supported for Windows?

    Can you add an example of a correct configuration?

  27. Unknown User (wenic)


    Is there a way to see all the groups I am in from active directory? I remember being able to see it when i go to configure in ../username/configure/ or something similar

    1. Unknown User (mobarger)

      Hi christof w - If you have AD configured you should be able to go to http://your_jenkins_URL/whoAmI/ to see that info.

  28. Unknown User (sysadmin2062364230)

    I have enabled security on the Manage Global Security page, then selected Matrix-based security.  I can configure the users or groups and they get the right icon, suggesting that they are detected in AD.  Users can log in using their credentials if I assign permissions individually but if I remove the individuals and assign permissions to groups the system accepts their credentials (using the wrong password is rejected, suggesting that it is checking with AD properly) but says they are missing the Overall/Read permission.  If I set permissions by user it works OK.  Can anyone suggest what I might be doing wrong?

  29. Unknown User (mlbright)

    How does one enable the cache?

  30. Unknown User (kake)

    Info: Using Jenkins ver. 1.560, Upgrading 1.36 --> 1.37. gave a LDAP timeout exception when logging in. Had to downgrade to login.

  31. Unknown User (kake)

    double post

  32. Unknown User (landoltjp)

    The AD plugin allows us to configure the Domain Name and Domain Controller.  When will we be able to Authenticate for AD servers that don't allow anonymous access?

    I've seen another Jenkins AD plugin that has "Site", "Bind DN" and "Bind Password".  Are those features limited to the "Enterprise" version, or will they be making their way down to the FOSS version any time soon?

    1. Unknown User (sharkannon)

      Click the "Advanced" button on the right side (Just below where it says Domain Name).. Bind info is in there.

  33. Unknown User (sharkannon)

    Hey Guys,

    Can't seem to find it anywhere (I may be blind) but I'm having an issue.

    The plugin itself works great, but I'm creating a backup/restore scheme for Jenkins right now and the problem is that when I restore the jenkins config.xml (with the stored Bind DN/Password) I lock out the Bind User account because the Password HASH doesn't resolve to the correct password.  Do you know of any way to solve this issue?

  34. Unknown User (proksaj)

    Please be warned that this plugin sends all user passwords in plain text over network.

    You cannot use SSL/TLS enabled port 636 or 3269 and TLS upgrade does not work. Regardless of AD controller setup.

    This is due to bugs

    1. Unknown User (christian_schmid)


      i configured the plugin with the parameter "hudson.plugins.active_directory.ActiveDirectorySecurityRealm.forceLdaps".

      No warnings are produced in the log and the traffic seems encrypted when inspecting it with tcpdump.

  35. Unknown User (alex01ves)

    Works VERY slowly in my corporate network. Authentication takes 1-2 minutes, and I don't see any tweaks to help that. Do you have any suggestions?

    1. Unknown User (alex01ves)

      I downloaded and compiled the yet-unreleased 1.39 with the option to ignore irrelevant groups. Together with "Matching rule in chain", this sped up my login to 15 seconds! Which is not perfect, but is OK. Thanks very much!
      If it helps further debug, the bulk of the time is spent between the following logs:

      Sep 09, 2014 2:40:27 PM FINER hudson.plugins.active_directory.LDAPSearchBuilder
      searching (member:1.2.840.113556.1.4.1941:={0})[CN=ec abc unix xxx my_name,OU=GenericAccounts,OU=xxx,OU=UNIX,OU=XXX XXX,OU=Resources,DC=abc,DC=corp,DC=company,DC=com] in DC=abc,DC=corp,DC=company,DC=com using {java.naming.ldap.attributes.binary=tokenGroups objectSid, java.naming.security.credentials=…, java.naming.referral=follow, java.naming.provider.url=ldap://server.abc.corp.company.com:389/, java.naming.security.principal=abc\manager_name, java.naming.ldap.version=3} with scope 2 returning [cn]
      Sep 09, 2014 2:40:37 PM FINE hudson.plugins.active_directory.ActiveDirectoryUnixAuthenticationProvider
    2. Unknown User (dgtlrift)

      We are using version 2.6 and stumbled on to this page via a google search when having issues with Speed.  We discovered that even though our AD DNS SD records work, the data center blocks a number of nodes, and had to force the config to use a specific node for authentication.   If you run into speed issues, this is probably the root cause.  The workaround is to figure out which node is accessible and force the plugin to use that one.   It would be helpful if the plugin would cache which nodes are problematic and skip them during service discovery.

  36. Unknown User (movavi)

    The plug-in doesn't work if to try to be connected to it through Internet, using port forward and the indication of port with a domain name.


  37. Unknown User (jessejacob)

    Couple of things--if the maintainer(s) could let me know if they think these are bugs or regressions I would really appreciate it, otherwise I'll take it up with other plugin owners:

    1) There appears to be an undocumented discrepancy between admin users and non-admin users. Admin users can see their list of AD groups on their user status page, while non-admin users cannot. Is this a restriction of the "users" feature or of the Active Directory plugin? I'm using matrix auth and granting limited rights to authenticated users...any idea which item in the matrix I need to get access to 

    2) If you are using the matrix auth strategies, you MUST enter the groups so that there is an exact case match of the name in the matrix to the actual security group. I just wasted a bunch of time troubleshooting this after finding out there was an accidental upper-case character in a group name. There is no documented indicator that this is necessary for either matrix auth or Active Directory plugins. Would this be an issue with the matrix plugin or with the Active Directory plugin?


  38. Unknown User (mfuxi)

    Tried the plugin and at first it looks fine, and seems to be working but after 5-10 minutes i'm getting those errors repeatedly when trying to login with one of the users I added and i'm being locked out:

    Jun 21, 2015 6:07:13 PM hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DescriptorImpl bind
    WARNING: Failed to authenticate while binding to ********:3268
    javax.naming.AuthenticationException: [LDAP: error code 49 - 80090308: LdapErr: DSID-0C0903A9, comment: AcceptSecurityContext error, data 52e, v1db1
    Jun 21, 2015 6:07:13 PM hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DescriptorImpl bind



    1. Unknown User (joshgo)

      Have you made any new progress that you can share/update us?

      I'm getting the same error message

  39. Unknown User (silkgoat)


    Is it possible somehow to use other AD attribute than sAMAccountName? In our company we set up services to use userPrincipalName to login. We would like to use the same in Jenkins with AD plugin.



  40. Unknown User (eduard)

    How can I specify a base (search base suffix?)? My company uses as base:

  41. Unknown User (wilson_ds_net)

    I'm seeing a Jenkins warning "TLS is not correctly configured on Active Directory plugin.Please, change to a more secured option;".  In addition to bad grammar, does anyone know what this means?  This is very non-specific and our Active Directory seems to be working fine.

  42. Unknown User (wilson_ds_net)

    I've done a little more explorations and it appears there is a problem with the 2.3 plugin. When we go to the http://<machine>:8080/configureSecurity/ screen and click the test domain button (with credentials that were working before the 2.3 update) we get the following message (user name X'd out in message).  At this point it appears Jenkins with Active Directory is broken.

    Bad bind username or passwordorg.acegisecurity.BadCredentialsException: Either no such user 'XXXXXXXX' or incorrect password
    at hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DescriptorImpl.bind(ActiveDirectorySecurityRealm.java:527)
    at hudson.plugins.active_directory.ActiveDirectorySecurityRealm$DescriptorImpl.bind(ActiveDirectorySecurityRealm.java:545)
    at hudson.plugins.active_directory.ActiveDirectoryDomain$DescriptorImpl.doValidateTest(ActiveDirectoryDomain.java:231)
    at java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:627)
    at org.kohsuke.stapler.Function$MethodFunction.invoke(Function.java:343)
    at org.kohsuke.stapler.Function.bindAndInvoke(Function.java:184)
    at org.kohsuke.stapler.Function.bindAndInvokeAndServeResponse(Function.java:117)
    at org.kohsuke.stapler.MetaClass$1.doDispatch(MetaClass.java:129)
    at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58)
    at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:715)
    at org.kohsuke.stapler.Stapler.invoke(Stapler.java:845)
    at org.kohsuke.stapler.MetaClass$5.doDispatch(MetaClass.java:248)
    at org.kohsuke.stapler.NameBasedDispatcher.dispatch(NameBasedDispatcher.java:58)
    at org.kohsuke.stapler.Stapler.tryInvoke(Stapler.java:715)
    at org.kohsuke.stapler.Stapler.invoke(Stapler.java:845)
    at org.kohsuke.stapler.Stapler.invoke(Stapler.java:649)
    at org.kohsuke.stapler.Stapler.service(Stapler.java:238)
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
    at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:812)
    at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1669)
    at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:135)
    at com.cloudbees.jenkins.support.slowrequest.SlowRequestFilter.doFilter(SlowRequestFilter.java:37)
    at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132)
    at hudson.plugins.greenballs.GreenBallFilter.doFilter(GreenBallFilter.java:59)
    at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132)
    at jenkins.metrics.impl.MetricsFilter.doFilter(MetricsFilter.java:125)
    at hudson.util.PluginServletFilter$1.doFilter(PluginServletFilter.java:132)
    at hudson.util.PluginServletFilter.doFilter(PluginServletFilter.java:126)
    at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
    at hudson.security.csrf.CrumbFilter.doFilter(CrumbFilter.java:49)
    at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
    at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:84)
    at hudson.security.UnwrapSecurityExceptionFilter.doFilter(UnwrapSecurityExceptionFilter.java:51)
    at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
    at jenkins.security.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:117)
    at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
    at org.acegisecurity.providers.anonymous.AnonymousProcessingFilter.doFilter(AnonymousProcessingFilter.java:125)
    at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
    at org.acegisecurity.ui.rememberme.RememberMeProcessingFilter.doFilter(RememberMeProcessingFilter.java:135)
    at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
    at org.acegisecurity.ui.AbstractProcessingFilter.doFilter(AbstractProcessingFilter.java:271)
    at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
    at jenkins.security.BasicHeaderProcessor.doFilter(BasicHeaderProcessor.java:93)
    at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
    at org.acegisecurity.context.HttpSessionContextIntegrationFilter.doFilter(HttpSessionContextIntegrationFilter.java:249)
    at hudson.security.HttpSessionContextIntegrationFilter2.doFilter(HttpSessionContextIntegrationFilter2.java:67)
    at hudson.security.ChainedServletFilter$1.doFilter(ChainedServletFilter.java:87)
    at hudson.security.ChainedServletFilter.doFilter(ChainedServletFilter.java:76)
    at hudson.security.HudsonFilter.doFilter(HudsonFilter.java:171)
    at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
    at org.kohsuke.stapler.compression.CompressionFilter.doFilter(CompressionFilter.java:49)
    at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
    at hudson.util.CharacterEncodingFilter.doFilter(CharacterEncodingFilter.java:82)
    at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
    at org.kohsuke.stapler.DiagnosticThreadNameFilter.doFilter(DiagnosticThreadNameFilter.java:30)
    at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
    at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
    at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:553)
    at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
    at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
    at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
    at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
    at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
    at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
    at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
    at org.eclipse.jetty.server.Server.handle(Server.java:499)
    at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:311)
    at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
    at org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:544)
    at winstone.BoundedExecutorService$1.run(BoundedExecutorService.java:77)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
    at java.lang.Thread.run(Thread.java:745)

  43. Unknown User (gulbrain)


    I've been wondering if it's possible to avoid the following anomaly: We have Jenkins deployed on a non-Windows system and authenticating against our main corporate domain. I am finding that it will authenticate and identify users whether or not they enter the domain prefix on their login. This is great - but if they do enter the domain prefix, this is treated as a distinctly different Jenkins user. I'd like to be consistent so that I know what to enter for the matrix permissions on projects.

    When I login using "MYDOMAIN\myuser", my name appears as "Surname,Forename". When I login using just "myuser", my name appears as "Forename Surname". This is not consistent for all colleagues where at least one appears as "Surname,Forename" whether the domain prefix is used or not.

    Is there any way to have the "thisuser" be treated as the same Jenkins users as "MYDOMAIN\thisuser"?


  44. Unknown User (rakekniven)

    Please maintain changelog. v2.8 and v2.9 are not documented.

    1. Unknown User (fbelzunc)

  45. Unknown User (jimmyjudas)

    I can only see the "Use Jenkins Internal Database" option if I first tick "Specify custom Active Directory domain name" (and then "Advanced"). Is this a bug? The plugin is picking up the AD just fine so I don't want to specify a custom name, but I do want the fallback user option. Thanks!

  46. Unknown User (agoeb)

    After the update to 2.11, I see the warning "TLS is not correctly configured on Active Directory plugin.Please, change to a more secured option;".

    I was using TRUST_ALL_CERTIFICATES with StartTLS before, which is not available in the Global Security settings anymore.

    Now I completely switched to LDAPS setting the hudson.plugins.active_directory.ActiveDirectorySecurityRealm.forceLdaps=true system property, changing the domain controller port to 3269, and importing the server certificate into a custom trust store, which I provide via the javax.net.ssl.trustStore system property as described in the documentation. Configuring the FINER log level for ActiveDirectorySecurityRealm shows the connection does indeed use LDAPS over port 3269, and users can successfully log in.

    Still, the warning about insecure TLS configuration is still shown. Am I missing something?

    Thanks a lot,

  47. Unknown User (volker59)

    Hi All.

    The hole configuration description (my understandig) based on Jenkins on a server. How setup the plugin in a docker container?

  48. Unknown User (pranav)

    Hi All,

    I am using plugin version 2.12 and facing issues regarding authorizations for nested groups - as I read above, this should already have been fixed with version 1.14. However I still face an issue with the user authorization when it is part of a nested group, works fine when added explicitly to the Matrix.

    Any ideas if this is still an open issue ? Any suggested workarounds / fix ?