I think the best way to give feedback to admins who mistakenly logged in as root is to disable root logins whilst still allowing su and sudo. Alternatively have root's .profile display a suitable feedback message and optionally then exit.
If anyone other than an admin is mistakenly logging in as root, you definitely need to at least change root's password :-)
OK, you have revised the question to clarify what it is you want to achieve. You need to minimise the number of services that allow logins and ensure all of them records a successful login. SSH records successful logins via syslog.
If you have several people logging in as "hudson", you need to stop that. It should be a site policy that admins each log in using a unique userid.
You need to ensure that logfile rotation is adjusted so that you can search older logs for whatever period you fell necessary.
You could certainly have a script scheduled by cron that daily greps logins from syslog and which also checks timestamps on critical configuration files.
In addition there are plenty of tools for monitoring configuration file changes. Many Unix systems have an audit subsystem that can be enabled and which could also help.
Personally, I suspect that the best way to provide feedback in the event of a mistake is not to hunt for someone to pin blame on but to explain the problem to the whole group, explain why the change was a mistake and solicit ideas for preventing mistakes.
It isn't asking for your current password because probably you run command/script as yourself, so it uses your credentials.
You can use PowerShell Set-ADAccountPassword for this, if you want more powerful feature to change your password. You can also get credentials from user with Get-Credential.
You can use them after installing RSAT (Remote Server Admin Tools) and importing module through command Import-Module ActiveDirectory.
Best Answer
From the domain controller's perspective, there's no difference between someone looking at AD objects using Active Directory Users and Computers,
net user /domain, or any other tool that looks through the directory. If you really want to audit process creation and termination, see Task Manager shows programs that are running - how can I see the ones that have been ended?That said, you can audit AD object access. First, adjust your domain controllers' audit policy (Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Audit Policy) to audit successful directory service access. Then go to ADUC and enable advanced features (under View). On each OU that contains users, open to Properties window to the Security tab. Click the Advanced button, then switch to the Auditing tab. There, add a List contents (or Full control if you want) entry that applies to Everyone. On the Auditing tab, entries don't grant access; they just mark objects for auditing. Then, any user that runs a program that enumerates those OUs will end up adding an event 4662 (Directory Service Access) to the DC's event log with all relevant information.
Alternatively, you could create a single "honeypot" user account to which all access (Full control) is audited. Since
net user /domainlooks at a few properties of the users it finds, it will trigger the auditing.Further reading: AD DS Auditing Step-By-Step Guide