ich hab jetzt noch ein paar Versuche gemacht und möchte die Ergebnisse hier schreiben. In meinen Augen ergeben sich hier ein paar neue Fragen.
Vorgehen:
Ich habe auf dem Linux-Client 1 (lmn-bionic-200507) die Datei /etc/kbr5.keytab und auf dem Server die Datei lmn-bionic-200507.cloop.macct gelöscht.
Dann linuxmuster-client-adsso-setup ausgeführt, ein neues Image erzeugt und hochgeladen und anschließend die Linux-Clients synchronisiert gestartet.
Die Anmeldung lief auf allen (zwei) Clients
Jetzt habe ich auf dem Client 1 Windows gestartet. Ich habe mich nicht angemeldet.
Auf dem anderen Client 2 war ich noch unter Linux angemeldet. Plötzlich hat mir Firefox den Proxy-Anmeldedialog gezeigt.
Nach dem Abmelden konnte ich mich nicht mehr anmelden.
Auf dem Client 1, auf dem Windows gestartet wurde lief alles.
Nach einem Neustart mit Linux war auch dort ein Anmelden nicht mehr möglich.
Auch nach einem synchronisierten Start kann man sich in Linux nicht mehr anmelden.
Da stellen sich folgende Fragen:
Wie kann sich ein MACCT, der beim Start von Windows auf Client 1 auf den AD kopiert wird, auf den Client 2 auswirken?
Für welche Clients wird das MACCT auf den AD kopiert?
Was mich interessieren würde:
Bei wem laufen Clients mit Linux und Windows ohne diese Problem? Bitte schreibt, wie ihr das gemacht habt.
Bei wem läufts auch nicht?
Holger, du hast geschrieben, dass bei dir alles läuft. Wie bist du vorgegangen? Weist du das noch oder ist es schon sehr lange her?
Ich möchte mich bereits jetzt für eure Antworten bedanken.
ich habe heute im Seminar mit meinem Netzwerkerkurs mit meiner
Schulungsumgebung gearbeitet.
Die war vor ein paar MOnaten noch mit 4 Clients bestückt: 2 Windows only
und zwei ubuntu only.
Nach meinen Tests bei der Mitgliederversammlung dieses Jahr hab ich sie
umgestellt: dazu habe ich die beiden ubuntuclients weggeworfen und ide
start.confs der winclients um weitere Parititonen erweitert und das
ubuntu dazu geklont.
Nun weiß ich nicht mehr, ob ich danach mit dem ubuntu nochmal beitreten
musste oder nicht, aber ich kann sagen; das funktioniert seit Monaten so.
Jetzt mach doch mal folgendes:
nenn einen Client in der devices.csv um: er soll einen Namen
bekommen, den es noch ie in deiner lmn gab: nenn ihn karlspc01
lösch alle Partitionen auf dem Client, bevor du linbo startest.
partitionier ihn mit linbo und spiel windows zurück.
Anmelden geht? wenn ja ->
spiel das ubuntu Image zurück
Anmelden geht? falls ja: andere Clients testen, falls nein->
lokal die /etc/kbr5key.tab dingens löschen und nochmal
linuxmuster-client-adsso laufen lassen
auf dem server die linuximage.cloop.macct Datei löschen oder wegbewegen
Image erstellen
Image auf dem Client zurückspielen
an dem Client anmelden: wenns geht: auf anderen clients testen.
ich habe die Clients von lc-rxx in test-rxx umbenannt habe und die Festplatten gelöscht und durch neue Festplatten resetzt habe bin ich wie folgt vorgegangen:
Festplatte mit linbo partitioniert und Neustart.
Formatiert partitioniert und windows synchronisiert gestartet.
Anmeldung hat geklappt.
Linux gesynct gestartet
Anmeldung hat nicht geklappt
Als linuxadmin kbr5.keytab gelöscht und linuxmuster-client-adsso laufen gelassen.
Auf dem Server die .macct-Datei gelöscht.
Image erstellt.
Linux synchronisiert gestartet
Anmeldung ging
Windows gestartet.
Anmeldung ging
Linux gestartet.
Anmeldung ging nicht
Dann habe ich ein ganz neues System aus den ova-Dateien aufgesetzt:
Auf einem Client ein Windows aufgesetzt und in die Domäne eingebunden.
Anmeldung ging,
Auf dem Client einen linuxclient aufgespielt.
Anmeldung ging
Windows gestartet.
Anmeldung ging.
Linux gestartet.
Keine Anmeldung
Linux synchronisiert gestartet.
Keine Anmeldung
Es ist mir ein Rätsel, wie du das mit dem Dualboot gemacht hast.
Hast du an Linbo etwas geändert?
In meinen Augen funktioniert das Übertragen des MACCT auf den AD nicht bei Linux.
Übrigens:
Beim Runterladen des Linux-Clients mit dem linuxmuster-client-servertools musste ich das Volume für /var/cache vergrößern, da sonst /var/cache voll läuft.
Bei mir ebenfalls. Ich habe schon zig mal das Linux neu aufgespielt, da ich immer davon ausgegangen bin das ich einen Fehler mache…
Diesen Umstand habe ich bereits gemeldet. Das ist eine unschöne Falle wenn man (wie ich) nicht damit rechnet, dass die Partitionsgröße noch nicht einmal für ein Cloop reicht.
baumhof:
Ich mach mal ein update auf das aktuelle linbo und teste nochmal.
Ich bin gespannt …
ich habe aktualisiert: linbo 2.3.63
Dann habe ich einen vorhandenen Client partitioniert und windows
gesynct: Domanmeldung geht Laufwerke da.
Dann habe ich den gleichen Client rebootet und ubuntu gesynct:
Domanmeldung geht Laufwerke da.
die macct Dateien sind unterschiedlich groß: unicodePW und
supementalCredentials sind unterschiedlich.
Dann habe ich eienn reboot gemacht und windows ungesynct gebootet:
Anmeldung geht, Laufwerke da. (Anderer Nutzer als vorher)
Dann reboot und ubuntu ungesynct gestartet: wieder anderer Nutzer:
Anmeldung geht, Laufwerke da.
einziger Hinweis: meine Rechnernamen haben keine „-“ im Namen, sie
heißen: r100pc01 und r100pc02
Vielleicht mal Rechnernamen ohne „-“ probieren?
Was steht den bei euch in der /etc/krb5.conf auf dem Client?
Ich hab meine Rechner statt lc-r01 in lcr01 umbenannt.
Geändert hat sich leider nichts. Aber mir ist aufgefallen, dass bei der Umbenennung eine Warnmeldung kam, die gesagt hat, dass die Rechner lc-r01 und lc-r02 nicht existieren.
Ich hab dann mal in LDAP reingeschaut:
Wie man sieht, sind die Rechner nicht im LDAP?!? Außer der Firewall ist da nix?!? Dann ist auch klar, dass die MAccT nicht gespeichert werden konnten. Der Fehler liegt also in der Rechneraufnahme.
Das ist meine devices.csv
Hallo Thomas,
zunächst mal vielen Dank für deine Antwort.
Hab ich gemacht. Leider war unter Linux die Anmeldung nicht möglich.
Im log /var/log/linuxmuster/linbo/rsync-pre-download.log steht:
### rsync pre download begin: Mo 6. Jul 12:40:40 CEST 2020 ###
HOSTNAME: lcr01.linuxmuster.lan
IP: 10.16.100.1
RSYNC_REQUEST: linbo/lmn-bionic-200507.cloop.macct
FILE: /srv/linbo/lmn-bionic-200507.cloop.macct
PIDFILE: /tmp/rsync.3173
EXT:* .macct
Machine account ldif file: /srv/linbo/lmn-bionic-200507.cloop.macct
Host: lcr01
DN: CN=LCR01,OU=info,OU=Devices,OU=default-school,OU=SCHOOLS,DC=linuxmuster,DC=lan
Modified CN=LCR01,OU=info,OU=Devices,OU=default-school,OU=SCHOOLS,DC=linuxmuster,DC=lan
Modified 1 records successfully
RC:
### rsync pre download end: Mo 6. Jul 12:40:40 CEST 2020 ###
Im LDAP-Baum unter CN=LCR01,OU=info,OU=Devices,OU=default-school,OU=SCHOOLS,DC=linuxmuster,DC=lan findet man die Attribute unicodePwd und supplementalCredentials nicht.
Ist das richtig so oder könnte da das Problem liegen?
In dem Fall ist es der Account mit $, also lcr01$.
Im Logfile sieht das ja gut aus.
Wichtig ist auf jeden Fall, dass man nach dem Domänenbeitritt als erstes in Linbo bootet und ein Image erstellt und nicht zwischendrin das andere BS startet. Wurde das so gemacht?
Ja, ursprünglich habe ich Linux installiert, in der Domäne angemeldet, sofort ein Image gemacht und den Client synchronisiert gestartet. Dann habe ich das Image auf den anderen Client gespielt.
Bis dahin lief alles gut.
Dann habe ich das gleiche mit Windows gemacht. Auch dort lief alles super.
Nach einem unsynchronisierten Start von Linux hat dann aber die Anmeldung nicht mehr funktioniert.
Auch nach einem synchronisierten Start von Linux ging die Anmeldung nicht.
Wo im LDAP-Baum findet man lcr01$? Da müssten doch die Attribute unicodePwd und supplementalCredentials stehen, oder?
Halle Holger,
ich hab die Punkte 1 bis 6 durch. Anmeldung geht auf beiden Clients.
Nach dem Start von Windows (ohne Anmeldung) und anschließendem Start von Linux geht die Anmeldung unter Linux nicht mehr
Wie kann ich den aktuellen MAccT ( unicodePwd und supplementalCredentials) vom AD auslesen?
Ich vermute, dass da was falsch läuft.
Hallo Thomas, hallo Holger,
ich hab mir eben den LDAP-Baum angeschaut. Dabei ist mir aufgefallen, dass der Rechner lcr01 nicht mehr drin ist:
Irgend was läuft da schief…
Gruß,
Mathias
ich hab die Punkte 1 bis 6 durch. Anmeldung geht auf beiden Clients.
Nach dem Start von Windows (ohne Anmeldung) und anschließendem Start von
Linux geht die Anmeldung unter Linux nicht mehr
