locked
Backup Active Directory ACL to restore later RRS feed

  • Question

  • Hello,

    I have to make some modifications to security permissions on AD objects, and I would like to use the get-acl command to back them up and then restore them later if I need.  

    So far, I can backup the permissions and store them as a variable in powershell, delete permissions on an object, then use the set-acl command below to restore them.  The problem is that this "backup" would only be valid as long as my powershell session is open.  Once it's closed, I lose the ACL variable and can't restore any longer.

    I have tried a ton of ways to write this data to a txt file then use the txt file to set-acl, but I keeps erroring. 

    This is for an Active directory computer object.  Let me know if you have any suggestions.  Thanks

    import-module activedirectory

    $acl=Get-Acl -Path "AD:\CN=testserver,OU=Servers,DC=itlab,DC=blah,DC=com"

    $acls = Set-ACL -Path "AD:\CN=testserver,OU=Servers,DC=itlab,DC=blah,DC=com" $acl

    Thursday, December 12, 2019 9:25 PM

All replies

  • You cannot do this with a text file with that code. You need to save the properties and use them to create new ACEs and add them to the DACL,

    You can sue ICACLS to store a DACL in a file and reapply.

    ICACLS /?


    \_(ツ)_/

    Thursday, December 12, 2019 9:34 PM
  • everything I've seen with icacls is specifically for ntfs/file permissions.  Do you know how/if it's even possible to use it for Active Directory Objects?
    Monday, December 16, 2019 7:17 PM
  • Yes. AD perms cannot be managed by ICACLS.

    You will need to design a script that saves the values of the ACES into a CSV or XML file then write a script that reverses that process.


    \_(ツ)_/

    Monday, December 16, 2019 9:02 PM
  • Thank you

    That takes me back to my original post.  

    If anyone knows how to do this with AD Object permissions then please let me know.

    Tuesday, December 17, 2019 4:46 PM
  • I described the exact steps. It is up to you to write the script. Start small. Remember that you have multiple ACEs for each object. How you design code to handle that will depend on what you want to do and how you want to it.

    Perform the steps and inspect the objects. 

    If you are not an experienced coder than I suggest purchasing one of the many tools that are designed to do this.

    In the end you will not want to copy all perms.  First learn AD and how it uses and allocates permissions.  Copying all perms between AD instances will break the target instance.

    Actually what you are trying to do is not something that any trained AD programmer would ever do.  We would define the reason for any changes to the basic AD scheme and the "why" of the change then recreate the rule at the target.

    Without a fairly complete technical understanding of AD you can get into deep trouble very easily.


    \_(ツ)_/

    Tuesday, December 17, 2019 5:33 PM
  • will you please stop replying.  I appreciate your efforts, but you're not answering my question. I know exactly what I want to do and what it's doing.  The only thing I'm asking for is to take the exact data I have in my variable from my original post and put it in a format that can be stored and then re-used later.

    the fact that you mentioned icacls which I can't even use, means you aren't really paying attention to my question. 

    You have not given me anything.  I have already tried capturing the data to a file in multiple ways, which I listed in my original post

    I'm looking for people who may have suggestions on how I can export the data I've mentioned in my post.  I appreciate you trying to help, but I would also appreciate it if you just stopped replying.

    thank you

    Tuesday, December 17, 2019 8:34 PM
  • You clearly do not understand what is happening an how this works.

    Ok mister who already knows everything here is the closest you can get:

    Get-Acl 'AD:OU=TestOU,DC=TESTNET,DC=LOCAL' | 
        select -expand access | 
        Export-Csv acltest.csv
    You will have to learn more before you can actually use the solution you are trying to implement.


    \_(ツ)_/


    • Edited by jrv Tuesday, December 17, 2019 11:00 PM
    Tuesday, December 17, 2019 10:59 PM
  • The following will select only directly applied ACEs to the objects:

    Get-Acl 'AD:OU=TestOU,DC=TESTNET,DC=LOCAL' | 
        select -expand access |
        Where{-not $_.IsInherited} |
        Export-Csv acltest.csv
    


    \_(ツ)_/

    Tuesday, December 17, 2019 11:09 PM
  • If you are really looking for objects within the OU instead of the `OU ACL itself then you have to do this:

    $ou = 'AD:OU=TestOU,DC=TESTNET,DC=LOCAL'
    Get-ChildItem $ou -PipelineVariable obj| 
        ForEach-Object{Get-Acl ('AD:' + $_.DistinguishedName)} |
        Get-Acl -PipelineVariable acl | 
        select -expand access |
        Where{-not $_.IsInherited} |
        select @{n='DistinguishedName';e={$obj.DistinguishedName}},@{n='Owner';e={$acl.Owner}},* |
        Export-Csv acltest.csv


    \_(ツ)_/


    • Edited by jrv Tuesday, December 17, 2019 11:38 PM
    Tuesday, December 17, 2019 11:37 PM
  • To select a single object then use the OU as a path and select the object. You will have to then get the object and use the above to extract the ACEs. To apply these you will need to write some tricky code to enumerate the ACEs from the file and build ACEs and add them to the ACL of the target object.  Tis will be done in a loop and will require error handling as the old ACEs can conflict with the existing object.


    \_(ツ)_/

    Tuesday, December 17, 2019 11:53 PM
  • I definitely didn't say I knew everything, but you can't disagree that your initial reply had nothing to do with my question, and your following replies after that were not really helpful.  This is not to say your continuing replies are not helpful. 

    The reason people come to these forums and post questions is because we are looking for solutions from people who may have more experience and knowledge, or maybe even have solved the exact issue we're having.  Your first reply was not helpful and your following replies were dismissive and condescending, that is why I responded the way I did. 

    In my case, I have a script that works perfectly well for backing up the ACL and reapplying it to the same object.  I've tested this and it will reassign permissions that I have removed, at least it appears to :).  The problem I'm having is that I can only keep that backup for as long as my powershell session is open. The variable is stored within the powershell session. 

    I understand that the stored powershell variable is very complex and is stored in a certain format that AD can understand and then use rewrite permissions.  That's where I need help.  I need to know, from someone who undersands ACLs a lot better than I, how to export that powershell variable to a file for more long term storage.  I've done a few things that will grab the whole variable, but I also understand that AD is expecting it in a specific format in order to import it in the same way it is stored as a variable.  That's what I'm looking for.

    If you have a full understanding of that stored variable vs trying to grab the same information from a file and recreate it in the same way, and you don't think it can be done, then that's really all I needed.  You have already said this would be a very tricky script, and maybe that's just the case.

    This is a need I ran into, and it would be nice for future reference if someone already knew how to dissect, store, and recreate an AD ACL in the same way it works as just a session variable. If it's super complex and going to take me a ton of time to figure out, then I'll just close this post and not worry about it for now.

    I'll look at some of the information you provided, but I would still like if anyone else has exported/imported acls similar to this for AD.  My need is not that dire at this point, i'm just hopeful that maybe someone has tried to skin this cat already and I can steal their code for my notes. :)

    Thank you

    Wednesday, December 18, 2019 6:24 PM
  • I tried to help you understand why your issue is bogus. AD does not require what you ae asking and your quesiotn is vague. Permissions are managed by the container and not by the object. Permissions on objects should almost never be changed as this prevents objects fro being independent and manageable.

    Containers can be altered but saving and restoring these permissions cannot be done by copying the permissions.  I can possibly be done on a one-shot basis if the person doing this clearly understands Windows security and AD technology at a programmatic (API) level.  Normal GUI trained users do not have the needed training or experience and often try the kind of thing you are trying which can cause damage to AD.

    I have been working with AD at an API and network design level since the first release of AD. I have yet to find a situation where permissions on objects needed changing, backing up or restoring. The reason MS has no tools for this is because it should not be attempted.

    The code I post6ed is examples of how to work with AD permissions and is much the same for permissions on any object in Windows.

    Before altering security in Windows on any object you need to learn the Windows security model and API.  To use this with PowerShell you need to learn PS beyond a beginner level.

    Most examples of using PS with security on the net are either highly targeted, incomplete, incorrect or just not useful.  Without training you will not be able to understand the examples and you will end up with the code in your original post which cannot work and clearly shows a lack of understanding of both AD and Windows security.

    Before attempting to alter anything in Windows beyond a simple file contents you really need to learn Windows technology at the API level.

    Remember that the GUI tools are designed to allow non-technical users to more easily perform technical operations.  They control an limit choices and do the necessary things to display complex objects and situations in an easy to understand way.  When scripting none of this is true.  At best we build CmdLets to simplify API access and to provide task oriented commands that are targeted.  If there was a need to backup an AD object security there would be CmdLets to do this.  The AD permission tools can allow us to view and edit the permissions but they cannot easily save them.  Understanding these fundamental design limitations of any technology is critical to understanding how to automate and script to the technology.

    I understand your frustration.  This happens to most GUI only users when they attempt to transfer GUI tasks to a script.  Learning Windows at a true technical level is necessary.  Any person of normal intelligence and skills can learn this but it takes time.  It cannot be learned by asking questions in forums or by guessing. It must be studying in a logical and layered order.  There are many books that have the full Windows API fully explained with examples but they require a certain amount of basic computer technical training at a basic engineering level.

    If you are at all interested in technical understanding then here is a set of books that can get you a clear and mostly complete baseline:

    https://www.amazon.com/Windows-Internals-Part-architecture-management/dp/0735684189/ref=dp_ob_image_bk

    There are two books part 1 and part 2.  It is comprehensive and up-to-date (thru WS2016)

    For specific subsystems like AD there are number of books that are available.  You should study the ones that apply to your job description.


    \_(ツ)_/

    Wednesday, December 18, 2019 6:54 PM
  • wow, I seriously can't believe you're a moderator.  With behavior like that it chases people away from seeking help.

    You're so focused on putting me down that you can't even see it.  Well, thanks for nothing.  I'll go find another forum where people can discuss and bounce ideas back and forth.  There's not one thing I said in this list that should make you react like this.  All I can hope is you at least see your behavior and respond differently for other people. 

    Thank you for the "enlighment" you have given little old me your declared "gui" only user. 

    Edit:

    I Want to append an answer to anyone else who may be looking for something similar, at least they can get something out of this post.   If you are working with an AD object that you need to modify a lot of permissions on, and also want the option to roll back, then you can use the commands below.  you just have to keep the session open...  There are other options to export a report of all the AD users/objects that have permission on a specific OU, user, computer, but they are not very detailed reports, and you would still be re-adding the permissions manually.  I was not able to get a clear report using the standard get acl commands.  In my case, I run the command to store the acl as a variable (first command), then I make my permission changes in ADUC this was removing a bunch of superfluous permissions.  If I notice issues a while after the change then I can use the second command and apply the permissions back.  This worked for me in testing, I have not had to do it in my production work yet.  

    $acl=Get-Acl -Path "AD:\CN=BURTEST103,OU=Servers,DC=lab,DC=blah,DC=com"

    $acls = Set-ACL -Path "AD:\CN=BURTEST103,OU=Servers,DC=lab,DC=blah,DC=com" $acl



    • Marked as answer by SammySammys Wednesday, December 18, 2019 10:09 PM
    • Unmarked as answer by jrv Wednesday, December 18, 2019 10:18 PM
    • Marked as answer by SammySammys Wednesday, December 18, 2019 10:25 PM
    • Unmarked as answer by jrv Wednesday, December 18, 2019 10:29 PM
    • Edited by SammySammys Friday, December 20, 2019 6:12 PM
    Wednesday, December 18, 2019 10:09 PM
  • Why would you consider constructive criticism "putting you down". You clearly need to take some time to learn the basic technology.  I posted one book that can help you. It is also a good reference and even I refer back to it for some details. Learning and knowing how to learn from documentation, well written books and others with a decade or more experience than you is also a good thing to keep in mind.

    You cannot learn any technology by guessing or demanding that you already know enough.  All of us very senior techs are constantly searching for new understanding.  I am always happy when someone takes the time to share advice or information with me and I have been doing this longer than you have been alive.

    Cool out and learn some new things.  This can be fun once you get the technical basics nailed.


    \_(ツ)_/

    Wednesday, December 18, 2019 10:24 PM