mirror of
https://salsa.debian.org/freeipa-team/freeipa.git
synced 2024-12-23 15:40:01 -06:00
f347c3f230
Add support for bind grace limiting per https://datatracker.ietf.org/doc/html/draft-behera-ldap-password-policy-06 389-ds provides for alternative naming than the draft, using those instead: passwordGraceUserTime for pwdGraceUserTime and passwordGraceLimit for pwdGraceLoginLimit. passwordGraceLimit is a policy variable that an administrator sets to determine the maximum number of LDAP binds allowed when a password is marked as expired. This is suported for both the global and per-group password policies. passwordGraceUserTime is a count per-user of the number of binds. When the passwordGraceUserTime exceeds the passwordGraceLimit then all subsequent binds will be denied and an administrator will need to reset the user password. If passwordGraceLimit is less than 0 then grace limiting is disabled and unlimited binds are allowed. Grace login limitations only apply to entries with the objectclass posixAccount or simplesecurityobject in order to limit this to IPA users and system accounts. Some basic support for the LDAP ppolicy control is enabled such that if the ppolicy control is in the bind request then the number of remaining grace binds will be returned with the request. The passwordGraceUserTime attribute is reset to 0 upon a password reset. user-status has been extended to display the number of grace binds which is stored centrally and not per-server. Note that passwordGraceUserTime is an operational attribute. https://pagure.io/freeipa/issue/1539 Signed-off-by: Rob Crittenden <rcritten@redhat.com> Reviewed-By: Alexander Bokovoy <abokovoy@redhat.com> |
||
|---|---|---|
| .. | ||
| certmonger | ||
| custodia | ||
| html | ||
| migration | ||
| oddjob | ||
| restart_scripts | ||
| share | ||
| tools | ||
| ui | ||
| updates | ||
| wsgi | ||
| Makefile.am | ||
| README.schema | ||
Ground rules on adding new schema Brand new schema, particularly when written specifically for IPA, should be added in share/*.ldif. Any new files need to be explicitly loaded in ipaserver/install/dsinstance.py. These simply get copied directly into the new instance schema directory. Existing schema (e.g. in an LDAP draft) may either be added as a separate ldif in share or as an update in the updates directory. The advantage of adding the schema as an update is if 389-ds ever adds the schema then the installation won't fail due to existing schema failing to load during bootstrap. If the new schema requires a new container then this should be added to install/bootstrap-template.ldif.