[7.904][QUESTION][NOT A BUG] Weblog last logins - last 5 never changing

OK, to clarify a few points about the userlog in the Webadmin Management main menu:

* Successful logins and storage changes come directly from /var/log/confd.log (and, on a not-so-busy machine, older Confd log files).  That's why successful logins and storage changes show up without any delay.

* The number of userlog entries regarding sucessful logins is limited to 20.  This number is configurable in the backend, but it is fixed in the frontend.  That's why the oldest successful logins can fall off the list even while older failed logins are still shown.

* Failed logins come from a completely different source, via the AUA (Astaro Authentication Agent), the reporting database framework, the inline reporting framework and the file /var/log/reporting/inline/management.ph. That is why they are completely independent, show up with a short delay (typically on the order of 15 minutes), and stay around longer.

* An increasing number of failed logins does not reduce the number of successful logins that are shown.  As fas as i know, the number of failed logins is limited independently (to 25?), but don't take my word for that, i'm not a reporting specialist.

* Do not waste your time testing the userlog on HA/cluster system.  By chance, it mostly works, but HA/cluster was completely forgotten when designing the userlog.  At some point, i need to check the design of the userlog with respect to HA/cluster systems, anyway.

You might wonder why i don't take the failed logins from the Confd log as well, avoiding the typical reporting delay.  That would work for failed webadmin logins, but not for failed logins in other authentication contexts, for example remote access and VPNs.

Yours,
  Ingo

Hi Ingo,

Many thanks for the feedback and interesting to hear this is performing as designed.  Is there any reason why the system is keeping the failed logins for longer than successful logins?  Is there really any need to show the last 20 successful and 20 failed logins independently?
It's fantastic that we can see a summary of all logins, but from a personal view point, being able to see the last 20 logins (whether successful or not) is more than enough.  If someone was serious about monitoring failures then more than likely an SNMP trap would have been configured to show this failure alert on a monitoring platform vs. on the Astaro WebAdmin page.

Just my 2p.

Cheers,

Darren

Is there any reason why the system is keeping the failed logins for longer than successful logins?

Oh, if you have many more failed than successful logins, the successful ones will be kept longer.  [;)]

If i understand correctly, we have always shown the last 25 failed logins.
The official specification by the Product Management Department was to show the last 20 successful logins.  There was no specification regarding failed logins.  So i think not changing the behaviour with respect to failed logins agrees with the principle of least surprise: People are probably used to seeing the last 25 failed logins.

Is there really any need to show the last 20 successful and 20 failed logins independently?
It's fantastic that we can see a summary of all logins, but from a personal view point, being able to see the last 20 logins (whether successful or not) is more than enough.

Um, well, perhaps.
Good to hear this display shows enough information for your purposes.  :-)

On the other hand, if we would count successful and unsuccessful logins together, people could abuse one type to scroll the other type off the screen.  That would somehow be half of a denial of service attack.  OK, it's not really serious, you can always look at the real logs.

Still, it does look somewhat sane to count and handle different things independently, such that you are sure to always have information about both of them.

If someone was serious about monitoring failures then more than likely an SNMP trap would have been configured to show this failure alert on a monitoring platform vs. on the Astaro WebAdmin page.

No doubt.
The userlog on the Management menu is intended just for convenience, not for serious auditing.

Hi Ingo,

Many thanks for the info, appreciate the reply.

Cheers,

Darren

Hi Ingo,

Is there perhaps a way to put a time limit/filter on the failed webadmin login report?  I have failed logins showing from 15th April and I'm not sure that anyone would find this useful.  Would it be possible to say filter entries by 

Hi Darren,

Is there perhaps a way to put a time limit/filter on the failed webadmin login report?  I have failed logins showing from 15th April and I'm not sure that anyone would find this useful.  Would it be possible to say filter entries by 

That is not currently implemented, even though implementing it would be easy.  Management explicitly rejected all suggestions to make the amount of information shown on this tab more configurable.  We definitely can't change anything in this area before the 8.0 GA release, it is too late now.

Thus, i suggest you look at feature.astaro.com whether there is a related feature request and vote for it, or create one if there is none.

Yours,
  Ingo

Many thanks Ingo.  In that case this would be marked as 'notabug' [:)]

Hi Darren,

In that case this would be marked as 'notabug' [:)]

Well, no; the related Mantis issue reads:

13608: In a cluster-environment, the behavior of the list of webadmin sessions is undefined.

That aspect still needs to be checked, and that's why this thread is still marked CONFIRMED/OPEN.  It is probably a rather small issue and not terribly urgent, but we should definitely not forget about it.

Yours,
  Ingo

Hi ,
i am not using cluster !
i had same issues of u see my this thread https://community.sophos.com/products/unified-threat-management/astaroorg/f/102/t/69474

Now i am facing new issues when i have 11 failed login at bottam the sr no doesnt change it remain at 33 ,to chack i logout and login with incorrect passwd then i login with correct login ,correct login was get noticed by login session but failed login was not get notice ,fail login suppose to be 2nd number but that is also Successful

so some login session are not get registered !

some time FAILED LOGIN SESSION SHOW FAILED WHEN U LOGIN AFTER SOME LOGINS /LOGOUT sessions 
edit::::[:D]o u think this is one of the problem "while u enter user name and passwd some time after passing 36% or 90 % webadmin login process stall doesn't go through /webadmin page not display ,login process stall "
thanks

Replying to myself...

The related Mantis issue reads:

13608: In a cluster-environment, the behavior of the list of webadmin sessions is undefined.

That aspect still needs to be checked, and that's why this thread is still marked CONFIRMED/OPEN.  It is probably a rather small issue and not terribly urgent, but we should definitely not forget about it.

Here is what i found when looking into this:

Even though the function userlog_read() was not designed for cluster/HA -
it turns out it just works.

The log file format is basically the same, except that the host name carries a node suffix. As the host name is ignored by the log file parser, that's no problem. The log file parser is using the log file entries from all nodes. For WebAdmin purposes, only those written by the webadmin and acc_agent facilities are used. On the other nodes, the relevant entries are written by the system facility, user ha_sync, so they don't get in the way.

Thus, nothing to do here, let's move on...