Beiträge von G4schberle

Zitat von Berichtigung

Sorry, da bin ich raus.

Für mich ist Apache veraltetes Digitalsteinzeit Zeuchs. Nett, wenn man es sich im Museum mal anguckt.
PHP ist ein vorsätzliches Sicherheitsloch.
(Da muss man glauben, dass sich der PHP- Pfrimmler an das MVC Paradigma hält und beten, dass er auch was kann).
Dann noch hinter PHP Shellscripte aufrufen, ist in diesem Kontext endgültig vorsätzliche Antisicherheit.
Und damit dann die Firewall dynamisch konfigurieren, ist so, als würde man bei einen VW Golf den Reifenwechsel mit einer Feldhaubitze erledigen wollen.

openSUSE ist für einen Server nur sehr bedingt geeignet. Würde ich niemals einsetzen.

Ihr braucht kein Kerberbos, sondern einen Arzt.

Alles anzeigen

Zusammengefasst möchtest du also nur kritisieren, anstatt mir zu helfen? Das ist Schade!

@On Topic:
Habe die Lösung durch Probieren herausgefunden. Die korrekte Syntax lautet:
yast2 users type=ldap ldap_password=foo username=bar foobar
wobei
foo - LDAP-Zugriffspasswort
bar - LDAP Name des zu editierenden Benutzers
foobar - vorgesehene Änderungen am Benutzer in der Form 'option=value' (siehe yast2 users edit help)

Zitat von Berichtigung

Meine Frage nach der Konfig des Authentication Servers war auch ein wenig ein Test

Du musst mich doch nicht testen.
Hättest du mich einfach gefragt, hätte ich dir doch verraten, dass ich ein eigentlich eher hardwarenaher Softwareentwickler bin. Das ist mein erstes Projekt mit Kerberos, aber ich habe mich schon einige Stunden (mittlerweile bestimmt 30+) in die Materie eingelesen und auf dem System ausprobiert.

Zitat von Berichtigung

Bevor ich dir da jetzt noch weiterhelfe, möchte ich eine präzise Beschreibung aller beteiligten Server samt deren Dienste.

Außerdem die Anzahl von Maschinen und User.
Und was du wie verwalten willst, und welches Backend du letztlich für die Authentifizierung einsetzen möchtest.
Letztlich kann Kerberos so ziemlich jede Methode der Benutzerauthentifizierung verwenden.

Alles klar, bevor es zu weiterer Verwirrung kommt die ganze Story, auch wenn das dann etwas ausufert und OT ist:
Ich soll dafür sorgen, dass man über ein Webinterface die Benutzer auf einer Gateprotect Firewall administrieren kann.
Dafür habe ich ein virtuelles Testnetzwerk aufgebaut. In dem Netzwerk befindet sich eine gateprotect Firewall und der openSuse Leap 42.3 Authentication Server. Die Firewall gewährt Benutzern, die sich gegen den Authentification Server mit Kerberos authentifizieren konnten Rechte. Auf dem Authentification Server ist außerdem ein LDAP Directory in dem Benutzerdaten (Mail-Adresse, Telefonnummer, echter Name) der korrespondierenden Benutzer stehen. Ebenfalls auf diesem Server befindet sich ein Apache Webserver auf dem eine php-Seite läuft. Über diese Webseite werden die Benutzerdaten editiert (z.B. Benutzer deaktiviert, sodass die Firewall diese sperrt).
Aktuell funktioniert eigentlich alles, bis auf das ändern der Passwörter. Das LDAP Passwort kann ich mit der entsprechenden php-ldap-Bibliothek ändern, das Kerberos Passwort aber nicht. Daher habe ich versucht die Passwörter mit Smbkrb5pwd zu synchronisieren, was aber nicht funktionierte. Leider ist auch die php-krb Bibliothek kadm5 völlig veraltet und nicht lauffähig. Daher ist mein aktueller Ansatz von der php-Seite aus ein Bash-Script zu starten, welches dann mit dem yast Befehl die Passwörter im Authentification Server ändert. Von hinten durch die Brust ins Knie, ich weiß, aber Hauptsache ist dass es funktioniert.
Dafür muss ich wissen, wie ich die Passwörter von LDAP Benutzern im yast2 Authentification Server mittels Kommandozeilenbefehl ändern kann.

Zitat von Berichtigung

Wie hast du denn dann den Authentication Server in Kerberos konfiguriert?

Eigentlich nichts Besonderes. LDAP Base-DN ist auth.de und das Kerberos Realm heißt dementsprechend AUTH.DE.
Die Kerberos Konfig sieht so aus:

[libdefaults]
    default_realm = AUTH.DE


[realms]
    AUTH.DE = {
        kdc = localhost
        admin_server = localhost
    }


[loggin]

