1 Metadirectory's

Integratie

10/1 Metadirectory's Inleiding Inzake platforms zoals we die de dag van vandaag kennen zijn verschillende vormen van integratie mogelijk. We kunnen daarbij denken aan het gebruik van managementapplicaties voor het crossplatform en aan het integreren van gegevens, autorisaties en single sign-ons etc. In het recente verleden vormden de meeste softwareproducten van een bepaalde leverancier ‘eilanden’ om zodoende geen inmenging van derden te hoeven dulden. Tegenwoordig echter wensen de afnemers, organisaties en eindgebruikers steeds meer de integratie van de datastromen en samenwerking van de systemen die ze nodig hebben, zonder bijvoorbeeld telkens weer te moeten inloggen. Om een goed beeld te krijgen van de mogelijkheden kijken we nu eerst waaraan een directory moet voldoen en vervolgens wat Novell daar tot nu toe mee heeft gedaan.

10/1.1 Inleiding tot directory’s

Definitie

In deze bijdrage wordt de term ‘directory’ gebruikt, zoals die vooral in Amerika (ofwel in het Engelse taalgebruik) is ingeburgerd. In het Nederlands is ‘directory’ het best te vertalen met het woord ‘gids’, maar we willen niet puristisch doen en gebruiken gewoon het gangbare ‘directory’. Op de vraag naar de definitie van directory is en wat we ermee kunnen doen, krijgen we veelal uiteenlopende antwoorden. Volgens sommigen is een directory een simpele database met gegevens. Anderen beweren dat een

Novell Netwerkoplossingen, basiswerk

10/1.1-1

Metadirectory’s

directory alleen handig is voor een telefoonboek en af en toe horen we ook wel zeggen dat alle directory’s hetzelfde zijn als ze maar in een database gestopt worden die op enigerlei wijze benaderbaar is. In de praktijk blijkt een directory eerder een combinatie van de diverse antwoorden te zijn.

Hulpmiddel

Om de waarde van directory’s goed te kunnen inschatten, is het belangrijk in te zien dat directory’s niet alleen in computerland voorkomen. Er bestaan talloze directory’s die niks van doen hebben met de computer. Voorbeelden zijn het telefoonboek, een adressenlijst van familie, vrienden en kennissen in een agenda, enzovoort. Een mooi voorbeeld is ook de informatie over de indeling van de verschillende verdiepingen in de Bijenkorf, of de aanduidingen die we in een lift kunnen aantreffen. Dit zijn allemaal directory’s die we dagelijks gebruiken zonder te beseffen dat het directory’s zijn. In de meeste gevallen zijn deze directory’s een hulpmiddel om ‘iets te weten te komen’: een nummer opzoeken, bepalen waar men heen wil of moet. De directory voorziet ons van gerichte informatie om een adequate beslissing te kunnen nemen. Directory’s hebben dus al een hele weg afgelegd voordat we ze in hun huidige vorm leren kennen. De meeste bekende directory.

Ooit was het telefoonboek een ‘directory’ van telefoonnummers bestemd voor slechts enkele telefoonbezitters, tegenwoordig zijn er alleen in Nederland al vijftig (regio-) telefoonboeken. Door de veranderde technologische moge10/1.1-2


Integratie

lijkheden en mobiliteit is het toevoegen van plaats- en route-informatie eveneens belangrijk geworden om te vermelden. De dienst die hieruit, in een ‘gekoppelde webapplicatie’, voortvloeit, is dat we bij het opvragen van een telefoonnummer meteen relevante route-informatie kunnen krijgen. U ziet de directory dienst wordt steeds breder van opzet. Het computertijdperk De telefoon zorgde voor een revolutie op het gebied van communicatie en in de wijze van (samen)werken, min of meer onafhankelijk van de plaats waar iemand zich bevond. We zien nu dat deze functie langzamerhand wordt overgenomen door computers en webtechnologieën. Door de vrijwel onbeperkte schaalgrootte van het internet ontstaat, op diverse fronten, al snel een behoefte aan een directory – denkt u hier bijvoorbeeld aan de immense hoeveelheden webpagina’s, aan uw e-mail en ICQ. Deze behoefte is onderkend en een aantal initiatieven is ontplooid om een antwoord te bieden. Door de opkomst van elektronische berichtensystemen ontstaat de noodzaak een methode te creëren waarmee individueel kan worden geadresseerd. De X.400-standaard bijvoorbeeld was (uitsluitend) gericht op e-mailberichten. Geleidelijk aan kwamen initiatieven van de grond om ook aan de andere behoeften te kunnen voldoen. In 1988 is een belangrijke standaard voor de huidige directoryservice vastgelegd, namelijk de X.500-standaard van de International Telecommunication Union (ITU). Het doel van deze standaard is het creëren van een standaarddirectoryformaat dat kan worden gebruikt voor e-mailsystemen en andere technologieën die een directoryservice nodig hebben. Ondanks het feit dat de X.500 niet zo’n succes


