none
AD Module for Windows PowerShell - Insufficient Access Rights to perform the operation RRS feed

  • Question

  • I have a recently upgraded domain that's now running all 2008R2 DCs.  The domain functional level is 2008R2 and the forest functional level is 2003.  I've also created a brand new lab domain with virtual machines and experienced the exact same problem.  When I logon to a DC and open the AD module for Windows Powershell I can run AD related commands like get-adcomputer, get-aduser, etc.  When I try to run any command that modifies attributes though I get an error (listed below).  I'm a member of the domain admins, enterprise admins, schema admins, etc.  The only way I can get it to work is to explicitly add myself to the ACL of an object.  That doesn't make any sense though because by virtue of being a domain admin I should have full control of the object anyway.  In fact if I check effective permissions it even shows me that I do have full control.  Considering I'm experiencing this exact same issue is two totally different 2008R2 domains I can't believe no one else is.  Any ideas?


    Set-ADComputer: Insufficient access rights to perform the operation at line:1 char:15
    + Set-ADComputer <<<<  testPC -Description Test3
    + CategoryInfo          : NotSpecified: (testPC:ADComputer) [Set-ADComputer], ADException
    + FullyQualifiedErrorId : Insufficient access rights to perform the operation,Microsoft.ActiveDirectory.Management.Commands.SetADComputer
    Friday, July 23, 2010 4:07 AM

