Audit Log troubleshooting
After enabling audit today I've been finding many of the following:
1341965715||GENERAL|FAILED LOGIN
With no identifying data it's hard to troubleshoot. Is there a way to increase the verbosity of the audit log?
1341965715||GENERAL|FAILED LOGIN
With no identifying data it's hard to troubleshoot. Is there a way to increase the verbosity of the audit log?
Comments
192.168.20.169 <= <msg data="1|auth|3015|dddbeb9eccdb350328b6ee285c36aa8c" />
-- PROCESS_FLASH_COMMAND origen 1 accion auth destino 3015 password dddbeb9eccdb350328b6ee285c36aa8c
** RECEIVING AUTH REQUEST for 3015
TRYING TO VALIDATE USER 3015
VALIDAR USUARIO 3015
VALIDAR USUARIO 3015 OK con clave regular (192.168.20.169)
(interesting mix of English and - I assume - Spanish)
The system is an Ipiphony with a general login page that links to the FOP2 panel and feeds it the login credentials. The tricky part is that some of my users have bookmarked the URL for the FOP2 panel. The bookmarked page automatically and immediately does a submit with no login entries when it is loaded. When extension is null a debug line like this is generated:
192.168.20.82 <= <msg data="1|auth||c8bca59c92e7dc9123e1f0c8b7fb230a" />
-- PROCESS_FLASH_COMMAND origen 1 accion auth destino password c8bca59c92e7dc9123e1f0c8b7fb230a
** RECEIVING AUTH REQUEST for
ValidateSecret general, no user
Note the missing data after 'auth'.
So mystery solved. I do have a request for the developers though. It took a couple of hours to find a way to link the audit log entry to the debug output. And I had to do it on my live system bouncing FOP2 with debuglevel changes and pissing off my users because I didn't know how to replicate the problem on my test system. It would be a big help if specific audit log entries could be tied to debug output by a timestamp in output.log. Or if the generation of the audit entry was actually in the debug output. In any case I learned a lot!