Samba als PDC

[ehorn]

Hallo zusammen,

bisher habe ich Samba in erster Linie als File-Server genutzt - das galt für den Verwaltungsbereich unserer Schule. Hier war es so, dass jeder Rechner einem (oder maximal zwei oder drei) bestimmten Personen zugeordnet war. Da brachte ein DC nicht viel, sondern Samba stellt hier nur Server-Verzeichnisse zur Verfügung, die beim Starten über Scripts auf den Clients eingebunden werden.

Im pädagogischen Bereich möchte ich nun einen uralten und baufälligen Server (MS Windows Server 2003) durch Samba ersetzen (Basis: SLES 10 SP2), vor allem, da wir immer mehr Rechner gespendet bekommen und plötzlich die Client-Lizenzen für den Windows Server ein Kostenproblem darstellen. Nun habe ich schon ziemlich viel mit Samba rumgespielt - aber inzwischen verzweifle ich. Ich habe es bisher in ich-weiß-nicht-wieviel-stündiger Arbeit nur ein einziges Mal geschafft, einen Windows-XP-Client an der Samba-Domäne anzumelden. Bei allen weiteren Versuchen (gleiches Basis-Image des Rechners, gleiche Kabel, selbst bei einem erneuten Versuch mit dem gleichen Client) erhalte ich immer die Fehlermeldung, dass der Domain-Controller nicht gefunden werden konnte - manchmal auch, dass der User nicht gefunden werden konnte, der zur Anmeldung berechtigt ist.

Ich kann mir eigentlich nicht vorstellen, dass es wirklich an der Samba-Konfiguration liegt. Diese gebe ich hier dennoch einmal an:

[global]
workgroup = schule
netbios name = server
wins support = yes
server string = Server

domain master = yes
local master = yes
preferred master = yes
os level = 250

host name lookups = yes

security = user
encrypt passwords = yes
domain logons = yes
map to guest = never

logon drive = h:
logon home = \\%N\%U

time server = yes

logon script = logon.bat
logon path =

add machine script = /usr/sbin/useradd -g computers -d /var/lib/nobody -s /bin/false %u$

[netlogon]
path = /home/local/sonstige/netlogon
read only = yes
writeable = no
browseable = no
writelist = @ntadmin

Kurz zur Erklärung der Grundkonfiguration (weitere Shares habe ich rausgelassen): "logon path" ist leer, weil ich lokale Profile erzwingen will (hat auch auf dem einen Client, der mal funktioniert hat, geklappt); aus dem gleichen Grund fehlt die PROFILES-Sektion.

Das Verrückte bei meinem Problem: Wenn ich die Clients in die Arbeitsgruppe "schule" bringe, kann ich über "\\server\freigabename" ohne Probleme auf die Shares zugreifen; Samba ist also ansprechbar. Wenn ich nun aber versuche, in die Domäne "schule" einzutreten, bekomme ich dauernd die oben erwähnten Probleme.

Mein Problem: Ich weiß im Moment nicht mehr, wo ich noch bei der Suche ansetzen soll. Hat jemand eine Ahnung, warum Samba Zugriffe auf die Shares bei gleicher Arbeitsgruppe erlaubt, aber sich weigert, die DC-Anmeldung anzunehmen (bzw. als DC nicht erreichbar zu sein scheint). Der frühere DC (Windows 2003) ist bei meinen Versuchen stets abgeschaltet gewesen, zudem habe ich längere Zeit (> 1 Stunde) gewartet, damit Samba seine DC-Dienste im Netzwerk anbieten kann.

Zuletzt noch eine ganz andere Frage: Mir ist ein Problem bei dem Client aufgefallen, der mal vorübergehend lief. Nutzer, die durch Samba angemeldet werden, haben keine lokalen Admin-Rechte. Die würde ich den Benutzern aber gerne geben (bzw. muss ich, weil viele Lernprogramme die erfordern). Bevor sich jetzt einer über den Sicherheitsaspekt aufregt: In allen Clients sind PC-Wächter-Karten installiert, die Veränderungen an den Clients nach einem Neustart rückgängig machen. Das ist für ein schulisches Umfeld eine sehr gute Lösung. - Die Frage also: Wie bekomme ich es hin, dass Benutzer innerhalb der Domäne lokale Admin-Rechte bekommen, ohne dass ich die Nutzer zusätzlich auf den Clients anlegen und von Hand mit Admin-Rechten ausstatten muss. Beim Test-Client war nämlich das Problem, dass nicht einmal die "Default User"-Dateien gelesen werden dürften, weshalb der Client in der Windows-Grundkonfiguration und mit englischer Tastatur startete [wegen erzwungenen lokalen Profilen].

