Eindwerk: Linux Active Directory Emulatie

Eindwerk: Linux Active Directory Emulatie

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

Inhoudstafel 1. Inleiding...........................................................................................................................4 2. Wat is Active Directory...................................................................................................5 3. Een korte beschrijving van de onderdelen.......................................................................6 3.1. Samba.......................................................................................................................6 3.2. Openldap..................................................................................................................6 3.3. DNS..........................................................................................................................6 4. Openldap als Samba backend..........................................................................................7 4.1. Configuratie van Openldap als Samba backend.......................................................9 5. DNS................................................................................................................................12 5.1. Configuratie van de Named server.........................................................................12 5.2. Secondary DNS......................................................................................................14 5.3. Dynamic DNS........................................................................................................14 5.4. Microsoft Domain Controller en Linux DNS server..............................................15 5.5. NETBIOS vs. DNS................................................................................................17 5.6. Samba en Name servers.........................................................................................18 6. Automatisatie.................................................................................................................19 7. RPM installatie script.....................................................................................................20 8. ACL's.............................................................................................................................21 8.1. Implementatie.........................................................................................................21 8.2. Besluit....................................................................................................................22 9. Policies...........................................................................................................................23 9.1. Poledit....................................................................................................................23 9.1.1. De werking.................................................................................................................23 9.1.2. Modes.........................................................................................................................24 9.1.3. ADM bestanden..........................................................................................................24 9.1.4. Zwakheden..................................................................................................................25 9.1.5. Test.............................................................................................................................25 9.1.6. Conclusie....................................................................................................................26

9.2. Nitrobit Group Policy.............................................................................................27 9.2.1. Prijskaartje..................................................................................................................28 9.2.2. Conclusies...................................................................................................................28

10. Beveiliging...................................................................................................................29 10.1. Kerberos...............................................................................................................29 10.1.1. Werking....................................................................................................................29 10.1.2. Terminologie............................................................................................................31 10.1.3. Pogingen om Kerberos te integreren in ons eindwerk.............................................31 10.1.4. Hoe zijn we te werk gegaan.....................................................................................32


3

10.2. TLS/SSL...............................................................................................................33 10.2.1. Werking....................................................................................................................33 10.2.2. Hoe zijn we te werk gegaan.....................................................................................35 10.2.3. Conclusie..................................................................................................................35

11. Replicatie.....................................................................................................................36 11.1. Werking................................................................................................................37 11.2. Configuratie..........................................................................................................37 12. De analyse en programmatie van de software.............................................................39 12.1. JNDI.....................................................................................................................39 12.1.1. Het Java object zelf opslaan.....................................................................................40 12.1.2. Een referentie naar het object opslaan.....................................................................41 12.1.3. De informatie als attributen opslaan........................................................................42

12.2. Analyse.................................................................................................................43 12.3. De use case...........................................................................................................44 12.4. Programmatie van de software.............................................................................45 12.4.1. Connectie maken......................................................................................................45 12.4.2. Gebruikers toevoegen, aanpassen en verwijderen...................................................45 12.4.3. Groepen toevoegen, aanpassen of verwijderen........................................................47 12.4.4. Computers verwijderen............................................................................................48 12.4.5. OU's aanmaken en verwijderen................................................................................49 12.4.6. Elementen toevoegen of verwijderen aan/uit een OU.............................................50 12.4.7. SambaUser................................................................................................................51 12.4.8. SambaGroup.............................................................................................................52 12.4.9. SambaOU..................................................................................................................52 12.4.10. Services...................................................................................................................53 12.4.11. De grafische userinterface......................................................................................54 12.4.12. Installer...................................................................................................................55

13. De Grafische tool.........................................................................................................57 13.1. Services................................................................................................................58 13.2. Gebruikers............................................................................................................59 13.3. Groepen................................................................................................................64 13.4. Computers............................................................................................................68 13.5. Ou.........................................................................................................................70 14. Gelijkaardige Projecten................................................................................................73 14.1. Samba 4................................................................................................................73 14.2. Novell eDirectory.................................................................................................74 14.3. Suse Linux Enterprise Server 9............................................................................75 15. Besluit..........................................................................................................................76 16. Bijlage en literatuurlijst...............................................................................................77


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

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

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.

