[W2k8] AD domein naamgeving & nieuwe regels .local Cert Auth

[Urk]

Twee weken geleden heb ik als reseller van Xolphin (sslcertificaten.nl) een bericht ontvangen dat de grote Certification Authorities onderling met elkaar hebben afgesproken om vanaf eind 2015 geen SSL certificaten meer uit te geven die interne domeinnamen (zoals bijv. .local) bevatten (bron oa: Digicert)
Wat je bijv. nu veel gebruikt met Exchange 2007/2010 UCC certificaten.
Xolphin en de Certification Authorities erkennen ook dat dit problemen gaat opleveren met Exchange UCC certficaten en de interne domeinnamen die nu bij veel bedrijven in Active Directory worden gebruikt, vandaar dat deze wijziging dus pas vanaf eind 2015 wordt doorgevoerd.

Simpelgezegd kun je na eind 2015 dus geen SSL certificaten meer krijgen met interne domeinnamen.
Naar mijn weten is het ook geen recommendation van Microsoft voor AD implementatie om publieke FQDN te gebruiken voor je interne netwerk.
Wat is nu dus de beste mogelijkheid met dit in acht te nemen om een AD domein op te zetten?

Aangezien ik nu bij een klant een nieuw Windows 2008 R2 netwerk aan het inrichten ben wil ik hier gelijk rekening mee houden zonder dat dit later nog problemen oplevert.


Een optie zou zijn toch gewoon een bedrijf.local domein te gebruiken voor AD en dan een interne DNS zone aan te maken met de publieke domain zone (bijv. bedrijf.nl) zodat mail.bedrijf.nl intern verwijst naar het interne IP en daarbij een SSL UCC certificaat met daarin bijv. mail.bedrijf.nl, autodiscover.bedrijf.nl en webmail.bedrijf.nl laat draaien.
Ik weet dat dit normaal ook geen recommendation is om publieke DNS zones dubbel te hebben in je interne DNS server (hier is een naampje voor volgens mij).

Wat zou jullie advies en gedachten hierin zijn?

Edit: officieel is de regel als volgt:
Vanaf 1 juli 2012 mogen er geen SSL certificaten meer uitgeven worden met interne domeinen welke een einddatum hebben later dan 1 november 2015. De browser fabrikanten zoals Microsoft en Mozilla vinden het gebruik van interne domeinen in SSL certificaten onveilig. Vandaar dat het tot 1 november 2015 nog wel mogelijk zal zijn om certificaten met interne domeinen aan te vragen, maar altijd met een einddatum die voor 1 november 2015 ligt.
Certificaten met interne domeinnamen welke voor 1 juli 2012 zijn uitgegeven en op 1 oktober 2016 nog geldig zijn zullen door de certificate authorities worden ingetrokken.

[ Voor 23% gewijzigd door Urk op 10-07-2012 15:37 ]

[Remco]

Als je vragen hebt met betrekking tot best practices, dan zoek je toch gewoon bij de fabrikant?
Zie: DNS Namespace Planning

[Razwer]

de term die je zoekt: Wikipedia: Split-horizon DNS

Waarom zou je in godesnaam 3rd party certs met .local uberhaupt willen uitrollen? In exchange kan je externe en interne URLs prima afscheiden, zit default in het pakket en autodiscover intern en extern heb je ook geen issues mee gezien die intern automagisch naar je .local domeintje gaan verwijzen en extern je gewoon het mail domein kan gebruiken voor je autodiscover. Split-Brain-DNS is totaal overbodig, maar ook geen grote issue als je beetje goed nadenkt over de implementatie.
Je kan gewoon je interne CA dus gebruiken voor je .local en je 3rd party voor je externe URLs

[ Voor 7% gewijzigd door Razwer op 10-07-2012 20:00 ]

[Red Cell]

Razwer schreef op dinsdag 10 juli 2012 @ 19:58
Waarom zou je in godesnaam 3rd party certs met .local uberhaupt willen uitrollen?

Mischien het feit dat je maar 1 certificaat mag gebruiken in IIS?

[Razwer]

Red Cell schreef op dinsdag 10 juli 2012 @ 20:04:
[...]


Mischien het feit dat je maar 1 certificaat mag gebruiken in IIS?

LOL ja per IP adres.
en als je TMG draait heb je maar 1 IP nodig. Anders bind je een extra IP en maak je desnoods een extra OWA virtual directory aan
http://technet.microsoft.com/en-us/library/bb123515.aspx

NEXT!

[Grvy]

Razwer schreef op dinsdag 10 juli 2012 @ 20:12:
[...]


LOL ja per IP adres.
en als je TMG draait heb je maar 1 IP nodig. Anders bind je een extra IP en maak je desnoods een extra OWA virtual directory aan
http://technet.microsoft.com/en-us/library/bb123515.aspx

NEXT!

Doe even normaal joh. Het is gewoon een vraag.. jezus.

[Razwer]

Grvy schreef op dinsdag 10 juli 2012 @ 20:13:
[...]


Doe even normaal joh. Het is gewoon een vraag.. jezus.

Als de vraag oprecht was, dan bij dezen mijn excuses, maar het kwam op mij over als een cynische opmerking met een vraagteken er achter.
Als IK die vraag oprecht zou stellen had ik het anders geformuleerd: "is het niet zo dat je maar 1 certificaat op IIS kan zetten?" oid

[ Voor 17% gewijzigd door Razwer op 10-07-2012 20:19 ]

[Urk]

Razwer schreef op dinsdag 10 juli 2012 @ 19:58:
de term die je zoekt: Wikipedia: Split-horizon DNS

Waarom zou je in godesnaam 3rd party certs met .local uberhaupt willen uitrollen? In exchange kan je externe en interne URLs prima afscheiden, zit default in het pakket en autodiscover intern en extern heb je ook geen issues mee gezien die intern automagisch naar je .local domeintje gaan verwijzen en extern je gewoon het mail domein kan gebruiken voor je autodiscover. Split-Brain-DNS is totaal overbodig, maar ook geen grote issue als je beetje goed nadenkt over de implementatie.
Je kan gewoon je interne CA dus gebruiken voor je .local en je 3rd party voor je externe URLs

Oh ja, split DNS idd, thanks. Was de naam even kwijt. Ik weet dat split DNS geen optie normaal is en ik gebruik het ook NOOIT!
Het cert issue zoals ik noem verandert dit misschien.
Vandaar mijn topic.

Er zijn volgens mij veel bedrijven die Exchange UCC certificaten gebruiken met zowel publieke als interne DNS namen. Je kan tevens inderdaad in IIS maar volgens mij ook bij Exchange (MAPI) maar 1 certificaat per service kiezen. Dus wat Red Cell zegt is volgens mij de bottleneck.

Ik weet ook dat je in Exchange interne en externe URL's kan afscheiden, dat doe ik ook altijd. Maar dan blijf je toch 1 IIS applicatie hebben voor bijv. OWA die binnen en buiten benaderbaar is. Binnen via de interne URL maar met het enige UCC certificaat wat je kan kiezen.

Wat Razwer zegt is nog wel interessant.
Bij dat verhaal begrijp ik dat je in IIS 2 apps hebt, 1 OWA extern en 1 OWA intern (dmv host header of IP gescheiden). Dan heb ik volgens mij nog wel steeds het probleem dat je dat niet kan doen voor MAPI, die beveilig je toch ook met SSL?

[alt-92]

SAN Certs > klaar.

[Urk]

alt-92 schreef op woensdag 11 juli 2012 @ 22:10:
SAN Certs > klaar.

Sorry maar ik snap niets van deze bijdrage aan dit topic. UCC certificaten zijn toch gewoon SAN certificaten? Daar heb ik het al over en juist daarover gaat dit topic icm met de nieuwe regels.

Bron: Digicert:
The Subject Alternative Name extension has been a part of the X509 certificate standard since before 1999, but only recently achieved widespread use with the launch of Microsoft Exchange Server 2007—which makes good use of Subject Alternative Names to simplify server configuration.

[Razwer]

http://blogs.technet.com/...client-access-server.aspx

intern MAPI verkeer kan je met je eigen CA een certje geven, extern via Outlook over the internet (RPC over HTTP) met 3rd party cert.

Host headeren met SSL werkt niet, je zal met een extra IP moeten werken.

Red Cell moet je niet serieus nemen, als iemand zo overtuigend en sarcastisch zulke verkeerde opmerkingen kan maken, kan je ze niet serieus nemen.

[Urk]

De basis vraag die eigenlijk blijft staan bij dit topic is "wat is de beste DNS namespace naamgeving voor een nieuwe Active Directory omgeving" met het in acht nemen van bovengenoemde veranderingen?

Ik zit nu zelf te denken aan:

intern.domeinnaam.nl

Met deze AD naam kan heb ik geen .local SSL cert meer nodig en kan ik de intere DNS naam gescheiden houden van de externe DNS naam (domeinnaam.nl).

Is dit niet de beste optie?

Edit: volgens dit artikel is bovengenoemd dus toch de beste optie, wat ik al dacht?

[ Voor 18% gewijzigd door Urk op 12-07-2012 12:59 ]

[ralpje]

Ik gebruik altijd de externe domeinnamen in combinatie met een firewall die netjes aan NAT-loopback doet. Je hoeft dan geen split DNS te implementeren, maar je firewall routeert je in plaats van naar buiten netjes naar binnen.

