.local or .com on internal domain.
Hi.
we have sat up many servers\ domains for our customers over the years and always used .local for the internal domain. Earlier dcpromo (2003) used it in its wizards examples and was told that it was a good way to keep internal and external domain seperate.
Have never had any problems with this.
Have now recently been told that it's against Microsoft recomandations to use .local internaly, and that we should use domainname.com also internaly.
Because of exchange and certificates.
What do you think?
we have sat up many servers\ domains for our customers over the years and always used .local for the internal domain. Earlier dcpromo (2003) used it in its wizards examples and was told that it was a good way to keep internal and external domain seperate.
Have never had any problems with this.
Have now recently been told that it's against Microsoft recomandations to use .local internaly, and that we should use domainname.com also internaly.
Because of exchange and certificates.
What do you think?
Your exchange certificates for your external domain can, and are, easily separate from your internal domain structure. I still currently recommend using a separate internal domain.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Securing internal resources can easily be done with an internal CA. External resources can be secured with an external name, which has no bearing on your internal domain name.
You can, for example, have an Exchange server joined to an internal name called mycompany.local, have it running the client access role, and secure the public face with a certificate with the name mail.some-company.com.
Internal-only domain names are fine. Like any infrastructure, it takes planning. So while some of the "supporting arguments" this person gave you are half-true, it doesn't actually make the case for using a public name.
You can, for example, have an Exchange server joined to an internal name called mycompany.local, have it running the client access role, and secure the public face with a certificate with the name mail.some-company.com.
Internal-only domain names are fine. Like any infrastructure, it takes planning. So while some of the "supporting arguments" this person gave you are half-true, it doesn't actually make the case for using a public name.
.local is used to distinguish internal network from external dns becasue .local is the primary dns domain name suffix for your internal clients so the internal network will work on .local.
.com is for external ones for safety and manageabillity.
.com is for external ones for safety and manageabillity.
@BM-vnext Since you can specify a SAN name (Subject Alternative Name) in your certificate that can display the local TLD that also should not generate problems.
Not if your certificate will expire after 1 Nov 15
Do not use .local -- certificate issues and also Apple products i..e Macbooks/Ipad have issues with .local
All Certificate Authorities (CAs) that are connected to the overall CA/Browser Forum have accepted worldwide renewed and improved guidelines for the issuance of a SAN SSL Certificate. Domain validated certificates may therefore no longer be issued on an invalid Fully-Qualified Domain Name (eg .local).
The reason that is given for the change is that the internal server names are not unique and therefore easy to falsify. With common names like server01 or webmail, the end user is never sure if it is actually dealing with the right party or with a malicious.
The changing legislation for SSL Certificates shall start on 1 November 2015.
http://www.networking4all.com/en/ssl+certificates/faq/change+san+issue/
If you are using .local you can change it.
https://www.networking4all.com/en/support/ssl+certificates/manuals/microsoft/exchange+2010/modify+.local/
It does mean registering another domain i.e. mycompany.net / mycompany.org or use a subdomain i.e. local.mycompany.com or internal.mycompany.com for your internal network.
Not if your certificate will expire after 1 Nov 15
Do not use .local -- certificate issues and also Apple products i..e Macbooks/Ipad have issues with .local
All Certificate Authorities (CAs) that are connected to the overall CA/Browser Forum have accepted worldwide renewed and improved guidelines for the issuance of a SAN SSL Certificate. Domain validated certificates may therefore no longer be issued on an invalid Fully-Qualified Domain Name (eg .local).
The reason that is given for the change is that the internal server names are not unique and therefore easy to falsify. With common names like server01 or webmail, the end user is never sure if it is actually dealing with the right party or with a malicious.
The changing legislation for SSL Certificates shall start on 1 November 2015.
http://www.networking4all.com/en/ssl+certificates/faq/change+san+issue/
If you are using .local you can change it.
https://www.networking4all.com/en/support/ssl+certificates/manuals/microsoft/exchange+2010/modify+.local/
It does mean registering another domain i.e. mycompany.net / mycompany.org or use a subdomain i.e. local.mycompany.com or internal.mycompany.com for your internal network.
I personally don't really think it matters. As long as you get the DNS setup correctly then from a technical point of view it isn't a problem.
If you do use a public domain, then make sure that it is one that you own.
Where the usual problems start is when the company changes names and the management want the old name erradicated from everywhere. Therefore a trend I am starting to see is the use of a generic name for the domain. office.local I have seen more than once. I have also seen D123456.com (where 123456 is a random number) used as well.
In those cases, what was then done is the UPN value changed to match the email address of the end users, and they use their email address for all authentication everywhere.
On the subject of the SSL certificates - having .local as your domain doesn't really matter too much. It is trivial to setup Exchange to not use the .local anywhere and therefore getting round the November 2015 issue. Renaming a domain isn't exactly straight forward, particularly with Exchange involved so if you are stuck with the domain then just work around it.
Simon.
If you do use a public domain, then make sure that it is one that you own.
Where the usual problems start is when the company changes names and the management want the old name erradicated from everywhere. Therefore a trend I am starting to see is the use of a generic name for the domain. office.local I have seen more than once. I have also seen D123456.com (where 123456 is a random number) used as well.
In those cases, what was then done is the UPN value changed to match the email address of the end users, and they use their email address for all authentication everywhere.
On the subject of the SSL certificates - having .local as your domain doesn't really matter too much. It is trivial to setup Exchange to not use the .local anywhere and therefore getting round the November 2015 issue. Renaming a domain isn't exactly straight forward, particularly with Exchange involved so if you are stuck with the domain then just work around it.
Simon.
.locl or .com doesn't make much difference but if you have an email system in place, it would be beneficial for you to use .com as it will not create any confusion for email addresses and internal domain names.
The Cert publishers are thanking Microsoft for this one... The generation of revenue to them will be significant. .Local or .prv will no longer be supported, Microsoft's way of getting you to move to the cloud...
It has NOTHING to do with Microsoft. This is something from the SSL providers consortium, which Microsoft I believe is a member of, but that is all.
.local and .prv is something they have decided not to support.
It also has nothing to do with forcing you to move to the cloud. It is just trying to fix SSL.
Linux and other OS's are also affected.
Simon.
.local and .prv is something they have decided not to support.
It also has nothing to do with forcing you to move to the cloud. It is just trying to fix SSL.
Linux and other OS's are also affected.
Simon.
I would stick to the microsoft recommendations to avoid having to migrate or rename your domain in the future. Not to mention that Certificate Authorities are no longer issuing internal ssl certificates to for non FQDN's.
As a best practice you keep internal domains seperated from your external ones for safety and manageabillity.
Certificates that contain intranet names are not widely supported anymore but you could get a multi-domain certificate here and there.