Kerberos, ticketing en impersonation. Waar ga ik beginnen? Want werk je in de ICT ben je er ongetwijfeld al eens tegenaan gelopen. Maar was er dat besef dat het hier om dit onderwerp ging toen de foutmelding naar voren kwam? En zo complex als het lijkt, zo eenvoudig kan het zijn als het een plekje heeft. Laat me je meenemen en beginnen met een voorbeeld:

We nemen Navision als voorbeeld. Stel je drukt in Navision op een knop welke een proces in de achtergrond start. De uitkomst van dit proces wordt weggeschreven naar de bestanden in een map. Niet spectaculairs, maar vanuit een beveiliging oogpunt wel. Wat hier feitelijk gebeurt is dat Navision de opdracht gaat verwerken namens de gebruiker die de opdracht heeft gegeven. Jij dus. Dit betekent dat iemand, in dit geval iets, zicht voordoet als iemand anders op het netwerk. Best bijzonder, want juist daarom werk je me Multi Factor Authenticatie. Om dit te voorkomen.

En er is nog een vraagstuk. Stel nu eens dat jij als gebruiker helemaal niet op die betreffende locatie mag schrijven via de verkenner. Dan zou dit impliciet via Navision wel mogelijk zijn. Puur omdat jij binnen Navision de opdracht “mag” geven? Je hebt rechten om dit proces te starten, maar is het logisch dat je daarmee ook alles mag wat nodig is om dit proces tot een succes te laten komen, ook wanneer daarmee acties worden verricht die je normaal niet mag? Nee dus.

En hier komt Impersonation om de hoek kijken. Wat er feitelijk gebeurt is dat onderliggend, door jou als gebruiker, een ‘kerberos ticket’ wordt afgegeven aan Navision. Een ticket uit jouw naam met de machtiging dat Navision bestanden namens jou mag klaarzetten.

Vanaf hier heb jij als gebruiker iemand een “machtiging” gegeven. Navision is gemachtigd om namens jou als persoon bestanden op te slaan. Wanneer Navision klaar is met het desbetreffende proces, dan wil deze de beloofde bestanden op de opgegeven locatie opslaan. Hiervoor gaat Navision naar de beheerder van het opslagsysteem, in deze de ‘file server’. Navision doet het verzoek de bestanden op te slaan als de betreffende gebruiker, jij dus.

En hier vallen de puzzel stukjes op zijn plek.

De ‘fileserver‘ ontvangt het verzoek van Navision om bestanden namens een ander op te slaan. De ‘fileserver’ wil echter wel zekerheid dat de gebruiker hiervoor Navision heeft gemachtigd. Gelukkig heeft hiervoor Navision eerder het ‘kerberos ticket’ verkregen. Dit ticket, welke alleen door de betreffende gebruiker kan worden gegenereerd, omschrijft de machtiging voor Navision. Dit ticket geeft aan dat Navision namens de gebruiker de bestanden op mag slaan op de ‘fileserver’.

Laten we deze stappen vertalen naar Kerberos, ticketing, impersonation.

Hoe weten we wie de gebruiker is? -> De aanmeld gegevens worden geverifieerd bij het eerste contact met, in ons voorbeeld, het Windows (Active Directory) Domein.
De Kerberos aanmelding wordt afgehandeld door het KDC (Key Distribution Center).

De gebruiker geeft een machtiging af -> Dit gebeurt via een ticket. Er wordt bij het centrale punt, de KDC, gevraagd om een speciaal ticket. Bestemd voor Navision, met als doel een opdracht namens de gebruiker te geven om bestanden op te slaan.
De aangevraagde machtiging wordt vertaald naar een kerberos ticket

Navision gebruikt de machtiging -> Navision verzoekt de fileserver om bestanden op te slaan namens de gebruiker. De fileserver wil weten of Navision dat mag, en derhalve wordt het Kerberos ticket gebruikt bij de aanvraag.
Navision overhandigt het verkregen ticket. Impersonation maakt het mogelijk dat Navision zich voor mag doen als de betreffende gebruiker.

De fileserver verifieert de machtiging -> Mag Navision zich inderdaad wel voordoen als een gebruiker? Navision heeft wel een ticket, maar mag deze zich ook inderdaad voordoen als een gebruiker. En als deze gemachtigd is, voor wat voor dienst is deze gemachtigd. Mailen is heel wat anders dan bestanden opslaan. Door dit te beperken tot alleen de benodigde rechten vindt een hoger beveiligingsniveau bereikt.
Er vind een controle plaats of het betreffende ‘service account’ van Navision gemachtigd is voor: ‘impersonation’. Zich voordoen als een gebruiker.
En dan nog de verificatie of deze machtiging inderdaad geldig is voor de gewenste actie. In deze dus bestanden opslaan.

Wat je hiermee voorkomt is dat een kwaadwillend stuk ‘code’ geïmplementeerd kan worden. Deze code zou ‘namens de gebruiker een mail kunnen sturen’. Dit gaat nu niet. Reden is dat er geen machtiging (kerberos ticket voor impersonation) is afgegeven om een e-mail te sturen. Wel om bestanden op te slaan, maar niet om te e-mailen.

In een dergelijke ‘setup’ wordt er ook wel gesproken over een 3-tier model.

• Tier1
  • Een gebruiker geeft de opdracht in de applicatie. Deze opdracht wordt doorgegeven aan Tier2 t.b.v. verwerking.
• Tier2
  • Verwerking laag. Opdracht vanaf de client wordt verwerkt op deze laag. Uitkomst wordt opgeslagen in de database.
• Tier3
  • Database opslag t.b.v. verwerkte data.

Uiteraard kan de applicatie vervangen worden door eenieder product. Exact welke CLIEOP bestaand klaarzet. Een Sharepoint pagina met een Webpart t.b.v. de (outlook) agenda weergave in de pagina. Webmail met een plug-in welke informatie leest/schrijft naar Sharepoint.