• IDSLDAP (at least 6.4) now configures properly aginst FreeIPA
• the rpm packages (aixtoolbox) are being maintained allowing for a much more recent sudo with ldap support (we couldn’t get sudo_ids to work, just go for normal sudo)
• sshd is finally a version with support for AuthorizedKeysCommand

So it was time for a new take on the HBAC front, and after not being successful with either pam_hbac or my own pam_ipahbac, a new look at the code was needed.

Turns out the issue was OpenLDAP. The integration of pam, sshd, idsldap… basically you now need to use idsldap’s libraries so… time for a new release.

Being much simpler to change my code rather than adapt pam_hbac, that’s what I did and now configure detects that one is on AIX and no longer requires OpenLDAP. Still you need special compilation flags so it wa smuch easier for me to just let them be setup in the rpm spec.

Anyway, you can go to the website and download shiny new binaries for 0.0.7 and tar ball if you want, as well as read my definitive AIX/FreeIPA integration guide (which is also quite relevant).

Without HBAC support, when you join a server to a real every single enabled user will be able to login into that server, which just might not be what you want, specially in more “”””enterprise“””” (please do notice the several quotes) environments with different servers having different access roles (developers can go into development servers but not into application life-cycle, operations people not having to logon to developement servers, system administration teams, security officers, etc…).

Some applications sort of implement HBAC by letting you restrict the users that can log into them, but that is definitely not elegant as it defeats the purpose of HBAC: a centralized place where one can define such access rules.

Being a PAM module it needed to have a few features:

1. KISS: it doesn’t have to do much more than get the rules, give success on the first match or just deny for any other reason
2. be secure: be not fancy, worry not about UNICODE, do not worry about supporting the kitchen sink, etc. This means:
   1. most AIX and Solaris environments do not have special characters like ç or ó or µ, and actually user logins are short in length, so a design strategy was to make this module extremely restrictive about the character set it allows, UNICODE is awesome but it’s also a sea of unexpected security issues;
   2. do not over-engineer in libraries and sub-files, just implement the PAM groups it needs, do a simple ldap query, navigate through the results, reply to PAM with allowed or denied
   3. I definitely do not mean to imply pam_hbac is not secure, only that it’s a critical focus on pam_ipahbac

If in the future such fancy use cases that need these things come up, then it can be re-evaluated. It’s not set in stone. Just not the focus. Priorities and such.

And this is why pam_ipahbac was born rather than working with pam_hbac.

I believe jhrozek’s module to be much more advanced, but I also believe in the above principles, and the primary focus of this module is to work in AIX and Solaris so those plagued with those systems can at least use the awesome Free Software that FreeIPA is.

Also, because it’s fun to father some code.

Happy hacking!