3.2. 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, ...

3.3. 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

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

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

4.1. 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

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

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://127.0.0.1 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: SMBLDAPTOOLS 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/smbldaptools/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

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.

5.1. 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 0.0.127.inaddr.arpa zone wordt de naam localhost gekoppeld aan 127.0.0.1 en omgekeerd. Deze 3 bestanden zijn overal gelijk. In de pinguin.be en 123.168.192.inaddr.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 123.168.192.inaddr.arpa.zone worden de IP adressen omgezet naar de juiste FQDN (DNS naam).


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: “namedcheckconf” controleert de named.conf file op syntax fouten, “namedcheckzone” 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

5.2. 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 “allowtransfer” 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.

5.3. 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 “allowupdate” toevoegen. De gemaakte updates zullen niet eeuwig beschikbaar zijn maar zullen verwijderd worden als de “Time to live” is verstreken.


15

5.4. 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 “allowupdate” 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 IPsettings), 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


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 Internetworking 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

5.6. 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

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

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.

* bindlibs9.2.42 * bindutils9.2.42

*openldapclients2.2.132 *openldapservers2.2.132

* bind9.2.42 Voor samba worden 2 pakketten

Voor smbldap worden 6 pakketten

geïnstalleerd. *sambacommon3.0.80.pre1.3

geïnstalleerd. *perlDigestMD5M4p0.011.1.fc3.rf

*samba3.0.80.pre1.3

*perlDigestSHA12.101.1.fc3.rf *perlCryptSmbHash0.021.1.fc3.rf *perlConvertASN10.180.1.fc3.r *perlNetLDAP0.27011.1.fc3.rf *smbldaptools0.8.51.1.fc3.rf


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.

8.1. 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

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 smbldaptools bieden genoeg mogelijkheden om een degelijk bestandsbeheer te implementeren zonder dat ACL's noodzakelijk zijn.


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. 9.1.1. 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

9.1.2. 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. 9.1.3. 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 95 – 98 – 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

Per gebruiker of groep kan men een scala aan opties instellen. 9.1.4. 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. 9.1.5. 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

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'. 9.1.6. 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

9.2. 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

9.2.1. Prijskaartje We hebben een mail gestuurd naar Nitrobit met de vraag naar de prijzen. Deze tabel hebben we gekregen: quantity:

price per client License

1 25 50 100 500 1000 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 = $2000. 9.2.2. 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

10. 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 10000 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.

10.1. Kerberos Kerberos is een authenticatieprotocol (MIT) met als voornaamste doel: veiligheid en “single sign on”. 10.1.1. 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

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 (68). Het is ook belangrijk te weten dat de klok tussen client en server gesynchroniseerd moet zijn (5 mins max is de standaard).


31

10.1.2. 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 10.1.3. 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

10.1.4. Hoe zijn we te werk gegaan We hebben de openldap admin guide op www.openldap.org strikt gevolgd. –

–

–

–

–

Er werd een service key aangemaakt met de principal: ldap/[email protected]. 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 'saslrealm' en 'saslhost' 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

10.2. 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. 10.2.1. Werking (illustraties: www.solidium.nl) 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

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

10.2.2. 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. 10.2.3. 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

11. 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

11.1. 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.

11.2. 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://10.0.0.20:389 binddn="cn=Manager,dc=test6,dc=be" bindmethod=simple credentials=secret

#slave updatedn "cn=admin,dc=example,dc=org" updateref ldap://10.0.0.1


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

12. 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.

12.1. 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

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

12.1.1. Het Java object zelf opslaan De eerste manier is het object zonder meer binden aan de LDAP structuur.


41

12.1.2. 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

12.1.3. 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

12.2. Analyse Voor de beheersoftware is er keuze uit genoeg programmeermodellen die elk hun eigen nut al bewezen hebben. Hier werd gekozen voor een 3lagen model. Eerst wordt de tweede laag gemaakt en als deze volledig operationeel is, zal de derde laag aangemaakt worden. Het 3lagen 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


