|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
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.