Techibee.com

Object deletion will be successful only when the following conditions are satisfied.

• Has appropriates rights for deleting objects in active directory
• The “DisAllow Delete” bit is not set in systemflags attribute of object
• The “IsCriticalSystemObject” attribute is not set to TRUE

After meeting above conditions, active directory starts the deletion operation by doing the following..

• Sets the “IsDelete” attribute of the object to TRUE
• Wipes out all attributes of object except below attributes. Refer to msdn for more details about attributes retained.

• Moves the object to “Deleted Objects” container by renaming it.

Renaming is necessary here as the “deleted objects” container is flat. Object will be renamed to a format similar to “ [OldRDN]ADEL:[GUID]” where GUID is the Global Unique Identifier of object being deleted.

This completes the deletion process.

Note that deleted objects will still remain in active directory for some days. This time is called tombstone life time. This time is 60 days for forest that are built initially with windows 2000 or 2003 OS and for forests that are built with windows 2003 SP1 or above the tombstone lifetime is 180 days. If you want you can increase them to the value you want by modifying tombstoneLifetime  attribute of CN=Directory Service,CN=Windows NT, CN=Services,CN=Configuration, DC=yourdomain, DC=COM object from adsiedit.msc.

After the tombstone period the object will be marked for permanent deletion. There is a process called “garbage collection” which runs every 12 hours in domain controllers and the job of this process is to collect objects which has exceeded tombstone lifetime and deleting them. So a deleted object in active directory will still stay in database for days mentioned in tombstone life time plus the no. of hours left for the garbage process to trigger after tombstone expiry.

Objects CAN NOT be retrieved using any mechanism after the deletion by garbage collection process.


In my next post I will take you through the different options available in active directory restoration.

Here in this post, I am *NOT* going to talk about the protection of active directory from external/internal intruders rather I would be talking about protecting Active Directory from Accidental Delete/Move/modify operations.

Sounds weird? But you have to believe that every organization faces the problem of accidental OU/Object deletions by privileged users (I mean administrators mostly). Though it is not intentional, but the damage costs the company. And again, sysadmin is the one who has to break their heads for proper restoral of objects or need to depend on costly restoral software’s.

So, in this post, I will take you through procedures for protecting an OU from moving and deleting

HIGH-ALERT: THIS PROCEDURE IS CONTAINING DENY PERMISSIONS FOR EVERYONE TO ACTIVE DIRECTORY OBJECTS. SO THE READER/FOLLOWERS OF THE DOCUMENT SHOULD BE MUCH CAREFUL WHILE FOLLOWING THE STEPS. AND I CANNOT GUARANTEE THAT IT WORKS IN THE SAME WAY AS I DESCRIBED AND IT DEPENDS ON YOUR AD INFRASTRUCTURE. USE THIS AT YOUR OWN RISK. I AM (SITARAM PAMARTHI) NOT RESPONSIBLE FOR ANY DAMAGES CAUSED BECAUSE OF THIS POST.

Protect from Deletion.

1. Open dsa.msc(a.k.a Active Directory Users and Computers) and select the properties of Organization Unit you want to protect
2. Switch to Security Tab and click Advanced to get advanced security settings page
3. Click on ADD and type Everyone and then click OK to close the window
4. On permissions entry page, select this object only from Apply onto drop down box and select deny option (or check box) for DETELE and DELETE SUBTREE permissions
5. Click OK to come out of permissions entry page(click Yes for the warning you message you receive explaining the deny functionality) and click OK on Advanced Security page and OU properties page.
6. This completes OU protection process from Deletion

Refer to this TechNet page for details on protection and in future if you want to really delete the OU which is protected, you need to follow the Remove protection procedure which is described in same TechNet page

Protect from Moving

We can deal with AD permissions similar to Deletion operation for blocking moving, but I don’t suggest that because of complexity involved in doing it. Rather, I would just disable the drag-drop functionality in dsa.msc to achieve this. I think this should suffice the requirement of protecting from moving. If any admin really wants to move OU, he can right click and select move operations.

I don’t want to describe steps here, but I will point to this KB article which is very straight forward.

Happy Learning…,
Sitaram Pamarthi

Tags: prevent OUs from deletion, protect OU’s in active directory, prevent OUs from moving

