Hi,
We have a customer setup where the corporate identity management applications provisions users to the directory, resets their passwords etc...
The tool binds as a specific user and we permit write access to appropriate subtress via an acl.
The customer also uses password policy to enforce policy in ldap.
The problem we have is that the idm tool is obivously also subject to the pwdMinAge and pwdSafeModify policies. The tool never stores a users password so when pwdSafeModify is in effect it cannot provide the old password to satisfy the policy. It obviously also cannot reset the password until pwdMinAge has elapsed.
Giving the rootDN credentials to the tool is also not an option as we would like to keep audit logs clean and have the acl in place to stop the tool from writing all over the place.
So we would like to override password policy for the idm tools bind user similarly as the rootDN is already able to bypass policy.
I found following section in ppolicy.c
1197 static int 1198 ppolicy_bind( Operation *op, SlapReply *rs ) 1199 { 1200 slap_overinst *on = (slap_overinst *)op->o_bd->bd_info; 1201 1202 /* Reset lockout status on all Bind requests */ 1203 if ( !BER_BVISEMPTY( &pwcons[op->o_conn->c_conn_idx].dn )) { 1204 ch_free( pwcons[op->o_conn->c_conn_idx].dn.bv_val); 1205 BER_BVZERO( &pwcons[op->o_conn->c_conn_idx].dn ); 1206 } 1207 1208 /* Root bypasses policy */ 1209 if ( !be_isroot_dn( op->o_bd, &op->o_req_ndn )) { 1210 Entry *e; 1211 int rc;
I would think hacking line 1205 one could hardcode additional dn but I am searching for a cleaner more general solution.
I was thinking on the lines of having a configurable olcPPolicyOverride with a list of dn that override password policy like the rootDN already does.
If I attempted such a patch would it have changes of being accepted from the architectural point of view ?
Any other ideas on how to solve above problem ?
Greetings Christian