Resolution
Requirements
In order to achieve this configuration, the following requirements need to be fulfilled:
On the AD side:
-
At the network/infrastructure level, the Jenkins instance must be able to connect to both domain servers.
-
A user ("UserX") is needed in all the different AD domains that shares common attributes that Jenkins can use to bind as. Those same values are:
-
first name
anddisplay name
(In fact, changes on one applies to the other) -
password
-
This can be checked by using, for example, Active Directory Explorer and trying to log in on the multiple domain, using for "Bind DN" field the display name value and for "Bind Password" the password of "UserX".
|
On the Jenkins side > Active Directory:
-
Include the multiple domains separated by "," ( a comma without spaces ) in the
Domain Name
field. -
Associate
Bind DN
to thedisplay name
andBind Password
to thepassword
of the mentioned "UserX".
anonymous user for Bind DN is not valid. |
Example scenario
The following scenario helps to understand the issue and its resolution:
On the AD side:
Two different domains ('example.com' and 'example.net') running on different Windows Server 2012 machines ('dcpr1' and 'dcpr2', for each domains respectively). Then, Server manager > Tools > Active Directory Users and Computer configuration for each one is as follows:
example.com
example.net
On the Jenkins side :
Global Security Configuration ($Jenkins_URL/configureSecurity/
) > Security Realm > Active Directory would succeed as follows:
Each user (from those 2 different domains) is added to Jenkins Users directory as soon as log into Jenkins. Thus, after logging all of them on the $Jenkins_URL/asynchPeople/
would look like this: (Note that "UserX" shares same name
but not UserId
)