Eindwerk: Linux Active Directory Emulatie

Transcriptie

1 1 Synopsis titel: Linux Active Directory Emulatie auteur: Steve Weemaels, Johan Huysmans, Dimitri Redant promotor: Dhr. Joeri Gerrits Dit project baseert zich op de Microsoft Active Directory, dat een logische laag vormt boven het fysieke netwerk. Het is de bedoeling dat Windows gebruikers zich kunnen authenticeren op een Linux systeem dat intern op dezelfde logische manier werkt als de Microsoft Active Directory. De drie voornaamste services die hiervoor gebruikt worden zijn: Samba, Openldap en DDNS. Samba zorgt voor de communicatie met de windows machines en voor het delen van bestanden, Openldap zorgt voor de interne organisatie van gebruikers, groepen en computers terwijl DDNS (Dynamic DNS) ervoor zorgt dat de windows machines de Openldap server kunnen terugvinden m.b.v. queries en zichzelf kunnen bekendmaken in het naamgevingsysteem. De installatie van het systeem kan volledig grafisch gebeuren dankzij onze JAVA INSTALLER. De samenwerking van de drie services kan beheerd worden door onze JAVA GUI tool. Naast onze JAVA software en de bovengenoemde services, werd er eveneens veel aandacht besteed aan beveiliging. Enerzijds is er de TLS beveiliging dat ervoor zorgt dat de gegevens tussen Samba en Openldap versleuteld worden, anderzijds is er beveiliging tegen servercrashes. Dit laatste gebeurt door replicatie. Het is mogelijk om 2 systemen synchroon te laten lopen. Dit betekent dat als het ene systeem crasht, het andere systeem de taak overneemt. Als conclusie kunnen we stellen dat het mogelijk is een goed werkend directorysysteem op te zetten voor windows machines. Echter is het niet mogelijk om een exacte kopie van de Microsoft Active Directory na te bouwen. Dit komt vooral door het feit dat Microsoft weinig informatie vrijgeeft over hun systeem.

2 2 Inhoudstafel 1. Inleiding Wat is Active Directory Een korte beschrijving van de onderdelen Samba Openldap DNS Openldap als Samba backend Configuratie van Openldap als Samba backend DNS Configuratie van de Named server Secondary DNS Dynamic DNS Microsoft Domain Controller en Linux DNS server NETBIOS vs. DNS Samba en Name servers Automatisatie RPM installatie script ACL's Implementatie Besluit Policies Poledit De werking Modes ADM bestanden Zwakheden Test Conclusie Nitrobit Group Policy Prijskaartje Conclusies Beveiliging Kerberos Werking Terminologie Pogingen om Kerberos te integreren in ons eindwerk Hoe zijn we te werk gegaan...32

3 TLS/SSL Werking Hoe zijn we te werk gegaan Conclusie Replicatie Werking Configuratie De analyse en programmatie van de software JNDI Het Java object zelf opslaan Een referentie naar het object opslaan De informatie als attributen opslaan Analyse De use case Programmatie van de software Connectie maken Gebruikers toevoegen, aanpassen en verwijderen Groepen toevoegen, aanpassen of verwijderen Computers verwijderen OU's aanmaken en verwijderen Elementen toevoegen of verwijderen aan/uit een OU SambaUser SambaGroup SambaOU Services De grafische userinterface Installer De Grafische tool Services Gebruikers Groepen Computers Ou Gelijkaardige Projecten Samba Novell edirectory Suse Linux Enterprise Server Besluit Bijlage en literatuurlijst...77

4 4 1. Inleiding Tegenwoordig staat de opensourcewereld niet meer in zijn kinderschoenen. Er zijn heel wat applicaties beschikbaar die kwalitatief even hoogstaand zijn als commerciële software. Een verwijt dat de opensource wereld echter vaak te horen krijgt, is dat het geen waardige vervanger heeft van de Microsoft Active Directory. Dit is wat we met ons eindwerk proberen te bereiken. Het systeem moet de voordelen hebben van de Microsoft Active Directory en volledig bestaan uit opensource software. Daarnaast is het niet enkel de bedoeling dat we een kant en klaar product afleveren, we vinden het delen van informatie even belangrijk. Daarom dat de bijlage bestaat uit zo'n 100 pagina's aan howto's en beschrijvingen van de gebruikte technologieën. Als taal voor onze beheersoftware wordt java gebruikt, aangevuld met enkele perl scripts. De software analyse wordt synchroon gedaan met het onderzoek naar de directoryservices. De gekozen linux distributie is Fedora Core 3. Deze keuze werd gemaakt omdat deze distributie heel dicht ligt bij de Redhat server. Ons eindwerk zou in principe ook bruikbaar moeten zijn voor alle andere distributies zoals Debian, Slackware, Gentoo,... Er valt wel aan te merken dat de plaats van de configuratiebestanden soms verschilt van distributie tot distributie.

5 5 2. Wat is Active Directory Als men het doel van ons eindwerk wil begrijpen, is het nodig dat men eerst even een kijkje neemt in de Microsoft Active Directory. Hoewel we om correct te zijn moeten spreken over Directory Services, zullen we in dit verslag vooral Active Directory vermelden, aangezien dit de implementatie is waarop we ons baseren. Op zich is de Active Directory niets anders dan een logische voorstelling van een fysisch netwerk. Active Directory kent geen routers, kabels, switches, netwerkkaarten en dergelijke. Het is een volledig logische onderverdeling van gebruikers en computers in groepen en units. Het kan best zijn dat 2 computers die geografisch gezien ver van elkaar liggen, samenhoren in één logische groep. Het grote voordeel hiervan is dat men een volledig gecentraliseerd systeem krijgt. Als men bepaalde instellingen doet op een Unit, worden deze instellingen toegepast op elk lid van de Unit. De onderstaande figuur is de Microsoft voorstelling van hun Active Directory. Verder is het ook zo dat de Microsoft Active Directory nog vele andere toepassingen bezit zoals replicatie, VPN (Virtual Private Network), en dergelijke. Deze zaken zijn volgens ons geen vast onderdeel van een directory service, maar aangezien we ook een volledig geïntegreerd systeem willen samenstellen, worden sommige van deze toepassingen ook geïmplementeerd in onze Linux Active Directory Emulatie.