10/1.1-3

Metadirectory’s

werd als de bedenkers ervan in gedachten hadden, was deze standaard wel zo volledig dat veel componenten ervan in de huidige directoryservices terugkomen. Drie basiscomponenten

De X.500-standaard identificeert de drie basiscomponenten van een directoryservice, namelijk • een client; • een toegangsmethode; • de directoryservice zelf.

Basis componenten van de X.500 standaard.

In de X.500-standaard worden de drie genoemde basiscomponenten achtereenvolgens Directory User Agent ofwel client, Directory Access Protocol ofwel toegangsmethode en één of meer Directory System Agents genoemd. Om een goed inzicht te krijgen in de werking van directory’s, behandelen we nu deze basiscomponenten. Client De definitie van een client is ‘een gebruiker van opgeslagen data uit de directory’. Meestal is het een computerprogramma op een pc dat gebruikmaakt van een directory zonder dat de gebruiker, degene die zich van het computerprogramma bedient, zich daarvan bewust is. Een goed voorbeeld is een centraal e-mailadressenbestand van alle medewerkers die een e-mailadres hebben. Applicaties zijn vaak de enige gebruikers die direct gebruik maken van een computer of systeemdirectory. In de netwerkinfrastruc-

10/1.1-4


Integratie

tuurwereld (Cisco, Lucent en bijvoorbeeld Nortel) zien we routers en switches steeds meer gebruik gaan maken van directory’s voor authentificatiedoeleinden. Policy’s over Quality of Service worden getoetst aan een directory. De standaard Directory Enabled Networking (DEN) wordt op dit moment bekeken door de Desktop Management Task Force (DMTF) en zal wellicht als dé standaard gaan dienen voor het leveren van deze integratie. Tendens

Juist op dit moment is ook een tendens gaande waarbij de informatie verdwijnt van de pc en overgaat naar PDA’s of, in de recente toekomst, naar slimme GSM-toestellen. Deze toestellen worden dan grootafnemers van directorydata, voor bijvoorbeeld telefoonnummers of e-mailadressen. Voor een wat groter bedrijf is het namelijk erg handig deze gegevens in een centrale directory als service aan elke werknemer te bieden, in plaats van deze gegevens door de werknemer zelf te laten invoeren. Het voordeel hiervan is dat het wijzigen van nummers dan centraal kan worden gecoördineerd. Ook de gewone kantoorautomatisering (tekstverwerking en spreadsheetprogrammatuur) kan profiteren van een directoryservice. Denkt u hierbij bijvoorbeeld aan centraal opgeslagen profielen, waardoor, met behoud van lay-out, plaats- en tijdonafhankelijk kan worden gewerkt. Toegangsmethode De toegangsmethode zou idealiter onafhankelijk moeten zijn van de keuze voor welke client. Het enige wat telt is dat de informatie die nodig is ook daadwerkelijk wordt verkregen. De toegangsmethode is de ‘deur’ naar de directoryservice.


10/1.1-5

Metadirectory’s

De toegangsdeur naar een directory service.

Access Protocols

