DNS SRV Records, Purpose and Functionality

DNS SRV Records, Purpose and Functionality

We all know that DNS provides hostname resolution and that this service is critical to Active Directory. It allows domain controllers as well as domain members to locate services in the domain. One of those services is Client / User authentication; and as we all know – Active Directory is a distributed database, one domain controller needs to find another in order to replicate the changes it makes to its local copy of AD Database (NTDS.DIT). DNS provides specific types of records for such services; these records are called SRV or Service Resource Records. SRV records map the name of a service to the server offering this service. Clients and domain controllers use these SRV records to find the IP addresses of authenticating domain controllers and replicating partners. I don’t need to remind you that a DNS Server must allow dynamic updates to the zone where SRV records are to be created by domain controllers in a domain. DNS maintains zones and these zones allow Secure dynamic updates by default. If a DNS Server does not or is configured to NOT allow any dynamic updates, these SRV records will not be registered by domain controllers automatically. We will discuss this some other time.

Once you promote a server to a domain controller using DCPROMO, a text file containing all the appropriate records the domain controller will register in DNS gets created. This text file is in the %systemroot%\system32\config and is called NETLOGON.DNS. Whenever a domain controller starts, the NETLOGON service registers these records or refreshes these records in the primary zone held by the DNS. This way, you will always have the SRV records registered dynamically with the DNS Server. There are other means to do the same, for instance, you can stop and start the NETLOGON service manually or nltest /dsregdns etc.

So now, let’s see what these records are and their function.

  • _ldap._tcp.<DNSDomainName> – Allows a client to locate a domain controller in the domain named by <DNSDomainName>. A client searching for a domain controller in the domain contoso.com would query the DNS server for _ldap._tcp.contoso.com
  • _ldap._tcp.<SiteName>._sites.<DNSDomainName> – Allows a client to find a domain controller in the domain and site specified (e.g., _ldap._tcp.lab._sites.contoso.com for a domain controller in the Lab site of contoso.com).
  • _ldap._tcp.pdc._ms-dcs.<DNSDomainName> – Allows a client to find the PDC emulator (FSMO) role holder of a domain. Only the PDC of the domain registers this record.
  • _ldap._tcp.gc._msdcs.<DNSForestName> – Allows a client to find a Global Catalog (GC) server. Only domain controllers serving as GC servers for the forest will register this name. If a server ceases to be a GC server, the server will deregister this record.
  • _ldap._tcp. ._sites.gc._msdcs.<DNSForestName> – Allows a client to find a GC server in the specified site (e.g., _ldap._tcp.lab._sites.gc._msdcs.contoso.com).
  • _ldap._tcp.<DomainGuid>.domains._msdcs.<DNSForestName> – Allows a client to find a domain controller in a domain based on the domain controller’s globally unique ID. A GUID is a 128-bit (8 byte) number that generates automatically for referencing Active Directory objects.
  • <DNSDomainName> – Enables a client to find a domain controller through a normal Host record.

You can also use the NETLOGON.DNS file to import the records to non-Microsoft DNS Servers that support SRV records but do not allow dynamic updates. At this point we will not discuss weights, priority or port numbers for these services. Another qUICK explanation is required for that 😉

And a picture is worth a 1000 words

image001

 

SRV Records Registered by Net Logon

The list that follows provides the definitions of the names associated with registered SRV records. It also describes the lookup criteria supported by each record and the checks performed by Netlogon as each record is registered. Text in bold type denotes constant record components; text in italic type denotes variable names.

In the descriptions of registered SRV records, DnsDomainName refers to the DNS domain name that is used during creation of the domain controller when the domain tree is joined or created (that is, while the computer is running the Active Directory Installation Wizard). DnsForestName refers to the DNS domain name of the forest root domain.

The following is a list of the owner names of the SRV records that are registered by Net Logon. An owner name is the name of the DNS node to which the resource record pertains.

_ldap._tcp.DnsDomainName.
Allows a client to locate a server that is running the LDAP service in the domain named by DnsDomainName. The server is not necessarily a domain controller — that is, the only assumption that can be made about the server is that it supports the LDAP application programming interface (API). All Windows 2000 Server–based domain controllers register this SRV record (for example, _ldap._tcp.reskit.com.).
_ldap._tcp.SiteName._sites.DnsDomainName.

