Workshops Mit dem. zur Einrichtung einer LDAP Benutzerverwaltung. unter Verwendung von. Debian Lenny. openldap 2.4. samba 3. bind 9 DHCP.

Transkript

1 Workshops Mit dem zur Einrichtung einer LDAP Benutzerverwaltung unter Verwendung von Debian Lenny openldap 2.4 samba 3 bind 9 DHCP und Postfix

2 Inhaltsverzeichnis Einleitung:...3 Grundkonfiguration des Servers:...3 Konfiguration des Nameservers:...5 Konfiguration des LDAP-Servers:...7 Einrichten des LAM...12 Einrichtung der Verschlüsselung mittels TLS...43 Absicherung des LAM über https...51 Konfiguration des Sambaservers:...54 Absicherung des LDAP über ACLs...78 Verwendung von Filtern zur Suche im LDAP-Baum...86 Einbinden des DHCP-Servers:...90 Konfiguration des Mailserver Postfix: Einbinden des Proxy Squid in den LDAP-Baum Konfiguration des LDAP Slaveservers: Konfiguration des Samba BDC: Weitere Möglichkeiten mit einem LDAP-Server

3 Einleitung: In der neuen Version des Workshops wird nun der Debian Lenny verwendet und nicht mehr opensuse. Das hat mehrere Gründe. Für Debian Lenny wird es länger updates geben als für die opensuse Versionen. Ein weiter Grund ist der, dass ist der Hauptvorteil, die Unterstützung von LDAP beim bind9 und dhcpd nicht mehr von opensuse bereitgestellt wird. Bei Debian ist diese Funktion zwar auch nur für den dhcpd verfügbar aber der Vorteil der längeren updates überwiegt hier ganz klar. Dieser Workshop unterteilt sich in zwei Teile. Im ersten Teil soll auf eine einfache Art und Weise das Einrichten eines LDAP-Servers veranschaulicht werden. Ziel ist es, am Ende einen Server zu haben, der mehrere Dienste zur Verfügung stellt, die alle über LDAP authentifiziert werden. Die folgenden Dienste sollen für die Verwendung von LDAP eingerichtet werden: Samba 3 Apache2 Postfix cyrus mit sasl Dhcpd Squid Ein weiterer wichtiger Punkt wird die Absicherung aller Dienste mittels TLS sein. Dadurch werden alle Daten im Netzwerk verschlüsselt übertragen. Auch wird hier jetzt etwas tiefer in die Bereiche ACLs im LDAP und Filter für die Suche im LDAP eingegangen. Im zweiten Teil soll ein zweiter Server eingerichtet werden, der als Slaveserver die Dienste absichert, so dass beim Ausfall eines Servers die Dienste noch im Netz zur Verfügung stehen. Wie schon in den vorherigen Versionen, wird auch hier der LAM für die Verwaltung des LDAP-Baums zum Einsatz kommen. Hier wird die Version 2.5 Verwendung finden. Mit der Version ist es erstmals möglich, die Einträge für den DHCP-Server zu verwalten. Grundkonfiguration des Servers: Der Debian Lenny Server wird ganz normal ohne grafische Oberfläche installiert. Bei der Installation ist darauf zu achten, dass die IP-Adresse statisch und nicht dynamisch vergeben wird, damit sich die IP im laufenden Betrieb nicht ändert. Am Ende der Grundinstallation müssen die Funktionen ausgewählt werden, für die dann die entsprechenden Pakete installiert werden. Hier muss die folgende Auswahl getroffen werden: DNS-Server Web-Server Mail-Server Druck-Server Datei-Server Standard-System Bei der Nachfrage wie die Sambadomäne heißen soll, kann der Standardwert an dieser Stelle einfach übernommen werden. 3

4 Nach der Installation sollte auf jeden Fall das System mit apt-get update apt-get dist-upgrade auf einen aktuellen Stand gebracht werden. Jetzt fehlen noch ein paar zusätzlich Pakete, die nun installiert werden können. Hier die Liste der zusätzlichen Pakte: slapd ldap-utils libsasl2-modules-ldap stunnel resolvconf xinetd swat libsasl2-2vi sasl2-bin libsasl2-modules cyrus-admin-2.2 cyrus-clients-2.2 cyrus-imapd-2.2 squid Vor der weiteren Konfiguration der Dienste, müssen jetzt noch einige Parameter festgelegt werden. Mit diesen Werten wird dann den ganzen Workshop hindurch weiter gearbeitet: Name des Master Server : ldapserver 1. IP-Adresse des Master Servers : IP-Adresse des Master Servers : Sub-Netz-Maske: Name des Slave Servers : slaveserver IP-Adresse des Slave Servers : IP-Adresse des Linuxclients : IP-Adresse des Windowsclients : DNS Zonenname: home.stka root Passwort: geheim LDAP suffix: dc=home,dc=stka LDAP rootdn: cn=manager,dc=home,dc=stka LDAP rootpw: geheim erste UID: erste GID: erste Sambahost ID: 2000 Bei den Parametern ist darauf zu achten, dass der DNS-Name und der LDAP Suffix identisch sind, da sonst der DNS Server hinterher nicht in den LDAP integriert werden kann. 4

5 Konfiguration des Nameservers: Damit der LDAP- und Samba-Server anschließend auch erreichbar sind, muss unbedingt ein Nameserver im Netz laufen. Dies soll der erste Schritt bei der Einrichtung des Servers werden. Die Konfiguration für den Nameserver wird bei debian im Verzeichnis /etc/bind/ durchgeführt und unterteilt sich in mehrere Dateien: named.conf --> Über diese Datei werden alle anderen Dateien inkludiert, hier werden keine Änderungen vorgenommen. Named.conf.options --> Hier werden Optionen wie zum Beispiel "forwarders" eingetragen. Named.conf.local --> Hier werden die eigenen Zonen eingetragen. Im ersten Schritt werden nun die "forwarders" in die Datei /etc/bind/named.conf.options eingetragen. Hier müssen die IP-Adressen des Providers eingetragen werden, da ja auch Namen im Internet aufgelöst werden sollen. Der entsprechende Eintrag sieht so aus: forwarders { ; ; }; Im nächsten Schritt werden nun in der Datei /etc/bind/named.conf.local die Zonen eingetragen. Hier soll eine "forward-zone" und eine "reverse-zone" eingerichtet werden. Die Einträge für die Zonen werden am Ende der Datei wie folgt eingetragen: zone "home.stka" in { type master; file "master/db.home.stka"; }; zone " in-addr.arpa" in { type master; file "master/db "; }; Das Verzeichnis für die Zonendateien wird in der Datei /etc/bind/named.conf.options festgelegt. In dem Verzeichnis, das dort angegeben ist, wird nun das Unterverzeichnis "master" angelegt. In dieses Verzeichnis werden dann die Dateien für die Zonen abgelegt. Da ein Nameserver gleichzeitig Master und Slave für unterschiedliche Zonen sein kann, sollte immer eine Unterteilung in "master-" und "slaveverzeichnisse" stattfinden. Das Verzeichnis für die Zonendateien ist bei debian /var/cache/bind. Für die Konfiguration der Zonen werden hier die folgenden Dateien verwendet. Alle Beispieldateien befinden sich in den tar-archiv zu dem Workshop. db.home.stka => Forwardlookup Zonendatei db => Reverselookup Zonendatei Jetzt kann der "bind" mit dem Kommando: 5

