Está en la página 1de 29

Cinta adhesiva y palitos de helado

Los desafíos y observaciones únicos (y no tan únicos) de un profesional de TI.

MA RTES 27 DE NOV IEMB RE DE 2012 BUSCAR EN ESTE BLOG

Buscar
Por qué no debería usar .local en su nombre de dominio de
Active Directory. SUSCRÍBASE A ESTE BLOG

Esta publicación se actualizó el 14 de noviembre de 2013. Publicaciones

Hay una gran cantidad de dominios de Active Directory .local, .corp y .lan por muchas Comentarios
razones. A veces, no hay una manera fácil de cambiar esto debido a cosas como Exchange,
aplicaciones personalizadas que se integran estrechamente con AD, o simplemente la gran ACÓSAME
cantidad de pruebas que requiere un cambio de nombre de dominio. Puedo entender si entras
en una situación como esta que no creaste, pero por favor  nunca hagas esto en un nuevo @mdmarra
dominio. G+
Falla del servidor
La forma correcta de nombrar un dominio de Active Directory es crear un subdominio que sea Reanudar (PDF)
la delegación de un dominio principal que haya registrado y sobre el que tenga control. Como markmarra (at) gmail (punto)
ejemplo, si alguna vez comencé un negocio de consultoría y usé el sitio web de Internet com
mdmarra.com como el sitio de mi empresa, debería nombrar mi dominio de Active Directory
ad.mdmarra.com o internal.mdmarra.com, o algo similar. Desea evitar crear un TLD como ARCHIV O DE BLOG
.local y también evitar el dolor de cabeza de usar mdmarra.com para la zona de Internet y la
zona interna. ► 2015 (1)

► 2014 (5)

► 2013 (17)

Escucho muchas razones diferentes por las cuales las personas pueden querer usar .local,
▼ 2012 (10)

algunas un poco más locas que otras. Algunos pocos son: "Dado que .local no es un TLD válido,
► diciembre (1)

es más seguro ya que mi AD no puede ser atacado desde Internet".
▼ noviembre (2)

Por qué no deberías usar
.local en tu Active Direct
De hecho, escuché esto en un video de capacitación de certificación de Active ...
Directory hoy y me sorprendió. Es simplemente tonto. No debería exponer sus Comparación de las
controladores de dominio a Internet, punto. Deben estar detrás de un firewall en revisiones instaladas en
usi de Windows Server ...
el lado confiable de su LAN. Si los expones a Internet, tener un TLD inventado no
te ayudará mucho. Esta es una falsa sensación de seguridad que no tiene raíces en ► septiembre (2)

la realidad.
► junio (2)

"El Small Business Server usa de manera predeterminada un TLD .local durante el asistente de ► mayo (2)

configuración". ► febrero (1)

Confía en mí cuando digo que SBS no es un producto sobre el que quieras modelar ► 2011 (9)

tu organización. Está destinado a ser una solución lista para usar que puede ser
administrada por usuarios con un conocimiento mínimo de Active Directory o
Windows Server. Microsoft está apostando a que las personas que instalen SBS ya
no poseerán un dominio de Internet válido o no entenderán lo que significa usar
un nombre de dominio de tercer nivel. SBS también tiene Active Directory, SQL
Server, Exchange y SharePoint, todos en el mismo servidor. Como dije, no es algo
que desee modelar su entorno después.

"Quiero que mis usuarios vean Compañía \ Usuario como nombre de inicio de sesión. ¡No
quiero algo feo como AD \ User o Corp \ User!"

Estas dos cosas no están realmente relacionadas. Puede establecer el nombre


NetBIOS del dominio (la parte anterior a la barra diagonal inversa) a lo que desee
durante la creación del dominio. También puede configurar el UPN (@
whatever.domain.com) para cualquier cosa que desee también. Esto le permitirá
que su FQDN de AD sea algo así como internal.company.com, mientras que sus
usuarios iniciarán sesión con Company \ User o user@company.com. El FQDN del
dominio tiene poco que ver con el formato del nombre de inicio de sesión de un
Los gTLD son un desastre por muchas razones.

En mi trabajo anterior, teníamos dos bosques separados y ambos eran locales.


Tuve que hacer un cambio de nombre de dominio en uno para que terminara en
.edu y luego tuve que migrar 20k objetos del otro bosque al dominio recién
consolidado. Habla de una pesadilla.

frank_rizzo 4/08/2016 9:55 AM


¿Por qué, específicamente, "tuvo que" cambiar el nombre de Active Directory?
Hacer que su nombre de bosque AD coincida con su nombre de dominio público
no es "requerido" de forma remota, y parece un problema mínimo / inexistente
que "alguna otra organización" podría terminar comprando "yourdomain.local" y
causar problemas de DNS. Debería comprar cualquier nombre de dominio que esté
utilizando, si su TLD elegido de repente se hace público ... Estamos hablando de
<$ 20 por año aquí, personas.

Vs. Semanas de planificación y trabajo para cambiar el nombre de los bosques de


AD. Eso parece inútilmente derrochador con cero beneficios reales.

marca 4/08/2016 10:48 AM


mDNS en las versiones de OS X unidas a AD en ese momento no funcionaba bien
con los dominios .local AD. Se tomó la decisión de "arreglar" el bosque de AD para
evitar futuros problemas similares o imprevistos en lugar de cambiar la
configuración en cada Mac de la organización.

Respuesta

Anónimo 2/05/2013 10:57 AM


Hola, Mark, con respecto a su declaración: "también desea evitar el dolor de cabeza de usar
mdmarra.com para la zona de Internet y la zona interna". Puede hacer esto, siempre y
cuando agregue las entradas de zona para abordar el tráfico de Internet - ¿correcto? ¿Está
diciendo que usar el subdominio como ad.mdmarra.com es simplemente más simple y evita
tener que agregar estas zonas?
Respuesta

Respuestas

marca 2/05/2013 11:12 AM


Bueno, en primer lugar, los clientes internos no podrían acceder al sitio web
externo mdmarra.com. Tendrían que usar algo como www.mdmarra.com. Esto se
debe a que los Controladores de dominio para un dominio registran registros A
para sí mismos en la raíz de la zona en la que se encuentran. Esto significa que
internamente, habrá un registro A para mdmarra.com para cada DC que apunte a
DC. Obviamente, no alojará su sitio en los DC, por lo que deberá hacer algo
desordenado como instalar IIS en sus controladores de dominio para redireccionar
o enseñar a sus empleados que mdmarra.com no funciona desde adentro.

Para otros registros como mail.mdmarra.com o cualquier otra cosa como esa, sí,
solo necesita agregarlos dos veces.

Imagine una situación en la que tiene una infraestructura de DNS dividida como la
que estamos hablando. Ahora imagine que tiene un compañero que tiene la misma
configuración. Tienes un enlace de fibra privado entre ustedes dos. ¿Te imaginas
lo que habría que hacer para asegurarte de que solo el tráfico interno atraviese
ese enlace mientras que el tráfico destinado a atacar los sitios externos de tu
pareja salga por Internet? Se necesita un montón de trabajo innecesario para que
eso suceda.

Básicamente, no hay una razón convincente para usar un espacio de nombres


superpuesto. Claro, para algunas personas está bien, pero para otras no. No sabe
cómo va a crecer su empresa o con quién se asociará en el futuro. No hay
inconvenientes en usar un subdominio y hay muchas trampas al hacerlo de otra
manera.

Desconocido 06/04/2016 3:04 AM


There is a way to make the domain.com available for the internal users. Just
install IIS on all domain controllers and configure a redirect to www.domain.com.
usuario, aparte de elegir un valor predeterminado razonable durante la creación
del dominio. Puede cambiar este valor predeterminado si desea hacerlo más
bonito.

Si todavía no lo he decidido, debería leer Best Practice Active Directory Design para
administrar redes Windows  en TechNet. Es un documento de la era de Windows 2000, pero
esta mejor práctica no ha cambiado. El pasaje relevante es el siguiente (la negrita es mía
para enfatizar):

Como práctica recomendada, utilice nombres DNS registrados con una


autoridad de Internet en el espacio de nombres de Active Directory . Solo los
nombres registrados tienen la garantía de ser únicos a nivel mundial. Si otra
organización luego registra el mismo nombre de dominio DNS, o si su organización
se fusiona, adquiere o es adquirida por otra compañía que usa los mismos
nombres DNS, las dos infraestructuras nunca podrán interactuar entre sí. 

Agregue un prefijo que no esté actualmente en uso al nombre DNS registrado


para crear un nuevo nombre subordinado. Por ejemplo, si su nombre raíz DNS
era contoso.com, entonces debe crear un nombre de dominio raíz del bosque de
Active Directory como concorp.contoso.com, donde el espacio de nombres
concorp.contoso.com aún no está en uso en la red

Otra razón, aunque mucho más pequeña, es que mDNS, también conocido como Bonjour, usa
.local para identificar nodos en la subred local sin usar una búsqueda de DNS. Según Apple ,
esto solo debería ocurrir cuando hay una sola etiqueta frente a .local, como server1.local. Si
su AD se llama company.local, adivine qué, ese es un nombre único frente a un .local. No es
una buena situación. Sin duda existen soluciones para esto, pero he trabajado en entornos
mixtos con FQDN AD locales y adecuados, y es mucho menos doloroso cuando no está usando
.local.

