Viviano, Brad wrote:
Adjusting ACL's seems like overkill for this situation and I have to work
within the bounds of what sssd offers. sssd doesn't have a native check for pwdAccountLockedTime when it does ppolicy based checking, the code just isn't there. sssd for LDAP auth does support a True/False check for account locked, which is how Redhat DS, 389ds and IPA do it, from what I've read. I've added a True/False as a schema extension, tested it and it works. If I manually set accountLocked to TRUE on a DN, the user can't login at all, it logs in the messages file the account it locked. Works perfect.
You're still missing the point that if the user didn't provide a password for LDAP Bind, then LDAP authentication *didn't happen*. If SSSD is still doing an LDAP authorization check here, that's a *bug*, because without a successful authentication, it has no way to verify that the provided username matches any particular LDAP entry. Therefore it cannot assert that any particular LDAP attribute has any relevance to the current login attempt.
My question is, is there a better way to set that True/False attribute value
based on pwdAccountLockedTime. What I am looking for is, if pwdAccountLockedTime is set for DN=x, then also set accountLocked=true for DN=x. Sure, I can do that with an external script, but is there a way to do it from within slapd.
Of course you can write a slapd overlay to do this, but it would be a mistake because your security mechanism is broken. Anyone with permission to write to the directory could spoof their username attribute and lockout any user of their choice.
SSSD has a lot of issues. This is why we still recommend nssov.
Basically can I create a virtual attribute so when a user queries for
accountLocked, it actually does a check for something else (pwdAccountLockedTime) and based on that value returns True or False. I'm thinking in terms of a stored procedure offered on many SQL servers.
Thanks, -Brad Viviano