Q1 - How does the driver determine which KDC or Kerberos realm is used?
Q2 - Can different PostgreSQL targets use different Kerberos realms within the same application process?
Q3 - Is there a connection-level property to override the Kerberos realm, KDC address, or Kerberos configuration file?
Q4 - Does the driver support connection-specific credential caches?
Q5 - Does the driver internally create separate Kerberos contexts for each connection?
Q6 - How does the driver prevent credential cache collisions when using multiple threads?
Q7 - Is it supported to use multiple client principals within the same process?
Q8 - What is the recommended method for credential cache isolation on Linux?
Q9 - Can the driver select a specific client principal on a per-connection basis?
Q10 - If multiple principals exist in a keytab file, how is the principal selected?
Q11 - Is there a connection string property to specify the client principal?
Q12 - Can different connections use different client principals concurrently?

Q1: How does the driver determine which KDC/realm is used?
Ans- The DataDirect PostgreSQL ODBC driver delegates all Kerberos realm and KDC
resolution to the underlying system GSSAPI library (e.g., libgssapi_krb5.so).
The driver passes the PostgreSQL server's service principal name (e.g.,
postgres/hostname@REALM) to the GSSAPI library, which then determines the
appropriate KDC by looking up the realm in krb5.conf (pointed to by
KRB5_CONFIG). The driver has no internal code to override or influence this
resolution.

Q2: Can different PostgreSQL targets use different realms in the same process?
Ans- This question covers two distinct scenarios that must be treated separately:

Scenario 1 — Different server realms (e.g., Server A in REALM_A, Server B in
REALM_B):
Yes, this is supported and works automatically. The GSSAPI library reads the
realm from each server's service principal name and contacts the appropriate
KDC as defined in krb5.conf. The application does not need to switch credential
caches or take any special action for this. Each connection to a different
realm is resolved independently by the GSSAPI library.

Scenario 2 — Different client principals authenticating in the same process
(e.g., User A and User B connecting from different threads):
This is where a limitation applies. The driver always uses the process-default
credential cache to obtain client credentials. In a multi-threaded application
using a shared KRB5CCNAME, only one client principal can be active at a time.
If Thread A and Thread B require different Kerberos identities, they will
compete for the same credential cache, resulting in credential overwrites or
use of the wrong principal. Process-level isolation is the recommended solution
for this scenario (see Section B, Q5).

Q3: Is there a connection-level override for realm or KDC configuration?
Ans- No. The driver does not provide any connection string property to override the
Kerberos realm, KDC address, or Kerberos configuration file. These are
controlled exclusively through KRB5_CONFIG and the system Kerberos library
configuration. The application is responsible for ensuring the correct
krb5.conf is in place before the driver is loaded.

Q4: Does the driver support connection-specific credential caches?
Ans- No. The driver does not expose any mechanism to assign a specific credential
cache to an individual connection. All connections within the same process use
whichever credential cache is defined by the KRB5CCNAME environment variable
at the time of the connection, or the Kerberos library default if KRB5CCNAME
is not set.

Q5: Does the driver internally create separate Kerberos contexts per connection?
Ans- Yes. The driver creates a separate GSSAPI security context for each connection.
However, all of these per-connection security contexts are initialized using
the process-default credential cache. This means that while each connection has
its own independent security context, all connections draw their client
credentials from the same credential cache defined by KRB5CCNAME. Having
separate security contexts per connection does not provide credential isolation
between connections.

Q6: How does the driver prevent credential cache collisions?
Ans- The driver does not prevent credential cache collisions. On Linux, the driver
serializes all GSSAPI library calls through an internal process-wide lock,
because the GSSAPI library itself is not thread-safe on Unix. This
serialization ensures that GSSAPI calls do not execute concurrently, but it
does not provide any isolation between credential caches. If multiple threads
share the same KRB5CCNAME, they share the same credential cache, and any
modification to that cache (such as a ticket renewal or a new kinit) affects
all threads simultaneously. Credential cache collision prevention must be
handled externally by the application or system administrator.

Q7: Is it supported to use multiple client principals in the same process?
Ans- Kerberos does support multiple principals within a single process, but only
when each principal uses a separate, independent credential cache. The driver
itself does not provide any connection attribute to select a specific client
principal or assign a specific credential cache per connection. In a
multi-threaded application using a shared KRB5CCNAME, only one client principal
can be active at any given time. Concurrent connections from different threads
will share that principal, and cache overwrites between threads are expected in
this configuration.

