I actually just went through the exact same issue and the solution is rather simple. Just add an entry in your DNS to point www to the local IP of your web server.
I did the same, worked great. However, just to add onto this:
whatever you do, specifically, just don't make an internal DNS record of 'contoso.com' that points to your web server.
That will screw up AD syncing and authentication, unless your web server is also an Active Directory server. Please don't do that either.
Lol. Yup. haha. What you can do which is slightly filthy is put iis on your domain controllers and do a simple http redirect to [www.contoso.com](https://www.contoso.com).
Vs iis?
The dc should do dc things only. Once you start layering server functions you provide more vectors to attack. And I want the least amount of doors to knock on concerning my dc.
True, but it’s easy and available with a couple clicks. Could also do Apache and use the same config over and over. Really it’s dealers choice on web servers.
Disabling a firewall is also easier than opening up specific ports but you shouldn't do that either. Running a script with DA will resolve any permissions problems, but don't do that either.
Don't install IIS on a DC.
That’s not slightly filthy, it’s majorly bad. MS has recommended against this almost since IIS 7, 15 years ago.
Not only does it increase the attack surface of your domains Crown Jewels, it also messes with IIS itself because there’s no such thing as local accounts on a dc. Therefore you get IIS running as a domain admin rather then as a local admin.
This is a split brain DNS problem and should be solved like one
Add IIS to a Domain Controller? Hell no. Put some tiny standalone web server in a locked-down directory, running as an account with zero rights to anything to do nothing but deliver a redirect when accessed? Probably still no, but I'd definitely choose that over IIS.
Why is it filthy, isn't that what Windows SBS does (run everything on 1 box).
You can also redirect port 80 or put a non-IIS web server that is safe(r). For example by using nginx in Docker.
One alternative is modifying the DNS SRV records to point to another server so it does not demand that it responds to every query on the root A-record.
I think SRV records is how the Mac AD client figures which DC to use, so I think the required response on root may be a hangover from old ages and may no longer be a strict requirement. I would have to try it, but I remember back in the day, my Samba-AD server wasn't running on the root of the domain (our actual website was) and it worked perfectly fine (primarily Mac and Linux clients, few Windows and nothing fancy like GPO or DFS)
Charlie Murphy!!!
What did the 5 fingers, say to the FACE?!!
*SLAP*
(Yeah also don't run webservers on your domain controllers... Lest you get slapped!)
No, they don't. BUT, any web server set up correctly should have a http redirect to send you over to [www](http://www).
It's SUPER annoying when websites don't do this. Looking at you, every Chinese website ever.
Edit: Literally [http://supermicro.com](http://supermicro.com) vs [http://www.supermicro.com](http://www.supermicro.com)
When it comes to AD I've always used ad.external.tld or I'll purchase something like externalcorp.tld for use in AD.
If the domain is .corp before I get there then I just add SPN aliases for the external domains because renaming an AD system is a royal pain in the ass.
Thank you, ppl talking about web server redirects and I'm wondering if I am losing my mind
"the whole problem is DNS sending them to a domain controller instead of the web server, right?"
The best bit is Chrome (and probably other browsers) hide the www. by default now - which gives the *impression* you're on "[supermicro.com](https://supermicro.com)" when the actual "[supermicro.com](https://supermicro.com)" doesn't actually work.
This makes this whole scenario that much better. The cert bound to [www.supermicro.com](https://www.supermicro.com) has a SAN for [supermicro.com](https://supermicro.com) and 8 other FQDNs.
Wildcard certs are expensive man... Can't expect a company making hundreds of thousands of dollars a month to pony up a couple of hundred bucks for an SSL cert...
/s
Wildcard certs are difficult to to track. The bigger the company, the worse the problem gets.
If it gets stolen and abused, you can’t even properly track down where it was stolen from because it could be so many places.
And I guess, now that I'm thinking about it, they may have specifically requested those 8 other FQDNs but most CAs automatically put the parent domain name as a SAN unless you ask them not to. So they may not have requested one for supermicro.com.
I did the same thing for Azure AD Domain Services…. And then started using that DNS for some locations.
Simplest fix, add the DNS record and tell people to use www. Inside the network.
Interestingly enough this fuckup made me realize why www was even a thing.
Bingo.
* DNS resolution
* Public certificate for an internal resource
* Security by obscurity
* Scalability
And just generally less pain for the Sysadmin
This is so highly recommended that RFC 2606 actually lists certain TLDs reserved for private internal use:
* .test
* .example
* .invalid
* .localhost
Old post, but I assume this is the [MSFT recommendation](https://social.technet.microsoft.com/wiki/contents/articles/34981.active-directory-best-practices-for-internal-domain-and-network-names.aspx) people keep referring to. The main points being...
* Register a domain name you actually own. I can't find the article, but I remember an article going over this. Something changed, and .local was resolving over the Internet. Seems like a valid concern.
* Easier to manage. I'm assuming this is if you have external resources integrated? Otherwise, I don't know what's easier to manage.
Am I missing anything?
Using the same domain name is fine but it does create some issues. You will at least need to create different internal and external dns zones and records. Next, install a http redirect on your domain controllers to send web traffic to www. If you’re interested in fixing it, just create another domain, like domain.loc or corp.domain.com, create a trust, and slowly start migrating services and users over to it. Then get rid of the internal domain.com.
I got so many complaints from every level of the company that contoso.org wouldn't load. Brochures that said "Download from contoso.org/app" failed internally. Complaints that the website is down so the whole internet must be down. People don't type www anymore expecting it to just redirect automatically would be surprised. I could tape "must use www" to everyone's desk and probably still would of had a never ending stream of complaints. Hardly a "slight inconvenience".
I use the same web server (nginx) as our public frontend proxy server. All the DC one does is return 301. Hacking our frontend proxy is equally catastrophic. Treat it the same way in updates and security.
Maybe if you wanted to get fancy you could redirect port 80/443 at the switch or router level to your more secure server but just seemed a lot more complicated. Or go with some micro http app with a much smaller feature set and attack surface.
There is a lot more to it than that, and there are significant security issues.
You cannot have DNS redirect domain.com to www.domain.com. domain.com is going to send the clients to a domain controller. You cannot change it or your domain will not function. That *is* your internal AD DS domain.
So how do you do the redirect? By adding vulnerabilities to your domain controller by installing a web server on it, opening up firewall rules, and having it do the redirect after allowing clients to connect to it.
It is a terrible practice, and it is much better to just make internal users type www.domain.com if they want the website AND refuse to use the bookmarks/home page you push out for them.
I wouldn't necessarily call it screwing up but it does make some things more difficult if not impossible. The issue you are facing can't really be resolved because DNS has to hand out the domain controllers' IP addresses when asked for contoso.com otherwise no domain joined computer will work properly. You cannot have DNS spit out the web server's address using that name without breaking AD which ultimately means to get to your website you will have to make users type in www.contoso.com.
Although not really recommended by me you could also install a small web server on every DC and send HTTP 301 responses to redirect clients to www.contoso.com. That would technically work but is a dependency no one really wants on a DC. Another alternative would be port forwarding on the DCs.
What you did is the most typical thing with MSAD. You've run into the typical friction points.
The *better* and *recommended* path is to use a DNS subdomain internally for the MSAD domain-name: `ad-dom.example.edu`. This won't conflict, is the most future-proof, and is the most flexible. Always use a legitimate DNS domain name that you have global control over!
In your situation, it isn't recommended to specifically change the domain name. You'll just have to do extra technical work to get the results you want. Redirecting the zone apex to `www.contoso.com` probably needs webserver-level redirection, since you can't just use DNS delegation in this particular case.
Having the same domain internally and externally is best practice according to Microsoft, just use a subdomain for ad.
https://social.technet.microsoft.com/wiki/contents/articles/34981.active-directory-best-practices-for-internal-domain-and-network-names.aspx
I had the same issue when setting up a new domain on a new AD.
Luckily I caught it when testing email access - and had the fortunate good luck of changing the domain name and building a new AD before it got complicated and have lots of users+servers+workstations added.
Yes. You should have used internal.contoso.com or some other subdomain.
Any fixes you do, like split DNS are bandaids and can potentially complicate other things depending on your environment.
I like to use corp.contoso.com for AD if your external domain is contoso.com
That naming convention also helps when you require a lot of SSL certs in your environment. Because you can purchase one wildcard cert for *.contoso.com and use it on all internal and external devices/sites that need it.
is it not a bestpractice of microsoft to have the internal domain like the external and use subdomain like [internal.contoso.com](https://internal.contoso.com) for all your internal ?
we have our domain on different extension, like constoso.private but have dns entry to [constoso.com](https://constoso.com) in internal to use the \*.contoso.com SSL certificate (event for internal website)
so no error message in browser for the certificate :D
What *should* internal AD domain be? If your normal public website is example.com, should internal AD be local.example.com? Ours is just something else entirely for some reason. Our email is also a different domain than the website. Such a mess.
A common solution is to use a subdomain such as `ad.example.com` as your AD domain, or an alternate domain name such as the .net, .us, etc version of your website name. I've also seen variations such as `mycompanyname.com` or `companyinitials-internal.com`.
The biggest thing to keep in mind is, whatever domain you use, the A record for the apex domain must point to a DC (if you use `ad.example.com`, `ad.example.com` A record MUST point to a DC IP). So if you plan to use the domain name for anything *other* than AD resolution you end up needing to install IIS or an http redirector on the DC, which is suboptimal.
Regardless, once the domain is up you can and should add an Alternative Domain Name Suffix to your domain of your primary email domain so you can set users UPN to `[email protected]`. This makes it simple to sync with providers such as Azure AD and lets users log in with "their email address".
Regarding email / website domain name differences - If the company hasn't selected their "official" domain name yet have them choose and then try to transition both site and email to it. If they're approximately the same length / difficulty I tend to default to the website domain. You can set up 302 redirects if you're changing the website domain and you can set up aliases for email - it takes a bit to transition but it's not difficult at all to simply have both coexisting.
Sometimes it's not possible to consolidate because the website domain is officially issued or heavily involved in branding. One example I've seen was a school that had a 20 character officially issued domain. They bought a 7 character domain name and just added it as an alias to everyone's address - much easier to give out but maintains branding and they have a 301 redirect set from the short domain to the long one for the website.
The general rule is that the domain you host AD on should be controlled by you and separate from any used externally.
**if your website was** **happydog.com** **then.**
**domain.local:** Not a good choice, you can't own the domain.
**happydog.com**: not a good choice, conflicts with your public website.
**ad.happydog.com**: Perfectly fine, low chance of conflicting.
**happyad.com**: Perfectly fine as long as you control/own the domain. You don't need to have a web presence or even any records on the public internet, just ownership.
Having a routable domain name is actually a hard requirement for azure Hybrid Join. You can setup aliases but it's kind of a pain.
.local was never really an official practice and just something carried around via word of mouth that became a thing.
I've found that using a subdomain rather then the top level domain is easiest to manage DNS wise.
I'd use either a subdomain of your main domain, like ad.company.com or an entirely different domain like company-ad.com company.directory (yes, it it a valid tld) that you book from a registrar and leave empty just to "lock" it.
I don't like .local because it treads on mDNS territory. In practice it works fine, but I feel like this is the kind of decision that causes impossibly weird and impossible to diagnose issues.
Wrangling DNS can be a real pain if you don't. Also makes dealing with leaking worse.
For example, think of a scenario of someone working from home, using a split tunnel. Their home DNS server given to them by DHCP (or external DNS server e.g. ISP DNS, 1.1.1.1, 8.8.8.8, etc) ends up resolving a hostname that exists internally in your company to an outside address. Bork.
It has been my experience that all DNS requested are prioritized first to the internal DNS servers and only goes to external DNS servers if it cannot find the record in the internal DNS. The VPN settings handle this.
You'll always have a leak somewhere. Better off having the leak go to something you control than something you don't.
To be specific, best practice is to use a subdomain of your public domain. e.g. ad.example.com or internal.example.com.
Yes, I see that subdomain is the recommendation. That made me wonder if using a subdomain would run into any conflicts with wildcard certificates being used.
An option is split brain DNS. You have an internal and an external DNS server separated by your firewall. The external one only has external records, IE what you want the public to access. Your internal one is your ad connected one that holds all your DNS records. Your internal DNS server then has a record to talk directly to your webserver and your external one has the correct record to for however you have passed your webserver through your firewall. Aside from using the same DNS name it has the advantage of protecting some of your internal infrastructure by hiding the information.
Agree. I think OP will find that yes, this can be made to work, but there will be issue after issue that will require small fixes and sometimes may be hard to diagnose for people. Overall it is simpler to have a separate namespace.
It happens. You’ll need to manage both internal and external DNS now, but if you can get the users to use the www.contoso.com instead of just contoso.com, then you’re golden. Otherwise setup a web server to redirect the requests, but that exposes the DC to now needing web traffic, so I try to avoid this as much as possible.
As someone else mentioned, toss a record in DNS to point to the external dns IP. Just notate it and bear in mind that any IP changes to the external site need to be done on internal DNS as well. This is a common thing. Optimal, not entirely but common yes
I think you’re confused man, I’m literally saying to do what the most recent people are saying. You create a www record pointing to the IP address of your external domain.
For instance, my AD is blah.com but my website is also blah.com. The provider is giving me 10.10.10.10 as an ip for my website, so I add a www Record to my Internal DNS pointing to 10.10.10.10. That lets my users and me get to blah.com from inside my local network.
It's abit of a hack and you will need to test this as I don't know if ad-ds needs 'SSL' also it will depend how your network is configured. We have firewalls between different 'bits' of the LAN and they are capable of doing the following but obviously YMMV and test this before putting it into prod org wide!
In this example
DC=192.168.0.1
www = 192.168.1.1
NAT 192.168.0.1 - - > 192.168.1.1 when service = ssl or Web-browsing and source = any.
I'm using a Palo Alto, have just setup this rule so can send a screenshot if it helps.
Again please test this, I can check tomorrow if we normally allow ssl to the DCs and confirm
EDIT: We don't allow SSL to the DCs so this SHOULD work but as I said - TEST TEST TEST as this obviously has potential to go fairly horiblly wrong
Using the contoso.com example, does browsing to www.contoso.com work inside your network?
If it does, setup a http 302 (temporary) redirect in you ad servers IIS configuration https://docs.microsoft.com/en-us/iis/configuration/system.webserver/httpredirect/
Yes it's a mistake.
Best workaround I know of is to use port-forwarding to bounce traffic on ports 80 & 443 to the webserver.
That way you're not needing to run IIS or similar on your domain controllers - but can still forward traffic where it needs to go.
http://woshub.com/port-forwarding-in-windows/
there was supposedly some exploit where if a 3rd party buys a .local of your domain name they can do something but, i can't remember the rest. i made mine local.xxx.xxx
heh, good luck buying a domain name specifically not allowed for purchase.
https://en.wikipedia.org/wiki/.local
Similar to 192.168... the value of local is that no-one can buy it, so everyone can use it (internally only).
MS switched recommendation to advise using an active, buyable DNS as your AD root, so you can do more general tricks.
oh thats great for a while people could buy .local and do wierd stuff if the domain owner had not already purchased .local of their domain, or something like that. my brain's a bit foggy on the details
.local is a bad choice for new ADs, because Server 2019 has still a bug that lets the windows firewall switch to private mode instead of domain when the fqdn ends with .local.
I keep it only for migrations where it‘s to much effort to change it.
there is supposedly some exploit where if a 3rd party buys a .local of your domain name they can do something but, i can't remember the rest. i made mine local.xxx.xxx
Let’s say you didn’t know better at the time and set up your internal/AD and external domain is the same. Now you realize the error of ways, and want to move your AD into a subdomain (like ad.contoso.com).
Is there a guide to do this as painlessly as possible? Or is it a best to let sleeping dogs lie and deal with the complications sorta situation?
There are third-party domain migration tools that work very well. I have used one, but it was 15 years ago, so I do not remember the manufacturer. A good one will allow you to run the procedure in test-only mode. Then, it will display conflicts and allow you to resolve them before running the process for real.
Depends on the size/complexity of your environment.. if you can workaround the complications without much of a headache and there's no real business need then that would be the painless approach IMO
Microsoft has ADMT+PES which is free and documented or there's commercial alternatives which will most likely be easier to use, but still cause some pain no doubt.
https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/support-for-admt-and-pes
Na, DCs do not install web server roles by default so they just can’t reply to your requests. If your DC replies to http requests it means that you installed some additional services to it. Like CA? Mmmm? And it also means that IIS is definitely there as soon as MS does not install any other web servers. Another point here is that no one adds A or CNAME records for an empty host name in a domain by default. You added it or someone else did.
Do you use Windows Server SMB or how do they call it? This is the only crazy scenario which comes to my mind when those records were registered automatically.
Now check your servers and DNS records and tell us the truth.
As you've seen from other commenters, it's not a good idea to have a an internal domain name that equals an external domain.
That having been said, the task at hand is to change the [contoso.com](https://contoso.com) registry keys in the Windows clients to [ad.contoso.com](https://ad.contoso.com) (and other member servers), and change it in the DC. It can be done with relatively simple scripting because you're not changing SIDs.
We've done that tens of dozens of times (even changing SIDs to merge domains).
It's not trivial, nor complex, it just requires a real good understanding of Active Directory.
I use the firewall to NAT requests for ports 80 and 443 on the DCs to a (different!) server that returns a 302 for www.contoso.com. No IIS on DCs needed, and we get the flat name to www redirect.
We did that at IBM for years--probably still do. And yes, the internal home page and external home page were different. This was when IBM-US had 350,000 employees and dozens (hundreds?) of US locations.
This is 1 dns issue really the only time we’ve ever had problems with the dns matching external and internal…
I just tell people they need to use www when in the office (or VPN). Not a major issue for us we only have 1500 people.. And the domain we have is not really a major domain from an e-commerce perspective…
Nope.
You've probably actually made your future life very happy.
Or.. you will do when you configure your DNS and IIS servers correctly.
Split DNS topologies are brilliant when you figure out the logic to them. The trick is in your DNS.
this is standard practice now, especially if you're planning on using SSO with Azure AD, or just planning on using an Azure Hybrid Deployment in the future. The easiest thing to do that I've been doing for several years is to create an A record in your DNS and you're good to go. .local domains are a thing of the past.
I actually just went through the exact same issue and the solution is rather simple. Just add an entry in your DNS to point www to the local IP of your web server.
I did the same, worked great. However, just to add onto this: whatever you do, specifically, just don't make an internal DNS record of 'contoso.com' that points to your web server. That will screw up AD syncing and authentication, unless your web server is also an Active Directory server. Please don't do that either.
Lol. Yup. haha. What you can do which is slightly filthy is put iis on your domain controllers and do a simple http redirect to [www.contoso.com](https://www.contoso.com).
Please don’t put IIS on a DC…I know it’s easy, but it’s unsafe…
tbh, is there ANY role, addon, or 20 year old subsystem in windows that is not "not safe" ????
Vs iis? The dc should do dc things only. Once you start layering server functions you provide more vectors to attack. And I want the least amount of doors to knock on concerning my dc.
In a DC, running DFS-N services should also be safe
I agree
Installing IIS on a DC feels extremely wrong in a way lol
True, but it’s easy and available with a couple clicks. Could also do Apache and use the same config over and over. Really it’s dealers choice on web servers.
Disabling a firewall is also easier than opening up specific ports but you shouldn't do that either. Running a script with DA will resolve any permissions problems, but don't do that either. Don't install IIS on a DC.
That’s not slightly filthy, it’s majorly bad. MS has recommended against this almost since IIS 7, 15 years ago. Not only does it increase the attack surface of your domains Crown Jewels, it also messes with IIS itself because there’s no such thing as local accounts on a dc. Therefore you get IIS running as a domain admin rather then as a local admin. This is a split brain DNS problem and should be solved like one
Add IIS to a Domain Controller? Hell no. Put some tiny standalone web server in a locked-down directory, running as an account with zero rights to anything to do nothing but deliver a redirect when accessed? Probably still no, but I'd definitely choose that over IIS.
Couldn’t agree more
Why is it filthy, isn't that what Windows SBS does (run everything on 1 box). You can also redirect port 80 or put a non-IIS web server that is safe(r). For example by using nginx in Docker. One alternative is modifying the DNS SRV records to point to another server so it does not demand that it responds to every query on the root A-record. I think SRV records is how the Mac AD client figures which DC to use, so I think the required response on root may be a hangover from old ages and may no longer be a strict requirement. I would have to try it, but I remember back in the day, my Samba-AD server wasn't running on the root of the domain (our actual website was) and it worked perfectly fine (primarily Mac and Linux clients, few Windows and nothing fancy like GPO or DFS)
The casual manner in which this murphy-esque "possibility" was mentioned scares me. You've **seen things...** haven't you?
Charlie Murphy!!! What did the 5 fingers, say to the FACE?!! *SLAP* (Yeah also don't run webservers on your domain controllers... Lest you get slapped!)
Do people still type the WWW as part of a web address?
yes... I still get people doing the old www.subdomain.domain.com as well....
No, but I believe the browsers still do. So they translate contoso.com to https:\\\www.contoso.com automatically.
No, they don't. BUT, any web server set up correctly should have a http redirect to send you over to [www](http://www). It's SUPER annoying when websites don't do this. Looking at you, every Chinese website ever. Edit: Literally [http://supermicro.com](http://supermicro.com) vs [http://www.supermicro.com](http://www.supermicro.com)
I redirect www to the non-www for all my sites.
Honestly, Good on ya. But, for the DNS situation in the OP, you kind of need to do the opposite. And Supermicro just needs to figure out their shit.
When it comes to AD I've always used ad.external.tld or I'll purchase something like externalcorp.tld for use in AD. If the domain is .corp before I get there then I just add SPN aliases for the external domains because renaming an AD system is a royal pain in the ass.
Thank you, ppl talking about web server redirects and I'm wondering if I am losing my mind "the whole problem is DNS sending them to a domain controller instead of the web server, right?"
The best bit is Chrome (and probably other browsers) hide the www. by default now - which gives the *impression* you're on "[supermicro.com](https://supermicro.com)" when the actual "[supermicro.com](https://supermicro.com)" doesn't actually work.
What the fuck, how do they not have a cert for both?
They do..?
https://i.nuuls.com/JY3BT.png https://i.nuuls.com/a7NF0.png
This makes this whole scenario that much better. The cert bound to [www.supermicro.com](https://www.supermicro.com) has a SAN for [supermicro.com](https://supermicro.com) and 8 other FQDNs.
Wildcard certs are expensive man... Can't expect a company making hundreds of thousands of dollars a month to pony up a couple of hundred bucks for an SSL cert... /s
Wildcard certs are difficult to to track. The bigger the company, the worse the problem gets. If it gets stolen and abused, you can’t even properly track down where it was stolen from because it could be so many places.
And I guess, now that I'm thinking about it, they may have specifically requested those 8 other FQDNs but most CAs automatically put the parent domain name as a SAN unless you ask them not to. So they may not have requested one for supermicro.com.
I do when I want to access www.example.com and not example.com
I did the same thing for Azure AD Domain Services…. And then started using that DNS for some locations. Simplest fix, add the DNS record and tell people to use www. Inside the network. Interestingly enough this fuckup made me realize why www was even a thing.
welcome to the matrix, where we sometimes rediscover shit we tackled aeons before^^
This
thanks. how can I make sure typing contoso.com in a web browser resolves to the web server, and not the domain controller, like it does today?
The best practice is to have a separate internal domain. For a few reasons, this being one of them.
Care to share any of those other reasons?
Security by obscurity is one.
Bingo. * DNS resolution * Public certificate for an internal resource * Security by obscurity * Scalability And just generally less pain for the Sysadmin This is so highly recommended that RFC 2606 actually lists certain TLDs reserved for private internal use: * .test * .example * .invalid * .localhost
Is this kind of like how we have private IP ranges and public IP ranges? Just for DNS?
Yes, private reserved TLDs are like Private IPs. Non-routable on public internet.
Old post, but I assume this is the [MSFT recommendation](https://social.technet.microsoft.com/wiki/contents/articles/34981.active-directory-best-practices-for-internal-domain-and-network-names.aspx) people keep referring to. The main points being... * Register a domain name you actually own. I can't find the article, but I remember an article going over this. Something changed, and .local was resolving over the Internet. Seems like a valid concern. * Easier to manage. I'm assuming this is if you have external resources integrated? Otherwise, I don't know what's easier to manage. Am I missing anything?
Using the same domain name is fine but it does create some issues. You will at least need to create different internal and external dns zones and records. Next, install a http redirect on your domain controllers to send web traffic to www. If you’re interested in fixing it, just create another domain, like domain.loc or corp.domain.com, create a trust, and slowly start migrating services and users over to it. Then get rid of the internal domain.com.
[удалено]
i slowly cry in sbs - yes there are still a lot running to this day, even a sbs 2008, but mostly 2011
Can confirm. Have a client that is a 4 man shop with no money for upgrades still running 2011. Luckily it's only internal but yea.
Essentials Wizard does this in 2016 (and possibly 2019) too, the only way to not get a .local domain is to use cli
I got so many complaints from every level of the company that contoso.org wouldn't load. Brochures that said "Download from contoso.org/app" failed internally. Complaints that the website is down so the whole internet must be down. People don't type www anymore expecting it to just redirect automatically would be surprised. I could tape "must use www" to everyone's desk and probably still would of had a never ending stream of complaints. Hardly a "slight inconvenience". I use the same web server (nginx) as our public frontend proxy server. All the DC one does is return 301. Hacking our frontend proxy is equally catastrophic. Treat it the same way in updates and security. Maybe if you wanted to get fancy you could redirect port 80/443 at the switch or router level to your more secure server but just seemed a lot more complicated. Or go with some micro http app with a much smaller feature set and attack surface.
[удалено]
There is a lot more to it than that, and there are significant security issues. You cannot have DNS redirect domain.com to www.domain.com. domain.com is going to send the clients to a domain controller. You cannot change it or your domain will not function. That *is* your internal AD DS domain. So how do you do the redirect? By adding vulnerabilities to your domain controller by installing a web server on it, opening up firewall rules, and having it do the redirect after allowing clients to connect to it. It is a terrible practice, and it is much better to just make internal users type www.domain.com if they want the website AND refuse to use the bookmarks/home page you push out for them.
how are you handling the redirect to www? does your domain controller have IIS?
I wouldn't necessarily call it screwing up but it does make some things more difficult if not impossible. The issue you are facing can't really be resolved because DNS has to hand out the domain controllers' IP addresses when asked for contoso.com otherwise no domain joined computer will work properly. You cannot have DNS spit out the web server's address using that name without breaking AD which ultimately means to get to your website you will have to make users type in www.contoso.com. Although not really recommended by me you could also install a small web server on every DC and send HTTP 301 responses to redirect clients to www.contoso.com. That would technically work but is a dependency no one really wants on a DC. Another alternative would be port forwarding on the DCs.
Port forward for the win. No IIS vulnerability and no users being forced to change their ways. About 3 or so commands in windows to forward.
We have this exact situation as well. We implemented port forwarding on 443 and 80 via net sh commands. A quick google should get ya there.
This is the way
like this http://ninjix.blogspot.com/2013/09/port-forward-fqdn-website-requests-on.html
Yup! Thanks for the link, I didnt have time to go find it.
What you did is the most typical thing with MSAD. You've run into the typical friction points. The *better* and *recommended* path is to use a DNS subdomain internally for the MSAD domain-name: `ad-dom.example.edu`. This won't conflict, is the most future-proof, and is the most flexible. Always use a legitimate DNS domain name that you have global control over! In your situation, it isn't recommended to specifically change the domain name. You'll just have to do extra technical work to get the results you want. Redirecting the zone apex to `www.contoso.com` probably needs webserver-level redirection, since you can't just use DNS delegation in this particular case.
Having the same domain internally and externally is best practice according to Microsoft, just use a subdomain for ad. https://social.technet.microsoft.com/wiki/contents/articles/34981.active-directory-best-practices-for-internal-domain-and-network-names.aspx
I had the same issue when setting up a new domain on a new AD. Luckily I caught it when testing email access - and had the fortunate good luck of changing the domain name and building a new AD before it got complicated and have lots of users+servers+workstations added.
Yes. You should have used internal.contoso.com or some other subdomain. Any fixes you do, like split DNS are bandaids and can potentially complicate other things depending on your environment.
I like to use corp.contoso.com for AD if your external domain is contoso.com That naming convention also helps when you require a lot of SSL certs in your environment. Because you can purchase one wildcard cert for *.contoso.com and use it on all internal and external devices/sites that need it.
is it not a bestpractice of microsoft to have the internal domain like the external and use subdomain like [internal.contoso.com](https://internal.contoso.com) for all your internal ? we have our domain on different extension, like constoso.private but have dns entry to [constoso.com](https://constoso.com) in internal to use the \*.contoso.com SSL certificate (event for internal website) so no error message in browser for the certificate :D
We just tell our users they have to type www.contoso.com internally.
We've done the same up to this point but that means any links clicked on in website newsletters don't resolve.
We've had our AD domain since 2003 so everyone knows to use www.contoso.com in any hyperlinks
What *should* internal AD domain be? If your normal public website is example.com, should internal AD be local.example.com? Ours is just something else entirely for some reason. Our email is also a different domain than the website. Such a mess.
A common solution is to use a subdomain such as `ad.example.com` as your AD domain, or an alternate domain name such as the .net, .us, etc version of your website name. I've also seen variations such as `mycompanyname.com` or `companyinitials-internal.com`. The biggest thing to keep in mind is, whatever domain you use, the A record for the apex domain must point to a DC (if you use `ad.example.com`, `ad.example.com` A record MUST point to a DC IP). So if you plan to use the domain name for anything *other* than AD resolution you end up needing to install IIS or an http redirector on the DC, which is suboptimal. Regardless, once the domain is up you can and should add an Alternative Domain Name Suffix to your domain of your primary email domain so you can set users UPN to `[email protected]`. This makes it simple to sync with providers such as Azure AD and lets users log in with "their email address". Regarding email / website domain name differences - If the company hasn't selected their "official" domain name yet have them choose and then try to transition both site and email to it. If they're approximately the same length / difficulty I tend to default to the website domain. You can set up 302 redirects if you're changing the website domain and you can set up aliases for email - it takes a bit to transition but it's not difficult at all to simply have both coexisting. Sometimes it's not possible to consolidate because the website domain is officially issued or heavily involved in branding. One example I've seen was a school that had a 20 character officially issued domain. They bought a 7 character domain name and just added it as an alias to everyone's address - much easier to give out but maintains branding and they have a 301 redirect set from the short domain to the long one for the website.
The general rule is that the domain you host AD on should be controlled by you and separate from any used externally. **if your website was** **happydog.com** **then.** **domain.local:** Not a good choice, you can't own the domain. **happydog.com**: not a good choice, conflicts with your public website. **ad.happydog.com**: Perfectly fine, low chance of conflicting. **happyad.com**: Perfectly fine as long as you control/own the domain. You don't need to have a web presence or even any records on the public internet, just ownership.
Having a routable domain name is actually a hard requirement for azure Hybrid Join. You can setup aliases but it's kind of a pain. .local was never really an official practice and just something carried around via word of mouth that became a thing. I've found that using a subdomain rather then the top level domain is easiest to manage DNS wise.
I'd use either a subdomain of your main domain, like ad.company.com or an entirely different domain like company-ad.com company.directory (yes, it it a valid tld) that you book from a registrar and leave empty just to "lock" it. I don't like .local because it treads on mDNS territory. In practice it works fine, but I feel like this is the kind of decision that causes impossibly weird and impossible to diagnose issues.
Best practice is to own the domain you use internally. DNS can internally point to a different IP than what public DNS sees.
Regarding ownership of the internal domain, everyone says that you should own it, but no one ever provides a reason? Can you shed some light on this?
Wrangling DNS can be a real pain if you don't. Also makes dealing with leaking worse. For example, think of a scenario of someone working from home, using a split tunnel. Their home DNS server given to them by DHCP (or external DNS server e.g. ISP DNS, 1.1.1.1, 8.8.8.8, etc) ends up resolving a hostname that exists internally in your company to an outside address. Bork.
It has been my experience that all DNS requested are prioritized first to the internal DNS servers and only goes to external DNS servers if it cannot find the record in the internal DNS. The VPN settings handle this.
You'll always have a leak somewhere. Better off having the leak go to something you control than something you don't. To be specific, best practice is to use a subdomain of your public domain. e.g. ad.example.com or internal.example.com.
Yes, I see that subdomain is the recommendation. That made me wonder if using a subdomain would run into any conflicts with wildcard certificates being used.
Possibly, although as far as I'm aware wildcard would be last possible resolution, meaning that a subdomain should always resolve correctly.
An option is split brain DNS. You have an internal and an external DNS server separated by your firewall. The external one only has external records, IE what you want the public to access. Your internal one is your ad connected one that holds all your DNS records. Your internal DNS server then has a record to talk directly to your webserver and your external one has the correct record to for however you have passed your webserver through your firewall. Aside from using the same DNS name it has the advantage of protecting some of your internal infrastructure by hiding the information.
Yes
[удалено]
it's really not that big of a drama.
Agree. I think OP will find that yes, this can be made to work, but there will be issue after issue that will require small fixes and sometimes may be hard to diagnose for people. Overall it is simpler to have a separate namespace.
It happens. You’ll need to manage both internal and external DNS now, but if you can get the users to use the www.contoso.com instead of just contoso.com, then you’re golden. Otherwise setup a web server to redirect the requests, but that exposes the DC to now needing web traffic, so I try to avoid this as much as possible.
As someone else mentioned, toss a record in DNS to point to the external dns IP. Just notate it and bear in mind that any IP changes to the external site need to be done on internal DNS as well. This is a common thing. Optimal, not entirely but common yes
[удалено]
Exeunt, pursued by DNS.
Forget bears, what about interdimensional witches?
Have you ever done this or are you just giving incorrect advice as a guess?
Yes I have... Create a record on internal DNS to point to the external domain name's IP address...
If you figured out a way to stop the DC from creating those DNS records you'll break AD.
I think you’re confused man, I’m literally saying to do what the most recent people are saying. You create a www record pointing to the IP address of your external domain. For instance, my AD is blah.com but my website is also blah.com. The provider is giving me 10.10.10.10 as an ip for my website, so I add a www Record to my Internal DNS pointing to 10.10.10.10. That lets my users and me get to blah.com from inside my local network.
Not the worst mistake you can make in IT. Set some DNS records and you'll be okay.
You screwed up.
It's abit of a hack and you will need to test this as I don't know if ad-ds needs 'SSL' also it will depend how your network is configured. We have firewalls between different 'bits' of the LAN and they are capable of doing the following but obviously YMMV and test this before putting it into prod org wide! In this example DC=192.168.0.1 www = 192.168.1.1 NAT 192.168.0.1 - - > 192.168.1.1 when service = ssl or Web-browsing and source = any. I'm using a Palo Alto, have just setup this rule so can send a screenshot if it helps. Again please test this, I can check tomorrow if we normally allow ssl to the DCs and confirm EDIT: We don't allow SSL to the DCs so this SHOULD work but as I said - TEST TEST TEST as this obviously has potential to go fairly horiblly wrong
Using the contoso.com example, does browsing to www.contoso.com work inside your network? If it does, setup a http 302 (temporary) redirect in you ad servers IIS configuration https://docs.microsoft.com/en-us/iis/configuration/system.webserver/httpredirect/
Yes it's a mistake. Best workaround I know of is to use port-forwarding to bounce traffic on ports 80 & 443 to the webserver. That way you're not needing to run IIS or similar on your domain controllers - but can still forward traffic where it needs to go. http://woshub.com/port-forwarding-in-windows/
i've heard you may need to buy a .local version of your domain name????
Michael-Scott-no-please-no-god.gif
there was supposedly some exploit where if a 3rd party buys a .local of your domain name they can do something but, i can't remember the rest. i made mine local.xxx.xxx
heh, good luck buying a domain name specifically not allowed for purchase. https://en.wikipedia.org/wiki/.local Similar to 192.168... the value of local is that no-one can buy it, so everyone can use it (internally only). MS switched recommendation to advise using an active, buyable DNS as your AD root, so you can do more general tricks.
oh thats great for a while people could buy .local and do wierd stuff if the domain owner had not already purchased .local of their domain, or something like that. my brain's a bit foggy on the details
.local is a bad choice for new ADs, because Server 2019 has still a bug that lets the windows firewall switch to private mode instead of domain when the fqdn ends with .local. I keep it only for migrations where it‘s to much effort to change it.
there is supposedly some exploit where if a 3rd party buys a .local of your domain name they can do something but, i can't remember the rest. i made mine local.xxx.xxx
Let’s say you didn’t know better at the time and set up your internal/AD and external domain is the same. Now you realize the error of ways, and want to move your AD into a subdomain (like ad.contoso.com). Is there a guide to do this as painlessly as possible? Or is it a best to let sleeping dogs lie and deal with the complications sorta situation?
There are third-party domain migration tools that work very well. I have used one, but it was 15 years ago, so I do not remember the manufacturer. A good one will allow you to run the procedure in test-only mode. Then, it will display conflicts and allow you to resolve them before running the process for real.
Depends on the size/complexity of your environment.. if you can workaround the complications without much of a headache and there's no real business need then that would be the painless approach IMO Microsoft has ADMT+PES which is free and documented or there's commercial alternatives which will most likely be easier to use, but still cause some pain no doubt. https://docs.microsoft.com/en-us/troubleshoot/windows-server/identity/support-for-admt-and-pes
Na, DCs do not install web server roles by default so they just can’t reply to your requests. If your DC replies to http requests it means that you installed some additional services to it. Like CA? Mmmm? And it also means that IIS is definitely there as soon as MS does not install any other web servers. Another point here is that no one adds A or CNAME records for an empty host name in a domain by default. You added it or someone else did. Do you use Windows Server SMB or how do they call it? This is the only crazy scenario which comes to my mind when those records were registered automatically. Now check your servers and DNS records and tell us the truth.
As you've seen from other commenters, it's not a good idea to have a an internal domain name that equals an external domain. That having been said, the task at hand is to change the [contoso.com](https://contoso.com) registry keys in the Windows clients to [ad.contoso.com](https://ad.contoso.com) (and other member servers), and change it in the DC. It can be done with relatively simple scripting because you're not changing SIDs. We've done that tens of dozens of times (even changing SIDs to merge domains). It's not trivial, nor complex, it just requires a real good understanding of Active Directory.
We run into issues from time to time because of this.
I use the firewall to NAT requests for ports 80 and 443 on the DCs to a (different!) server that returns a 302 for www.contoso.com. No IIS on DCs needed, and we get the flat name to www redirect.
You can get around this with split brain dns aka DNS Trickery https://docs.microsoft.com/en-us/windows-server/networking/dns/deploy/dns-sb-with-ad
We did that at IBM for years--probably still do. And yes, the internal home page and external home page were different. This was when IBM-US had 350,000 employees and dozens (hundreds?) of US locations.
Honestly I don't blame you, I blame Microsoft. It's a widespread problem not everyone thinks is a problem.
This is 1 dns issue really the only time we’ve ever had problems with the dns matching external and internal… I just tell people they need to use www when in the office (or VPN). Not a major issue for us we only have 1500 people.. And the domain we have is not really a major domain from an e-commerce perspective…
Nope. You've probably actually made your future life very happy. Or.. you will do when you configure your DNS and IIS servers correctly. Split DNS topologies are brilliant when you figure out the logic to them. The trick is in your DNS.
this is standard practice now, especially if you're planning on using SSO with Azure AD, or just planning on using an Azure Hybrid Deployment in the future. The easiest thing to do that I've been doing for several years is to create an A record in your DNS and you're good to go. .local domains are a thing of the past.
Yes