6 /etc/init.d/bind9 restart neu gestartet werden. Anschließend sollte in der Datei /var/log/syslog der ordnungsgemäße Start des "bind" überprüft werden. An Hand der folgenden Zeilen kann das fehlerfreie Starten überprüft werden: Sep 23 15:17:01 ldapserver named[6655]: zone in-addr.arpa/IN: loaded serial Sep 23 15:17:01 ldapserver named[6655]: zone home.stka/in: loaded serial Damit der Server jetzt auch die Namensauflösung über den eigenen Nameserver durchführt, muss die Datei /etc/network/interfaces wie folgt angepasst werden: auto eth0 iface eth0 inet static address netmask network broadcast gateway # dns-* options are implemented by the resolvconf package, if installed dns-nameservers dns-search stka.home Nach einem Neustart übernimmt nun der eigene Nameserver die Namensauflösung. In der Datei /etc/resolv.conf müssen die folgenden Einträge stehen: search home.stka nameserver Jetzt kann die Namensauflösung getestet werden. Hier eine paar Beispiele, sowohl für die Namensauflösung im eigenen Netz, als auch im Internet: stefan@ldapserver:~$ host ldapserver ldapserver.home.stka has address stefan@ldapserver:~$ host in-addr.arpa domain name pointer ldapserver2.home.stka. stefan@ldapserver:~$ host has address Damit ist die Installation und Konfiguration des Nameservers abgeschlossen. Im nächsten Abschnitt wird nun die Grundkonfiguration des LDAP-Server durchgeführt. 6

7 Konfiguration des LDAP-Servers: Die Verwaltung des LDAP-Servers wird über die Datei /etc/ldap/slapd.conf realisiert. In der Datei werden alle Grundeinstellungen und Zugriffsrechte verwaltet. Für den Zugriff von älteren LDAP-Clients wird der Eintrag allow bind_v2 benötigt. Der Eintrag darf auf keinen Fall im "Database definition" Teil stehen. Leider fehlt beim Sambapaket von debian das "samba.schema". Die Datei befindet sich aber in dem "tar.gz-file" zu diesem Workshop. Die Datei wird einfach in das Verzeichnis /etc/ldap/schema kopiert. Hier nun die Liste der include Einträge: include include include include include /etc/ldap/schema/core.schema /etc/ldap/schema/cosine.schema /etc/ldap/schema/nis.schema /etc/ldap/schema/inetorgperson.schema /etc/ldap/schema/samba.schema Jetzt wird der Eintrag für die LDAP-Domäne Suffix angepasst und zwar auf suffix "dc=home,dc=stka" ACHTUNG seit der openldap Version 2.3 muss der suffix im Datenbankbereich oberhalb des Eintrags "checkpoint" erstellt werden. Jetzt muss noch ein Verwalter für den LDAP-Server eingerichtet werden. Dazu muss der Eintrag rootdn "cn=admin,dc=home,dc=stka angepasst werden. Das Passwort wird auf einer Konsole mit slappasswd -h {MD5} generiert und dann mit "copy-and-paste" in die Datei "slapd.conf" eingetragen. Der Eintrag für das Verwalterpasswort sieht dann so aus: rootpw {MD5}6GNuoBPmgvr2H1bOHLGrXA== Damit am Anfang Fehlermeldungen auch im Logfile landen, muss noch das Loglevel gesetzt werden. Dazu wird die Zeile: loglevel 256 eingetragen. Das Loglevel beim openldap wird nicht mit jeder Nummer höher, vielmehr entsprechen bestimmte Zahlen bestimmten Informationen die gelogged werden. Mehr dazu steht in der manpage zur slapd.conf. 7

8 Nach der Konfiguration wird der LDAP-Server mit dem Kommando /etc/init.d/slapd restart neu gestartet. Auch hier sollte die Datei /var/log/syslog/ kontrolliert werden. Mit dem Kommando tail f /var/log/syslog können auf einem anderen Terminal die Meldungen beim Starten beobachtet werden. Hier sollten keine Fehlermeldungen auftauchen. Bei einem fehlerfreien Start sollten die Meldungen so aussehen: Sep 23 17:07:37 ldapserver $OpenLDAP: slapd (Aug :08:50) $ ^Ibuildd@terranova:/build/buildd/openldap /debian/build/servers/slapd Sep 23 17:07:37 ldapserver slapd[5777]: /etc/ldap/slapd.conf: line 121: rootdn is always granted unlimited privileges. Sep 23 17:07:37 ldapserver slapd[5777]: /etc/ldap/slapd.conf: line 138: rootdn is always granted unlimited privileges. Sep 23 17:07:37 ldapserver slapd[5778]: slapd starting Damit nun der LDAP-Server selber auch auf den LDAP-Baum für die Authentifizierung der Benutzer zugreifen kann, muss nun noch der LDAP-Client eingerichtet werden. Ein Zugriff auf den LDAP Server ist jetzt noch nicht möglich, da erst noch der LDAP Client auf dem Server eingerichtet werden muss. Als erstes werden mit dem Kommando: apt-get install libpam-ldap libnss-ldap die benötigten Pakete installiert. 8

9 Wären der Installation werden die Parameter für den LDAP-Server abgefragt: Hier wird die URL für den LDAP-Server eingetragen. Im nächsten Fenster muss die oberste Ebenen das LDAP-Baums eingetragen werden, da diese als Anfangspunkt für die Suchen festgelegt wird. Als LDAP Version wird die 3 ausgewählt, die Version 2 ist veraltet und sollte nicht mehr verwendet werden. 9

10 Wenn die Passwörter der LDAP Benutzer auch über die Kommandozeile geändert werden sollen, dann muss die Frage im nächsten Fenster mit "Yes" beantwortet werden. Da für die Datenbank kein login benötigt wird, muss die nächste Frage mit "no" beantwortet werden. Wenn der lokale "root" ein Passwort ändern soll, muss er die Berechtigung dazu erhalten. Deshalb wird nun dem lokalen root-accout der Manager des LDAP-Baums zugewiesen, damit der lokale "root" Passwörter der Benutzer im LDAP ändern darf. 10

11 Natürlich muss auch das Passwort für den Manager hinterlegt werden, das passiert im nächsten Schritt. Der erste Teile der Clientkonfiguration ist damit abgeschlossen. Die Authentifizierung unter Linux wird über PAM geregelt, deshalb muss PAM nun noch so eingerichtet werden, dass bei einer Anmeldung auch auf dem LDAP-Server zugegriffen wird. Die Dateien, die bearbeitet werden müssen, liegen im Verzeichnis /etc/pam.d Die Datei "common-account" ###account required pam_unix.so account sufficient pam_unix.so account sufficient pam_ldap.so account required pam_deny.so Die Datei "common-auth" ###auth requisite pam_unix.so nullok_secure auth sufficient pam_unix.so auth sufficient pam_ldap.so use_first_pass auth required pam_deny.so Die Datei common-password ###password requisite pam_unix.so nullok obscure md5 # password sufficient pam_unix.so use_authtok md5 password sufficient pam_ldap.so use_first_pass use_authtok md5 password required pam_deny.so 11

12 Jetzt muss nur noch die Datei /etc/nsswitch.conf und /etc/ldap/ldap.conf angepasst werden, damit der LDAP-Server die Benutzer auch im LDAP sucht. In der Datei nsswitch.conf müssen nur zwei Zeilen angepasst werden. passwd: group: compat ldap compat ldap In der Datei ldap.conf müssen die Informationen eingetragen werden, über welche URI der Server erreichbar ist und welches der Base-DN ist. BASE dc=home,dc=stka URI ldap://localhost Einrichten des LAM An dieser Stelle wird das Werkzeug für die Verwaltung des LDAP-Baums, der LAM, eingerichtet. Der LAM basiert auf php und somit kann der LDAP-Server komplett über einen Browser konfiguriert werden. Für den LAM muss ein Webserver laufen. Der Webserver muss aber nicht unbedingt auf dem selben System laufen wie der LDAPServer, hier im Workshop wird das aber so eingerichtet um das ganze etwas übersichtlicher zu halten. Als erstes wird der LAM in der Grundkonfiguration eingerichtet, das heißt, ohne die Verwendung von https für die Verbindung zwischen Browser und Webserver. Auch wird die Verbindung zum LDAP-Server zu diesem Zeitpunkt noch nicht verschlüsselt durchgeführt. Später werden alle Netzwerkzugriffe über tls oder https abgesichert. Der LAM kann in der neuesten Version auf herunter geladen werden. Hier wird die Version 2.5 verwendet. Es gibt die Version in zwei Varianten, einmal als.deb Paket und einmal als tar.gz Paket. Die.deb-Version hat den Vorteil, dass Abhängigkeiten bei der Installation aufgelöst werden können. Nach dem die Datei heruntergeladen wurde, wird das Paket mit dem Kommando: dpkg -i ldap-account-manager_ _all.deb installiert. 12