6 6 3. Een korte beschrijving van de onderdelen 3.1. Samba De term Samba slaat op het SMB protocol van Microsoft dat geïmplementeerd werd onder Unix systemen. Het voornaamste doel daarvan is het delen van printers en directories alsook het verzorgen van gebruikersauthenicatie Openldap Openldap is een Unix service dat net zoals samba, volledige gebruikers authenticatie kan verzorgen. Daarnaast heeft het als grote voordeel dat men kan gaan werken met organizational units en dat men op de objecten heel wat attributen kan gaan toevoegen die de objecten beschrijven. Mogelijke attributen kunnen zijn: employeenumber, Address, homedirectory, DNS Hoewel Samba al kon voorzien in een naamservice, werd toch besloten om DNS te gaan gebruiken. Dit heeft 2 redenen. De eerste reden is omdat Windows 2000 systemen gebruik maken van DNS queries om de LDAP server te localiseren. De tweede reden is omdat DNS zo goed als synchroon georganiseerd is met LDAP. Dit valt duidelijk op te maken uit onderstaande illustratie.

7 7 4. Openldap als Samba backend Het is duidelijk uit voorgaande hoofdstuk dat zowel Samba als Openldap beperkingen hebben. Openldap heeft als grote beperking dat het op zich geen windows clients kan authenticeren terwijl Samba als grootste beperking heeft dat het niet de uitbreidbaarheid van Openldap heeft. Dit probleem wordt opgelost door Openldap als backend te laten fungeren voor Samba. In plaats van een Samba database waar alle gebruikers in opgeslagen worden, zal een hier Openldap database gebruikt worden. Elk onderdeel in de LDAP tree heeft zijn eigen naamconventie. De domeinnaam wordt bijvoorbeeld beschreven als: dc=pinguin, dc=be. Dc staat voor Domain Component. De administrator wordt beschreven als: uid=administrator,ou=users,dc=pinguin,dc=be. Dit heet de Distinguished name (DN) en is in zekere mate vergelijkbaar met een DNS FQDN (Fully Qualified Domain Name). Onderstaande tabel maakt een vergelijking tussen de naamconventie van LDAP en deze van Microsoft Active Directory: LDAP Microsoft Active Directory cn = common name cn = common name ou = organizational unit ou = organizational unit o = organisation dc = domain component c = country n.a. De beschrijving van een object is steeds van beneden naar boven. vb: o=pinguin.be ou=people ou=machines uid=jeff uid=patrick

8 8 De distinguished name van Jeff is in dit geval: uid=jeff,ou=people,o=pinguin.be. De organisatie o=pinguin.be zou in Microsoft Active Directory dc=pinguin,dc=be zijn. Een minimale database voor Samba in Openldap ziet er uit als volgt: Deze screenshot werd genomen vanuit java ldapbrowser, een open source programma dat met de meeste varianten van LDAP kan communiceren. De LDAP databank bevat standaard 3 organizational units. Eén voor gebruikers, één voor groepen en één voor computers. Op de screenshot worden de attributen van het Administrator object getoond. De precieze betekenis van alle attributen wordt later in het verslag besproken.

9 Configuratie van Openldap als Samba backend Eerst en vooral moet het juiste schema gebruikt worden. Een schema is een soort blauwdruk van hoe de databankstructuur eruit ziet, vergelijkbaar met schema's in XML. Dit schema heet samba.schema en moet zich bevinden in de schema directory van openldap: /etc/openldap/schema. De volgende stap bestaat vooral uit configuratie van bestanden. Zo worden de bestanden: /etc/nsswitch.conf, /etc/openldap/ldap.conf, /etc/openldap/slapd.conf, /etc/ldap.conf en /etc/sysconfig/authconfig aangepast aan onze noden. Een domeinnaam, managerpaswoord en restricties worden ingesteld. Een handige tool dat redhat levert is: authconfig. Deze tool stelt de bestanden in zodat de gebruiker dit niet manueel moet gaan doen. Eén van de belangrijkste bestanden is slapd.conf. Daarin staan volgende belangrijke parameters ingesteld: include /etc/openldap/schema/samba.schema access to attrs=userpassword by self write by anonymous auth by dn="cn=manager,dc=pinguin,dc=be" write by * none access to attrs=sambalmpassword,sambantpassword by self write by dn="cn=manager,dc=pinguin,dc=be" write by * none access to * by * read De eerste regel geeft aan dat het sambaschema gebruikt wordt. De regels daaronder stellen de permissies in voor de gebruikers van het domein pinguin.be.

10 10 Het bestand /etc/nsswitch.conf dient om te specificeren in welke databases de hosts, gebruikers, paswoorden en groepen opgeslagen worden. Hier voegen we LDAP toe als volgt: passwd: files ldap shadow: files ldap group: files ldap ldap protocols: files ldap Een redhat specifiek bestand is /etc/sysconfig/authconfig. Hierin wordt het type van de authenticatie in vermeld. De parameter USELDAPAUTH moet hier op yes komen te staan. USECRACKLIB=yes USEDB=no USEHESIOD=no USELDAP=yes USENIS=no USEPASSWDQC=no USEWINBIND=no USEKERBEROS=no USELDAPAUTH=yes USEMD5=yes USESHADOW=yes USESMBAUTH=no USEWINBINDAUTH=no

11 11 Onze Sambaserver zal beschikken over de volgende eigenschappen: Samba is een PDC Samba haalt de gebruiker en groepgegevens uit de LDAP database Gebruikers zullen hun profielen opslaan op deze server. Het instellen van Openldap als backend gebeurt als volgt in het samba configuratiebestand: passdb backend = ldapsam:ldap:// ldap suffix = dc=pinguin,dc=be ldap machine suffix = ou=computers ldap user suffix = ou=users ldap group suffix = ou=groups ldap idmap suffix = ou=users ldap passwd sync = Yes admin users Domain Admins ldap admin dn = cn=manager,dc=pinguin,dc=be Ldap passwd sync betekent dat als een gebruiker zijn paswoord verandert, SambaNTPassword, SambaLMPassword ook veranderen. Ook het attribuut pwdlastset zal geupdated worden. Het zorgt m.a.w. voor een synchronisatie tussen Openldap en Samba. Eén van de moeilijkste zaken is het vullen van de Openldap database met de noodzakelijke gegevens. Gelukkig zijn op het internet enkele opensourcetools beschikbaar die deze taak wat vereenvoudigen. Deze tools heten: SMBLDAP TOOLS en bestaan uit allerlei perl scripts dat functies zoals gebruikers toevoegen en verwijderen, de databank vullen, gebruikers in groepen steken, enz... vervullen. Men kan hun werking vergelijken met de unixcommando's: useradd, userdel, usermod, groupadd, groupdel, groupmod en passwd. De instellingen van deze tools worden in het bestand / etc/smbldap tools/smbldap.conf ingesteld. Daarin kan men onder andere het poortnummer, de locatie van SSL certificaten, de default map voor homedirectories,... instellen. De tools geven ons een exact idee van hoe we moeten omgaan met de LDAP databank. Later in ons project worden deze tools omgezet in java code en toegevoegd aan het framework.

