When running in machine context, DPAPI stores the key as an LSA secret. you
won't find the key in a user profile.
I'm not sure, but I believe it is keyed to a user SID. Once the machine was
joined to a domain, the SID used became a domain one - had a domain RID
instead of the old unjoined machine's.
Can you unjoin the machine, then run as system (using task scheduler or the
"at" command) and decrypt?
--
Drew Cooper [MSFT]
This posting is provided "AS IS" with no warranties, and confers no rights.
"Dmitriy Kopnichev" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> How could the profile be default if the schedule wizard asks as who the
cmd
> will run?
> "Roger Abell" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > Interesting. For me it is the default user profile
> >
> > --
> > Roger Abell
> > Microsoft MVP (Windows Server System: Security)
> > MCSE (W2k3,W2k,Nt4) MCDBA
> > "Dmitriy Kopnichev" <(E-Mail Removed)> wrote in message
> > news:%(E-Mail Removed)...
> > > USERPROFILE=C:\Documents and Settings\2 - my directory
> > > cmd opens in the filesystem at C:\WINDOWS\system32>
> > > "Roger Abell" <(E-Mail Removed)> wrote in message
> > > news:%(E-Mail Removed)...
> > > > Check your system time, say it is 7:25 am
> > > > At cmd prompt issue
> > > > at 7:30 /INTERACTIVE "cmd"
> > > > and wait. When the new cmd windows opens issue
> > > > set
> > > > Notice what is the userprofile. Also, notice where
> > > > cmd opens in the filesystem.
> > > > --
> > > > Roger Abell
> > > > Microsoft MVP (Windows Server System: Security)
> > > > MCSE (W2k3,W2k,Nt4) MCDBA
> > > > "Dmitriy Kopnichev" <(E-Mail Removed)> wrote in message
> > > > news:(E-Mail Removed)...
> > > > > When I scheduled the cmd for the first time after a logon a window
> > "run
> > > > as"
> > > > > appeared showing my name and asking for my password. Why do you
> think
> > > the
> > > > > scheduled cmd window runs as System, not me?
> > > > > "Roger Abell" <(E-Mail Removed)> wrote in message
> > > > > news:(E-Mail Removed)...
> > > > > > I believe what efsinfo.exe is saying.
> > > > > > There is an account on each machine, System, that also
> > > > > > is known as the name of the machine with $ at the end
> > > > > > (this is what a domain knows it as).
> > > > > > However, as I recall, you did use the scheduled task trick
> > > > > > and from the cmd windows receive running as System (which
> > > > > > efsinfo say has decrypt capability - something I find wierd)
> > > > > > try using cipher.exe to decrypt the file (right?) and this did
> > > > > > not work. I am stumpted, as it seems you have an encrypted
> > > > > > file with no accounts allowed to decrypt (System does not
> > > > > > really make sense to me).
> > > > > > Out of curiosity, is this an En-Us English version of XP Pro?
> > > > > >
> > > > > > --
> > > > > > Roger Abell
> > > > > > Microsoft MVP (Windows Server System: Security)
> > > > > > MCSE (W2k3,W2k,Nt4) MCDBA
> > > > > > "Dmitriy Kopnichev" <(E-Mail Removed)> wrote in message
> > > > > > news:%(E-Mail Removed)...
> > > > > > > The efsinfo.exe says:
> > > > > > > Users who can decrypt (the file):
> > > > > > > NT AUTHORITY\SYSTEM (ME$(ME$@WORKGROUP))
> > > > > > > What account can decrypt the file?
> > > > > > > "Data Recovery Agents For This File As Defined By Recovery
> Policy"
> > > is
> > > > > > > "Administrator" is written in "Encryption Details for" the
file
> > > window
> > > > > in
> > > > > > > "Advanced Attributes" window.
> > > > > > > The only user Name in "Users Who Can Transparently Access This
> > File"
> > > > in
> > > > > > > "Encryption Details for" the file is "ME$(ME$@workgroup)".
"ME"
> > was
> > > my
> > > > > > > computer name before renaming. The renaming was made for
joining
> > the
> > > > > > domain.
> > > > > > > "Workgroup" was my workgroup name. There was not a Local user
> with
> > > > "ME"
> > > > > > name
> > > > > > > before joining the domain.
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>
>
|
Similar Threads