13 Dabei kommt es zu den folgenden Meldungen: Wähle vormals abgewähltes Paket ldap-account-manager. (Lese Datenbank Dateien und Verzeichnisse sind derzeit installiert.) Entpacke ldap-account-manager (aus ldap-account-manager_ _all.deb)... dpkg: Abhängigkeitsprobleme verhindern Konfiguration von ldap-account-manager: ldap-account-manager hängt ab von php5 (>= 5.1); aber: Paket php5 ist nicht installiert. ldap-account-manager hängt ab von php5-ldap; aber: Paket php5-ldap ist nicht installiert. ldap-account-manager hängt ab von php-fpdf; aber: Paket php-fpdf ist nicht installiert. dpkg: Fehler beim Bearbeiten von ldap-account-manager (--install): Abhängigkeitsprobleme - lasse es unkonfiguriert Fehler traten auf beim Bearbeiten von: ldap-account-manager Das kommt daher, dass die entsprechenden php-pakete bis jetzt noch nicht installiert wurden. Dieser Fehler kann mit dem Kommando: apt-get -f install behoben werden. Denn damit werden alle fehlenden Pakete installiert. Nach dem die entsprechenden Pakete installiert wurden, wird auch sofort der LAM installiert und der Apache neu gestartet. 13

14 Wenn nun im Browser die Adresse eingegeben wird, kommt die folgendes Anmeldefenster: 14

15 Über den Link "LAM configuration" oben rechts in der Ecke muss nun der LAM als erstes konfiguriert werden. Im nächsten Fenster erscheinen zwei Auswahlmöglichkeiten, zum einen "Edit general settings" und zum anderen "Edit server profiles". 15

16 Im ersten Schritt werden die "general settings" eingestellt. Nach dem Klick auf den entsprechenden Link erscheint das folgende Bild: Hier wird das default Passwort "lam" eingetragen. 16

17 Im folgenden Fenster werden nun bestimmte Sicherheitsrichtlinien eingerichtet. Im ersten Teil der "Security settings" wird festgelegt, nach welcher Zeit die Sitzung beendet wird, wenn keine Aktionen im LAM mehr durchgeführt werden. Hier können auch bestimmte IP-Adressen eingetragen werden, von den aus der LAM verwendet werden darf. Im Workshop werden hier keine Änderungen vorgenommen. Auch die Einstellung für die "Password policy" wird hier nicht verändert. Hierbei handelt es sich um die Richtlinien für die Anmeldung am LAM und hat nichts mit der späteren Benutzerverwaltung zu tun. 17

18 Unter den Punkt "Logging" lässt sich das logging Verhalten des LAM verändern, auch hier wird keine Änderung vorgenommen. Bei dem Punkt "Change master password" wird nun eine neues Passwort für den Master der sich am LAM anmelden kann neu festgelegt. 18

19 Nach dem Bestätigen der Änderungen kommt die Meldung, dass alle Änderungen erfolgreich gespeichert wurden. 19

20 Durch einen klick auf "Back to login" kommt man wieder auf die Startseite des LAMs. Hier wird nun wieder der Punkt "LAM configuration" angeklickt. Dann wird der Punkt "Edit server profiles" ausgewählt. Denn nun muss noch ein Profil für den Server erzeugt werden mit allen wichtigen Angaben. Im nächsten Fenster erscheint die Eingabe für das Passwort, die kann zu diesem Zeitpunkt noch nicht verwendet werden, da noch kein Profil angelegt wurde. Im ersten Schritt auf dem Weg zu einem Profil muss der Punkt "Mange server profiles" angeklickt werden. 20

21 Jetzt soll ein neues Profil für den "ldapserver" hinzugefügt werden. Dazu wird die Seite wie hier im Bild gezeigt ausgefüllt und dann mit "Ok" bestätigt. Das Passwort für das Profil muss nicht das selbe Passwort sein wie das Masterpasswort. Es kann ja sein, dass eine andere Person für die Verwaltung der Profile verantwortlich. 21

22 Nach der Eingabe der entsprechenden Daten kommt ein Fenster mit der Bestätigung, dass das Profil angelegt und gespeichert wurde. Hier kann jetzt auch gleich das "default profile" eingestellt werden. Diese Änderung muss wieder mit dem Masterpasswort bestätigt werden. 22

23 Über den Punkt "Back to profile login" kann nun die Anmeldung am gerade erzeugten Profile stattfinden. 23

24 Jetzt folgt die eigentliche Konfiguration der Umgebung für diesen Workshop. In den nächsten Schritten müssen nun alle Informationen eingetragen werden. Im ersten Teil den "Server settings" wird dem LAM mitgeteilt, auf welchem System der LDAP-Server installiert ist. In diesem Fall ist es der localhost, deshalb muss hier nur der "Tree suffix:" angepasst werden. 24

25 Der zweite Teil wird an dieser Stelle erst einmal ausgelassen, da durch das Klicken auf "Edit account types" oder "Edit modules" die Änderungen auf dieser Seite wieder zurück gesetzt werden. Deshalb geht es hier jetzt erst einmal mit dem dritten Schritt weiter. Hier können die Bereiche der UIDs der Unix-User und der Hosts festgelegt werden. Die Host-IDs werden später für die Samba-Workstations benötigt. Da aber für jeden Samba-Benutzer, und nichts anderes ist ein Winclient, ein entsprechender Unix-User existieren muss, wird hier ein eigener Bereich für die Workstations festgelegt. Im Workshop werden hier keine Änderungen vorgenommen. 25

26 In Teil vier wird die Zeitzone festgelegt, das ist für die Winclients wichtig, damit die Zeit auch über mehrere Zeitzonen angeglichen werden kann. Im fünften Teil wird der Bereich für die GIDs der Unix-Gruppen festgelegt. Auch hier werden keine Änderungen durchgeführt. 26

27 Im Teil sechs wird die default Sprache eingestellt. Im Teil sieben können nun bestimmte Skripte abgelegt werden. Diese Einstellungen, genau wie die Berechtigungen für die Homedirectories der Benutzer werden nur benötigt, wenn der lamdaemon eingesetzt wird. Da die Konfiguration des lamdaemons aber Pakete erfordert, die nicht als.deb vorliegen sondern kompiliert werden müssen, wird im Workshop darauf nicht eingegangen. Die Homedirectories der Benutzer müssen also immer von Hand angelegt und mit den richtigen Rechten versehen werden. Der achte Teil "Security settings" ist wieder wichtig, denn hier werden alle Benutzer eingetragen, die sich später am LAM anmelden können. Hier muss auf jeden Fall der "Manager" angepasst werden! Alle gemachten Änderungen werden nun mit "Ok" bestätigt. Es kommt die Meldung, dass alle Änderungen gespeichert wurden. 27

28 Über den Link "Back to login" kommt man nun zurück zur Startseite des LAMs. Im letzten Schritt wurden die Punkte "Edit account types" und "Edit modules" noch nicht konfiguriert, das folgt nun. Über den Link "LAM configuration" -> "Edit server profiles" -> Login erstellten Profil "ldapserver", kann nun zu erst der Punkt "Edit account types" ausgewählt werden. Neben den "Active account types" können am Anfang weitere account types eingerichtet werden. Das wird hier nicht benötigt. Hier werden nun die Einstellungen der Accounts wie im Bild vorgenommen: 28

29 Die Änderungen werden wieder mit "Ok" bestätigt. Danach kommt man zurück auf die vorherige Seite. Über den Punkt "Edit modules" können nun noch weiter Module des LAMs eingebunden werden. Hier im Workshop ist das nicht notwendig. Bei den Modulen handelt es sich um zusätzliche Attribute für Benutzer die über weitere Schemata in den LDAP eingebunden werden. Da hier dies Schemata nicht im LDAP inkludiert sind, brauchen keine weiteren Module eingebunden werden. Wenn der LAM für eine reine Linuxumgebung, ohne Winclients verwendet wird, können an der Stelle aber die Module für den Samba entfernt werden. 29

30 Nach der Anpassung der Account Typs und der Module, muss nun die Änderung über OK bestätigt werden. Nach dem nun alle Einstellungen für den LAM vorgenommen wurden, kommt man zurück auf die Startseite des LAMs. Hier kann nun die Anmeldung am LDAP-Server mit dem entsprechenden Profil durchgeführt werden. Nach dem ersten Login kommt die folgende Meldung: Das ist korrekt, denn bis jetzt wurden ja noch keine Objekte erzeugt. Im Moment gibt es nur einen leeren LDAP-Baum. Durch einen Klick auf die Schaltfläche "Erstellen" werden alle benötigten Objekte automatisch erzeugt. Nun kommt die Meldung: Alle Änderungen waren erfolgreich. 30

31 Ein Klick auf den Punkt "Baumansicht" zeigt nun das folgende Bild: Damit ist die Konfiguration des LAMs abgeschlossen. 31

32 Nachdem der LDAP-Client auf dem Server auch schon konfiguriert wurde, kann nun auch die Verbindung zum LDAP-Server über die Kommandozeile mit dem folgenden Kommando getestet werden: ldapsearch -x -h localhost Das Ergebnis des Kommandos sieht wie folgt aus: # # # # # # # extended LDIF LDAPv3 base <dc=home,dc=stka> (default) with scope subtree filter: (objectclass=*) requesting: ALL # home.stka dn: dc=home,dc=stka objectclass: organization objectclass: dcobject dc: home o: home # users, home.stka dn: ou=users,dc=home,dc=stka objectclass: organizationalunit ou: users # groups, home.stka dn: ou=groups,dc=home,dc=stka objectclass: organizationalunit ou: groups # hosts, home.stka dn: ou=hosts,dc=home,dc=stka objectclass: organizationalunit ou: hosts # search result search: 2 result: 0 Success # numresponses: 5 # numentries: 4 32

33 Für den weiteren Verlauf des Workshops werden die folgenden Objekte benötigt, die jetzt mit dem LAM erzeugt werden müssen: Eine "default" Gruppe für alle Benutzer (Benutzer) Eine Gruppe für die Zugriffsberechtigung auf den LAM (lamadmins) Ein Benutzer der sich am LAM anmelden darf (stefan) Als erstes sollen nun die beiden Gruppen erzeugt werden. Dazu wird im LAM auf den Link "Gruppen" geklickt. Im Moment steht dort noch die Meldung "Keine Gruppen gefunden!" Das soll sich nun ändern. Durch einen Klick auf die Schaltfläche "Neue Gruppe" erscheint das folgende Fenster: 33

34 Die Meldung "Keine Samba 3 Domäne gefunden, bitte erstellen Sie eine!" kann an dieser Stelle ignoriert werden. Der LAM ist für die Verwaltung des Sambas vorbereitet, aber der Samba wurde bis jetzt noch nicht konfiguriert, das kommt erst später. Der LAM kann aber trotz dem die Posixgruppen erstellen. Mehr wird zu diesem Zeitpunkt auch nicht benötigt. Das Feld "GID Number" muss nicht ausgefüllt werden, obwohl dort ein "*" steht. Die GID Number vergibt der LAM automatisch. Nach der Eingabe der Daten wird die Gruppe über die Schaltfläche "Speichern" erzeugt. Die zweite Gruppe wird nun genau so erzeugt. Wenn beide Gruppen erzeugt wurden, sieht die Übersicht über die Gruppen nun wie folgt aus: 34

35 Nun wird der erste Benutzer erstellt. Hierbei handelt es sich auch wieder um einen reinen Posixbenutzer, so dass die Meldung über die fehlende Samba 3 Domäne auch hier ignoriert werden kann. Nach dem Klick auf "Benutzer" erscheint auch hier das leere Übersichtsfenster des Benutzers. Hier wird auf die Schaltfläche "Neuer Benutzer" geklickt um den ersten Benutzer zu erzeugen. Auf der Seite erscheinen vier Karteireiter, von denn jetzt nur die ersten drei benötigt werden. Auf dem ersten Karteireiter werden alle persönlichen Einstellungen des Benutzers vorgenommen. Nur die Zeile "Nachname" muss ausgefüllt werden, alle anderen Zeilen müssen nicht ergänzt werden. 35

36 Auf dem zweiten Karteireiter "Unix" werden nun alle Angaben gemacht, die für ein Unixaccount wichtig sind. Auch hier muss die UID nicht angegeben werden, da diese vom LAM automatisch vergeben wird. Wichtig ist, das als "RDN-Bezeichner" "uid" ausgewählt bleibt. Das wird für den Verlauf des Workshops noch wichtig. An dieser Stelle sei noch mal darauf hingewiesen, das die Homedirectories der Benutzer nicht automatisch erzeugt werden. Über die Schaltfläche "Passwort setzen" kann nun noch das Passwort für den Benutzer eingerichtet werden. 36

37 Auf dem Karteireiter "Shadow" können noch die Werte für die Gültigkeit des Passworts des Benutzer geändert werden. Für den Workshop sind hier keine Änderungen erforderlich. 37

38 Jetzt kann der Benutzer über die Schaltfläche "Speichern" gespeichert werden. Die Liste der Benutzer sieht nun so aus. 38

39 Jetzt muss der neu erstellte Benutzer noch Mitglied der Gruppe "lamadmins" werden. Das kann nun über zwei Wege geschehen. Zum einen kann die Zugehörigkeit direkt über das Gruppenobjekt geregelt werden. Zum anderen ist es aber auch möglich, die Gruppenzugehörigkeit über das Benutzerobjekt zu regeln. Im Beispiel wird die Gruppezugehörigkeit über das Gruppenobjekt geregelt. Dazu wird die Gruppenübersicht aufgerufen und auf das Symbol "Editieren" der Gruppe "lamadmins" geklickt. Dort wird dann die Schaltfläche "Mitglieder ändern" angeklickt. Es öffnet sich ein Fenster mit zwei Spalten. Auf der linken Seite die aktuellen Gruppenmitglieder und auf der rechten Seite die verfügbaren Benutzer die der Gruppe hinzufügt werden können. Hier wird nun der Benutzer "stefan" der Gruppe hinzufügt. Über die Schaltfläche "Speichern wird die Änderung gespeichert. 39

40 Jetzt ändert sich auch die Anzeige der Gruppenübersichtsliste, hier wird nun der Benutzer "stefan" als Gruppenmitglied angezeigt. Der Benutzername wird in blau angezeigt. Der Name ist ein Link, durch einen Klick auf den Namen kommt man sofort in die Eigenschaften des Benutzers. 40

41 Hier kann dann unter dem Karteireiter "Unix" und der Schaltfläche "Gruppen ändern", die Gruppenmitgliedschaft überprüft und geändert werden. 41

42 An dieser Stelle ist die Verwaltung von Benutzern und Gruppen erst einmal abgeschlossen. Zum Schluss kann man im folgenden Bild noch einmal die Baumansicht sehen wie der LDAP-Baum jetzt aussieht. Im nächsten Abschnitt werden nun alle Zugriffe auf den LDAP und den Apache über TLS und HTTPS abgesichert, damit keine Daten mehr unverschlüsselt übertragen werden. 42

