Windows 7 an Skolelinux-Domäne anbinden

Die Anbindung von Win7 Workstations ist leider nicht mehr so zu erledigen, wie noch unter WindowsXP.

Um überhaupt eine Anmeldung zustande zubringen, müssen auf alle Fälle Samba >= 3.3. geupdatet werden und einige Änderungen an der Win7 WS vorgenommen werden.

Die Anleitung im Samba-Wiki dazu ist gut nachvollziehbar und scheint auch immer zu funktionieren:

http://wiki.samba.org/index.php/Windows7

Damit sollte man sich am tjener anmelden können und bekommt auch sein Home-Verzeichnis H:\ zur Verfügung gestellt.

Änderungen an der Windows 7 Workstation

Ich fasse hier einmal alle Änderungen, die ich an der Win7 WS vorgenommen habe, zusammen.

Das betrifft v.a. Änderungen in der Registry (regedit.exe) und den Gruppenrichtlinien (gpedit.msc).

Letztendlich sind das aber alles Anregungen aus dem Web, widersprüchliche manchmal, die ich ausprobiert oder verworfen habe. Es ist überhaupt nicht gesagt, dass es nicht auch ohne einige dieser Änderungen auch funktionieren könnte, bzw. dass es andere "bessere" geben könnte (der berühmte verborgene Schlüssel "MakePleinLinuxSambaCompatibility" DWORD:1).

- this is a wiki, feel free make it better -

15.1.2011: Anmelden auf neuer HW scheitert!

Ein weiteres Problem: Nachdem wir unseren Daten auf eine neue Hardware migriert haben, wollten wir auch die neuen Win7-Notebooks, die bereits am alten Tjener gelaufen sind, am neuen Server anmelden.

Die Maschinenanmeldung lief wie gewohnt, allerdings war es danach nicht möglich, sich als Domänen-User anzumelden.

Fehlermeldung:  "Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne scheiterte."

Habe unten noch einen weiteren Parameter hinzugefügt, der angeblich bei samba/openldap helfen könnte, sicher ist das aber nicht. Auf alle Fälle scheint es nicht im Nachhinein zu funktionieren, momentan ist Neuinstallation vin Win7 angesagt!

Wichtige Modifikationen:

zuerst die must-dos in der Registry, ohne die gar nichts geht, neben dem samba-upgrade am Tjener:

 HKLM\System\CCS\Services\LanmanWorkstation\Parameters
            DomainCompatibilityMode DWORD  = 1

            DNSNameResolutionRequired DWORD  = 0

 HKLM\System\CCS\Services\Netlogon\Parameters
           RequireSignOrSeal DWORD = 1

           RequireStrongKey DWORD = 1

ein Eintrag, der in den internationalen Listen immer wieder kommt und empfohlen wird; - muss erst hinzugefügt werden

 HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System
           EnableLinkedConnections DWORD = 1

soll die Abarbeitung des login-Skripts sicherstellen ? - muss erst hinzugefügt werden

 HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System
           RunLogonScriptSync DWORD = 1

Eintrag, um zu verhindern, dass die Maschine nach 30 Tagen ihr PW ändert und sich so nicht mehr anmelden kann. Ob's stimmt?

 HKLM\System\CCS\Services\Netlogon\Parameters
            DisablePasswordChange DWORD  = 1

            maximumpasswordage DWORD  = 3e7

(15.1.2011) Nachdem beim Migrieren auf eine neue HW nac h der Maschinenanmeldung die User sich nicht mehr anmelden konnten ("Vertrauensstellung ...") habe ich noch folgenden Eintrag gefunden, der hier vielleicht Abhilfe schaffen könnte , bezieht sich konkret auf Samba und openldap:

sambaRefuseMachinePwdChange = 1
    (in the sambaDomainName=.... entry.)

