Hello all, I'm having a recurring issue with GSSAPI authentication failing in an application using KfW 3.2.2 libraries on Windows Server 2008, specifically, the PostgreSQL database server.
The problem is that, after some authentication attempts (certainly less than 100) have succeeded, the Kerberos replay cache file becomes inaccessible to further updates, causing gss_accept_sec_context() to fail with GSS_S_FAILURE, with no minor error code. As far as I can tell, during authentication, the replay cache file is read completely, then a temporary file is written (presumably containing all current entries plus the new one), the replay cache file is removed and the new one renamed in its place. In my situation, the deletion fails because the file is still open in another process. PostgreSQL uses one "backend" process per client connection. In three separate attempts to get it working, authentication started failing when there were about 12 to 15 simultaneous connections. Using Process Explorer, I found that the replay cache file remains open in each backend that originally authenticated its client using GSSAPI, even after authentication completed. When I then closed these handles, new authentication attempts were successful again. That there were several active processes, each with its own open handle to the file, indicates that updating the cache _can_ succeed even if the file is open in another process; at some point, however, it starts failing. I'm reluctant to disable the replay cache because I don't know whether PostgreSQL implements its own replay protection. PostgreSQL offers various other authentication methods, including through the Windows SSPI mechanism, but GSSAPI is the only one that offers single sign-on through the JDBC driver, for portability reasons. Is there anything I can do to fix this? Thanks in advance for your help. -- Christian ________________________________________________ Kerberos mailing list [email protected] https://mailman.mit.edu/mailman/listinfo/kerberos