Realmente hay cero Hay buenas razones para usar .local en una nueva instalación de Active
Directory y hay muchas razones para no hacerlo, así que facilítelo a usted y a sus sucesores y
planifique un poco el nombramiento de su dominio raíz del bosque.

Actualización: desde que se escribió esta publicación, ha habido un nuevo desarrollo


importante con TLD fabricados. El foro CA / Browser, que es un consorcio de proveedores de
navegadores web y CA públicas, ha publicado un documento titulado:   Nombres de servidores
internos y requisitos de dirección IP para SSL: Orientación sobre el desuso de nombres de
servidores internos y direcciones IP reservadas proporcionadas por CA / Foro del
navegador. Se puede encontrar aquí (advertencia: enlace directo a PDF).

Este documento establece que ningún proveedor de certificados importante emitirá un


certificado SSL para una dirección con un TLD inventado, como .local, .lan, .corp, etc. Esto
refleja las mejores prácticas que se han publicado durante años, pero ahora tiene
consecuencias tangibles reales asociadas a él.

Publicado por Marcos en Martes, 27 de noviembre 2012

Etiquetas: directorio activo , mejores prácticas , W indows Server

135 comentarios:

Anónimo 27/11/2012 5:58 PM


Solo cometí este error cuando ayudé a configurar el primer entorno de AD en mi entonces
trabajo. El proyecto de implementación de AD se ejecutó entre 2001 y 2003, y una de las
decisiones fue cómo nombrar los dominios. Empujó y obtuvo un "TLD que nunca se usará".
Siendo uno de los miembros junior de ese equipo, lo vi como una victoria personal. Ejem.

En mi defensa, no había tanta literatura sobre la selección de dominios en ese entonces, y


la explosión de TLD que ICANN estaba haciendo ni siquiera estaba en el horizonte. Ese gTLD
en particular ahora ha sido solicitado por tres entidades diferentes, así que ... las malas
ideas pueden surgir y golpearte una década más tarde.
Respuesta

Respuestas

marca 28/11/2012 9:51 a.m.


Works like a charm :)

Unknown 4/15/2016 12:34 PM


Sounds like a bad workaround...

Unknown 4/17/2016 3:54 AM


Got any better ideas?

Unknown 9/07/2016 8:41 AM


You can do a port proxy on the domain controllers for port 80. This does not
require IIS.
http://blogs.catapultsystems.com/chsimmons/archive/2015/04/08/domain-
controller-http-redirect/

Reply

Anonymous 3/15/2013 5:17 PM


Mark,

I work for a CA SSL provider and are running into trouble helping our clients get past the
.local/internal name issue. We are required to limit their certs to a two-year term even
though they want longer. I cannot find any relevant articles let alone walk-through's to
reconfigure the exchange environment to not use .local's. For example when they go thru
the CSR generation process and pick the services to enable, it automatically wants to
generate a SAN for domain.local or just the server name.

Can you provide insight to this problem? Thanks from all of us.
Reply

Replies

Mark 3/15/2013 5:23 PM


There's no easy way for them to get off of .local. They'll need to migrate to a
whole new AD domain. This is why it's critical to get the name of your AD correct
during implementation, since it's months or even years worth of intense
preparation to migrate to a new domain.

Unfortunately, Exchange 2007 and 2010 don't support a domain rename like
Exchange 2003 did. Once you have exchange in a domain, it can no longer be
renamed and requires an entire migration to a whole new domain.

Anonymous 3/19/2014 1:53 PM


They can just use a internal CA.

Jasper 10/08/2014 2:47 AM


There is a walktrough for exchange 2007 and above to change the behaviour of
exchange: https://www.digicert.com/ssl-support/redirect-internal-exchange-san-
names.htm

Anonymous 10/25/2014 2:28 PM


Hi Mark,

Is it supported by exchange 2003 SP1 only or can also be done regardless the SP
installed in the organization (sp1 sp2)

Reply

Unknown 4/12/2013 12:39 PM


Mark -
We are running into what you've mentioned. A consultant named our (very small) domain
the same as our external facing website. Now when people are on-site and try to go to
domain.edu, they get sent to the DC and and not to the website. I had originally planned on
going to domain.local, but then I found your site. I'm definitely not an AD expert...so, can
we just rename our domain to ad.domain.edu with the domain rename tool? Or is it much
more heavily involved? Users don't authenticate or really interact with this domain. It was
simply setup in order to utilize DFS for some web servers.
Reply

Replies

Mark 4/12/2013 12:58 PM


You can rename it from domain.edu to ad.domain.edu with the domain rename
tool, just make sure that you read, test, and fully understand the documentation
and limitations (like you can't rename a domain with Exchange 2007+ in it.)

Reply

Anonymous 4/16/2013 4:37 PM


we have a domain currently with no TLD whatsoever, so if you name your company xyz, the
name of our AD domain is simply xyz.
I am thinking about renaming it according to what you have suggested here but I do have a
exchange 2003 server running as well. According to Microsoft I can't do rename of the
netbios domain name with any version of Exchange. Am I understanding this wrong or does
it really mean I can't do a rename at all? Or does it mean that I won't be able to change the
netbios name of the domain but I will be able to rename it to xyz.xyzpublic.com?
Reply

Replies

Mark 4/16/2013 4:52 PM


Ouch, a single-label domain name. I actually don't know the caveats of changing
that since it's so rare. You *should* be able to just do a rename and change only
the FQDN, but a domain migration using ADMT might be just as easy depending on
your size. It really depends.

Make sure you read the documentation for either path carefully and check for
caveats regarding single-label domains.

Reply

Martin Grotegut 4/18/2013 8:01 AM


I strongly second you, Mark!

AD domain names ending with ".local" are a nuisance.

I like to add that ISO Standard 3166 reserves the country codes codes AA, QM-QZ, XA-XZ,
and ZZ as user-defined codes. These will never be used in the public Internet!

So it is feasible to use e.g. 'company.xa' as AD name space.

Reply

Replies

Mark 4/18/2013 8:13 AM


That's interesting. Are organizations able to register them to guarantee that they
are unique? If not, they should still be avoided. If I'm example.xa and you're
example.xa, we can never have a trust between us or resolve each others internal
namespace for collaborative purposes.

Reply

Avi 4/25/2013 12:43 PM


Hi Mark and and everyone who is participating in this very excellent discussion--Hat's off to
you Mark for this exemplary post. I currently inherited an AD environment (company.com
with an externally hosted website company.com--and yes dns was and is a pain) with one
sever running under windows 2003 r2, and is running AD/DNS services at a windows 2000
functional level. It is also running exchange server 2003 sp2. I am charged with migrating this
whole thing to several new servers that will have 2008 r2. My plan is to have one server
running ADDS and one server running exchange 2010. If I rebuild my AD from the ground up
on these new servers, can I name my new domain, company.com like the old system was
without worrying about users having access to their mailboxes--i.e. will the new system
create new SIDs that will prevent me from importing/migrating our mail store into the new
exchange? I want to hear what peoples' opinions are on this, or any recommended
strategies. Has anyone had an experience like this before?
Reply

Replies

Mark 4/30/2013 6:16 AM


First of all, why are you starting a new AD? Why not just add new DCs to what you
have?

Secondly, you should always have more than one DC. Always.

Finally, if you do actually need to stand up a new infrastructure for some reason,
you'll need to create a trust (which you can't do if the domains have the same
name) in order to move the mailboxes. Users won't have the same SID in each
domain anyway, since the domain SID is derived from the SID of the first DC in the
domain, which will be unique.

Hope that helps.

Reply

Anonymous 5/03/2013 7:21 AM


Interesting discussion. I have a question regarding isolated networks. If you know for
certain that your domain will never be connected to internet, is it still feasible to use .com
vs. .local?
Reply

Replies

Mark 5/03/2013 9:02 AM


I don't see what you would gain from .local in that situation. Can you explain why
you think it would be better?

frank_rizzo 4/08/2016 10:06 AM


If you're not ever going to connect to the Internet all of these rules are totally
moot, because you're probably on a classified or sensitive network so it totally
doesn't matter. Government networks that run this way usually have access to
issue "official" certificates via a delegation from a well-known CA.

This is a program available to any enterprise that can afford it through most of the
"Big boys" of the CA universe, and well worth the money if you want everything
to run encrypted and certified via "well-known CA" certificates.

Reply

tShabbir 5/03/2013 11:22 AM


Hi Mark !
After reading your article I am making my mind to create move for domain.com
Previously we had several domain.com web and application services and locally we have
domain.local. Now as a pilot project we are working on domain2.local with the same
domain.com externally .But I am facing lots of certificate and SSO issues on implementing
2012 RDS deployment.
I am thinking to replace this domain2.local with domain.com , Please help on these

1: should I go for domain.com or abc.domain.com


2: If we go for abc.domain.com , what advantages we can get on domain.local
3: If move with abc.domain.com , my domain.com certificates will still work ?

Please guide me , I will be thankful .


Reply

Replies

Mark 5/03/2013 4:47 PM


1. abc.domain.com

2. This whole article is about why you shouldn't use .local. Is there a specific point
you'd like clarified?

3. Sure. Why wouldn't they?

Reply

Anonymous 5/08/2013 4:44 PM


Mark,
Thanks for a great article. Our very small company leases a dedicated remote web server
from Hostgator. Initially it was intended for hosting .NET web applications via the internet.
We also sell or rather "rent" a massive desktop applications written in VB6 (no flame please
... we are talking about a large vertical industry application that has grown and evolved over
12 years... our newer apps are written in .NET).