Allows a client to locate a server that is running the LDAP service in the domain named in DnsDomainName in the site named by SiteName. SiteName is the relative distinguished name of the site object that is stored in the Configuration container in Active Directory. The server is not necessarily a domain controller. All Windows 2000 Server–based domain controllers register this SRV record (for example, _ldap._tcp.charlotte._sites.reskit.com.).

_ldap._tcp.dc._msdcs.DnsDomainName.
Allows a client to locate a domain controller (dc) of the domain named by DnsDomainName. All Windows 2000 Server–based domain controllers register this SRV record.

_ldap._tcp.SiteName._sites.dc._msdcs.DnsDomainName.
Allows a client to locate a domain controller for the domain named by DnsDomainName and in the site named by SiteName. All Windows 2000 Server–based domain controllers register this SRV record.

_ldap._tcp.pdc._msdcs.DnsDomainName.
Allows a client to locate the server that is acting as the primary domain controller (also known as a “PDC”) in the mixed-mode domain named in DnsDomainName. Only the PDC emulator master of the domain (the Windows 2000–based domain controller that advertises itself as the primary domain controller to computers that need a primary domain controller) registers this SRV record.

_ldap._tcp.gc._msdcs.DnsForestName.
Allows a client to locate a Global Catalog (gc) server for this forest. Only domain controllers that are functioning as Global Catalog servers for the forest named in DnsForestName register this SRV record (for example, _ldap._tcp.gc._msdcs.reskit.com.).

_ldap._tcp.SiteName._sites.gc._msdcs.DnsForestName.
Allows a client to locate a Global Catalog (gc) server for this forest in the site named in SiteName. Only domain controllers that are serving as Global Catalog servers for the forest named in DnsForestName register this SRV record (for example, _ldap._tcp.charlotte._sites.gc._msdcs.reskit.com.).

_gc._tcp.DnsForestName.
Allows a client to locate a Global Catalog (gc) server for this domain. The server is not necessarily a domain controller. Only a server that is running the LDAP service and functioning as the Global Catalog server for the forest named in DnsForestName registers this SRV record (for example, _gc._tcp.reskit.com.).
Note:
In Windows 2000, a Global Catalog server is a domain controller. Other non-Windows 2000 implementations of directory services can also register servers as Global Catalog servers.

_gc._tcp.SiteName._sites.DnsForestName.
Allows a client to locate a Global Catalog (gc) server for this forest in the site named in SiteName. The server is not necessarily a domain controller. Only a server that is running the LDAP service and functioning as the Global Catalog server for the forest named in DnsForestName registers this SRV record (for example, _gc._tcp.charlotte._sites.reskit.com.).

_ldap._tcp.DomainGuid.domains._msdcs.DnsForestName.
Allows a client to locate a domain controller in a domain on the basis of its GUID. A GUID is a 128-bit number that is automatically generated for referencing objects in Active Directory — in this case, the domain object. This operation is expected to be infrequent; it occurs only when the DnsDomainName of the domain has changed, the DnsForestName is known, and DnsForestName has not also been renamed (for example, _ldap._tcp.4f904480-7c78-11cf-b057-00aa006b4f8f.domains._msdcs.reskit.com.). All domain controllers register this SRV record.

_kerberos._tcp.DnsDomainName.
Allows a client to locate a server that is running the Kerberos KDC service for the domain that is named in DnsDomainName. The server is not necessarily a domain controller. All Windows 2000 Server–based domain controllers that are running an RFC 1510–compliant Kerberos KDC service register this SRV record.

_kerberos._udp.DnsDomainName.
Same as _kerberos._tcp.DnsDomainName, except that UDP is implied.

_kerberos._tcp.SiteName._sites.DnsDomainName.
Allows a client to locate a server that is running the Kerberos KDC service for the domain that is named in DnsDomainName and is also in the site named in SiteName. The server is not necessarily a domain controller. All Windows 2000 Server–based domain controllers that are running an RFC 1510–compliant Kerberos KDC service register this SRV record.

_kerberos._tcp.dc._msdcs.DnsDomainName.
Allows a client to locate a domain controller that is running the Windows 2000 implementation of the Kerberos KDC service for the domain named in DnsDomainName. All Windows 2000 Server–based domain controllers that are running the KDC service (that is, that implement a public key extension to the Kerberos v5 protocol Authentication Service Exchange subprotocol) register this SRV record.

