Van de week zat ik bij een klant die een veel voorkomend probleem had. Er was sprake van een gerelateerde maar externe partij die toegang nodig had tot interne applicaties, en de directeur had beloofd dat het gisteren af zou zijn. De architecten hadden aantal oplossingen aangedragen. Federation Services stond hoog op de lijst; dit betreft een open standaard om trust relaties te leggen op Web Service niveau middels certificaten. Op papier de ideale oplossing, maar met twee probleempjes: Federations Services is redelijk complex om te implementeren en vereist aanpassingen bij beide partijen, en de betreffende applicaties bleken niet of heel moeilijk werkend te krijgen met Federation Services. Kortom, niet gisteren gerealiseerd zoals ze zelf ook inzagen.
Een andere “oplossing” was om de externe partij accounts te geven in de interne AD, en toegang tot de applicatie te geven middels een Terminal Server farm of zelfs via een VPN. De beveiligingsproblematiek rond deze oplossing was wel vrij duidelijk. Het voorkeur scenario was een variant hierop: een nieuw forest (Extranet Forest) voor de nieuwe accounts, en een trust relatie met de bestaande AD. De lead architect had goed gezien dat er een interessant issue was met dit model: als de trust er eenmaal is dan heeft de Extranet gebruiker dezelfde rechten als Authenticated Users: effectief leesrechten in een groot deel van het productie forest. Zijn oplossing was simpel. We maken een groep waarvan alle Extranet users lid zijn, en geven die overal Deny rechten. Overal, vroeg ik? Ja, overal. Veel werk zeker? Ja, heel veel werk wel. Lastig te onderhouden ook? Ja, ook dat…
Toch is er een simpele oplossing, zei ik. Zet gewoon Selective Authentication aan. Toen viel het stil, al zaten er heel wat MCSE’ers in de zaal. Dus stapte ik naar het whiteboard om uit te leggen wat dit is.
Sinds Windows 2003 kennen we het concept van de forest trust: een transitieve trust relatie, waarbij alle domeinen in het trusted forest onder het trust bereik vallen. Waar “normale” external trusts gebaseerd zijn op het authenticatie protocol NTLM maakt een forest trust gebruik van Kerberos. Volstrekt analoog aan de transitieve internal trusts tussen domeinen in een forest zorgt Kerberos ervoor dat ook een inter-forest trust transitief is. Selective Authentication is een schakelbare eigenschap van een forest trust die in feite zegt: “voordat je met een computer mag authenticeren heb je daarvoor expliciete permissie nodig”. Kortom, standaard mag je nergens bij – precies het gedrag dat de klant zocht.
Tijdens het aanmaken van een forest trust door de wizard in Active Directory Domains & Trusts wordt je gevraagd of je Selective Authentication aan of uit wil hebben. Dit is overigens achteraf nog te wijzigen. Ik ga je hier niet vertellen hoe je een trust moet maken, maar ik laat je we zien hoe de properties van een forest trust eruit zien. In het volgende plaatje staat dat Selective Authentication aan staat. Het alternatief (Forest-wide authentication) is de default.
In dit voorbeeld heb ik een domein genaamd sol.local, en een server s1.sol.local met daarop de share genaamd Tools. Vanuit het andere domein (dat even naamloos blijft, want het heeft de naam van een klant…) kan je die share NIET zomaar benaderen, ook al heeft Everyone leesrechten. De foutmelding van Explorer is nogal algemeen:
Echter, als je hetzelfde probeert met een command prompt krijg je een veel aardiger foutmelding:
“Logon Failure, […] protected by Authentication Firewall, […] not allowed to authenticate.”. Dat geeft precies aan wat er aan de hand is: je mag niet eens proberen te authenticeren. Overigens, de Authentication Firewall is de oude naam van Selective Authentication zoals die in de beta’s van Windows 2003 werd gebruikt. Marketing heeft toen op het laatste moment ingegrepen en de naam veranderd – maar dat is niet overal gelukt.
Om gebruikers uit het trusted domain door de voordeur te laten geef je ze het recht “Allowed to Authenticate” op het computer account in Active Directory Users & Computers. In dit geval heb ik de Domain Admins van het andere domein dit recht gegeven. Vanaf dat moment gelden de gebruikelijke NTFS en Share rechten.
Met precies hetzelfde commando heb je nu wel toegang:
Kort samengevat is dit het punt. Bij een gewone trust mag iedereen overal bij tenzij je het dichtzet. Met Selective Authentication op een forest trust zeg je het omgekeerde: je mag helemaal nergens bij tenzij ik je toestemming geef om een bepaalde computer te gebruiken. Juist deze eigenschap is nuttig in een beveiligde omgeving zoals een Extranet. Nadat ik mijn verhaal had gedaan en in een lab had laten zien hoe het werkt heeft de betreffende klant de forest trust met Selective Authentication opgenomen in het project.
Meer om te lezen: