Hi,
nö - tröstet nicht 
Ich werde für Montag jetzt das „Notprogramm“ anlaufen lassen und alle Rechner erst mal in die noProxy Gruppe schieben. Da muss ich allerdings erst mal sehen, wo bzw. wann beim Linux-Client die Proxies gesetzt werden. Beim Windows-Client scheint es zu funktionieren - teste ich heute/morgen noch.
Ich bin sicher, dass es mit dem Zeitproblem zusammenhängt. Ich hab da einen Verdacht, muss das aber morgen noch checken …
VG
Wolfgang
Hi,
gibt es belastbare Aussagen über maximal erlaubte Zeitabweichungen?
Kerberos lässt bis zu 5min zu (?)
Mein Problem ist, dass mein Schulträger kein ntp durch die Firewall lässt, und ich das quasi „hintenrum“ irgendwie ins System bringen muss …
VG
Wolfgang
Selbes Problem bei mir. Ich hab das neue Linbo Update installiert. Hat leider nicht geholfen. Windows kommt mit dem Zeitunterschied klar, aber Linux verbindet keine Laufwerke und surfen ist auch nicht möglich.
Montag geht die Schule wieder los, eine schnelle Lösung wäre super, sonst müssen alle Clients in die no Proxy Gruppe.
Danke im vorraus.
Hallo Thomas,
ich bin leider nicht so gut im Code lesen:
Bedeutet
Ok, ist in linuxmuster-linbo7 2.3.63 ungesetzt.
dass linbo beim Starten die lokale BIOS Zeit auf UTC setzt und dann, wie Tobias schreibt, beim Starten von windows die BIOS zeit schnell auf localtime setzt?
Oder bedeutet es Lösung b:
dass linbo die lokale Zeit immer auf die Zeit des Servers setzt (sollte UTC sein) udn wir Windwos mit regpatch behandeln, dass es weiß, dass die RTC Zeit UTC ist nicht localtime?
LG
Holger
Hallo Wolfgang,
Mein Problem ist, dass mein Schulträger kein ntp durch die Firewall
lässt,
… dazu sag ichmal besser nichts…
und ich das quasi „hintenrum“ irgendwie ins System bringen muss …
wichtig ist ja in erster Linie nicht, dass deine Zeit im Netz ganz genau
mit der „draußen“ übereinstimmt, sondern dass deine Zeit im Netz intern
synchron ist.
Deswegen sollte diese Kette eingehalten werden:
OPNsense ist der Zeitserver im Netz.
Der Server bezieht von ihm die Zeit.
der Server gibt die Zeit per linbo und mit seinem ntp weiter an die
Clients im Netz.
Also:
welche Zeit hat die OPNsense? welche der Server?
Welche Zeit ist den am Server eingestellt?
Bei mir:
timedatectl
Local time: Fr 2020-06-12 22:03:21 CEST
Universal time: Fr 2020-06-12 20:03:21 UTC
RTC time: Fr 2020-06-12 20:03:22
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
systemd-timesyncd.service active: no
RTC in local TZ: no
läuft auf dem Server der ntp Dienst?
root@server:~# systemctl status ntp.service
● ntp.service - Network Time Service
Loaded: loaded (/lib/systemd/system/ntp.service; enabled; vendor
preset: enab
Active: active (running) since Sun 2020-06-07 23:08:23 CEST; 4 days ago
Docs: man:ntpd(8)
Main PID: 7212 (ntpd)
Tasks: 2 (limit: 4915)
CGroup: /system.slice/ntp.service
└─7212 /usr/sbin/ntpd -p /var/run/ntpd.pid -4 -g -u 113:117Ist der ntp auf dem Server korrekt eingestellt?
Bei mir in der /etc/ntp.conf
:
# Specify one or more NTP servers.
# use firewall as primary ntp server
pool 10.16.1.254
server 10.16.1.254
# Use servers from the NTP Pool Project. Approved by Ubuntu Technical Board
# on 2011-02-08 (LP: #104525). See http://www.pool.ntp.org/join.html for
# more information.
# pool pool.ntp.org
#server 0.de.pool.ntp.org
#server 1.de.pool.ntp.org
#server 2.de.pool.ntp.org
#server 3.de.pool.ntp.org
LG
Holger
Hallo Dias El,
Selbes Problem bei mir. Ich hab das neue Linbo Update installiert. Hat
leider nicht geholfen. Windows kommt mit dem Zeitunterschied klar, aber
Linux verbindet keine Laufwerke und surfen ist auch nicht möglich.
Montag geht die Schule wieder los, eine schnelle Lösung wäre super,
sonst müssen alle Clients in die no Proxy Gruppe.
bitte lies zuerst, was ich Wolfgang geschrieben habe und vollzieh das an
deinem Server.
Dann kannst du am Cleint unter ubuntu schauen, was dort eingestellt ist.
Zuerst die /etc/ntp.conf (auf dem Cleint).
Da steht bei mir drin
server 10.16.1.254Da muss bei dir die IP deiner OPNsense hin.
dann schauen, was timedatectl sagt. Bei mir (wo es geht):
root@vmclient8:~# timedatectl
Local time: Fr 2020-06-12 22:48:33 CEST
Universal time: Fr 2020-06-12 20:48:33 UTC
RTC time: Fr 2020-06-12 20:48:34
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
systemd-timesyncd.service active: yes
RTC in local TZ: no
man beachte: localtime stimmt und Universaltime sowie RTC Time sind
identisch (UTC).
Syncservice ist aktiv.
Das soltle ebi dir alles so stimmen.
Falls nciht, dann schau hier hin und richte das ein:
LG
Holger
Hi,
… also …
ich seh zwar, dass auf der OPNSense der ntp läuft (gui und ps)
und auch ein nmap -sU -p123 10.0.0254 liefert einen Treffer.
Die beiden Rechner waren aber dennoch 8 Sekunden auseinander.
Ich hab das mittlerweilen angeglichen … .
Allerdings hab ich aktuell gerade wieder die Situation, dass ich mich im Linux-Client nicht mehr anmelden kann … Kann das auch ein Zeit-Problem sein. Aber den Rest des Tages ging die Anmeldung am Rechner, aber eben kein SSO. Ist von daheim halt immer blöd remote rumzufrickeln.
Aktuell sind die Zeitsettings:
OPNSense: 21:00
Server: 21:00
Client: 23:00
Und was mich wahnsinnig macht … Gestern: Anmeldung Linux - kein Problem. Heute in der Schule: falsches Kennwort. Ich hatte noch einen Client laufen, da ging es noch, auf allen anderen nicht.
Ok - von dem Client ein Image gezogen und verteilt - ging überall.
JETZT wieder „falsches Kennwort“ … auch nach Reboot. Woran hängt das? Geht da auch so was wie eine Vertrauensstellung kaputt?
VG
Wolfgang
Der systemd-timesyncd läuft bei mir nicht und kann auch nicht gestartet werden:
root@server:/srv/samba/global/management/global-admin/globaladmindir1# timedatectl
Local time: Fr 2020-06-12 23:28:24 CEST
Universal time: Fr 2020-06-12 21:28:24 UTC
RTC time: Fr 2020-06-12 21:28:24
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
systemd-timesyncd.service active: no
RTC in local TZ: no
root@server:/srv/samba/global/management/global-admin/globaladmindir1# service systemd-timesyncd status
● systemd-timesyncd.service - Network Time Synchronization
Loaded: loaded (/lib/systemd/system/systemd-timesyncd.service; disabled; vendor preset: enabled)
Active: active (running) since Fri 2020-06-12 23:26:50 CEST; 1min 37s ago
Docs: man:systemd-timesyncd.service(8)
Main PID: 2042 (systemd-timesyn)
Status: "Synchronized to time server 10.0.0.254:123 (10.0.0.254)."
Tasks: 2 (limit: 4915)
CGroup: /system.slice/systemd-timesyncd.service
└─2042 /lib/systemd/systemd-timesyncd
Jun 12 23:26:50 server.niedernburg.lan systemd[1]: Starting Network Time Synchronization...
Jun 12 23:26:50 server.niedernburg.lan systemd[1]: Started Network Time Synchronization.
Jun 12 23:26:50 server.niedernburg.lan systemd-timesyncd[2042]: Synchronized to time server 10.0.0.254:123 (10.
root@server:/srv/samba/global/management/global-admin/globaladmindir1# service systemd-timesyncd start
root@server:/srv/samba/global/management/global-admin/globaladmindir1# timedatectl
Local time: Fr 2020-06-12 23:28:52 CEST
Universal time: Fr 2020-06-12 21:28:52 UTC
RTC time: Fr 2020-06-12 21:28:53
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
systemd-timesyncd.service active: no
RTC in local TZ: no
VG
Wolfgang
Hallo Wolfgang,
ich seh zwar, dass auf der OPNSense der ntp läuft (gui und ps)
und auch ein nmap -sU -p123 10.0.0254 liefert einen Treffer.Die beiden Rechner waren aber dennoch 8 Sekunden auseinander.
Ich hab das mittlerweilen angeglichen … .
magst du uns verraten, wie du das gemacht hast?
Allerdings hab ich aktuell gerade wieder die Situation, dass ich mich im
Linux-Client nicht mehr anmelden kann … Kann das auch ein Zeit-Problem
sein.
hast du da ein Fragezeichen vergessen?
… ich denke ja: das kann ein Zeitproblem sein.
Aktuell sind die Zeitsettings:
OPNSense: 21:00
Server: 21:00
Client: 23:00
das sind nicht die settings nach denen ich gefragt hatte…
Welche Zeiten nennst du mit den hier?
localtime?
RTC?
Viele Grüße
Holger
Hallo Wolfgang,
… was ist mit dem ntp?
die Zeile:
systemd-timesyncd.service active: nohab ich ja auch: das ist wohl nicht dramatisch.
LG
Holger
Hi,
sorry für die ungenauen Angaben. Bei dir steht da schon yes - siehe Posting von dir
root@server:~# timedatectl
Local time: Sa 2020-06-13 08:16:07 CEST
Universal time: Sa 2020-06-13 06:16:07 UTC
RTC time: Sa 2020-06-13 06:16:07
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes
systemd-timesyncd.service active: no
RTC in local TZ: no
Der ntp:
root@server:~# ps aux|grep ntp
ntp 9389 0.0 0.0 113812 4344 ? Ssl 08:21 0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -g -u 113:117
root 9409 0.0 0.0 13136 960 pts/0 S+ 08:21 0:00 grep --color=auto ntp
In der /etc/ntp.conf:
# use firewall as primary ntp server
pool 10.0.0.254
Beim Aufruf von date auf server und firewall ist der Zeitunterschied die Reaktionszeit beim Taste drücken (+2 Stunden beim Server).
Auf dem Client stand zwar wirklich der falsche ntp-Server in der ntp.conf, die Zeit war aber identisch. Anmeldung ging dennoch nicht.
reboot - Anmeldung geht immer noch nicht.
Siehe:
root@server:~# ntpdate -d 10.0.0.1
13 Jun 08:30:24 ntpdate[10690]: ntpdate 4.2.8p10@1.3728-o (1)
Looking for host 10.0.0.1 and service ntp
10.0.0.1 reversed to server.niedernburg.lan
host found : server.niedernburg.lan
transmit(10.0.0.1)
receive(10.0.0.1)
transmit(10.0.0.1)
receive(10.0.0.1)
transmit(10.0.0.1)
receive(10.0.0.1)
transmit(10.0.0.1)
receive(10.0.0.1)
server 10.0.0.1, port 123
stratum 13, precision -24, leap 00, trust 000
refid [10.0.0.1], delay 0.02565, dispersion 0.00000
transmitted 4, in filter 4
reference time: e28ef099.4fee5435 Sat, Jun 13 2020 8:28:41.312
originate timestamp: e28ef106.6e334d7f Sat, Jun 13 2020 8:30:30.430
transmit timestamp: e28ef106.6e2e0a77 Sat, Jun 13 2020 8:30:30.430
filter delay: 0.02565 0.02565 0.02565 0.02577
0.00000 0.00000 0.00000 0.00000
filter offset: -0.00000 -0.00000 -0.00000 -0.00006
0.000000 0.000000 0.000000 0.000000
delay 0.02565, dispersion 0.00000
offset -0.000002
Hab jetzt mal server neu gestarter, import devices gemacht, client neu gestartet …
timedatectl
Local time: Sa 2020-06-13 08:53:02 CEST
Universal time: Sa 2020-06-13 06:53:02 UTC
RTC time: Sa 2020-06-13 06:53:02
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: no
systemd-timesyncd.service active: yes <<<<<<<<<<<<<<<<<<<<
RTC in local TZ: no
Aber die Anmeldung geht immer noch nicht. Kann man das von der Shell her irgendwie debuggen? Oder kann man auf dem Server die laufenden Tickets sehen und da welche „löschen“ … nicht, dass da was aufeinander prallt …
Anscheinend braucht der Time-daemon etwas länger … ohne Interaktion:
timedatectl
Local time: Sa 2020-06-13 09:06:30 CEST
Universal time: Sa 2020-06-13 07:06:30 UTC
RTC time: Sa 2020-06-13 07:06:30
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: yes <<<<<<<<<<<<<<<<
systemd-timesyncd.service active: yes
RTC in local TZ: no
Ändert aber nichts am Anmeldeproblem …
Neue Erkenntnisse! Mein Rechner heißt sufi-pc01 …
Ich hab jetzt mal beim Anmeldeversuch in einem anderen Fenster das Syslog mitlaufen lassen …
Hier sieht man, dass die Anmeldung schon vor der Anmeldung scheitert …
Jun 13 09:44:12 sufi-pc01 systemd[2308]: Started Virtual filesystem service.
Jun 13 09:44:59 sufi-pc01 [sssd[ldap_child[2424]]]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Client 'INST-PC19$@NIEDERNBURG.LAN' not found in Kerberos database. Unable to create GSSAPI-encrypted LDAP connection.
Jun 13 09:44:59 sufi-pc01 [sssd[ldap_child[2425]]]: Failed to initialize credentials using keytab [MEMORY:/etc/krb5.keytab]: Client 'INST-PC19$@NIEDERNBURG.LAN' not found in Kerberos database. Unable to create GSSAPI-encrypted LDAP connection.
Was sagt uns das? Irgendwas ist faul … wo steht noch der alten Name drin? In der krb5.keytab
Was ich der Doku so entnehme muss man ja vor dem adsso die keytab löschen (hab ich, sonst stünde ja kein Rechnername von mir drinnen).
Ich gehe davon aus, dass ich gestern meinen „INST-PC01“ in meine normale Nomenklatur überführt habe und es den Rechner nicht mehr gibt - und damit nicht im AD. Kann es sein, dass (intern) alle Linuxrechner nach dem Rollout mit dem gleichen Rechner an den AD rantreten?
Hallo Holger,
Ich verfolge gerade deine ganzen Beiträge hier im Forum zu diesem Thema. Mein Problem deckt sich so ziemlich mit dem der anderen. Deshalb schaue ich mal wie es bei den anderen weiter geht und mache die Tipps nach, damit du nicht an zu vielen Fronten gleichzeitig kämpfen musst.
Danke für deine Hilfe.
Hi,
ich hab jetzt in der devices.csv wieder einen Rechner inst-pc19 angelegt.
Wenn ich mich von dem (nicht inst-pc19) anzumelden versuche, ist nun die Fehlermeldung weg …
Anmeldung geht aber dennoch nicht.
Auth.log sagt:
Jun 13 10:10:17 sufi-pc01 lightdm: pam_unix(lightdm:auth): check pass; user unknown
Jun 13 10:10:17 sufi-pc01 lightdm: pam_unix(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost=
Jun 13 10:10:17 sufi-pc01 lightdm: pam_sss(lightdm:auth): authentication failure; logname= uid=0 euid=0 tty=:0 ruser= rhost= user=hoeferwo
Jun 13 10:10:17 sufi-pc01 lightdm: pam_sss(lightdm:auth): received for user hoeferwo: 10 (User not known to the underlying authentication module)
Es gibt mich also nicht??? Generell kann ich mich wohlgemerkt von unserer externen Nextcloud anmelden. Scheint mich also doch zu geben
Machen wir weiter …
Auf einem Client die krb5.keytab gelöscht, linuxmuster-client-adsso-setup laufen lassen …
Es entsteht eine neue keytab mit dem Namen des aktuellen Rechners drinnen … Ich kann mir nicht vorstellen, dass die beim Imagen dann ersetzt wird.
Nach dem syncen eines anderen Clients ist wirklich die keytab vom „falschen“ Rechner drauf.
Wenn ich die „neue“ keytab von dem nun funktionierenden Rechner per scp auf einen der „unwilligen“ Rechner kopiere, klappt auch wieder die Anmeldung …
Sehe ich das richtig, oder ist das NICHT so geplant?
VG
Wolfgang
Hallo Wolfgang,
Beim Aufruf von |date| auf server und firewall ist der Zeitunterschied
die Reaktionszeit beim Taste drücken (+2 Stunden beim Server).
das verstehe ich nicht: ist die Zeit nun gleich, oder unterscheidet sie
sich um 2 Stunden?
Auf dem Client stand zwar wirklich der falsche ntp-Server in der
ntp.conf, die Zeit war aber identisch. Anmeldung ging dennoch nicht.>
reboot - geht immer noch nicht.
… na dann liegt es nicht an der Systemzeit würde ich sagen…
stimmt den der Name in der /etc/hosts auf dem Client?
Vielelicht läuft der postsync nicht richtig…
Ansonsten müßten wir wohl noch mal in die Dom einterten.
LG
Holger
Hast du meine Ergänzungen oben gelesen? Der Hund mit meiner Anmeldung liegt woanders begraben …
„Sekunden gleich, aber 2h diff“
Hallo Wolfgang,
ich hab jetzt in der devices.csv wieder einen Rechner inst-pc19 angelegt.
Wenn ich mich von dem (nicht inst-pc19) anzumelden versuche, ist nun die
Fehlermeldung weg …
kannst du bitte etwas deutlicher die Dinge beschreiben, die du da machst?
Ich kann dir oft nicht folgen und muss dann Nachfragen: das müßte doch
eigentlich nicht sein, oder?
Es gibt mich also nicht??? Generell kann ich mich wohlgemerkt von
unserer externen Nextcloud anmelden. Scheint mich also doch zu geben
kannst du dich an der WebUI anmelden mit diesem Nutzer?
Was sagt den ein
sophomorix-user -i -u hoerferwo?
LG
Holger
Klar kann ich
Linux-Client mit Name inst-pc19 für adsso verwendet, Image gezogen, ausgerollt. Anmeldung geht
Der Rechner sollte nicht sein ganzes Leben lang „inst-PC19“ heißen, deshalb in der Devices.csv auf its1-pc19 umbenannt (IT-Saal = its)
import gemacht
Alle Linux Anmeldungen scheitern, weil jeder Rechner eine krb5.keytab hat, in der er sich als inst-pc19 verkauft.
Ein Umbenennen des Rechners wieder auf inst-pc19 bringt nichts, weil der dann anscheinend einen anderen Fingerabdruck als vorher hat.
Einen Rechner (its1-pc18) neu mit adsso aufgenommen, image erstellt und verteilt. EINEN Rechner (its-pc01) zum Testen mit sync laufen lassen und die Anmeldung geht.
von diesem Rechner die krb5.keytab (wo immer noch its-pc18 drinnen steht, auch wenn es der its-pc01 ist) auf einen anderen Rechner kopiert, wo die Anmeldung nicht ging => schon geht sie.
Die Keytab müsste beim Imageverteilen für die Rechner passend neu erstellt werden, denn wenn ich nun den its1-pc18 lösche, dann geht wieder gar nichts mehr …
Sind alle benötigten Infos drinnen? Wenn nein - was fehlt? Wir können auch telefonieren, falls es noch Unklarheiten gibt …
ACHTUNG: Das betrifft grad nur mein Anmeldeproblem. Der Internetzugang ist ein anderes Thema, so weit bin ich noch nicht!
VG
Wolfgang
Hallo Wolfgang,
Hast du meine Ergänzungen oben gelesen? Der Hund mit meiner Anmeldung
liegt woanders begraben …
nein, habe ich nicht: das ging nicht per mail an mich raus.
Jetzt hab ich es online nachgelesen.
Das sugerriert, dass man den Cleint, mit dem das Image aufgenommen
wurde, nicht in der devices.scv umnennen oder löschen darf…
Das müßte man mal austesten: oder jemand weiß bescheid.
Ich kann ja mal Heute Nacht bei meinem Client nachschauen, was in der
kbr5.keytab drin steht.
LG
Holger
Ok.
Aber generelle Frage … bei Ergänzungen eine Antwort oder ein Edit?