Hey, Hal!
I've been using it for a while now, because it really does simplify management once you get used to it. The big thing to understand is that when you set up PAM to work with IDS, "implicit connections" may not work for such connections in the way you might be used to. For people accessing from remote tools or programs, this isn't a problem. But it may give you grief with cron jobs and the like, as well as for users who have direct shell access. For this reason, I recommend setting up two listener ports, one that's PAM-enabled and one that uses the traditional connection methods. That latter will only work for service accounts (i.e., ones that are local to the machine and exist in /etc/passwd), but will come in handy for cron jobs and the like.
It also gets tricky if you use the Connection Manager. For Connection Manager SLAs servicing PAM-enabled ports, you need to set up an encrypted password file using the onpassword utility so that the CM can connect via that port (since it must explicitly provide a username and password). See the doc for that. I'm not super-comfortable with it, but it is what it is.
I'll save you some trouble and give you my ifmx-auth file, which should have pretty close to the bare necessities to get it to work:
auth required pam_env.so
auth required pam_faildelay.so delay=2000000
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 1000 quiet_success
auth sufficient pam_winbind.so use_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 1000 quiet
account required pam_permit.so
You need to be careful here, because some of the default Linux PAM configuration files (e.g., password-auth) include a line that will cause the system to prompt for password changes when a password is set to expire, and IDS has no idea what to do with that request, so it just sends the password again -- which is promptly logged in clear text to the system log. That's, uhh, bad. The file above has that line removed and the issue is corrected for us now. ;)
Then, when you've got that file created (/etc/pam.d/ifmx-auth on CentOS/Red Hat), you add this to the end of a pam-enabled sqlhosts entry:
my-dbserver onsoctcp myhost.mydomain.com my_service_entry s=4,pam_serv=(ifmx-auth),pamauth=(password)
Hope this helps, and şerefe!
------------------------------
TOM GIRSCH
------------------------------
Original Message:
Sent: Mon April 27, 2020 03:15 PM
From: Hal Maner
Subject: Informix and Single Sign-on Configuration
Hello everyone,
Can you please share your experience (good, bad, feedback, gotchas) with Informix Single Sign-on feature?
I have always used the good old Unix/Linux host accounts as Informix has been supporting by default. It looks like I cannot avoid the single sign-on much longer as I have a requirement to "make Informix authentication work like Microsoft SQL Server's integrated Windows Authentication". I do need to be able to identify the client login back in the database in triggers etc. so I want to make sure the single sign-on feature does carry the client login all they way throughout (and this already generates a question for me about how the existing grants etc. would work and whether or not they would need to be re-done - I know, RTFM!).
Thank you,
Hal Maner
M Systems International, Inc.
#Informix