43 Einrichtung der Verschlüsselung mittels TLS Nachdem nun der LDAP-Server läuft, geht es im nächsten Schritt darum, dass die Datenübertragung verschlüsselt stattfindet. Normalerweise werden alle Daten bei der Kommunikation zwischen LDAP-Server und LDAP-Client, auch Passwörter, unverschlüsselt übertragen. Mittels TLS kann dies aber geändert werden. Eine weitere Möglichkeit der Verschlüsselung für Passwörter des LDAP ist die Verwendung von SASL. SASL ist aber nicht Bestandteil dieses Workshops. Hier soll nun die Verschlüsselung der Übertragung mit TLS realisiert werden. TLS baut auf dem Protokoll SSL auf, ist aber nicht dessen Nachfolger, sondern ein eigenständiges Protokoll. Das primäre Ziel von TLS besteht darin, die Integrität und eine geschützte Verbindung zwischen zwei kommunizierenden Anwendungen herzustellen. Hierzu wird eine Verschlüsselungsmethode verwendet, die auf Schlüsseln und Zertifikaten basiert. Das Zertifikat muss normalerweise von einer "Certificate Authority" (CA) beglaubigt werden. Da hier das Zertifikat aber nur intern verwendet wird, kann das Zertifikat selbst beglaubigt werden. Dieses Zertifikat würde dann außerhalb des Netzwerks als "self-signed" betrachtet, und von gut konfigurierten Sicherheitssystemen abgelehnt werden, aber die Verwendung nach außen ist auch nicht gewollt. Zur Erstellung aller Zertifikat wird openssl verwendet. Openssl wird über die Datei /etc/ssl/openssl.cnf konfiguriert. In dieser Datei können Anpassungen an die eigene Umgebung vorgenommen werden. Hier können zum Beispiel alle Informationen über das Unternehmen voreingestellt werden. Die folgende Änderung an dieser Datei sollte für die folgenden Beispiele auf jeden Fall vorgenommen werden. Sonst kann es beim signieren des Zertifikats zu Fehlermeldung kommen. Vor der Zeile #unique_subject = no muss das "#" Zeichen entfernt werden. Im Verzeichnis /usr/share/ssl/misc/ befindet sich das Programm "CA.pl" und "CA.sh". Eines dieser beiden Programme wird verwendet, um die eigenen Zertifikate zu erstellen. Da sich das Programm nicht im Pfad befindet, kann hier ein Link in das Verzeichnis /usr/sbin gelegt werden, ln /usr/lib/ssl/misc/ca.pl /usr/sbin jetzt kann das Programm überall verwendet werden. Alle Zertifikate sollen in Zukunft an einer zentralen Stelle gespeichert werden, sowohl die Server- als auch die Clientzertifikate. Für diese Zertifikate wird das Verzeichnis /etc/ssl/zertifikate erstellt. In diesem Verzeichnis sollen alle Zertifikate für alle Server und Clients zentral gespeichert werden. ACHTUNG! Die Dateisystemberechtigungen auf dem Verzeichnis müssen so gesetzt 43

44 werden, dass alle Dienste, die nachher über Zertifikate abgesichert werden sollen, auf das Verzeichnis zugreifen können. Mit dem folgenden Kommando können die Rechte passend gesetzt werden: chmod 755 /etc/ssl/zertifikate Vor der Erstellung des Zertifikats wird in das Verzeichnis /etc/ssl/zertifikate gewechselt, da alle folgenden Kommandos relativ zum aktuellen Verzeichnis ausgeführt werden. Nun wird als erstes das Zertifikat für die CA mit dem Kommando erstellt: CA.pl newca Das Ergebnis sieht dann so aus: CA certificate filename (or enter to create) "ENTER Taste" Making CA certificate... Generating a 1024 bit RSA private key writing new private key to './democa/private/cakey.pem' Enter PEM pass phrase: "Pashrase wird nicht angezeigt" Verifying Enter PEM pass phrase: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. Country Name (2 letter code) [DE]: State or Province Name (full name) [NRW]: Locality Name (eg, city) []:Muenster Organization Name (eg, company) [SSK Netzwerke und Internet]: Organizational Unit Name (eg, section) [Home]: Common Name (eg, YOUR name) []:Stefan Kania Address []:stefan@kania online.de Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: Die letzten beiden Zeilen werden einfach mit RETURN bestätigt. 44

45 Im Anschluss wird das erzeugte CA Zertifikat angezeigt. Enter pass phrase for./democa/private/cakey.pem: Check that the request matches the signature Signature ok Certificate Details: Serial Number: 9b:06:02:df:58:7b:dd:db Validity Not Before: Feb 8 13:19: GMT Not After : Feb 7 13:19: GMT Subject: countryname = DE stateorprovincename = NRW organizationname = SSK Netzwerke und Internet organizationalunitname = CA SSK commonname = Stefan Kania address = stefan@kania online.de X509v3 extensions: X509v3 Subject Key Identifier: F1:47:C9:54:E8:3E:63:CA:29:BE:12:C5:31:72:C8:1F:93:56:0C:04 X509v3 Authority Key Identifier: keyid:f1:47:c9:54:e8:3e:63:ca:29:be:12:c5:31:72:c8:1f:93:56:0c:04 DirName:/C=DE/ST=NRW/O=SSK Netzwerke und Internet/OU=CA SSK/CN=Stefan Kania/ Address=stefan@kania online.de serial:9b:06:02:df:58:7b:dd:db X509v3 Basic Constraints: CA:TRUE Certificate is to be certified until Feb 7 13:19: GMT (1095 days) Write out database with 1 new entries Data Base Updated Als nächstes wird das Server Zertifikat erstellt. Hierbei ist darauf zu achten, dass als "common name" der FQDN des Servers verwendet wird, denn nur mit diesem Namen wird der Server authentifiziert. Zur Erstellung des Server Zertifikats wird das folgende Kommando verwendet, alle Fragen müssen systembezogen beantwortet werden: CA.pl newcert 45

46 Das Ergebnis sieht so aus: Generating a 1024 bit RSA private key writing new private key to 'newreq.pem' Enter PEM pass phrase: Verifying Enter PEM pass phrase: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. Country Name (2 letter code) [DE]: State or Province Name (full name) [NRW]: Locality Name (eg, city) []:Munester Organization Name (eg, company) [SSK Netzwerke und Internet]: Organizational Unit Name (eg, section) [Home]:Verwaltung Common Name (eg, YOUR name) []:ldapserver.home.stka Address []:stefan@kania online.de Certificate is in newcert.pem, private key is in newkey.pem Als Nächstes muss dann noch der Request für das Zertifikat erzeugt werden, das geschieht mit dem Kommando: CA.pl newreq 46

47 Hier das Ergebnis: Generating a 1024 bit RSA private key writing new private key to 'newkey.pem' Enter PEM pass phrase: Verifying Enter PEM pass phrase: You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. Country Name (2 letter code) [AU]:DE State or Province Name (full name) [Some State]:NRW Locality Name (eg, city) []:Muenster Organization Name (eg, company) [Internet Widgits Pty Ltd]:SSK Netzwerke und Internet Organizational Unit Name (eg, section) []:LDAP Req Common Name (eg, YOUR name) []:ldapserver.home.stka Address []:stefan@kania online.de Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: Request is in newreq.pem, private key is in newkey.pem Das neue Zertifikat für den Server wird nun direkt im Verzeichnis /etc/ssl/zertifikate abgelegt. Jetzt muss das Serverzertifikat mit dem CA-Zertifikat signiert werden, das geschieht mit dem Kommando CA.pl sign Als Passphrase muss hier das Passwort der CA angegeben werden. 47

48 Das Ergebnis sieht so aus: Getting request Private Key Enter pass phrase for newreq.pem: "Passwort des Servers" Generating certificate request Using configuration from /etc/ssl/openssl.cnf Enter pass phrase for./democa/private/cakey.pem: "Passwort der CA" DEBUG[load_index]: unique_subject = "yes" Check that the request matches the signature Signature ok Certificate Details: Serial Number: 2 (0x2) Validity Not Before: Jul 19 08:24: GMT Not After : Jul 19 08:24: GMT Subject: countryname = DE stateorprovincename = NRW localityname = Muenster organizationname = SSK Netzwerke und Internet organizationalunitname = Home commonname = ldapserver.home.stka address = stefan@kania online.de X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: :E4:C1:91:A8:20:A1:34:48:1A:67:3D:4C:1D:16:C2:B8:17:3B:26 X509v3 Authority Key Identifier: keyid:16:18:a1:05:28:0e:da:80:3a:ca:9f:44:55:c5:19:f0:d0: 7E:78:89 DirName:/C=DE/ST=NRW/L=Muenster/O=CA Munester/OU=Zertifikate/CN=Stefan Kania/ Address=stefan@kania online.de serial:00 Certificate is to be certified until Jul 19 08:24: GMT (365 days) Sign the certificate? [y/n]:y Signed certificate is in newcert.pem Damit beim Starten des Servers nicht immer das Passwort eingegeben werden muss, soll jetzt das Passwort aus dem Server Zertifikat entfernt werden. 48

