I want newly create files to be owned by the creating user like XP used to do. Under Windows 7 they are owned by administrator.

First, the file's owner on any NT based system has always been whoever is logged in when the file is created (or whoever the process is running as, if you run an elevated/runas/service and it creates a file).
Secondly, NT (and that includes XP, Vista, and Windows 7) has *never* changed ownership of a file when someone is editing it. That would defeat the purpose of NTs ACLs and this functionality has been unchanged since NT4.
Now, some *programs* have an odd habit of creating a new file if you make changes (they delete the old, save the changed file as an entirely new file) and so, by point #1 above, that new file would have a new creator owner.
But, this is how the program writers chose to implement their save functionality, thus it isn't the OS making this "owner" change, and you'd see the same behavior with that program on NT4 and on Windows 7.
In short, it isn't a reliable way to audit file changes, and thus there is no group policy to turn on or off alternate ownership of files, because again, ACLs are a core part of NT security.
Now, Windows *does*  have a robust file autiding system. You can turn on various auditing features so you can see who touched, opened, deleted, file objects even when the owner *doesnt* change. All of that will get written to the security event log if you turn on auditing on those objects. There are a lot of online resources on how to do this, and since I recommend reading them (there is a lot to it, and configured improperly, your event log will fill rapidly), I shall leave it to you to bing-le some results.
Good luck,
-Cliff
 

So tell us more about what's going on...   For example, what is the file type (ie. *.docx) or what application is being used (ie. Microsoft Word).  Can you verify that the Win7 box has the same version of the software (ie. Microsoft Office) as the WinXP boxes?
I wholeheartly agree with cgaliher that there is some major confusion as to how things are supposed to work.

Sorry I wasn't clearer in my first post.  90% of the files are .doc, and .xls.

Both of these file types DO have the "odd habit of creating a new file if you make changes (they delete the old, save the changed file as an entirely new file) and so, by point #1 above, that new file would have a new creator owner.

I recently bought a new lenovo t500 with Windows 7 to replace my t43p.  I reinstalled all software on the t500 using the same office 2003 pro cd that was used 4 years ago on my t43p.  (Right now, my computer is the only one in the domain using Windows 7, all others are XP)

In fact, all computers are using a retail version of office 2003 pro. But, the weird behavior is not restricted to Office.  When I create a txt file using the Explorer context menut, the same thing happens. When I create it on the c: drive it is owned by the local administrator.  When I create it on the server, it is owned by the domain administrator.

Turns out this has been happening ever since I first started using the t500 Windows 7 software 5 months ago.  I just didn't notice until now.

Finally, I agree, sophisticated audit tools are essential for monitoring changes to databases like access, sqlserver and exchange server applications.
Nonetheless, for our simple needs related to xls and doc, the file owner has been totally adequate for the last 5 years.

By the way, the t43p/XP and the t500/W7 are simultaneously connected to the domain.  The XP system works properly, the W7 does not.

I'll admit I am not a security guru, but verifying this weirdness is not rocket science.

I simply create a file, then view the properties and click advanced to see the owner. Yes, I agree ownership on NT based system has always been whoever is logged in when the file is created, but not when I do it on my W7 machine.

And, here is a screen shot just in case you are as skeptical as I would be if I was in your shoes  ;)
temp.jpg

Hummmm, very interesting!
I tried that exact same thing on my Win7 box, and I get the owner set correctly.   So, there is defineately something going on here.
So tell us about the account that you're using when this occurs.... is it a local account or a domain account?   UAC on or off? What are the local group memberships for this account.   Do a screen shot of the registry editor while at expanded HKEY_USERS (so we can see the SID for that account).

cgaliher:

Most of your questions can be answer by looking at my screenshots.

The t500 came with Windows pre-installed, so I can't vounch for much.  I joined it to the domain myself and do not recall any security issues. Everything is standard as far as I know, but something is clearly messed up badly.

I will try another experiment.  I am going to sign off as rberke and sign on as JohnDoe.  That will create a new user profile, which should be instructive.  I will report back in about 10 minutes.

Oh, I just thought of something else....
Did you "clone" the hard drive (or install your Win7 from an corporate "image") or was it an OEM install (or a normal full clean install)?
I'd recommend that you do a CHKDSK on your C: drive (which requires a reboot), to check to see if the NTFS security descriptors are not corrupted.

same problem with John Doe, so a new user profile does not solve the problem
It was a normal OEM install which is all Lenovo ever does. I will run a chkdsk last after I post a few other things.

Where both accounts local or domain?

Post the results of   "fsutil fsinfo ntfsinfo c:" ... I'm most interested in the version number

