[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: sane ppolicy choices
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.
>
>