Der folgende Eintrag hat nichts mit der Domänanmeldung zu tun, aber er verhindert das <Ctrl-Alt-Delete >beim Anmelden, da jetzt sowieso schon 2 Schaltflächen mehr geklickt werden müssen, wenn man den User wechselt, wollte ich mir wenigstens das ersparen:

 HKLM\Software\Microsoft\WindowsNT\CurrentVersion\Winlogon
           DisableCAD DWORD = 1

 HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System
           DisableCAD DWORD = 1

und dann noch eine Gruppenrichtlinie, die auch für einen problemlosen Zugriff auf Samba-Freigaben gut sein soll:

Systemsteuerung - Verwaltung - Lokale Sicherheitsrichtlinie

Lokale Richtlinien - Sicherheitsoptionen   ändern:

           Netzwerksicherheit: LAN-Manager-Authentifizierungsebene -> "LM und NTLM-Antworten senden"

           Netzwerksicherheit: Minimale Sitzungssicherheit für NTLM-SSPbasierte Server (einschl. sicherer RPC-Server) 
                      -> 128-Bit-Verschlüsselung erfordern" muss deaktiviert werden

Ausführen des Login-Skripts / Mappings

Meist (????) wird bei der Anmeldung das Login-Skript im netlogon-Verzeichnis am Tjener nicht richtig abgearbeitet, zumindest sind die verschiedenen Samba-Mappings nicht sichtbar.

Abhilfe schafft hier die login.bat an der WS nach dem Einloggen, aber am Tjener (in Netzwerk-Tjener-netlogon) auszuführen, dann funktioniert das Mapping korrekt, d.h. es werden nur die Freigaben des einzelnen Users angezeigt. Ein solches Abarbeiten des Skripts nach dem Login könnte natürlich auch automatisiert geschehen. Die Frage ist allerdings auch, ob das ganze wirklich notwendig ist.

Sofort nach dem Anmelden bekommt der User auf alle Fälle sein Homeverzeichnis gemappt, das auch auf dem Desktop als MyHome-Link <myHome_symbol> angezeigt wird. Dort sieht der User seine ganzes Home auch mit den Profilen, und hat außerdem diverse Möglichkeiten im LAN zu navigieren < myHome.png>

Einerseits gibt es da den Link auf "Computer" (auch direkt erreichbar über Windows-Startsymbol -- Computer).

Hier sieht man alle lokalen Laufwerke und evt. angeschlossene externe Datenträger (so wie "Arbeitsplatz" bei XP) und falls die Abarbeitung der login.bat beim Anmelden erfolgreich war, auch die jeweiligen Samba-Mappings des Users.

Wenn nicht (und das ist doch relativ häufig der Fall) wird hier nur das Mapping auf das Homeverzeichnis H:\ angezeigt. In diesem Fall kann man nun durch Starten der login.bat über die Netzwerkumgebung das fehlende Mapping "nachholen" und es wird dann unter "Computer" auch korrekt angezeigt.

<Computer_Browser2.png>

Die zweite Möglichkeit, auf die Freigaben zugreifen, geht über den Link "Netzwerk-tjener". Damit erscheinen sofort alle Freigaben am Tjener, auch die, in denen der User keine Rechte hat.

<myHome_netzwerk2.png>

Wobei natürlich zu sagen ist, dass der User - auch wenn er alle Freigaben sieht - trotzdem die ihm nicht erlaubten nicht öffnen kann. Es erscheint ein Fenster "Zugriff verweigert".

Hier könnte man sogar, (ähnlich wie bei gnome- Verbindung zu Server) die Daten eines berechtigten Users eingeben und sich verbinden, ohne den angemeldeten User abzumelden. Bei XP war das in meiner Erinnerung nicht so einfach.

<zugriff_verweigert.png>

Lange Wartezeit bei Anmeldung

Standardmäßig dauert der Anmeldeprozess eines Users auf einer Win7-WS am der Domäne 30 Sekunden, durch folgendes Workaround kann das drastisch reduziert werde:

 . gpedit.msc

 Computerkonfiguration - Administrative Vorlagen - System - Benutzerprofile

 letzter Eintrag: "Maximale Wartezeit für das Netzwerk festlegen, wenn Benutzer servergespeicherte ..." doppelklicken

 aktivieren

 Wert auf 0 setzen