12.3. De use case

44


45

12.4. Programmatie van de software 12.4.1. 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. 12.4.2. 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:


46

Hieronder worden de belangrijkste attributen verklaard: Attribuut

Verklaring

DisplayName

Loginnaam die wordt getoond in het windows startmenu

ObjectClass

Hierin wordt gedefinieerd van welke LDAP schema's het object gebruikt maakt

UserPassword

Het wachtwoord van de gebruiker, dit is een SSHA hashwaarde

SambaLogonTime

De laatste keer dat de gebruiker ingelogd was

SambaHomeDrive

De gemapte homedrive

Cn

De canonical name van de gebruiker

SambaLogoffTime

De laatste keer dat de gebruiker werd uitgelogd

SambaPwdLastSet

De laatste keer dat het paswoord geset werd

SambaAcctFlags

Dit zijn een reeks waarden die aangeven wat de gebruiker kan. Bv: U = User W = Workstation D = Disabled

SambaProfilePath

Het pad naar de map met het gebruikersprofiel in

SambaPwdMustChange Geeft aan of een gebruiker al dan niet zijn paswoord moet wijzigen SambaPwdCanChange

Geeft aan of het al dan niet mogelijk is het paswoord te wijzigen

Gecos

Extra informatie over de gebruiker

HomeDirectory

Hierin zal gekeken worden naar de home directory van de gebruiker. vb: “/Adhomes/user”

SambaKickoffTime

De tijd alvorens een gebruiker gekickt wordt van het systeem

Sn

surname, meestal gelijk aan de gebruikersnaam


47

12.4.3. Groepen toevoegen, aanpassen of verwijderen Voor groepen wordt opnieuw een eigen object aangemaakt die van de interface “DirContext” overerft.

Hieronder worden de belangrijkste attributen verklaard: Attribuut

Verklaring

ObjectClass

Hierin wordt gedefinieerd van welke LDAP schema's het object gebruik maakt

GidNumber

Het groepsnummer

Description

De beschrijving van de groep.

Memberuid

Het uid van de gebruiker van de groep.

Hiermee is het mogelijk om in de “LDAPConnect” klasse methodes te voorzien die: * groepen aanmaken en verwijderen * toevoegen en verwijderen van gebruikers in/uit een groep * opzoeken van de groepsnaam aan de hand van het GID nummer * opvragen van een lijst van alle groepen * opvragen van een lijst van alle groepen waarvan een gebruiker lid is


48

12.4.4. Computers verwijderen Als een computer zich voor de eerste keer aanmeldt in het domein zal deze worden toegevoegd in de OU “Computers”. Dit wordt door samba uitgevoerd waardoor het niet mogelijk is handmatig een computer toe te voegen. Een “computer” object is hetzelfde als een “SambaUser” object. Hierdoor kan een deel van de functionaliteit van de “SambaUser” klasse gebruikt worden voor de computer klasse. Om een computer te verwijderen is er in de “LDAPConnect” klasse een methode “removeComputer” bijgekomen. Tevens is er een methode voorzien om alle computers in de LDAP structuur op te vragen.


49

12.4.5. OU's aanmaken en verwijderen Een OU (organizational unit) is een middel om de overzichtelijkheid te garanderen. Wanneer men bijvoorbeeld 2 groepen van gebruikers heeft, is het overzichtelijker om voor elk groep een aparte OU aan te maken. Een OU aanmaken in de LDAP structuur zal moeten gebeuren met een “SambaOU” klasse die overerft van de DirContext interface. Om een OU aan te maken werd een methode in “LDAPConnect” voorzien die aan de hand van de OUnaam een OU zal aanmaken. Deze methode heet “addOU”. Een OU verwijderen zal gebeuren met de methode “removeOU” die voorzien is in de “LDAPConnect”. Tevens kan een lijst opgevraagd worden van alle OU's met de methode “getAllOUs”. De standaard OU's die reeds van in het begin aanwezig zijn in de LDAP structuur zijn de volgende: “ou=Users”, “ou=Groups” en “ou=Computers”.


