none
An issue with InfoBlox DNS appliance, Active Directory and LDAP

    Question

  • Hi All,

    in our company we have implemented Active Directory, served by four DCs - dc1, dc2, dc3 and dc4, which maintain the domain domain.local, single forest single domain. We are using an InfoBlox applience as DNS server instead of Microsoft AD integrated DNS. The IP address of InfoBlox appliance is set on each domain controller as primary name server on the network card. As this AD implementation was inherited from the previous administrator (which suddenly left the company before I take his place) with no documentation at all what I found is that an AD integrated DNS server exists on dc2. This AD integrated DNS obviously was built during the initial configuration of Active Directory, it holds the zone domain.local with all supporting zones as _msdcs.domain.local etc. At the InfoBlox's side the zone was configured and it acts perfectly as a name server, every computer or server when added to domain registers itself in the InfoBlox, _msdcs.domain.local, _gc, _kerberos, _ldap zones and records are OK. We are facing an issue with ldap localization with Oracle BI software, which is installed on a domain member server. Oracle BI is set to work with AD users and for this purpose a LDAP connector was set. As a LDAP server I set domain.local, there is a dedicated domain user which is set in Oracle BI to perform LDAP queries, the user is specified with its distinguished name. When Oracle BI queries domain the users are listed in the Oracle BI. However, when I shut down dc2 Oracle BI is no longer able to perform LDAP queries. It seems that the connector somehow prefers AD integrated DNS instead the InfoBlox's DNS when performing LDAP queries. I have added DNS server role on dc1 (whith dc2 powered on), all the zones are transferred from dc2. When I shutdown dc2 the Oracle BI works perfectly with LDAP queries. The conclusion I made is that when there is no AD integrated DNS up and running Oracle BI is unable to perform LDAP queries even with specified in its network settings InfoBlox name server with all zones and records. Does anybody know what would be the reason this issue to occurs?
    PS. Forgot to mention that on both AD Integrated DNS and InfoBlox all the _ldap records are set with priority 0 and weight 100.




    Saturday, December 17, 2016 7:51 AM

