We’re looking at enabling password verification for our user id’s to ensure that “rogue” id’s don’t get used.
Having read various articles it does explain that when a user, or intruder, uses an id which doesn’t have the correct password that that user receives an error message.
Does this error get logged to anywhere?
ie: Can we identify (potential) attempts to use a rogue id?
Subject: Logging “intruder” id’s with password verification
Have you tried this on a test domino server? Testing would be the easiest way.
My guess is it does and the guess is from that fact that any other server message a user receives is in the log: Denied access to a server or database, cross-certificate not field for a particular user, etc.
HTH – Cheers
Subject: RE: Logging “intruder” id’s with password verification
Alan/Joe
Thanks for your comments.
We’ve got some selective analysis of the logs in the present environment - but I wasn’t sure if the log did actually record an attempt to use the (old) id for us to track but it would appear from your comments that it does.
As for the testing - not yet is the quick answer. We’re in the middle of a huge infrastructure rollout 30,000+ user migration/upgrades etc and this is a future need. We’ll get round to testing it but I figured there would be some folk out there using Password verification who would confirm the principles!
I’ll try to find some resource now to hit the test lab
Thanks again for your thoughts
Alan
Subject: My suggestion…
I often suggest to customers that they create a mail in DB called “Security Events”. Than in the Monitoring Configuration DB, create and Event Handler that where the event must have the text “ATTEMPT TO ACCESS” in the event message, and the action is to log to the database “Security Events” (choose the proper server/file name). This will than capture the following events in a single spot for you to look at:
ATTEMPT TO ACCESS DATABASE by was denied
ATTEMPT TO ACCESS DATABASE by was denied
ATTEMPT TO ACCESS DATABASE by was restricted
ATTEMPT TO ACCESS DATABASE by was restricted
ATTEMPT TO ACCESS SERVER by was denied
ATTEMPT TO ACCESS SERVER by was denied
Subject: Also… look at the dozens of other Security task events (fatal, failure, high, low, and normal) that can be tracked and pick the ones that meet your needs.