-
Bug
-
Resolution: Not A Defect
-
Blocker
-
CentOS 6.3, Jenkins 501
We are moving our build servers to AWS. We want to auth against our main corporate Active Directory, but our IT department will not allow direct connection to our internal DCs. They have created a new read-only DC and placed it in our DMZ for such external auth use. We are currently using this for outsourced Jira and Jive successfully. Our internal domain uses the convention "company.local" - meaning it's not compatible with external DNS. Our AWS servers define any local names in the AWS VPC via /etc/hosts, and use AWS provided DNS servers for any external names. While we can define in /etc/hosts the DMZ DC, such as dmzdc.company.local, so that resolves, it appears the active directory plugin has no method of turning off it's attempts to use DNS to obtain the domain controller. When we enter into the domain: company.local, despite the fact we try to override the server with dmzdc.company.com, we still get errors because it's not taking that as a hint DNS isn't valid, and it's still attempting to lookup a name that isn't resolvable in our cloud-deployment situation.
There's also likely an issue here related to referrers, which we experienced when attempting to integrate with outsourced Jira/Jive. Because we're part of an AD forest, any attempt to hit the DMZ DC returns referrals, which are based on internal *.company.local names which are not in external DNS we have access to. While we can override such names in /etc/hosts, they are for servers which are not reachable as they are internal and protected by firewalls. Jira has an option to turn off referrers, which allows it to work. It would be nice if the Active Directory plugin could also add this flag.
We managed to convince IT to add a read-only global catalog server exposed via SSL to this DMZ DC, as we read this does not generate referrals. We have confirmed via the ldapsearch tool that this is true, but that still did not allow the active directory plugin to work. We also tried extensively to get this to work with the LDAP plugin, but that doesn't work either.
[JENKINS-16988] Active Directory plugin doesn't work with DMZ read-only DC, where DNS is not available
Michael Crawford
added a comment - If you're attempting to run a Jenkins server within the same internal network, where the jenkins server is using the AD-provided DNS servers with such records, that might work.
But, we're not trying to do that.
We are trying to move our Jenkins build servers into an account with Amazon Web Services, and our IT department will not allow such external access directly into our internal networks, even though we are using a VPC and have a site-to-site VPN which would make that possible.
Instead, they have created a read-only domain controller on our DMZ, which they have exposed for LDAP authentication use by external servers which need it. We're using outsourced Jive for our intranet, which integrates in this manner. We've moved Jira to the same AWS account, and had some early issues with referrer references before we got this to work, as Jira's Active Directory integration 1. does not use SRV records or other fancy techniques - it simply connects with the URL, connect username and password, and a base path, so we can get to the server without any DNS in place once firewall rules are setup to allow it, and 2. they have a GUI control which disables following referrals.
I have had our IT department create a global catalog server on the DMZ read-only DC, which does not cause referrals to be returned, and tried to hook into that with the LDAP server plugin, but still was not able to get this to work.
There should be a method to handle this type of centralized AD auth need, when a company moves build infrastructure into AWS or other cloud providers. These separate systems frequently do not have direct access to internal networks and internal DNS servers. We connect the cloud account via a VPN, but many people will not, or if they do large corporation security policies may prevent direct access. And, we don't want to introduce a dependency on new additional DNS servers for such small cloud-based architectures - we use the DHCP-provided DNS servers from Amazon for external host resolution, and simply create /etc/hosts entries for all local hosts in the architecture, so there is no location to create any SRV records. Last, our Active Directory domain is something like "dc=mycompany,dc=local" or mycompany.local, which isn't resolvable on the internet. So, even when we have tried to override some of the names, these cause internal referrals to other domain controllers higher in the forest, where either the name doesn't resolve, or the IP address of these other DCs is unreachable by firewall prohibition or no routable path. There should be controls to disable referrals, and this should work even with no DNS server in place, as long as Jenkins can get to port 363 on the IP specified. Simple is better.
Michael Crawford
added a comment - If you're attempting to run a Jenkins server within the same internal network, where the jenkins server is using the AD-provided DNS servers with such records, that might work.
But, we're not trying to do that.
We are trying to move our Jenkins build servers into an account with Amazon Web Services, and our IT department will not allow such external access directly into our internal networks, even though we are using a VPC and have a site-to-site VPN which would make that possible.
Instead, they have created a read-only domain controller on our DMZ, which they have exposed for LDAP authentication use by external servers which need it. We're using outsourced Jive for our intranet, which integrates in this manner. We've moved Jira to the same AWS account, and had some early issues with referrer references before we got this to work, as Jira's Active Directory integration 1. does not use SRV records or other fancy techniques - it simply connects with the URL, connect username and password, and a base path, so we can get to the server without any DNS in place once firewall rules are setup to allow it, and 2. they have a GUI control which disables following referrals.
I have had our IT department create a global catalog server on the DMZ read-only DC, which does not cause referrals to be returned, and tried to hook into that with the LDAP server plugin, but still was not able to get this to work.
There should be a method to handle this type of centralized AD auth need, when a company moves build infrastructure into AWS or other cloud providers. These separate systems frequently do not have direct access to internal networks and internal DNS servers. We connect the cloud account via a VPN, but many people will not, or if they do large corporation security policies may prevent direct access. And, we don't want to introduce a dependency on new additional DNS servers for such small cloud-based architectures - we use the DHCP-provided DNS servers from Amazon for external host resolution, and simply create /etc/hosts entries for all local hosts in the architecture, so there is no location to create any SRV records. Last, our Active Directory domain is something like "dc=mycompany,dc=local" or mycompany.local, which isn't resolvable on the internet. So, even when we have tried to override some of the names, these cause internal referrals to other domain controllers higher in the forest, where either the name doesn't resolve, or the IP address of these other DCs is unreachable by firewall prohibition or no routable path. There should be controls to disable referrals, and this should work even with no DNS server in place, as long as Jenkins can get to port 363 on the IP specified. Simple is better. I'm closing this bug as "not a defect".
As I wrote in my comment, this mode of deployment isn't a conforming AD environment. For example, you won't be able to put a Windows client in EC2 that authenticates with this read-only domain controller on your DMZ.
The point of AD plugin is to reduce the amount of configuration as much as possible by maximally taking advantages of the AD environment. The proposed improvement would go the opposite direction.
I see no reasons why you cannot treat this as just another LDAP server, which Jenkins already provide a good connectivity to.
I wonder in this case falling back to the LDAP plugin is a reasonable approach, since I thought custom DNS SRV records are an integral part of AD.