50

12.4.6. Elementen toevoegen of verwijderen aan/uit een OU Gebruikers, groepen en computers kunnen reeds aangemaakt worden in de standaard OU's van de directory. Nu moet er voor gezorgd worden dat gebruikers, groepen en computers kunnen toegevoegd worden in een nieuwe OU. De eerste poging daartoe was niet geslaagd. Computers konden niet toegevoegd worden. Er werden namelijk exceptions geworpen die weergaven dat sommige velden niet voldeden aan de objectClass. Een volgende poging werkte wel. Hierbij werd gebruik gemaakt van “DirContext”. Via “rename” kon men een object van de ene OU naar de andere OU verplaatsen. Er werden eveneens nog enkele extra methodes in de LDAPConnect klasse toegevoegd. Zo zijn er methodes voor het toevoegen van computers, gebruikers en groepen in een OU, namelijk “addComputerToOU”, “addUserToOU” en “addGroupToOU”. Om deze computers, gebruikers en groepen weer te verwijderen kan men gebruik maken van: “removeComputerFromOU”, “removeUserFromOU” en “removeGroupFromOU”.


51

12.4.7. SambaUser Ten eerste werd van elk attribuut een private variabele gemaakt die voorzien werd van getters en setters. Om het SID te bekomen dat de Domain Controller heeft verkregen, kan gekeken worden in de standaard LDAP structuur, deze bevat een OU waarin de SID wordt weergegeven.

Dit wordt verwerkt in een klasse die via “toString” de SID weergeeft.

Net zoals het SID kan men het groepsnummer en gebruikersnummer ophalen uit de LDAP structuur.


52

Om het wachtwoord te wijzigen wordt gebruik gemaakt van een perl script. Dit omdat perl een kant en klare module bevat voor het encrypteren van deze paswoorden. De attributen die veranderd moeten worden bij het wachtwoord zijn de volgende: ● ● ●

sambaLMPassword sambaNTPassword userPassword

Het script zet de 3 geëncrypteerde wachtwoorden in een bestand dat achteraf door java kan uitgelezen worden. 12.4.8. SambaGroup Deze klasse krijgt ook weer private variabelen en de nodige getters en setters. Hier is ook het sambaSID vereist. Aangezien voor de SambaUser al reeds de “SambaSID” klasse geschreven werd, kunnen we deze weer hergebruiken. Het gidNumber kan opgehaald worden uit de LDAP structuur. Aan een groep kunnen we een gebruiker toevoegen. We moeten dus allereerst het attribuut “memberuid” gaan ophalen en er dan een waarde aan toevoegen. 12.4.9. SambaOU Een OU kent maar 2 attributen. Deze zijn de naam van de OU en de objectclass.


53

12.4.10. Services In het programma zullen ook enkele methodes worden voorzien om de services te starten, stoppen of herstarten. Deze zijn voorzien in de klasse “ServiceStatus”. Met services worden de ldap service, de bind service, en de samba service bedoeld. In de klasse ServiceStatus zijn er methodes voorzien die een boolean teruggeven. True wanneer de service draait of false indien deze niet draait. Om te zien of een service draait, openen we een socket naar de desbetreffende poort. Kan er geen connectie tot stand gebracht worden, dan draait de service niet. De klasse ServiceStatus ziet er in dit geval als volgt uit:

Eindwerk: Linux Active Directory Emulatie 12.4.11. De grafische userinterface Voor de grafische userinterface was het eerst de bedoeling te werken met JSP en servlets. Aangezien de tijd te beperkt was om dit te volbrengen, werd er gekozen om te blijven verder werken aan de hand van de voorlopige interface. Hiervoor werd de code volledig herschreven en werd er gebruik gemaakt van swing. Dialogen werden gemaakt om de operaties op LDAPConnect te volbrengen. Dit werd onder andere gebruikt bij het toevoegen van gebruikers, verwijderen van groepen en computers, ... De “default button” staat ingesteld op de OK button, zodat wanneer men op 'enter' drukt hetzelfde gebeurt als bij het klikken op de OK knop. Voor het weergeven van de gebruikers, groepen, computers en OU's worden Jtree's gebruikt. Na het wijzigen van een object worden de boomstructuren vernieuwd zodat altijd de laatste informatie zichtbaar is.