12 12 5. DNS Het Domain Name System wordt niet enkel op het internet gebruikt, maar kan ook op lokale netwerken handig zijn. Zo kan men een interne server een dns naam geven zodat de gebruikers niet telkens het IP adres van deze server moeten invoeren. Een Windows Domain Controller is sterk afhankelijk van de DNS server, hierdoor werd het nodig geacht om de verschillende aspecten van de DNS server te onderzoeken Configuratie van de Named server De configuratie bestaat uit verschillende bestanden, het belangrijkste bestand is /etc/named.conf. Hierin worden al de instellingen gemaakt en wordt verwezen naar de verschillende zonebestanden. In deze bestanden kan men de vertaling van hostname naar IP adres en omgekeerd terugvinden. Het named.conf bestand kan voor de eenvoud in 3 delen worden opgedeeld. Het eerste deel zijn de opties. Hier worden de algemene instellingen gemaakt. Er zijn een groot aantal opties mogelijk, in het configuratiebestand worden enkel deze gebruikt die we echt nodig hebben. Het tweede deel bevat de zone definities. Standaard zijn er 5 zones. De root zone, hierin staan de 13 root name servers gedefinieerd. In de localhost en in addr.arpa zone wordt de naam localhost gekoppeld aan en omgekeerd. Deze 3 bestanden zijn overal gelijk. In de pinguin.be en in addr.arpa zone worden de hosts gedefinieerd op het netwerk. In het bestand pinguin.zone worden de hosts omgezet naar hun IP adres, in het bestand in addr.arpa.zone worden de IP adressen omgezet naar de juiste FQDN (DNS naam).

13 13 Het derde deel is optioneel, het bevat informatie over het loggen. Als men geen gebruik maakt van logging zal de informatie terecht komen in de /var/log/messages file. Via het logging gedeelte kan men 3 bestanden aanmaken om zo de informatie te sorteren. De algemene informatie wordt in het bestand named.log gezet, de uitgevoerde queries in het bestand queries.log en informatie over de updates worden in updates.log geplaatst. Men kan zelf bepalen wat er juist gelogd wordt in welke bestanden, men kan dan ook nog enkele opties bepalen per bestand, zoals o.a. het aantal bestanden, hoe groot elk bestand mag worden en of er een tijd moet afgedrukt worden. De verschillende zonebestanden hebben ongeveer dezelfde structuur, één uitzondering hierop is de named.ca file (root zone). Elke zone bevat een SOA (Start of Authority) waarin de serial en refresh tijden worden gedefinieerd, elke zone bevat ook een NS (Name Server) record waar de name servers worden gedefinieerd voor dat domein. In een zone file kan men ook een A (Address) of CNAME (Canonical Name) record terugvinden. De A zet een naam om naar een IP adres, met CNAME maakt men een alias. In de reverse lookup zone maakt men geen gebruik van A en CNAME maar van PTR (Pointer) dit zet een IP adres om naar een FQDN (Fully Qualified Domain Name). De gemaakte configuratie kan op fouten gecontroleerd worden door 2 hulpprogramma's: named checkconf controleert de named.conf file op syntax fouten, named checkzone checkt een bepaalde zone file op syntax en integriteitsfouten. Bij het starten van de named server worden deze controles ook uitgevoerd. Om een werkende server te testen kan men gebruik maken van één van volgende 3 hulpprogramma's: nslookup (is ook beschikbaar voor windows), host en dig.

14 Secondary DNS Een synoniem voor secondary DNS is backup DNS. De secundaire DNS server zal altijd dezelfde informatie bevatten als de primaire DNS server, na een bepaalde tijd zal het zonebestand gekopieerd worden van de primaire naar de secundaire DNS server. Als één van beide servers niet meer beschikbaar is kunnen de clients requests uitvoeren naar de andere server. Om dit te bekomen moet op beide servers iets aangepast worden. Op de primaire DNS server moet men transfers toelaten. Dit doet men door de optie allow transfer toe te voegen bij de zones die men beschikbaar wilt stellen voor de secundaire DNS server. Op de secundaire DNS server gaat men bij de bepaalde zone vermelden dat dit van het type slave is, alsook via de optie masters aanduiden waar de primaire DNS server zich bevindt. Als beide servers herstart worden zal onmiddellijk die bepaalde zone kopieerd worden naar de backup server Dynamic DNS Een dynamic DNS zorgt ervoor dat één of meerdere clients zelf records kunnen toevoegen of verwijderen uit de DNS server. Als men een dynamic DNS server instelt zullen zowel de Windows als Linux clients hun naam kunnen registreren. Het omzetten van een gewone DNS server naar een dynamic DNS server gebeurt door het toevoegen van één regeltje per zone. Bij de zones die men dynamic wilt maken moeten men de optie allow update toevoegen. De gemaakte updates zullen niet eeuwig beschikbaar zijn maar zullen verwijderd worden als de Time to live is verstreken.

15 Microsoft Domain Controller en Linux DNS server Bij de installatie van een Domain Controller moet een DNS server geïnstalleerd worden, ofwel kan de DNS server van microsoft gebruikt worden ofwel een andere server. Om zoveel mogelijk van de werking van de DNS bij een Domain Controller te weten te komen werd gekozen om de Windows Domain Controller te laten samenwerken met de Linux named server. Als eerste werd de named server geconfigureerd. Enkele zaken moesten juist ingesteld worden voor een goede werking. Zo moest er een zone beschikbaar zijn met dezelfde naam als de domeinnaam. Die zone moet dynamic zijn, de optie allow update moet dus toegevoegd worden. Vanop de Domain Controller moet deze DNS server beschikbaar zijn en dus queries kunnen uitvoeren. Bij het uitvoeren van dcpromo, het commando om onder windows server de Active Directory op te zetten, wordt gevraagd naar de volledige DNS naam, dit is de naam van de zone die eerder werd gedefinieerd. De installatiewizard zal dan op zoek gaan naar de DNS server (degene die is ingesteld bij windows IP settings), als hij deze gevonden heeft wordt ook getest of hij updates kan uitvoeren. Als de installatie voltooid is en de computer herstart, zullen er bij het booten al de nodige records worden toegevoegd. Al deze toegevoegde records kunnen verdeeld worden in 4 subzones, namelijk: _msdcs, _sites, _tcp en _udp. Binnen deze 4 subzones komen er 4 SRV records regelmatig terug, namelijk: _ldap, _kerberos, _kpasswd, _gc. Deze DNS structuur van een DC kan weergegeven worden als een boomstructuur, deze ziet er als volgt uit:

