Hallo Dorian,
tut mir Leid: das weiß ich nicht.
Ich würde sagen: mach ein Backup vom Server und dann probier das aus …
LG
Holger
Ich hab nochmal ein bisschen rumgesucht und das Tool dcgpofix scheint es nur für Windows server zu geben …
Dann muss ich wohl woanders suchen 
VG, Dorian
Folgender Fehler ist mir jetzt noch aufgefallen:
Starting test: SysVolCheck
Das SYSVOL ist nicht bereit. Dies kann dazu führen, dass der Domänencontroller nach dem Ausführen von
"dcpromo" nicht als Domänencontroller für die Anmeldung angekündigt wird. Probleme mit der
FRS-SYSVOL-Replikation können zudem zum Auftreten von Problemen mit der Gruppenrichtlinie führen. Weitere
Informationen finden Sie im FRS-Ereignisprotokoll des Domänencontrollers.
......................... Der Test SysVolCheck für SERVER ist fehlgeschlagen.
Es scheint also irgendwie mit dem sysvol zutun zu haben, kennt sich da jemand aus?
VG, Dorian
Hallo Dorian,
muss zum Check nicht vorher neu gestartet werden?
Gruß
Alois
Hi Alois,
Keine Ahnung 
Wie kommst du drauf? Und meinst du den Client oder den Server?
VG, Dorian
Hallo Dorian,
normalerweise müssen die Festplatten ausgehängt sein wenn sie geprüft werden, oder geht es nicht um Festplatten in Deinem Fall?
Gruß Alois
Hi Alois,
Nein, es geht um das Samba AD.
VG, Dorian
Hallo Dorian,
da war der Begriff SysVol der mich annehmen ließ es ging um eine Festplatte.
Gruß
Alois
Hi Alois,
Ah, achso 
Es geht ums AD Sysvol, da werden dei GPOs gespeichert.
VG, Dorian
Hallo Dorian,
ein Samba ist kein Windows Server. Die von dcdiag abgefragten Funktionen und Dienste (z.B. FRS-
SYSVOL-Replikation) existieren unter Samba nicht. Daher sind diese angezeigten Fehler normal.
Werden denn die GPOs angewendet, also die Netzlaufwerke unter Windows eingebunden?
Was passiert, wenn du diese GPO löschst und neu anlegst?
Du kannst das SysVol auf dem Samba-Server mit samba-tool ntacl sysvolcheck prüfen und mit samba-tool ntacl sysvolreset reparieren. Nach einem Backup!
Weitere Möglichkeiten werden unter Fixing Incorrect Sysvol and Directory ACLs beschrieben.
Noch eine Frage:
Wieso zwei Suffixsuchlisten? Hast du die Netzwerkverbindung manuell konfiguriert?
Viele Grüße
Christian
Hi Christian,
Achso, das ergibt Sinn.
Nein, leider nicht, aber das war von Anfang an s auch schon bevor ich selbst in den GPOs eingespielt hab.
Wenn ich einfach den Ordner lösche, kommt immernoch der gleiche Fehler und zusätzlich nochmal ein ähnlicher mit dem gleichen Pfad nur für die Computerrichtlinie.
Gibt es noch einen anderen Weg, die Richtlinie zu löschen?
Danke für den Tipp, probiere ich mal aus 
Gute Frage, keine Ahnung … Ich hab da nichts gedreht… Woran könnte das denn liegen?
Danke für die Hilfe! 
VG, Dorian
Hallo Dorian,
kennst du
sophomorix-school ?
Mach mal
sophomorix-school --help
Hast du schon mal
sophomorix-school --gpo-create default-school
gemacht?
LG
Holger
Hallo Dorian,
dann heißt der Rechner also vollständig server-admin1.linuxadmin und ist in der Domain Linuxmuster? Dann nimmt er natürlich keine GPO aus der Domain Linuxmuster.net.
Schau mal unter Einstellungen, System, Info, Erweiterte Einstellungen. Da müsste der FQDN stehen. Wenn da wirklich nur server-admin1.linuxmuster steht, dann ist Samba falsch konfiguriert.
Viele Grüße
Christian
Hi Holger,
Das kannte ich tatsächlich nicht. Aber
sophomorix-school --gpo-kill default-school
sophomorix-school --gpo-create default-school
Hat das Problem tatsächlich behoben
Vielen Dank! Jetzt läuft gpupdate durch.
Die Tauschlaufwerke wurden aber trotzem nicht eingebunden, deshalb bin ich zum Testen einmal aus der Domäne aus- und dann wieder eingetreten.
Jetzt habe ich das Problem, dass er immer wenn ich versuche mich anzumeden folgende Fehlermeldung anzeigt: „Die Vertrauensstellung zwischen dieser Arbeitsstaion und der primären Domäne konnte nicht hergestellt werden.“
Das Zertifikat in der smb.conf ist aber das Richtige:
tls certfile = /etc/linuxmuster/ssl/server.cert.pem
und auch
openssl verify -CAfile /var/lib/samba/sysvol/linuxmuster.lan/tls/cacert.pem /etc/linuxmuster/ssl/server.cert.pem gibt OK zurück… woran könnte das liegen?
Der vollständige Name ist hier server-admin1.linuxmuster.lan, das müsste dann doch eigentlich passen, oder?
VG, Dorian
Bist du ganz sicher? Ich denke, dass du gerade über den gleichen Stein stolperst, über den ich mich seinerzeit auch lang gemacht habe … bei mir steht da (nachdem im LE-Forum gefragt hatte – ist also nicht auf meinem Mist gewachsen):
tls certfile = /etc/linuxmuster/ssl/fullchain.pem
Du kannst das testen, indem du die Verbindung auf Port 636 testest:
openssl s_client -connect server:636
Da muss die vollständige Zertfikatskette ausgespuckt werden – sonst gibt’s irgendwo Stress…
Viele Grüße,
Michael
Hallo Dorian,
hat es auch schon server-admin1.linuxmuster.lan angezeigt, bevor du aus der Domain aus- und wieder eingetreten bist?
Was zeigt ipconfig -all nun?
Was sagt rsop in der Eingabaufforderung? Werden da die GPOs angezeigt?
Viele Grüße
Christian
Hi Michael,
Danke für den Tipp, ich hab es ausprobiert, aber das hat leider nichts gebracht, auch nicht nach erneutem Domänen rejoin.
Das sieht meiner Meinung nach gut aus:
Certificate chain
0 s:O = MakerLab Murnau, OU = LINUXMUSTER, CN = server.linuxmuster.lan, subjectAltName = server.linuxmuster.lan
i:O = MakerLab Murnau, OU = LINUXMUSTER, CN = LINUXMUSTER.LAN, subjectAltName = LINUXMUSTER.LAN
.....
SSL handshake has read 1515 bytes and written 446 bytes
Verification: OK
Windows-IP-Konfiguration
Hostname . . . . . . . . . . . . : server-admin1
Primäres DNS-Suffix . . . . . . . : linuxmuster.lan
Knotentyp . . . . . . . . . . . . : Hybrid
IP-Routing aktiviert . . . . . . : Nein
WINS-Proxy aktiviert . . . . . . : Nein
DNS-Suffixsuchliste . . . . . . . : linuxmuster.lan
Ethernet-Adapter Ethernet 3:
Verbindungsspezifisches DNS-Suffix: linuxmuster.lan
Beschreibung. . . . . . . . . . . : Intel(R) 82574L Gigabit Network Connection
Physische Adresse . . . . . . . . : 52-54-00-18-5D-A1
DHCP aktiviert. . . . . . . . . . : Ja
Autokonfiguration aktiviert . . . : Ja
Verbindungslokale IPv6-Adresse . : fe80::10bc:da72:6299:ed4c%7(Bevorzugt)
IPv4-Adresse . . . . . . . . . . : 10.0.0.50(Bevorzugt)
Subnetzmaske . . . . . . . . . . : 255.255.0.0
Lease erhalten. . . . . . . . . . : Mittwoch, 24. Februar 2021 22:12:44
Lease läuft ab. . . . . . . . . . : Freitag, 26. Februar 2021 22:12:44
Standardgateway . . . . . . . . . : 10.0.0.254
DHCP-Server . . . . . . . . . . . : 10.0.0.1
DHCPv6-IAID . . . . . . . . . . . : 374494208
DHCPv6-Client-DUID. . . . . . . . : 00-01-00-01-27-3E-EA-CF-52-54-00-1D-F6-06
DNS-Server . . . . . . . . . . . : 10.0.0.1
Primärer WINS-Server. . . . . . . : 10.0.0.1
NetBIOS über TCP/IP . . . . . . . : Aktiviert
Nach dem Neueintritt (mit lokalem Benutzer - geht vermutlich deshalb nicht) fehlen die GPOs
Vor dem Rejoin (hab das alte Image zurückgespielt) fehlen die GPOs auch. Der FQDN des Rechners ist aber tatsächlich server-admin1.LINUXMUSTER, komisch…
VG, Dorian
Ich denke, dass du da weiterhin das self-signed-Cert hast!?
@mdt hatte mir in mühevoller Kleinarbeit in diesem Thread damals ein paar Nachhilfelektionen erteilt und mich so auf den richtigen Weg bzgl SSL/LE gebracht.
Wenn du ein LE-Cert einsetzen willst (was in diesem Thread aber gar nicht das eigentliche Problem ist!!), muss da jedenfalls nach meinem Halbwissen die vollständige Kette stehen, die hier so aussieht:
openssl s_client -connect server:636
...
Certificate chain
0 s:CN = server.linuxmuster.meine-domain.de
i:C = US, O = Let's Encrypt, CN = R3
1 s:C = US, O = Let's Encrypt, CN = R3
i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate
-----BEGIN CERTIFICATE-----hth,
Michael
Hallo Dorian,
wenn das System mit Linbo zurückgesetzt wird, dann heißt der Client server-admin1.linuxmuster und ipconfig -all zeigt auch nur linuxmuster.
Eine Anmeldung mit Domain-Nutzern ist möglich.
Wenn der Client aus der Domain raus- und dann reingenommen wird, dann heißt er server-admin1.linuxmuster.net und ipconfig -all zeigt linuxmuster.net.
Dafür geht eine Anmeldung mit Domain-Nutzer nicht mehr, da das Maschinenpasswort vom Client nicht mit dem auf dem Server übereinstimmt. Dann ist die Vertrauensstellung nicht vorhanden. Wurde das von Linbo durch das alte ersetzt?
In keinem der Fälle werden die GPOs angewendet, auch wenn das Sysvol nach dem löschen und wiederanlegen nun die richtigen ACL (Rechte) aufweist.
Hab ich das so richtig verstanden?
Kannst du in einer VM eine Installation von Windows erstellen und in die Domain aufnehmen? Völlig ohne Linbo, Regpatch,…… nur ein blankes Windows und dann schauen, ob die Anmeldung der Domainuser funktioniert und die GPOs angewendet werden?
Dann wäre der Server mit seinen Diensten ok und es ist ein Problem mit dem Image.
Viele Grüße
Christian
Hi Christian,
Also es sieht jetzt so aus:
Ich hab nochmal alles neu gestartet und mit Linbo die alten Images zurückgespielt. Dann hat alles funktioniert, auch mit Domänenrejoin. Die Domänenanmeldung klappt und auch gpupdate. Die Laufwerkmappings funktionieren und auch sonstige GPOs (Deaktivierung von Cortana, WindowsStore, …). Und das, obwohl der Hostname nicht auf .LAN endet. Aber das ist mir jetzt egal, es funktioniert ja alles, vielen Dank für eure Hilfe!
Hier nochmal der Fix für den gpupdate Fehler:
sophomorix-school --gpo-kill default-school
sophomorix-school --gpo-create default-school
Viele Grüße
Dorian