Jorge's Quest For Knowledge!

All about Windows Server, ADDS, ADFS & ILM/FIM (It is just like an addiction, The more you have, the more you want to have!)

Archive for the ‘Object Deletion/Restore’ Category

(2012-10-22) Presenting At The Experts Conference (TEC) In Barcelona (Spain)

Posted by Jorge on 2012-10-22


As we speak, I’m preparing my presentation and demo’s for tomorrow (Tuesday, October 23rd 2012) about all object recovery methods in all Windows Server versions released until now. It will cover common information related to object recovery and then I will dive in into the technical specific for each method available. This presentation will  consist of two sessions of each 75 minutes and I will also show 4 demo’s, one for each method of recovering objects.

image

Figure 1: Opening Slide Of Session

-

  • Location: Barcelona, Spain – Hotel Rey Juan Carlos I
  • Meeting Room: “J”
  • Time: 10:15 – 11:30 (part 1) & 11:30 – 12:45 (part 2)
  • Session Title: “The Evolution Of Object Recovery In AD – The Road To Perfection – A Technical Deep Dive (Part 1 and Part 2)”
  • Level: 400
  • Abstract: Since the beginning, when Active Directory was first released with Windows 2000 Server, the methods and means for object recovery in AD have evolved and improved each time a new version of Windows was released. In time, the technology made it more easy to recover objects and prevent the loss of data after recovery. We will start this session with an introduction to object recovery related topics, followed by an explanation of all object recovery methods in all versions of AD after an accidental (mass) deletion, including what’s new in Windows Server 2008 R2 and in Windows Server "8". The session will finish with recommendations around object recovery. This session consists of two parts (2x 75 min.) and will include multiple demos!
  • Bios (Dutch): Jorge de Almeida Pinto is Principal Consultant Infrastructure Services binnen Valid (http://www.valid.nl/). Binnen zijn functie heeft hij een sterke focus op Microsoft Identity and Access Management (IAM) technologieën. Aangezien zijn professionele passie in deze technologieën gevonden kan worden, heeft hij zich ook gespecialiseerd in Microsoft producten zoals Active Directory Domain Services (ADDS), Active Directory Lightweight Directory Services (ADLDS), Identity Lifecycle Manager (ILM), Forefront Identity Manager (FIM) en Active Directory Federation Services (ADFS) in contexten zoals analyse, ontwerpen, implementaties, migraties, troubleshooting en recovery.
    Jorge is Microsoft gecertificeerd (MCP, MCSE, MCITP, MCT) en is sinds januari 2006 MVP op het “Identity & Access – Directory Services” vlak.
    Een andere passie van Jorge is het spreken op conferenties en het schrijven van artikelen. Hij is sinds 2006 een frequente spreker op de “The Experts Conference (TEC)” van Quest en andere (Microsoft) conferenties en seminars en sinds 2005 schrijft hij artikelen in het technische blad "NetOpus/NetworkPro".
    Om voorop te blijven, participeert Jorge in beta programma’s van nieuwe Microsoft IAM gerelateerde producten en onderhoudt hij het contact met de Microsoft Product Group door het bijwonen van de jaarlijkse MVP Summit en de maandelijkse “Product Group Interaction Events”. Jorge heeft ook nog een blog welke gevonden kan worden op http://jorgequestforknowledge.wordpress.com/.
  • Bios (English): Jorge de Almeida Pinto is a Principal Consultant Infrastructure Services working for Valid (http://www.valid.nl/). Within his role he has a strong focus on Microsoft Identity and Access Management (IAM) technologies. Because his professional passion can be found in these technologies, he has specialized himself in Microsoft products such as Active Directory Domain Services (ADDS), Active Directory Lightweight Directory Services (ADLDS), Identity Lifecycle Manager (ILM), Forefront Identity Manager (FIM) and Active Directory Federation Services (ADFS) in contexts such as analysis, design, deployment, migration, troubleshooting and recovery.
    Jorge is Microsoft certified (MCP, MCSE, MCITP, MCT) and he has received the MVP Award for “Identity & Access – Directory Services” since January 2006.
    Another passion of Jorge is speaking at conferences and writing articles. He has been a frequent speaker at “The Experts Conference (TEC)” from Quest and other (Microsoft) conferences/seminars since 2006, and he has been writing articles in the Dutch technical magazine “NetOpus/NetworkPro” since 2005.
    To stay ahead, Jorge participates in beta programs of new Microsoft IAM related products and he maintains the contact with the Microsoft Product Group by attending the MVP Summit every year and by participating in the monthly “Product Group Interaction Events”. Jorge also has a blog, which can be found at     http://jorgequestforknowledge.wordpress.com/.

-

With this I would like to thank:

imageimage

  • and of course,last but not least, “Valid” my employer (http://www.valid.nl/) for making this possible

image

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Company/Employer Stuff, Conferences, Object Deletion/Restore | 1 Comment »

(2012-03-28) Managing The ‘Protect From Accidental Deletion’ Option On AD Objects Through PowerShell

Posted by Jorge on 2012-03-28


In this post I explain the “Protect From Accidental Deletion” feature that is made accessible through both “Active Directory Users And Computers” and “Active Directory Administrative Center”. Under the hood that feature in reality is implemented through a combination of ACEs on objects. If you wanted to script the addition or removal of the protection you had to screw with ACEs and that was not always a fun thing to do as it could be quite complex to achieve a simple configuration.

-

Let’s say you want to create and protect the OU "OU=MyProtectedOU,OU=TOPLevel,DC=ADCORP,DC=LAB". The OU "OU=TOPLevel,DC=ADCORP,DC=LAB" already exists and is already protected!

-

[1] Using ADMOD and DSACLS

Creating the OU:

  • ADMOD -sc adaou:1;OU=MyProtectedOU,OU=TOPLevel,DC=ADCORP,DC=LAB

Adding the protection:

  • DSACLS "OU=TOPLevel,DC=ADCORP,DC=LAB" /D "EVERYONE:DC" (DENY ACE for Everyone to DELETE CHILD with the This object only scope)
  • DSACLS "OU=MyProtectedOU,OU=TOPLevel,DC=ADCORP,DC=LAB" /D "EVERYONE:SDDT" (DENY ACE for Everyone to DELETE and DELETE TREE with the This object only scope)

-

[2] Using the Microsoft AD PowerShell CMDlets And Configuring The Correct ACEs

Creating the OU (I know I could use the CMDlet “New-ADOrganizationalUnit”…):

  • $objParent = [ADSI]"LDAP://ADCORP.LAB/OU=TOPLevel,DC=ADCORP,DC=LAB"
  • $objOU = $objParent.Create("organizationalUnit","OU=MyProtectedOU")
  • $objOU.SetInfo()

Adding the protection:

  • Import-Module ActiveDirectory
  • $sidEVERYONE = [System.Security.Principal.SecurityIdentifier]‘S-1-1-0′
  • $ACLParent = Get-Acl "AD:\OU=TOPLevel,DC=ADCORP,DC=LAB"
  • $ACEParent = $sidEVERYONE,"DeleteChild","Deny"
  • $AccessRuleParent = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $ACEParent
  • $ACLParent.AddAccessRule($AccessRuleParent)
  • Set-Acl -ACLObject $ACLParent -Path "AD:\OU=TOPLevel,DC=ADCORP,DC=LAB"
  • $ACLOU = Get-Acl "AD:\OU=MyProtectedOU,OU=TOPLevel,DC=ADCORP,DC=LAB"
  • $ACEOU = $sidEVERYONE,"Delete,DeleteTree","Deny"
  • $AccessRuleOU = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $ACEOU
  • $ACLOU.AddAccessRule($AccessRuleOU)
  • Set-Acl -ACLObject $ACLOU -Path "AD:\OU=MyProtectedOU,OU=TOPLevel,DC=ADCORP,DC=LAB"

Removing the protection:

  • Import-Module ActiveDirectory
  • $sidEVERYONE = [System.Security.Principal.SecurityIdentifier]‘S-1-1-0′
  • $ACLOU = Get-Acl "AD:\OU=MyProtectedOU,OU=TOPLevel,DC=ADCORP,DC=LAB"
  • $ACEOU = $sidEVERYONE,"Delete,DeleteTree","Deny"
  • $AccessRuleOU = New-Object System.DirectoryServices.ActiveDirectoryAccessRule $ACEOU
  • $ACLOU.RemoveAccessRule($AccessRuleOU)
  • Set-Acl -ACLObject $ACLOU -Path "AD:\OU=MyProtectedOU,OU=TOPLevel,DC=ADCORP,DC=LAB"

-

[3] Using the Microsoft AD PowerShell CMDlets And Using The Exposed Property

Creating the OU:

  • Import-Module ActiveDirectory
  • New-ADOrganizationalUnit -Name ‘MyProtectedOU’ -Path ‘OU=TOPLevel,DC=ADCORP,DC=LAB’

REMARK: when using this CMDlet, the default behavior is to protect the created OU

Adding the protection:

  • Import-Module ActiveDirectory
  • Set-ADOrganizationalUnit "OU=MyProtectedOU,OU=TOPLevel,DC=ADCORP,DC=LAB" -ProtectedFromAccidentalDeletion:$true

Removing the protection:

  • Import-Module ActiveDirectory
  • Set-ADOrganizationalUnit "OU=MyProtectedOU,OU=TOPLevel,DC=ADCORP,DC=LAB" -ProtectedFromAccidentalDeletion:$false

-

[4] Using the Quest AD PowerShell CMDlets

Creating the OU:

  • Add-PSSnapin Quest.ActiveRoles.ADManagement
  • New-ADOrganizationalUnit -Name ‘MyProtectedOU’ -Path ‘OU=TOPLevel,DC=ADCORP,DC=LAB’

Adding the protection:

  • Add-PSSnapin Quest.ActiveRoles.ADManagement
  • Add-QADPermission -identity ‘OU=TOPLevel,DC=ADCORP,DC=LAB’ -Deny -Account ‘EVERYONE’ -Right ‘DeleteChild’ -ApplyTo ThisObjectOnly
  • Add-QADPermission -identity ‘OU=MyProtectedOU,OU=TOPLevel,DC=ADCORP,DC=LAB’ -Deny -Account ‘EVERYONE’ -Right ‘Delete,DeleteTree’ -ApplyTo ThisObjectOnly

Removing the protection:

  • Add-PSSnapin Quest.ActiveRoles.ADManagement
  • Get-QADPermission -identity ‘OU=MyProtectedOU,OU=TOPLevel,DC=ADCORP,DC=LAB’ -Deny -Account ‘EVERYONE’ -Right ‘Delete,DeleteTree’ -ApplyTo ThisObjectOnly | Remove-QADPermission

-

[5] Adjusting the default security descriptor for OUs

When you create any object, that object will receive the default explicit permissions as configured in the AD schema. So, by adjusting the default explicit permissions (a.k.a. the default Security Descriptor) for the organizationalUnit objectClass any newly created organizational unit from that point on will receive the new default security descriptor. The change to the default security descriptor can be undone if you desire so! However, just making the change is not enough as the schema is cached for performance reasons. Therefore any changes to the AD schema will be refreshed into the cache within five minutes after the change has been committed into the database. If you cannot wait and you want to reload the schema right away you can follow either of the following procedures:

  1. Start the Active Directory Schema MMC, right-click “Active Directory Schema” and then click “Reload the Schema”
    OR
  2. Add the “schemaUpdateNow” operational attribute to rootDSE with a value of 1

For more detailed information about the schema please see: How the Active Directory Schema Works

-

To adjust the default security descriptor for the organizationalUnit objectClass perform the following steps:

  1. Open ADSIEDIT.MSC and connect to the SCHEMA naming context
  2. Find the object “CN=Organizatinal-Unit” and adjust the value of the “defaultSecurityDescriptor” property
    1. From the default value:
      1. D:(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(OA;;CCDC;bf967a86-0de6-11d0-a285-00aa003049e2;;AO)(OA;;CCDC;bf967aba-0de6-11d0-a285-00aa003049e2;;AO)(OA;;CCDC;bf967a9c-0de6-11d0-a285-00aa003049e2;;AO)(OA;;CCDC;bf967aa8-0de6-11d0-a285-00aa003049e2;;PO)(A;;RPLCLORC;;;AU)(A;;LCRPLORC;;;ED)(OA;;CCDC;4828CC14-1437-45bc-9B07-AD6F015E5F28;;AO)
    2. To the custom value (difference with the default has been highlighted in red):
      1. D:(D;;DCDTSD;;;WD)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;SY)(A;;RPWPCRCCDCLCLORCWOWDSDDTSW;;;DA)(OA;;CCDC;bf967a86-0de6-11d0-a285-00aa003049e2;;AO)(OA;;CCDC;bf967aba-0de6-11d0-a285-00aa003049e2;;AO)(OA;;CCDC;bf967a9c-0de6-11d0-a285-00aa003049e2;;AO)(OA;;CCDC;bf967aa8-0de6-11d0-a285-00aa003049e2;;PO)(A;;RPLCLORC;;;AU)(A;;LCRPLORC;;;ED)(OA;;CCDC;4828CC14-1437-45bc-9B07-AD6F015E5F28;;AO)

clip_image001

Figure 1: Adjusting The Default Security Descriptor Of The ObjectClass OrganizationalUnit

-

REMARK: During my testing with Windows Server “8” Beta, I discovered that there is a difference in behavior between ADUC and ADAC if you select to NOT protect the if the above custom configuration for the default security descriptor is in place. In ADAC, after the new object has been created/instantiated it will in addition remove the protection as expected. However, in ADUC it will not be removed as requested. I’m not sure if Microsoft will change this unexpected behavior for ADUC in the official release of Windows Server “8”. Just be aware of this!

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Delegation Of Control, Object Deletion/Restore, PowerShell | 5 Comments »

(2008-03-26) Free AD Objects Recovery Tools

Posted by Jorge on 2008-03-26


UPDATED: 09-10-2010

A while ago, I wrote about the new feature within Windows Server 2008 to reanimate and populate the attributes from a snapshot backup. That post can be found here. I thought it would be interesting to summarize the tools available that can help you recover deleted objects for free. Some of the tools are CLI based and some are GUI based. Again, some provide basic functionality (hey, it’s free!) and some provide advanced functionality (hey, it’s still free you lucky…).

Tools available to save the day for free:

A tool should not only be able to restore one or a few objects, but it should also be able to restore a complete OU structure with all kinds of objects in that OU structure. It should also be possible to filter objects based upon time. What I mean with the last remark is that until the major accidental deletion, you may have deleted all kinds of objects intentionally, which you may not want to restore. Your best bet to filter on time, is by using the whenChanged attribute, and preferably determine the very first object that was deleted as the deletion occurs from the bottom to the OU that was selected to be (accidentally) deleted. Be careful though with just using the whenChanged attribute. That attribute does not replicate between DCs, so before using any RWDC for the undeletion, make sure to determine the RWDC where the deletion occurred!!!

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Object Deletion/Restore, Tooling/Scripting | 2 Comments »

(2008-03-20) Windows Server 2008 – Reanimating Objects And Restoring Additional Information

Posted by Jorge on 2008-03-20


This post is an updated version of the following post and now contains RTM information: Windows Server Longhorn – Reanimating Objects And Restoring Additional Information

Reanimating Objects and Restoring Additional Information

Basically when restoring deleted objects you have two choices. You either authoritatively restore the object(s) using a DC that has not yet received the tombstone of the deleted object or by using the restore of the system state onto some DC. Another option is to reanimate the object. Both are also mentioned and described in MS-KBQ840001.

In my opinion, one major disappointment with Windows Server 2008 is that it is not possible to do an authoritative restore by stopping and starting the "Active Directory Domain Services" (ADDS). The first time I heard it is possible to stop and start ADDS I envisioned the following scenario when I had to recover one or more objects:

  • Stop ADDS –> NET STOP NTDS
  • Restore the System State –> WBADMIN START SYSTEMSTATERECOVERY
  • Authoritative restore the object(s) –> RESTORE OBJECT "<DN>" or RESTORE SUBTREE "<DN>" (RESTORE DATABASE does not exist anymore in W2K8. In W2K/W2K3 it does exist but it should never be used!)
  • Start ADDS –> NET START NTDS
  • Import LDF files if needed/required –> LDIFDE –i –f <LDF file>

The main issue with reanimating objects is that only the mandatory information or any attribute configured to be preserved is retained (enable bit 3 [2^3=8] on "searchFlags" property of attribute) when the object is deleted. Other information is removed and lost at the moment the object is deleted. So, when reanimating an object only the mandatory information and the information within attributes configured to be preserved will be available again after the reanimation. So, what are you going to do to retrieve the other information that was lost during the deletion?

Although third party solutions are available to help you provide that missing information, Windows Server 2008 is also going to help you with the answer to that question.

The short story is that within Windows Server 2008 you are able to create a snapshot from AD, mount that snapshot and start it as a parallel AD instance and use any utility that is able target that parallel AD instance through another pre-configured LDAP ports than the default LDAP ports à (LDAP: 389, LDAP-SSL: 636, GC: 3268, GC-SSL: 3269)

The long story is a somewhat longer one! ;-)

NTDSUTIL contains a new submenu called SNAPSHOT. Within that submenu new commands are available and one of those commands, ‘CREATE’, creates a snapshot of AD using "Volume Shadow Copy". When the snapshot is created, the logs are replayed and the database is defragmented (compared to offline defrag). Before using that command you need to activate the instance (ADDS or ADLDS) for which you want to create a snapshot. As soon as the snapshot has been created you need to mount it using the command ‘MOUNT <GUID>’ to make it available through the file system. By default the mounted snapshots will available through the C-drive. See picture below. After that you can see the available snapshots with ‘LIST ALL’ and all snapshots that are mounted with ‘LIST MOUNTED’. Unmounting a snapshot is done with ‘UNMOUNT <GUID>’. Deleting a snapshot is done with ‘DELETE <GUID>’ or all snapshots with ‘DELETE *’. As you can see great scripting capabilities!

image

image

As soon as the snapshot has been mounted you need to start the AD within that snapshot as a parallel AD instance. Because the default AD instance on the DC uses the standard LDAP/LDAP-SSL/GC/GC-SSL ports, it is mandatory to specify custom ports. You can specify all four ports if you want to, or just the LDAP port. The other ports will be derived from the LDAP port by adding +1, +2, +3. The rule is that the defined/used ports must be available to be used by the parallel AD instance. It is that simple!

The command to start the parallel AD instance is:

  • CMD –> DSAMAIN –DBPATH <path to NTDS.DIT file within mounted snapshot> -LDAPPORT <custom LDAP port that is free to use>
  • EXAMPLE: DSAMAIN -DBPATH C:\$SNAP_200803201137_VOLUMED$\AD\DB\ntds.dit -LDAPPORT 2389

The command prompt window should NOT be closed as that would stop the parallel AD instance!

Also see the picture below.

image

As soon as the parallel AD instance is up and running you can use any tool like LDP, ADSIEDIT, ADFIND, LDIFDE that is able to target the new AD instance through the custom configured ports and access information within that parallel AD instance. You can even target "Active Directory Users and Computers" and "Active Directory Sites and Services" against the parallel AD instance. There are two ways to do that. The first is through the command "DSA.MSC /SERVER=<DC>:<PORT>" or "DSA.MSC /SERVER=<DC>:<PORT>". The second is to just start the GUI and then retarget the GUI to another DC by specifying: "<DC>:<PORT>" Remember the information within the parallel AD instance is READ-ONLY! By default only Domain Admins are able to look inside the parallel AD instance. All others will be denied access into the parallel AD instance. If you need to allow a non-Domain Admin to access the information within the parallel AD instance you must specify the option called "-allowNonAdminAccess" option in the DSAMAIN command line. Access to the information in the parallel AD instance is still determined through the configured permissions. So, if you don’t have permissions to access some of the information, access will be denied!

As soon as you are ready using the parallel AD instance you can press CTRL+C in the open command prompt window to stop the parallel AD instance from running. Another way is to write the value 1 into the "stopService" operational attribute on the rootDSE of the DC at the specified port. An example of the command line is:

  • CMD –> ADMOD.EXE -h <DC>:<LDAPPORT> -b "" "stopService::1"
  • Example: ADMOD.EXE -h RFSRWDC1:2389 -b "" "stopService::1"

As soon as either one happens, you will not be able to target it through the earlier specified ports and those ports will be available again.

Again, great possibility for scripting!

This all works well if you want to target the parallel AD instance locally on the DC where it is loaded. But, let’s say you would want to target it remotely from your management workstation/server. By default that is not possible because the firewall on W2K8 servers/DCs is by default enabled and there is not firewall exception for it. For that to be possible you need to create a firewall exception for the parallel AD instance. You can do that through the GUI using FIREWALL.CPL or you can also do that through NETSH like:

  • CMD to create firewall exception à NETSH FIREWALL SET PORTOPENING ALL <LDAPPORT> "DSAMAIN-<LDAPPORT>" ENABLE ALL
  • Example: NETSH FIREWALL SET PORTOPENING ALL 2389 "DSAMAIN-2389" ENABLE ALL
  • CMD to remove the firewall exception à NETSH FIREWALL DELETE PORTOPENING ALL <LDAPPORT>
  • Example: NETSH FIREWALL DELETE PORTOPENING ALL 2389

The main use of this feature is to give you the possibility to retrieve the information that was lost when the object was deleted and apply it again after the object has been reanimated using whatever tool. One of the other uses to just be able to compare information between the default AD instance and the parallel AD instance for whatever reason needed. This feature does not replace the required backups that are needed for disaster recovery of a DC, a domain or even a forest! Be aware of that.

Unfortunately there is not tooling available by default that would allow you to retrieve the information in the parallel AD instance and apply it to the reanimated objects. The only way is to create something for yourself with LDIFDE and VBS scripting or buy a third party tool. However since the beginning of march 2008 a friend of mine created a tool that leverages this backup/restore feature. I have tested this tool for numerous times and it works quite well! The best of it all is that the tool is free!!! You can get the tool here.

One of the scenarios that people might try is creating a snapshot, getting the NTDS.DIT out to some place and deleting the snapshot. If that is the case, you can save yourself some time by creating an IFM set on an RWDC for an RWDC. The DSAMAIN tool can load any NTDS.DIT. But, the use of the snapshot/IFM set/NTDS.DIT must be treated as the use of any backup of a DC or the DC itself. Again, only very trusted people should be able to access the NTDS.DIT (not talking about accessing its contents remotely)

And if you want to go all crazy with the scripting capabilities within Windows Vista and Windows Server 2008, I suggest you read more about using "Windows Remote Management" (WinRM) and "Windows Remote Shell" (WinRS). It is possible to do all the above remotely using WinRS!

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Object Deletion/Restore, Windows Server | 4 Comments »

(2007-04-22) Windows Server Longhorn – Reanimating Objects And Restoring Additional Information

Posted by Jorge on 2007-04-22


Reanimating Objects and Restoring Additional Information

Basically when restoring deleted objects you have two choices. You either authoritatively restore the object(s) using a DC that has not yet received the tombstone of the deleted object or by using the restore of the system state onto some DC. Another option is to reanimate the object. Both are also mentioned and described in MS-KBQ840001.

The main issue with reanimating objects is that only the mandatory information or any attribute configured to be preserved is retained when the object is deleted. Other information is removed and lost at the moment the object is deleted. So, when reanimating an object only the mandatory information and the information within attributes configured to be preserved will be available again after the reanimation. So, what are you going to do to retrieve the other information that was lost during the deletion?

Although third party solutions are available to help you provide that missing information, Windows Server Longhorn is also going to help you with the answer to that question.

The short story is that within Windows Server Longhorn you are able to create a snapshot from AD, mount that snapshot and start it as a parallel AD instance and use any utility that is able target that parallel AD instance through another pre-configured LDAP ports than the default LDAP ports (LDAP: 389, LDAP-SSL: 636, GC: 3268, GC-SSL: 3269)

The long story is a somewhat longer one! ;-)

NTDSUTIL contains a new submenu called SNAPSHOT. Within that submenu new commands are available and one of those commands, ‘CREATE’, creates a snapshot of AD using "Volume Shadow Copy". When the snapshot is created, the logs are replayed and the database is defragmented (compared to offline defrag). Before using that command you need to activate the instance (AD or ADAM) for which you want to create a snapshot. As soon as the snapshot has been created you need to mount it using the command ‘MOUNT’ to make it available through the file system. By default the mounted snapshots will available through the C-drive. See picture below.

image

As soon as the snapshot has been mounted you need to start the AD within that snapshot as a parallel AD instance. Because the default AD instance on the DC uses the standard LDAP/LDAP-SSL/GC/GC-SSL ports, it is mandatory to specify custom ports. The command to start the parallel AD instance is:

DSAMAIN –DBPATH:<path to NTDS.DIT file within mounted snapshot> -LDAPPORT:<custom LDAP port that is free to use> -SSLPORT:<custom LDAP-SSL port that is free to use> -GCPORT:<custom GC port that is free to use> -GCSSLPORT:<custom GC-SSL port that is free to use>

Also see the picture below.

image

The custom ports specified in the picture are derived from the default ports by just adding the value of 1000 to it. Of course it is possible to use some other logic. The rule is that the port must be available to be used by the parallel AD instance. It is that simple!

As soon as the parallel AD instance is up and running you can use any tool like LDP, ADSIEDIT, ADFIND, LDIFDE that is able to target the new AD instance through the custom configured ports and access information within that parallel AD instance. As soon as you are ready you can press CTRL+C to stop the parallel AD instance from running. As soon as that happens you will not be able to target it through the earlier specified ports and those ports will be available again.

All the information within the parallel AD instance is read-only when accessed and access to that information is still determined through the configured permissions. So, if you don’t have permissions to access some of the information, access will be denied!

The main use of this feature is to give you the possibility to retrieve the information that was lost when the object was deleted and apply it again after the object has been reanimated. One of the other uses to just be able to compare information between the default AD instance and the parallel AD instance for whatever reason needed. This feature does not replace the required backup that are needed for disaster recovery of a DC, a domain or even a forest!

The use of the snapshot must be treated as the use of any backup of a DC or the DC itself. Again, only very trusted people should be able to use the snapshot.

If you deleted an OU as an accident you can use the following command to reanimate the OU itself before reanimating its leaf objects:

adfind -default -f "lastKnownParent=<distinguishedName of parent OU>" -showdel -dsq | admod -undel
<distinguishedName parent OU> = the "distinguishedName" of the parent OU of the OU that got deleted

As soon as the deleted OU has been reanimated you reanimated its leaf objects:

adfind -default -f "lastKnownParent=<distinguishedName of deleted OU>" -showdel -dsq | admod –undel –unsafe
<distinguishedName of deleted OU> = the "distinguishedName" of the deleted OU that was reanimated previously

REMARK:

As soon as the objects are restored you can export the information from the parallel AD instance and import to the default AD instance. With that a lot of information is retrieved again. How, challenges still exist like restoring the back links. The way to restore those is also mentioned in MS-KBQ840001.

NOTE: this information is based upon a beta release of Windows Server Longhorn and thus subject to change in the final RTM release. Do not use Windows Server Longhorn in a production environment without the explicit commitment from Microsoft for help and support.

Additional interesting links:

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Beta/RC Stuff, Object Deletion/Restore, Windows Server | 1 Comment »

(2007-04-22) Windows Server Longhorn – Protecting Objects

Posted by Jorge on 2007-04-22


Protecting AD objects from accidental deletions or moves

One of the common issues, when managing objects within AD, are accidental deletions or moves. Although the system asks for confirmation (depends on the OS of the DC if I’m not mistaken) it still occurs. Because of that people may either need to reanimate objects or restore them authoritatively. If we are talking about one or two objects it is not that terrible when comparing it with the deletion of an OU with thousands of objects. Also taking the restore of backlinks (e.g. group memberships) it can be a pain and the impact is very high. Information about restoring objects can be found in MS-KBQ840001.

When managing objects using the Windows Server Longhorn version of "Active Directory Users and Computers" a new option is available that mitigates the risk of accidental deletions and moves (see pictures below).

image

image

When creating an OU (left picture) you have the possibility to check the option called "Protect container from accidental deletion" (automatically selected!). It is also possible to use that option after the creation of the OU (or whatever object) by first enabling "Advanced Features" from the pull-down menu and then asking the properties of the object in question and looking at the "Object" tab.

With that, the OU and its leaf objects are protected from deletions or moves when the deletion targets the OU. If the deletion targets a leaf object within that OU, that leaf-object is still deleted. Of course you can also protect a leaf object from being deleted, but the idea here is to configure that option for OUs with leaf objects. Important to know is that the new option does not use something like an attribute. That option just instructs the "Active Directory Users and Computers" MMC to configure additional permissions on the object being protected. The permissions that are configured when that option is that are a DENY "Delete" and a DENY "Delete subtree" for EVERYONE on "This object only". As you can see leaf objects do not inherit those permissions. The strange part here is setting that option on a certain OU does not make the first level of leaf objects (and also lower) to inherit the same option. However when the option is removed from an OU at a certain level it will remove the same option from the first level of leaf objects (and not lower).

When trying to delete an OU that has that option configured you will see something similar like the picture below. If you really want to delete or move an OU that has been configured with that option, you need to remove that option (or the permissions mentioned) first.

image

And now it is time for the fun part. As I mentioned before it is not a new AD feature, but it is a new Windows Server Longhorn "Active Directory Users and Computers" MMC feature. What I’m trying to say here is that within current W2K and W2K3 AD environments this can also be used by just configuring the permissions mentioned above. This is no high-tech feature, but it is one MMC feature just making things easier for people when creating OUs.

If you scripts or tools to create OUs, you might need to consider to add those permissions into the process of creating OUs.

Although it is possible to use configurations like these mentioned here, the most important thing here is to have a correct delegation of control model where someone only gets those permissions or rights that are really needed!

NOTE: this information is based upon a beta release of Windows Server Longhorn and thus subject to change in the final RTM release. Do not use Windows Server Longhorn in a production environment without the explicit commitment from Microsoft for help and support.

Updated Information:

To prevent the accidental deletion or movement of objects (especially organizational units), two Deny access control entries (ACEs) can be added to the security descriptor of each object (DENY "DELETE" & "DELETE TREE") and one Deny access control entries (ACEs) can be added to the security descriptor of the PARENT of each object (DENY "DELETE CHILD"). To do this in Windows 2000 Server and in Windows Server 2003, use Active Directory Users and Computers, ADSIEdit, LDP, or the DSACLS command-line tool. You can also change the default permissions in the AD schema for organizational units so that these ACEs are included by default.

For example, to protect the organization unit that is called Users in the AD domain that is called CONTOSO.COM from accidentally being moved or deleted out of its parent organizational unit that is called MyCompany, make the following configuration:

For the MyCompany organizational unit, add DENY ACE for Everyone to DELETE CHILD with the This object only scope:

·         DSACLS "OU=MyCompany,DC=CONTOSO,DC=COM" /D "EVERYONE:DC"

 

For the Users organizational unit, add DENY ACE for Everyone to DELETE and DELETE TREE with the This object only scope:

·         DSACLS "OU=Users,OU=MyCompany,DC=CONTOSO,DC=COM" /D "EVERYONE:SDDT"

 

The Active Directory Users and Computers snap-in in Windows Server 2008 includes a Protect object from accidental deletion check box on the Object tab. Note The Advanced Features check box must be enabled to view that tab. When you create an organizational unit by using Active Directory Users and Computers in Windows Server 2008, the Protect container from accidental deletion check box appears. By default, the check box is selected and can be deselected. Although you can configure every object in Active Directory by using these ACEs, this is best suited for organizational units. Deletion or movements of all leaf objects can have a major effect. This configuration prevents such deletions or movements. To really delete or move an object by using such a configuration, the Deny ACEs must be removed first.

Additional interesting links:

-

Cheers,
Jorge
———————————————————————————————
* This posting is provided "AS IS" with no warranties and confers no rights!
* Always evaluate/test yourself before using/implementing this!
* DISCLAIMER: http://jorgequestforknowledge.wordpress.com/disclaimer/
———————————————————————————————
############### Jorge’s Quest For Knowledge #############
######### http://JorgeQuestForKnowledge.wordpress.com/ ########
———————————————————————————————

Posted in Active Directory Domain Services (ADDS), Beta/RC Stuff, Object Deletion/Restore | 4 Comments »

 
%d bloggers like this: