LMN7: Zeit läuft verquer, SSO, Kerb. Tickets werden als 2 Stunden zu früh ausgestellt

Hallo Ihr Lieben,

aktuell kämpfe ich hier mit einem Problem, dass am Client die kerberos tickets als 2 Stunden zu spät ausgestellt werden, also valid starting ist immer -2h, deshalb funktioniert wahrscheinlich auch ein kinit -R nicht. Ich tippe, dass auch deshalb kein SSO bei übern Webproxy mitm Browser funktioniert. Bei kinit -R bekomme ich z.B.

Uhrzeitabweichung zu groß bei Anmeldaten werden erneuert.

Wennich nach der Anmeldung mit einem Domain user aufm terminal kinit eintippe um nochmal ein Ticket zu bekommen, werden zwar die Tickets wieder -2h ausgestellt, jedoch funktioniert dann SSO über Webbrowser.

Habt Ihr vielleicht einen Tipp?

Server steht auf UTC, date zeigt -2h, hwclock zeigt die richtige Zeit

Firewall(Opensense) steht auf UTC, Webinterface zeigt -2h

Die Kisten laufen auf einem ESXi

LIebe Grüße
Andreas

Hallo Andreas!

Welches Betriebssystem auf den Clients?

Beste Grüße

Thorsten

danke für die Rückmeldung…

Ubuntu lmn-bionic-200507. Das Problem tritt sowohl mit dem original image(einfach domain join) als auch mit von mir modizierten Variante auf.

Komischerweise funktionieren die Windows 10 Clients…ich tippe dass die Zeiten in den Systemen nicht stimmen. Sobald ich heute vor Ort komme, werde ich dies nochmal im OS bzw. auf Bios Basis kontrollieren…

VG
Andreas

Hallo Andreas,

hast Du das aktuellste Linbo drauf? Da wurde irgendwas an der Systemzeit geändert/verbessert.

Viele Grüße,
Jochen

Hallo Jochen,
danke für die Rückmeldung, das aktuellste Linbo ist drauf, leider half mir das auch nicht weiter…

Hallo,

danke für die Rückmeldung, das aktuellste Linbo ist drauf,

… das finde ich zu ungenau.
Ist es 2.3.63 ?

Dann nähern wir uns der Sache mal langsam:
Welche Zeit hat der Server?
Bei mir:

timedatectl

bei mir sieht das so aus.

                      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

wichtig ist auch: läuft der ntp?

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

Ist das alles OK dann wissen wir:

  1. server hat UTC als Zeit und Berliin als Zeitzone. Er hat UTC ins BIOS
    geschrieben.
  2. der eitserver ntp läuft.

Nächster Schritt wäre: Client booten und in linbo starten: dabei wird
die lokale Zeit gesetzt: stimmt die Zeit im linbo Bildschirm?

Viele Grüße

Holger

Hallo Holger,

danke für die Rückmeldung und die Zeit. Hier noch kurz eine Info, ich weiss nicht ob die wichtig ist: Ich hatte 2 Tests Clients als virtuelle Maschinen auf dem Server laufen, da ich hier schneller Images erstellen, bzw. schreiben kann und auch linbo im Blick habe. Hoffe das war keine zu schlechte Idee!?

hier mal die Basics:

linuxmuster.net packages:
-Base…: 7.0.70-0ubuntu0
-Linbo…: 2.3.63-0
-WebUI…: 1.0.142-1
-Sophomorix…: 3.77.2-1

timedatectl sah nach meinen letzten Tests anders auf server aus. Bei meinem letzten Test hatte ich alles auf UTC(wirklich alles) gedrückt, leider wiesen die Clients dann unterschiedliche Zeiten auf, was ich mir nicht erklären konnte.
Desweiteren habe ich gecheckt, dass der Host(ESXi) kein Timesync in die Systeme(server,opnsense,2 ubuntu clients, alles virtuell) macht. Gute Idee?

Aktuell siehts so auf der Firewall aus(wie ich die HW clock auslese keine Ahnung):

root@firewall:~ # date
Fri Jun 12 23:03:57 CEST 2020

Aktuell siehts jetzt so aufm Server aus(nach deinem Hinweis wies funktionieren muss):

                  Local time: Fr 2020-06-12 23:06:35 CEST
              Universal time: Fr 2020-06-12 21:06:35 UTC
                    RTC time: Fr 2020-06-12 21:06:35
                   Time zone: Europe/Berlin (CEST, +0200)
   System clock synchronized: yes

systemd-timesyncd.service active: no
RTC in local TZ: no

NTP Service läuft auf Server

Linbo hat aufm virtuellen ubuntu Client UTC. welche mit Server UTC übereinstimmt(also kein CEST), will sagen, der Client geht in linbo 2h nach. Habe gelesen, dass das aktuell „normal“ ist.

Im Ubuntu dann habe ich die richtige Uhrzeit(also wie auf Server die ausgabe von timedatectl). Danach hatte ich das Image geclont(zuvor wieder ein turnkey…) und zurück auf die zweite virtuelle Maschine → war alles ok. Auf Hardware war dann wie oben erwähnt unterschiedliche Zeiten je Test Hardware.

Grüße
Andreas

Hallo Andreas,