All replies

  • Sounds like it could be a User Account Control (UAC) issue.  Open the Powershell window using Run As Administrator.

    Alexei

    Friday, July 23, 2010 4:16 AM
  • Sounds like it could be a User Account Control (UAC) issue.  Open the Powershell window using Run As Administrator.

    Alexei


    Sorry, should have mentioned that I tried that too.  Still a no go the majority of the time unless I manually add myself to the ACL of an object with full control. 
    Friday, July 23, 2010 1:07 PM
  • Are you logging on with the original Admin account, or a user  account that's a Domain Admin?
    [string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "
    Friday, July 23, 2010 1:32 PM
  • Are you running this from a DC or your workstation?

    Are the two domains in the same forest?

    Justin

    Friday, July 23, 2010 1:36 PM
  • logging on as an account that's a member of the domain admins group - but not the original administrator account.  This problem seems to only occur if you're doing the powershell from teh actual DC.  If you're running it form a Windows 7 machine it seems to be OK. 
    Friday, July 23, 2010 7:19 PM
  • hmm so thats even weirder. I wonder if thats some sort of a security feature of 2008 AD? I have to work on a 2k8 domain shortly, i'll play around with it and see what happens.

    you arent using a script of any kind, just the Set-ADComputer at a console?

    Friday, July 23, 2010 7:55 PM
  • hmm so thats even weirder. I wonder if thats some sort of a security feature of 2008 AD? I have to work on a 2k8 domain shortly, i'll play around with it and see what happens.

    you arent using a script of any kind, just the Set-ADComputer at a console?


    The intent would be to eventually use it in a script.  But right now I've just been testing via the console.  Let me know if you see similar results. 
    Friday, July 23, 2010 9:00 PM
  • I ran into this too...a workaround is to specify an alternate domain controller with the -Server parameter.
    Jan Egil Ring

    Blog: http://blog.powershell.no
    Twitter: http://twitter.com/janegilring
    • Proposed as answer by octavmarius Sunday, July 17, 2011 5:06 PM
    Thursday, October 14, 2010 8:59 PM
  • I have run into this as well.  I found that directly giving the user (that is executing the powershell script) full control permissions on the objects the script manipulates does work.   I have found that even if the script user has the necessary permissions as a result of their group memberships (domain amins etc), it still doesn't work.

     But this solution is not ideal.  We can't use the -server option because the other DC in our env. is not 2008 R2.

    Thursday, November 18, 2010 1:03 AM
  • As long as you specify the server name with the -Server switch it seems to work - even if you are specifying the server you are on.

    Thursday, September 15, 2011 6:39 PM
  • Did any one resolve this issues, I'm getting something very similar. but different

    I'm trying to use set-ADUser on a Server running 2008R2, and get the insufficient access rights message.

    But only for what I call old users, people  who have been in AD for a long time, New users, added within the last year update normally.
    Now if I run the same commands from powershell on my Windows 7 PC all users update as expected.
    Running as Admin or specifying the server switch doesn't make any difference?!

    Any ideas gratefully received,
    Russ

    Tuesday, September 18, 2012 8:05 AM
  • To answer my own question... it turns out it was user permissions, the account I was using on the server, had less priviledges that than my personal account!
    • Proposed as answer by cvbob Thursday, November 28, 2013 7:52 AM
    Tuesday, September 18, 2012 8:10 AM
  • As long as you specify the server name with the -Server switch it seems to work - even if you are specifying the server you are on.

     I was having the same problem doing

    Get-ADUser -Filter "SamAccountName -eq '$($user.samaccountname)'" -Properties * -SearchBase "dc=xxx,dc=xx,dc=xxxxx,dc=xxx" |            
        Set-ADuser -Server XXDC6 -PasswordNeverExpires $True -Credential (Get-Credential)
    WTH?  Why in the world providing the -Server would matter makes no sense at all! Grrrrrrrrr, Windows... Good thing it keeps me in a job!
     
    • Proposed as answer by cvbob Thursday, November 28, 2013 7:52 AM
    Friday, March 22, 2013 8:31 PM
  • Does installing RSAT include the AD powershell Module?

    Tuesday, October 8, 2013 8:58 PM
  • Does installing RSAT include the AD powershell Module?

    Yes and no. Installing RSAT gives you the option to enable the module. If you have additional questions, I suggest starting your own thread.

    Don't retire TechNet! - (Maybe there's still a chance for hope, over 12,110+ strong and growing)

    Tuesday, October 8, 2013 8:59 PM
    Moderator
  • I was having a similar issue when running the code (our Admin folks wanted to set the Description property to match the DisplayName):

         $users = Get-ADUser -filter * -properties * -SearchBase "ou=myusers,dc=domain,dc=net"
         $users | ForEach-Object {Set-ADUser -identity $_.samaccountname -Description $_.displayname}

    Every time I ran it from the DC, it gave the "Insufficient access rights to perform the operation" on each user object.  As soon as I did this from a Win7 desktop, it worked without error.

    Thursday, November 28, 2013 8:00 AM
  • I am on a windows 7 machine and I get the same error.
    Friday, December 20, 2013 3:57 PM
  • I am on a windows 7 machine and I get the same error.

    Have you verified that your account has sufficient privileges? Are you running elevated?

    This is an ancient thread, you'll get better exposure by starting your own.


    Don't retire TechNet! - (Don't give up yet - 12,420+ strong and growing)

    Friday, December 20, 2013 4:02 PM
    Moderator
  • Domain Admin should normally be good enough permissions-wise in AD to perform set functions on user and computer objects in AD. If you are able, you can also set yourself as Enterprise and Schema Admin for peace of mind. Make sure you run the powershell application as Administrator if you are on a DC, and in-addition to that, most problems with insufficient access rights are because there are some DCs in the domain which may be behind firewalls and depending on the restriction of port traffic, may cause issues with permissioning. As stated above, adding the -server 'Server.domain.com' line (set to the DC you are working on) will usually correct this.

    Monday, February 3, 2014 4:47 PM
  • Hello all,

    I found that setting location to "AD:" drive cause to Set-ADUser run without problems:

    Set-Location AD:

    HTH


    Marcelo Lucas Guimarães - MCP, MCTS, MCDBA, MCITP Blog: http://mlucasg.wordpress.com

    Wednesday, May 7, 2014 6:16 PM
  • I would love to know how this -server is applied.
    Tuesday, January 16, 2018 3:13 PM