Bei Suchen im Internet habe ich gefunden, dass angeblich der Befehl

net groupmap add ntgroup="Domain Admins" unixgroup="smbusers"

dafür sorgen soll, wobei natürlich "smbusers" dann die primäre Gruppe der Samba-User sein muss. Habe ich so gemacht, hat aber keinerlei Auswirkungen gehabt.

Für alle Tipps vielen Dank im Voraus.

 

[nathanhi]

Hi,

soviel ich weiss funktioniert das nicht, dass man einem Domaenenuser auf dem Client direkt Adminrechte gibt, ohne dies auf jedem PC einzeln einzustellen. Zumindest habe ich leider keinen anderen Weg gefunden. Ich benutze einfach lokale Admins in der Schule und die Kiste rennt. (Muss man ja nich ewig dran rumfummeln..)

Gruesse,
Nathan

 

[saeckereier]

Doch es geht, und das net groupmap ist der richtige Weg. Aber erstmal in die Domäne reinkommen: Ein Basis-Image... Details? Das könnte bereits die Ursache sein. Wie wird das erstellt und wie wird es auf die Kisten aufgebracht? Welche Nacharbeiten werden durchgeführt. Eigentlich ist das kein Linux Thema und daher hier falsch, mal sehen, evtl. können wir doch etwas helfen..

 

[kuaza]

Hab mir mal für mich ein tutorial zusammen gestellt! vielleicht hilft dir ja das weiter.

[global]
workgroup = DOMAINNAME
netbios name = server
socket options = TCP_NODELAY IPTOS_LOWDELAY SO_RCVBUF=16384 SO_SNDBUF=16 384
printcap name = cups
add machine script = /usr/sbin/useradd -c Machine -d /var/lib/nobody -s /bin/false %m$
logon script = %G.bat
logon path = \\%L\profiles\%U
logon drive = U:
logon home = \\%L\%U
domain logons = Yes
os level = 80
domain master = Yes
wins proxy = Yes
wins support = Yes
ldap ssl = no
admin users = root


6.1. User die Rechte geben

Um auf einem PC genau einem User Administratorrechte zu geben muss man sich zuerst als lokaler Administrator anmelden. Unter der Systemsteuerung nun die Benutzerkonten öffnen und dort auf Benutzerkonten klicken. Unter dem nun erschienen Fenster den Reiter Erweitert anwählen und den Button Erweitert klicken. Danach den Menüpunkt Gruppen öffnen und mit der rechten Maustaste auf Administratoren klicken. Nun kann über Mitglied hinzufügen der am Sambaserver liegende Benutzer hinzugefügt werden.

6.2. Gruppe die Rechte geben.

Unter Linux die Gruppe ntadmins anlegen und die Benutzer welche Administratorrechte am Windows-PC erhalten sollen hinzu fügen:
#groupadd ntadmins
#usermod -G ntamdins user

Jetzt muss diese Gruppe dem Sambaservice noch bekannt gegeben werden:
#net groupmap add unixgroup=ntadmins ntgroup="Domain Admins"

Nun kann wie unter Punkt 6.1. beschrieben vorgegangen werden. Anstatt dem Beutzer dem man zur Gruppe Adminstratoren hinzufügt gibt man jetzt die Gruppe Domain Admins an. Danach kann sich jeder Benutzer welcher in der Gruppe ntadmins ist mit Adminstratorrechten am Windows-PC anmelden.

Falls notwendig kann eine angelegte Gruppe kann mit folgendem Befehl wieder gelöscht werden:
#net groupmap delete ntgroup="Domain Admins"

kurzer erklärung:

add machine script .... wird ein unbekannter pc (name) in die domain eingebunden so wird automatisch dieser in linux angelegt.
os level = 80 .... umso niedriger das os level umso höher die priorität des pdc, sollte ein pdc mit geringerem os level gefunden werden so wird dieser bevorzugt.

hoffe das ist was du suchst

 

[NoXqs]

os level = 80 .... umso niedriger das os level umso höher die priorität des pdc, sollte ein pdc mit geringerem os level gefunden werden so wird dieser bevorzugt.

Genau andersrum.
Je höher der Wert, desto wahrscheinlicher ist, dass Samba gewinnt.

