Vielleicht meintest du diesen Beitrag von 2019?
Den kenne ich zufällig – kam von mir 
Nein, der war es nicht, aber ich finde ihn leider auch nich mehr 
Hab da leider auch nicht mega viel Ahnung von …
@MachtDochNix: Warum? Es ist ja noch nicht abschließend geklärt, warum das bei mir ohne s sein muss, während es woanders auch mit funktioniert
Ich würde das hier zusammen lassen…
Weil du die Überschrift schon als gelöst markiert hast, vielleicht?! siehe post #6 
Ein Problem --> ein neuer Thread und bei dem eine möglich treffende Überschrift! Erleichtert auch das wiederfinden.
Beste Grüße
Thorsten
… dann nehme ich doch lieber das „Gelöst“ wieder raus, meine ich?
Die Frage, wer von wo über welche Verschlüsselung auf den Server zugreifen darf, scheint jedenfalls der Kern des Problems zu sein?!
Ich habe dazu diese Seite gefunden:
Hier ist es so: Wenn ich auf dem Server den Befehl mit TLS-Verschlüsselung (also mit der Option -Z) verwende:
ldapsearch -H ldap://server -b "ou=default-school,ou=SCHOOLS,dc=linuxmuster,dc=meine-domain,dc=de" -D global-binduser@linuxmuster.meine-domain.de -w supergeheimesPasswort -Zläuft die Anfrage durch; versuche ich das gleiche vom Client aus, erhalte ich:
ldap_start_tls: Connect error (-11)
additional info: (unknown error code)
ldap_result: Can't contact LDAP server (-1)Wenn ich es stattdessen mit SSL-Verschlüsselung und ohne die Option -Z über ldaps:// versuche, klappt es sowohl vom Server als auch vom Client aus! Das könnte ein Anhaltspunkt sein!?
Mir ist aber nicht klar, welche Verschlüsselung denn nun gewählt wird!?
Bisher war ich von SSL ausgegangen, da in o.g. Script ldbsearch -k yes -H ldaps:// stand, was dann über Port 636 bzw 3269 läuft…!?
Wer blickt da besser durch?
Vielleicht @mdt?
Viele Grüße,
Michael
Nur als Ergänzung noch ein Querverweis auf
Seltsamerweise steht in meiner smb.conf:
[root@server:]$ cat /etc/samba/smb.conf | grep strong
ldap server require strong auth = noLaut dem Thread sollte da aber yes stehen – könnte das jemand mit seinen Settings vergleichen und hier posten?
Hallo Michael,
Nur als Ergänzung noch ein Querverweis auf
Server-Appliance <https://ask.linuxmuster.net/t/server-appliance/3312> v7-Betatest <https://ask.linuxmuster.net/c/server-v7/v7-betatest/47> Hi! Es gibt eine aktualisierte Version der Server-Appliance <https://github.com/linuxmuster/linuxmuster-base7/wiki/Die-Appliances#server> auf Basis von Ubuntu Server 18.04.2. VG, ThomasSeltsamerweise steht in meiner smb.conf:
[root@server:]$ cat /etc/samba/smb.conf | grep strong ldap server
require strong auth = no|Laut dem Thread sollte da aber |yes| stehen – könnte das jemand mit
seinen Settings vergleichen und hier posten?
in meiner steht das auch auf „no“.
Laut dem Thread solltest du das da ändern: das wird nciht per
distupgrade geändert.
Ich dachte damals wohl: " das machste mal in den Ferien und schaust ob
noch alles geht" … und habs dann vergessen … jetzt sind aber gerade
Ferien … da kann ich wohl gleich nochmal ran an die Boulette
LG
Holger
Hallo Holger,
also, wenn du „yes“ setzt, sind nur noch verschlüsselte Verbindungen über TLS bzw LDAPS erlaubt – auch auf Port 389, ja?
Wäre ja interessant zu erfahren, welches Cert. bei Dir dann ausgeliefert wird – es gibt ja „nur“ das SnakeOil-Cert der Installation, nehme ich an? Hast du das irgendwann mal auf dem Client hinzugefügt, damit der Client dem Cert. vertraut??
Viele Grüße
Michael
Hallo Michael,
also, wenn du „yes“ setzt, sind nur noch verschlüsselte Verbindungen
über TLS bzw LDAPS erlaubt – auch auf Port 389, ja?
Wäre ja interessant zu erfahren, welches Cert. bei Dir dann ausgeliefert
wird – es gibt ja „nur“ das SnakeOil-Cert der Installation, nehme ich
an? Hast du das irgendwann mal auf dem Client hinzugefügt, damit der
Client dem Cert. vertraut??
ich hab da nix gemacht: ich hab nur irgend wann mal
linuxmuster-client-adsso ausgeführt.
Ich denke, da passiert das.
LG
Holger
Ja, so hieß es geht am Anfang, jetzt aber
linuxmuster-cloop-turnkey
… hat nur indirekt mit diesem Thread zu tun … aber wie groß ist bei Euch das Vorlagenverzeichnis von /home/linuxadmin?
Ich habe hier insgesamt 258MB im Profil:
… entsprechend dauert die Erstanmeldung eines neuen Users an den Client.
(Unter Win10 ist es noch größer und nerviger … aber unter Linux sollte man das doch ordentlich nach unten drücken können?)
Hallo Michael,
… hat nur indirekt mit diesem Thread zu tun … aber wie groß ist bei Euch
das Vorlagenverzeichnis von |/home/linuxadmin|?Ich habe hier insgesamt 258MB im Profil:
Screenshot_20201229_174033
bei mir sind es 182MB
… entsprechend dauert die Erstanmeldung eines neuen Users an den Client.
(Unter Win10 ist es noch größer und nerviger … aber unter Linux sollte
man das doch ordentlich nach unten drücken können?)
da hab ich schon rumgespielt: arg viel hab noch nicht erreicht. Ich
nutze lmlcc und bleachbit als root und als linuxadmin vor der
Imageerstelltung.
Leider macht ubuntu anscheinend inzwischen Ähnliches wie Windows beim
Login: also nicht nur das Vorlagenprofil kopieren.
250MB sollten für eine SSD nicht der Schocker sein.
Und wegen der Anmeldezeiten unter Windows: aufgrund eines Supportfalls
ist mir bewußt geworden, dass dein GPO Zeug auch andere Nebenwirkungen
hat: die Loginzeit kann das sehr beeinflussen.
Darauf wollte ich dich noch hinweisen
Also mal GPOs abschalten und Loginzeit vergleichen (unter Windows… hat
nix mit ubuntu zu tun).
LG
Holger
Ja, ist klar, dass es etwas länger dauert – ich hatte ja extra die GPO „auf Netzwerk warten“ aktiviert. Aber das ist es in dem Fall wert …
Die Anmeldung am Bionic-Client geht hier schneller als unter Windows … aber der alte Xenial-Client war noch schneller…
Hallo Michael,
zunächst mal vielen herzlichen Dank, dass Du das Problem mit den fehlenden Homes hier formuliert und dann auch selbst einen Workaround gefunden hast.
Wir haben gestern festgestellt, dass das Problem auch bei uns so aufgetreten ist - wegen Lockdown ist das seit Weihnachten nur niemandem aufgefallen.
Wir waren der Ursache soweit auf der Spur (hatten den Fehler bei der LDAP-Verbindung im 00_userinfo.sh Skript entdeckt) und sind dann auf diesen Thread gestoßen. Wir waren überglücklich, dass Du schon den Workaround hattest.
Aber gelöst ist das Problem damit ja nicht. Uns würde auch interessieren, warum die ldaps-Verbindung via ldbsearch-Befehl nicht funktioniert.
Deine Vermutung, dass es daran liegt, dass dein server intern wie extern den gleichen FQDN benutzt, könnte stimmen. Das ist bei uns auch so.
Und auch in unserer smb.conf steht ldap server require strong auth = no und das obwohl der erst im Sommer 2020 aufgesetzt wurde - wo das ja schon lange Standard gewesen sein müsste. Was ist dabei eigentlich Sache?
@Michael : Hast Du das geändert? Hat das irgendwelche negativen Nebeneffekte?
Grüße
Michael
Hallo,
Deine Vermutung, dass es daran liegt, dass dein server intern wie extern
den gleichen FQDN benutzt, könnte stimmen. Das ist bei uns auch so.
warum schreibt ihr dann den Server mit seiner internen IP nicht in die
/etc/hosts auf dem Client?
LG
Holger
Hi.
Zunächst mal: Ich bin immer etwas „erleichtert“, wenn andere das gleiche Problem haben – dann steigt die Chance, dass es ein Bug ist und er eines Tages behoben wird. Dass Du nun also auch über die fehlende Home_auf_Server-Verknüpfung gestolpert bist, „freut mich“! 
Holger: Intern funktioniert die Namensauflösung problemlos.
Michael: Hast du auch diesen Thread entdeckt & mitverfolgt:
Ich weiß mittlerweile, dass fehlende Home_auf_Server bzw Tausch_auf_Server Icons mehrere Ursachen haben können: Das Anmeldescript muss natürlich vernünftig durchlaufen – aber auch die Sache mit Kerberos und den lokalen Systemzeiten muss passen. Da ich bisher immer auf einer VM (Proxmox) getestet habe, unterscheiden sich manche Dinge von realer Hardware (hwclock, Bios-Zeit …).
Was habt ihr denn ausprobiert?
Mir kommt es weiterhin so vor, als sei ldaps im Zusammenhang mit Kerberos überflüssig (wie schon in dem Thread erwähnt). 100%ig sicher bin ich da aber nicht – ich hatte mich da nur auf andere Webseiten berufen, wo das geschrieben steht.
Ich habe den Eintrag ldap server require strong auth = no hier auch – weiß aber nicht, ob das default ist und ob es Auswirkungen auf anderes gibt …
Eine bessere Lösung habe ich leider momentan nicht. Vielleicht liest ja eine @Entwickler mit?
Viele Grüße,
Michael
Hej,
Ja, geteiltes Leid ist halbes Leid. 
Michael: Hast du auch diesen Thread entdeckt & mitverfolgt:
Bisher nicht. Scheint auch nicht auf die Situation bei uns zu passen. klist zeigt bei uns ein aktuelles Ticket.
Was habt ihr denn ausprobiert?
Nicht viel. Wir haben überprüft, ob die Shares unter /srv/samba/... gemountet sind (waren sie) und haben dann nachgeforscht, was da beim login schief läuft. also /etc/linuxmuster-client/scripts/login.sh ausgeführt und diese Fehlermeldung erhalten:
sed@r118-imagevm:/etc/linuxmuster-client/scripts$ sudo ./login.sh
Executing /etc/linuxmuster-client/login.d/00_userinfo.sh ...
Failed to connect to ldap URL 'ldaps://server.meine-domaene.de' - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to 'ldaps://server.meine-domaene.de' with backend 'ldaps': LDAP client internal error: NT_STATUS_INVALID_PARAMETER
Failed to connect to ldaps://server.meine-domaene.de - LDAP client internal error: NT_STATUS_INVALID_PARAMETER
...
Dann haben wir das Discourse angesurft und deinen Foreneintrag gefunden.
Haben dann das s bei ldaps entfernt und den login.sh nochmal ausgeführt. Nachdem das script so fehlerfrei durchlief und die Shares wieder vorhanden waren, haben wir schnell eine überarbeitete 00_userinfo.sh ins Postsync gelegt und uns dann wieder unserer eigentlichen Aufgabe zugewandt…
Eigentlich waren wir in der Schule, weil letzte Woche endlich unsere Corona-„Sofort“-Hilfe-Notebooks für die SuS angekommen sind… 
Grüße
Michael
Hallo, OK das sind doch gleich zwei wichtige Infos:
-
Das s bei der LDAP Verbindung ist scheinbar ein Problem, wenn man ein gültiges Zertifikat auf dem Server einsetzt.
-
Du hast im Gegensatz zu mir ein Ticket mit richtiger Uhrzeit beim Erstlogin.
Kannst du Deine vollständige smb.conf hier posten? Vielleicht gibt es ja doch einen markanten Unterschied??
Viele Grüße
Michael
Hej, na klaro:
root@server:/etc/samba# cat smb.conf
# /etc/samba/smb.conf.setup
#
# Don't edit this file!!!
# Add your stuff in /etc/samba/smb.conf.admin.
#
# thomas@linuxmuster.net
# 20200818
#
[global]
workgroup = #MEINE-SCHULE#
realm = #MEINE-SCHULE.DE#
netbios name = SERVER
server role = active directory domain controller
dns forwarder = 10.16.1.254 # Das ist bei uns die OpnSense
registry shares = yes
host msdfs = yes
tls enabled = yes
tls keyfile = /etc/linuxmuster/ssl/server.key.pem
tls certfile = /etc/linuxmuster/ssl/server.cert.pem
tls cafile = /etc/linuxmuster/ssl/cacert.pem
tls verify peer = ca_and_name
ldap server require strong auth = no
rpc_server:spoolss = external
rpc_daemon:spoolssd = fork
spoolss:architecture = Windows x64
printing = cups
printcap name = cups
time server = yes
ntp signd socket directory = /run/samba/ntp_signd
[netlogon]
path = /var/lib/samba/sysvol/csg-tuebingen.de/scripts
read only = No
acl allow execute always = yes
[sysvol]
path = /var/lib/samba/sysvol
read only = No
[printers]
browseable = No
path = /var/spool/samba
printable = Yes
read only = No
[print$]
path = /var/lib/samba/printers
read only = No
# including custom admin stuff
include = /etc/samba/smb.conf.admin
Die drei Zeilen mit den Standard-Zertifikaten werden durch die /etc/samba/smb.conf.admin überschrieben.
root@server:/etc/samba# cat smb.conf.admin
# modified by linuxmuster-setup at 20200722190310
# /etc/samba/smb.conf.admin
#
# thomas@linuxmuster.net
# 20180713
#
# add here your custom admin stuff
#
[global]
tls keyfile = /etc/linuxmuster/ssl/server.le.privkey.pem
tls certfile = /etc/linuxmuster/ssl/server.le.fullchain.pem
tls cafile = /etc/linuxmuster/ssl/server.le.chain.pem
Hi, ich habe mit kdiff3 verglichen. Einziger relevanter Unterschied dürfte bei mir dieser Eintrag sein, den es bei dir nicht gibt:
#Protokoll geaendert: #ntlm auth = yes < deaktiviert und nur noch eingeschraenkt erlaubt: 02.07.2020
ntlm auth = mschapv2-and-ntlmv2-onlyIch fürchte, dass das ein ziemliches „im Nebel stochern“ bleibt … ?!
Wenn du aber sagst, dass deine User direkt bei der ersten Anmeldung ein gültiges Kerberos-Ticket erhalten, läuft bei Dir ja immerhin dieser Schritt richtig. Bei mir passt das immer erst, wenn ich es manuell anstoße.
Vielleicht sollte ich den Client doch nochmal aus der Domäne entfernen und neu hinzufügen!?
Viele Grüße,
Michael