16 16

17 17 Dit zijn héél wat records, waarvan er veel niet gebruikt worden. Zo zijn er records bij die enkel gebruikt worden wanneer er verschillende sites gedefinieerd zijn. In de lijst vind men 2 keer een 128bit nummer, deze worden enkel gebruikt als het domein hernoemd wordt. Tussen al de SRV records zitten ook enkele A records, deze zijn bedoeld voor clients die geen gebruik kunnen maken van de SRV records. Als we kijken naar de queries dat uitgevoerd worden bij het starten en inloggen van een windows client zal men zien dat enkel naar deze record wordt gezocht: _ldap._tcp.dc._msdcs.pinguin.be 5.5. NETBIOS vs. DNS NETBIOS (Network Basic Input/Output System) is de oude manier dat door Windows wordt gebruikt voor name resolution. De nieuwe manier is name resolution via DNS. Vanaf Windows versies 2000/XP is het mogelijk om NETBIOS over TCP/IP uit te schakelen en is het enkel nog aanwezig voor backwards compatibility. Op de netwerken waarbij NETBIOS is uitgeschakeld is het dus noodzakelijk om een (D)DNS server te hebben. In een NETBIOS netwerk zal er altijd een WINS (Windows Inter networking Name Server) server zijn, indien deze niet gekend is zullen de clients werken met UDP broadcasts om hun naam bekend te maken. In het andere geval wordt de naam direct bij de WINS server geregistreerd. Als er nog geen WINS server aanwezig is, zal één van de machines automatisch WINS server worden. Als men zelf de WINS servers aanmaakt moet men er op letten dat er geen 2 WINS servers zijn op hetzelfde netwerk. Doordat DNS gebruikt wordt op het wereldwijde Internet, is op de meeste computers DNS dan ook beschikbaar. De Windowsversies 2000/XP en hoger kunnen hun hostname registreren bij een Dynamic DNS server, zodat de pc zelf bekend is in het netwerk. Dit komt dus overeen met het principe van NETBIOS.

18 Samba en Name servers In het configuratiebestand van samba kan men enkele wijzigingen aanbrengen zodat deze gebruik gaat maken van de DNS server. Het is mogelijk het gebruik van NETBIOS binnen samba uit te schakelen maar dit kan niet gecombineerd worden met een samba Domain Controller. Op een windows client is het ook mogelijk om het gebruik van NETBIOS uit te schakelen, indien dit zo is ingesteld zal het niet mogelijk zijn om deze op ons domein te joinen.

19 19 6. Automatisatie Voor een drukke netwerkspecialist die dikwijls nieuwe domeinen moet aanmaken zou het configureren van al deze services veel te veel tijd innemen. Daarom werd besloten om een enkele installatiescripts te schrijven in perl. Deze scripts gaan aan de hand van een aantal commandline argumenten alle nodige bestanden parsen. Het resultaat is dat men dankzij onze scripts op enkele seconden tijd een werkende directory service opgezet heeft met een draaiende samba, Dynamic DNS en openldap. Deze scripts zullen later opgeroepen worden door onze grafische java installer. In totaal werden er 5 scripts geschreven: install_directoryservices.pl Parst de samba en openldap configuratiebestanden en vult de ldapdatabank met de nodige data. Nadat men dit script uitgevoerd heeft kan men windowsclients laten inloggen op het domein. install_pdc.pl en install_bdc.pl Deze scripts moeten uitgevoerd worden op 2 verschillende servers, het stelt de machines in als PDC of BDC met ldapreplicatie. install_dns.pl Parst de configuratiebestanden van de DNS server, zorgt ervoor dat dynamic DNS werkt en dat SRV records beschikbaar zijn. install_rpm.pl Installeert de nodige RPM's nadat gecontroleerd werd welke er reeds geïnstalleerd werden op het systeem.

20 20 7. RPM installatie script Het install_rpm.pl script controleert of de nodige programma's en libraries aanwezig zijn en houdt zelfs rekening met de juiste versie. Als juiste versie beschouwen we hier de versie dat geleverd wordt op de cd's van Fedora Core 3. Als een bepaald programma nog niet geïnstalleerd is wordt het gedaan door het script. Als er reeds een (oudere of nieuwere) versie aanwezig is wordt deze eerst verwijderd waarna de juiste versie wordt geïnstalleerd. Elke package heeft enkele afhankelijkheden of dependencies. Deze werden ook toegevoegd aan het script om de meeste dependencyproblemen te voorkomen. Hierdoor is de lijst van te installeren packages groter dan het aantal services. Voor bind worden 3 pakketten Voor ldap worden 2 pakketten geïnstalleerd. geïnstalleerd. * bind libs * bind utils *openldap clients *openldap servers * bind Voor samba worden 2 pakketten Voor smbldap worden 6 pakketten geïnstalleerd. *samba common pre1.3 geïnstalleerd. *perl Digest MD5 M4p fc3.rf *samba pre1.3 *perl Digest SHA fc3.rf *perl Crypt SmbHash fc3.rf *perl Convert ASN fc3.r *perl Net LDAP fc3.rf *smbldap tools fc3.rf

21 21 8. ACL's Acl's zijn een onmisbaar onderdeel van de Windows beveiliging. Ze zorgen ervoor dat op een bestand per gebruiker kan gedefinieerd worden welke rechten deze heeft. Als men in een situatie komt waarbij bijvoorbeeld 15 gebruikers een bestand mogen editeren, 6 groepen dit bestand mogen uitvoeren, 9 gebruikers het bestand mogen uitvoeren en editeren, 8 gebruikers geen rechten erop hebben en de rest enkel leesrechten krijgt, dan kan het een redelijk complexe situatie worden om dit te verwezelijken zonder ACL's. Vooral voor het gebruik van Samba komen deze ACL's van pas Implementatie Als men een vrij recente kernel het hart van het besturingssysteem ter beschikking heeft (in ons geval de 2.6 kernel van Fedora Core 3), heeft men reeds alles ter beschikking. Indien er van een oudere kernel gebruik gemaakt wordt, zijn er patches beschikbaar op het internet. Het enige dat moet gedaan worden is het keyword 'acl' toevoegen aan /etc/fstab: LABEL=/home /home ext3 defaults,acl 1 2 Remounten of de computer heropstarten zorgt ervoor dat de acl's gebruikt kunnen worden. We gaan de ACL's opvragen met het commando: getfacl De output hiervan is de volgende: # file: test # owner: root # group: root user::rw group::r other::r