While working with Active Directory Users and Computers, I felt pain sometimes, to see when the user is modified last, home mailbox server, User account is locked or not, and many other parameters. I need to go to user properties and check each piece of information in each tab. Sometimes, I miss to enable “advanced features” option which gives me some more details in properties. I felt it’s enough and questioned myself, “Do I need to really navigate to all tabs in User properties to get the information I want?” and asked my friend “google.com” which showed me some way out J

By default, Active Directory will not give a option for creating “Container” objects. It only allows you to create Organization units for grouping the AD objects. However, if your situation demands, you can create a container objects by following the below procedure.

• Open adsiedit.msc and navigate to schema partition
• Select Cn=Schema,CN=Configuration, DC=domain,DC=com in left plane
• In right plane, look for cn=contianer object and go to it’s properties
• Change the value of defaultHidingValue to FALSE

This will give a option for creating a container object when you right click on any OU/container and select “new” option. Container also will be listed in that list along with OU, User, computer, etc etc.

More about defaultHidingValue attribute:

A Boolean value that specifies the default setting of the showInAdvancedViewOnly property of new instances of this class. Many directory objects are not interesting to end users. To keep these objects from cluttering the UI, every object has a Boolean attribute called showInAdvancedViewOnly.

If defaultHidingValue is set to TRUE, new object instances are hidden in the Administrative snap-ins and the Windows shell. A menu item for the object class will not appear in the New context menu of the Administrative snap-ins—even if the appropriate creation wizard properties are set on the object class’s displaySpecifier object.

If defaultHidingValue is set to FALSE, new instances of the object are displayed in the Administrative snap-ins and the Windows shell. Set this property to FALSE to see instances of the class in the administrative snap-ins and the shell and enable a creation wizard and its menu item in the New menu of the administrative snap-ins.

If the defaultHidingValue value is not set, the default is TRUE.

Happy Learning..,
Sitaram Pamarthi.

[If you missed to read part-1 of this article, read it from here]

In part-2, I am going to cover the steps taken by a windows XP computer when the DC it cached goes down. As said earlier, XP caches DC name intially and supplies the DC name to applications that are requesting for it. Also netlogon process frequently checks for the availability of cached DC by doing a LDAP ping. If it finds that cached DC is down, it tries to get another available DC by using /force discovery flag(see nltest help). In this case it may go to a DC which is sitting in other AD site if no local DCs are available. But what I observed is, in some of the cases netlogon is not trying to force rediscover even if the cached DC is down. I guess it has some schedule and it is waiting for it. In this case one can restart netlogon service or use nltest /dsgetdc:domainname.com /force command to refresh the DC list. So now XP is happy that it got another available domain controller at the cost of slow access(because it is in remote site connected by wan links). But remember that XP will not switch automatically to local DC when local DC becomes online again. The netlogon refresh everytime finds the DC(remote one) it cached is available and will not try for force discovery. The XP can get local DC only if either Remote DC it connected goes down or when XP machine is rebooted.

I did some discussion on netlogon behavior in one of the forum and a guy has written to a tool to address the situation where in netlogon fails to get new DC when the cached DC goes down. You can download this tool from here.

Please refer to http://www.petri.co.il/forums/showthread.php?t=31534 for more details.

Happy learning…,

Sitaram Pamarthi

Well, before going much into the details of DCLOCATOR process, I will give brief description of what it is.

“DCLOCATOR is a process(or a procedure) which describes the steps involved in a windows XP client computer trying to identify it’s nearest domain controller”

A windows XP computer tries to identify its nearest domain controller in mainly two scenarios:

1) During it’s start-up
2) When the domain controller to which it is connected goes down

In this part-I, I am going to give details about the first scenario. I hope you already know about the requirement for a windows XP computer to locate its nearest domain controller.

If not, find them below.

o Faster authentication
o Less utilization of Wan Links
o Faster GPO processing

So, we know why XP has to get it’s nearest DC. Now lets look at the details of how it identifies nearest DC. Any computer that is booting into network will be either a new computer that is added to domain or an existing computer. The new computer needs an additional step when compared to existing computer

A new computer booting into the network will make a query to its DNS server by passing IP address (uses the DSGETSITE api). The DNS server returns the SITE name by verifying AD sites and services and subnet assigned it to. The client caches this returned information in registry. An existing computer which is booting into the network will not require this as it already cached the SITE name during its previous boot process.