_kerberos.tcp.SiteName._sites.dc._msdcs.DnsDomainName.
Allows a client to locate a domain controller that is running the Windows 2000 implementation of the Kerberos KDC service for the domain that is named in DnsDomainName and that is also in the site named in SiteName. All Windows 2000 Server–based domain controllers that are running the KDC service (that is, that implement a public key extension to the Kerberos protocol Authentication Service Exchange subprotocol) register this SRV record.

_kpasswd._tcp.DnsDomainName.
Allows a client to locate a Kerberos Password Change server for the domain. All servers that provide the Kerberos Password Change service (which includes all Windows 2000–based domain controllers) register this name. This server at least conforms to “Kerberos Change Password Protocol.” (For more information about this draft, see the Microsoft Platform SDK link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. Use a keyword search to locate the draft.) The server is not necessarily a domain controller. All Windows 2000 Server–based domain controllers that are running an RFC 1510–compliant Kerberos KDC service register this SRV record.

_kpasswd._udp.DnsDomainName.
Same as _kpasswd._tcp.DnsDomainName, except that UDP is implied.
If multiple domain controllers have the same criteria, multiple records exist with the same owner name. A client that is looking for a domain controller with specific criteria would receive all the applicable records from the DNS server. The client would pick one of the returned records to select a domain controller, as described in “A DNS RR for specifying the location of services (DNS SRV).” For more information about this draft, see the Internet Engineering Task Force (IETF) link on the Web Resources page at http://windows.microsoft.com/windows2000/reskit/webresources. Follow the links to Internet Drafts, and then use a keyword search.
For information about the Kerberos v5 authentication protocol and Kerberos subprotocol extensions, see “Authentication” in this book.

Host Records for Non-SRV-Aware Clients
Net Logon registers the following DNS A records for the use of LDAP clients that do not support DNS SRV records (that is, that are “non-SRV-aware”). The Locator does not use these records.

The following owner names of A (host) records are registered by Net Logon:

DnsDomainName.
Allows a non-SRV-aware client to locate any domain controller in the domain by looking up an A record. A name in this form is returned to the LDAP client through an LDAP referral. (For more information about LDAP referrals, see “LDAP Referrals” later in this chapter.) A non-SRV-aware client looks up the name; an SRV-aware client looks up the appropriate SRV resource record.

gc._msdcs.DnsForestName.
Allows a non-SRV-aware client to locate any Global Catalog server in the forest by looking up an A record. A name in this form is returned to the LDAP client through an LDAP referral. A non-SRV-aware client looks up this name; an SRV-aware client looks up the appropriate SRV resource record.
Netlogon also registers a DNS CNAME (alias) record for use by Active Directory replication. The Locator does not use this record.

The owner name of the CNAME record is:
DsaGuid._msdcs.DnsForestName.
Allows a client to locate any domain controller in the forest by looking up an A record. The only information that is known about the domain controller is the GUID of the directory system agent (also known as the “DSA”) object for the domain controller and the name of the forest in which the domain controller is located. This record is used to facilitate renaming a domain controller.

Other SRV Record Content

The following information is also included in an SRV record:
Priority   The priority of the server. Clients attempt to contact the server with the lowest priority.
Weight   A load-balancing mechanism that is used when selecting a target host from those that have the same priority. Clients randomly choose SRV records that specify target hosts to be contacted, with probability proportional to the weight.

Port Number
The port where the server is listening for this service.

Target
The fully qualified domain name of the host computer.

The following example illustrates the combined information that is contained in A resource records and SRV resource records. A domain controller named Phoenix in the domain reskit.com has an IP address of 157.55.81.157. It registers the following A records and SRV records with DNS:
phoenix.reskit.com   A   157.55.81.157
_ldap._tcp.reskit.com    SRV  0 0 389 phoenix.reskit.com
_kerberos._tcp.reskit.com   SRV  0 0 88 phoenix.reskit.com
_ldap._tcp.dc._msdcs.reskit.com  SRV  0 0 389 phoenix.reskit.com
_kerberos._tcp.dc._msdcs.reskit.com  SRV  0 0 88 phoenix.reskit.com.