The "web" server was originally provisioned with Plesk control panel and no AD Domain.
Some of our customers asked about a "cloud" version of our
VB6 app. So I installed RDS 2008 on the Windows 2008 R2 server and it worked like a dream.
Until I wanted to add another "cloud" customer that needed to see a distinct version of our
application in RDweb. I found that I could not accomplish that scenario without full blown
AD.

The server also serves as a registered name server. I was not sure how I could promote the
server to DC, as it is and will always be the only domain member (we have our own local AD
domain at our office location with members).

Now I will use a subdomain naming scheme when I elevate the server. You corporate guys
will say "buy another server". We employees had to take a 20% pay cut as it is with the bad
economy...so don't even mention that.

Thanks again for the article.


Reply

Anonymous 5/09/2013 1:47 AM


Hello Mr. Marra,
I have a few questions regarding the installation of server 2008R2 Enterprise as it will
ultimately relate to an exchange 2013 installation. I am in a 2013 Exchange class which is why
part of these questions are relevant. 1. I have a domain which I will be using for the
exchange services. I am limited at this time to only 1 server, if you will and will need to run
all the required components on the same box; AD DC IIS Exchange, etc. I realize that the
namespace; i.e. domain name is critical for correct operation or at least I think that it is. #2.
I have played with the idea of giving the computer name, mail so when resolution will
eventuaqlly occur it will look like mail.mydomain.com. Interestingly enough when all is said
and done it will look more like mail.mail.domain.com. My box is behind a router/firewall and
it is certainly not the best level of security but this is just an exercise for my class. There
will be no data on this box. I will be using the outlook anywere process (web - owa only) so I
do not think security will be an issue. So.....if I have my host point the mx records to my
box without opening up the DNS or creating Name Server alias' will it really matter about the
netbois and computer name being the same? Sorry for the long post but I am in a crunch
with this class and really need any asistance possible. No one else has got this working so I
want to get a heads up...
Thank you in advance.

Respectfully,
Daniel W
Reply

Replies

Mark 5/09/2013 8:33 AM


Your internal presence (the AD name and the server's hostname) have nothing to
do with your external web presence, which could be something like
mail.example.com. This is why you use UCC certificates with multiple SANs with
Exchange. It allows you to secure both the internal naming and public naming of
the server.

Even in this scenario, there's no reason to have your internal AD name overlap
with your external name. It's a hard concept to grasp if you're new to DNS.

Reply

young_teknivor 5/09/2013 9:58 PM


Hi Mark,
Hi Everybody,
First, thanks for this great article and discussion.
I am handling a project migrating an Exchange 2010 Server1 from the Active Directory
domain mycompany.local to another Exchange Server 2010 on the new Active Directory
domain mycompany.com
I know that to be able to migrate a exchange database to another server, the exchange
organization name should be exactly same but what about the Active Directory domain
name ?
Thanks for sharing your practices.
Reply

Anonymous 2/06/2014 10:34 AM


I just want to point out that you are wrong according to SANS, and they are cooler than
you!
http://www.sans.org/reading-room/whitepapers/win2k/basic-security-issues-active-
directory-191
(page 6)
"If your organization has a presence on the Internet, the name of your forest root domain
should be registered. An example would be the SANS Institute, which would use sans.com
as a DNS namespace for the Internet, and sans.com would be the namespace for their
Active Directory forest root domain"
Reply

Replies

Mark 2/06/2014 4:30 PM


SANS can be (and in this case, is) wrong!

Reply

@bhitalks 2/13/2014 7:18 AM


Hi Mark,

First of all, thanks for such a great article. I was looking for alternate UPN suffixes when I
found this article.

I inherited an 8 year old AD with internal name as "company.co" and external domain as
"company.org". This month we migrated to Office 365 and got rid of on-premise Exchange
2003. This migration required me to add an alternate UPN suffix so that DirSync could map
the users to the cloud AD. So far, so good. Users can log on as "user@company.org" internally
as well as on O365.

Now, the problem was that our internal application servers (in fact all servers) are still
named as "server.company.co". So, internally the users on LAN have to access
"http://server.company.co" to use the app. But, when coming from outside, they need to
access "http://server.company.org" to use the same app (I did an 'A' record on "server"
subdomain on my external "company.org" domain DNS records to point to the static public IP
on that server).

I was wondering how could I get rid of this situation as well? That is how I landed on this
article while searching.

May I seek your expert insight/guidance, which could point me in the right direction.

Should I rename the internal domain? (No on-premise Exchange servers). But, then will the
user and computer SIDs change? Will the current user-profile on client computers stop
working? What are the pitfalls?
If I rename the internal domain to say "internal.company.org", then how would I map
internal access to apps to "http://server.company.org" instead of
"http://server.internal.company.org"?

Apologies for my limited understanding of AD/DNS internals.

Thanks / @bhi
Reply

Replies

Mark 2/13/2014 7:27 PM


You can approach this one of two ways - neither rely on you changing your
internal namespace despite it being "incorrect"

1. Configure your network so that internal users can access servers by the
external name. If you have something like an ASA and are using the internal and
external zone interfaces, you'll have to configure NAT hairpinning.

2. Create a copy of your company.com zone on your internal DNS servers and
replace their public IP addresses with their internal ones.

@bhitalks 3/04/2014 10:59 AM


Thanks a lot Mark for taking time out to help me out. Much appreciated.

I did try the second option suggested by you earlier, but perhaps due to my
inadequate knowledge, I couldn't make it work.

However, option #1 did it for me! We used to have ASA in HA mode earlier, but
was de-commissioned long back. Cost-cutting measures by organization :( Got
replaced by much cheaper local UTM devices. Surprisingly, these boxes supported
mapping of internal name to external one in the NAT config area.

Works great now. Thank you so much again for pointing me in the right direction.

Thanks / @bhi

Reply

Anonymous 2/17/2014 7:20 PM


Great Article!
From a .local domain created back in 2000 I would go now for dc.company.com or similar.

Can I suggest an article for domain users profiles: local profiles vs roaming vs redirected.?

I prefer redirected profiles, including AppData folder ( I know that so many apps do not
understand that but...still good) so what would you recommend with W2012R2?
Reply

Anonymous 2/25/2014 4:02 AM


I have some counter points. Lookup DNS devolution, I have had this bite my users in the
past, especially with the wpad bug, that tricky person who registered wpad.com.au had a
field day.

I would also suggest you have a look at your firewall when you have some users out and
about, and see the occasional 88, 389 and 135 hit from that users public IP, so possible plain
text credentials of users going over the public internet or a hash you can use, perfect for a
bad guy to MITM.

My counter to your trust issue, would be to think about your domain name and ensure it is
likely unique; how likely is it that usa.contoso is going to be used by a competitor contoso
just bought out, and how likely is it that the contoso TLD gets registered.
Reply

Replies

Mark 2/25/2014 7:10 AM


Strongly disagree here. Neither NTLM not Kerberos send anything in plaintext and
they also do not transmit the password hashes. They send a *verifier* that's been
salted and hashed one way.

Also, if you've got DNS devolution problems like you've said, you've mis configured
something somewhere. I also don't understand the point you're trying to make in
your last paragraph.

Mark 2/25/2014 7:12 AM


Just to be clear - verifier or not - if you've got logon/auth traversing the public
internet, you've configured something wrong. I was just pointing out that your
specific point is flawed, but flawed or not, it should not factor into a properly
configured infrastructure at all.

Reply

Anonymous 2/25/2014 7:15 PM


I know how NTLM and Kerberos work, however if the NTLM hash is captured over the wire it
can then be passed using "pass the hash" to authenticate as that user or the Kerberos
packet brute forced to discover the NTLM hash then passed. The NTLM hash can also be
thrown at an NTLM rainbow table handy to discover the users plaintext password. You don't
even need to be in the middle to do this, just on the same broadcast network say a coffee
shop wifi. There are torrents of the NTLM rainbow tables too.

DNS devolution problems are also pretty widespread, the WPAD bug I am talking about has
reared its ugly head at least twice in my career (1999 and 2007);
http://technet.microsoft.com/en-us/security/advisory/971888
But DNS devolution does happen on machines, and a big enough network 10,000+ nodes you
will see a few a day, adding to the noise, surely it is better to keep them from being able to
devolve to wpad.domain.tld or wpad.tld as has been the case before. Who is to say there
isn't another vulnerability of this ilk coming. I know microsoft have given us the ability to
turn off devolution, but it hasn't always been there.

My point on auth traversing a public internet is still a valid one, lets say you set your
internal domain to ad.contoso.com, and www.contoso.com and contoso.com are your
public facing website, someone takes a laptop home and during the usual login process it
attempts to resolved ad.contoso.com, obviously if you have proper split DNS it won't, unless
for some reason you have created the subdomain ad.contoso.com or it does devolve to just
contoso.com, then your auth will route to your public ip for your website. It can happen.

My last paragraph is addressing seemingly your only point of contention for why you
shouldn't use a non-registerable domain. You say in case you need to setup a trust. I can see
this, I had a client many years ago who's previous admin had set the domain as corp.local,
they bought another business that just happened to have the domain corp.local...
fortunately the other business only had a hundred or so users, but it still meant nuking their
domain, no nice easy trust to migrate things. My point is, if you think about your domain a
little more and pick one that is unlikely to be used by anyone else this problem is mitigated.
If you pick USA.contoso it is not likely that contoso will be put into the new TLD's that are
coming out, and unlikely that you buy a company that has the same AD domain in use in
their organisation.
Reply

Replies

Mark 2/26/2014 12:07 PM


I think that we are going to have to agree to disagree here. All of the things that
you mentioned can be mitigated with proper configuration. Not doing something
because there was once a bug that impacted it isn't something that I take into
consideration. There have been vulnerabilities and bugs in almost every part of
every OS at one time or another. To pick and choose which ones you care about
when making these decisions doesn't make sense to me. But, of course, I value
feedback and you're certainly entitled to your own opinion. I've cited sources
published directly from Microsoft that are clear on this issue. Deviate at your own
risk.

Reply

Unknown 3/13/2014 4:50 AM


Hi Mark!

I have a situation here and i would like our advise. I inherited an infrastructure in which the
domain is named abc.local. There are others sites and all are on abc.local domain. We have 3
writable DCs and 3 RODCs. We dont use exchange but Google Apps. We also have another
domain in the same company seperated as a Headquarter and on HQ.local. My compnay
operates a Hub and Spoke network topology for the abc.local domain. Now based on
business needs i am saddled with the task changing the HQ.local domain to abc.local or
establish a trust between the 2 separate domains.
Reply

Replies

Mark 3/13/2014 2:28 PM


I think you forgot to ask your question :)

Reply

Unknown 3/14/2014 9:28 AM


I'm sorry Mark. I actually want to know the best way to go about this. Or would it be safer to
do decommission existing domain name and do a clean install of an additional DC then
deploy to the site?
Reply

Replies

Mark 3/15/2014 7:19 AM


The easiest thing to do is just create a trust. That will take about 5 minutes of
your time, whereas doing a domain migration will take significantly longer and has
a much more visible impact to operations.

Reply

Unknown 3/16/2014 6:47 AM


I think i forgot to tell you that i have tried doing a trust but it was not successful. Do i have
to get all DCs in abc.local to talk to the HQ.local server before the trust is successful?

We have 3 DCs and 3 RODCs in abc.local domain.


Reply

Replies

Mark 3/16/2014 3:47 PM


Yes. You need DNS resolution between the two environments. The documentation
for this is very thorough on TechNet. I'd recommend you look it up and read it if
you haven't yet. It is very explicit.

Reply

Unknown 3/17/2014 3:50 AM


Do i need the 3 RODCs too. The last time i tried doing the trust thing i could not get a
forest trust in my options.I only had Realm trust and windows domain options.However, two
of the Writable domain controllers in abc.local are already talking to HQ.local. Will the trust
still be successful if we are able to get the 3rd DC in abc.local to talk to the HQ.local server?
Reply

JBERG 3/31/2014 3:12 PM


Hi Mark,

First off, thank you for also stating that it's a bad idea to use a TLD for your internal domain
as well as your internet facing TLD. Also, this is something i've seen and even from my
Microsoft Certification i recall adding a .local is preferred as opposed to a .com, .org, .net,
anything that could be registered publicly. However, i'm curious because a .local does seem
to add that additional security by not allowing the internal domain to be published publicly
AND authentication to any resource outside (by VPN or application) would require that
.local or .whatever (if you're using SPN)... but most would probably force the user to use
the NetBios XXX/username for authentication.

Now, like you said all this can be avoided and secured with proper implementation, i get
that.. it also seems to me the argument here pertains to only scenarios when multiple
domains (internal) have the same name because you can't trust contosso.local with
contosso.local... and i can see that being a nightmare with administrating a migration. I'm
curious on your thoughts of security that it might add or take away...

For instance, if i register contosso.org, and i name my internal domain ad.contosso.org,


even though the TLD is unique, contosso.org is registered publicly. Does that pose any
threat because i have that part in my internal domain name as well?

Also what about a scenario where public domains don't match with internal domain names?
And i'm not talking about contosso.com to contosso.local... what if i have my internal
domain called by a totally different domain name? For example, my internal domain is
JDOE.COM, but my external site is registered as JOHNDOE.COM. Is this still the same issue
here as the .local even if JDOE.COM could be registered publicly?
Reply

Replies

Mark 3/31/2014 6:05 PM


> However, i'm curious because a .local does seem to add that additional security
by not allowing the internal domain to be published publicly

It doesn't add any security. You have to actively try and expose your AD's DNS
zones to the internet.

> AND authentication to any resource outside (by VPN or application) would
require that .local or .whatever (if you're using SPN)... but most would probably
force the user to use the NetBios XXX/username for authentication.

Not sure what you mean by SPN here, SPNs are related to Kerberos auth and have
little to do with AD domain naming. Also, relying on NetBIOS for name resolution
is bad news.

> it also seems to me the argument here pertains to only scenarios when multiple
domains (internal) have the same name because you can't trust contosso.local
with contosso.local.

Not just internal, it's quite common for companies that are partners to have
private connectivity with a trust between them. This applies to that situation as
well.

> and i can see that being a nightmare with administrating a migration. I'm curious
on your thoughts of security that it might add or take away...

Again, using .local or any other made up TLD has nothing to do with security. At
all. Ever.

> For instance, if i register contosso.org, and i name my internal domain


ad.contosso.org, even though the TLD is unique, contosso.org is registered
publicly. Does that pose any threat because i have that part in my internal domain
name as well?

No. Only if you go out of your way to misconfigure your DNS.

>
Also what about a scenario where public domains don't match with internal
domain names? And i'm not talking about contosso.com to contosso.local... what
if i have my internal domain called by a totally different domain name? For
example, my internal domain is JDOE.COM, but my external site is registered as
JOHNDOE.COM. Is this still the same issue here as the .local even if JDOE.COM
could be registered publicly?

If you do this, you should register jdoe.com. It's common for a company to be
example.com publicly and example.net for their internal AD network. This is fine
as well, same idea roughly. Just make sure you register the domain name you use
internally.

Mark 3/31/2014 6:07 PM


I also think you're misunderstanding that TLD means. A TLD is strictly the top-level
domain (org, com, net).

JBERG 4/04/2014 12:58 PM


Err... i didn't mean SPNs, i meant UPNs: User Principal Names. Instead of
authenticating by domain\username you're authenticating with
username@domain.com (or username@domain.local according to my question).
But you pretty much answered my question regarding security to a resource thats
accessible from the outside that authenticates through AD. I see that it wouldn't
matter if it's a .com or a .local. Even though most applications will automatically
apply the UPN for authentication or NETBios name to the user account when
authenticating. Thanks.

Reply

Unknown 4/15/2014 6:15 PM


so let’s say we call our domain ad.company.com. our internal servers would then be
server1.ad.company.com, server2.ad.company.com etc? and we would create similar entries
on our external DNS, so users can always enter the same URL to get to the same site
regardless of whether they were internal or external… but what about wildcard SSLs? They
only work for one level of subdomain… so right now we are able to use a wildcard SSL to
cover server1.company.com and server2.company.com etc. Wouldn’t naming our domain
ad.company.com prevent us from being able to use wildcard certs for our internal URLs?
(unless we keep internal DNS records for company.com but then we are back to split
domain, which was what we were trying to avoid in the first place?)
Reply

Replies

Mark 4/15/2014 6:20 PM


You don't want to create an "ad" zone on your public DNS. You can configure your
network to not have hairpinning issues so that internal clients can access public-
facing resources on their public IP. Then you don't need split DNS. If you can't do
this, split-DNS is the lesser of two evils here.

Reply

Anonymous 4/17/2014 10:37 AM


Hi Mark,
very, very interesting articles.
May I ask you a question about my situation at a customer?
I'll try to explain:
The official external domain is company.at, mail-gw in DMZ is mail.company.at.
The internal domain is also company.at, the Netbios-name is company (same as real name of
the company).
I have two locations, on each a domain-controller (W2K8 R2), FQDN of the Servers are
location1.company.at and location2.company.at. Both sides are connected through VPN
(site-to-site). All users authenticate the same way on both sites.
The internal Exchange-Server is a W2K3-server with Exchange 2003.
All users in AD identify through netbios-name "company\user1" (on both sites)
Now I have the situation, that the company changed the name to newcompanyname.
What users there ask me:
Is it possible to change the names (AD, Netbios) from company.at (AD) and company
(Netbios) to newcompanyname.at (AD) and newcompany (Netbios)?
The external newcompanyname.at is already set up and works with additional address-space
in Exchange (additional default-mailaddresses user1@newcompanyname.at).
Actually I didn't set up anything in AD or DNS with "newcompanyname.at or
newcompanyname".
At location1 (Headquarter, Financing, Sales) I have app. 30 client-pc's (and 6 Servers, one of
them the W2K3-Exchange 2003, another SQL2005 on W2K8 R2), at location2 (production,
stock, ...) I have app. 50 client-pc's (and 7 servers, one of them W2K3-Terminalserver,
another also SQL2005 on W2K8 R2). I don't want to think about lot of work on setting up
newcompanyname.at parallel to existing and moving users/pc's/servers to the new
AD-/Netbios-Domainname. Is there a way to Change ?
Thanks in advance for your appreciated advice.

Greetings from Austria,


Andy
Reply

Anonymous 5/29/2014 12:57 AM


I see your point.. but...

Biggest problem I see when naming your internal domain the same as your public domain, is
that your public domain name can change much easier and more often. This can leave you in
a pinch down the road when your internal domain name is not relevant (or worse, hated).

For example: I register a public domain fruitcakes.com. I decide to name my new AD


ad.fruitcakes.com. Sometime later my company restructures and we don't sell fruitcakes any
more. Now we sell hammers, and we hate fruitcakes. So we register hammers.com. But my
internal domain space is fruitcakes.com .. and will be forever unless I migrate to a new AD.
No easy fix there.

However, if my internal domain name was corp.local, my CEO wouldn't harass me every day
in the hallway about having that old name pop up from time to time. He really hates
fruitcakes now.

Another unpleasantry would be if the public domain name was very long. Like:
fortheloveofgiganticfruitcakeswithnuts.com.
fc.local sure is easier to those managing AD.

Or what if my company name doesn't have anything do with my public domain name. If I
register the domain freefruitcakes.com as the face of my company, but my company name is
Microsoft, that doesn't make much sense.

Or what if I'm a cloud services provider in multi-tenant situation. I have multiple companies
managed under the same domain or multiple domains. Using a public name would not be
possible.

Or what if I own multiple public domain names. Which should I choose? Whatever I choose, I
would have to keep renewing forever even if I hate the name now to make sure some other
company doesn't snatch it up and name their AD the same as mine.

As for the internal server SSL problem, you can usually use an internal CA.

Finally, the odds are probably very low that your company merges with another company
that uses the same internal AD name. Especially if both companies use their public domain
name but just replace .com, .net, or whatever with .local. In fact, it would literally have to
be two companies that own the same public name, but one owns .com and the other owns
.net. Very rare.

Oh. And nothing prevents me from naming my AD the same as yours, despite your best
efforts to be unique.
Reply

Replies

Anonymous 4/14/2015 1:54 AM


Mark, care to respond to this post? This is a very valid reason. We are now in a
situation where our domain name does not represent our business.
We are being harassed about it.
Therefor with our new domain name we want to choose something universal. So
if the organization name would change in the future we have no issues there.

We host all our services within our own domain (have our own CA as well), so
what exactly would be my benefit of choosing a public domain name?

Besides not going to get a SSL certificate and maybe some bonjour issues I'm not
reading that many strong arguments.

Anonymous 7/07/2015 12:33 PM


I think this falls under another best practice that states you don't name your
domain after a product line. Your domain name should be well thought out and
something that will age well. If you name your domain fruitcake.com, then well...
you pretty much deserve to be harassed daily by the CEO. Better yet, you
deserved to be fired. Your domain name doesn't need to be the same as your
public web names. The only thing recommendation I see being made is that you
also register your domain name so that it's guaranteed to be unique.
Reply

Anonymous 6/24/2014 10:19 PM


First Many thanks for clarifying lot of concepts with DNS.
One question if I may ask. which you probably answered but will like to clarify as currently
doing it in prod environment...
Existing - Scenario : SMB Location with Windows 2003 Server AD/DC - DNS is messed up.
Current DNS setting on the windows 2003 server is DNS Server IP address of ISP. User
workstation have ISP DNS too ..
Planned work going on : Building Windows 2012 r2 . AD / DNS.. Point user to IP address of
the Win 2012 r2 server. Have root hints enabled by adding ISP IP addresses.

Question : when building AD DNS win2012 r2 you get prompted to create NEW FOREST then
fill in Root domain name : can this root domain be named as i.e AD.company.com,
Internal.company.com - where company.com is real registered domain name with website
running as company.com and then do the AD NETBIOS name as i.e " ABCD " so when user
logon it will be ABCD\username .. Am I on the right track here..

Your help to answer this and if I am doing this right is greatly appreciated. Regards ..
Reply

Anonymous 6/26/2014 5:10 PM


So if I have an internet domain called (for example) happyservice.com and an internal
domain called happy.local, am I better off renaming my intranet domain to
internal.happyservice.com or is it just as well to use happy.com? I like the subdomain idea,
seems it would be better when you set up your UCC certificate, but
internal.happyservice.com is a lot more to type into a username
(internal.happyservice\username) than happy\username. Does it make any difference? Thx!
Reply

Anonymous 7/08/2014 11:00 AM


Hello Mark,

thans for this article.

I'm going to install a new AD. abc.de is registered and has a website hosted. I'd go for
ad.abc.de now. Will there be any trouble if the domain provider resolves all subdomains
(even them which do not exist) to the IP of the webserver? There is no Exchange, nor any
services which need to be accessed from outside.

Thanks in advance and sorry for my maybe crappy english ;)

