=== DaKu- is now known as DaKu === TheSphinX_ is now known as TheSphinX^ === it_diver1 is now known as it_diver === it_diver1 is now known as it_diver [14:15] Hallo. Ich versuche bereits seit längerer Zeit, den Postgres-Server Windows-Logins zu akzeptieren. Das soll über GSSAPI realisiert werden. [14:16] Der Ubuntu-Server ist in der Windows Domain. Anmelden mit Windows-Anmeldedaten funktioniert. Per kinit bekomme ich auch ein Ticket. [14:17] Beim Anmeldeversuch auf der Postgres-Konsole, bekomme ich aber den Fehler: GSSAPI continuation error: Server not found in Kerberos database [14:17] Und an der Stelle komme ich einfach nicht weiter. [14:19] In #postgres weiß dazu auch keiner was. [14:21] Und wenn ich mich von einer Windowsmaschine am Server anmelden will: SSPI continuation error: Das angegebene Ziel ist unbekannt oder nicht erreichbar. (80090303) [14:23] Es wäre ja schon mal ein Anfang, wenn ich wüsste, wo ich nach der Kerberos-Datenbank schauen kann. [14:31] ist denn der service principal definiert? [14:31] die doku für gssapi ist https://www.postgresql.org/docs/current/gssapi-auth.html [14:31] Title: PostgreSQL: Documentation: 11: 20.6. GSSAPI Authentication (at www.postgresql.org) [14:33] tomreyn, an der Stelle bin ich mir nicht sicher. Bin nach dieser Anleitung vorgegangen: https://info.crunchydata.com/blog/windows-active-directory-postgresql-gssapi-kerberos-authentication [14:33] Title: How to setup Windows Active Directory with PostgreSQL GSSAPI Kerberos Authentication (at info.crunchydata.com) [14:33] Die Doku von Postgres verstehe ich teilweise noch nicht 100% [14:34] Genau wie das hier: "If running psql on Windows, it may be necessary to deal with case differences- specifically, the service principal might have to be specified to psql in the connection string, or created in active directory as "POSTGRES/pg1.domain.local@DOMAIN.LOCAL" instead (though psql on unix systems would then have to use the connection [14:34] string option)." [14:36] ich würde erst mal versuchen es unter linux hinzubekommen und mich dann erst um windows kümmern. [14:36] ja, ... dachte weil dort auch der Principal angesprochen wird. [14:38] Ich verdächtige ja immer noch die Keytab-Datei. [14:39] ich hab das auch noch nie gemacht. und im netz finden sich da außer der doku eher wenige hinweise zu. ich tippe mal dass postfix support-mailinglisten hat, wo ich dann mal nachfragen würde. [14:39] ja, evtl. besser als ein Chat. [14:41] der hinweis auf Groß-/Kleinschreibung in dem was du eben zitiert hast findet sich auch in der PostgreSQL-Doku selbst: "Some Kerberos implementations might require a different service name, such as Microsoft Active Directory which requires the service name to be in upper case (POSTGRES)." [14:43] d.h. für linux-windows-mischbetrieb müsste der konfigurationsparameter krbsrvname angepasst werden. [14:44] ein groß geschriebenes POSTGRES probiere ich gerade. [14:47] ändert leider nichts. [14:49] allerdings stört mich die Warung von ktpass: Failed to set property 'servicePrincipalName' to 'POSTGRES' on Dn ... WARNING: Unable to set SPN mapping data. If pga already has an SPN mapping installed for POSTGRES, this is no cause for concern. [15:00] endlich ein Lichtblick. Der Service-Benutzer hat tatsächlich keinen verbundenen Dienst. [15:20] Wenn ich jetzt noch wüsste, wie ich psql beibringe POSTGRES als Servicename zu benutzen ... [15:38] bitt emal 5 zeilen hochscrollen [16:05] Habe jetzt festgestellt, dass statt mit "server" mit "server.domain.local" verbinden etwas bringt. ---- Ticket isn't for us. [16:05] und zusätzlich wird ein Ticket für "postgres/...." erstellt. [16:38] die Service Tickets werden immer für postgres/....@DOMAIN erstellt. Das könnte echt daran liegen. Nur wie gebe ich den Parameter richtig mit? [16:43] Tickets bekomme ich jetzt endlich für POSTGRES/...@DOMAIN .... aber immernoch der gleiche Fehler: Ticket isn't for us.