Toegangsmethoden worden vaak ‘Access Protocols’ genoemd waarvan een groot aantal verschillende versies in omloop is. Niet alle directory’s ondersteunen echter alle protocollen. Veelal is het zo dat een directory alleen een specifiek voor de (directory)functie gemaakt protocol ondersteunt. De meeste directory’s van dit moment ondersteunen alleen het Lightweight Directory Access Protocol (LDAP), een afgeleide van het X.500 Directory Access Protocol. Dit LDAP-protocol wordt gepatroneerd door de Internet Engineering Task Force (IETF) en staat als een ‘Request for Comments (RFC)’ voor iedereen open om commentaar op te leveren of voorstellen voor verandering aan te dragen. Dit maakt het protocol tot een openbare standaard, wat erg handig kan zijn voor softwareontwikkelaars. Het is wel belangrijk dat we ons realiseren dat er eigenlijk niet zoiets bestaat als het ideale protocol waarin alle informatie kan worden gestopt. Een directoryservice moet dan ook openstaan voor zoveel mogelijk toegangsmethoden, en voldoende flexibiliteit ingebouwd hebben om toekomstige protocollen te integreren. Gezien de uiteenlopende behoeften van diverse platforms, met voorbeelden als ODBC, Suns Java en Microsofts Active Directory Service Interface en Novells XML, is het ingewikkeld tot een volledige directoryservice te komen. Alleen vertrouwen op het LDAP is dus niet voldoende voor een full-service directory.

10/1.1-6


Integratie

Vier hoofdcategorieën

Directoryservice De directoryservice zelf ten slotte is één van de belangrijkste onderdelen van alle componenten en is verantwoordelijk voor zaken als het definiëren van toegangsprotocollen, beveiligingsmethoden en het intelligent opslaan van data (fysiek opslaan of een referentielink opnemen naar een andere storageplaats). De directoryservice is ruwweg in te delen in vier hoofdcategorieën, namelijk (1) opslag, (2) beveiliging, (3) relaties en (4) discovery, die vervolgens elk weer subcategorieën hebben.

De full directory service.

Dit ‘Full Service Directory Model’ vult alle lagen van het OSI-model (opdeling van de verschillende netwerkfaciliteiten in 7 duidelijk afgebakende lagen: application, presentation, session, transport, network, datalink en physical layer) in en brengt de onderlinge relaties in kaart. Dit betekent geen implementatie, maar een beschrijving van


10/1.1-7

Metadirectory’s

elke netwerkcomponent, wat het moet doen en welke afhankelijkheden er onderling zijn. De waarde van een directoryservice Het is logisch de vraag te stellen: ‘wat is nu de toegevoegde waarde van een directoryservice en wie kan een directoryservice gebruiken?’ Het antwoord hierop is volgens Novell dat de waarde van de directory wordt gemeten door het aantal relaties die worden beheerd en het aantal nieuwe applicaties die nodig blijken te zijn als gevolg van directory-gebruik.

Directory’s creëren relaties.

Juist de mogelijkheid relaties te leggen tussen verschillende objecten geeft de full-service directory een voorsprong op de minimale directory’s, zoals e-mailadressengidsen. In plaats van ons te beperken tot één enkele databron kunnen meerdere bronnen voor verschillende

10/1.1-8


Integratie

informatiestromen worden benaderd, waaruit uiteindelijk het eindresultaat voortvloeit. Applicaties die gebruikmaken van een full-service directory zijn intelligente applicaties die gebruik kunnen maken van informatie opgeslagen in de directory. Zonder deze directory was de combinatie van informatie niet voorhanden was geweest. Omdat ook hardware gebruik maakt van een directoryservice, kan er intelligentere apparatuur komen. De full-service directory blinkt op een drietal gebieden uit ten opzichte van de minimale directoryservice, namelijk: • mogelijkheden; • hergebruik; • betrouwbaarheid. Mogelijkheden De mogelijkheden van een product zijn altijd van belang voor de keuze van een product. Meestal kiezen we op basis van specificaties en mogelijkheden voor een bepaalde oplossing. Bij een e-mailoplossing zal de kracht van het product niet liggen in de directoryservice zelf maar in de user-interface en de e-mailafhandeling. De directoryservice is daarbij van essentieel belang om het pakket te laten functioneren, maar niet het bestaansrecht van het product. Zaken als uitwisseling van gegevens met andere directory’s hebben waarschijnlijk niet erg hoog op de lijst van vereisten gestaan bij de softwareontwikkelaars. Deze oplossing voldoet dus aan het minimale directory-serviceprofiel. Bij een full-service directoryprofiel gaat het er juist om dat de oplossing is ontworpen met de directorygedachte in het achterhoofd. De oplossing is idealiter dus alleen een goed functionerende directoryservice en géén e-mailoplossing, databaseoplossing enzovoort. De directoryservice dient juist sterk te zijn in het leggen van onder-