54


55

12.4.12. Installer Voor de volledigheid werd ook voor de installatie van “Active Directory emulatie” een grafische interface gebruikt. Ook hier wordt gebruikt gemaakt van een java swing applicatie. Deze applicatie stelt de gebruiker vragen zoals 'gewenste IP adres','administrator paswoord',... Voor het programmeermodel van de grafische installer werd weer gekozen voor een 3lagen model. Waarin de 3de laag dan de grafische interface is en de 2de laag de perl scripts. De eerste laag zal het systeem zelf zijn. Voor de installer werd een pattern geschreven. Dit pattern is gebasseerd op de Linked List.


56

Elke vraag word in een aparte Jpanel gestoken. Deze panels erven over van de interface “Installable”. Deze beschikt over de “next”, “previous” en “check“ methodes. Doordat in elk panel een verwijzing naar het vorig panel wordt bijgehouden, is het zeer eenvoudig om naar ander een panel terug te keren. In de Data klasse zullen de gegevens bewaard worden. Dit systeem biedt een aantal voordelen: * Niet alles wordt in 1 klasse geprogrammeerd => Dit zorgt voor duidelijke en overzichtelijke code * De data wordt op een centrale plaats bijgehouden => Dit zorgt voor een betere opslag => Er hoeft geen ingewikkeld opzoekingswerk te gebeuren De installer maakt ook gebruik van een Thread, dit om de output van de uitgevoerde perl scripts te laten verschijnen in een textbox.


57

13. De Grafische tool Er moet als hoofdgebruiker (root) van het systeem aangemeld worden. Nadien zal er zich een venster openen met een boom en enkele knoppen. Dit venster is de sectie van de gebruikers. Zoals te zien op de afbeelding hieronder:


58

13.1. Services In dit venster zal een menubalk te zien zijn. In deze balk zal de status van de services kunnen bekeken en eventueel aangepast worden. Als de 'view status services' aangeklikt wordt, zal dit venster zich openen.

Hierin kunnen de 4 services waarvan het eindwerk gebruik maakt bekeken en aangepast worden. Wanneer er in het blauw “Active” verschijnt betekent dit dat de service draaiende is. Bij het in het rood verschijnen van “Down” is de service niet draaiende. Legenda De service starten De service herstarten De service stoppen


13.2. Gebruikers Een gebruiker toevoegen aan het systeem kan gedaan worden door op de knop te drukken. Nadien zal deze dialoog zich openen:

Hierin kunnen de gegevens van een gebruiker ingevuld worden. De gebruikersnaam (username), de weergavenaam (displayname) en de beschrijving (description). Eveneens kan de gebruiker op niet actief gezet worden door het vinkje naast 'user active' uit te schakelen. De gevolgen hiervan zijn dat een gebruiker niet meer aanmelden kan in het systeem. De mogelijkheid bestaat er ook in een gebruiker zijn wachtwoord te laten wijzigen bij zijn volgende aanmelding, hiervoor moet het selectievakje naast 'user must change password at next logon' aangevinkt worden.

59


60

De mogelijkheid om een gebruiker het recht af te nemen om zijn wachtwoord te wijzigen zal gedaan worden door het selectievakje naast 'user can change password' uitgevinkt te laten. Nu moet enkel nog een standaard groep herkozen worden. Deze wordt gekozen in de boomstructuur naast 'default group'. Hierna kan de 'ok' knop aangeklikt worden. Nu zal een dialoog tevoorschijn komen dat een wachtwoord vraagt voor de gebruiker hierjuist aangemaakt.