22 22 Om de gebruiker 'fred' het read/write recht te geven gebruiken we het volgende commando: setfacl m fred:rw test Een voorbeeldsituatie met verschillende gebruikers: de gebruiker ftp heeft readrechten, de gebruiker squid heeft alle rechten en de gebruiker fred heeft read en write rechten. # file: test # owner: root # group: root user::rw user:ftp:r user:squid:rwx user:fred:rw group::r mask::rwx other::r 8.2. Besluit Hoewel de ACL's zeker hun nut hebben zagen we het niet direct noodzakelijk om een extra wrapper ervoor te schrijven. In grote netwerken waarbij men vele verschillende gebruikers en groepen heeft kunnen de ACL's eventueel wel goed van pas komen. Ons eindwerk richt zich echter eerder tot kleinere netwerken en de standaardpermissies van Unix samen met alle extra beveiliging van samba en smbldap tools bieden genoeg mogelijkheden om een degelijk bestandsbeheer te implementeren zonder dat ACL's noodzakelijk zijn.

23 23 9. Policies 9.1. Poledit De tool dat we zullen gebruiken om policies te specifiëren is poledit. Zaken zoals: toegang tot opties in het control panel, uitzicht van de desktop, netwerkmogelijkheden en andere, kunnen ingesteld worden. Alles wat ingesteld wordt in de policies, wordt toegepast op de registry. De tool zelf wordt geleverd bij windows NT4 of kan gratis gedownload worden van het internet De werking Als een gebruiker aanlogt op het domein, of als een userprofile wordt geladen, wordt uit de NETLOGON map het NTConfig.POL bestand gehaald. Aangezien de NETLOGON map zowel in Windows NT als in Samba bestaat, kan Samba ook met de policies om. In dit bestand kunnen 4 soorten policies voorkomen. Policies op USER > de instellingen worden opgeslaan in de registry in: HKEY_CURRENT_USER 1. Policies op GROUP > de instellingen worden net als in de USER policies opgeslaan in de registry in: HKEY_CURRENT_USER 2. Policies op COMPUTER > de instellingen worden opgeslaan in de registry in: HKEY_CURRENT_MACHINE 3. Default policies > deze instellingen worden pas geladen als er geen andere policies gedefinieerd zijn en werken op dezelfde manier als de USER en GROUP policies.

24 Modes Er zijn 2 modes: de registry mode en de policy mode. Met de registry mode, kan men op de computer waarop poledit draait, rechtstreeks de registry gaan aanpassen. De policy mode dient om een NTConfig.POL bestand aan te maken. Dit is hetgene dat we zullen gebruiken ADM bestanden De ADM bestanden zijn te vergelijken met LDAP of XML schema's dat bepalen welke elementen er mogen voorkomen in de policy. Deze zijn de belangrijkste: Winnt.adm: deze bevat instellingen voor Win NT en varianten (niet voor Win ME) Common.adm: deze bevat settings zowel voor Win NT als voor Win95 98 cpanel.adm: deze werd na lang zoeken gevonden op het internet en bevat opties voor het restricteren van het control panel. De volgende screenshots illustreren het gebruik van Poledit: In deze menu's kan men 'users' en 'groups' gaan toevoegen aan de policy.

25 25 Per gebruiker of groep kan men een scala aan opties instellen Zwakheden De grootste zwakheid is dat poledit enkel beschikbaar is voor NT4 computers. Vele registrysettings zijn sinds Windows 2000 dezelfde gebleven maar sommige zijn ook veranderd. Dat wil zeggen dat deze settings niet meer toepasbaar zijn. Ook hangt het ervan af welke service packs op de clientcomputers geïnstalleerd zijn Test Als test werden 2 nieuwe groepen aangemaakt. De restricted group heeft geen rechten tot het control panel, geen 'run' tool en geen rechten tot 'regedit'. De nonetwork group heeft geen rechten om in het lokale netwerk te browsen.

26 26 De gebruiker Jeff kan alles doen met zijn computer, behalve browsen in het netwerk. De gebruiker Patrick kan daarentegen wel browsen in het netwerk, maar heeft geen rechten tot het control panel, de 'run' tool en 'regedit'. De gebruiker Jane, heeft geen rechten tot netwerkbrowsing en geen rechten tot het control panel, de 'run' tool en 'regedit' Conclusie We hebben ondervonden dat de policies meestal goed werden toegepast, maar niet altijd. Bij één clientcomputer leken de policies niet te werken, bij de twee andere wel. Ook werd opgemerkt dat een werkende configuratie die getest werd op pc A soms na een tijdje niet meer bleek te werken. Toen pc B aangesloten werd als client, bleek de configuratie wel te werken. Toen opnieuw pc A aangesloten werd, bleek de configuratie terug opnieuw te werken. We hebben niet kunnen verklaren hoe dit kwam. In de poging om specifieke windows XP policies te kunnen instellen, werden de. adm bestanden die in windows XP gevonden werden geladen. Poledit crashte echter aangezien deze bestanden vanaf windows ME uit een ander formaat bestaan. Het algemeen besluit is dat als policies toegepast moeten worden, deze best eerst grondig getest worden alvorens ze grootschalig te gaan toepassen. Mensen met een goede kennis van de registry kunnen eventueel in staat zijn bepaalde policies te omzeilen.

27 Nitrobit Group Policy De Nitrobit group policy is een alternatief voor het Microsoft Group Policy systeem dat gebruikt wordt in Microsoft Active Directory. Het heeft echter het voordeel dat het gebruikt kan worden in combinatie met Samba domeinen. Nitrobit raadt ook aan om Samba te combineren met LDAP, maar in principe hoeft het niet. Het is wel noodzakelijk om extra software te installeren op de windows clients in het netwerk. Het systeem kan ongeveer hetzelfde doen als de Microsoft group policies. Het heeft ook nog enkele extra tools die dienen om de connectie met LDAP makkelijker te maken. Op onderstaande screenshot valt op te merken dat het hier om een exacte kloon gaat van de group policy console van Microsoft. De group policy console van Nitrobit

