Allow Informix to accept Non PAM aware clients to connect when using PAM PASSWORD mode

Standard Informix Authentication on unix will perform a getpwnam() call to retrieve the encrypted shadow password from the OS, it will then  compare an encrypted version of the password supplied by the client against this, and if they match, authentication would succeed.

Unfortunately, LDAP clients and servers are no longer sending the encrypted passwords across the wire due to Security issues, and some common implementations of authentication like SSSD  specifically stop sending any encrypted password over the network.

We are therefore forced to use PAM to authenticate our several thousand user base.

However, a large portion of our estate use older clients such as OLEDB, or DataDirect ODBC drivers (Like IBM Information server).

These clients will not work when connecting to a PAM configured port, the Engine will only accept clients that have sent the CLNT_PAM_CAPABLE flag to the server. 

Theoretically, this behaviour is only required for connections where PAM is in CHALLENGE mode, as the client will need to be able to deal with PAM callbacks.
However, this is not required in PASSWORD mode, as the password is already sent in the request.

Several older Clients, as well as OLEDB clients will never send this flag, and as such cannot connect, even when using PASSWORD mode.  This is an unnecessary restriction, and is causing significant problems to us and other customers.

--------------------------------------------------------

Our request is to allow PAM clients to connect even when they have not set the flag, but only if the server is in PAM PASSWORD mode:

1- If listener is PAM in PASSWORD mode, then whatever client is connecting, as long as it sends the password, authentication should be done through PAM in transparent mode, even if CLNT_PAM_CAPABLE is not set

2- If listener is PAM in challenge mode, than the variable needs to be sent from the client, and the client needs to answer properly (SQ_ACK?) etc. and old drivers, OleDB, DRDA etc. will not be accepted


Discussions have been ongoing with Javier Sagrera and Andreas Legner, who are aware of our requirement and are aware of what would be required to implement this request.