Greetings from Germany.

Alfred
Reply

Replies

Mark 7/08/2014 11:04 AM


Nope. No problem with that! Good luck!

Anonymous 7/08/2014 11:08 AM


Thank you so much for this super-fast response!

-Alfred

Anonymous 7/11/2014 8:13 AM


Hello again,

I'm currently testing what I wrote at 7/08/14.


I got myself "alfred.de" (as example ;)) registered and my AD's name is
"ad.alfred.de". I'm using 2012 R2.

In DNS I got a forwarding to my local ADSL router.


When I now do a nslookup on "Google.de" I always get the response:

Name: Google.de.ad.alfred.de
Adresse:

Why is that and how can I turn it off?


Thanks in advance! Still learning, so sorry for stupid questions.

Unknown 8/21/2016 2:18 PM


Hello @anonymous.
Regarding your post on 7/11/2014, how did u configured ur forwading?

Reply

Anonymous 7/15/2014 12:21 AM


Interesting that nobody said anything about that on February 20, 2013, .local is officially has
been approved... http://en.wikipedia.org/wiki/.local

You are all talking about 6-8 year old standards here....

I think .local could be used now with no problem!


Reply

Replies

Mark 7/17/2014 9:48 PM


Did you bother to read the article that you linked to? .local is reserved for use in
multicast DNS. That's even more of a reason NOT to use it.

Reply

Anonymous 7/17/2014 1:48 PM


Hello,

You wouldn't happen to have a guide (or know of a guide) to setup a new domain using
server 2012r2 with a subdomain of a registered TLD do you? All that I've been able to find are
guides explaining either adding server 2012r2 to existing domains, or setting up a new
domain using domain.local (etc).

Thanks,
Dustin
Reply

Replies

Mark 7/17/2014 9:49 PM


I posted a video on this very blog about how to do just that.

Reply

Anonymous 7/26/2014 12:08 PM


Thank you. Nice article.
Just 1 question.
If I install new domain aaa.contoso.com I should select option "root domain in new forest".

So aaa.contoso.com has nothing to do with my contoso.com registered with Godaddy.


Contoso.com is not a parent for aaa.contoso.com.

Correct?

Thank you.
Reply

Replies
Mark 7/26/2014 12:23 PM
Correct

Reply

Anonymous 7/30/2014 3:59 PM


I just recently inherited an environment with this exact .local ad domain issue. I am working
on changing it but as you know it is quite a project.

In the mean time I am attempting to set up an additional mail server on a different domain
on the same lan. The problem I am encountering is that when a message is sent from my
new mail server to user@company.net it is unable to see it because the domain is
company.local. This is causing the message to come in over our public address. How can I set
up the local DNS server on company.local to recognize company.net look-ups and forward
them to its mail server keeping everything internal...

I apologize if what I am saying is unclear. It is a little difficult for me to explain. I appreciate


any insight you can provide.
Reply

OMA 8/04/2014 6:45 AM


There's one problem. Microsoft also says you shouldn't have a domain name of more than 15
characters, for whatever reason. That's an stupid constraint, since there are LOTS of domain
names with more than 15 characters including the ".com" (that's just 11 characters worth of
domain name, ridiculous!) so if I should use a real domain name and mine is longer than 11
characters (plus the dot com), what do I do then? Don't tell me I have to register a short
domain name just for this!
Reply

Replies

Mark 8/17/2014 1:34 PM


You're getting confused with two different things. The domain's NETBIOS name
cannot exceed 15 characters. The DNS FQDN of the domain is constrained only by
the character limit of DNS itself.

Reply

AeroBatGeek 8/07/2014 3:13 PM


I just found an updated Technet Article that is more current than the 2000 article you
referenced above.
See http://social.technet.microsoft.com/wiki/contents/articles/17974.active-directory-
domain-naming-considerations.aspx
It says that you need to have a registered domain name in order to interact with Azure.
It also EXPLICITLY says not to use .local, .example, .test, among others since these are all
actually "IANA Special-Use Domain name" reserved names.
Reply

Anonymous 9/06/2014 5:11 PM


Dear Mark,

I'm working with a customer to implement a complete new domain. The website is hosted
externally and the domain is abc.com.ar. My idea is to name the domain as ad.abc.com.ar .
Could you please confirm me if that is a good choice ?

Many Thanks !!
Best Regards
Franco A Nicosia
Reply

tommy 9/07/2014 11:42 PM


Mark,
I just found this blog, while fighting with a .local network, regarding a future problem with
obtaining a UCC certificate. I have one domain controller Server 2008R2 Std (AD, FSMO roles,
DHCP, ...) that is called abc.domain.local. The client has a domain name registered as
domain.com. I just installed Exchange 2013sp1 on a member server (2012R2 Std) called
xyz.domain.local. The network has about 40 computers/users. What should I do? I was
thinking:
1. uninstall Exchange 2013SP1, since it is not in production yet
2. rename domain to ad.domain.com
3. install Exchange again

Is this a correct approach?