All replies

  • I'm not familiar with Oracle BI software so I can only give you generalities in an answer.  DNS and LDAP are two different protocols but during LDAP query sequences they can easily get confused during troubleshooting.  I need to start by saying you should not be running an DNS service on your DCs since all DNS is being hosted by InfoBlox.  But since you stated everyone including the DCs themselves are pointed towards InfoBlox, that particular architectural error is being masked.  It is important to keep in mind that DNS settings configured at the host-machine level (on the actual network card) can be different than that which is set inside the Oracle BI software connector properties, which could account for why you are seeing the inconsistent behavior with only the Oracle BI member server.

    Examine the settings of the Oracle BI software connector very closely.  Could be that the BI software DNS and/or LDAP server settings were hard-coded directly at dc2 and dc1, but is unable to failover when a DC gets turned off.   This suggests why first shutting down dc2 caused a problem.  As for why it worked after transferring DNS zones from dc2 to dc1, and the LDAP query succeeds, then perhaps you or someone else re-initalized the BI software engine after you transferred the DNS zones from dc2 to dc1, so that's why it worked.  Something about the DNS/LDAP configuration is wrong in the Oracle BI connector, rather than in the enterprise at large (apart from the fact that you're still running DNS service on one of your DCs).  

    What you could do is within the Oracle BI software connector properties, set the InfoBlox DNS servers as your DNS rather than dc1 or dc2.  Then restart the BI engine afterwards.  Based on your problem statement, this is where I would look.  InfoBlox is fully capable of hosting an AD DNS zone successfully, as many large enterprises employ it this way.



    Best Regards, Todd Heron | Active Directory Consultant

    Saturday, December 17, 2016 12:38 PM
  • Thanks for the quick reply, Todd!

    yesterday, when I specified an exact domain controller as a LDAP server (dc2.domain.local), Oracle BI was unable to load the AD users! This is weird! There are several LDAP fields which I filled with the exact values in accordance with the BI documentation, so I do not think that something special has to be done at the BI's side. The only setting that defines whether BI to failover to another LDAP server is "Enable Failover = true", that's it. All the settings that are being done are through the BI management interface, there is no need to modify any BI config files manually. The curious in my case is that BI is unable to establish an LDAP session with exact domain controller specified. The AD integrated DNS holds the zone domain.local, there are no recent A, NS, SRV etc. records redistered, the last record is from 2011. BI does not have any settings for DNS, it has only several types of connectors and one of them is a LDAP connector (BI also supports working with local users and users, retrieved from a database). The only solution that comes to mind is to prepare a test lab, where I will move the entire AD infrastructure along with BI, AD integrated DNS role will be uninstalled and all the DNS queries will be maintained by InfoBlox (we have an extra InfoBlox device, which is not used in our production environment). The curious fact is that we have raised a SR to Oracle support regarding this issue three months ago, they are unable to find out what's wrong.

    Sunday, December 18, 2016 8:31 AM
  • Hi,
    Thank you for the update and feedback, in my opinion, you could also open up a case with Microsoft Technical Support to see if they could help further: https://support.microsoft.com/en-us/contactus/?ws=support
    It might be hard to troubleshoot successfully in the forum as the third party system/applications are involved and could not test well from our side.
    Best regards,
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, December 19, 2016 7:15 AM
    Moderator
  • Hi Wendy,

    thanks for your advice. Oracle support are engaged for now with resolving the case, I will wait a couple of days to see what will be the conclusion and whether they will manage to fix this. If they are unable to help with resolving the issue I will raise a ticket with Microsoft, the company that I work for is Microsoft partner and we have a  subscription. Oracle BI is working fine, today I have added DNS server role to the rest two domain controllers. I just wanted to know what is causing this :). I would like to thank to all the people who read this and especially those who replied with an opinion.

    Monday, December 19, 2016 6:24 PM
  • Hi,
    Ok, we appreciate you any feedback and thank you for the understanding again.
    Best regards,
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Tuesday, December 20, 2016 2:35 AM
    Moderator
  • may be you can check in the configuration of infoblox may be there will be some alias or host record created which points to sticky setting.
    Tuesday, December 20, 2016 2:26 PM
  • Hi sunny.sinha,

    I have checked the Infoblox's configuration, this is what I did first, there weren't any bad records.

    Anyway, I am still waiting for an answer from Oracle.

    Sunday, December 25, 2016 6:37 PM
  • Hi All,

    after a detailed investigation, what I found is when I set the Global Catalog port 3268 instead of LDAP port 389, Oracle BI is able to load the users without DC5 being powered on, which is not described neither the official Oracle documents, nor anywhere else. This is weird, but it works!!! I have forgot to mention that our domain consists of subdomains, e.g. domain123.xxx.yyy.com, I have read that LDAP queries are restricted to a single domain directory partition, the Global Catalog queries are drilling all directory partitions. I would like to know whether this could be the reason for LDAP query not to retrieve the users. Thanks!


    • Edited by Anton Vasilev Friday, December 30, 2016 8:41 AM
    • Proposed as answer by Todd Heron Friday, December 30, 2016 1:05 PM
    Friday, December 30, 2016 8:39 AM
  • Hi,
    The default port for an LDAP connection is 389. When you configure an LDAP connection to use port 389/636, you search for objects from this local domain controller only (replicated between domain controllers in the same domain). It has a complete set of all attributes each object contains. For environments with multiple domains in the forest, it is often required to use the Global Catalog in order to return objects from all domains in the forest. The Global Catalog is a Read Only replica which contains a Partial Attribute Set (PAS) of objects within the forest, so it holds certain replicate objects from all domains. The default port for this is 3268 for LDAP. When you configure the LDAP connection to use port 3268, you search this Global Catalog (GC) to locate objects from any domain without having to know the domain name itself.
    Best regards,
    Wendy

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Monday, January 2, 2017 2:20 AM
    Moderator
  • To expand on Wendy's excellent post: If you query for users on port 389 (a DC), you will get all users in the current domain (the domain where the computer is joined). If you query on port 3268 (a GC), you will get all users in all domains in the forest, but you cannot retrieve all attributes of the users. On port 3268 you can only retrieve attributes in the PAS.

    You can retrieve more users from the GC, but unless you are in a domain with no users, or you are filtering for a subset of users, you should retrieve some users on port 389.


    Richard Mueller - MVP Enterprise Mobility (Identity and Access)

    Monday, January 2, 2017 2:38 AM
  • Hi,

    I am checking how the issue going, if you still have any questions, please feel free to contact us.

    And if the replies as above are helpful, we would appreciate you to mark them as answers, and if you resolve it using your own solution, please share your experience and solution here. It will be greatly helpful to others who have the same question.

    Appreciate for your feedback.

    Best regards,

    Wendy


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Friday, January 6, 2017 8:26 AM
    Moderator
  • Hi, sorry for the delayed response. Since we did not receive an adequate answer from Oracle about the issue with port 389, we decided to use the Global Catalog port 3268. As a bank institution for us is very important all the systems and services to be reliable and up. In this manner we've managed to provide the employees the maximum availability of the service.
    Sunday, February 12, 2017 8:42 AM