both rberke and john doe were domain accounts.
Also, no cloning has been done.

UAC was turned off (I did that intentionally several months ago but I can't remember why).  But turning it back on did not help. Except maybe I have to reboot after turning it on??? I hope not but I'll get a reboot shortly, just to be sure.  I will leave UAC on at least until I remember why I turned it off.

Which registry keys do you want me to display. key_Users just has these:
.DEFAULT
S-1-5-18
S-1-5-19
S-1-5-20
S-1-5-21-2971853685-2787453534-2743671043-1157
S-1-5-21-2971853685-2787453534-2743671043-1157_Classes

here comes the reboot, back soon

If it requires a reboot it sure as @#$$ should say so when I turned it on.  I thought Microsoft figured out long ago is that the only thing worse than requiring a reboot is not warning people about it  !!!

Anyhow, the reboot did not help, plus I double checked and control panel still says Always Notify Me.  And, I am getting annoying messages all the time now.  

NTFS Volume Serial Number :       0x7e04f42e04f3e6d5
Version :                         3.1
Number Sectors :                  0x00000000114387f7
Total Clusters :                  0x00000000022870fe
Free Clusters  :                  0x00000000009c6837
Total Reserved :                  0x00000000000007f0
Bytes Per Sector  :               512
Bytes Per Cluster :               4096
Bytes Per FileRecord Segment    : 1024
Clusters Per FileRecord Segment : 0
Mft Valid Data Length :           0x0000000010540000
Mft Start Lcn  :                  0x00000000000c0000
Mft2 Start Lcn :                  0x000000000127c07f
Mft Zone Start :                  0x0000000000ba3240
Mft Zone End   :                  0x0000000000ba4040
RM Identifier:        DCEEC2D4-2FE7-19DF-85F0-002713694E07

C:\Windows\system32>

I'm starting chkdsk and going home.  I will be back in an hour or two.

bob

Things seem to be working better now, although still not  quite as well as under XP.  


It looks like turning on UAC without rebooting did NOT solve the problem.

I erroneously stated that the reboot  after turning on UAC did not help, but it actually DID solve the problem.

I say it is still not quite as nice as XP because XP reported the owner in TWO places.  It first showed under the Security tab as follows
   Authenticated Users                    
   SYSTEM      
   My.Name(my.name@mydomain.local)                          
   Administrators (cpu0109\Administrators)

The My.Name entry no longer appears under the Security tab.  You have to click on Advanced to see it. So, this is not quite as convenient as under Xp, but there is probably a good reason for it.

By the way, I think I know why I turned off UAC.  Now that it is back on Remote Web Workplace no longer allows access from to the server from home. But, that is a question for another day.  

Yep, I turned of UAC and rebooted. Once again, original problem resurfaces, name does not become owner.

I turn UAC back on and rebooted, and things are back to normal.

And, my apologies to Bill Gates, there IS a warnng message about needing to reboot.  I just missed it before.

I am very close to closing this problem

UAC has 4 levels 1 = off 4 = highest security (and most annoying messages)

Only level 1 has the problem with owner not being established.

I currently have my security set to level 3 which does not have too many annoying messages.  

Thanks to everybody for their help, here come the points

Glad to hear it. Disaling UAC definitely has some bad side-effects. Better to adjust it (as you discovered) with the various levels and use the various application compatibility wedges that are avaiilable. I learned that way back with Vista, so for Win7 it was a non-adjustment for me. But enough people skipped Vista that the full ramifications of UAC still aren't known (sadly) and it is only thought of as that annoying warning feature.  But hopefully as app vendors get better, this too will improve.
Good luck. I have RWW working with Win7 and UAC too, so if you want to work on that, I'm sure myself as well as other EE folks can help.
 

When looking at the list of users in the Owner tab, that's the list that you can select to change the ownership of the file to.   A file has only one owner.

>> When looking at the list of users in the Owner tab, that's the list that you can select to change the ownership of the file<<

The list of users/groups in my 11:37 post was not from the Owner Tab in the advanced dialog, it was from the Security tab on the Properties dialog, so it reflects actual security settings, not potential owners to be selected.

XP always adds an extra entry explicitly giving the owner (the user) full control. The occurs when creating a file, OR save and Excel/Word file.

Under Windows 7 on my computer this extra entry is not added.  

I conjecture that this may be because the owner automatically has full authority?  If that is true, it would mean the extra entry for full control was redundant which could explain why it is no longer added under Windows 7.


ANOTHER IMPORTANT POINT
Also, we have discovered that cgaliher <https://www.experts-exchange.com/M_5946720.html>  first statements should be amended to mention UAC.  I believe the following amendment is correct, but I would like opinions.

cgaliher <https://www.experts-exchange.com/M_5946720.html>  first post said

1. The file's owner come from whoever is logged in when the file is created or  whoever the process is running as.

2.  applications like Excel delete the old file then save the changed file as an entirely new file and so, by point #1 above, that new file would have a new creator owner.

Add to 1: If UAC is turned off the file owner  for local files is the local Administrators group for server files the owner is the domain administrators' group for server files.

Add to 2: If UAC is turned off the file modifications in applications like Excel delete then the old file, then save the changed with the same ownership and security permissions that were on the original file.
 

Personally, I find point #2 to be a little odd, but I just verified to be true on my computer with UAC off.

FINAL IMPORTANT POINT
Another unsettling thing about this whole mess: If I was intent upon committing fraud, I could simply disable UAC, make my fraudulent file change, then re-enable UAC.  Of course, there are other ways it could be detected, but nonetheless, it seems the Windows 7 is now slightly less secure because Microsoft introduced the ability to turn off UAC.  Xp had no such ability.  I will probably never understand why they would do that.

typo and grammer !!   I should have said:

Add to 2: If UAC is turned off applications like Excel delete the old file, then save the changed file with the same ownership and security permissions that were on the original file.

Well to clear up a few things:
First, to understand the rest of my points, we should clarify something about UAC. Its intention is to prevent a user who may be an administrator from automatically running every process elevated. If the core OS is a castle, UAC is a moat. It isn't an inpenetrable wall, it isn't a security *barrier*, but it does provide some immediate ability for a user to run an administrative account without having the whole town open wide to pillaging.
So, with that in mind, when comparing how secure an OS is, it is only fair to compare *default* configurations. By default, a user in XP was an administrator, not a "limited user" (as XP called them.) Thus, with no UAC, the default configuration of XP was *less* secure than Windows 7. I could disable UAC in Windows 7, but I could also install IIS, turn on various RPC services, enable UPnP, disable the firewall, disable windows update, and basically make the OS less secure than Windows 98. Is it fair to say that Windows 7 is less secure than Windows 98 because I have the capability to make it so? Of course not!
In fact, I'd argue that if MS enforced UAC and didn't allow it to be disabled, anti MS fanboys would call MS fascist and flame them for that. So you ar4e upset that UAC can be disabled, thus making the OS less secure.
Which, on a complete aside, disabling UAC requires administrative privileges, so in a domain environment (or even a workgroup where you actually create "standard users" (the limited user from XP renamed), UAC could not be disabled without an administrator's password. Thus your concern of someone committing fraud is misplaced. An administrator can *always* commit fraud. The administrator can, for example, even in XP, go to the owners tab and *assign* a new owner or delete privileges from the security tab, thus obfuscating your standard method. So yes, an administrator can disable UAC...but that means an Admin has no more power in Win7 to hide their activities than they did in XP. You don't want them to have that power? Don't make them admins and don't give them an admin password.
Which, for all of that, still brings me to an earlier statement I made. Security permission and ownership were *never* meant to be used for auditing and compliance. MS provides a method to do such things, and you aren't using it. Thus saying that a system is less secure because it is being used in a way it wasn't intended to be used is, at best, unfair, and at worst, inaccurate. If UAC threw off the auditing then I'd argue you have a case (and even then, only if the user is not an administrator...for reasons stated above), but in this context, in this situation, I cannot say that a change to how ownership is assigned is even a security principle. It simply isn't.
-Cliff
 

Sorry, I didn't meant to touch a nerve. I agree with 95% of what you said and I am positive that Windows 7 is more secure in 100 other areas.

I don't think I will ever understand why microsoft felt that UAC off should mean Owner = Administrators. I'm sure they would say it is working as designed, but I am not smart enough to understand why that design was correct.

So, in this single area I still think Windows 7 is slightly less secure.  

UAC had been off for quite a while, and I created a few batch files that seemed to work fine.

After turning UAC back on, some of these batch files stopped working.

The most annoying problem was myLogin.bat  in \\server\sharedfolder\. All my users run it automatically as part of the sbs daily login script.

On windows 7 machines, the script did not work. A step that copied data from the Server\Sharedfolder to c:\program filehave would fail with access denied to the c: drive.  

I .  I created a shortcut to mylogin.bat in \\server\sharedfolder
2.  I set the mylogin.lnk shortcut property to say Run As Administrator
3.  I changed my sbs login to call myLogin.lnk  instead of myLogin.bat

This solved my problem.