28 Prijskaartje We hebben een mail gestuurd naar Nitrobit met de vraag naar de prijzen. Deze tabel hebben we gekregen: quantity: price per client License over 1500 $16 $14 $12 $10 $9 $8 on request Per Upgrade moet er nog een extra kost van 20 tot 40 % betaald worden Om dit even toe te passen op een netwerk van 200 computers: 200 x $10 = $ Conclusies We hebben met de trial versie wat geëxperimenteerd en zijn tot de conclusie gekomen dat Nitrobit Group Policy zeer degelijke software is. Het grote probleem is echter dat deze software betalend is. Dit is tevens de reden waarom we niet met deze software verderwerken in ons eindwerk. Als men de prijs bekijkt die men betaalt voor 200 clients, kan men ervan uitgaan dat het beter is om een echte Microsoft Domain controller aan te kopen bij een groter netwerk, aangezien deze behalve de group policies nog vele andere mogelijkheden heeft.

29 Beveiliging In een hedendaags netwerk is beveiliging heel belangrijk. Daarom werd besloten om ons systeem te onderzoeken op gaten. Als een windows client inlogt op het domein worden er zo'n paketten verstuurd. Het duurde slechts 5 minuten of we hadden met behulp van packet sniffers (ethereal en ettercap) het manager paswoord (het paswoord dat Samba gebruikt om te communiceren met Openldap) in cleartext van het netwerk gehaald. Daarom hebben we besloten dat het netwerkverkeer beveiligd moest worden. We hebben 2 mogelijkheden geprobeerd: Kerberos en TLS/SSL. Onze eerste keuze viel op Kerberos omdat Microsoft dit protocol gebruikt in hun Active Directory Kerberos Kerberos is een authenticatieprotocol (MIT) met als voornaamste doel: veiligheid en single sign on Werking In tegenstelling tot vele andere authenticatieprotocollen authenticeert kerberos elke gebruiker niet opnieuw voor een bepaalde netwerkservice. Kerberos gebruikt encryptie en een vertrouwde derde partij (trusted third party): de Key Distribution center (KDC). Eenmaal een gebruiker zich authenticeert bij de KDC, zendt deze een specifiek ticket terug dat ervoor zorgt dat de gebruiker zich voor elke service authenticeert. Dit principe heet single sign on.

30 30 Met behulp van onderstaande tekening wordt de werking in stappen uitgelegd: De terminologie wordt later uitgelegd. Als een gebruiker inlogt op een netwerk dat Kerberos als authenticatie gebruikt, moet hij eerst een request zenden naar de KDC voor een ticket (1). Dit kan gezonden worden door het login programma of door kinit als de gebruiker ingelogd is. De KDC checkt de principal in zijn database (2). Indien deze gevonden is, geeft de KDC de TGS opdracht om een TGT aan te maken (3). Deze is geëncrypteerd met de key van de gebruiker (afgeleid van het paswoord). De TGT wordt vervolgens naar de gebruiker gestuurd (4). De login of het kinit programma op de client machine decrypteert de TGT met de key van de gebruiker. Deze key wordt overigens nooit over het netwerk verstuurd. De TGT wordt opgeslaan in de cache van de client en wordt na een bepaalde periode ongeldig (meestal na 10 uur). Voor deze periode moet de gebruiker nooit meer zijn paswoord opnieuw geven aan de KDC (tenzij hij uitlogt). Telkens de client een nieuwe service wil gebruiken (5), gebruikt de clientsoftware de TGT om een nieuw ticket aan de TGS voor deze service aan te vragen (6 8). Het is ook belangrijk te weten dat de klok tussen client en server gesynchroniseerd moet zijn (5 mins max is de standaard).

31 Terminologie ciphertext: geëncrypteerde data credential cache / ticket file: bestand dat de key bevat om data te decrypteren KDC: (key distribution center): server dat kerberos ticket uitdeelt principal: een gebruiker/service dat zich met kerberos kan authenticeren key table /keytab: tabel van de principals en hun keys ticket: identificeert een client TGS (ticket granting service): een service dat tickets levert aan gebruikers/programma's TGT (ticket granting ticket): een ticket dat ervoor zorgt dat clients bijkomende tickets kunnen krijgen zonder hen te moeten vragen aan de KDC. kinit: commando, zorgt ervoor dat een ingelogde principal de TGT (ticket granting ticket) kan krijgen en cachen realm: een netwerk dat kerberos gebruikt Pogingen om Kerberos te integreren in ons eindwerk Het eerste probleem waarmee we te kampen hadden was dat de Microsoft implementatie van Kerberos verschilt van de implementatie die we onder linux gebruiken namelijk Kerberos V. Het is onduidelijk hoe een windows client gebruik maakt van dit protocol. Op een forum werd wel volgende informatie gevonden: benodigdheden voor een samba domaincontroller voor windows 2000 authenticatie: een Kerberos V KDC dat de win 2000 PAC kan uitdelen (deze is echter niet gedocumenteerd) Ldap server dat Kerberos V gebruikt als authenticatie een CIFS server (samba) Er werd geprobeerd om verschillende manuals te volgen. Het authenticeren van linux clients werkte perfect. De tool authconfig werd hiervoor gebruikt. Daarna hebben we geprobeerd met behulp van forums en man pages een windows client te laten authenticeren.

32 Hoe zijn we te werk gegaan We hebben de openldap admin guide op strikt gevolgd. Er werd een service key aangemaakt met de principal: Slapd, de LDAP server, moet toegang hebben tot de key. Dit wordt gedaan door de key in keytab te plaatsen met kadmin. De permissies van ldap.keytab werden gewijzigd zodat LDAP leesrechten heeft. Openldap.conf werd aangepast. De entries 'sasl realm' en 'sasl host' werden toegevoegd. Daarna werd de variabele KRB5_KTNAME geset op de ldap.keytab file. Er werd een SRV record toegevoegd in de DNS. Dit leverde echter geen succes op. Met ethereal konden we zien dat de kerberos authenticatie overgeslaan werd door de windows client. Er werden dus enkel maar SMB en LDAP requests uitgevoerd. Dit betekende voor ons dat we moesten zoeken naar een andere beveiliging.

