A- A A+

Featured

Twee weken geleden was het zo ver, een nieuwe versie van Joomla. Langzamerhand had deze site wel zo een beetje iedere versie vanaf 1.5 meegemaakt met als gevolg dat de boel aardig vervuild was, en veel enger, vol met  php code stond welke potentieel onveilig en was.   Tijd dus voor een drastische aanpak....

Lees meer.....

Windows 10 is nu enkele weken officieel uit en het marktaandeel van Windows 10 begint langzamerhand te groeien. Microsoft positioneert Windows 10 als opvolger voor alle cliënt desktop systemen waaronder Windows XP, Vista, 7, 8 en 8.1. Daarnaast zal Windows 10 later dit jaar de opvolger worden voor Windows Phone 8/8.1. Dit review beschrijft de upgrade naar Windows 10 en de eerste ervaringen met dit OS. Het is moeilijk om een cijfer of waardering te geven op basis van 22 dagen intensief gebr...

Lees meer.....

Gisteren had ik een script nodig van mijn site. Dus ik laad mijn site en wat zie ik, woorden als "V1agra" en andere rare uitingen met links. Het eerste wat ik dacht is "What the f...". En toen bedacht ik me. Ik heb een backup. Dus het eerste wat ik deed was, de site off-line halen, maar mijn joomla admin page was kapot. Dus inloggen op mijn vps en toen zag ik het al, robots.txt aangepast, andere google id file. Et cetera. Dat was dus gepast schrikken. Mijn grootste fout, maar...

Lees meer.....

Geen private TLD's meer in Publieke Certificaten vanaf november 2015

In november 2015 zullen alle publieke certificaat aanbieders geen certificaten meer uitgeven voor foutieve domeinnamen. Hierbij gaat het om domeinnamen zoals .corp, .local etcetera. Dit om meerdere redenen, waaronder een stuk beveiliging omdat deze namen door meerdere bedrijven gebruikt worden en het niet mogelijk is om de hele certificaat keten met zekerheid te valideren.

Voor meer informatie kan je de volgende links lezen:

http://www.digicert.com/internal-names.htm
http://www.networking4all.com/en/ssl+certificates/faq/change+san+issue/

Het officiele standpunt luidt als volgt en heeft voor u als techneut een aantal implicaties....

The reden voor deze wijziging is dat de interne servernamen niet meer uniek zijn en eenvoudig te vervalsen zijn. Met generieke namen zoals webserver01, webmail, portaal, is het voor de eindgebruiker nooit zeker of hij een verbinding op zet met een goede partij of met een partij met kwade bedoelingen.
De verandering in het legalisatie proces van SSL Certificaten zal starten op 1 november 2015. Dit houdt in dat, vanaf deze datum, de niet valide Fully-Qualified Domain Names (ookwel bekend als FQDNs) niet meer geaccepteerd worden binnen de standaard van het CA/Browser Forum en dat dergelijke certificaten niet langer worden uitgedeeld. Alle certificaten welke zijn uitgedeeld met foutieve/illegale FQDN's na 1 november 2015 zullen bij gebruik worden revoced bij ontdekking en afhankelijk van software implementatie bij gebruik.
Gebruikers met een illegale FQDN zullen er rekening mee moeten houden dat alle certificaten na 1 november 2015 niet meer zullen werken ook al is deze voor deze datum vrijgegeven. Na deze datum, geen SAN SSL Certificate met een gereserveerd IP address of met een interne servernaam zal worden toegekend.

Voor meer informatie over basiseisen kunt u hier kijken: http://www.cabforum.org/Baseline_Requirements_V1.pdf

Wat gaat dit betekenen

Wanneer je een domein in gebruik hebt met een foutieve naam (.local, .corp) kan je tegen een aantal issues aanlopen, afhankelijk van de configuratie. In de meeste gevallen heeft dit invloed op applicaties zoals Microsoft Exhange en Microsoft Lync servers.

Jaren lang worden er certificaten gebruikt welke het toestonden om interne servernamen aan interne fqdn's te koppelen tezamen met publieke fqdn's. Dit maakte het eenvoudig om 1 certificaat te gebruiken voor zowel intern als extern met alle voordelen van dien. Doordat dit op 1 november 2015 niet meer kan is het mogelijk dat er veel Exchange, Sharepoint, Citrix en Lync omgevingen aangepast moeten worden en zelfs opnieuw ontworpen moeten worden.

Afhankelijk van de configuratie dienen er in de infrastructuur een aantal wijzigingen doorgevoerd te worden om deze wijziging te ondersteunen. We kunnen deze wijziging onderverdelen in de volgende:

1- Uw Active Directory domein naam is <domein>.nl of een andere valide domeinnaam:

Wanneer uw interne Active Directory domein een valide naam heeft, bijvoorbeeld vanderwaals.nl (zoals in mijn geval), dan zijn de wijzigingen minimaal. Het enige probleem is wanneer er voor gebruikers eenvoudige namen gebruikt worden zoals, https://mail, https://webmail, https://owa, https://citrix etcetera. Deze zullen niet meer werken. Er zullen dus normale certificaten gebruikt moeten worden met identieke namen, zoals https://webmail.<bedrijf>.nl, of https://citrix.resources.<mijnbedrijf>.nl. Dit is meer een probleem voor de eindgebruiker dan voor de IT organisatie.