os level = Zahl
Zulässige Werte: Integer
[global]
Default: 20
Legt die Kandidatur des Servers bei der Wahl eines Hauptsuchdienstes fest. Wird zusammen mit den Optionen domain master oder local master verwendet. Sie können einen Wert einstellen, der höher ist als der eines konkurrierenden Betriebssystems, falls Sie wollen, dass Samba gewinnt. Windows for Workgroups und Windows 95/98/Me verwenden 1. Die Systeme Windows NT/2000/XP benutzen 16, wenn sie nicht als PDC agieren, und 32, wenn sie PDC sind. Warnung: Dadurch können unerwartet Nicht-Samba-Suchdienste außer Kraft gesetzt werden.

Quelle: http://www.oreilly.de/german/freebooks/samba2ger/appb.html#988775

 

[ehorn]

Ein Basis-Image... Details? Das könnte bereits die Ursache sein.

Das schließe ich meinerseits aus. Basis-Image ist ein Windows XP Pro SP3 mit allen Patches, die bis Ende Mai 2009 verteilt wurden. Sonst kaum was drauf auf den Images (OpenOffice, Gimp - das war es schon). Das Image selbst wurde mit Acronis TrueImage 11 erstellt und auch wieder zurück gelesen. Das Kuriose: Es hat ja schon ein Mal geklappt, einen Rechner auf Basis dieses Image in die Domäne zu bekommen - und danach nie wieder. Obwohl ich alles jeweils gleich gemacht habe. Und im Gegensatz dazu kann ich vom Roh-Image ohne Probleme sofort in die Domäne eintreten, wenn ich stattdessen den alten W2K3-Server laufen lasse. Also sollte es auch keine Probleme bei den Clients geben, überhaupt einer Domäne beizutreten. Irgendwie scheinen die Clients aber im Normalfall den Samba-PDC nicht zu finden - obwohl ich (wie schon geschrieben) auf Samba-Shares ohne Probleme zugreifen kann.

Ein Problem fällt mir gerade ein, vielleicht weiß jemand, ob es das sein kann: Damit das alte Netzwerk weiterlaufen kann, arbeite ich in verschiedenen IP-Bereichen. Das alte Netzwerk läuft unter 192.168.*/16 (ja, ist ungewöhnlich, halt ein Shared-Klasse-B-Netzwerk, hat "historische Gründe"). Das neue Netzwerk soll nun unter 10.*/8 laufen. Damit ich - solange es noch nicht läuft - nicht zu viel umkonfigurieren muss, habe ich den alten Router, der auch DNS-Server des Netzwerkes ist (ein IP-Cop) im 192.168.*/16 gelassen. Der neue Server und die Clients laufen in 10.*/8. Die beiden Netzwerke benutzen das gleiche physikalische Netzwerk. Der DC des alten Netzwerkes wird bei Versuchen immer abgeschaltet, damit er nicht dazwischen funken kann, dann warte ich eine ganze Zeit (ca. 1 Stunde) und teste dann die Anmeldung. An sich würde ich denken, dass das so kein Problem darstellen dürfte. Oder kann es doch sein, dass aufgrund des fehlenden DNS-Servers im 10.*/8-Netzwerkes kein DC gefunden wird? Ich wäre davon ausgegangen, dass eine DC-Client-Verbindung auch ohne DNS-Server zustande kommen kann, weil es doch eigentlich keiner DNS-Auflösung bei dem Vorgang bedarf. Oder bin ich da jetzt komplett auf dem Holzweg?

 

[ehorn]

Habe heute noch mal ein paar Stunden mit dem Problem verbracht - und oh Wunder: Den einen PC, den ich schon mal in die Domäne gebracht habe, hat nach x Anläufen auch wieder funktioniert. Werde in den nächsten Tagen mal das Image dieses PCs auf einen zweiten überspielen und schauen, ob es doch am Basis-Image liegt (glaube ich eigentlich nicht, weil alle vorher aus dem gleichen Image geklont worden sind und danach nichts verändert wurde).

Das Problem bleibt insgesamt das Gleiche: Alle anderen PCs sagen immer wieder, dass sie die Domäne nicht gefunden haben, wenn ich beitreten möchte. Gleichzeitig kann ich mich auf dem einen eingebundenen Rechner ohne Probleme anmelden und auf die zugewiesenen Shares zugreifen.

Habe nun mal Samba ein bisschen was loggen lassen - und siehe da: es kommen Fehlermeldungen, mit denen ich aber nichts anfangen kann. Ich gebe hier mal das komplette Protokoll von /var/log/samba/log.nmbd seit einem Reboot des Servers heute Mittag:

