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.
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 plugin performs TLS upgrade — 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 fot "TLS" in the log messages.
If you must insist on using LDAPS, and not TLS upgrade, you can set the system property hudson.plugins.active_directory.ActiveDirectorySecurityRealm.forceLdaps=true as a startup parameter to force Jenkins to start a connection with LDAPS, even though this will buy you nothing over LDAP+TLS upgrade. Example: Add -Dhudson.plugins.active_directory.ActiveDirectorySecurityRealm.forceLdaps=true inside the <arguments> tag in Jenkins.xml. You will also need to check inside config.xml to ensure either the secured port is defined (636 or 3269) or not defined at all.
<SecurityRealm ...> <server>your.hostname.com[|:636|:3269]</server></SecurityRealm>
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.
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:
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.
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.
Skip to end of metadata Go to start of metadata