Place a computer object in an OU based on the user who added it

Adding a second answer to comments 1 and 2:

1) yes there is a difference and the difference is the point of the discussion.

If you share files on a workgroup computer, they have access permissions to account(s) or group(s).
If you don't have a Domain, the accounts are local to the machine so each user will need an acount on the sharing machine, even if you use groups, you can only add local acounts in the group.

If you have a Domain, the accounts and groups are global to the Domain so you don't need an acount on the local machine sharing the files, only one Domain acount for all machines in the Domain. The difference is that a Domain is a central authentication system (one server for all users on all machines) and a Workgroup is a local authentication system (each machine has its own users that can be differents). When you want to access a Workgroup machine, your computer sends its credentials (login/password you used) and they have to be the same as the ones existing on the remote machine for your connection to be accepted. On a Domain they are the same always as they are "checked by the server" and not the local machine.

2) Nothing prevents you from using the same login on all computers and for all users but you can't use windows without an account (or any modern OS I know). When you install it, it has already an account (and it's an Admin account). If you have only one user and without password, windows won't ask for user/password and will enter alone but it will use the account.

With accounts you can have security if you use it like making user's files private, using limited accounts instead of the Admin account used by windows (with admin, a virus or a bad user has access to your whole computer AND network if you have the same account on all machines), each account has it's own outlook configuration, not all users in the same inbox.

You can also use the windows account to access remote software like a database server for example without the user having to login. If you have the same account for all, all will have the same rights on the database.

Last but not least to prevent a visitor to use the machine as an Admin.

These are the reasons that came to my mind while writing but I'm sure there are a lot more.

Comments on Edit 3 from OP (lack of space... :))

"only one Domain acount for all machines in the Domain" was part of the answer to your Comment 1 asking if there were differences between sharing a folder to a workgroup or to a domain machine so if not we could leave the domain out of the discussion.

Now, on Edit 3: for 1): the common answer from the beginning (as always) yes if you make an account with the same login/password on the workgroup computer as the LDAP account. I use this every day from a linux machine joined to openLDAP on linux server accessing files and printer shared in a XP Home standalone machine (this is the only way as XP Home won't enter a Domain).

2): the situation is not possible, you can't use a domain account on a machine not joined to a domain. What you can do, is again, making an account on the workgroup machine with same login/password as a domain account and yes, you'll access the files on a domain share with domain groups permissions if the domain account you have "replicated" on you machine is in the right groups, even if your machine is not on the domain. I had this situation some years ago as I had a notebook and didn't want to change config every time I was login so I had the same login as my domain account on the notebook and was using it with a normal login (no domain) to connect on the network and it was working exactly as the desktop connected to the domain.

What I am saying in the whole thing is that the common answer is perfectly right, you have only 3 possibilities if you want to make a "real" network (opposed to simple networks like internet connection sharing for example):

• replicate the users on a workgroup or standalone machines. Workgroups are almost useless in my opinion, they are not very different from normal standalone networked machines. They appeared on window 3.11 a long time ago and at this time I had pretty much the same opinion (not saying win 3.11 was not good, it had others good points over 3.1 but that's out of the point)
• use a domain of some kind.
• use the Administrator builtin login for everybody on all machine with the same password and this in far from recomended in a "real" network

It sounds like your "Desktop Support" group has excessive rights, which allow members to overwrite attributes on existing computer accounts.

There's no specific functionality to prevent joining computers with existing names. By not delegating the "Desktop Support" group rights to modify existing computer objects you remove the ability for group members to modify existing computer objects.

If I were you I'd do the following:

• Create an OU in your Active Directory for newly-created computer accounts to "land" in (when created with the default GUI domain join functionality in the client OS). I'm going to call this the "New Computers" OU.

• Redirect the default "Computers" container to the "New Computers" OU using the redircmp utility (Microsoft has specific usage details)

• Delegate the "Desktop Support" group rights to "Create Computer Objects" to the "New Computers" OU.

Members of the "Desktop Support" group will be able to join computers to the domain and the newly-created computer objects will end up in the "New Computers" OU. They will not, assuming you've removed the users' memberships in any higher-privileged groups, be able to modify existing computer objects and, thus, will not be able to join computers to the domain with names that are used by computers joined to the domain already.

Edit:

I am not able to reproduce the behavior you're seeing re: "...an error about not being able to change the Primary Domain DNS Name".

Be aware that the default permissions set on computer objects when you're testing the behavior of the product. The account you use to create the computer object is set as the owner and granted permission (as CREATOR OWNER) to the newly-created object. If you're using the same account to add the "conflicting" computer these permissions are going to allow you to "break" the original computer account. I'm not aware of any way to override this behavior. Your best bet to prevent this behavior from causing problems would be to programmatically reset the owner on newly-created computer objects to "Administrators" and re-apply the default ACL (to remove the ACEs that refer to the original CREATOR OWNER).

I joined a machine named "TEST-SVR01" to my test domain using a member of my "Desktop Support" group. After I did that I reset the ownership on the TEST-SVR01 computer object to "Administrators" and re-applied the default permissions (using the "Default" button on the "Advanced" security dialog).

I attempted to join another machine named TEST-SVR01 to the domain using the same "Desktop Support"-member user and got the error message "Access is denied" during the attempt. The original TEST-SVR01 still had an intact trust relationship with the domain.

There is no simple (or, in my opinion, advisable) way to make "Domain Admins" group members unable to alter existing computer accounts. You could probably do something sickening with "Deny" permissions but you're going to make the product behave in a manner very different from its default. I'd argue that you shouldn't be using "Domain Admins"-member accounts to join computers to the domain. The principle of least privilege dictates that you should only be using "Domain Admins"-member accounts to perform functions for which their excessive rights are necessary, and joining computers to the domain doesn't needthose excessive rights.