danke für die Rückmeldung und die Zeit. Hier noch kurz eine Info, ich
weiss nicht ob die wichtig ist: Ich hatte 2 Tests Clients als virtuelle
Maschinen auf dem Server laufen, da ich hier schneller Images erstellen,
bzw. schreiben kann und auch linbo im Blick habe. Hoffe das war keine zu
schlechte Idee!?
nö, das ist schon OK: das mache ich auch so.
virtualisierte Clietns haben aber immer Probleme mit der Zeit, wenn
diese nciht mit einem server gesynct wird, weil ihre „Uhren“ nicht mit
konstanter Geschwindigkeit laufen (so hab ich das Gefühl).

>Local time: Fr 2020-06-12 23:06:35 CEST Universal time: Fr
2020-06-12 21:06:35 UTC RTC time: Fr 2020-06-12 21:06:35 Time zone:
Europe/Berlin (CEST, +0200) System clock synchronized: yes |

systemd-timesyncd.service active: no
RTC in local TZ: no

NTP Service läuft auf Server

hat er die OPNsense als server eingetragen in /etc/ntp.conf ?

Linbo hat aufm virtuellen ubuntu Client UTC. welche mit Server UTC
übereinstimmt(also kein CEST), will sagen, der Client geht 2h nach.

schau mal mein POsting hier an:

LG

Holger

ja, in der /etc/ntp.conf
steht u.A.
# use firewall as primary ntp server
pool 10.0.0.254

(ich hatte gestern oder so sogar aus Verzweiflung den pool pool.ntp.org dort drin auskommentiert und den dienst neu gestartet)

danke auch noch für den Hinweis mit dem anderen Thread -> Ich lese da jeden Poste. Ich habe statt pool 10.0.0.254 nun server 10.0.0.254 eingetragen. Eine andere Änderung, welche auf mein Problem passen konnte, konnte ich nicht finden…oder hab ich was überlesen?

ADD: wenn ich die ganzen Posts richtig lese und Linbo mir -2h anzeigt, läuft alles richtig? kann es passieren, dass linbo nicht die hwclock auf utc setzen darf?

Hallo Andreas,

was gibt den
timedatectl

auf dem Client aus?

LG

Holger

timedatectl aufm virtuellen client gibt das gleiche aus wie aufm Server. Könnte es sein, dass bestimmte hardware sich hier anders verhält? Hast Du Erfahrungen oder funktioniert das setzen der hwclock auf utc immer?

VG
Andreas

Update: timedatectl aufm virtuellen client gibt doch nicht das gleiche aus, ich war gestern wohl schon zu müde, ansonsten die local time, universal time, rc time und time zone sind gleich. hier deshalb nur die ausgaben, welche für dich interessant sind:

system clock sync: no
systemd-timesyncd.service active: yes
RTC in local TZ: no

Update:
ich habe mal weiter geforscht. da ich ja mit der system clock sync: auf yes kommen muss?!

ein

systemctl status systemd-timesyncd.service

zeigte

status: inactive (dead)

nachdem ich den service restartet habe, läuft der dienst nun. Warum der nicht lief, keine Ahung. Es scheint kein Konflikt mit ntp zu haben. Habe das restarten jetzt erstmal in rc.local rein. Ist das so richtig?

Hallo Andreas,

timedatectl aufm virtuellen client gibt das gleiche aus wie aufm Server.
Könnte es sein, dass bestimmte hardware sich hier anders verhält? Hast
Du Erfahrungen oder funktioniert das setzen der hwclock auf utc immer?

das hat bisher immer ohne Probleme funktioniert.

LG

Holger

Hallo Holger,

beim letzten Test ist zwar die timedatectl aufm client ok, jedoch stand da plötzlich tickettime irgendwas mit 1970. Irgendwas läuft da schief, aktuell bin ich grad so am verzweifeln, wahrscheinlich ists nur ein kleiner Kniff, das macht verrückt…

VG
Andreas

Hallo Andreas,

beim letzten Test ist zwar die timedatectl aufm client ok, jedoch stand
da plötzlich tickettime irgendwas mit 1970. Irgendwas läuft da schief,
aktuell bin ich grad so am verzweifeln, wahrscheinlich ists nur ein
kleiner Kniff, das macht verrückt…

was war den die Zeit der Timeticket Datei?
War das ein aktuelles Ticket aber drin stand die falsche Zeit?

LG

Holger

Hallo Holger,
danke übrigens für die Geduld.

Also File Zeit der /tmp/krb55cc_blublubs ist login datum. Im Ticket selbst mit klist sehe ich 01.01.1970

hoffe hatte die Frage richtig interpretiert…

hast eine Idee?

LG
Andreas

so am Rande:
in der profile.d fürn proxy im lmn-bionic-200507 ist für https_proxy=http://firewall.linuxmuster.lan:3128 müsste ich das nach https://xxxx:3129 drücken?

VG
Andreas

aktuell siehts virtuell gut aus, ich clone jetzt grad mal auf die wichtigen test hardware klassen und berichte dann, falls es funktioniert heists ca. 300 clients heute noch betanken…

Hi,
da ja viele ähnliche Probleme haben - hast Du noch was geändert, dass es jetzt funktioniert?
Gruß, Andreas (einer der vielen :wink: )

Hallo Andreas,

auf den clients lief kein timesyncd von , habe wie irgendwo im forum empfohlen folgendes in die rc.local geklatscht:

systemctl restart systemd-timesyncd.service

die hwclock auf allen geräten sollte wohl auf utc laufen, die Zeitzone auf cest (+2)

beim server habe ich noch in die ntp.conf pool 10.0.0.254 durch server 10.0.0.254 ersetzt und pool ntp.pool.org (oder so) auskommentiert