deleting password from /savecred ... Attention: Here is how to delete a users saved credentials

BACKGROUND: I had to come up with a set of initialization scripts to automate
custom security settings, symbolic links, user prefs, et al. on
new accounts... wo/requiring I be there for each account created.

Because these scripts required access to the new account's profile
and USER registry tree, it was easiest to run these scripts within
the account itself, the first time it was logged into.

99% of the scripts could run with even a limited user's permissions,
but those last 1% were crucial to security and had to be done by an
administrator.

So, when the scripts started up the user was prompted for an Admin's
name, verified that account was a member of Administrators, and then
"prompted" for the account's password by running a trivial

runas /user:%Admin% /savecred "cmd /c echo gotcha!" >NUL

As long as the above command didn't return an errorlevel, the script
could then go about its business using saved credentials when needed

PROBLEM: This could leave a dangerous loophole in each account because there
is no documented method for revoking such saved credentials.

INELEGENT
SOLUTION: Require each new account to be assigned a random password (one not
likely to be reassigned to it). Log in and initialize the account.
Log off, and switch out the user's password to a different one by
having an Admin "set password" on the account. This effectively
"masks" the saved credentials.

This solution has lots of "special steps" required that are hard
to enforce. A more elegant solution was much desired.

ANALYSIS: By examining what changed on a system (using PC Mag's InCtrl5) the
first time /savecred is used, I discovered a "credentials cache"
kept in each user's profile on the hard drive.

%UserProfile%\Application Data\Microsoft\Credentials\-SID-\Credentials

(where -SID- is a directory named with the current account's SID)

Deleting this file effectively removes the saved credentials.

Note that the saved credentials can still be used if the account is
currently logged in when the cache is deleted. So the credentials
must be kept in memory and the file is only used to reload them.

FINAL
SOLUTION: Each new account can be created "whenever" (I don't have to be
there, no special steps are required when the account is created).

The "Default User" registry hive has been altered to run the first
initialization script at startup. So when a new account gets logged
into for the first time, it gets a copy of the Default User hive
as part of its new profile, and runs the initialization script.

The first initialization script prompts for an Admin's credentials.
If it doesn't get them, it logs off the account. (Note, these are
not "fixed credentials" any account name belonging to Administrators
is acceptable... the password is entered by successfully executing a
trivial echo command with the /savecred switch)

Once credentials have been established, the other initialization
scripts are chained to. They all can use the Admin account name
(saved in an environment variable) along with /savecred when needed.
No additional prompting for passwords required.

The last script in the initialization chain deletes the credentials
cache, deletes the registry entry that runs the initialization
scripts, and finally logs off the account.

The new account has now been completely initialized, no further
special steps are required, no hidden saved credentials to worry
about. The *only* "special step" required in the whole chain of
events is that an administrator must be present to enter his or her
credentials when the account is first logged on.

SYNOPSIS: When you use the /savecred switch to save/reuse credentials in a
runas (and presumably net use) command line, the credentials are
saved on disk as part of the user's profile in a "credentials cache"

This cache is located under the %APPDATA%\Microsoft\Credentials path

Delete this cache file and you effectively remove saved credentials.

Hope you people find this enlightening.

[|%^)