UPDATE:
The audit index already tracks everything you should need:
index=_audit action="login attempt" | stats count by user info
ORIGINAL:
1- when a user logs in succcessfully, there's an event that happens in SplunkWeb's splunk web_service log, that can be matched by the search:
index=_internal sourcetype=splunk_web_service user=* action="login" status="success"
Unfortunately though this log declines to log anything at all when a login fails. Possibly if you change log level to DEBUG it might, but that will make it an extremely chatty log.
2- All of the POST's to the /login endpoint will show up in SplunkWeb's web_access log: for instance many events will match this search:
index=_internal sourcetype="splunk_web_access" POST "/en-US/account/login" status=200
Unfortunately SplunkWeb returns 200 even when login fails (and when it should thus return 401).
From what I've seen, and granted I haven't looked into it very long, there's not a good way of differentiating a failed login event from a successful login event. However there's a bad and messy way that might at least stimulate someone else's thinking on the matter.
index=_internal ( sourcetype=splunk_web_service user=* action="login" status="success") OR ( sourcetype="splunk_web_access" POST "/en-US/account/login" status=200 ) | eval loginstatus=if(sourcetype="splunk_web_service",status,loginstatus) | transaction clientip endswith="sourcetype=splunk_web_access" | fillnull loginstatus value="failed" | fillnull user value="unknown" | stats count by user loginstatus clientip