Außerdem gibt es ein Kerberos principal für den LDAP Dienst.
Im Yast2 User-Modul kann man dann der Domäne/dem REALM beitreten und den LDAP service für 'provides identity data' und den Kerberos service für 'handles user authentication' auswählen.

Zitat von Sauerland

Dann kannst du es ja mal versuchen und hier posten....

Definitiv. Falls ich etwas herausfinde dokumentiere ich das hier.

Zitat von Berichtigung

Das, was du Kerberos- Passwort nennst, ist tatsächlich ein LDAP-Spasswort. Egal, welches Backend der LDAP-Server verwendet, er ist zuständig für Änderungen.

So wie ich es hier erlebe sind Kerberos credentials und LDAP Benutzerpasswort zwei unterschiedliche Paar Schuhe. Wenn ich das Benutzerpasswort nur im LDAP ändere (zB. mit ldappasswd), kann sich der Benutzer trotzdem mit seinem alten Passwort gegen Kerberos authentifizieren. Das liegt daran, dass bei der Authentifizierung die Kerberos credentials geprüft werden. Das LDAP Passwort ist dabei egal. Es gibt zwar die Möglichkeit einer Passwortweiterleitung, aber nur von LDAP auf Kerberos und nicht umgekehrt.
Das ist eben das schöne von dem Yast2-Modul. Wenn ich dort das Passwort editiere, dann ändern sich sowohl das LDAP Benutzerpasswort als auch das Passwort in den Kerberos credentials.

Zitat von Berichtigung

frage den Admin des Netzwerkes.

Der bin ich.

Zitat von Sauerland

Dann würde ich mir einen Testuser im LDAP anlegen und mit den Optionen, die ich dir oben schon genannt habe bzw. help zeigt, spielen.....

Ich hab halt gehofft, dass jemand das schon einmal gemacht hat und mir sagen kann wie das geht. Kann ja eigentlich nicht sein, dass LDAP Benutzer immer nur händisch administriert werden und dass in keiner Dokumentation diese Funktion beschrieben steht.

PS: Übrigens vielen Dank, dass ihr mir hier so tatkräftig helft. Ich habe schon eine kleine Odyssey hinter mir und meine Fragen wurden bisher überall ignoriert.

Zitat von Sauerland

Code

yast2 users list local

Das zeigt keine Ergebnisse. Das ist aber auch richtig so, da es keine lokalen Benutzer (außer root) gibt.
yast2 users list ldap hingegen zeigt alle vorhandenen Benutzer an und von denen möchte ich das Passwort ändern.

Zitat von Berichtigung

ldapmodify und ldappasswd sind deine Freunde

Das bringt mir leider auch nix, da für Benutzer-Authentifikation ein Kerberos zuständig ist. Sprich: ldappasswd würde nur das LDAP-Passwort ändern; das Kerberos-Passwort bleibt aber gleich. Wenn ich aber ein neues Passwort in dem Yast2 Modul eintrage, dann ändere dieses automatisch beide Passwörter, LDAP und Kerberos.

Grade mal ausprobiert:
Interessanter Weise führt
yast2 users list ldap edit username=jackdoe password=test nicht zu einem Fehler, sondern zu
jackdoe x
jilldoe x
johndoe x

Das hab ich ja auch schon probiert, aber leider funktioniert das ebenfalls nicht.
Konkret:
linux-69h9:~ # yast2 users edit username=jackdoe password=test
There is no such user.

Könnte das eventuell daran liegen, dass es sich dabei um LDAP Benutzer handelt? In der grafischen Oberfläche muss man ja auch erst den Filter auf LDAP stellen bevor man die LDAP Benutzer angezeigt bekommt.

Hm, danke erstmal für die schnelle Antwort.
Leider hilft mir das nicht wirklich weiter.
Kannst du mir ein Beispiel nennen, wie ich z.B. vom Benutzer mit der uid 'foo' das Passwort auf 'bar' ändere?

Hallo,

ich möchte in der Shell Yast2 aufrufen und dort einen Benutzereintrag editieren.

Soweit ich weiß sollte das mit yast2 users edit gehen.
Allerdings ist mir unklar, wie ich den zu ändernden Benutzer angebe. Und in der Tat erhalte ich nach Eingabe von
yast2 users edit password=test
ich die Fehlermeldung
There is no such user.

Die help Option hilft mir leider nicht weiter. Genauso wenig wie die online verfügbaren Manuals, welche sich leider häufig nur mit der Bedienung der grafischen Oberfläche von Yast2 beschäftigen.

Meine Frage lautet also:
Wie benutzt man yast2 users edit richtig?

Grüße
G4

Danke dir. Damit komme ich schon einmal viel weiter.

Ich hoffe zwar immer noch, dass ich eine entsprechende Zuarbeit von gateprotect bekomme und sich mein Problem somit in Wohlgefallen auflöst, aber ich glaube nicht wirklich dran.