Q8 - What is the recommended method for credential cache isolation on Linux?
Ans- The following approaches are listed in order of reliability:

Approach 1 — Process-level isolation (most reliable, recommended)

Run one OS process per Kerberos user. Each process has its own environment
block and therefore its own independent KRB5CCNAME value.

  # Start a worker process for User A:
  export KRB5CCNAME=FILE:/var/tmp/krb5cc_usera
  ./my_app_worker_a

  # Start a separate worker process for User B:
  export KRB5CCNAME=FILE:/var/tmp/krb5cc_userb
  ./my_app_worker_b

Note: KRB5CCNAME cannot be set to two different values simultaneously within
the same process. It must be set to a distinct value in each separate process
before that process starts its ODBC connections.

Approach 2 — Pre-created credential cache files with kinit

Generate credentials for each principal into separate cache files before the
application connects:

  KRB5CCNAME=FILE:/var/tmp/krb5cc_usera \
    kinit -k -t /etc/keytabs/usera.keytab usera@REALM

  KRB5CCNAME=FILE:/var/tmp/krb5cc_userb \
    kinit -k -t /etc/keytabs/userb.keytab userb@REALM

Each worker process then sets KRB5CCNAME to its designated pre-populated cache
file before making any ODBC connection. This works well when combined with
process-level isolation (Approach 1).

Approach 3 — DIR cache type (MIT Kerberos 5 only)

MIT Kerberos 5 supports a directory-based credential cache collection:

  KRB5CCNAME=DIR:/var/tmp/krb5cc_collection

This allows multiple credential entries to coexist in one directory. However,
the concept of a "default" principal within the collection still applies per
process. Switching the active principal within a collection requires using
kswitch. This is a system Kerberos library feature, not a driver feature.
Applicability depends on the MIT Kerberos version installed on the system.

Note: Manipulating KRB5CCNAME per-thread inside a running multi-threaded
process via setenv() is not thread-safe on Linux and must not be used.

Q9: Can the driver select a specific principal per connection?
Ans-No. The driver does not provide a connection string property or any other
mechanism to select a specific client principal for an individual connection.
The client principal used is determined entirely by the content of the active
credential cache (KRB5CCNAME) at the time the connection is established.

Q10: If multiple principals exist in the keytab, how is one selected?
Ans- When KRB5_CLIENT_KTNAME points to a keytab containing multiple principals, the
Kerberos library selects a principal based on its internal matching rules
(typically, the first entry in the keytab that matches the target service's
realm). The driver has no influence over this selection.

To use a specific principal from a multi-principal keytab, the application
should pre-populate the credential cache with the desired principal using kinit
before establishing the ODBC connection:

  KRB5CCNAME=FILE:/var/tmp/krb5cc_target \
    kinit -k -t /path/to/keytab specific_principal@REALM

The ODBC connection is then made in a process where KRB5CCNAME points to that
pre-populated cache file, ensuring the correct principal is used.

Q11: Is there a connection string property to specify the client principal?
Ans- No. The driver does not provide a connection string property to specify the
client principal.
Ans- Clarification on ServicePrincipalName: The driver does have a connection
attribute called ServicePrincipalName, but it serves a completely different
purpose. It specifies the server's Kerberos principal — that is, the identity
of the PostgreSQL service that the driver is authenticating to (for example,
postgres/dbserver.example.com@MYREALM). This tells the driver which service
to target, not which client credential to present. It has no effect on client
principal selection. Client principal selection must be handled externally
through kinit and credential cache management before the connection is made.

Q12: Can different connections use different principals concurrently?
Ans- Not within a single process using a shared KRB5CCNAME. Because the driver
always uses the process-default credential cache for all connections, only one
client principal can be active at a time across all connections in that process.
For concurrent multi-principal workloads, process-level isolation is required:
each user's connections must run in a separate OS process with its own
KRB5CCNAME pointing to a dedicated credential cache.

The DataDirect PostgreSQL ODBC driver delegates all Kerberos credential management to the underlying GSSAPI library (on Linux) or Windows SSPI (on Windows). The driver does not provide connection-level properties to select a client principal, assign a credential cache, or override Kerberos configuration.

Credential isolation for multi-user, multi-threaded workloads must be implemented externally — the recommended approach is process-level isolation, where each user's worker runs in a separate OS process with a dedicated credential cache.