49 Das geht mit dem Kommando openssl rsa in newkey.pem out ldapkey.pem Das Ergebnis sieht so aus: Enter pass phrase for newreq.pem: "Passwort des Servers" writing RSA key Um die Bezeichnungen etwas übersichtlicher zu halten, wird "newcert.pem" noch in "ldapcert.pem" umbenannt. mv newcert.pem ldapcert.pem Jetzt kann getestet werden, ob alles richtig gelaufen ist. Dazu wird das Kommando CA.pl wie folgt verwendet: CA.pl verify ldapcert.pem Das Ergebnis sieht so aus: ldapcert.pem: OK Die beiden Dateien newkey.pem und newreq.pem im Verzeichnis /etc/ssl/zertifikate können jetzt gelöscht werden, da die Zertifikate für den LDAP-Server alle umbenannt wurden. Dadurch kann es auch nicht zu Verwechselungen kommen, wenn im weiteren Verlauf des Workshops neue Zertifikate erzeugt werden. Nachdem das Zertifikat erstellt wurde, muss jetzt der Server so konfiguriert werden, dass er auch TLS nutzt. Dazu wird die Datei "slapd.conf" um die folgenden Zeilen ergänzt: TLSCertificateFile /etc/ssl/zertifikate/ldapcert.pem TLSCertificateKeyFile /etc/ssl/zertifikate/ldapkey.pem TLSCACertificateFile /etc/ssl/zertifikate/democa/cacert.pem TLSVerifyClient allow ACHTUNG Wer vorher schon mit dem alten Workshop gearbeitet hat, hier gibt es eine Änderung. Die Zeile: TLSCipherSuite HIGH:MEDIUM:+SSLv2 darf NICHT MEHR gesetzt werden. Bei Debian Lenny wird anstelle von openssl gnutls verwendet, gnutls kennt diese Parameter nicht. Jetzt muss der LDAP-Server neu gestartet werden. 49

50 Bevor nun der Client über TLS auf den Server zugreifen kann, muss der LDAP-Client auf dem Server noch eingerichtet werden. Dazu wird die Datei /etc/ldap/ldap.conf um die folgenden Zeilen ergänzt: TLS_REQCERT demand TLS_CACERT /etc/ssl/zertifikate/democa/cacert.pem Nun folgt noch ein Test, ob jetzt auch die Anfragen mit TLS akzeptiert werden. Der Test wird mit dem Kommando ldapsearch d 1 x ZZ h ldapserver.home.stka durchgeführt Die Optionen "-ZZ" verlangen zwingend eine TLS Kommunikation. Durch den Parameter "-d 1" wird eine erweiterte Debugausgabe erzeugt. In der Ausgabe kann die Übergabe der Zertifikate bei der TLS Verschlüsselung verfolgt werden. Der LAM erkennt, dass der Server über TLS erreichbar ist und verwendet dann automatisch TLS, dieses kann man in der /var/log/syslog des LDAP-Servers auch sehen. Sep 29 17:04:32 ldapserver slapd[5861]: conn=0 fd=17 ACCEPT from IP= :34264 (IP= :389) Sep 29 17:04:32 ldapserver slapd[5861]: conn=0 op=0 EXT oid= Sep 29 17:04:32 ldapserver slapd[5861]: conn=0 op=0 STARTTLS Sep 29 17:04:32 ldapserver slapd[5861]: conn=0 op=0 RESULT oid= err=0 text= Sep 29 17:04:32 ldapserver slapd[5861]: conn=0 fd=17 TLS established tls_ssf=32 ssf=32 Sep 29 17:04:32 ldapserver slapd[5861]: conn=0 op=1 BIND dn="" method=128 Sep 29 17:04:32 ldapserver slapd[5861]: conn=0 op=1 RESULT tag=97 err=0 text= Sep 29 17:04:32 ldapserver slapd[5861]: conn=0 op=2 SRCH base="dc=home,dc=stka" scope=2 deref=0 filter="(objectclass=*)" Sep 29 17:04:32 ldapserver slapd[5861]: conn=0 op=2 SEARCH RESULT tag=101 err=0 nentries=8 text= Sep 29 17:04:32 ldapserver slapd[5861]: conn=0 op=3 UNBIND Sep 29 17:04:32 ldapserver slapd[5861]: conn=0 fd=17 closed 50

51 Absicherung des LAM über https Im ersten Teil des Workshops wurde ja für den "ldapserver" eine zweite IP festgelegt, diese IP-Adresse muss nun einer virtuellen Netzwerkkarte zugewiesen werden. Über diese IP-Adresse soll nachher der LAM erreicht werden können. Für die Einrichtung einer virtuellen Netzwerkkarte muss die Datei /etc/network/interfaces um die folgenden Zeilen ergänzt werden: auto eth0:0 iface eth0:0 inet static address netmask network Im Anschluss wird die Konfiguration mit dem Kommando: /etc/init.d/networking restart neu gelesen. Danach steht die Netzwerkkarte zur Verfügung und kann mit "ping" angesprochen werden. Als erstes wird wieder ein Zertifikat erstellt, hierbei wird genau so vorgegangen wie bei der Erstellung des Zertifikats für den LDAP-Server. Das Zertifikat für die "CA" muss nicht neu erstellt werden. Der LAM soll hinterher über den FQDN lam.home.stka erreichbar sein. Deshalb ist es wichtig, bei der Erstellung des Zertifikates als "common name" diesen Namen einzutragen! Damit der Name auch über DNS aufgelöst werden kann, muss in der Datei /var/cache/bind/master/db.home.stka die folgende Zeile eingetragen werden: lam IN A In der Datei /var/cache/bind/master/db muss die folgende Zeile eingetragen werden: 171 IN PTR lam.home.stka. Anschließend muss der Nameserver mit dem Kommando: /etc/init.d/bind9 restart neu gestartet werden. Anmerkung: Normalerweise sollte in den beiden Dateien auch die Seriennummer hochgezählt werden. Da aber im Moment noch kein Slavenameserver läuft, ist das noch nicht so wichtig. Wenn aber später eine Slavenameserver läuft, ist das Anpassen der Seriennummer wichtig, damit der Slavenameserver auch die Änderungen mitbekommt. 51

