Die systemd Dateien sind im krb5-server Paket, wenn das nicht installiert ist......
ZitatDa der Rechner wie in #4 geschrieben in einer AD-Domain hängt, sollte soweit ich weiß die Anmeldung am DC über Kerberos laufen.
Dann würde ich da mal nachforschen?
Igel1954 Die waren bei mir auch installiert, hab dann alles gelöscht, was ohne Probleme zu löschen war......
Wie gesagt, einen Kerberos-Server brauche ich auf meinem Rechner eigentlich nicht, der läuft ja auf dem Domain Controller. Die Anmeldung scheint auch zu funktionieren: Mein Suse sagt dass ich Mitglied der Domain bin, auf dem DC bin ich (bzw. mein Rechner) auch als korrekt angemeldetes Mitglied zu sehen.
Hier scheint also alles zu passen...
Was mich etwas irritiert ist dass die Abfrage
Codesystemctl status krb5kdc.service systemctl status kadmind.service systemctl status kpropd.servicebei mir kein Ergebnis bringt. Bei Igel1954 aber schon, obwohl hier nichts mit Kerberos gemacht wird und der nur nebenbei installiert wurde. Oder sind das Server-Dienste?
Die systemd Dateien sind im krb5-server Paket, wenn das nicht installiert ist......
Okay, das sind also Server-Dienste von Kerberos. Aber die brauche ich doch nicht, der Server läuft ja nicht auf meinem Rechner? Oder liege ich da falsch?
Die hast du ja auch nicht.......
Ihr seid komplett auf dem Holzweg.
Das Problem ist rein eine Konfigangelegenheit zwischen dem lokalen Linuxsystem und der kerberisierten Linuxmaschine, die in einer AD läuft. Eine Maschine, zwei Welten.
Um zwischen denen versuchen arme, kleine "Pluggable Authentication Modules" von Linux munter hin- und her zu vermitteln.
Das gelingt hier nur mäßig erfolgreich.
Die Gute Nachricht ist, dass alles tut, was es soll.
Die Schlechte: das Ergebnis weicht weit vom Ziel ab.
Kerberos, der Höllenhund, ist ein sogenannter Ticketgranting Server System. Für das gesamte Netzwerk werden alle Ressourcen zentral verwaltet. Egal, ob Maschine, oder User mit Maschine.
Das funktioniert, weil es in solchen Netzen keine Services gibt, die irgendeinen Dienst ohne gültiges Kerberosticket anbieten. Es sind also alle Dienste so angepasst, dass jede Maschine vor jedem Kontakt mit irgendwelchen Services im "lokalen Netz" sich ein gültiges Ticket besorgen, oder schon haben muss.
Genau diesen Job erledigt eben der "Kerberos- Server".
Der erstellt und prüft jedes Ticket. Der Client meldet sich beim TicketGrantingServer an, authentisiert sich dort und erhält -je nach Konfig des gesamten Netzes- ein Ticket, das ihm an bestimmten Maschinen für bestimmte Dienste zu bestimmten Zeiten usw. usw. usw. Nutzungsrechte erteilt.
Das ist die technische Seite, wie man höchst sicher ein lokales Netzwerk konfiguriert, so dass man zu jeder Zeit sagen kann; "Maschine X hat (mit User soundso) am Rechner Y um <nanosekundengenaueZeitangabe> DiesUndDas" getan.
Das beste, was man über ein solches Sicherheitssystem sagen kann, ist, dass es schon lange auf dem Markt ist, und Hacker sich leichtere Ziele suchen, sobald sie auf einen Höllenhund treffen.
(Meinen Fans mag nicht entgangen sein, wie groß dieses Lob gemeint war.)
So sichere Netzwerke braucht man in grösseren Organisationen.
In denen man mit sehr vielen Users und Maschinen allesamt im Netz umgehen muss.
Fast alle Linuxkisten fahren seit Jahren das PAM.
Deine Fehlermeldung besagt klar, dass auf dem Rechner auf dem der User sich anmelden will, kein PAM Modul fähig war diesen User zu finden.
User not known tothe underlying authentification module
Der Rechner scheint die Login-ID bei der AD nachzuschlagen, statt die locale /etc/passwd nachzufragen.
Verhau im PAM durch AD Verseuchung.
Um es zu lösen, sollte man wissen, ob diese AD noch jemals benötigt wird, oder erhalten bleiben muss.
Du kannst einfach mit PAM ein wenig rumspielen und die AD- lastigen Aktionen einstweilen auskommentieren.
Wenn die AD noch aktuell ist, solltest du dich erst mit den Admins der AD verständigen. Koordiniert mit denen, kann man sauberes Anmelden, wowohl local, als auch in der AD, gleichzeitig betreiben.
Weißt du zufällig, ob und wann dieser Rechner sich zuletzt gültig an der AD angemeldet hat?
Weißt du zufällig, ob und wann dieser Rechner sich zuletzt gültig an der AD angemeldet hat?
Heute - ist das genau genug? Daher meine Aussage von #22:
Mein Suse sagt dass ich Mitglied der Domain bin, auf dem DC bin ich (bzw. mein Rechner) auch als korrekt angemeldetes Mitglied zu sehen.
Da war der Rechner als korrektes AD-Mitglied auf dem DC sichtbar.
Ob die AD erhalten bleiben muss - von mir aus nicht, aber sie sollte. Die existiert zu Lehr- bzw. Übungszwecken, und da sollte sie dann schon mal eine Weile korrekt (in allen Details) laufen.