[redfoxert]

ralpje schreef op donderdag 12 juli 2012 @ 13:02:
Ik gebruik altijd de externe domeinnamen in combinatie met een firewall die netjes aan NAT-loopback doet. Je hoeft dan geen split DNS te implementeren, maar je firewall routeert je in plaats van naar buiten netjes naar binnen.

Is dat niet ontzettend lastig als je een externe presence hebt zoals een publieke website?

[Urk]

ralpje schreef op donderdag 12 juli 2012 @ 13:02:
Ik gebruik altijd de externe domeinnamen in combinatie met een firewall die netjes aan NAT-loopback doet. Je hoeft dan geen split DNS te implementeren, maar je firewall routeert je in plaats van naar buiten netjes naar binnen.

Hmmm... en je interne servers dan? Hoe en waar staan die in DNS geregistreerd?
Stel je server is in AD server.domein.nl, die wil je extern niet in je DNS hebben, maar intern wel lijkt me. Heb je toch intern een DNS server nodig die de zone domein.nl serveert.
Toch...?

Dan kan je toch beter je publieke DNS zone buiten houden en intern bijv. intern.domein.nl gebruiken. Je server wordt dan server.intern.domein.nl, en je interne AD DNS service draait die DNS zone.

Ben benieuwd hoe andere hun AD naamgeving hebben gedaan....

[Razwer]

Urk schreef op donderdag 12 juli 2012 @ 12:54:
De basis vraag die eigenlijk blijft staan bij dit topic is "wat is de beste DNS namespace naamgeving voor een nieuwe Active Directory omgeving" met het in acht nemen van bovengenoemde veranderingen?

Ik zit nu zelf te denken aan:

intern.domeinnaam.nl

Met deze AD naam kan heb ik geen .local SSL cert meer nodig en kan ik de intere DNS naam gescheiden houden van de externe DNS naam (domeinnaam.nl).

Is dit niet de beste optie?

Edit: volgens dit artikel is bovengenoemd dus toch de beste optie, wat ik al dacht?

Je vraagstelling is beetje off, gezien jij alleen weet wat het "beste" is. In verschillende opvattingen is een verschillende uitkomst. Beiden kan, is maar net waar je voorkeur ligt.
Persoonlijk ben ik meer fan van .local te gebruiken maar heb geen problemen met een public fqdn te gebruiken. Je zal in sommige gevallen hoe dan ook split brain dns moeten gebruiken. Stel je host je eigen externe site, die wil je intern misschien wel op je interne IP willen benaderen. Dan zal je intern in je eigen DNS daar een verwijzing voor moeten maken. Zo zijn er nog vele voorbeelden. Dit is per situatie verschillend en zal je zelf de afweging moeten maken wat de minste administratieve puinhoop wordt en waar je zelf het beste mee kan om gaan en je fijn bij voelt.

Bij mij op werk is het AD domein een .com het mail domein een .nl en de netbios naam van het domein weer iets totaal anders (uit NT4 tijd overgekomen). Niet ideaal, maar helaas een erfenis.

[ralpje]

Urk schreef op donderdag 12 juli 2012 @ 14:09:
[...]

Hmmm... en je interne servers dan? Hoe en waar staan die in DNS geregistreerd?
Stel je server is in AD server.domein.nl, die wil je extern niet in je DNS hebben, maar intern wel lijkt me. Heb je toch intern een DNS server nodig die de zone domein.nl serveert.
Toch...?

Dan kan je toch beter je publieke DNS zone buiten houden en intern bijv. intern.domein.nl gebruiken. Je server wordt dan server.intern.domein.nl, en je interne AD DNS service draait die DNS zone.

Ben benieuwd hoe andere hun AD naamgeving hebben gedaan....

Mijn uitleg was niet helemaal duidelijk, merk ik.
Intern gebruik ik gewoon .local adressen. Dingen als webmail, lync en andere meuk worden (zowel vanaf intern als vanaf extern) benaderd op hun .nl-adres. Dus: intern surf je naar webmail.bedrijfsnaam.nl.
De client doet een DNS-lookup, en krijgt een extern IP door. De firewall ziet echter dat er voor dat IP een NAT-regel geldt en zal dus netjes het pakketje bij het interne adres afleveren. Op die manier heb je, zonder dat je zelf lastig hoeft te doen met een split-DNS, wel hetzelfde effect en kun je gewoon je externe (.nl) adressen op je certs gebruiken.

Heb ik tot nu toe alleen gebruikt in combinatie met Cisco ASA's en Astaro firewalls, maar werkt ongetwijfeld ook op andere merken.

[wagenveld]

