Joining a computer to a domain

What is the exact permission needed to join a computer to a domain? I mean, if there is already a computer object in AD for PC1, and you want to join PC1 to the domain, which exact permission(s) will the user need to do so?

I know that the NewObject - Computer wizard over-delegates, so I want to know the exact permission(s). I am btw thinking of joining a computer to a domain, and not creating a computer object in an OU, or is the permission used to perform both tasks the same (create computer objects)?
Current certs: MCP (210) MCSA (270, 290, 291 and 680) MCTS (680, 640)


  • 7lowe7lowe Member Posts: 178 ■□□□□□□□□□
    I believe by default standard users can add something like 10 computers to a domain. I don't believe there are separate permissions for adding it to the domain or creating the object. If the computer object doesn't exist in AD the adding the computer to the domain creates it.
  • SephStormSephStorm Member Posts: 1,732
    by default, domain admins can add pcs to the domain. If the account is not created in AD, then it MAY (doesnt always work in my enterprise) create the account when it joins.

    You can change the group to whatever group you wish, by creating the account in AD first, and in the box that says" User or Group" change this to the group (or user account) that you want to be able to add computers to the domain.

    act.png 48.3K
  • RomBUSRomBUS Member Posts: 699 ■■■■□□□□□□
    I believe there is a GPO persmission to allow a user to join the computer to the domain no matter if they are administrators or not and 10 count does not take effect
  • higherhohigherho Member Posts: 882
    RomBUS wrote: »
    I believe there is a GPO persmission to allow a user to join the computer to the domain no matter if they are administrators or not and 10 count does not take effect

    There is, its a local security policy under either user assignments or security options (I forget which atm, its very late). Basically by default its set to administrators and backup operators (in 2008R2 I think). Certain security hardening standards dictate you change that to only allow admins to join to a domain.
  • docricedocrice Member Posts: 1,706 ■■■■■■■■■■
    I'm kind of rusty with the Windows side of the world, but to create user and computer objects in AD, I believe your account needs to be in the Account Operators domain group. On the client machine itself, you need administrative-level privileges to join the machine to the domain. When you "join the domain," you're essentially creating a trust relationship between the client and Active Directory and this involves syncing of machine credentials (which in itself is periodically cycled under the hood) and other items like policy configurations.

    A little side rant - use of the word "permissions" has always been a gray area for me. In the Microsoft world, depending on who you talk to there is a distinction between the terms "permissions," "privileges," and "rights." Permissions refer to specific actions you can take against named objects like files, folders, registry keys, etc. such as Read, Write, Modify, Read & execute, Write extended attributes, Take ownership, etc..

    Privileges refer to actions a security context (that is, an account) can perform within an operating system environment based on the security token which is assigned by the Local Security Authority during session logon. Examples are creating users, viewing the Security event log, shutting down the system, modifying the security policy, etc.. Security tokens are generated and attached to the account's root initial process after that account is successfully validated via the SAM or AD (or cached credentials). It's post-authentication.

    Rights ("user logon rights") are functions one can perform before logon and before the security token is assigned. The list is smaller here like "Log on as a service," "Allow log on locally," etc..

    At least, this is how I learned it from reading one of Mark Minasi's books as well as Windows Internals. Now that said, most people use these terms interchangeably. Even many Microsoft articles do this. It doesn't help that there's a section in the policy labeled "User Rights Assignment."

    Getting back to your original question, I'd guess it's SeMachineAccountPrivilege that you're looking for, but you can also check out these lists as well:
    Hopefully-useful stuff I've written:
  • Dracula28Dracula28 Member Posts: 232
    Thanks for the replies guys. I would have written a proper reply, but I have the exam coming up in a couple of weeks time. But what I was really looking for was the exact permission/user right to just join a computer to an already created Computer account.

    I asked the same question here Joining a computer to a domain - forums by Daniel Petri and I think the answer he provided (have not tried it though) might be what I was looking for, but it still does not provide the exact permission(s). Obviously I think Create Computer objects will do the trick too, but that would give you the right to add as well, and not JUST join.

    About the msDSAccountQuota, doesn't it prevail of the user right "add workstations to domain", because by default the Authenticated Users group has the "add workstasions to domain" user right, but if you set the msDSAccountQuota to 0, the user right will have no effect. That's atleast how I remember having read it.
    Current certs: MCP (210) MCSA (270, 290, 291 and 680) MCTS (680, 640)
  • LunchbocksLunchbocks Senior Member FloridaMember Posts: 319 ■■■■□□□□□□
    That is correct; the msDSAccountQuota attribute controls the 10 computer quota that allows authenticated users to join up to 10 computers to the default computer container. Changing it to 0 removes that ability.

    If the default computer container has been redirected with the redircmp command, and the new OU has the proper permissions, this will also prevent standard authenticated users from joining computers to the domain.
    Degree: Liberty University - B.S Computer Science (In Progress)
    Current Certs: CCENT | MCTS | Network+
    Currently Working On: Security+
    2020 Goals: CCNA, CCNP Security, Linux+

Sign In or Register to comment.