When the appropriate SRV records and A records are in place, a DNS lookup of _ldap._tcp.dc._msdcs.reskit.com returns the names and addresses of all domain controllers in the domain.
For more information about A records, SRV records, DNS, and dynamic updates, see “Introduction to DNS” and “Windows 2000 DNS” in the TCP/IP Core Networking Guide.

If the DCs are in a truly configured “Site”, then to change the priority and weights, you must change the registry entries under the Netlogon key. Once changed, then it will register that info into DNS.

 

 

Advertisements

DNS

DNS: The Domain Name System consists of a hierarchical set of DNS servers. Each domain or subdomain has one or more authoritative DNS servers that publish information about that domain and the nameservers of any domains “beneath” it. The hierarchy of authoritative DNS servers matches the hierarchy of domains. At the top of the hierarchy stand the root nameservers: the servers to query when looking up (resolving) a top-level domain name (TLD). Iterative and recursive queries:

  • An iterative query is one where the DNS server may provide a partial answer to the query (or give an error). DNS servers must support non-recursive queries.
  • A recursive query is one where the DNS server will fully answer the query (or give an error). DNS servers are not required to support recursive queries and both the resolver (or another DNS acting recursively on behalf of another resolver) negotiate use of recursive service using bits in the query headers.

DNS Propagation

DNS Propagation refers to the time for any DNS changes to transmit across the Internet. Please remember that DNS changes in general can take up to 24-48 hours to fully propagate.

DNS Records

CNAME or “Canonical Name”

(CNAME) Record is used to define an alias hostname. A “CNAME” record takes this format:

alias.domain.name      IN     CNAME   otherhost.domain.name.

This defines alias.domain.name as an alias for the host whose canonical (standard) name is otherhost.domain.name.

“A” Record

An A record gives you the IP address of a domain. That way, users that try to go to www.example.com will get to the right IP address. An A record or “Address Record” maps a hostname to a 32-bit IPv4 address. An “A” Record takes this format (example):

Name             TTL     TYPE    DATA

ftp.domain.com   43200   A       IP Address

(mt) Media Temple DNS Zone files are written with a “wildcard” entry, that looks like this:

*.domain.com   IN   A   xxx.xxx.xxx.xxx

The x’s represnt your particular IP address. The star takes “anything” .domain.com and points it to your server’s IP address. This way, if someone mistakenly types too many or too few w’s, they’ll still see your website. This is also useful for setting up subdomains on your server, relieving you of the duty of adding an additional “A” record for the subdomain.

MX Record

Mail Exchange Record: Maps a domain name to a list of mail exchange servers for that domain. A zone can have one or more Mail Exchange (MX) records. These records point to hosts that accept mail messages on behalf of the host. A host can be an ‘MX’ for itself. MX records need not point to a host in the same zone. An ‘MX’ record takes this format:

host.domain.name       IN     MX      10 otherhost.domain.name.

IN     MX      20 otherhost2.domain.name.

The ‘MX’ preference numbers nn (value 0 to 65535) signify the order in which mailers select ‘MX’ records when they attempt mail delivery to the host. The lower the ‘MX’ number, the higher the host is in priority.

PTR Record / Pointer Record

Maps an IPv4 address to the canonical name for that host. Setting up a PTR record for a hostname in the in-addr.arpa. domain that corresponds to an IP address implements reverse DNS lookup for that address. For example, at the time of writing, www.icann.net has the IP address 192.0.34.164, but a PTR record maps 164.34.0.192.in-addr.arpa to its canonical name.

NS Record or “Name Server Record”

Maps a domain name to a list of DNS servers authoritative for that domain. In this case, for (mt) Media Temple purposes would be:

ns1.mediatemple.net

ns2.mediatemple.net

SOA Record or “Start of Authority Record”

Specifies the DNS server providing authoritative information about an Internet domain, the email of the domain administrator, the domain serial number, and several timers relating to refreshing the zone.

TXT Record

The TXT Record allows an administrator to insert arbitrary text into a DNS record. For example, this record is used to implement the Sender Policy Framework and DomainKeys specifications.

Configuring advanced settings of DNS server

The Advanced page of a DNS server’s property sheet allows you to set several advanced options that control the way the server functions. To configure the following settings, open the DNS console, right-click the server, choose Properties, and click the Advanced tab:

