How to Setup AD Integrated DNS with .local TLD on LAN Interface?
-
My company has four geographic sites, a Windows 2016 Active Directory domain, and one NetGate XG-7100 pfSense firewall per site (well, it will have, once I get them configured). Externally we have SomeCompany.com as a DNS namespace, and internally we have SomeCompany.local as both an Active Directory and DNS namespace. I am not at liberty to change that.
I am troubled by the pfSense caution under General Setup that says, "Do not use '.local' as the final part of the domain (TLD)..." Well what I have is a domain that ends with .local, and there is little I can do about that. How should I deal with this issue (how to I configure around a limitation I cannot change)?
I would like to be able to use LDAP authentication (to Active Directory) by pointing my Authentication Server at @.SomeDomain.local rather than SomeSpecificNode.SomeDomain.local so that it can pick up any domain controller and not just the one that is probably offline for updates. To present, I have only been able to authenticate to AD when I hard-code the IP address of the DC into the Authentication Server form.
My expertise goes more to programming and database design than WAN configuration and networking... I know just enough about DNS to be dangerous, but it seems to me that the LAN interface on my pfSense appliance ought to be bound to my Active Directory integrated DNS servers, and the WAN interface ought to be bound to my External or ISP's DNS servers.
Thanks!
-
Don't worry about it. I've been using blah.local for 6 years now without any problems that I'm aware of. I'm sure there are some cases, like those listed in the 11-year-old warning, that apply but I've never heard of such issues.
-
@KOM Thanks... your experience gives me some peace about the issue. As a thank you, I believe I'll setup my VPN tunnels on port 2112 (for the rest of you, it's a Rush thing).
-
What can (and probably will) make trouble are Linux or Mac Clients, that are pretty straightforward in using .local as mDNS and can screw with an internal domain. As I had mostly linux or BSD workstations in earlier days, I had to deal with some of that problems. I ended up reconfiguring the local DNS resolver of my WS to use something like .mlocal to use as mDNS or disabled mDNS resolving alltogether to get it to resolve internal services correctly.
What could also be a problem is the ability to get "real" certificates for internal services via a valid CA or LetsEncrypt. If that are no concerns you'll likely not run into that much trouble, but it isn't recommended and can be a problem later on.I know the problem if you get dumped an internal domain with .local in your lap but what you actually can do is introduce another domain name into the mix, a real one without the .local problems, and try to migrate everything to it, so services like Exchange etc. are using the internal.realdomain.tld later instead of olddomain.local. The only thing left than can/will be the user names in old domain syntax like
olddomain\useroruser@olddomain.localbut for anything else the other real domain can be used to minimize the impact or shortcomings of the .local domain.And if you have any chance like an upgrade or anything to a new DC -> perhaps think about setting up a new clean domain without all baggage from the old one and dump the .local :)
Just as additional .02$ :)
Greets
Jens -
@JeGr Thank you.
-
A couple of points...
Regarding .local, Wikipedia has this to say about using it, falls in line with what @JeGr has to say (my emphasis):
Networking device hostnames ending with .local are often employed in private networks, where they are resolved either via the multicast domain name service (mDNS) or local Domain Name System (DNS) servers. The implementation of both approaches on the same network can be problematic. However, resolving such names via unicast DNS servers has fallen into disfavor as computers, printers and other devices implementing zero-configuration networking (zeroconf) have become increasingly common.The one thing that was not addressed so far was what @JSchenk said:
I would like to be able to use LDAP authentication (to Active Directory) by pointing my Authentication Server at @.SomeDomain.local rather than SomeSpecificNode.SomeDomain.local
Here things get a bit trickier since LDAP authentication is configured by entering the IP address or hostname of the AD Server, thus not specifically meeting your requirement.
Some (correctly configured) domains will have DNS A records for the naked domain name (ie: SomeDomain.local returns the IP addresses of only the domain controllers), but I've seen instances where some strange stuff is thrown back, such as 127.0.0.1, an intranet web server, etc.I think some improvement could be made in how pfSense is able to find the nearest AD servers based on some basic LDAP queries and then direct the authentication to those servers, thus eliminating the need to actually specify a hostname or IP address, and eliminating wrong information returned from a naked domain query.
All that is needed is the domain name and functioning internal DNS resolution, from there LDAP can bootstrap itself to ask the query to the right server.
For instance the process would be:- DNS resolve _ldap._tcp.SomeDomain.local, which would return the IP address(es) and ports of the LDAP servers (ie: you get back SRV 0 100 389 dc1.SomeDomain.local.)
- Perform an ldapsearch -x -h ip_from_previous_step -p port_from_previous_step -s base namingContexts -- you don't need to be authenticated to AD to ask it what domains it manages
- Finally select the appropriate naming context out of the returned list (ie: dc=SomeDomain,dc=local) along with valid AD credentials and using that as a starting point to finish up the configuration (ie: select user's container / group naming, etc).
This might be pretty specific to AD (haven't tried with Novell or OpenLDAP), but the LDAP Server settings page could have the Initial Template drop down moved up near the top and the remainder of the page be affected by the choice made there.
–A.
-
@awebster Incredibly helpful... I will pore over this in great detail today. Thank you.
-
@JSchenk said in How to Setup AD Integrated DNS with .local TLD on LAN Interface?:
.local, and there is little I can do about that.
And why is that? Just change it to something else... At a loss to why you can not do anything about a horrible choice of a tld..
-
@johnpoz While I certainly agree with your "horrible choice" comment, it was that way when I arrived, and technical difficulties aside, there are also political hurdles to overcome (getting my boss' blessing to do so, a smart guy who has been many times bitten by, "Oh, it'll be easy."). Beyond that, while changing the DNS namespace is relatively straight forward, I personally know no one who has had a good outcome from attempting changing an Active Directory TLD (which should, for the most part, parrot the DNS namespace). Most of the advice online cautions against it (they could all be wrong, but I slow not to respect for the journey of my peers).
Here's what's involved:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc738208(v=ws.10)Not something to take on lightly in a manufacturing environment that runs around the clock at four geographic locations, all interconnected, etc. Sixty-some (albeit cloud or virtual) servers, hundreds of client nodes, Office 365 integration, cloud-based Exchange, hundreds of automated jobs (some with embedded user principal names), etc.
Long term, I hope to remedy this, but I need to stand up those pfSense firewalls in the near term.
I have already added split DNS to what I inherited, with my public namespace to-some-degree copied onto my internal DNS servers, but the Active Directory zone file remains .local (arrrgh). If I had set it up, they would both have started out .com...Have you ever successfully migrated a medium-sized Active Directory forest to a new TLD? Would love to hear how that went; I really would like to smoothly support Linux and Mac clients, beyond that the .local makes the uber geek in me groan.
-
Your link is for 2k3? Is that what your currently running? If so I would spin up NEW current Boxes with current schema, and then migrate your clients from the old ad to the new one - killing 2 birds if you will.
I have in the past migrated whole companies to new AD, but I do not recall ever just changing the domain.
-
@JSchenk said in How to Setup AD Integrated DNS with .local TLD on LAN Interface?:
Have you ever successfully migrated a medium-sized Active Directory forest to a new TLD? Would love to hear how that went; I really would like to smoothly support Linux and Mac clients, beyond that the .local makes the uber geek in me groan.
Since you asked, I have in fact worked on such projects for several different clients.
IMHO, the simplest way to achieve this is to fire up a new domain on new infrastructure (cheap to do it virtually these days), establish trust relationships and move the assets stuff over to the new domain.The domain rename procedure is way too ripe with potential for problems to crop up along the way, and then what? You can't restore AD from a backup, ever.
Some thoughts on what domain to use:
If you use the same domain internally and externally, you have to deal with split horizon DNS.
If you use a different domain internally, you have to deal with mapping external DNS names to internal hosts, stuff like making OWA work.
Pick your poison on that one.
I have never had issues using the same name internally and externally provided you have good control over both DNS views.–A.
-
@awebster said in How to Setup AD Integrated DNS with .local TLD on LAN Interface?:
simplest way to achieve this is to fire up a new domain on new infrastructure
QFT ;)
-
@johnpoz That is probably exactly what we will do, but we are running a manufacturing floor, so that will be arduous in itself. Thanks for your insight, John. :D
-
@awebster I have given your observations great thought--you are right on the money with the issues and with your suggestions. Thank you.
-
@awebster In previous domains that I created (rather than inherited), I took the same approach, and it always worked beautifully (split dns, same names internal and external). Eventually, this is what we are sure to do, but I inherited a rich set of issues, and some of those are taking greater priority right now. I am excited to be standing up pfSense Netgate firewalls behind a VMWare VeloCloud SD-WAN solution as we speak. If you groaned at our .local domain, you should see our current WAN configuration--Fisher-Price networking. ;)
-
@JSchenk said in How to Setup AD Integrated DNS with .local TLD on LAN Interface?:
Fisher-Price networking. ;)
heheh - dude I am sure I have seen worse ;) Good luck, have fun fixing it.. And if you have any questions there lots of smart people here that love to help.