Servergespeicherte Profile

Allerdings speichert Win7 nicht immer (??? - ich konnte keinen nachvollziehbaren Grund finden) Änderungen am Profil eines Users beim Abmelden zurück - und lässt dann auch noch das Profil-Verzeichnis auf der lokalen Platte.

Generell ist es so, dass ab Vista Microsoft Änderungen beim Speicherort der Profile vorgenommen hat, nämlich lokal von C:\Dokumente und Einstellungen auf C:\Users.

Und ebenfalls am Domain-Server: Dort liegt jetzt im Homeverzeichnis des Users ein Verzeichnis /Profile (mit den XP-Daten) und ein Verzeichnis /profile.V2 auf das Windows 7 zugreift.

Ein gemeinsames Profil für XP und Win7 dürfte damit nur sehr schwer realisierbar sein, ist allerdings auch fraglich, ob das Sinn machen würde.

Problem mit "temporären Profil"

Manchmal erscheint nach dem Anmelden kurz ein Fenster, dass darauf hinweist, dass der Benutzer nur mit einem "temporären Profil" angemeldet wurde. Das passiert z. B, wenn man die User_verzeichnisse in C:/Benutzer löscht, weil sie aus irgendwelchen Gründen dort nicht korrekt nach dem Abmelden entfernt wurden und langsam die Platte zumüllen. Das verlangsamt einerseits natürlich den Anmeldeprozozess erheblich, da jedesmal für diesen User Windows neu eingerichtet werden muss; andererseits sind damit alle user-spezifischen Einstellungen weg, auch wenn sie nach wie vor im V2-Profil am Server liegen. Windows ignoriert dies aber. Ich hab bei MS einen Workaround für Vista gefunden, der (ein bisserl anders in Win7) so zu funktionieren scheint.

 regedit.exe (als lokaler Administrator) aufrufen

 zu HKLM-Software-Microsoft-WindowsNT-CurrentVersion-ProfileList


Testprotokoll

Bis ich ( oder wer anderer) gesicherte Ergebnisse hat, schreibe ich derweil meine Testbemerkungen hier herein:

Mo, 30.8.20010:

Begonnen verschiedene Registry-Einträge aus der Linkliste zu probieren. Erste Ergebnisse schienen gut. Es wurde über Start-Computer wirklich die jeweiligen Mappings angezeigt. Im Unterschied dazu kann / (konnte- auch schon vorher) man über Arbeitsplatz-Netzwerk auchalleMappings sehen und die, für die man berechtigt ist - auch öffnen. Dieses Anzeigen der Mappings in "Computer" ist allerdings nicht immer geschehen, ohne dass mir klar war, warum. Meist war es so, dass wenn es einmal klappte, es eine Zeitlang funktionierte (bei fast allen ?!) und dann plötzlich wieder nicht.

Das Anmelden dauert sehr lang (30-32 Sekunden)

Beim erstmaligen Anmelden eines Users klappte das gut und es wurde am Tjenner in /home0 in dem jeweiligen Benutzerverzeichnis ein weiteres Verzeichnis "Benutzer.V2" angelegt. Allerdings wird auch für das Verzeichnis in C:\Benutzer angelegt und nicht mehr gelöscht. Bei vielen Usern auf einem Gerät füllt das dann ganz schön die Platte.

Also habe ich die angelegten Benutzer auf C:¿Benutzer einmal gelöscht und damit ging das ganze Schlamassel erst richtig los

Di, 31.8.2010:

