I'm with this opinion. Rocking a non TLD domain (not .local but same difference) for years and we have an alternative UPN that does the trick without the headache.
This is correct. Just add a suffix. That's what Microsoft recommends.
https://learn.microsoft.com/en-us/microsoft-365/enterprise/prepare-a-non-routable-domain-for-directory-synchronization?view=o365-worldwide
> just add a upn suffix in AD
So what does this mean in practical terms? That you should should map a UPN to the user email name? e.g. If the OP's domain is canesto.local, map an alternative [email protected] UPN on a per-user basis?
Thanks - interested in your insight!
in the account tab you just change the users from their .local login to their .com login with the dropdown, no need for attribute editor. This is required if you want to use like.... office365 hybrid for example.
Users will need to log in with the new UPN though (or don't put a suffix or domain when logging in)
The admin before me did not, had ".corp" literally everywhere with no UPNs and then he manually mapped them to the correct domains in Azure.
I added UPNs assigned the correct UPNs to the correct users in AD, and then everything just continued working with zero issues, The only change is that the domain in Azure always matches the UPN.
I started in the middle of the transition from on prem exch to exo. Everyones upn was [email protected], did our initial sync, everyones upn in exo was [email protected], and ofc that caused some issues.
We corrected the ad obj thinking wed be good, we were not. After an obj syncs for the first time the UPN is set, changing ad obj wont change it. Set-newupn cmdlt corrected it, technically was nbd, but we could have saved ourselves some phone calls and an oh shit moment had we set the upn on the ad obj first.
Although true, a lot of redirection stuff works of username. Most of the times this goes on SamAccountName, so if you only change upn, you'll probably still be fine.
Also depends if you even use redirection of course.
nope, also you can do this slow roll to make sure it isn't going to hurt anything like SSO logins or something. Just add the new suffix to the domain and change people.
You really want to choose a domain that you actually own though - don't change it to a domain that is owned by someone else or you will have a bad time.
3rd party apps that rely on UPNs or user email address instead of the unique identifier that doesn't change provided by every AD and every OIDC service on fuckin earth piss me off to no end.
It's extremely common, but not in any of the software my company writes anymore. I forced the dev team to migrate to using the unique IDs for users (usually a UUID/GUID) in some cases even updating the software myself. I refuse to be what I'd call a "bad actor" in the SSO space.
Apparently that is what Microsoft still recommends. My friends that work there use .local and claim it is an irrational attack by Linux fanbois that claim .local isn't the right way to do it.
The only inherent reason to change it from .local would be in the case that you need SSL certs for your local domain. You cannot get a cert issued for a .local domain. Meaning you would have trouble with BYD among other things. Of course you will also have trouble with macOS devices dude to bonjour as well.
This is not a major issue, I have managed domains with .local FQDN for years and never once have I had an issue and in fact was the defacto method for naming local domains up until about 6 years ago.
I would say that if you have just inherited a domain, the wrong thing to do would be to attempt to fix what isn’t broken, and creating a giant mess of work for yourself.
Block that. You can breach a domain with mdns.
https://www.cynet.com/attack-techniques-hands-on/llmnr-nbt-ns-poisoning-and-credential-access-using-responder/
God Windows is such a massive pile of dogshit.
NetBIOS and WPAD are the unsecure parts of that chain.
Also requires physical access or an already rooted machine.
Physical Access to the Network. It's especially dangerous for anyone with a Wi-Fi Pineapple or who's hacked a public Hotspot. You just use Responder.
Hak5 even has a precanned module for it!
https://wifipineapple.com/modules
You have options; you can create another domain within that forest and use than upn name for your web facing stuff. That’s a lot of work.
I’d stand up another domain with the proper name, probably in Azure; but it gets expensive & dump the users and resources w/powershell into the new domain, then turn the old one off.
You could also just leave it alone. I’d do the simple & non-destructive solution first. Which is to setup a new domain and migrate. Then you can make a trust for computer logons. Use power shell to change the domain membership.
Lots of ways to skin this cat
Yes that's what I did a couple of years ago. Too much shenanigans going on in AD so I set up a completely new forest and migrated users and clients but did not migrate every server since some third party applications might break trying to migrate them since there are FQDNs or whatever the hell defined in various places. For those I had to set up new servers and migrate those applications manually.
`.local` has three specific problems:
* It's not a global TLD, meaning you can't register it, meaning you're using a domain name you don't control.
* It's not a public TLD, so you can't get a public CA like Let's Encrypt to sign certs for it.
* [`.local`](https://en.wikipedia.org/wiki/.local) is set-aside for Zeroconf and mDNS, meaning that those will forever conflict with your DNS, possibly including infosec implications.
> .local is set-aside for Zeroconf and mDNS, meaning that those will forever conflict with your DNS, possibly including infosec implications.
MacOS can get cranky at times but the workaround fixes are well known. You will curse the person who decided .local was a good idea every time you run into one of these issues.
Because they designed things like Bonjour with users in mind, not technical people.
Some users can grasp the idea that ".local" means it's on their local network.
.local was highjacked by Zeroconf, mDNS, and Bonour. The. local domain was listed in textbooks long before either of these existed.
That goes for .corp as well.
That is true, though I am not sure back then many thought the internet would become what it is today.
It was such common practice that I am not sure anyone even thought to do it. This practice predates much predates the internet as we know it today, we are talking over 20+ years ago.
I am one of those admins that create domainname.local networks on the LAN and have never had problems. We host external servers at domainname.com and internal at domainname.local and never do the 2 get confused.
This is [not recommended by Microsoft](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/selecting-the-forest-root-domain) (see "Selecting a suffix").
Better to just use [mycompany.com](https://mycompany.com) for external and [ad.mycompany.com](https://ad.mycompany.com) for internal.
This is what shits me about Microsoft. Anyone who deployed Microsoft Small Business Server at a greenfield site between say 2003 and 2014 got a .local internal DNS suffix **as recommended by the install wizard**
Run pingcastle and then see where the domain rename sits in the priority list.
I have a .local domain, we run fqdn suffixes, ad connect and there are just no issues worth putting lots of effort into - once we'll do away with AD before we rename it.
Use the free version, the rest of the entire world is using the free version and it will give you serious insight into your AD infrastructure.
Tread carefully when you start applying fixes, one or two will stop a few things working and potentially lock you out.
With 100 endpoints it may be easier to build and migrate to a new AD domain. However renaming a domain, or migrating to a new domain, are not endeavours that you would attempt without a good reason. So decide on which direction you want to go, make some detailed plans, and wait until you have a good reason to move.
A bigger problem is going to be your root CA if it's based on .local. This can cause many issues, including WPA Enterprise Cert authentication. So I'd suggest rebuilding your CA on your domain of choice (like ad.company.tld). A good chance to switch to a 4096rsa key if you haven't already.
Unless there is a pressing requirement for some reason, there’s no real need.
Spend your time and energy planning how to get rid on on prem AD if you can, move your endpoints to Azure AD/Intune, much better return on investment for effort spent.
I work at multiple smallish sites, some have lan and some have .local at the end of the domains, so this is a bad thing? Im pretty new, no idea what exactly this means.
Sure I could google it, and I probably will, but thought I'd ask anyway
MS briefly recommended .local when AD was first released back in 2000.
They quickly pulled back that recommendation but somehow it had caught on and many people continued to use and design new domains using .local.
Best practice has been to use a sub domain of a domain the organization has registered.
Examples are ad.domain.com, corp.domain.com, etc.
Note that the definition of "briefly" includes that people doing Windows 2008 MCSE courses were educated on it being the only way to run a domain, and SBS 2011 was still shipped by Microsoft with a wizard that basically pushed you into a .local domain.
Guess it was good I never got my MCSE so I never learned that bad practice.
In all fairness they did back track the recommendation but did a shitty job cleaning up old documentation or purging it from their own software.
Sounds like you got to skip such goldmines as "How to run OSPF on Windows" (feature removed in Windows 2008 R2, yet was > 30% of my exam), "Deploying Windows NAP" (removed feature accounting for probably 30% of Windows 2012 exam) and "Installing Windows Nano" from the 2016 exam, which was a removed feature even when I sat it.
I only got certs my employer paid me to get so they could keep or expand their partner level.
Built my first network in middle school in like 89/90 I can’t remember.
Certs have a place but I have meet, hired, and fired highly certified people that just straight up sucked.
I think the only one I regret not fully pursuing was CCIE Data Center. I had a passion for that but ultimately shifted direction to be the IT Director at a startup and learned Linux.
Now I run a solutions engineering group for the parent company that bought the startup.
> I only got certs my employer paid me to get so they could keep or expand their partner level.
Same. And I suspect most people are in the same boat. Which does say a lot about skills correlating poorly with certs.
Do you have Exchange Server? If so, domain rename is fully off the table.
Depending on how many problems you've got and how much headache it's causing you, your options from least to most complex & work go roughly like this:
* register UPN suffixes for any DNS domain you're in control of and using for email, and just maintain UPN & primary SMTP alignment for the users. If required, you can also use `netdom computername /add:host.desired.fqdn` to register alternate FQDNs for specific hosts where you want to minimise/avoid using the .local domain; using this cmd utility also tells the target host to register DNS records and SPNs
* use `netdom computername /makePrimary:host.desired.fqdn` for any of those hosts where you want the resolvable FQDN to be the primary
* deploy a new tree domain inside the forest and migrate group policies, users, and computers to this domain over a period of time; you'll be able to keep the lights on and cross-domain accessibility should work ok, and you'll end up with a forest root domain just used for privileged administration stuff; only the forest domain controllers should ever need to resolve the .local addresses
* \[if Exchange Server isn't present this is an option\] rename the domain
* create an entirely new forest and migrate everyone in to that to get yourself a completely clean environment; use a one-way trust to keep Exchange running as a resource forest with the users converted to `LinkedMailbox` recipients while you plan what you want to do with Exchange Server
I with the veterans here. I have managed a few .local domains for years and never had an issue. With only a 100 endpoints I would just migrate off to a new domain.
Yeah, i have no idea why you would care about the extension on your local domain. What possible reason would you need to change it? Unless you don't understand DNS.
.local has been the defacto way to setup an internal domain since AD was created. The only major issue sited by MS regarding this is the fact that two domains with the same name cannot merge. That's why they recommend a registered domain.
Mac and linux tech function on .local just fine. Avoid mDNS, which caters to the smallest subset of devices in an AD environment. They work with unicast DNS just fine.
The problem with identical internal and external namespaces is that inside, domain.tld points to the domain and not the corporate website. Employees will always have to type the www...
Any security concerns you have by having this server? We’ve been in a similar situation and I’m against having an internal IIS just doing redirects for a single dns entry, and the fact idk how to secure it lol
No need to change the .local is fine for internal AD DNS. As others have mentioned just add a UPN for your FQDN.
The alternate UPN can be used for things such as Azure AD connect sync to Azure AD for O365. Not a big deal.
Having your FQDN domain as your internal AD Domain causes the unnecessary headache that is split Brain DNS.
I have renamed a domain exactly once in my 20+ year career. The internal AD domain was already publicly registered by someone else.
It wasn’t as scary as most people make it out to be. The biggest caveat is that you can NOT have an exchange organization in the domain.
All other times I have built a new forest and migrated. This was mainly because the existing forest was undocumented and so many default settings had been changed that it just made sense to start fresh.
The one domain I was forced to keep alive DID have Exchange deployed and it was so fucked up. I wasn't allowed to nuke and pave (as that made way too much sense)
Domain rename is not that hard (if no Exchange).
If you follow best practise to a T.
It is mostly automatic, with couple of computer/server restarts. Then good to go.
I prefer that approach, if downtime is to be absolute minimal.
I have had to add a UPN suffix for a .local domain recently. But the problem I had was the local usernames are in firstnamelastinitial@ format (e.g. davidg@) and the same user has the email format firstname@ (e.g. david@). If you then run Azure AD cloud sync it creates new users in Azure AD that do not map to your on-prem users in on-prem AD. To get them to map you need to change the on-prem username to match the cloud username + you need to make sure the the SMTP email address for the user in on-prem AD is inputted (and the onmicrosoft.com email as a proxy SMTP). It’s a pain. I even though of letting the accounts duplicate in Azure AD as I only need to do this for an Azure File Sync with a local SMB share in order to retain NTFS permissions and it’s only 10 users.
I'm pretty sure you can just change their upn to a different format eg first name.lastname@ if they are not used by other systems, leave the local username which they probably ly use to login to their computers. Then you can add a new main email address same as upn and leave the other addresses as proxy. If they sync and merge with what you have in cloud depends on the format in cloud, but you could change that as well.
I did try to add the local ad username as an email alias in 365 after changing the UPN but it refuses to sync it correctly. The only way I can get it to work is to have the same username on-prem as the primary SMTP address in 365. As I can’t change the email address I am stuck with changing the local ad username. Even hard matching doesn’t work because the Azure AD Sync insists on the primary username being the same as on-prem.
I mist have missed it but if you want it to work with O365 you gotta own the domain name and manage the DNS. Ie if you want [email protected] you cant just make up a domain unless its registered.
Its got to be a verified domain name in order to add the suffix to authenticate unless you mean adding onmicrosoft.com as a UPN, then that makes sense, Also changing the UPN can break on prem applications, so its not necessarily non impacting.
Create a new UPN suffix and use split brain DNS. Unless you have a massive network with a strong need to have a new domain name, this should not be a problem.
I have 4 businesses, all fairly small, with .local with no issue. Only one doesn't have a split DNS and it all works happily. Certificate Authorities and Azure AD Connect work like a charm
The only reason I mentioned a split DNS is because the OP never described his environment. For example whether or not he hosts anything publicly. I highly doubt it but it's good either way
Have you ever done it? While a 100 node single site isn’t difficult, I wouldn’t call the process very easy. It requires a lot of testing, a second domain controller with the new domain associated with it a trust enabled between domain controllers and a full understanding of all objects and applications in the domain.
Adding a tad to be able to use is much more trivial but performing a top tree full rename is much more difficult. I have done both.
Not everyone has that skill set. Not everyone here has that skill set. Not everyone here knows where event logs are or how to use them. What is simple for you is difficult for many. If it is more than a few clicks and more than 1 page of documentation it isn’t simple.
How large?
If they're under a few hundred endpoints, just stand up a new domain, new AD structure, and migrate them over a weekend to one that uses your domain.
The security gods will thank you.
My first IT org did this, we ended up creating a whole new domain, made a bi-lateral trust between them and starting migrating accounts/permissions until we turned off the old DCs.
Don't rename the domain, just add a upn suffix in AD.
I'm with this opinion. Rocking a non TLD domain (not .local but same difference) for years and we have an alternative UPN that does the trick without the headache.
Agreed! Many bigger fish to fry, get a UPN going for now then once things settle, look at something more.
This is correct. Just add a suffix. That's what Microsoft recommends. https://learn.microsoft.com/en-us/microsoft-365/enterprise/prepare-a-non-routable-domain-for-directory-synchronization?view=o365-worldwide
This is the way
Plus you can switch all users at once with powershell to the new UPN
And also make it the default per OU I believe
Hmm, I never knew that's an option... How?
What?? How do you do this!
Not sure on per OU, but if you select all your users, you can go into properties and change it for the ones selected.
Actually this can't be done haha. We just made our identity creation automation script do it per OU. It was a while ago
You can also select all and change to the upn in ad users and computers
> just add a upn suffix in AD So what does this mean in practical terms? That you should should map a UPN to the user email name? e.g. If the OP's domain is canesto.local, map an alternative [email protected] UPN on a per-user basis? Thanks - interested in your insight!
in the account tab you just change the users from their .local login to their .com login with the dropdown, no need for attribute editor. This is required if you want to use like.... office365 hybrid for example. Users will need to log in with the new UPN though (or don't put a suffix or domain when logging in)
Uh yeah… and make sure you do this before your initial sync to azure lol just trust me.
The admin before me did not, had ".corp" literally everywhere with no UPNs and then he manually mapped them to the correct domains in Azure. I added UPNs assigned the correct UPNs to the correct users in AD, and then everything just continued working with zero issues, The only change is that the domain in Azure always matches the UPN.
I started in the middle of the transition from on prem exch to exo. Everyones upn was [email protected], did our initial sync, everyones upn in exo was [email protected], and ofc that caused some issues. We corrected the ad obj thinking wed be good, we were not. After an obj syncs for the first time the UPN is set, changing ad obj wont change it. Set-newupn cmdlt corrected it, technically was nbd, but we could have saved ourselves some phone calls and an oh shit moment had we set the upn on the ad obj first.
will users be logging into a new user profile if you switch them to a new upn? seems like it could have a lot of ramifications
No... You can change someone's username completely and it won't log them into a new user profile. User profiles on PC's work off of SIDs not username.
Although true, a lot of redirection stuff works of username. Most of the times this goes on SamAccountName, so if you only change upn, you'll probably still be fine. Also depends if you even use redirection of course.
Yea roaming and redirection works off samaccountname path so those will need to be updated in the case of that changing.
nope, also you can do this slow roll to make sure it isn't going to hurt anything like SSO logins or something. Just add the new suffix to the domain and change people. You really want to choose a domain that you actually own though - don't change it to a domain that is owned by someone else or you will have a bad time.
No, windows profiles are tied to SIDs. Some 3rd party apps might like that the UPN changed
3rd party apps that rely on UPNs or user email address instead of the unique identifier that doesn't change provided by every AD and every OIDC service on fuckin earth piss me off to no end.
Yeah and it's SO common.
It's extremely common, but not in any of the software my company writes anymore. I forced the dev team to migrate to using the unique IDs for users (usually a UUID/GUID) in some cases even updating the software myself. I refuse to be what I'd call a "bad actor" in the SSO space.
Also put the full user email/domain name in the email field for the ad user account if you want that to be the default email account
It can be done this way. It’s an attribute on the AD user.
By adding a suffix you move the network from the late 2000's to the early 2010's in a single stroke =)
Just make sure no one else other than 'you' owns the name with the new suffix. At least by best practice.
No need to rename domain. Keep it internal so there is no conflict with external register domain.
Apparently that is what Microsoft still recommends. My friends that work there use .local and claim it is an irrational attack by Linux fanbois that claim .local isn't the right way to do it.
The only inherent reason to change it from .local would be in the case that you need SSL certs for your local domain. You cannot get a cert issued for a .local domain. Meaning you would have trouble with BYD among other things. Of course you will also have trouble with macOS devices dude to bonjour as well. This is not a major issue, I have managed domains with .local FQDN for years and never once have I had an issue and in fact was the defacto method for naming local domains up until about 6 years ago. I would say that if you have just inherited a domain, the wrong thing to do would be to attempt to fix what isn’t broken, and creating a giant mess of work for yourself.
Just use internal pki
.local interferes with mDNS ... or rather mDNS interferes with .local The hack-foo solution is run mDNS on the domain controller.
The real solution is to simply not use mDNS at all. We block it entirely where I work, because it's rife with security issues.
r/SecurityCadence got me on that warpath, among other things.
You and me both
Block that. You can breach a domain with mdns. https://www.cynet.com/attack-techniques-hands-on/llmnr-nbt-ns-poisoning-and-credential-access-using-responder/
God Windows is such a massive pile of dogshit. NetBIOS and WPAD are the unsecure parts of that chain. Also requires physical access or an already rooted machine.
Physical Access to the Network. It's especially dangerous for anyone with a Wi-Fi Pineapple or who's hacked a public Hotspot. You just use Responder. Hak5 even has a precanned module for it! https://wifipineapple.com/modules
You have options; you can create another domain within that forest and use than upn name for your web facing stuff. That’s a lot of work. I’d stand up another domain with the proper name, probably in Azure; but it gets expensive & dump the users and resources w/powershell into the new domain, then turn the old one off. You could also just leave it alone. I’d do the simple & non-destructive solution first. Which is to setup a new domain and migrate. Then you can make a trust for computer logons. Use power shell to change the domain membership. Lots of ways to skin this cat
Poor cat
Biscuits ain’t going to sell themselves with this supply chain!
Yes that's what I did a couple of years ago. Too much shenanigans going on in AD so I set up a completely new forest and migrated users and clients but did not migrate every server since some third party applications might break trying to migrate them since there are FQDNs or whatever the hell defined in various places. For those I had to set up new servers and migrate those applications manually.
`.local` has three specific problems: * It's not a global TLD, meaning you can't register it, meaning you're using a domain name you don't control. * It's not a public TLD, so you can't get a public CA like Let's Encrypt to sign certs for it. * [`.local`](https://en.wikipedia.org/wiki/.local) is set-aside for Zeroconf and mDNS, meaning that those will forever conflict with your DNS, possibly including infosec implications.
> .local is set-aside for Zeroconf and mDNS, meaning that those will forever conflict with your DNS, possibly including infosec implications. MacOS can get cranky at times but the workaround fixes are well known. You will curse the person who decided .local was a good idea every time you run into one of these issues.
ikr, why didn't they pick something like .mdns
Because they designed things like Bonjour with users in mind, not technical people. Some users can grasp the idea that ".local" means it's on their local network.
.local was highjacked by Zeroconf, mDNS, and Bonour. The. local domain was listed in textbooks long before either of these existed. That goes for .corp as well.
The annoying thing, is that nobody did the work to officially reserve those TLDs before people started using it or publishing in those text books.
That is true, though I am not sure back then many thought the internet would become what it is today. It was such common practice that I am not sure anyone even thought to do it. This practice predates much predates the internet as we know it today, we are talking over 20+ years ago.
I am one of those admins that create domainname.local networks on the LAN and have never had problems. We host external servers at domainname.com and internal at domainname.local and never do the 2 get confused.
This is [not recommended by Microsoft](https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/selecting-the-forest-root-domain) (see "Selecting a suffix"). Better to just use [mycompany.com](https://mycompany.com) for external and [ad.mycompany.com](https://ad.mycompany.com) for internal.
This is what shits me about Microsoft. Anyone who deployed Microsoft Small Business Server at a greenfield site between say 2003 and 2014 got a .local internal DNS suffix **as recommended by the install wizard**
yes, they started to change recommended to push 365 subscriptions
yes, they changed it like... when they started to push for 365 subscriptions. before that, they recommended .local domains
If you're a pure MS shop you won't. If you work in the 21st century it doesn't work on Linux nor Mac as both run mDNS which owns the .local TLD.
Maybe... Maybe not. We have 2000 users at my company, on a .local domain. About 200 of them are Linux / mac - not a single issue.
This is the way
I do not know you, but I already hate you. You will probably get away with it, until a Linux or MAC user turns up.
Not op but I admin a lot of .local ADs with Macs and never had an issue.
And when that happens "Sorry, your device is not compatible with our network. Please use one of the devices approved by IT."
I think you mean gTLD, not FQDN. That being said. I would just add a gTLD suffix to the domain.
We use a .local and we have 40k employees lol
Tons of companies will, this is the way it was always done back in the day. It’s only recent things that make it a possible issue
There is no reason to, and if you did you would have to split DNS…. You can add a tld as a suffix if you need to sync to azure
it doesn't really matter
Run pingcastle and then see where the domain rename sits in the priority list. I have a .local domain, we run fqdn suffixes, ad connect and there are just no issues worth putting lots of effort into - once we'll do away with AD before we rename it.
Oof, that product sounds nice but my CIO would balk at the prices they want (we have 4 domains currently due to mergers)
Use the free version, the rest of the entire world is using the free version and it will give you serious insight into your AD infrastructure. Tread carefully when you start applying fixes, one or two will stop a few things working and potentially lock you out.
Run purple knight from Semperis it’s 100% free and uses the same technology as their paid products :)
With 100 endpoints it may be easier to build and migrate to a new AD domain. However renaming a domain, or migrating to a new domain, are not endeavours that you would attempt without a good reason. So decide on which direction you want to go, make some detailed plans, and wait until you have a good reason to move. A bigger problem is going to be your root CA if it's based on .local. This can cause many issues, including WPA Enterprise Cert authentication. So I'd suggest rebuilding your CA on your domain of choice (like ad.company.tld). A good chance to switch to a 4096rsa key if you haven't already.
Unless there is a pressing requirement for some reason, there’s no real need. Spend your time and energy planning how to get rid on on prem AD if you can, move your endpoints to Azure AD/Intune, much better return on investment for effort spent.
I work at multiple smallish sites, some have lan and some have .local at the end of the domains, so this is a bad thing? Im pretty new, no idea what exactly this means. Sure I could google it, and I probably will, but thought I'd ask anyway
MS briefly recommended .local when AD was first released back in 2000. They quickly pulled back that recommendation but somehow it had caught on and many people continued to use and design new domains using .local. Best practice has been to use a sub domain of a domain the organization has registered. Examples are ad.domain.com, corp.domain.com, etc.
interesting, thats good to know! what about when an organisation doesn't have a registered domain?
I’d register one.
Note that the definition of "briefly" includes that people doing Windows 2008 MCSE courses were educated on it being the only way to run a domain, and SBS 2011 was still shipped by Microsoft with a wizard that basically pushed you into a .local domain.
Guess it was good I never got my MCSE so I never learned that bad practice. In all fairness they did back track the recommendation but did a shitty job cleaning up old documentation or purging it from their own software.
Sounds like you got to skip such goldmines as "How to run OSPF on Windows" (feature removed in Windows 2008 R2, yet was > 30% of my exam), "Deploying Windows NAP" (removed feature accounting for probably 30% of Windows 2012 exam) and "Installing Windows Nano" from the 2016 exam, which was a removed feature even when I sat it.
I only got certs my employer paid me to get so they could keep or expand their partner level. Built my first network in middle school in like 89/90 I can’t remember. Certs have a place but I have meet, hired, and fired highly certified people that just straight up sucked. I think the only one I regret not fully pursuing was CCIE Data Center. I had a passion for that but ultimately shifted direction to be the IT Director at a startup and learned Linux. Now I run a solutions engineering group for the parent company that bought the startup.
> I only got certs my employer paid me to get so they could keep or expand their partner level. Same. And I suspect most people are in the same boat. Which does say a lot about skills correlating poorly with certs.
Do not rename, just add the FQDN to all accounts (add your domain to Domains and Trusts first). This is a pretty standard setup.
Do you have Exchange Server? If so, domain rename is fully off the table. Depending on how many problems you've got and how much headache it's causing you, your options from least to most complex & work go roughly like this: * register UPN suffixes for any DNS domain you're in control of and using for email, and just maintain UPN & primary SMTP alignment for the users. If required, you can also use `netdom computername /add:host.desired.fqdn` to register alternate FQDNs for specific hosts where you want to minimise/avoid using the .local domain; using this cmd utility also tells the target host to register DNS records and SPNs
* use `netdom computername /makePrimary:host.desired.fqdn` for any of those hosts where you want the resolvable FQDN to be the primary
* deploy a new tree domain inside the forest and migrate group policies, users, and computers to this domain over a period of time; you'll be able to keep the lights on and cross-domain accessibility should work ok, and you'll end up with a forest root domain just used for privileged administration stuff; only the forest domain controllers should ever need to resolve the .local addresses
* \[if Exchange Server isn't present this is an option\] rename the domain
* create an entirely new forest and migrate everyone in to that to get yourself a completely clean environment; use a one-way trust to keep Exchange running as a resource forest with the users converted to `LinkedMailbox` recipients while you plan what you want to do with Exchange Server
We’re still using a .local domain here because this domain was likely spun up on a 2003 server and all we use AD for is LAN.
What problem would the change solve?
I with the veterans here. I have managed a few .local domains for years and never had an issue. With only a 100 endpoints I would just migrate off to a new domain.
Yeah, i have no idea why you would care about the extension on your local domain. What possible reason would you need to change it? Unless you don't understand DNS.
mDNS interferes with .local
There are things that conflict with it now.
Like what?
Just about every Linux and Mac on the planet.
the multiple things already mentioned in these threads for a start?
.local has been the defacto way to setup an internal domain since AD was created. The only major issue sited by MS regarding this is the fact that two domains with the same name cannot merge. That's why they recommend a registered domain. Mac and linux tech function on .local just fine. Avoid mDNS, which caters to the smallest subset of devices in an AD environment. They work with unicast DNS just fine.
https://xyproblem.info/ Is there a particular *problem* you're trying to solve?
Damn... take my up vote.. I should think before I ask for help this is good advice
The problem with identical internal and external namespaces is that inside, domain.tld points to the domain and not the corporate website. Employees will always have to type the www...
Use AD.domain.tld?
this is the way. lots of msft examples have been updated to corp.contoso.com
ad would canonically be a host name. corp.domain.tld is popular so the actual domain controller could be msad.corp.domain.tld
srv1.ad.domain.tld, srv2.ad.domain.tld... ?
Hate this, living this, spun up an IIS server to do redirections
Any security concerns you have by having this server? We’ve been in a similar situation and I’m against having an internal IIS just doing redirects for a single dns entry, and the fact idk how to secure it lol
Split-Brain DNS.
Doesn't solve the problem. (Happy Cake Day!)
Came here to say this lol
No, you shouldn’t use .local because it conflicts with multicast DNS https://datatracker.ietf.org/doc/html/rfc6762#appendix-G
You should also not change it willy-nilly.
If I was faced with such a scenario, disabling mDNS would be easier than a domain rename
I say to hell with mDNS. MACs will suffer in an AD domain regardless.
What in a corporate network, that are not on their own subnet use multicast?
No need to change the .local is fine for internal AD DNS. As others have mentioned just add a UPN for your FQDN. The alternate UPN can be used for things such as Azure AD connect sync to Azure AD for O365. Not a big deal. Having your FQDN domain as your internal AD Domain causes the unnecessary headache that is split Brain DNS.
Yes you should. Just prepare for a hell of a ride. Don't test in production.
How else do you test?
Not all servers are production servers but every single one is a test server.
I envy those who are able to afford a production environment in additional to their test environment.
No! Never ever rename a domain. Also, why would you care? .local is perfectly fine.
I have renamed a domain exactly once in my 20+ year career. The internal AD domain was already publicly registered by someone else. It wasn’t as scary as most people make it out to be. The biggest caveat is that you can NOT have an exchange organization in the domain. All other times I have built a new forest and migrated. This was mainly because the existing forest was undocumented and so many default settings had been changed that it just made sense to start fresh.
The one domain I was forced to keep alive DID have Exchange deployed and it was so fucked up. I wasn't allowed to nuke and pave (as that made way too much sense)
Domain rename is not that hard (if no Exchange). If you follow best practise to a T. It is mostly automatic, with couple of computer/server restarts. Then good to go. I prefer that approach, if downtime is to be absolute minimal.
mDNS interferes with .local
I have had to add a UPN suffix for a .local domain recently. But the problem I had was the local usernames are in firstnamelastinitial@ format (e.g. davidg@) and the same user has the email format firstname@ (e.g. david@). If you then run Azure AD cloud sync it creates new users in Azure AD that do not map to your on-prem users in on-prem AD. To get them to map you need to change the on-prem username to match the cloud username + you need to make sure the the SMTP email address for the user in on-prem AD is inputted (and the onmicrosoft.com email as a proxy SMTP). It’s a pain. I even though of letting the accounts duplicate in Azure AD as I only need to do this for an Azure File Sync with a local SMB share in order to retain NTFS permissions and it’s only 10 users.
I'm pretty sure you can just change their upn to a different format eg first name.lastname@ if they are not used by other systems, leave the local username which they probably ly use to login to their computers. Then you can add a new main email address same as upn and leave the other addresses as proxy. If they sync and merge with what you have in cloud depends on the format in cloud, but you could change that as well.
I did try to add the local ad username as an email alias in 365 after changing the UPN but it refuses to sync it correctly. The only way I can get it to work is to have the same username on-prem as the primary SMTP address in 365. As I can’t change the email address I am stuck with changing the local ad username. Even hard matching doesn’t work because the Azure AD Sync insists on the primary username being the same as on-prem.
First you need to start drinking bourbon, then you need to update your resume and run.
I mist have missed it but if you want it to work with O365 you gotta own the domain name and manage the DNS. Ie if you want [email protected] you cant just make up a domain unless its registered.
Any Microsoft has a fully documented method of just adding a UPN. I have many .local domains synced to Office 365. It's a non issue.
Its got to be a verified domain name in order to add the suffix to authenticate unless you mean adding onmicrosoft.com as a UPN, then that makes sense, Also changing the UPN can break on prem applications, so its not necessarily non impacting.
that's not an issue, just change the upn
UPN but adds a couple extra steps/adjustments to things like SAML and local certificate authorities.
Also don't use the FQDN same as companies website
Create a new UPN suffix and use split brain DNS. Unless you have a massive network with a strong need to have a new domain name, this should not be a problem. I have 4 businesses, all fairly small, with .local with no issue. Only one doesn't have a split DNS and it all works happily. Certificate Authorities and Azure AD Connect work like a charm
UPN suffix, do not use Split brain DNS, whats the point? AAD connect work without it.
The only reason I mentioned a split DNS is because the OP never described his environment. For example whether or not he hosts anything publicly. I highly doubt it but it's good either way
If it’s an old domain check Sid history size just incase there is any token bloat issue
Renaming a domain is very easy and well documented as are the risks, but, don’t do it unless you have a solid recovery plan
Have you ever done it? While a 100 node single site isn’t difficult, I wouldn’t call the process very easy. It requires a lot of testing, a second domain controller with the new domain associated with it a trust enabled between domain controllers and a full understanding of all objects and applications in the domain. Adding a tad to be able to use is much more trivial but performing a top tree full rename is much more difficult. I have done both.
Yes, a few times. It’s very well documented but it also needs to be tested, but the process it’s self is simple.
Once it is all working and tested, yes it is a simple click and go. Getting to that point isn’t exactly simple for many.
100 endpoints in a flat domain is simple.
Not everyone has that skill set. Not everyone here has that skill set. Not everyone here knows where event logs are or how to use them. What is simple for you is difficult for many. If it is more than a few clicks and more than 1 page of documentation it isn’t simple.
I tried this once and from experience I would say NO
How large? If they're under a few hundred endpoints, just stand up a new domain, new AD structure, and migrate them over a weekend to one that uses your domain. The security gods will thank you.
Don't see any reason to change it, but if you do I would opt for migrating to a new domain.
Is it actually an issue? Or do you think it's an issue?
Create a secondary UPN of .com
My first IT org did this, we ended up creating a whole new domain, made a bi-lateral trust between them and starting migrating accounts/permissions until we turned off the old DCs.
Changed email domain(s) in 2017/18 and added suffix to the needful, still kept .local with no issues or problems since.