[2009/07/08 13:00:32, 0] nmbd/nmbd.c:main(723)
Netbios nameserver version 3.0.32-0.11-2115-SUSE-CODE10 started.
Copyright Andrew Tridgell and the Samba Team 1992-2008
[2009/07/08 13:00:32, 0] nmbd/asyncdns.c:start_async_dns(151)
started asyncdns process 5473
[2009/07/08 13:00:32, 0] nmbd/nmbd_logonnames.c:add_logon_names(163)
add_domain_logon_names:
Attempting to become logon server for workgroup MKG on subnet 10.0.0.2
[2009/07/08 13:00:32, 0] nmbd/nmbd_logonnames.c:add_logon_names(163)
add_domain_logon_names:
Attempting to become logon server for workgroup MKG on subnet 127.0.0.2
[2009/07/08 13:00:32, 0] nmbd/nmbd_logonnames.c:add_logon_names(163)
add_domain_logon_names:
Attempting to become logon server for workgroup MKG on subnet UNICAST_SUBNET
[2009/07/08 13:00:32, 0] nmbd/nmbd_become_dmb.c:become_domain_master_browser_wins(335)
become_domain_master_browser_wins:
Attempting to become domain master browser on workgroup MKG, subnet UNICAST_SUBNET.
[2009/07/08 13:00:32, 0] nmbd/nmbd_become_dmb.c:become_domain_master_browser_wins(349)
become_domain_master_browser_wins: querying WINS server from IP 127.0.0.2 for domain master browser name MKG<1b> on workgroup MKG
[2009/07/08 13:00:33, 0] nmbd/nmbd_logonnames.c:become_logon_server_success(124)
become_logon_server_success: Samba is now a logon server for workgroup MKG on subnet UNICAST_SUBNET
[2009/07/08 13:00:37, 0] nmbd/nmbd_logonnames.c:become_logon_server_success(124)
become_logon_server_success: Samba is now a logon server for workgroup MKG on subnet 10.0.0.2
[2009/07/08 13:00:37, 0] nmbd/nmbd_logonnames.c:become_logon_server_success(124)
become_logon_server_success: Samba is now a logon server for workgroup MKG on subnet 127.0.0.2
[2009/07/08 13:00:53, 0] nmbd/nmbd_nameregister.c:register_name_response(130)
register_name_response: WINS server at IP 10.0.0.2 rejected our name registration of MKG<1b> IP 10.0.0.2 with error code 5.
[2009/07/08 13:00:53, 0] nmbd/nmbd_become_dmb.c:become_domain_master_fail(70)
become_domain_master_fail: Failed to become a domain master browser for workgroup MKG on subnet UNICAST_SUBNET. Couldn't register name MKG<1b>.
[2009/07/08 13:00:53, 0] nmbd/nmbd_namelistdb.c:standard_fail_register(304)
standard_fail_register: Failed to register/refresh name MKG<1b> on subnet UNICAST_SUBNET
[2009/07/08 13:00:55, 0] nmbd/nmbd_become_lmb.c:become_local_master_stage2(396)
*****

Samba name server PYTHAGORAS is now a local master browser for workgroup MKG on subnet 10.0.0.2

*****
[2009/07/08 13:00:55, 0] nmbd/nmbd_become_lmb.c:become_local_master_stage2(396)
*****

Samba name server PYTHAGORAS is now a local master browser for workgroup MKG on subnet 127.0.0.2

*****
[2009/07/08 13:00:55, 1] nmbd/nmbd_incomingrequests.c:process_node_status_request(32
process_node_status_request: status request for name MKG<1b> from IP 127.0.0.2 on subnet UNICAST_SUBNET - name not found.
[2009/07/08 13:00:55, 1] nmbd/nmbd_incomingrequests.c:process_node_status_request(32
process_node_status_request: status request for name MKG<1b> from IP 127.0.0.2 on subnet UNICAST_SUBNET - name not found.
[2009/07/08 13:01:01, 1] nmbd/nmbd_incomingrequests.c:process_node_status_request(32
process_node_status_request: status request for name MKG<1b> from IP 127.0.0.2 on subnet UNICAST_SUBNET - name not found.
[2009/07/08 13:01:01, 1] nmbd/nmbd_incomingrequests.c:process_node_status_request(32
process_node_status_request: status request for name MKG<1b> from IP 127.0.0.2 on subnet UNICAST_SUBNET - name not found.
[2009/07/08 13:01:06, 1] nmbd/nmbd_incomingrequests.c:process_node_status_request(32
process_node_status_request: status request for name MKG<1b> from IP 127.0.0.2 on subnet UNICAST_SUBNET - name not found.
[2009/07/08 13:01:06, 1] nmbd/nmbd_incomingrequests.c:process_node_status_request(32
process_node_status_request: status request for name MKG<1b> from IP 127.0.0.2 on subnet UNICAST_SUBNET - name not found.
[2009/07/08 13:01:11, 1] nmbd/nmbd_incomingrequests.c:process_node_status_request(32
process_node_status_request: status request for name MKG<1b> from IP 127.0.0.2 on subnet UNICAST_SUBNET - name not found.
[2009/07/08 13:01:11, 1] nmbd/nmbd_incomingrequests.c:process_node_status_request(32
process_node_status_request: status request for name MKG<1b> from IP 127.0.0.2 on subnet UNICAST_SUBNET - name not found.
[2009/07/08 13:01:16, 0] nmbd/nmbd_browsesync.c:domain_master_node_status_fail(24
domain_master_node_status_fail:
Doing a node status request to the domain master browser
for workgroup MKG at IP 127.0.0.2 failed.
Cannot sync browser lists.
[2009/07/08 13:01:16, 0] nmbd/nmbd_browsesync.c:domain_master_node_status_fail(24
domain_master_node_status_fail:
Doing a node status request to the domain master browser
for workgroup MKG at IP 127.0.0.2 failed.
Cannot sync browser lists.

Was mir schon auffällt: Der WINS wird immer mit dem Domänennamen "MKG<1b>" angesprochen, also (wenn ich das richtig verstehe) mit einem angehängten Escape-Zeichen. Ist das richtig? Dann scheint auch der Fehler beim WINS zu bestehen. Ich denke, das Problem steht und fällt mit der LOG-Zeile:

[2009/07/08 13:00:53, 0] nmbd/nmbd_nameregister.c:register_name_response(130)
register_name_response: WINS server at IP 10.0.0.2 rejected our name registration of MKG<1b> IP 10.0.0.2 with error code 5.

Ich habe einige Einträge im Internet gefunden, dass ähnliche Probleme nicht mehr bestanden, wenn man WINS SUPPORT auf "no" gestellt hat. (Kann das leider nicht testen, weil ich im Moment wieder zuhause bin.) Brauche ich denn überhaupt für einen PDC einen WINS-Support?

 

[ehorn]

Es lag tatsächlich am Eintrag

wins support = Yes

Nachdem ich den auf "No" gesetzt habe, läuft alles einwandfrei. Habe allerdings eine andere Merkwürdigkeit: Ich stelle die Clients ja - wie gesagt - von einem Basis-Image her. Dieses war noch nicht an der Domäne angemeldet. Als Standard heißt der Rechner nach dem Wiederherstellen des Image "REFERENZ" und ist in einer Arbeitsgruppe "MKG" (gleichlautend wie die Domäne, weil ich dann auf eine offene Nur-Lese-Freigabe des PDC zugreifen kann, die im Notfall Installationsprogramme enthält, z.B. für besondere Treiber etc.). Wenn ich nun versuche, den Rechner in die Domäne einzubinden (also unter "Netzwerkidentifikation / Netzwerkkennung") und dem Client dann einen vernünftigen Namen geben will (sagen wir RAUM1-PC01), geht das nicht in einem Durchgang. Ich erhalte dann beim Einbinde-Vorgang am Ende immer eine Fehlermeldung, dass der Benutzername nicht bekannt sei (gebe bei der Einbindung die root-Daten ein). Ich kann den PC nur in die Domäne aufnehmen, wenn ich folgenden Ablauf einhalte:

• Umbenennen des Rechners in "RAUM1-PC01" in der Arbeitsgruppe "MKG"
• Neustart von Windows XP
• Durchlauf des Einbinde-Vorgangs für die Domäne

wobei Letzteres dann so durchläuft, wie es sein soll. Finde ich komisch, dass ich nicht gleichzeitig die Umbenennung des Clients und die Einbindung in die Domäne vornehmen kann ...

 

[fje_84]

Das ist normal

Wenn du einen Client umbennenst muss der Name erst von dem Betriebsystem selbst übernommen werden damit er sich nach einem Neustart richtig meldet.

Wie in deinem Beispiel RAUM1-PC1

Hab bis heute keine Möglichkeit gefunden das zu umgehen

LG

Franz