Na het indrukken van de 'ok' knop zal de boomstructuur in het hoofdprogramma automatisch geupdated zijn met de juiste informatie. Er zal ook een homedirectory worden gecreëerd die zal bestaan uit /ADhomes/ + de naam van de gebruiker. Indien de gebruiker “redantd” zal toegevoegd worden zal automatisch de map “/Adhomes/redantd“ er bijkomen. Het wachtwoord kan achteraf ook nog aangepast worden door in de gebruikerssectie van het programma de gebruiker te selecteren en daarna de knop in te drukken. Hierna zal het dialoogvenster van hierboven terug tevoorschijn komen.


61

Er zal bij het selecteren van een gebruiker, een sectie naast de boomstructuur, automatisch de belangrijkste gegevens van een gebruiker weergeven. Ook zal er in deze sectie een overzicht worden gegeven van de bestanden in de homedirectory van de gebruiker. Indien er dan op een bestand gedubbelklikt wordt, zal het bestand geopend worden met de teksteditor “gvim”.

Eindwerk: Linux Active Directory Emulatie Een gebruiker editeren, dus de gegevens van die gebruiker wijzigen, doet men door op de

knop te drukken. Daarna zal dit venster te zien zijn:

Hierin zullen de gegevens van de gebruiker te zien zijn en kunnen waardes gewoon opnieuw ingegeven worden. Daarna zullen deze waardes gebruikt worden als nieuwe gegevens voor de gebruiker.

62

Eindwerk: Linux Active Directory Emulatie Een gebruiker die aangemaakt werd kan terug verwijderd worden door de knop in te drukken. Vervolgens zal er volgend dialoog te voorschijn komen:

Hierin kan nog gekozen worden om de homedirectory van de gebruiker te behouden of te verwijderen.

63


64

13.3. Groepen De sectie die gewijd is aan de groepen ziet er in de applicatie als volgt uit:

Er is een boomstructuur te zien waarin een groep geselecteerd kan worden. Indien er een groep geselecteerd is komen in de boomstructuur ernaast de gebruikers te voorschijn die lid zijn van deze groep. Een gebruiker kan men dan ook selecteren en kunnen de gegevens zoals de groepen waarvan de gebruiker lid is, bekeken worden. Ook zal de beschrijving van de groep te zien zijn bovenaan. Naast de knoppen om een groep aan te maken en groep te verwijderen.

Eindwerk: Linux Active Directory Emulatie Een groep aanmaken zal gebeuren door op de

65

knop te drukken. Hierna

wordt deze dialoog getoond:

Een groep verwijderen gebeurt dan weer door de wordt dan deze dialoog getoond:

knop in te drukken. Hierna

Eindwerk: Linux Active Directory Emulatie Een gebruiker toevoegen aan een groep zal gedaan worden door de

66 knop

naast 'users in group' in te drukken. Het dialoogvenster dat te voorschijn zal komen is het volgende:

Na de 'ok' knop ingedrukt te hebben en de groep en gebruiker geselecteerd te hebben zal dit te zien zijn:


67

De gebruiker die geselecteerd is uit de groep verwijderen zal gebeuren door de knop naast 'users in group' in te drukken. Nadien wordt dit venster afgebeeld:

Na de 'ok' knop ingedrukt te hebben zal de gebruiker uit de groep verwijderd zijn.


13.4. Computers De sectie van de computers is vrij eenvoudig. Er is namelijk enkel de mogelijkheid om computers te verwijderen van het systeem. Een computer aanmaken op het systeem is niet nodig. Dit komt doordat wanneer de Administrator een computer lid maakt van het domein, de computer in het systeem automatisch toegevoegd wordt.

68

Eindwerk: Linux Active Directory Emulatie Een computer verwijderen zal ook hier gebeuren door de Waarna dit dialoogvenster verschijnt:

69 knop in te drukken.


70

13.5. Ou De sectie OU's ziet er uit als volgt:

In de linkerboom zullen alle OU's te zien zijn. Als een OU geselecteerd is zullen de objecten van de geselecteerde OU tevoorschijn komen in het kader naast de OU. De objecten die zich in een OU kunnen bevinden zijn de volgende: • Gebruikers • Groepen • Computers