1) Disable Recursion: Select this option to prevent the server from performing recursive queries. With this option selected the server replies with referrals instead of recursively querying until a resolution is reached.

2) BIND Secondaries: To optimize zone transfer speed, Windows Server 2008 DNS servers (by default) use compression and submit multiple resource records in a single TCP message whenever performing zone transfers. This method is compatible with servers running BIND (Berkeley Internet Name Domain) version 4.9.4 and later, but is incompatible with earlier versions of BIND. To optimize performance, leave this option deselected if your server is not going to be performing zone transfers with these earlier systems. Select this option to have the Windows Server 2008 DNS server to perform slower, uncompressed zone transfers to ensure compatibility with these older systems.

3) Fail on Load if Bad Zone Data: The Windows Server 2008 DNS service, by default, continues to load a zone even when it detects errors in the zone data, logging the errors but not failing. Select this option if you want the DNS service to stop loading the zone when the zone data contains errors.

4) Enable Round Robin: The Windows Server 2008 DNS service, by default, rotates and re-orders a list of host records if a given host name is related with multiple IP addresses. This round-robin behavior permits an administrator to perform load balancing, directing traffic to multiple computers with the same host name but different IP addresses (such as multiple servers hosting www.mcity.us). With this option selected, the server responds to queries with each address in turn. Deselect this option if you want to disable round-robin and have the server return the first match in the zone.

5) Enable Netmask Ordering: If a given zone includes multiple host records that map the same host name to multiple IP addresses, the Windows Server 2008 DNS service can order the response list according to the IP address of the client. Windows Server 2008 DNS checks the IP address of the client against the addresses of the host records and if a record falls in the client’s subnet, the DNS service places that host record first in the list. This directs the client to the requested host that is closest and typically fastest for the client to access, which is very important for Active Directory services. This option is selected by default. Deselect this option to prevent the DNS service from reordering responses based on subnet. Netmask ordering succeeds round-robin ordering, although round-robin is used for secondary sorting if enabled, and it is useful where subnets are in different geographical locations.

6) Secure Cache Against Pollution: The Windows 2003 DNS service does not add unrelated resource records added in a referral from another DNS server to the Windows Server 2008 server’s cache. It caches referrals which may not match the queried host name, however, such as caching a referral for www.sillycity.com if querying for www.mcity.us. Selecting this option prevents the DNS service from caching nonrelated referrals.

7) Name Checking: Internet host names were originally limited to alphanumeric characters and hyphens. Although this limitation was maintained after DNS was developed, it caused a problem in some situations, particularly for supporting international character sets. This option controls how the DNS service performs name checking. By default, Windows Server 2008 uses the UTF8 (Unicode Transformation Format) character set, which gives the broadest and least restrictive character set support. Select Strict if you need to limit names to the standard format. Use Non-RFC to permit names that do not follow the RFC 1123 specification. Use Multi-byte to recognize characters other than ASCII, including Unicode.

8) Load Zone Data on Startup: By default, the Windows Server 2008 DNS service loads zone data from the Active Directory (for AD-integrated zones) and from the registry. You can configure the server to load only from the registry or from a BIND 4 boot file. This latter option allows you to essentially duplicate a BIND server under Windows Server 2008, importing all the zone data. Notice that the boot file—typically called Named.boot—must use the BIND 4 format, rather than the newer BIND 8 format.

9) Enable Automatic Scavenging of Stale Records: Stale records typically are those that point to hosts no longer on the network. Accumulation of old records can lead to decreased storage space, degradation of server performance, incorrect name-to-address resolution, and no capability for a host to have the DNS service create its resource record (through Dynamic DNS). Scavenging, which is turned off by default, enables the DNS server to use timestamps and other properties to determine when a resource record is stale and automatically remove it from the zone. Records added automatically through DDNS are subject to scavenging, as is any record manually added with a timestamp that you have modified from its default of zero. Resource records with a time stamp of zero are not subject to scavenging. Select this option and configure the related scavenging period. Notice that scavenging must be enabled for individual zones in their properties as well.

10) Reset to Default: Select this option to reconfigure all advanced settings to their defaults.