10/1.1-9

Metadirectory’s

linge relaties tussen de verschillende producten. Hij dient als het ware als de lijm tussen diverse informatiestromen. Hergebruik Eén van de sterke punten van een full-service directory is de mogelijkheid data opnieuw te gebruiken. De meeste organisaties hebben allerlei bronnen met verschillende doeleinden waarin dezelfde data zijn opgeslagen.

Hergebruik van data tussen verschillende bronnen.

Ook voor de eindgebruiker (dat kan u ook zijn als netwerkbeheerder) zijn deze verschillende systemen zonder een full-service directory lastig, omdat voor elk systeem apart ingelogd moet worden, met wellicht steeds een ander userID en een ander wachtwoord. Daarbij komt dat de configuratie op elke locatie anders kan zijn. Door het gebruik van een full-service directory kan dit allemaal worden gecentraliseerd en ontstaan op deze wijze geheel nieuwe mogelijkheden en applicaties. Een voorbeeld van intelligent gebruik van de directoryservice is dat een gebruiker een ERP-applicatie (Enterprise Resource Planning) opstart waarbij de router (DEN-apparatuur) weet dat daar een

10/1.1-10


Integratie

minimale bandbreedte bijhoort, en deze direct beschikbaar stelt, zodat de applicatie optimaal functioneert. Zonder een full-service directory zou dit bijna niet te realiseren zijn. Door de uitwisseling van data kunnen de onderlinge relaties in kaart worden gebracht en aan elkaar verbonden. Betrouwbaarheid Op het moment dat steeds meer componenten deel gaan uitmaken van een directoryservice, worden de mate van toegang en de servicegraad van de directoryservice steeds belangrijker. De directoryservice is op dat moment immers een bedrijfskritische applicatie geworden, met alle bijhorende problemen in geval van downtime, en in een 24uurseconomie is downtime geen wenselijke situatie. De directoryservice is door alle onderlinge relaties en koppelingen het hart van de infrastructuur geworden en zonder deze service functioneert niets meer. In een goede fullservice directory is dan ook terdege nagedacht over fouttolerantie bijvoorbeeld, o.a. in de vorm van redundantie (dubbele uitvoering) of verwijzing naar een andere locatie. Een voorbeeld van fouttolerantie.

Deze risicospreiding en fouttolerantie is uiteraard een automatisch proces. De aanvrager van informatie merkt hier niets van en dat is een groot verschil met een minimale directoryservice, die meestal niet voorzien is van


10/1.1-11

Metadirectory’s

fouttolerantie of redundantie en als er iets mis gaat met de hand opnieuw moet worden geconfigureerd. De full-service directory dient altijd en overal beschikbaar te zijn, zodat alle bedrijfskritische applicaties erop kunnen vertrouwen. Samenvatting Een full-service directory moet vooral uitblinken in het leggen van relaties tussen verschillende informatiestromen en wordt steeds bedrijfskritischer als er meer informatie in wordt gestopt. Na deze theoretische inleiding in het onderwerp, bekijken we de ontwikkelingen van Novell op dit gebied.

10/1.1-12


Integratie

10/1.2 De ontwikkeling van eDirectory van Novell

NDS in de loop der jaren.

Toen Novell in 1985 begon met het uitbrengen van software was zij een belangrijke speler in de markt van netwerk-operatingsystemen. Het netwerk stond toen nog in de kinderschoenen en van standaardisatie was geen sprake. Iedere fabrikant bedacht zijn eigen protocol en standaarden. Integratie was nog lang niet in beeld. Het beheer van deze netwerken was dan ook lastig. Zoals eerder vermeld werd in 1988 de X.500-standaard vastgesteld. Novell speelde hier na enkele jaren op in met het uitbrengen van NetWare 4.0 in 1993. Hierin was voor het eerst de NetWare Directory Service (NDS) opgenomen, waarin Novell de goede punten van de X.500-standaard had opgenomen. Deze initiële versie was echter voornamelijk gericht op zaken die direct met een netwerk te maken hebben, zoals files, printen en andere netwerkservices. In deze begintijd werd er nogal wat gepionierd op het gebied van NDS en bijvoorbeeld het repliceren van data. Een flink aantal gebruikers was ontevreden over de 4.0-versie van NetWare, en beschouwde deze softwareversie met NDS als ‘buggy’. De meerwaarde van NDS moest zich nog bewijzen.


