Hello,
I am sorry to re-open an old thread. It just has some of the points raised.
I am trying to temporarily disable authentication for a group of users from a cron job. I believe that Michael has a good point that users might want to change password, plus the provider would probably prefer that instead of having a liability being responsible.
I searched for ideas online. One way people deal with disabling logins is by changing shell to none. This is however not idea for various reasons, plus won't work for my project. Another idea was to use "shadowexpire: 0" yet it probably won't work either, as I need users to authenticate, and the LDAP server is being used as a persistent datastore for attributes. Users do not need to login to any *nix machines. Removing an account is also a bad idea. I need to implement support for a trial mode. One of the ideas is that often people sign-up for a paid service only after they have lost access to the system. It would be unfriendly to require those eager to become paid customers to re-register.
Would I be able to perhaps: read userPassword hash, prepend '!' or something then write it back to the userPassword [for each user in the group] field? If works, this should probably disable login, yet be reversible. Is this totally crazy?
Sincerely,
Igor Shmukler
On Thu, Mar 5, 2015 at 7:56 PM, Michael Ströder michael@stroeder.com wrote:
Igor Shmukler wrote:
On Thursday, March 5, 2015, Dieter Klünter dieter@dkluenter.de wrote:
I would create and set a password according to RFC-3062, a little Perl script could do this and mail the password to the trial user. I would not allow a user to modify her pasword in a trial period.
Thank you for the suggestion. This certainly is one way to go. Your approach is simple. That's always good. I just need to think whether disallowing password change for trial users is acceptable.
Being a trial user one of the first things I'd test is how I can change my own password.
Generally the password policy is a bad place to limit the life/usage time of an account.
I'd recommend to define separate attributes for status and end-of-trial-time and implement a CRON job which disables the account after the a trial user is reached.
If the trial accounts are removed in any case then slapo-dds and auxiliary object class 'dynamicObject' could be an option. Note that a dynamic entry cannot be modified to a static entry by removing this object class. You'd have to delete and re-add the entry.
Ciao, Michael.