User Logon Process

  1. When a user attempts to log on, the KDC on the DC that authenticate the user‘s logon must provide the SIDs for each domain-based group that the user is a member of. These SIDs and the SIDs for local groups that the user is a member of, are used to authenticate the user and provide access to resources.
  2. The Global catalog contains different information different type of groups, when the domain functional lever is Windows 2000 native or later, members in universal group can be accounts or groups from any domain.
  3. Universal group also provide access to resources in any domain. A global catalog contains the entire group membership list for universal groups. Members in universal group can only be accounts or groups from any domain. However, domain local group can only provide access to resources in the domain in which the group is created. The global catalog does not contain the entire membership list for domain local groups. Because in a universal group, the membership and resources are not necessarily from the user’s logon domain, and the membership stored in the global catalog. The global catalog must be available to ensure that the universal groups that the user is member of are included in the user’s list of SIDs.
  4. When the global catalog is available, the authentication and authorization process proceeds like this,
  5. The user enters the credentials at a workstation to logon. The credentials are encrypted by client and sent to DC for the client’s domain.
  6. The encrypted credentials that the clients send s are matched with the encrypted credentials on the DC. The KDC stores the encrypted user credentials.
  7. If the credentials from the client match the credentials that are stored by the KDC, the process continues.
  8. Then the DC creates a list of the domain-based groups that the user belongs to. The DC then queries the Global catalog to identify the universal groups that the user belongs to.
  9. After this,
  10. The KDC issues the client TGT. The TGT contains the encrypted SIDs for the groups that the user is member of. The user is now authenticated and can request access to resources. The client access to a resource, which resides on the specific server.
  11. The client uses the TGT to access TGS on the DC. The TGS issues a session ticket to the client for the server on which the resource resides. The session ticket contains the SIDs for the user’s group memberships. The client presents the session ticket to the server. The LSA on the server uses the information in the session ticket to create an access token.
  12. The LSA compares the SIDs in the access token with the groups that are assigned permissions in the resources DACL. If they match, the user is granted access to resource.
  13. When a global catalog server is not available, the KDC cannot obtain SIDs of the universal groups of which the user is member. In such cases, the KDC does not issue a TGT for the user, because the unavailable universal groups may be named in an explicit deny permission in a resource’s DACL.
  14. If the KDC issued a TGT that did not include universal group membership for the user, it might compromise security.
  15. The GLOBAL catalog must be available for the user to obtain TGT. TGTs are valid for 8 hours by default. After a session ticket is granted, a user can use it until he logs off or the session ticket expires. This is true even if the global catalog becomes unavailable during that time. When the global catalog is not available, the user’s universal group membership cannot be enumerated and the user cannot login. However if no DCs are available, the user can log on to a workstation if the user’s credentials are cached on that computer. Universal group membership caching is available on DCs running Windows Server 2003. You can configure universal group membership caching for a site, and enable DCs within that site to service logon requests for repeat users that are in the same site.
  16. When a user logs on at a remote site without a global catalog, universal group membership is cached as follows: The first the user logs on to the local site, the DC contacts the global catalog on the WAN.
  17. The global catalog returns the user’s universal group membership, which is cached on the domain controller. During the subsequent logons, the DC resolves the universal group membership at the local site by using cached information, which is refreshed every 8 hours by default. The benefits of enabling universal group membership caching at a remote site without a global catalog server include:
  18. Authentication is not dependent on a WAN link to global catalog, authentication traffic for repeat users does not use a WAN, the local resolution of universal group membership improves logon times, because there is no global catalog at a remote site, the WAN link does not need to replicate the entire global catalog.

To Disable Computer account

To Disable Computer account:

dsmod computer “CN=BR10-08GGR48,OU=Workstations,OU=BCD,OU=Organizations,DC=domain,DC=com” -disabled yes

To Move Disabled computer account:

dsmove “CN=BR10-08GGR48,OU=Workstations,OU=BCD,OU=Organizations,DC=domain,DC=com” -newparent “OU=Waste Basket,OU=GC,OU=Organizations,DC=domain,DC=com”

To remove the computer account :

dsrm “CN=BR10-08F5R35,OU=Workstations,OU=BCD,OU=Organizations,DC=domain,DC=com” –noprompt -subtree

Active Directory Recycle Bin in Windows Server 2012

  1. Go AD administrative center  right click the domain Enable Recycle Bin

e

To Enable Recycle bin your Forest and domain fuctional level should be Windows 2008R2

2.Once you enabled recycle bin you cannot disable the feature.

2