10/1.2-1

Metadirectory’s

Een stabiel operatingsysteem werd belangrijker gevonden dan NDS. Een groot gedeelte van de opgedane ervaring uit die tijdspanne zien we echter in de huidige producten terugkomen. Door de jaren heen zijn door Novell veranderingen doorgevoerd in de directoryservice. In 1998 werd bijvoorbeeld de eerste crossplatform-directoryservice geïntroduceerd, namelijk de nieuwe Novell Directory Service (NDS). De N van NetWare werd vervangen door Novell om aan te geven dat NDS niet langer afhankelijk was van NetWare-producten. Met deze versie is het mogelijk gebruikers op meerdere platforms te beheren.

SCADS-project

Fushion

10/1.2-2

Ondertussen was in 1997 een nieuw project door Novell opgestart, namelijk het SCADS-project (voluit: Scalable Directory Service). Het doel van dit project was het creëren van de meest schaalbare directoryservice ter wereld. Novell toonaangevend met NetWare besturingssysteem had namelijk grote concurrentie gekregen van de Windows NTserver en verloor. Een aanzienlijk marktaandeel (in de jaren ’80 80 tot 90 procent marktaandeel, in 2000 nog maar 17 procent) ging naar de concurrent Microsoft. Productontwikkeling was van het hoogste belang om nieuwe markten aan te boren. In dit project is de hele NDS inclusief de achterliggende database opnieuw ontwikkeld. In mei 1999 is het product onder de naam NDS8 op de markt geïntroduceerd. Deze softwareversie vormt nog steeds de basis van de huidige NDS directoryservice. In de winter van 1999 rondde Novell een intern project met de naam Fusion af waarbij alle code van NDS over de verschillende platforms heen gelijk werd getrokken. Dit noemen we volledige standaardisatie die platformonafhankelijk opereert. Vooral het beheer is hierdoor een stuk een-


Integratie

voudiger; patches zijn voor alle platforms gelijk. Inspelend op alle drukte rond e-business, kreeg het product ook een nieuwe naam, namelijk NDS eDirectory.

In the winter of 1999 Novell completed project Fusion. Fusion’s goal was to standardize the NDS code base across all platforms that NDS ran upon. By accomplishing this standardization, all patches made to one NDS platform can easily be made to other platforms and ensures that features are consistent across all platforms. This also marked the introduction of the new name of NDS eDirectory.

De verschillende benamingen van NDS Door al deze veranderingen en door de introductie van steeds weer nieuwe producten, is er in de markt nogal wat verwarring ontstaan. Wat is eigenlijk het verschil tussen NDS, NDS eDirectory en NDS Corporate Edition?

Platformonafhankelijk

Het verschil tussen NDS en NDS eDirectory is heel simpel te verklaren: er is geen verschil, ze zijn hetzelfde. De toevoeging eDirectory geeft aan dat het product platformonafhankelijk is en de naamgeving voornamelijk is ingegeven door marketingmotieven. NDS Corporate Edition is (om het makkelijk te maken) recentelijk weer van naam veranderd en heet nu NetWare Accountmanagement. NDS Corporate Edition is een service die draait bovenop NDS eDirectory om gebruikersaccounts van andere platforms, zoals Windows NT/2000, UNIX en Linux, te kunnen beheren.


10/1.2-3

Metadirectory’s

NDS corporate edition.

NDS Corporate Edition maakt het mogelijk een centraal punt van administratie te verkrijgen voor alle gebruikersbeheerhandelingen op de verschillende platforms. Samenvatting Sinds de introductie van de directoryservice in 1993 heeft Novell driftig gewerkt aan de ontwikkeling en dit heeft geresulteerd in een krachtige, crossplatformwerkende directory service. NDS eDirectory is de overkoepelende directory ofwel metadirectory van alle crossplatform directory services.

10/1.2-4


1 Metadirectory's

Recommend Documents