After knowing the site name, client performs the below steps to identify the DC

1) Client makes below DNS query to find the SRV records of DCs which are available in the site that client belongs to. DCs will register these SRV records in DNS during their startup.

_ldap._tcp.mysite._sites.dc._msdcs.mydomain.com
where mysite is the site name of client

2) DNS returns all the DC SRV records available in enquired site to client irrespective of their DC availability.

3) Client picks up one DC randomly from list and checks for the services(authentication service) it is looking for and caches the DC name if it succeeds.

4) If client finds the picked DC as unavailable, then it picks another DC from list and caches it after checking the availability.

5) The cache will be maintained by netlogon service and it passes the cached DC name for all DC requests that it receives from applications installed on client.

NOTE: If the can not find it’s site name, it queries the DNS for all DCs using the below SRV record and picks one from the list returned by DNS. There is no guarentee that it can get the nearest DC and the pick is random. These type of clients may experience during their boot/login time.

_ldap._tcp.dc._msdcs.mydomain.com

In part-II, I will give details about how a window XP client switches to another DC when the DC it cached goes down.

Happy Learning..,
Sitaram Pamarthi

Sometimes we end up clueless while troubleshooting AD related issues. Event log doesn’t say anything and there are no error/warning messages on DC or at client side. To troubleshoot this kind of problems, increasing the Active directory diagnostic logging levels is very helpful. There are 5 levels(0-none, 1-minimal, 2-basic, 3-extensive, 4-verbose, 5-internal) of logging for each of below category and they writes the detailed events to “Directory Services” log of event viewer.

1 Knowledge Consistency Checker (KCC)
2 Security Events
3 ExDS Interface Events
4 MAPI Interface Events
5 Replication Events
6 Garbage Collection
7 Internal Configuration
8 Directory Access
9 Internal Processing
10 Performance Counters
11 Initialization/Termination
12 Service Control
13 Name Resolution
14 Backup
15 Field Engineering
16 LDAP Interface Events
17 Setup
18 Global Catalog
19 Inter-site Messaging
New to Windows Server 2003:
20 Group Caching
21 Linked-Value Replication
22 DS RPC Client
23 DS RPC Server
24 DS Schema

You can refer to http://support.microsoft.com/kb/314980 for more details on how to enable this logging.

Happy Learning..
Sitaram Pamarthi

I faced few questions in past about the maximum numbers in Active Directory. I managed to findout below and happy to share with you all.

Q1 : Maximum number of objects that can be created in active directory?
A : A little bit less than 2.15 billion.

Q2 : Maximum number of {users & computers & Groups} active directory can have?
A : ~ 1 billion.

Q3 : A user/computer/group can be member of how many groups at a time?
A : ~1,015 groups at max.

Q4 : What is the maximum length for FQDN Active Directory?
A : Should not exceed 64 characters.

Q5 : How big my OU name can be?
A : 64 characters max.

Q6 : What is the maximum no. of GPOs that can be applied to a user or a computer?
A : 999. No surprise..!! This is in place for performance reasons. But don’t relate it with no. of GPOs a Active directory system can have.

Q7 : How many accounts a LDAP transaction can hold?
A : 5000. This you can see when writing scripts. A roll back can happen if this limit is exceeded. Don’t compare it with ADODB objects 1000 limit. Both are different.

Q8 : How many objects a group can hold?
A : M$ hasn’t defined any limit yet. But few production environments proved up to 4 million objects. For windows 2000 active directory the static limit is 5000.

Q9 : Any limits on no. of domains a forest can have?
A : Yes, of course. Recommended Maximum no. of domains in a windows 2003 forest is limited to 1,200 and windows 2000 forest is 800.

Q10: How many Domain Controllers a domain can have?
A : Recommended maximum no. of DCs in a domain is limited to 1,200.

I hope this is informative. Please feel free to make any corrections and new additions.

Reference : http://technet.microsoft.com/en-us/library/cc756101.aspx

You can reach me at sitaram.pamarthi@gmail.com

Happy Learning!!
Sitaram Pamarthi

Microsoft has released revised version of Active directory domain services(a.k.a AD DS) operations guide for Windows 2008 operating system. This really has some interesting stuff for AD administrators.

Click here to download it.

Happy Learning…
Sitaram Pamarthi