Real world: Changing default permissions for a computer newly joined to a domain

eserfelizeserfeliz Member Posts: 134
Hi everyone,

Not sure whether this belongs in 70-290 or 70-294, but I thought I'd give it a try here; I apologize in advance if my question isn't clear.

I'm trying to set the default security for computer objects that are newly joined to the domain.

Currently, the default behavior is such that a help desk user that joins a computer to our domain has the ability to rejoin the computer to the domain without having to delete the computer account from AD first. All other help desk/technicians must delete the computer object, join a workgroup, reboot, rejoin to the domain and reboot again.

Is there a place/setting that I can change to allow all tech users to rejoin computers without having to delete the computer object in AD and reboot twice before being able to rejoin the domain?
MCP, HDI-SCA, MCDST, Network+, MCTS: W7C, MCITP: EDST7, BS: MIS

In progress: MCSA (70-290 & 70-291), CCENT, CCA XenDesktop 5

Comments

  • pmmcateerpmmcateer Member Posts: 22 ■□□□□□□□□□
    Is there a reason your help desk staff need to be able to remove the computer from the domain once joined, then rejoin? What is the error they get if they don't delete from AD and try to rejoin?
  • Mojo_666Mojo_666 Member Posts: 438
    TBH real world techs do not join computers to the domain as it is scripted/automated into the build process. if using RIS the guid is an atribute in the computer object, in the MDT and SCCM you have a database that holds that info but either way you never want that info deleted.
  • eserfelizeserfeliz Member Posts: 134
    pmmcateer wrote: »
    Is there a reason your help desk staff need to be able to remove the computer from the domain once joined, then rejoin? What is the error they get if they don't delete from AD and try to rejoin?

    They receive the error:

    The following error occurred attempting to join the domain "<domain>"

    Access is denied.

    So we currently have to delete the computer record from AD, change the client to a workgroup computer, reboot, join the computer to the domain, and reboot. I don't want a new SID generated if we have to reimage the machines, I just want them to be able to rejoin the domain using the existing Computer object.
    MCP, HDI-SCA, MCDST, Network+, MCTS: W7C, MCITP: EDST7, BS: MIS

    In progress: MCSA (70-290 & 70-291), CCENT, CCA XenDesktop 5
  • eserfelizeserfeliz Member Posts: 134
    Mojo_666 wrote: »
    TBH real world techs do not join computers to the domain as it is scripted/automated into the build process. if using RIS the guid is an atribute in the computer object, in the MDT and SCCM you have a database that holds that info but either way you never want that info deleted.

    I got it, but our shop is a little backwards: we're just starting to use SCCM to do deployments. Even using SCCM, we still need to delete the computer object, or else the script fails to rejoin the computer to the domain successfully, hence, the manual process.

    Can you tell me where these permissions are set/delegated? Do I need to create a GPO to do this?
    MCP, HDI-SCA, MCDST, Network+, MCTS: W7C, MCITP: EDST7, BS: MIS

    In progress: MCSA (70-290 & 70-291), CCENT, CCA XenDesktop 5
  • Mojo_666Mojo_666 Member Posts: 438
    eserfeliz wrote: »

    Can you tell me where these permissions are set/delegated? Do I need to create a GPO to do this?

    Well tbh I do not quite get what you want to do exactly but you can set permissions over AD objects such as users, computers, groups and OU's etc by selecting the "advanced" view and modifying the security permission as you would do with any other object, that is how I administer my support people and assign perms to build/instal/service accounts.
  • eserfelizeserfeliz Member Posts: 134
    Mojo_666 wrote: »
    Well tbh I do not quite get what you want to do exactly but you can set permissions over AD objects such as users, computers, groups and OU's etc by selecting the "advanced" view and modifying the security permission as you would do with any other object, that is how I administer my support people and assign perms to build/instal/service accounts.

    I was thinking less managing permissions on an object-by-object basis, more of changing the permissions for what will be the default every time a computer object is created.
    MCP, HDI-SCA, MCDST, Network+, MCTS: W7C, MCITP: EDST7, BS: MIS

    In progress: MCSA (70-290 & 70-291), CCENT, CCA XenDesktop 5
  • earweedearweed Member Posts: 5,192 ■■■■■■■■■□
    You may be better served by prestaging your computers in AD.Prestaging Client Computers

    As far as how to move them and how to grant permission to those who should be able to move them (from the computer container to the appropriate OU or group)
    How to Grant Permission to Move Computer Accounts to a User or Group

    By default when you join a computer to AD it is added to the computers container.
    Hope this helps

    I'm not sure why exactly your helpdesk people have to join computers to a workgroup in order to be placed in the correct OU or group. My only guess is that they don't have permission to move the computers in AD and that is what I've addressed.
    No longer work in IT. Play around with stuff sometimes still and fix stuff for friends and relatives.
  • eserfelizeserfeliz Member Posts: 134
    earweed wrote: »
    You may be better served by prestaging your computers in AD.Prestaging Client Computers

    As far as how to move them and how to grant permission to those who should be able to move them (from the computer container to the appropriate OU or group)
    How to Grant Permission to Move Computer Accounts to a User or Group

    By default when you join a computer to AD it is added to the computers container.
    Hope this helps

    I'm not sure why exactly your helpdesk people have to join computers to a workgroup in order to be placed in the correct OU or group. My only guess is that they don't have permission to move the computers in AD and that is what I've addressed.

    Man, earweed, thanks for this. Seems so easy!
    MCP, HDI-SCA, MCDST, Network+, MCTS: W7C, MCITP: EDST7, BS: MIS

    In progress: MCSA (70-290 & 70-291), CCENT, CCA XenDesktop 5
Sign In or Register to comment.