2- Uw active Directory domein naam is een valide naam maar niet de uwe:

Dit is een nachtmerrie situatie, en zij die het zagen gebeuren lachen u toe en wensen u veel succes. Dit soort situaties ontstaan bijvoorbeeld wanneer uw bedirjf heeft besloten om een TLD te gebruiken welke tot heden geen officiële was. Zoals bekend is, is het mogelijk om eigen TLD's aan te vragen (zie http://tld.name/register-your-tld.php). Stel u heeft een bedrijf, bijvoorbeeld "Automobiel Dealer Amsterdam Marinehaven" en u heeft uw interne domein kantoor.adam. genoemd. Nu gaat de gemeente Amsterdam de TLD adam. registreren. In dit geval kan je je Active Directory Domein hernoemen want het is een tijdbom tot iemand anders je interne TLD publiekelijk gaat registreren. Kortom komt dit neer op je hele infrastructuur opnieuw bouwen. De consultant/beheerder/beslisser welke dit heeft verzonnen is een .........

3- Uw Active Directory domein naam is domein.corp (of andere foutieve naam zoals domein.local): 

In deze situatie zul je je hart op kunnen halen en je zal veel plezier beleven. Met name in combinatie met Exhange en de wijze waarop Exhange omgaat met Interne en Externe URL's. In deze gevallen is het meer dan alleen een ander certificaat.

oooh baby, you will have fun, because of how internal and external URLs in Exchange are functioning you will need to do more than just a new certificate request for your servers, but again it depends on how you configured your Exchange servers:

Voor Microsoft Exchange heeft situatie 3 een aantal opties.

Voor een single Active Directory site omgeving:

Wanneer je Interne URL's voor de Exchange Webservices Publieke namen gebruiken, dan ben je met Exchange veilig. Dat geldt ook voor Microsoft Lync adressen overigens. Maar wanneer je Interne URL's voor Exchange private namen zijn dan heb je een aantal oplossingen:

  • Verander de interne namen van de Virtual Directories dermate dan ze de publieke domein namen bevatten (.nl bijvoorbeeld), dit zal betekenen dat de correcte DNS zones in de Active Directory aangemaakt moeten worden. En map de server namen in deze zone naar de juiste IP adressen (Split DNS configuratie, externe DNS wijst naar externe IP adressen, interne DNS wijst naar interne IP adressen), neem als hostnaam een CNAME op met exact de zelfde naam als de externe naam. Bijvoorbeeld webmail.<bedrijf>.nl, autodiscover.<bedrijf>.nl etcetera. En gebruik 1 certificaat voor zowel intern als extern.
  • Maak een nieuwe Website voor Exhange (of meerdere) met eigen IP adres(sen). Maak eveneens een Split DNS aan en migreer de omgeving naar deze nieuwe namen. Binnen Exc hange Powershell zijn er tevens veel applets beschikbaar om zaken te corrigeren en de gehele communicatie binnen Exchange goed te laten verlopen. In het beste geval configureer je Exchange dermate dat alles een valide FQDN gebruikt en gebruik je overal een valide Publiek certificaat voor.
  • Controleer ook de Externe namen en de bijbehorende certificaten om issues te voorkomen.

Voor een multi-domein Active Directory omgeving:

Ook dit is afhankelijk van de configuratie en het grootste probleem zit in de redirection en proxy architectuur binnen Exhange 2010 en Exchange 2013. Ik heb het een beetje vereenvoudigd maar er zijn te veel situaties en configuratie mogelijkheden om een simpele beschrijving te maken. Maar hier volgen een aantal kleine tips:

  • Documenteer je OWA en webservices configuratie en inventariseer hoe het proxy en redirect verkeer loopt en is geconfigureerd.
  • Inventariseer alle externe namen en bijbehorende certificaten, controleer deze en zorg dat deze goed zijn (voldoen aan de eisen en de omgeving).
  • Interne namen dienen stap voor stap omgebouwd te worden, sommige vereisen compleet nieuwe Web-services, gebruik valide namen en belangrijk, zorg voor de juiste publieke certificaten. Werk met Split DNS om alles recht te trekken zoals eerder beschreven.
  • Interne namen welke niet aangepast worden dienen eigen IP adressen te krijgen met eigen Web services, eventueel dienen nieuwe Self Signed certificaten aangevraagd te worden.
  • Controleer binnen de omgeving de InternalNLBBypassUrl, het advies is om deze niet te wijzigen en de interne servernaam te handhaven. En wanneer je een proxy gebruikt tussen de sites, dan zal hiervoor een nieuwe Web-service site gemaakt moeten worden.
  • Werk top-down, stap voor stap, niet in een keer alles omzetten. Pas een onderdeel aan, test deze, en doe de volgende stap.