How to Setup AD Integrated DNS with .local TLD on LAN Interface?
-
@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.