Ik zie het probleem van split DNS niet helemaal. Ja, je moet even je www publieke IP in je interne DNS gooien, maar dat is toch geen probleem? Wij draaien gewoon bedrijf.com zowel intern als extern, geen centje pijn.

[Razwer]

ralpje schreef op donderdag 12 juli 2012 @ 13:02:
Ik gebruik altijd de externe domeinnamen in combinatie met een firewall die netjes aan NAT-loopback doet. Je hoeft dan geen split DNS te implementeren, maar je firewall routeert je in plaats van naar buiten netjes naar binnen.

dat is niet de meest efficiente oplossing. Al helemaal niet als je exchange CAS verkeer op die manier door je firewall heen pompt. Hoe groter de organisatie, hoe vervelender de inefficientie.

[downtime]

Mijn grootste bezwaar tegen fictieve TLD's zoals .local is dat er geen garantie is dat ICANN die TLD nooit "in de verkoop" gooit. Ik heb tenminste nooit documentatie kunnen vinden waarin .local officieel als gereserveerde TLD is betiteld. Nu is dat risico met .local niet zo groot, ze zullen (hopelijk) bij ICANN toch slim genoeg zijn om die niet vrij te geven, maar met andere TLD's kan dat best eens anders aflopen.

[ralpje]

Razwer schreef op vrijdag 13 juli 2012 @ 00:25:
[...]

dat is niet de meest efficiente oplossing. Al helemaal niet als je exchange CAS verkeer op die manier door je firewall heen pompt. Hoe groter de organisatie, hoe vervelender de inefficientie.

Je verkeer gaat niet door de firewall. Als je een DNS-lookup doet ziet de firewall het DNS-verkeer (of dat nou van je client of van je interne DNS-server die een forward doet komt) en rewrite het antwoord vervolgens naar het interne adres. Je uiteindelijke connectie wordt dus op het interne IP-adres gemaakt.

[Razwer]

ralpje schreef op vrijdag 13 juli 2012 @ 09:30:
[...]


Je verkeer gaat niet door de firewall. Als je een DNS-lookup doet ziet de firewall het DNS-verkeer (of dat nou van je client of van je interne DNS-server die een forward doet komt) en rewrite het antwoord vervolgens naar het interne adres. Je uiteindelijke connectie wordt dus op het interne IP-adres gemaakt.

Ik begreep het als dat je het beschreef als hairpinning, en als dat het zou zijn zou het wel degelijk door je firewall gaan (en weer terug).
random plaatje van google:

[ Voor 11% gewijzigd door Razwer op 13-07-2012 10:07 ]

[Paul]

wagenveld schreef op donderdag 12 juli 2012 @ 23:26:
Ik zie het probleem van split DNS niet helemaal. Ja, je moet even je www publieke IP in je interne DNS gooien, maar dat is toch geen probleem? Wij draaien gewoon bedrijf.com zowel intern als extern, geen centje pijn

Dat inderdaad

En een SAN-certificate is in veel gevallen ook niet nodig, in je (externe) DNS zet je een SRV-record naar net welk FQDN er op je certificate staat (bij ons vaak remote.bedrijfsnaam.nl) en je zegt tegen Exchange dat alle externe URLs 'remote.bedrijfsnaam.nl' zijn.

In je interne DNS een zone aanmaken 'remote.bedrijfsnaam.nl', IP van '(same as parent folder)' ('@' in Bind) naar je CAS en klaar

ralpje schreef op vrijdag 13 juli 2012 @ 09:30:
Je verkeer gaat niet door de firewall. Als je een DNS-lookup doet...

Hij heeft het over NAT loopback, niet over split-DNS? Bij mijn weten herschrijft de router het pakketje naar de nieuwe destination (NAT), het past niet de DNS-reply aan.

Dat kan ook niet, want een connectie is naar IP + poort, niet enkel naar IP. Als ik een portforward heb naar .1 en eentje naar .2, naar welk van de 2 moet de router mijn DNS-request dan ombuigen?

[ Voor 26% gewijzigd door Paul op 13-07-2012 10:14 ]

[Razwer]

Paul schreef op vrijdag 13 juli 2012 @ 10:10:

Hij heeft het over NAT loopback, niet over split-DNS? Bij mijn weten herschrijft de router het pakketje naar de nieuwe destination (NAT), het past niet de DNS-reply aan.

Dat kan ook niet, want een connectie is naar IP + poort, niet enkel naar IP. Als ik een portforward heb naar .1 en eentje naar .2, naar welk van de 2 moet de router mijn DNS-request dan ombuigen?

dus dat, hairpinning...
en mocht die firewall de records toch omzetten, is het alsnog split brain dns...

[ Voor 7% gewijzigd door Razwer op 13-07-2012 10:33 ]