52 Nun geht es an die eigentliche Konfiguration des Apache Webservers. Die Authentifizierung der Benutzer, die auf den LAM zugreifen dürfen, soll nicht über die Datei.httpaccess geregelt werden, sondern über LDAP. Alle Mitglieder der Gruppe "lamadmins" sollen auf den LAM zugreifen können. Damit der Apache die Authentifizierung auch gegen LDAP durchführen kann, müssen noch ein paar zusätzliche Module geladen werden. Auch müssen die Module für die SSL Unterstützung geladen werden. Bei Debian Lenny wird dies über die Verlinkung der Module in das entsprechende Verzeichnis geregelt. Mit den folgenden Kommandos werden die benötigten Module aktiviert: ln -s /etc/apache2/mods-available/*ldap* /etc/apache2/mods-enabled/ ln -s /etc/apache2/mods-available/*ssl* /etc/apache2/mods-enabled/ Jetzt den Apache mit dem Kommando: /etc/init.d/apache reload neu initialisieren Ein weiterer Schritt ist notwendig, damit der Webserver über https erreichbar ist. Es müssen wieder, wie schon für den LDAP-Server, die Zertifikate erstellt werden. Dazu werden die Schritte der Zertifikatserstellung vom LDAP-Server wiederholt. Nun ist darauf zu achten, dass jetzt der "common-name" lam.home.stka verwendet wird und dass die Dateinamen lamkey.pem und lamcert.pem heißen sollten. Die CA muss natürlich nicht neu erstellt werden. Jetzt muss noch die Konfigurationsdatei lam.conf für den LAM erstellt und an den richtigen Platz gepackt werden. Unter dem ubuntu-server werden die Konfigurationsdateien in dem Verzeichnis /etc/apache2/sites-available/ abgelegt und dann per softlink nach /etc/apache2/sitesenable/ verlinkt. ln -s /etc/apache2/sites-available/lam.conf /etc/apache2/sites-enabled/ Auf der folgenden Seite befindet sich die Konfigurationsdatei 52

53 # LDAP Parameter LDAPCacheEntries 1024 LDAPCacheTTL 60 LDAPOpCacheEntries 1024 LDAPOpCacheTTL 60 LDAPSharedCacheSize # LDAP Parameter <VirtualHost :443> DocumentRoot "/usr/share/ldap-account-manager" ServerName lam.home.stka:443 ServerAdmin ErrorLog /var/log/apache2/lam-error_log TransferLog /var/log/apache2/lam-access_log SSLEngine on SSLCipherSuite ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW: +SSLv2:+EXP:+eNULL SSLCertificateFile /etc/ssl/zertifikate/lamcert.pem SSLCertificateKeyFile /etc/ssl/zertifikate/lamkey.pem <Files ~ "\.(cgi shtml phtml php3?)$"> SSLOptions +StdEnvVars </Files> SetEnvIf User-Agent ".*MSIE.*" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 CustomLog /var/log/apache2/ssl_request_log ssl_combined <Directory "/usr/share/gosa/html"> Options Indexes FollowSymLinks AllowOverride None Order deny,allow # LDAP auth AuthType Basic AuthBasicProvider ldap AuthzLDAPAuthoritative On # AuthLDAPBindDN und AuthLDAPBindPassword wird benoetigt, da # keine anonyme suche im LDAP erlaubt ist. AuthLDAPBindDN "cn=manager,dc=home,dc=stka" AuthLDAPBindPassword "geheim" AuthName "Anmeldung fuer LAM" AuthLDAPURL "ldap://ldapserver.home.stka:389/dc=home,dc=stka?uid?sub" require ldap-group cn=lamadmins,ou=groups,dc=home,dc=stka # "AuthLDAPGroupAttributeIsDN" muss auf "Off" gesetzt sein, # sonst wird in der Mitgliederliste # immer nach dem vollstäigen DN des Benutzers gesucht # und nicht nur nach der uid AuthLDAPGroupAttributeIsDN Off AuthLDAPGroupAttribute memberuid # LDAP auth </Directory> </VirtualHost> 53

54 Nachdem der Apache soweit eingerichtet wurde, kann er nun neu gestartet werden. Im Anschluss daran ist der LAM über die URL erreichbar. Je nach Browser kommen unterschiedliche Meldungen hinsichtlich des Zertifikats. Das Zertifikat wurde ja selber signiert und ist somit für den Browser nicht vertrauenswürdig. Die Verschlüsselung der Verbindung funktioniert damit aber ohne Probleme. Bevor nun weitere Benutzer und Gruppen angelegt werden, wird jetzt erst der Sambaserver konfiguriert, damit die Benutzer und Gruppen gleich mit den benötigten Eigenschaften erzeugt werden können. Konfiguration des Sambaservers: Verwendet wird der Samba 3, in der aktuellen Version, die bei der Installation des Debian Servers installiert wurde. Genau wie bei anderen Paketen, gibt es hier aktuellere im Netz, aber bei der Installation des Servers kommt es darauf an, möglichst stabile Pakete zu nutzen und Pakete, welche auch von den Updates der Distribution berücksichtigt werden. Der LDAP-Server soll zur Verwaltung der Samba-Benutzer und -Gruppen verwendet werden, aus diesem Grunde wurde bei der Konfiguration des LDAP-Servers das Schema der Samba-Objekte bereits mit eingebunden. Zur Verwaltung des Samba Servers soll der SWAT verwendet werden, ein Werkzeug, das mit dem Samba Server installiert wird. Der SWAT wird über den "Super-Server" xinetd verwaltet. Bei Debian wird der SWAT nicht über den xinetd sondern über den Älteren unsichereren inetd eingerichtet. Das soll an dieser Stelle erst einmal geändert werden. Dazu wird im Verzeichnis /etc/xinetd.d/ eine Datei "swat" angelegt mit dem folgenden Inhalt: service swat { port = 901 socket_type = stream wait = no only_from = localhost user = root server = /usr/sbin/swat log_on_failure += USERID disable = no } In der Datei /etc/inetd.conf wird die Zeile für den SWAT durch ein "#" am Anfang der Zeile entwertet. Nun den xinetd mit dem Kommando: /etc/init.d/xinetd restart neustarten. ACHTUNG: Der SWAT kann nach der Installation nur vom "localhost" aus erreicht werden, das soll auch so bleiben, da die Verbindung unverschlüsselt ist. SWAT verwendet normalerweise http als Protokoll. Da der Samba Server aber über das 54

55 Netz verwaltet wird, soll hier auch https als Protokoll Verwendung finden. Um dies möglich zu machen, wird zusätzlich der Dienst "stunnel" installiert und konfiguriert, mit diesem Dienst werden alle Zugriffe auf den SWAT durch einen ssltunnel geleitet. Die Konfiguration von "stunnel" liegt im Verzeichnis /etc/stunnel. Nach dem Wechsel in das Verzeichnis, wird der folgende Befehl ausgeführt: openssl req new x509 days 365 nodes config /usr/share/doc/stunnel4/examples/stunnel.cnf out/etc/stunnel/stunnel.pem keyout /etc/stunnel/stunnel.pem ACHTUNG: Das Ganze ist eine Befehlszeile und muss genau so eingegeben werden. Nach der Eingabe des Kommandos, werden wieder alle Angaben für das Zertifikat erfragt. Im Anschluss muss die Datei "/etc/stunnel/stunnel.conf" bearbeitet werden. Am Anfang der Datei müssen die Zeilen für das Zertifikat "cert" und den Schlüssel "key" auf die vorher erstellte Datei angepasst werden: cert = /etc/stunnel/stunnel.pem key = /etc/stunnel/stunnel.pem die folgenden drei Zeilen müssen am eingefügt werden: [swat] accept = 902 connect = 901 Alle Zeilen für die nicht benötigten Dienste müssen mit einem ";" am Anfang der Zeile deaktiviert werden. Der "stunnel" wird nach der Installation nicht automatisch gestartet, damit der "stunnel" bei jeden Systemstart automatisch gestartet wird, muss die Datei /etc/defaults/stunnel4 angepasst werden. In der Datei muss der Wert ENABLED=1 gesetzt sein. Vor dem Starten von stunnel, muss die Berechtigung an der Zertifikatsdatei noch angepasst werden, da stunnel sonst beim Starten mit einer Fehlermeldung aussteigt: chmod 600 /etc/stunnel/stunnel.pem Jetzt noch den stunnel mit dem Kommando /etc/init.d/stunnel4 start starten, dann kann der Zugriff auf den SWAT über eine gesicherte Verbindung stattfinden. 55

56 Nach der Konfiguration des "stunnel" kann jetzt über einen Browser auf den den SWAT zugegriffen werden. Dazu muss als URL " eingegeben werden. 56

57 Nach der Anmeldung am SWAT müssen am Anfang erst einmal, unter Schaltfläche "GLOBALS", die Grundeinstellungen des Sambas vorgenommen werden. ACHTUNG vor dem Ändern der Werte unbedingt die Ansicht auf "Erweiterte Ansicht" umstellen, da sonst nicht alle Werte angezeigt werden. Workgroup = LDAPDOM passdb backend = ldapsam:ldap://ldapserver.home.stka printcap name = /etc/printcap logon path = \\%N\profile\%U logon home = \\%N\%U logon drive = H: Domain Logons = yes os level = 99 domain master = yes ldap admin dn = cn=manager,dc=home,dc=stka ldap group suffix = ou=groups ldap machine suffix = ou=hosts ldap user suffix = ou=users ldap passwd sync = yes ldap suffix = dc=home,dc=stka ldap ssl = start tls time server = Yes Alle anderen Optionen können momentan auf den Standardeinstellungen belassen werden. Jetzt über den Button "Speichere Änderungen" alle Änderungen in die Datei /etc/samba/smb.conf übernehmen. Bevor nun der Samba neu gestartet werden kann, muss dem Samba Server noch das Passwort für den LDAP Manager mitgeteilt werden. Sonst kann der "smbd" keine Verbindung zum LDAP Server aufbauen. Dazu geben wird das Kommando smbpasswd w <passwort> eingegeben. Nach der Konfiguration kann der Samba mit dem Kommando: /etc/initd./samba restart neu gestartet werden. 57

58 Wenn dann das Kommando "net getlocalsid" das folgende Ergebnis liefert, hat alles geklappt: ldapserver:~ # net getlocalsid SID for domain LDAPSERVER is: S Die SID ist natürlich bei jeder Installation eine andere. Jetzt wird auch im LAM die gerade erstellte Sambadomäne angezeigt. 58

59 Jetzt können die ersten Gruppen und Benutzer angelegt werden. Es gibt ein paar Standardgruppen, die zuerst angelegt werden müssen, diese Gruppen benötigen ganz bestimmte Gruppen-ID's, da diese die Standardgruppen des Windowssystems widerspiegeln. Diese Gruppen werden mit dem LAM als "Groupmapping" erzeugt. Ein "Groupmapping" ist vergleichbar mit einer globalen Gruppe in einer NTDomäne. Der Name der Gruppe spielt hier keine Rolle, nur die GID ist wichtig. Zu diesen Gruppen gehören: - domainadmins == GID domainusers == GID domainguests == GID winclients == GID 515 Um diese Objekte zu erzeugen, wird im LAM der Punkt "Gruppen" ausgewählt und dann jeweils eine neue Gruppe erzeugt. Der LAM unterscheidet hier zwischen den Unix und den Samba Eigenschaften. Der Name für die Groupmappings ist frei wählbar. Wichtig ist, das die SID richtig eingetragen ist. Dazu gibt es im LAM die Möglichkeit, die entsprechenden Sambagruppe beim Erstellen des Groupmappings direkt auszuwählen. Hier die entsprechenden Werte des LAM: - Domainadmins == Domänenadministratoren - Domainuser == Domänenbenutzer - Domainguests == Domänengäste - NT-Maschinen == Domänen-PCs Bei allen Groupmappings MUSS der "Gruppentyp" "Domänengruppe" ausgewählt werden. Die SIDs der Groupmappings dürfen nicht mehr auf eine entsprechende RID umgerechnet werden, da an sonst die Zuordnung der Gruppen beim Hinzufügen eines Rechners zur Domäne nicht mehr stimmt. Auch brauchen die GIDs der Groupmappings nicht mehr geändert werden. 59

60 An den folgende beiden Screenshots werden die Einstellung an Hand der Domain_admins gezeigt: 60

61 Mit den anderen drei Groupmappings wird genau so verfahren wie mit den Domänenadmins. 61

62 Hier noch ein Bild der aktuellen Baumansicht. Das Objekt der Gruppe "domainadmins" ist dabei markiert, am Ende der "sambasid" auf der rechten Seite ist der richtige RID 512 zu sehen. 62

63 Mit dem Kommando: ldapsearch -x -h localhost "(cn=domainadmins)" kann die Zuordnung überprüft werden. Das Ergebnis sieht dann so aus: # domainadmins, groups, home.stka dn: cn=domainadmins,ou=groups,dc=home,dc=stka objectclass: sambagroupmapping objectclass: posixgroup displayname: domainadmins sambagrouptype: 2 sambasid: S description:: QWRtaW5pc3RyYXRvcmVuIGRlciBTYW1iYSBEb23DpG5l gidnumber: cn: domainadmins Neben den oben aufgeführten Gruppen können weitere "Groupmappings" erzeugt werden, diese globalen Gruppe können dann für die Vergabe von Rechten auf einem Windowsserver in der Domäne Verwendung finden. Jetzt wird noch ein Domänenadmin benötigt der in der Lage ist, Hosts in die Domäne aufzunehmen. Seit einiger Zeit ist es nicht mehr notwendig, einen "fake-root" mit der UID und GID = "0" zu erstellen. Es ist möglich mittels des "net" Kommandos Rechte zu vergeben, um diese Funktion ausführen zu können. Das hat den Vorteil, dass kein zusätzlicher Benutzer erzeugt werden muss, der Rootrechte im System hat. Als erstes wird ein ganz normaler Benutzer angelegt, der sowohl einen Unix- als auch einen Sambaaccount besitzt. Hier ist darauf zu achten, dass der Benutzer als "Primäre Gruppe" der Gruppe "domainadmins" angehört. 63

64 Wichtig sind vor allen Dingen die Samba Einstellungen, deshalb hier noch ein Bild der Einstellungen: 64

65 Das folgende Kommando sorgt jetzt dafür, das der vorher erstellte "administrator" auch Hosts in die Domäne aufnehmen kann. Das Kommando MUSS mit einer Benutzerkennung abgesetzt werden, die Mitglied der Gruppe "Domainadmins" ist! Mit dem Kommado: su administrator kann die Identität gewechselt werden. Dann das folgende Kommando eingeben: net rpc rights grant LDAPDOM\\administrator \ SeMachineAccountPrivilege S localhost Hier wird dann als erstes nach dem Passwort des "Administrators" gefragt. Wenn das Passwort richtig eingegeben wurde, kommt die Meldung: Password: Successfully granted rights. Mit dem Kommando: net rpc rights list LDAPDOM\\administrator kann das Ergebnis überprüft werden. Jetzt ist der Benutzer "Administrator" in der Lage, Hosts in die Domäne aufzunehmen. 65

66 Im nächsten Schritt können nun die Hosts für die Samba-Domäne erzeugt werden. Um einen neuen Host mit dem LAM anzulegen, wird auf den Link "Hosts" geklickt und dann auf "Neuer Host". Die Hostnamen werden unter Windows intern immer mit einem angehängten "$" Zeichen verwaltet, das "$" Zeichen wird vom LAM automatisch beim Erzeugen des Objekts, angehängt. Der Hostname im LDAP muss immer gleich dem NetBIOS Namen des Winclients sein, da darüber der Account zugeordnet wird. Die UID wird, wie bei den Benutzern, automatisch ermittelt. Bei dem Abschnitt "Account" muss lediglich der Hostname das Systems eingetragen werden: 66

67 Unter dem Karteireiter "Unix" muss nur der "Benutzername" und der "Allgemeine Name" eingetragen werden. Die "Primäre Gruppe" steht standardmäßig auf "NT-Maschinen", das muss auch so bleiben. 67

68 Auch in dem Abschnitt "Samba" muss nur der Hostname eingetragen werden, der Name der Domäne wird automatisch übernommen. Das Passwort wird beim Aufnehmen in die Domäne zwischen Host und Domaincontroller automatisch ermittelt und muss hier nicht geändert werden. Anschließend kann über die Schaltfläche "Speichern" das Objekt erstellt werden. 68

69 Nach dem Erzeugen des Objekts sehen die "Unix" Eigenschaften so aus: 69

70 Jetzt kann der Windowsclient ganz normal in die Domäne aufgenommen werden. Bei der Frage nach dem Benutzer, der berechtigt ist, den Host in die Domäne aufzunehmen, wird der "Administrator" angegeben. Das Ergebnis, wenn ein Windowsclient in die Domäne aufgenommen wurde, sieht dann so aus: Bis jetzt gibt es in dem LDAP nur Posixuser, deshalb müssen nun erst noch Samba Benutzer angelegt werden, oder zumindest der am Anfang angelegte Benutzer um die Sambaaccount Informationen erweitert werden. Beides wird wieder mit dem LAM realisiert. Das Heimatverzeichnis des Benutzers muss auf dem Server von Hand angelegt und mit den entsprechenden Rechten versehen werden. Bei der Konfiguration des Samba wurde der Pfad mit \\%N\profile\%U bereits festgelegt. die Variabel "%N" steht für den Anmeldeserver und die Variabel "%U" für den Anmeldename des Benutzers. Deshalb müssen die Felder hier nicht ausgefüllt werden. In den Feldern für die verschieden Passwortoptionen können die Informationen für das maximale oder minimale Alter des Passworts für die Windowsanmeldung abgelegt werden. Bei der Option "Samba PCs" können Arbeitsstationen festgelegt werden, an denen sich der Benutzer anmelden darf. Wenn dort Einträge gemacht werden, darf der Benutzer 70