33 TLS/SSL TLS staat voor transport layer security en is een open IETF standaard gebaseerd op de SSL (Secure Socket Layer) standaard. SSL is een transportlaag dat door andere protocollen kan gebruikt worden. De meest bekende is HTTP. De termen SSL en TLS zullen hier door elkaar gebruikt worden afhankelijk van de situatie Werking (illustraties: De versleuteling van SSL/TLS is bijzonder complex. Eerst en vooral moet men weten dat er 2 types versleuteling zijn. De symmetrische en de asymmetrische versleuteling. Symmetrisch versleuteling: Zowel encryptie als decryptie gebeurt met dezelfde sleutel. Deze heet de sessie sleutel. Asymmetrische versleuteling: Een publieke sleutel encrypteert een tekst, enkel de private sleutel is in staat deze tekst te decrypteren. De omgekeerde situatie is ook mogelijk, nl: het encrypteren met een private sleutel en decrypteren met een publieke sleutel.

34 34 SSL werkt met de voordelen van beide types versleuteling: Symmetrische versleuteling is zeer snel, terwijl het voordeel van asymmetrische versleuteling is dat er geen geheime sleutel afgesproken moet worden. Als de server bij het opzetten van de SSL verbinding zijn publieke sleutel naar de client stuurt kan men niet 100% zeker zijn dat deze wel afkomstig is van de juiste server. Om zeker te zijn dat de sleutel niet door iemand onderweg werd vervangen, wordt deze verpakt in een certificaat dat werd uitgegeven door een certificaatverstrekker zoals VeriSign. Het is ook mogelijk om zelf een certificaat aan te maken. De 3 functionaliteiten van deze beveiliging zijn: vertrouwelijkheid: client en server beschikken over de nodige sleutels zodat ze in staat zijn berichten naar elkaar te sturen die enkel zij kunnen lezen. authenticatie: de authenticatiedienst bestaat uit twee varianten. De eenzijdige authenticatie (server is bekend bij de client door zijn certificaat) en de tweezijdige authenticatie (beiden zijn bekend bij elkaar). integriteit: SSL/TLS biedt garantie dat gegevens niet gewijzigd worden tijdens het transport.

35 Hoe zijn we te werk gegaan Aangezien TLS het standaard beveiligingsprotocol is voor Openldap, leek dit ons de aangewezen keuze voor de tweede test. Eerst en vooral maken we een certificaat en private key aan met het commando: openssl req new x509 nodes out server.pem keyout server.pem days 365 De private key wordt hiermee automatisch aangemaakt en weggeschreven in het bestand server.pem. Vervolgens worden enkele vragen gesteld waarvan de antwoorden verwerkt worden in het certificaat, dat ook weggeschreven wordt in server.pem. Het bestand server.pem wordt gekopiëerd naar /etc/openldap. In slapd.conf worden 3 regels toegevoegd: TLSCACertificateFile, TLS CertificateFile en TLSCertificateKeyFile. Deze verwijzen allemaal naar het server.pem bestand Conclusie Het opzetten van een TLS beveiligde LDAP server duurt slechts enkele minuten. Bij het packet sniffen werd vastgesteld dat geen paswoorden in cleartext over het netwerk verstuurd werden.

36 Replicatie We vonden het belangrijk dat ons eindwerk bruikbaar zou zijn in een echt netwerk. Dit betekent dat er redundantie moet zijn. Als er een server uitvalt, mag dit niet betekenen dat de windows clients niet meer kunnen aanloggen. Samba 3 beschikt over de mogelijkheden om als BDC te fungeren. Met dit in het achterhoofd beschikken we over de volgende oplossingen: PDC Backend BDC Backend Conclusie smbpasswd file smbpasswd file Niet aan te raden. We zouden rsync/cron moeten gebruiken. Dit is geen elegante oplossing. centrale LDAP server centrale LDAP server Elegante oplossing, echter doet zich hier het probleem voor dat als de LDAP server crasht, er ook geen backup is. master LDAP server slave LDAP server Dit is de oplossing die wij hier zullen bespreken aangezien dit een volledige backupstrategie vertegenwoordigt. We zullen één machine gebruiken om de PDC en de master LDAP server op te installeren. Een andere machine zullen we gebruiken om de BDC en de slave LDAP server te installeren. De LDAP slave server is een kopie van de LDAP master server. Echter, zal deze enkel read requests beantwoorden. Als deze een write request krijgt, zal deze de request doorsturen naar de master server. Elke wijziging aan de master server zal ook doorgevoerd worden naar de slave server.

37 Werking (openldap.org) Slurpd zorgt voor de replicatieservice: 1. De client wijzigt iets aan de master ldap server. 2. De master ldap server voert de wijziging uit en schrijft de wijziging naar de replicatie logfile en returnt een success code naar de client. 3. Het slurpd proces verneemt dat er een nieuwe entry toegevoegd werd aan de replicatielogfile, leest deze en stuurt de wijziging door naar de slave server. 4. De slave server wijzigt zijn database en stuurt een success code door naar het slurp proces Configuratie Configuratie van de master en slave LDAP servers: Eerst moeten de databankbestanden in de directory van de master server, vermeld bij 'directory' in de slapd.conf file, gekopieerd worden naar deze directory in de slave server. Bij deze actie is het aan te raden de services op beide machines te stoppen. Daarna moet de master server als eerste opgestart worden, vervolgens de slave server. configuratie van slapd.conf: #master replogfile /var/lib/ldap/replog replica uri=ldap:// :389 binddn="cn=manager,dc=test6,dc=be" bindmethod=simple credentials=secret #slave updatedn "cn=admin,dc=example,dc=org" updateref ldap://

38 38 Zoals op de tekening te zien is, werken op die manier samba en ldap onafhankelijk. Als de eerste machine met de samba PDC en de master LDAP server uitvalt, zal de tweede machine dat beschikt over de samba BDC en de slave LDAP server ervoor zorgen dat de clients toch kunnen aanloggen op het domein. Een andere mogelijkheid zou zijn dat zowel in het configuratiebestand van de PDC als van de BDC, de beide LDAPservers gespecifieerd worden. Het voordeel is dat als de LDAP server het begeeft op de PDC, de PDC niet down gaat, aangezien de PDC de slave LDAP server zal gebruiken als backend. In onze situatie gaan we er echter van uit dat samba en LDAP één geheel vormen en dat elke sambaservice zijn eigen LDAP backend toegewezen krijgt. Dit is ook de manier waarop Microsoft Domain Controllers werken.

39 De analyse en programmatie van de software Het gebruiksgemak van de software was één van de belangrijkste zaken. De LDAP structuur en commando's zitten voor leken te ingewikkeld in elkaar. Dit is dan ook de reden waarom ervoor gekozen werd om een userinterface te maken die eenvoudig te bedienen is en waar geen kennis van LDAP voor vereist is. Doordat er een userinterface geschreven moest worden, werd er een keuze gemaakt van hoe deze interface aan de gebruiker zou voorgeschoteld worden. Er werd besloten dat de userinterface gemaakt zou worden als webinterface. Hiervoor was er de keuze tussen JSP, ASP en PHP. De taal die hiervoor het beste leek was JSP (JAVA server pages) aangevuld met servlets. De aanpak die gehanteerd werd, was eerst het ontwikkelen van een framework en daarna het schrijven van de userinterface. De ontwikkeling van het framework gebeurde synchroon met de ontwikkeling van de directory services, beschreven in voorgaande hoofdstukken JNDI Er bestaat voor java een API die ervoor zorgt dat een LDAP databank kan aangesproken worden. Deze API heet JNDI (Java Naming and Directory Interface). JNDI bevindt zich in het pakket javax.naming en javax.naming.directory. Om een verbinding met de LDAP databank te maken moet er een DirContext geïnstantieerd worden. Deze DirContext moet daarna opgevraagd worden aan de hand van enkele properties.

40 40 Verklaring van de properties: Property Verklaring PROVIDER_URL Dit zal de hostnaam zijn van de ldap databank, gevolgd door de rootcontext. Deze rootcontext is de distinguished name (DN). Bijvoorbeeld: ldap://localhost/dc=test,dc=com SECURITY_PRINCIPAL De inlognaam van de manager (LDAP administrator), gevolgd door de DN. Bijvoorbeeld: cn=manager,dc=test,dc=com SECURITY_CREDENTIALS Het wachtwoord van de manager. SECURITY_AUTHENTICATI Dit is om aan te geven of de wijze van inloggen ON in de LDAP databank moet gebeuren via een beveiligde verbinding of niet. In de volgende stap worden objecten aangemaakt in de LDAP databank. Dit gaat via de bind methode of de createsubcontext van de DirContext. Het verschil tussen de twee methodes is eenvoudig. De bind methode koppelt een naam aan een object en de createsubcontext koppelt een object aan een naam. Er bestaan 3 methodes om een object in een LDAP databank aan te maken via JNDI: Het Java object zelf opslaan Een referentie naar het object opslaan De informatie als attributen opslaan Het Java object zelf opslaan De eerste manier is het object zonder meer binden aan de LDAP structuur.

41 Een referentie naar het object opslaan In plaats van de volledige geserialiseerde status van een object op te slaan, kan ook de referentie naar dit object opgeslagen worden. De referentie naar een object bevat volgende informatie: De klassenaam van het gerefereerde object. Een vector van javax.naming.refaddr objecten die de adressen representeren. De naam en locatie van de object factory die gebruikt zal moeten worden voor de reconstructie. De javax.naming.refaddr abstracte klasse, zoals hieronder weergegeven, bevat informatie die toelaat om het object op te vragen. De klasse definieert een associatie tussen inhoud en type. De inhoud slaat informatie op benodigd voor het herbouwen van het object en het type identificeert het doel van de inhoud.

42 De informatie als attributen opslaan De laatste methode is het opslaan van de attributen van een object. Deze methode wordt ook gebruikt in ons systeem. Met deze methode slaat men geen java geserialiseerde data of referenties op. Het object dat aan de LDAP structuur gebonden moet worden zal eerst en vooral de interface DirContext moeten implementeren. Als men dan dit object zal binden aan de LDAP structuur, zal deze de attributen opvragen en gebruiken. Nu objecten toegevoegd kunnen worden moeten deze ook gewijzigd of verwijderd kunnen worden. Om dit te verwezenlijken moet het object uit de databank gehaald worden. De lookup methode zal het object teruggeven indien het gevonden is. Nadien wordt het object gecast naar het type object dat gewijzigd moet worden. Eenmaal dit object verkregen is, zullen methodes aangeroepen worden die geïmplementeerd zijn in het object zelf om de gegevens aan te passen. Nadien moeten deze gebonden worden aan de LDAP structuur. Om een object terug te binden hebben wordt de rebind methode gebruikt. Om een object te verwijderen biedt de DirContext ook enkele eenvoudige methodes aan. Deze methodes zijn respectievenlijk unbind en destroysubcontext. Het volledige framework zal dus geïmplementeerd worden volgens deze manier.

43 Analyse Voor de beheersoftware is er keuze uit genoeg programmeermodellen die elk hun eigen nut al bewezen hebben. Hier werd gekozen voor een 3 lagen model. Eerst wordt de tweede laag gemaakt en als deze volledig operationeel is, zal de derde laag aangemaakt worden. Het 3 lagen model zal er als volgt uitzien. 1. JNDI 2. De laag met de denklogica 3. De grafische laag De software moet volgende zaken kunnen: Gebruikers toevoegen Gebruikers wijzigen Gebruikers verwijderen Gebruikers voorzien van een ander wachtwoord Gebruikers in groepen toevoegen Gebruikers uit groepen verwijderen Gebruikers in een OU verplaatsen Gebruikers uit een OU verwijderen Groepen toevoegen Groepen verwijderen Groepen in een OU verplaatsen Groepen uit een OU verwijderen Computers verwijderen Computers in een OU verplaatsen Computers uit een OU verwijderen Status van de services weergeven Services kunnen starten, stoppen of herstarten

44 12.3. De use case 44

45 Programmatie van de software Connectie maken Om de connectie tot stand te brengen wordt er een klasse geschreven die de connectie regelt met LDAP en in deze klasse zullen ook de methodes worden voorzien die de use case vermeld staan Gebruikers toevoegen, aanpassen en verwijderen In het verhaal over JNDI werd gezien dat er 3 mogelijkheden bestaan om een object aan de LDAP structuur te binden. Eveneens werd er vermeld dat enkel de derde methode wordt gebruikt in ons eindwerk. De reden is dat als er gebruikers inloggen, er gegevens uit LDAP moeten opgehaald kunnen worden. Deze gegevens moeten leesbaar, een java object of een gerefereerd object zijn. De beheersoftware maakt gebruik van een zelfgeschreven klasse SambaUser die overerft van DirContext. Deze klasse beschikt over de volgende attributen: