[OGo-Users] Automatically Lock an Account on Failed Logins

[Sebastian Reitenbach]

Hi Adam,

users@opengroupware.org wrote: 
> > I took a look at this page:
> > 
http://docs.opengroupware.org/Members/helge/Configurations/FailedLoginLock/view?searchterm=login

> > and have a few questions:
> 
> This feature is documented in WMOGAG.
> http://docs.opengroupware.org/Members/whitemice/wmogag/file_view
unfortunately the chapter "Locking Accounts For Failed Login Attempts" is 
empty. Nevertheless, I can writeup a littlebit, and send it to you, when I 
know how it works and that it works, or not works...

> 
> It also doesn't work
What do you mean with also? So this feature is just unusable because the 
lock out does never happen?

> 
> Implemented in Logic/LSFoundation/OGoContextManager+FailedLogin.m
> 
> See Logic/LSFoundation/OGoContextManager+FailedLogin.m
I'll need to test, and then maybe take a look at these files.

> 
> > 1. Does the administrator has to unlock the account after ogo locked the 
> > account, or is it unlocked automatically after 
MinutesBetweenFailedLogins?
> 
> I think it is locked persistently.
> 
> > 2. I assume there is a mail sent out to notify an Administrator about 
the 
> > locked account, because of the FailedLoginLockInfoMailAddress Default. 
To 
> > whom is mail sent, in case an account is locked?
> 
> Yep,  a mail is sent to the administrator.,
> 
>   if (LockInfoMail == nil) {
>     LockInfoMail = [[ud objectForKey:@"FailedLoginLockInfoMailAddress"]
> copy];
>     if (LockInfoMail == nil)
>       LockInfoMail = @"root";
>   }
> .....
>     [self failLogin_sendInfoMailInCommandContext:cmdCtx
>           to:LockInfoMail
>           from:[root valueForKey:@"email1"]
>           account:_login
>           numberOfFails:FailedCount
>           timeRange:MinutesBetweenFailed];
> 
> 
> > 3. Where does ogo store the failcount? I assume in memory and after a 
> > restart the counter are reset to 0?
> 
> It stores locked status in the isLocked attribute of Person; "is_locked"
> in the "person" table.   It looks like it tries to use the session log
> to compute the failures.
ok, so when it is persistently locked via the is_locked column in the 
database, then the Admin has to reenable the account via the WebUI. That's 
fine for me. thanks.


kind regards
Sebastian