Die zuvor lokal gelöschten Benutzer kann ich nicht mehr wie vorher anmelden; d.h. sie melden sich an an der Domäne , kurz nach der endgültigen Anmeldung erscheint ein Fenster, dass darauf hinweist, dass der Benutzer nur "temporär" angemeldet ist und keinerlei Änderungen an den Server zurückgeschrieben werden. Was stimmt. Was aber auch bedeutet, dass der Anmeldeprozess wieder viel länger wird, da jedesmal Windows neu eingerichtet wird. Manchmal klappt es dann dann, wenn man auch am Tjenner das V2-Verzeichnis löscht, aber auch nur manchmal; bestimmte User kann ich überhaupt nur mehr temporär anmelden und ich habe keine Ahnung, warum gerade diese. Jedenfalls sieht es so aus, das Windows irgendwo massenhaft Informationen über einmal angemeldete User sammelt und die dann irgendwie abgleicht und dann das zurückschreiben auf das Servergespeicherte Profil verhindert. Wahrscheinlich müsste man hier an den lokalen Gruppenrichtlinien (gpedit.msc) drehen, aber da gibt es soviele Einträge, die ich überhaupt nicht verstehe. Übrigens auch ein Abmelden und neuerliches Anmelden an der Konsole hat nichts gebracht.

kleiner Erfolg: Die Anmeldezeit habe ich auf 3 - 5 Sekunden heruntergebracht durch Änderung über gpedit.msc (s. oben)

14h : plötzlich werden die Mappings wieder über "Computer" angezeigt, bei allen Usern, die ich versucht habe.

halbe Stunde später: wieder nichts, keine Mapping mehr! Ich habe das Gefühl, wann immer ich irgendwas ändere (regedit, gpedit) geht es nachher, wenn es vorher nicht gegangen ist und umgekehrt. Habe jetzt bei einem User (mit temporären Profil) über Netzwerk-Tjenner-netlogon die login.bat gestartet und dann waren die Mappings wieder sichtbar, und nun auch bei allen anderen usern die ich der reihe nach noch probiert habe. Bis zur nächsten Änderung wahrscheinlich.

Das Problem mit temporären Profils komme ich kein Stück näher, habe mittels suchen in der Registry gefunden, dass die einzelen Usern tatsächlich zig-mal fest wo drinnen stehen, aber absolut keine Ahnung wie man dagegen was machen könnte. Jetzt hab ich mal von der MS-Knowlegebase einen Trick zu Vista versucht umzulegen, das scheint zu funktionieren; Anleitung siehe oben.

Wie nicht anderes erwartet, haben nach dieser Änderung die Mappings wieder funktioniert :) Trotzdem denke ich mir, dass es wohl z.Zt. am gescheitesten sein würde, nach dem Einloggen automatisch die login.bat am Tjenner nochmals aufzurufen, das scheint wenigsten halbwegs gesicherte Ergebnisse zu bringen!

Ach ja, Wunder. Zur Zeit funktionieren auch die Roaming Profiles, also nach dem Abmelden, sind die User wieder aus C:/Benutzer weg.

Mi, 1.9.2010:

Noch verschieden Einstellungen ausprobiert, mit ähnlichen Effekten wie bisher. Hinzugefügt noch den DisablePasswordChange, soll verhindern, dass die Maschine nach 30 Tagen ihr PW eigenständig ändert; Überprüfung in 30 Tage :)

Glaube aber, dass das System soweit funktioniert (stabil würde ich es ja nicht nennen), dass man damit im skole-Netz arbeiten kann. Habe deshalb den Wikibeitrag oben so ergänzt/umgeschrieben, dass er auch für andere brauchbare Informationen bringt, und das werde das auch posten. Allerdings habe ich bis jetzt nur auf einem Notebook getestet, hoffentlich gibt nicht neue Probleme, wenn die restlichen geklont sind und sich derselbe Benutzer auf verschiedenen Geräten einlogt.

Das Testprotokoll lösche ich noch nicht, wer weiss, was es noch für Überraschungen gibt.

BgWin7 (last edited 2013-11-03 12:10:36 by anonymous)

Alle Inhalte in diesem Wiki stehen unter der GPL.