Replay cache issue in KfW 3.2.2

[Christian Ullrich]

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