andreas72
10.10.03, 15:53
'tschuldigung, der Text ist lang. Würde mich aber sehr freuen, wenn's jemand liest. Danke.
Hallo Allerseits,
hier ist mal wieder der ehemalige Praktikant Andreas, der an seiner Projektarbeit sitzt und sich von einem Problem zum nächsten hangelt.
Hier nochmal das Thema meiner Projektarbeit:
Thema der Projektarbeit (kurz):
Aufbau und Konfiguration einer zentralen Benutzerverwaltung in einerWindows 2000
Domäne mit Authentifizierung und Autorisierung der Benutzer anhand der ActiveDirectory-Benutzerdatenbank.
Anlage 1 (Thema lang):
In der Projekt GmbH werden die von den Windows-Clients benötigten und bearbeiteten Daten auf einem Samba-Dateiserver auf der Basis eines Linux-Systems gespeichert. Derzeit existieren drei Benutzerdatenbanken wobei die Benutzerdatenbank auf dem Windows 2000 Domaincontroller die einzige aktualisierte ist. Die Linux- und Samba-Benutzerdaten werden völlig unabhängig von der Windows-Datenbank gepflegt. Die Samba-Benutzerdatenbank entspricht der Linux-Benutzerdatenbank abzüglich der System-Benutzer und es existieren in diesen beiden Datenbanken auch viele veraltete Einträge. Es soll nun nur noch eine Benutzerdatenbank auf dem Windows 2000 Domaincontroller gepflegt werden, welche dem gesamten heterogenen Netzwerk zur Verfügung steht. Somit soll Samba auf die Benutzerdatenbank des Windows 2000 Domaincontrollers zugreifen.
Meine Aufgabe ist es, diese Umstellung durchzuführen und zu dokumentieren.
Ich habe das Thema in der letzten Woche des Praktikums bekommen und sitzte nun zu Hause mit meinem virtuell nachgestaltetem Netzwerk.
Bevor ich meine Fragen/ Probleme äußere, etwas zu den Vorraussetzungen, mit denen ich arbeite:
Also ich habe mir zu Hause das Netzwerk mit Hilfe des von der Firma erhaltenen VMware virtuell nachgestaltet. Da existieren ein Windows 2000 Server mit Active Directory als Domaincontroller, ein Windows 2000 Professional Client für die ganzen User und ein Linux-Rechner mit Samba 3.0 (Member Server ???).
Auf dem Active Directory Server habe ich 21 Benutzer in drei Benutzergruppen eingerichtet (User_01 – User_21, jeweils sieben in den Gruppen Projekt_Admin, Projekt_User und Projekt_Guest). Die Rechte der User entsprechen den der Gruppen, denen sie angehören, und die Rechte der Gruppen entsprechen denen ihrer Bezeichnungen (Admin, User, Guest).
Auf dem Windows 2000 Professional Client-Rechner sind nur die Standard-Systemnutzer eingerichtet/ vorhanden. Die ganzen 21 Nutzer melden sich am Server an. Auf dem Server habe ich auch testweise Freigaben für jede der Benutzergruppen bzw. eine für alle eingerichtet und das klappt auch alles.
Nun habe ich mich dem Linux-Rechner zugewandt und die OpenLDAP development libaries und die Kerberos development libaries installiert/ aktiviert. Dann habe ich in der /etc/krb5.con-Datei die Einträge geändert (dabei benötigt Kerberos die Domainbezeichnung immer in Großbuchstaben - Kleinbuchstaben werden nicht erkannt/ akzeptiert):
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
ticket_lifetime = 24000
default_realm = SERVER.DE
dns_lookup_realm = false
dns_lookup_kdc = false
[realms]
SERVER.DE = {
kdc = 192.168.0.1
default_domain = server.de
}
[domain_realm]
.server.de = SERVER.DE
server.de = SERVER.DE
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
Dann habe ich die Verbindung mit dem Kerberos-Befehl kinit getestet:
wenn server.de runtergefahren (zum Vergleich)
linux:~# kinit User_01@SERVER.DE
kinit(v5): Cannot contact any KDC for requested realm while getting initial credentials
wenn server.de hochgefahren (Domain-Name in Groß- und Kleinbuchstaben)
linux:~# kinit User_01@server.de
kinit(v5): Cannot find KDC for requested realm while getting initial credentials
linux:~# kinit User_01@SERVER.DE
Password for User_01@SERVER.DE:
kinit(v5): Clock skew too great while getting initial credentials
Da kam die nächste Aufgabe auf mich zu. Kerberos benötigt Zeitsynchronisation zwischen Windows 2000 Server/ Client und Linux Server, da das Standard-Authentifizierungs-Protokoll (Kerberos v5) die Zeit der Clients für den Prozess der Ticket-Erzeugung nutzt.
Somit habe ich einen Network Time Protocol (NTP) Server auf dem Windows 2000 Domaincontroller (Windows 2000 Server) eingerichtet, an dem sich alle orientieren können (das dieser selbst seine Zeit später noch mit einer externen Quelle abgleichen sollte, steht außer Frage).
Die Clients (Windows 2000 Professional, Client-Rechner) im LAN wurden dann so eingerichtet, dass sie ihre Systemzeit mit dem NTP-Server abgleichen. Das klappt auch alles und ich habe mich dann am Linux weiterprobiert.
Auf dem Linux-Rechners habe ich dann die xntpd (Network-Time-Protokoll-Daemon) Installation überprüft bzw. es installiert und dann die /etc/ntp.conf angepasst:
################################################## #########################
## /etc/ntp.conf
##
## Beispiel-Konfiguration fuer xntp-Client und die Nutzung
## Beachten Sie auch das Package 'xntp-doc' für die DoKumentation, Mini-HOWTO and FAQ
##
################################################## #########################
# Time-Server Ihrer Abteilung (NTP Server im LAN)/ bevorzugter
# minimales/ maximales Abfrageintervall (Zweierpotenz in Sekunden)
#
server 192.168.0.1 prefer minpoll 5 maxpoll 10
# Sicherheitshalber bei Ausfall des angegebenen Time-Servers
# einen anderen Time-Server angeben(evtl.)
#
# server 192.168.x.y minpoll 15 maxpoll 17
#
# Zugriffschutz fuer Rechner ausserhalb der Abteilung.
# ersetzen Sie x.y durch Ihren Time-Server, wenn nicht vorhanden, dann
# Zeile loeschen.
# Ersetzen Sie a.b durch die letzten beiden Stellen der IP-Adresse Ihres
# Rechners.
#
restrict 192.168.0.1 # IP-Adresse Ihres Abteilungs-Servers
restrict 192.168.0.5 # eigene IP-Adresse
restrict 127.0.0.1 # local config
restrict default ignore
# Sonstige Einstellungen
#
driftfile /var/lib/ntp/ntp.drift # path for drift file
logfile /var/log/ntp # alternate log file
#
################################################## #########################
Dann habe ich noch das Runlevel konfiguriert:
chkconfig –list
...
xntpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
...
chkconfig –set xntpd on
chkconfig –list
...
xntpd 0:off 1:off 2:on 3:on 4:off 5:on 6:off
...
Nun wird beim Neustart die Zeit mit dem Server abgeglichen. All das funktioniert nun auch (nachdem ich eine Weile an den Windows Registry-Entries verzweifelt bin, die Linux wollte, so z.B. wird in vielen Dokumenten der ntpserver-Eintrag, welcher die IP-Adresse des NTP-Servers enthält, von dem synchronisiert wird, als optional aufgeführt aber SuSE Linux findet ohne diesen Eintrag keinen NTP-Server zum Synchronisieren).
Nun ein nochmaliger Test mit dem Kerberos-Befehl kinit zeigt, dass es nichts zu „meckern“ gibt:
linux:~# kinit User_01@SERVER.DE
Password for User_01@SERVER.DE:
linux:~#
---------------------------------------------------------------------------
Nun kommt endlich das Problem. Nachdem das alles lief, dachte ich, man könnte ja mal mit Samba anfangen und habe mir die letzte Version (Samba-3.0.0-final) geladen.
Die habe ich dann in den Ordner /samba-3.0.0/ entpackt und im Konsolenfenster in das Unterverzeichnis /source/ gewechselt. Darin dann den configuration script ausgeführt (./configure –with-ads). Vorher habe ich noch ./configure –help aufgerufen und unter den aufgeführten Optionen erschien mir die Option –with-ads, die einzig wichtige für mich zu sein.
In der Datei /samba-3.0.0rc4/source/include/config.h kontrolliert, dass folgende Zeilen existieren
/* Whether to have KRB5 support */
#define HAVE_KRB5 1
/* Whether ldap is available */
#define HAVE_LDAP 1
Im /source/ Verzeichnis habe ich die Anwendung mit der Anweisung make compiliert und danach die Anwendung mit der Anweisung make install installiert.
Das verlief meiner Meinung nach alles ganz ordentlich.
Dann habe ich in meiner /usr/local/samba/lib/smb.conf folgendes eingegeben:
# Global parameters
[global]
realm = SERVER.DE
security = ADS
ads server = 192.168.0.1
encrypt password = yes
Nun wollte/ sollte ich einen Computer Account (für den Linux Rechner)im Windows 2000 Active Directory erstellen. Dazu muß ich mich als Administrator auf dem Windows 2000 Server einloggen oder ich logge mich vom Linux-Rechner im Server ein. Das fand ich besser, da das auch gleich die Connection testet. Somit mußte ich den Kerberos-Befehl /usr/kerberos/bin/kinit administrator@SERVER.DE eingeben, der ja mit den User_01 – User_21 gut funktioniert hat. Doch nun kommt das Problem:
linux:~ # kinit administrator@SERVER.DE
Password for administrator@SERVER.DE:
kinit(v5): KDC has no support for encryption type while getting initial credentials
linux:~ #
Nach dem Passwort wird ja noch ganz anständig gefragt, aber dann kommt die Meldung, mit der ich nicht umzugehen weiß. Mit den Usern klappt es, aber nicht mit dem Administrator (oder adm… habe beides probiert).
Habe gerade bei weiteren Lösungsversuchen ein neues Problem festgestellt:
Im Webmin sind unter Systemkofiguration im Samba-Modul einige Pfade aufgeführt. Die habe ich jetzt alle korrigiert, so dass sie die Pfade enthalten, die in meinem System existieren. Danach kam ich zumindest schon in das richige Menü (Global Configuration, Shared Files, etc.). Doch dann gibt es ganz unten noch zwei Pfade mit dem Titel Command to start (bzw. stop) Samba servers und darin stehen standardmäßig /etc/init.d/smb start (bzw. stop). Diese Pfade dürften eigentlich stimmen, aber ich finde im gesamten System keine smb start (bzw. stop) Datei.
Irgendwie ist das mal wieder ein Stelle, an der ich stehen bleibe. Ich hatte zwar bis hierhin schon einige Probleme/ Unklarheiten, aber irgendwie habe ich mich dann doch weiterbewegt.
Falls Ihr/ Sie bis hier gelesen habt und eine Idee habt, wir Ihr/ Sie mir helfen könnt, würde ich mich über eine Mail sehr freuen.
Danke im voraus.
Andreas (kofi@freenet.de)
Hallo Allerseits,
hier ist mal wieder der ehemalige Praktikant Andreas, der an seiner Projektarbeit sitzt und sich von einem Problem zum nächsten hangelt.
Hier nochmal das Thema meiner Projektarbeit:
Thema der Projektarbeit (kurz):
Aufbau und Konfiguration einer zentralen Benutzerverwaltung in einerWindows 2000
Domäne mit Authentifizierung und Autorisierung der Benutzer anhand der ActiveDirectory-Benutzerdatenbank.
Anlage 1 (Thema lang):
In der Projekt GmbH werden die von den Windows-Clients benötigten und bearbeiteten Daten auf einem Samba-Dateiserver auf der Basis eines Linux-Systems gespeichert. Derzeit existieren drei Benutzerdatenbanken wobei die Benutzerdatenbank auf dem Windows 2000 Domaincontroller die einzige aktualisierte ist. Die Linux- und Samba-Benutzerdaten werden völlig unabhängig von der Windows-Datenbank gepflegt. Die Samba-Benutzerdatenbank entspricht der Linux-Benutzerdatenbank abzüglich der System-Benutzer und es existieren in diesen beiden Datenbanken auch viele veraltete Einträge. Es soll nun nur noch eine Benutzerdatenbank auf dem Windows 2000 Domaincontroller gepflegt werden, welche dem gesamten heterogenen Netzwerk zur Verfügung steht. Somit soll Samba auf die Benutzerdatenbank des Windows 2000 Domaincontrollers zugreifen.
Meine Aufgabe ist es, diese Umstellung durchzuführen und zu dokumentieren.
Ich habe das Thema in der letzten Woche des Praktikums bekommen und sitzte nun zu Hause mit meinem virtuell nachgestaltetem Netzwerk.
Bevor ich meine Fragen/ Probleme äußere, etwas zu den Vorraussetzungen, mit denen ich arbeite:
Also ich habe mir zu Hause das Netzwerk mit Hilfe des von der Firma erhaltenen VMware virtuell nachgestaltet. Da existieren ein Windows 2000 Server mit Active Directory als Domaincontroller, ein Windows 2000 Professional Client für die ganzen User und ein Linux-Rechner mit Samba 3.0 (Member Server ???).
Auf dem Active Directory Server habe ich 21 Benutzer in drei Benutzergruppen eingerichtet (User_01 – User_21, jeweils sieben in den Gruppen Projekt_Admin, Projekt_User und Projekt_Guest). Die Rechte der User entsprechen den der Gruppen, denen sie angehören, und die Rechte der Gruppen entsprechen denen ihrer Bezeichnungen (Admin, User, Guest).
Auf dem Windows 2000 Professional Client-Rechner sind nur die Standard-Systemnutzer eingerichtet/ vorhanden. Die ganzen 21 Nutzer melden sich am Server an. Auf dem Server habe ich auch testweise Freigaben für jede der Benutzergruppen bzw. eine für alle eingerichtet und das klappt auch alles.
Nun habe ich mich dem Linux-Rechner zugewandt und die OpenLDAP development libaries und die Kerberos development libaries installiert/ aktiviert. Dann habe ich in der /etc/krb5.con-Datei die Einträge geändert (dabei benötigt Kerberos die Domainbezeichnung immer in Großbuchstaben - Kleinbuchstaben werden nicht erkannt/ akzeptiert):
[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log
[libdefaults]
ticket_lifetime = 24000
default_realm = SERVER.DE
dns_lookup_realm = false
dns_lookup_kdc = false
[realms]
SERVER.DE = {
kdc = 192.168.0.1
default_domain = server.de
}
[domain_realm]
.server.de = SERVER.DE
server.de = SERVER.DE
[kdc]
profile = /var/kerberos/krb5kdc/kdc.conf
[appdefaults]
pam = {
debug = false
ticket_lifetime = 36000
renew_lifetime = 36000
forwardable = true
krb4_convert = false
}
Dann habe ich die Verbindung mit dem Kerberos-Befehl kinit getestet:
wenn server.de runtergefahren (zum Vergleich)
linux:~# kinit User_01@SERVER.DE
kinit(v5): Cannot contact any KDC for requested realm while getting initial credentials
wenn server.de hochgefahren (Domain-Name in Groß- und Kleinbuchstaben)
linux:~# kinit User_01@server.de
kinit(v5): Cannot find KDC for requested realm while getting initial credentials
linux:~# kinit User_01@SERVER.DE
Password for User_01@SERVER.DE:
kinit(v5): Clock skew too great while getting initial credentials
Da kam die nächste Aufgabe auf mich zu. Kerberos benötigt Zeitsynchronisation zwischen Windows 2000 Server/ Client und Linux Server, da das Standard-Authentifizierungs-Protokoll (Kerberos v5) die Zeit der Clients für den Prozess der Ticket-Erzeugung nutzt.
Somit habe ich einen Network Time Protocol (NTP) Server auf dem Windows 2000 Domaincontroller (Windows 2000 Server) eingerichtet, an dem sich alle orientieren können (das dieser selbst seine Zeit später noch mit einer externen Quelle abgleichen sollte, steht außer Frage).
Die Clients (Windows 2000 Professional, Client-Rechner) im LAN wurden dann so eingerichtet, dass sie ihre Systemzeit mit dem NTP-Server abgleichen. Das klappt auch alles und ich habe mich dann am Linux weiterprobiert.
Auf dem Linux-Rechners habe ich dann die xntpd (Network-Time-Protokoll-Daemon) Installation überprüft bzw. es installiert und dann die /etc/ntp.conf angepasst:
################################################## #########################
## /etc/ntp.conf
##
## Beispiel-Konfiguration fuer xntp-Client und die Nutzung
## Beachten Sie auch das Package 'xntp-doc' für die DoKumentation, Mini-HOWTO and FAQ
##
################################################## #########################
# Time-Server Ihrer Abteilung (NTP Server im LAN)/ bevorzugter
# minimales/ maximales Abfrageintervall (Zweierpotenz in Sekunden)
#
server 192.168.0.1 prefer minpoll 5 maxpoll 10
# Sicherheitshalber bei Ausfall des angegebenen Time-Servers
# einen anderen Time-Server angeben(evtl.)
#
# server 192.168.x.y minpoll 15 maxpoll 17
#
# Zugriffschutz fuer Rechner ausserhalb der Abteilung.
# ersetzen Sie x.y durch Ihren Time-Server, wenn nicht vorhanden, dann
# Zeile loeschen.
# Ersetzen Sie a.b durch die letzten beiden Stellen der IP-Adresse Ihres
# Rechners.
#
restrict 192.168.0.1 # IP-Adresse Ihres Abteilungs-Servers
restrict 192.168.0.5 # eigene IP-Adresse
restrict 127.0.0.1 # local config
restrict default ignore
# Sonstige Einstellungen
#
driftfile /var/lib/ntp/ntp.drift # path for drift file
logfile /var/log/ntp # alternate log file
#
################################################## #########################
Dann habe ich noch das Runlevel konfiguriert:
chkconfig –list
...
xntpd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
...
chkconfig –set xntpd on
chkconfig –list
...
xntpd 0:off 1:off 2:on 3:on 4:off 5:on 6:off
...
Nun wird beim Neustart die Zeit mit dem Server abgeglichen. All das funktioniert nun auch (nachdem ich eine Weile an den Windows Registry-Entries verzweifelt bin, die Linux wollte, so z.B. wird in vielen Dokumenten der ntpserver-Eintrag, welcher die IP-Adresse des NTP-Servers enthält, von dem synchronisiert wird, als optional aufgeführt aber SuSE Linux findet ohne diesen Eintrag keinen NTP-Server zum Synchronisieren).
Nun ein nochmaliger Test mit dem Kerberos-Befehl kinit zeigt, dass es nichts zu „meckern“ gibt:
linux:~# kinit User_01@SERVER.DE
Password for User_01@SERVER.DE:
linux:~#
---------------------------------------------------------------------------
Nun kommt endlich das Problem. Nachdem das alles lief, dachte ich, man könnte ja mal mit Samba anfangen und habe mir die letzte Version (Samba-3.0.0-final) geladen.
Die habe ich dann in den Ordner /samba-3.0.0/ entpackt und im Konsolenfenster in das Unterverzeichnis /source/ gewechselt. Darin dann den configuration script ausgeführt (./configure –with-ads). Vorher habe ich noch ./configure –help aufgerufen und unter den aufgeführten Optionen erschien mir die Option –with-ads, die einzig wichtige für mich zu sein.
In der Datei /samba-3.0.0rc4/source/include/config.h kontrolliert, dass folgende Zeilen existieren
/* Whether to have KRB5 support */
#define HAVE_KRB5 1
/* Whether ldap is available */
#define HAVE_LDAP 1
Im /source/ Verzeichnis habe ich die Anwendung mit der Anweisung make compiliert und danach die Anwendung mit der Anweisung make install installiert.
Das verlief meiner Meinung nach alles ganz ordentlich.
Dann habe ich in meiner /usr/local/samba/lib/smb.conf folgendes eingegeben:
# Global parameters
[global]
realm = SERVER.DE
security = ADS
ads server = 192.168.0.1
encrypt password = yes
Nun wollte/ sollte ich einen Computer Account (für den Linux Rechner)im Windows 2000 Active Directory erstellen. Dazu muß ich mich als Administrator auf dem Windows 2000 Server einloggen oder ich logge mich vom Linux-Rechner im Server ein. Das fand ich besser, da das auch gleich die Connection testet. Somit mußte ich den Kerberos-Befehl /usr/kerberos/bin/kinit administrator@SERVER.DE eingeben, der ja mit den User_01 – User_21 gut funktioniert hat. Doch nun kommt das Problem:
linux:~ # kinit administrator@SERVER.DE
Password for administrator@SERVER.DE:
kinit(v5): KDC has no support for encryption type while getting initial credentials
linux:~ #
Nach dem Passwort wird ja noch ganz anständig gefragt, aber dann kommt die Meldung, mit der ich nicht umzugehen weiß. Mit den Usern klappt es, aber nicht mit dem Administrator (oder adm… habe beides probiert).
Habe gerade bei weiteren Lösungsversuchen ein neues Problem festgestellt:
Im Webmin sind unter Systemkofiguration im Samba-Modul einige Pfade aufgeführt. Die habe ich jetzt alle korrigiert, so dass sie die Pfade enthalten, die in meinem System existieren. Danach kam ich zumindest schon in das richige Menü (Global Configuration, Shared Files, etc.). Doch dann gibt es ganz unten noch zwei Pfade mit dem Titel Command to start (bzw. stop) Samba servers und darin stehen standardmäßig /etc/init.d/smb start (bzw. stop). Diese Pfade dürften eigentlich stimmen, aber ich finde im gesamten System keine smb start (bzw. stop) Datei.
Irgendwie ist das mal wieder ein Stelle, an der ich stehen bleibe. Ich hatte zwar bis hierhin schon einige Probleme/ Unklarheiten, aber irgendwie habe ich mich dann doch weiterbewegt.
Falls Ihr/ Sie bis hier gelesen habt und eine Idee habt, wir Ihr/ Sie mir helfen könnt, würde ich mich über eine Mail sehr freuen.
Danke im voraus.
Andreas (kofi@freenet.de)