3.Replication needs to happen all the domain controllers

3

4. You can see one more container as Deleted objects in the AD Administrative center

4

5.Now delete a user object

5

6. You can view the deleted object in the deleted objects folder and when it’s deleted, OU path.

d

If you right click the object you will get the option to restore it back to original location or restore to new location

7. If you click the deleted user properties you can see the deleted view with GUID

6

8. You can add criteria to search the deleted objects container.

7

If you deleted entire OU you can see the below view in deleted objects container

c

If you click the restore from user object you will get the below error since the parent OU is not available.

8

You can restore to different OU by selecting restore to option

9

9. In 2008R2 you have to use ldp.exe to view the deleted objects container

Connection->connect your domainàbindàDC=domain,DC=com

Options-> controls-> Loadpredefined-> Return deletedobjects

12

10.View->Treeà Deleted objects folder and all deleted objects

a

  • · Locate and right-click the deleted Active Directory object that you want to restore, and then click Modify.
  • · In the Modify dialog box:
  1. In Edit Entry Attribute, type isDeleted.
  2. Leave the Values box empty.
  3. Under Operation, click Delete, and then click Enter.
  4. In Edit Entry Attribute, type distinguishedName.
  5. In Values, type the original distinguished name (also known as DN) of this Active Directory object.
  6. Under Operation, click Replace.
  7. Make sure that the Extended check box is selected, click Enter, and then click Run.

b

Active Directory References to Learn and Grow..!!!!!

Active Directory:
My TechNet WIKI :Biswajit Biswas
A Guide to Active Directory Replication: Must Read

BLOGS:

Rich Peckham’s Technical Blog

http://blogs.msdn.com/b/richpec/archive/2011/10/07/the-authoritative-restore-explained.aspx

joeware – never stop exploring… : http://blog.joeware.net/

Ask the Directory Services Team: http://blogs.technet.com/b/askds/

jorgequestforknowledge : http://jorgequestforknowledge.wordpress.com/

The things that are better left unspoken : http://blogs.dirteam.com/blogs/sanderberkouwer/default.aspx

Florian’s Blog : http://www.frickelsoft.net/blog/

Santhosh Sivarajan’s Blog : http://portal.sivarajan.com/

Paul Bergson (MVP – Directory Services): http://blogs.dirteam.com/blogs/paulbergson/default.aspx

AD and Exchange Quantum Singularity  : http://msmvps.com/blogs/acefekay/default.aspx

Open a Socket!  http://www.open-a-socket.com/

Directory Services/Active Directory Ulf B. Simon-Weidner’s Blog : http://msmvps.com/blogs/ulfbsimonweidner/default.aspx

Exchange Team Blog http://blogs.technet.com/b/exchange/

Tomek’s DS World http://blogs.dirteam.com/blogs/tomek/default.aspx

http://blogs.dirteam.com/blogs/carlos/default.aspx

ADisfun: http://adisfun.blogspot.ch/

http://briandesmond.com/blog/

AD Shot Gyan  http://www.adshotgyan.com/

MWeber’s Blog: http://msmvps.com/blogs/mweber/default.aspx

Michael’s meanderings… : http://theessentialexchange.com/blogs/michael/default.aspx

Matt Hester’s WebLog : http://blogs.technet.com/b/matthewms/

Ask the Core Team : http://blogs.technet.com/b/askcore/

Ask the Performance Team Blog http://blogs.technet.com/b/askperf/

Awinish’s Technical Blog : http://awinish.wordpress.com/

Sandesh Dubey Blog: http://sandeshdubey.wordpress.com/

http://eprajesh.wordpress.com/

http://cbfive.com/blog/

http://blogs.technet.com/b/omers/

http://blogs.msdn.com/b/muaddib/

Powershell:

http://rkeithhill.wordpress.com/

http://www.amandhally.net/

http://dmitrysotnikov.wordpress.com/

http://blogs.technet.com/b/heyscriptingguy/

http://technet.microsoft.com/en-us/scriptcenter

http://powershell.com/cs/blogs/hey-scriptingguy/default.aspx

http://blogs.msdn.com/b/adpowershell/

Group Policy:

http://blogs.technet.com/b/grouppolicy/

http://www.grouppolicy.biz/

http://www.gpanswers.com/blog.html

http://www.gpoguy.com/