Eindwerk: Linux Active Directory Emulatie Een nieuwe OU aanmaken gaat simpelweg door op de

71 knop te drukken.

Daarna zal dit dialoogvenster tevoorschijn komen:

Wanneer een OU verwijderd moet worden kan op de Het volgend venster zal zich dan openen:

knop gedrukt worden.

Eindwerk: Linux Active Directory Emulatie Om een object aan een OU te kunnen toevoegen zal op de

72 knop naast

'Objects in OU' gedrukt moeten worden. Dan zal zich volgend venster openen:

Wanneer een object aan een OU toegevoegd is zal dit object veplaatst zijn. Het venster van de OU's zal er nu uitzien als volgt:

De gegevens zullen ook automatisch in de rest van de applicatie zijn toegepast.


73

14. Gelijkaardige Projecten We zijn natuurlijk niet de enige die een Active Directory service maken op een linux server. Hier worden 3 producten besproken die in dezelfde lijn staan als ons eindwerk. Samba, de service die instaat voor het authenticeren, file en printsharen tussen een linux en windows client, wil met zijn nieuwste versie een volledige Active Directory Domain Controller nabootsen. Dit is echter nog toekomstmuziek omdat deze versie nog steeds in ontwikkeling zit. Toch zullen we kort bespreken wat hiervan de nieuwe mogelijkheden zijn. Novell eDirectory biedt een Directory structuur aan dat installeerbaar is op een groot aantal platformen, waaronder zowel Linux als Windows. Suse Linux Enterprise 9 bevat een groot deel van de elementen dat ons eindwerk ook bevat, een combinatie van Samba, openLDAP en Dynamic DNS, verstopt achter een mooie userinterface.

14.1. Samba 4 Sinds geruime tijd werkt men aan de nieuwe versie van samba. Deze versie belooft heel wat goeds... De code van samba wordt helemaal herschreven. Dit is omdat de code van samba 3 nog steeds verder bouwde op de allereerste samba code. In die tijd was er nog niet zoveel bekend over de gebruikte Windows protocollen. In samba 3 werden sommige elementen van de protocollen pas geïmplementeerd nadat men een programma had gevonden dat er gebruik van maakte. In samba 4 gaat men het volledige protocol implementeren. In de vorige versie was de communicatie tussen 2 unix systemen via samba onmogelijk, enkel Windows <> Unix was mogelijk. In samba 4 zal dit veranderen, dit komt omdat men gebruik gaat maken van CIFS (Common Internet File System).


74

Via Unix CIFS extensions zal men gebruik kunnen maken van hardlinks, symlinks, devices maar ook zal het hernoemen en verwijderen van geopende bestanden mogelijk zijn. Nieuw is ook de LDB (LDAP like Database), deze is toegevoegd zodat samba niet meer afhankelijk is van openLDAP. De LDB biedt een LDAPlike API en ondersteunt de LDAP search expressions. Het kan gebruik maken van een TDB (Trivial Database, reeds gebruikt in vorige versie van samba) of LDAP backend. Eén van de doelen van Samba 4 is de volledige Active Directory Domain Controller, alsook een volledige NT4 Domain Controller nabootsen. Het gebruik van LDB en de volledige implementatie van het CIFS/SMB protocol zijn hier belangrijke elementen. Het stadium van “Active Directory Domain Controller” is nog maar in het begin, maar de basis ziet er reeds goed uit. Kerberos is ook een deel van Samba 4. Het CIFS protocol biedt reeds ondersteuning voor Kerberos, maar de koppeling van Kerberos en LDB is nog niet werkende. De reeds voltooide elementen van samba 4 zijn al veelbelovend, ook de elementen die nog in ontwikkelingsfase zijn, zijn het wachten waard.