Thank you for your input.
Reply

TYbarrondo 9/10/2014 2:15 PM


Hi Mark,
First of all I am glad to see the discussion still active. I am a consultant charged with
restructuring AD DS for a conglomerate which has acquired several companies, and to bring
them in to a single forest each with their own disjointed name space, and a single Exchange
2013 Org. to serve all domains in the forest. My plan is to have a root domain "ad.xyz" per
your advice, for administration of the forest; and all subsequent domains having disjointed
namespaces. However, the 2012r2 DC's in the root domain will be authoritative DNS servers
for all domains configured with FLZ's. I have it set up that way in an OOB lab and it all works
great. The main reason they want this setup is to save on the cost of Exchange Server
Licensing. My question is: Is there any reason I couldn't use a .net for all the domains in the
forest with a .com as my TLD?

Thanks
Reply

Bret 9/11/2014 2:17 AM


Thanks for the great article.

I am reading this because our AD domain name is not registered by our company. The AD
domain name is based on the name of our company, but is not the same. It's been setup
that way since about 2000.

The domain name has been for sale for years, and they want > $15k to buy it (strange to me,
because it doesn't seem like a name anyone would want.) So buying the name is out of the
question.

This has never created any problems, but I am seriously considering doing an AD rename to
something that we can register.

I am not looking forward to this process. We have two sites, 3 DCs, about 150 workstations,
and about 40 Macs bound to AD as well (what in the world happens to them during a domain
rename?)

Is it worth renaming the domain to something that we can register (or to a sub-domain of
our web domain)? What are the reasons to do so? What are the risks of continuing to use an
internal AD domain name registered elsewhere on the Internet?

Thanks.
Reply

Anonymous 12/15/2014 7:38 AM


Dear Mark, I have a domain name say xyz.com but netbios suggested during domain creation
was xyz0. I used that. and now my users have xyz0\firstname as usernames. I would like to
have an external internet facing domain, how can I register my domain?
Reply

tortoise 12/17/2014 3:00 PM


Dear Mark,

I am testing a roll-out. I followed best practices by naming active directory


sub.mydomain.com where mydomain.com is registered.

Next I installed exchange 2013 and this is where my confusion starts. Email addresses are
user@sub.mydomain.com. What would I do to get email addresses like user@mydomain.com.
It would be preferable to make this the default setting, as I would rather avoid having to
run a rename script every time I add a new user.

I didn’t mention, buy mine is a simple on-premise install with single exchange server with
mailbox & client access roles – no edge server.
Reply

Replies

JBERG 12/18/2014 8:50 AM


Tortoise, when it comes to exchange and the email addresses, you shouldn't have
to worry about doing anything with the UPN suffixes. Addresses in Exchange are
determined by the email address policy. For instance our organization's domain
and forest are denoted by (ex: contosso.org), while our email addresses to the
outside world are ex: (supermelon.com). Now Exchange can take the UPN, but
through the address policy you can tell it which domain names you want.. as long
as you own that name and it is registered. which by your post it is. User UPN
names will be still user@ad.mydomain.com while Exchange can give them an email
address of user@mydomain.com.

Reply

TYbarrondo 12/17/2014 4:09 PM


First you have to add all dns suffixes in ADSI, then add the domains to allowed domains in
exchange. Then you will be able to have domain specific email addresses.
Reply

Replies

Mark 12/17/2014 5:27 PM


The correct way to add UPN suffixes is through the AD Domain and Trusts console
(or through PowerShell) not directly through ADSI Edit.

Reply

SteveH 1/20/2015 4:52 PM


Mark,
Great article. I'm new to AD and building DC's, and wish I'd have seen this a week ago! I just
finished building Win Server 2012 R3 Ess for a friend with a small business. The install
defaulted to .local so I went with it not knowing. So far I only have one of his 4
workstations joined to the domain, and a company specific file share on the server they are
using in a production mode. Since this is new and small... realistically how much work would
it be to rename the domain (No Exchange) for an AD greenhorn?

Thanks
Steve
Reply

Anonymous 3/02/2015 12:50 PM


We just ran into yet another reason to never use fake TLDs. We just enabled DNSSEC
validation on our recursive servers. Even with forwarder records, our ".local" domains simply
stopped resolving. After some head scratching, we realized it had to be the DNSSEC
validation process causing it. That is because the recursive server will insist on going to the
root to validate the DNSSEC chain from the root to .local, and then to xyz.local even though
we had an explicit forwarder statement for the domain. As there is no such TLD, the first
level validation fails... and subsequently all resolution for any .local domain fails (or anything
that doesn't adhere to an officially designated TLD).

I bodged this by creating the local hierarchy on my recursive servers so that any xyz.local
domains get properly delegated (and now do not need to reference the root servers), but
that is just a stop-gap measure. It's not a truly valid solution to the issue.
Reply

DJC 3/07/2015 11:55 AM


I have a sbs2008 server on the blink and it has the .local on it. So I have 2 new servers with
Windows 2012 r2 essentials and win 2012 r2 standard exchange 2013 planned to replace the
sbs 2008 but need to migrate exchange and folders and mailboxes to new servers.
So .local needs to change to server.abc.net and mail.abc.net but I don't know how to
migrate the sbs if I change the domain? What do you suggest?
Thanks
Reply

DJC 3/07/2015 12:03 PM


I have a sbs2008 server on the blink and purchased 2 servers installing win 2102 r2 essentials
and win 2012 r2 standard with exchange 2013. I just found out about the .local as you have
been discussing in this blog. How would you approach setting the the new servers up as I
don't know how to migrate sbs 2008 with the .local domain to the new servers to
server1.abc.net.
How would you do this? Nothing on the microsoft tech net could i find to support this
change.
Thanks
Reply

Anonymous 3/25/2015 4:06 PM


I have a AD DC server with a DNS and DHCP server set up, and i would like to connect it to 2
client pcs. The error i get is "an active directory domain controller for the domain
'domainhere' could not be contacted.
Reply

Replies

Vivian 4/11/2015 2:16 PM


When trying to join the PCs, add the AD server's IP address to the preferred list of
DNS servers in each PCs network config and you should not see this error.

Reply

Kris 4/21/2015 2:34 AM


Hi Mark,

This article has nailed exactly where we shouldn’t be. We just outsourced our migration
(no-one in our company is very cluey when it comes to the MS world) from an old SBS
machine to Exchange 2013 and Windows Server 2012 R2 for the DC’s. Unfortunately the
outsourced company have migrated us to a .local domain (which I now see as being a clear
mistake, particularly in light of the changes by registered CA's).

This is already causing us grief since we use a web service for email filtering. This service
needs to to talk with our AD in order to authenticate users. Unfortunately, the filtering
service will not accept self-signed SSL certificates (and CA’s apparently no longer sell certs
for domains that are not publicly resolvable). This leaves the clear text option for LDAP, or
nothing.

As I understand it, we can't do a domain rename due to the Exchange server, hence, we
should build an entirely new AD domain (as a sub-domain of our existing public domain) and
then migrate all the machines and mailboxes in a cross-forest migration.

Can we build the new domain on the DC's in parallel with the currently operational
production domain (company.local) and then migrate everything over to the new sub
domain (internal.company.com.au)?

Can you see any alternative to this domain migration, given that we need to have the
machines talking securely to at least one web service that only accepts certs issued by
registered CA’s?

Could we proxy LDAP and similar requests through a machine we setup on our public domain
(but living behind the firewall) and set the public domain as being trusted by the machines
in the .local domain?
Is that a really bad idea from a security point of view? (all the machines involved are secured
behind a firewall but even so, it seems risky to me to tell the DC's to trust the public
domain....)

Any thoughts would be appreciated, and thanks for the great article!
Reply

Anonymous 5/20/2015 3:47 PM


Hello Mark,

very informative and well written.

Could you please clarify the following sentence "The correct way to name an Active
Directory domain is to create a subdomain that is the delegation of a parent domain that
you have registered and have control over." From what I understood we should never create
a delegation from the external to internal DNS Server to keep the local DNS data private. I'm
not an native speaker, just looking for confirmation.

thank you

Adam
Reply

Anonymous 7/05/2015 2:17 PM


Wow! Just sheer GREAT advice!!! Thanks out to Microsoft for screwing so many over with
.local as the default when using the configuration wizard of windows server essentials 2012.
:(
Reply

Anonymous 7/07/2015 12:52 PM


Since .local is now a reserved gTLD by ICANN, is it now OK to use .local in your Active
Directory name?

http://newgtlds.icann.org/en/applicants/agb/guidebook-full-04jun12-en.pdf
Reply

Replies

Mark 7/07/2015 1:16 PM


No, it's reserved for an entirely different purpose. If anything, it's worse to use it
now.

Reply

Anonymous 8/14/2015 3:50 PM


Hi Mark,
Excellent article and insight to the situation I just inherited. I'm a one man show and our
small network is comprised of VM 5.5 running 3 servers (2 are Serv. 2012 R2 & 1 is Serv. 2012)
and one physical server running Serv. 2003 SBS. The company is growing and before we get
to that "too big" thresh hold I would like to change the domain setup and remove the
.Local. We are now using O365 so we have no Exchange and one of the 2012 R2 Vm's is slated
to become the new DC. What can I expect if I change the domain and remove the .Local?
What are the steps that would need to take for this as well?

Thanks. Russ
Reply

Anonymous 9/04/2015 4:19 AM


When someone tells you in a sarcastic tone, "there are no stupid questions.", they should
be pointed to this web site. Mark you hit several nails on the head and punished more than
one troll. You deserve an award for having more patience than the entire industry of IT put
together. It's no wonder to me that pay has dropped when this is the calibre of support
companies must put up with. Kudos to you Mark for cutting through the bologna.
Reply

Replies

Anonymous 10/06/2015 9:19 PM


Actually, Microsoft used to recommend .local, back in the Windows NT 5.0 days.
Yes, some of us have been on the bleeding edge, and sometimes you do.

Reply

TP 10/13/2015 6:46 AM
Hello Mark,
Single Windows Server 2012 Domain Controller with 10 Windows 7/10 functioning
workstations that have joined the domain and functioning.
One of the workstations suddenly started to given an error message when logging in --- "The
trust relationship between this domain and the workstation has failed.....". Since we don't
have the local administrator password we may be dead in the water and this may require
reinstalling the O/S on this workstation. This I can handle...
BUT...
So, I decided to take a new workstation and tried joining it to the Domain but a couple of
screens into the wizard, I get the following error message -- "The specified domain does not
exist or could not be contacted".
I did ipconfig /all and saw the workstation received an IP address from DHCP and that the
workstation does point to the DNS server on the DC.
Is there something specific I can check to look for the problem...

Reply

Unknown 10/21/2015 12:54 PM


Mark,

I just recently started working for a company that uses their external domain name for their
internal AD domain as well. My first job is to do a major revamp of their network to help
them become HIPAA compliant, and this domain name is one of the big compliance issues
they're encountering, as it is a security risk.

We're getting all new servers, and will be migrating to a new domain name to move away
from this. However, I'm curious if it's possible for me to use best practice here given the
situation. We have Exchange 2010, and will be moving to Exchange 2016, so we're doing a
cross-forest migration of that anyway.

My issue is whether or not I can create a sub-domain (for example, we are company.org and
I want to use internal.company.org) and set up the necessary forest trust for this transfer,
or if a forest trust will fail because the new domain would technically be seen as part of the
existing domain.

I'd like to resolve that question before setting up the new domain, so that I can avoid this
issue if possible. Any suggestions?
Reply

Unknown 10/21/2015 12:56 PM


Mark,

I have an existing domain I've inherited using its public domain name for the internal domain
as well. (For this example, say company.org)

We will be migrating to a new domain name to ensure HIPAA compliance, as this practice can
cause security issues. However, because we need to migrate e-mail across the domain, I
need to ensure I can set up a forest trust.

Will making the new domain internal.company.org cause forest trusts to fail, or will they
work as intended even though that's technically a sub-domain of the current domain name?
(I've not run into this particular situation before, thankfully.)
Reply

Anonymous 10/30/2015 1:58 PM


I've used domain.local on several domains across a few companies over the past 15 years
now and never have I run into the issues described in this article.

1. SSL not a problem, I run my own CA so why would I need to ever or want to ever spend
money on a certificate that is for internal resources.
2. Exchange, not a problem if you understand split DNS and how to create additional
forward lookup zones if needed.

3. I never have to worry about a domain name existing as mine since I use
companyname.local.

4. look at all the posts where people followed other guidance and now have to cleanup
since they used the wrong domain name.

5. I never have issues with domain name resolution, just setup the forwarders on the dc,
.local resolves internally, everything else is external... simple.

I will continue to use .local and it will continue to work for me. Have fun folks.
Reply

Replies

Stanley Ng 6/04/2016 3:23 PM


Totally agreed!

Reply

Unknown 11/12/2015 3:28 PM


DONT
FUCKING
USE
IT

Linux also reserves .local for mDNS. The way some distributions are configured by the
operating system does not even try to call the DNS resolver for .local domains. I'm ripping my
hairs off trying to disable and/or uninstall the mDNS resolver from 900+ POS machines. Please
don't.
Reply

Replies

Александр Якименко 7/27/2016 12:47 PM


Use dhcp for DNS server setup or use "search" with correct DNS suffix and use
"dns files" in /etc/nsswitch.conf for "hosts:"

Reply

Anonymous 11/20/2015 12:43 AM


ಠ╭╮ಠ

I've been doing this all my life. Thanks for making me feel stupid. I mean, JEEZERS!!! I just
realized that I've also made dozens of other people who listen to my advice stupid as well. I
should have realized it sooner. Think about anybody who works in a Microsoft environment.
Sure, you see "contoso" all over help documents and whatnot, but have you ever, I mean
EVER seen a Microsoft document or internal memo or anything at all with "microsoft.local"
on it? That should have tipped me off, but I'm stupid. So stupid.

Gosh.

Reply

PaulS 11/22/2015 4:10 PM


Hi Mark

Good article, I have set up a complete AD and exchange environment using your advice.
e.g. abc.companyname.com

This is a Server 2012/Exchange 2013 environment

its still pre-production and all seems to wok OK.

My only concern is external users of Outlook that use Outlook anywhere or Outlook HTTPS
over RPC
I cannot get my head around how the certificate will work and if indeed it will
The accepted domain for exchange is companyname.com, without the subdomain prefix
I know this will accept email

I am a fan of self-signed certificates and these have worked well for me in the past. If I
change my Certificate in Exchange to the published remote.domain.com internal users stop
working.

Can you offer any guidance please?

Thanks PaulS

Reply

69Petusik 1/07/2016 3:13 PM


Hi Mark, i think you're missing a few things. I don't see any reasons why I can't simply use
.local .corp as a internal root ad top level domain name. What If I have a single forest single
domain architecture and dividing AD based on location via OUs. It does make sense to have
something like comapny.corp for the root ad domain and internal dns records like
cz.company.corp, at.company.corp, com.company.corp instead of com.company.com. ??? And
internal users are usually visiting company websites through internal dns records, that's
what split dns is about. I think this post is completely useless, if somebody use .local tld it's
for a reason !!!
Reply

Replies

Mark 1/07/2016 5:11 PM


It seems you've missed almost the entire point of everything I've said.

1. I'm talking about single domain forests, which is the preferred architecture in
almost all cases. Empty forest roots were. A bad idea of the past.

2. If you don't use split DNS, you don't need to maintain internal DNS records for
internal sites. If your public DNS is company.com, but your AD is ad.company.com,
you don't need to keep records for company.com internally and externally. It's
fewer DNS records to curate, which is a win for everyone.

3. If someone uses .local, it's because they think there is a reason, but they don't
actually know what it is. I have yet to hear a single good reason to do it other
than "I always have" which is never a good reason to do anything.

If you disagree, I'd love to here specific technical points. As it is, your current
post adds very little to the conversation.

Reply

Neesh 1/19/2016 2:41 PM


Great post. I inherited an SBS 2003 server many years ago and even back then the sys admin
had the sense not to use .local
Reply

Maniax 1/30/2016 9:48 AM


Hi Mark, I have named my AD ad.company.com and now I try to configure Exchange 2016 and
my host is named mta.ad.company.com Now I will have two addresses that will point to
autodiscover servicess mail.company.com for external and mta.ad.company.com for internal
users. I would like to users only have to know a single namespace (e.g., mail.company.com)
to access their data, regardless of where they are connecting. Naming my domain this way
will enable me to avoid split brain DNS, but the exchange team states : "Since the release of
Exchange 2007, the recommendation is to deploy a split-brain DNS infrastructure for the
Internet-based client namespaces."
http://blogs.technet.com/b/exchange/archive/2014/02/28/namespace-planning-in-
exchange-2013.aspx. My issue is how to keep configuration simple for my users.

Thanks !
Reply
Replies

Mark 1/30/2016 11:05 AM


If you want, you can split-brain by creating a company.com zone in your AD DNS.
You don't have to name your AD "company.com" to do this. Or you can just have
the users use the public "company.com" zone to connect to the mail
infrastructure.

Reply

Unknown 2/06/2016 6:07 AM


This comment has been removed by the author.
Reply

Unknown 2/06/2016 6:12 AM


Hi Mark ,

we are going to install new domain .


we have site internally and public site and email that hosted locally .
we also need to have SSO ,
and our email is linux base server .
do you suggest use best practice ?
if yes please suggest the plan .

thanks .
Reply

Anonymous 2/18/2016 7:49 PM


Hello Mark,
First thanks for the article and you should be commended on your points and its clarity. I
have to admit I implemented several SBS environments and have used the .local as
suggested by the wizards. Each of them are SBS 2003, 2008, or 2011 with using Exchange and
SharePoint's companyweb which made the SBS model very cost effective (even it is not
recommended) but Microsoft provide the suggestion of the .local so I thought it made sense
(at the time) and also Microsoft throttled down the SBS implementation so it could all reside
on the same box/server.

So, now SBS is no longer available or at least not worth purchasing due to its duration for
support.

Only recently has it caused a complication when getting certificates. Which caused me to
do some reach and I found your article and I think that I have painted myself and the server
in to a corner. In the past, I booted the new server with a migration answer file but that
was SBS old to SBS new and then complete the rest of the migration process.

This is nothing that I have to do soon as I merely making plans due to your .local article and I
ask the following per your experience in the .local to .edu rename and migrate in
comments. Also, the existing environments are less than 20 computers so I was not
completely worried about the disjoining computers and joining to the new domain. But,
wished to avoid the renaming of the domain due to Exchange 2007 and 2010 limitations and
exporting mailbox items to .pst and importing to the newly created mailbox.

When upgrading these clients from SBS 20xx to Server 2012 or 2016 and using HyperV for a
virtual machine for the AD and another virtual machine for Exchange, do you think I will able
to use an answer file technique per (https://technet.microsoft.com/en-
us/library/gg563801.aspx) or ADMT to go from domainname.local to corp.domainname.com
and migrate users and mailboxes as described in the following article
http://blogs.technet.com/b/sbs/archive/2009/05/01/sbs-2003-to-sbs-2008-migration-to-a-
different-domain-name.aspx? Or do you have another suggestion?

Your recommendation and opinion valued and THANK YOU in advance!! Anonymously as to
not call attention to my poor decision of using .local.
Reply

Anonymous 5/27/2016 5:08 AM


I named my AD to x.y.com.sb and my exchange server pointing to y.com.sb - how can I set
my AD to show my fQDN when creating new email users? currently when I want to create
new users it will give users - john.smith@x.y.com.sb but I want users to be like -
john.smith@y.com.sb
Reply

Replies

Mark 5/27/2016 6:45 AM


You're talking about a user principal name and it is configurable on a per-user
basis.

Reply

Michiel Wouters 6/01/2016 11:52 AM


I totally get your point, Mark, but creating a dependency between a public web domain and
your AD domain is not a great idea when considering mergers or company name changes.
Like the example of the fruitcakes in one of the comments. On the other hand, when using
a more generic name like insurance.local or finance.local, does not need to be renamed
when company changes it's name, but could get messy when the company merges with
another financial corporation, which thought insurance.local was a good idea.

Great discussion though!

I think registering a more generic public domain name which relates to your company's
activities can be a good way to go.
Reply

Replies

Mark 6/01/2016 11:58 AM


Great examples, but by the same token, companies change lines of business as
well. I have a customer who is in the health device field, but started as a jet
rental company (not joking) so they log in with something like JETSETTER\user
and they're not in the medical space.

Just goes to show that you can't predict the future, you can only plan for best
practices of today :)

Reply

Anonymous 6/29/2016 2:42 PM


I have worked for the last 12 years in an environment where we had a split DNS
infrastructure. We setup IIS to redirect to our web site. This has been my only experience
with AD and it wasn't ever an issue. I am now at a new job and was hired to migrate from
Novell to AD (currently there is no AD) and then integrate all our Macs (80/20 split of Macs
to Windows). I have been convinced by blogs such as yours that using a sub domain is the
better way to go. Also, our domain name is longer than 15 characters so keeping the name
"pretty" will not be possible. The last piece of unknown to me is the Mac integration. We
have narrowed down out Mac integration solutions to Dell Authentication Services or
Casper. Does a sub domain add any complexities to the already difficult Mac integration
process?
Reply

Anonymous 7/13/2016 6:07 AM


It is good to see this post is still continuing to generate questions and debate. My
knowledge is limited to self research from posts like this, and I do have some questions;
some basic so don't shoot the dumb ass.

I have two public websites at companyx.com and companyy.com. Those are managed on
Goddady servers.

I have emails with O365 E3, as you can add more than one domain into one service. Recently
I set up an internal server with a DC called companyz.com but panicked it would mess a
future public facing site I was planning to launch and so I renamed the DC companyz.local to
keep it separate.

Now this post is saying .local is bad practice and I was just about to create two more DCs as
I want to create internal logins for companyx.com and companyy.com on the same box as my
.local, but if I call the new DCs companyx.com and companyy.com I'm thinking that would
affect the pubic websites... If I call them DC.companyx.com or AD.companyx.com how
would that effect the user login name. I want them to log in to services with
name@companyx.com and name@ompanyy.com so now i'm a little lost.

So my emails are managed on O365, my pubic sites on managed on hosted servers, my


internal servers are for SQL and CRM and I want uses in companyx.com, companyy.com and
companyz.com to all have access CRM as different business units.

Ps - I don't normally ask question on the net and normal find the answers, but the feedback
on this post looks helpful to ask.
Reply

Replies

WhatdDomain 2/07/2017 3:47 AM


I've noticed that you have not received a response to your questions. I've been
working with AD and DNS for many years now, ever since the old school of NT
domains (predecessor to AD DS). I have no formal training in either. All my
knowledge comes from years of experience which is accompanied with lots of trial
and error. Which is a very dangerous kind of knowledge.

With that said I will attempt to shine light on your doubts if for nothing else to
test my knowledge.

I see that you were confused when you questioned about what you will call your
DC's. First of all you have to realize that, as Mark mentioned, you will be creating
a second-level domains called internal.companyx.com, internal.companyy.com and
internal.companyz.com. You will then name the DC's DC.internal.companyx.com,
etc., etc. Now, internal.companyx.com is a subdomain of companyx.com and
although there exists some trust relationship benefits, when it comes to your
publicly visible domain companyx.com, there essentially separate.

You can also add the UPN Suffix to your domains so that users can log in using
user@companyx.com instead of user@internal.companyx.com.

I hope this helps. Please, anyone, correct me where I'm wrong. Thanks.

Reply

Anonymous 8/24/2016 6:29 AM


Hi,

> You shouldn't be exposing your Domain Controllers to the Internet, period.

True, but... there is at least one vector of attack you may not be aware of. Windows DNS
clients are a bit non-deterministic and it is very common for them to leak DNS requests out
to the internet. An administrator might have set up a public DNS server in the list "for
redundancy", in which case it will be used at random a small percentage of the time, or you
may have a good old hijack. If your AD domain is registered externally by a bad actor and
gets a DNS lookup sent to it, boom, that machine can be made to send AD requests to an
arbitrary server. The attacker can then presumably get password hashes, or set up a
netlogon share and get arbitrary code executed.

DNS outbound should be blocked, yes, but it isn't sufficient just to firewall your AD
infrastructure.

- Freddie Sackur
Reply

Dawesi 1/19/2017 7:45 PM


" You shouldn't be exposing your Domain Controllers to the Internet, period."

Wow really... better tell Azure.

I'd say it's bad practice to tie an internal system to any external domain... Most companies
have more than one domain name, so and the rate companies change branding... then the
domain changes, then you rename you're whole forest... K.I.S.S.

There is nothing, nor will there be anything wrong with using .local on a AD setup in itself.
Reply
Replies

Mark 1/19/2017 9:12 PM


I'm not sure what you mean by the "tell that to Azure" comment. Active Directory
Domain Controllers shouldn't be exposed to the internet whether they are on-
prem or Azure.

roeland 6/13/2017 9:10 AM


Dawesi,

if you still believe that there are good reasons to use .local, you have missed the
point. Even internal it causes so much pain as it's tied to mDNS.

Anyone who plugs in a linux or apple system will face problems due to this
misjudgement/misunderstanding.

Reply

WhatdDomain 2/07/2017 12:48 AM


It's been a while since I installed SBS but if I remember correctly one of the first thing
Installation asks is for your public company.com domain in order to correctly configure
Exchange. Why did Microsoft than decided to use .local as opposed to
internal.company.com for the local AD structure if such a use is "Best Practice"?
Reply

Unknown 4/18/2017 10:32 AM


Hi, I have inherited a .local domain with at the moment 2003 domain controllers and a
Exchange 2007 server. What is the way to use public SSL certificates then? Rename the
domain to .com or ....
Reply

midiman25 3/01/2020 3:25 PM


I know this is an old post but this is still relevant.

For example
1. I am going to register a public domain name called demoworkers123.com
2. Then I am going to create a new AD Infrastructue and call my forest root
internal.demoworkers123.com
3. But the only problem with this is that all my users emails email address will be
bob@internal.demoworkers123.com and I would like them to be bob@demoworkers.com

What can I do about this?

Thanks
Reply

Replies

Mark 3/01/2020 6:17 PM


This has been addressed here a few times but the short answer is that you are
describing what is called a User Principal Name. The suffix can be changed and is
independent of the AD DS domain name.

Reply

-Henry Lafontaine 3/02/2020 9:45 AM


You can name the domain exchange uses to anything you want. Best to make the cert
wildcard and listed the local domain and all email exchange suffixes named.

Cost more money but will allow you to use one cert locally and externally without issues.

Reply
-Henry Lafontaine 3/02/2020 9:59 AM
Don't name your forrest valid TLDs they are not meant to be registered for public access
themselves and is much safer to use a alias for any web application.

There is never a reason for a cert from the public web space needing to be giving to
anything internal.

Use a internal ca server for that.

Reply

Vandrey Trindade 3/13/2020 8:30 AM


Hola Mark, acabo de leer tu publicación y me encantó.
Sin embargo, todos los documentos que encuentro sobre este tema son muy antiguos.
¿Sigue siendo una buena práctica usar ad.domain.com? Un tipo en un curso de Office 365 me
dijo que siempre usa domain.local y que no hay razones para usar subdominios ...
Respuesta

Enter your comment...

Comment as: Google Accoun

Publish Preview

Publicación más reciente Hogar Entrada antigua

Suscribirse a: Publicar comentarios (Atom)

A propósito, no nombro a mi empleador aquí y cualquier referencia a él se elimina de los scripts / códigos antes de que se publique. Este
blog y todos los enlaces y perfiles relacionados son completamente míos. Mis opiniones, creencias, críticas, etc. son completamente mías
y no son indicativas de las creencias de mi empleador.

Desarrollado por Blogger .

También podría gustarte