[14:15] <doev> Hallo. Ich versuche bereits seit längerer Zeit, den Postgres-Server Windows-Logins zu akzeptieren. Das soll über GSSAPI realisiert werden.
[14:16] <doev> Der Ubuntu-Server ist in der Windows Domain. Anmelden mit Windows-Anmeldedaten funktioniert. Per kinit bekomme ich auch ein Ticket.
[14:17] <doev> Beim Anmeldeversuch auf der Postgres-Konsole, bekomme ich aber den Fehler: GSSAPI continuation error: Server not found in Kerberos database
[14:17] <doev> Und an der Stelle komme ich einfach nicht weiter. 
[14:19] <doev> In #postgres weiß dazu auch keiner was.
[14:21] <doev> 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] <doev> Es wäre ja schon mal ein Anfang, wenn ich wüsste, wo ich nach der Kerberos-Datenbank schauen kann.
[14:31] <tomreyn> ist denn der service principal definiert?
[14:31] <tomreyn> die doku für gssapi ist https://www.postgresql.org/docs/current/gssapi-auth.html
[14:31] <le_bot> Title: PostgreSQL: Documentation: 11: 20.6. GSSAPI Authentication (at www.postgresql.org)
[14:33] <doev> 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] <le_bot> Title: How to setup Windows Active Directory with PostgreSQL GSSAPI Kerberos Authentication (at info.crunchydata.com)
[14:33] <doev> Die Doku von Postgres verstehe ich teilweise noch nicht 100%
[14:34] <doev> 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] <doev> string option)."
[14:36] <tomreyn> ich würde erst mal versuchen es unter linux hinzubekommen und mich dann erst um windows kümmern.
[14:36] <doev> ja, ... dachte weil dort auch der Principal angesprochen wird.
[14:38] <doev> Ich verdächtige ja immer noch die Keytab-Datei.
[14:39] <tomreyn> 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] <doev> ja, evtl. besser als ein Chat.
[14:41] <tomreyn> 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] <tomreyn> d.h. für linux-windows-mischbetrieb müsste der konfigurationsparameter krbsrvname angepasst werden.
[14:44] <doev> ein groß geschriebenes POSTGRES probiere ich gerade.
[14:47] <doev> ändert leider nichts.
[14:49] <doev> 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] <doev> endlich ein Lichtblick. Der Service-Benutzer hat tatsächlich keinen verbundenen Dienst.
[15:20] <doev> Wenn ich jetzt noch wüsste, wie ich psql beibringe POSTGRES als Servicename zu benutzen ...
[15:38] <tomreyn> bitt emal 5 zeilen hochscrollen
[16:05] <doev> Habe jetzt festgestellt, dass statt mit "server" mit "server.domain.local" verbinden etwas bringt.  ---- Ticket isn't for us.
[16:05] <doev> und zusätzlich wird ein Ticket für "postgres/...." erstellt.
[16:38] <doev> 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] <doev> Tickets bekomme ich jetzt endlich für POSTGRES/...@DOMAIN .... aber immernoch der gleiche Fehler: Ticket isn't for us.