How do I monitor who's logged in?

We in our department are implementing a new admin policy: everyone in a department which we support will receive admin access to their computers. We need to know (while we are performing this "pilot program" policy on this department) who logged in, and when they did, on any machine. So how could I (using a powershell script, cmd script or other automatic means) find out who logged in to a given windows 7 or XP machine?

You could make a logon script and link it in Group Policy for those computers that echos %date% %time% %username% %computername% to a file on a hidden share somewhere. Then you'll have a centralized log of all logins.

Monitor the event logs on the domain controllers for event 672. It will show all successful logon events for AD users and which computer they logged on from. Filter by computer to get logon events for only those computers that you are interested in.

I think what you're probably looking for is knowing whenever the domain controller / active directory authenticates a user. Some explanation may be found in http://www.windowsecurity.com/articles/windows-active-directory-auditing.html

Audit logon events – This will audit each event that is related to a user logging on to, logging off from, or making a network connection to the computer configured to audit logon events. A good example of when these events are logged is when a user logs on interactively to their workstation using a domain user account. This will generate an event on the workstation, but not on the domain controller that performed the authentication. In essence, logon events are tracked where the logon attempt occurs, not where the user account resides. This setting is not enabled for any operating system, except for Windows Server 2003 domain controllers, which is configured to audit success of these events. It is common and best practice to log these events on all computers on the network.

Enabled on all machines and used with a system that will pull the logs from all machines, I would consider that the most reliable.

Once you've granted access to the administrators group, you may basically "lose" the computer, and it may be difficult to get it back.

Back in a previous job, The Powers That Were (instead of Be) decided it was actually a bangup idea to FORCE me to be in the admin group for the XP Pro workstation assigned to me. As I was an admin of other systems joined to that domain, I had another account for admin purposes which I could use as I saw fit (occasional installation or updates of software, or things like that). It was impractical to swap the roles of those two accounts (Exchange, various servers' group memberships, FS object ACLs, and on and on). I just simply disagreed that I should be forced to log into the system day-to-day as admin. So as a matter of course, I used to set up the local computer's policy (gpedit) to run startup scripts asynchronously and visibly, and established one that ran CMD. Naturally, this showed its window on the logon winstation (I think I'm describing that right, not sure) with a superuser (SYSTEM) security token. From there I could do basically anything I wanted, including removing my day-to-day domain SID from the local admin group (after a fashion), adding my intended admin account to local admin, and setting up a recurring Task Scheduler job to do that every few hours (to get around automatic GPO refreshes).

Giving them admin would also allow them to create local accounts and use them instead of domain accounts, and simply use "net use /user:DOM\user" to authenticate against your domain for access to any network resources, and only when they wanted it. So anything like trying to monitor logons/logoffs might be a bit dicey and inaccurate. With admin access, if I'm not mistaken, it wouldn't be that difficult to "cover their tracks," at least locally (such as clearing the Event Logs, setting up the characteristics of the Event Logging Service, changing the audit policy, etc.)

I would think long and hard about why you're doing this, and maybe find some other way around giving them full admin access. The Windows security model is extremely fine-grained, and just about any object (file, service, registry entry, etc.) can have an ACL, and SIDs (e.g., groups) have a rich set of rights which can be granted them.