14.2. Novell eDirectory Novell eDirectory biedt buiten een directory service de mogelijkheid om gebruikers en hun toegangsrechten te koppelen aan resources, devices, ... Het softwarepakket is compatibel met verschillende open standaarden zoals LDAP, XML (eXtensible Markup Language), DSML (Directory Services Markup Languages), ... Het is ook beschikbaar voor een tal van platformen zoals Linux, Windows, Solaris, Aix, NetWare, .. De toegangsrechten van de gebruikers worden in realtime gecontroleerd. Bij elke request zal de controle opnieuw gebeuren zodat elke aanpassing onmiddellijk wordt doorgevoerd.


75

Kleine errors worden onmiddellijk gedetecteerd en opgelost, de data wordt ook automatisch gerepliceerd en ook backups kunnen gemaakt worden zonder dat het systeem wordt onderbroken. Deze elementen zorgen ervoor dat Novell's eDirectory een grote betrouwbaarheid en beschikbaar heeft.

14.3. Suse Linux Enterprise Server 9 Suse is een Linux distributie waarbij men de mogelijkheid heeft om deze server te configureren als een Windows Domain Controller. Tijdens de installatie van Suse wordt de LDAP server reeds opgezet, dit gebeurt dan al omdat de LDAP database gebruikt wordt voor de authenticatie van de gebruikers. De configuratie van de Domain controller gebeurt via YaST (Yet another Setup Tool). Dit houdt de configuratie van samba in, het koppelen van samba met ldap en de configuratie van Dynamic DNS. Ook het beheer van de gebruikers en de groepen gebeurt via YaST. Vanaf dat de gebruikers daar zijn toegevoegd kan men daarmee inloggen vanop windows clients. Doordat de gegevens in een LDAP database worden opgeslagen kunnen ook linuxclients deze gegevens gebruiken om in te loggen. In een vergelijking van Suse Linux Enterprise Server (SLES9) met Windows 2003 server zou volgens Novell SLES9 het beter en sneller doen op dezelfde hardware. Ook qua kosten wint Suse, het kost namelijk maar één tiende van de windows oplossing. Volgens ons is deze vergelijking echter een marketingstunt aangezien beide producten over andere toepassingen beschikken en SLES9 niet beschikt over group policies.


76

15. Besluit Na deze maanden van onderzoeken, testen en programmeren, kan besloten worden dat het goed mogelijk is om een werkende opensouce directoryservice op te zetten die in staat is windows machines te authenticeren en die eventueel professioneel gebruikt kan worden. Aangezien Microsoft zijn technologie niet vrijgeeft is het echter onmogelijk om hun Active Directory exact na te bouwen. Met de komst van Samba 4 zal dit eventueel wel mogelijk zijn. Het allergrootste probleem om de Microsoft Active Directory te vervangen, zelfs met de toekomstige samba 4, is dat de “group policies” geen waardige opensource tegenhanger hebben. Ook hier is het zo dat er zeer weinig informatie te vinden is over hoe deze toegepast worden op de windowsclients. Wat onze beheersoftware betreft kunnen we stellen dat deze geschikt is om gebruikt te worden door mensen die niets over Linux of Java weten. Alle mogelijkheden werden verschillende keren getest en alles bleek goed te blijven werken na de nodige “bugfixes”. Voor onszelf kunnen we stellen dat we ons doel bereikt hebben. We hebben veel bijgeleerd, mooie zaken gerealiseerd en er op de koop toe veel werkgenot aan gehad.


16. Bijlage en literatuurlijst Het grootste deel van onze bijlagen, de zelfgeschreven howto's en tutorials, bevinden zich op de cdrom die bij het verslag zit. Literatuurlijst: – – – – – – – – – –

Red Hat Linux 8 Red Hat Linux Networking and System Administration Red Hat Linux Internet Server Beheer van netwerken windows 2000 MCSE Active Directory DNS and Bind Configuratie van de Bind 9 DNSserver Samba 3 Using samba, 2nd Edition Java cookbook

Lijst van veelgebruikte website: – – – – – – – – – –

www.openldap.org www.samba.org www.sambaxp.org www.bind9.net www.isc.org web.mit.edu/kerberos/www www.solidium.nl www.openssl.org java.sun.com www.microsoft.com

77

Eindwerk: Linux Active Directory Emulatie

Recommend Documents