Univention Bugzilla – Bug 35088
Deny logins if user account expiration date has been reached
Last modified: 2022-05-21 08:08:52 CEST
Currently a LDAP bind is possible if a user account has expired/reached the expiration date. This also affects 3rd party products which rely on LDAP bind as authentication method. Possible solution: A cronjob is looking for expired user accounts (*not* expired user passwords!) and disables at least the POSIX/LDAP login for these accounts.
The cronjob script has to search for objects whose shadowExpire values are in a specific range. This is only possible if the LDAP server is able to compare/sort those values. Patching the LDAP schema "nis.schema" has been outsourced to Bug 35329.
The package univention-ldap now adds the attributes shadowMax and shadowExpire to the LDAP indices: - shadowMax → pres - shadowExpire → eq This way, the object lookup will much faster is large environments. The shadowMax attribute is required for Bug #36215 that has been also fixed. YAML: 2014-10-17-univention-ldap.yaml In univention-server-master (src pkg: univention-server) a new cron job has been added that calls the new script /usr/share/univention-directory-manager-tools/lock_expired_accounts on a daily basis. The cron job is called every night at 03:17 (this may be changed via UCR but is undocumented on purpose; if unset 03:17 is used). The cron job may be disabled via directory/manager/user/lock_expired_accounts/cron/enabled. By default, the cron job is enabled. YAML: 2014-10-17-univention-server.yaml The script looks for user accounts that have expired (shadowExpire <= today). For all accounts found, the POSIX account will be locked so a simple LDAP bind will be no longer possible. The windows/kerberos login is handled correctly by Windows/kerberos, so no action is required here. YAML: 2014-10-15-univention-directory-manager-modules.yaml
The latest Jenkins test failed: http://jenkins.knut.univention.de:8080/job/UCS-3.2/job/UCS-3.2-3/job/Autotest%20MultiEnv/SambaVersion=s3,Systemrolle=master/64/testReport/61_udm-users/25_script_lock_expired_accounts/test/
Changes have been also merged to UCS 4. (In reply to Stefan Gohmann from comment #3) > The latest Jenkins test failed: Disabled some checks due to bug #36210 → FIXED ucs-test
OK - ldap indices (shadowExpire in eq, shadowMax in pres) OK - cron job (activated by default, configurable) OK - lock_expired_accounts (last week, dry run, ...) S3: OK - User with shadowExpire < today -> lock_expired_accounts -> account is locked (no UMC, no ldap bind, no kinit, no pam) S4: OK - User with shadowExpire < today -> lock_expired_accounts -> account is locked (no UMC, no ldap bind, no kinit, no pam, no smbclient) FYI: If "Account deactivation" is set to "POSIX disabled" or "all" shadowExpire is set to 1 and lock_expired_accounts then disables the POSIX login method (no more ldapbind). But that should be OK. In a s4 env the users quest and krbtgt have "All disabled" and lock_expired_accounts locks the POSIX login method. Should be OK too. OK - 2014-10-17-univention-ldap.yaml OK - 2014-10-17-univention-server.yaml OK - 2014-10-15-univention-directory-manager-modules.yaml
Please revert the changes, we move this to errata4.0-0.
(In reply to Felix Botner from comment #6) > Please revert the changes, we move this to errata4.0-0. done, see Bug #36215
Is this a duplicate of Bug #36215 ?
This issue has been filled against UCS 4.1. The maintenance with bug and security fixes for UCS 4.1 has ended on 5st of April 2018. Customers still on UCS 4.1 are encouraged to update to UCS 4.3. Please contact your partner or Univention for any questions. If this issue still occurs in newer UCS versions, please use "Clone this bug" or simply reopen the issue. In this case please provide detailed information on how this issue is affecting you.