How to remove data in Active Directory after an unsuccessful domain controller demotion

This article describes how to remove data in Active Directory after an unsuccessful domain controller demotion.

Warning If you use the ADSI Edit snap-in, the LDP utility, or any other LDAP version 3 client, and you incorrectly modify the attributes of Active Directory objects, you can cause serious problems. These problems may require you to reinstall Microsoft Windows 2000 Server, Microsoft Windows Server 2003, Microsoft Exchange 2000 Server, Microsoft Exchange Server 2003, or both Windows and Exchange. Microsoft cannot guarantee that problems that occur if you incorrectly modify Active Directory object attributes can be solved. Modify these attributes at your own risk.

The Active Directory Installation Wizard (Dcpromo.exe) is used for promoting a server to a domain controller and for demoting a domain controller to a member server (or to a stand-alone server in a workgroup if the domain controller is the last in the domain). As part of the demotion process, the wizard removes the configuration data for the domain controller from Active Directory. This data takes the form of an NTDS Settings object that exists as a child of the server object in Active Directory Sites and Services.

The information is in the following location in Active Directory:

CN=NTDS Settings,CN=<servername>,CN=Servers,CN=<sitename>,CN=Sites,CN=Configuration,DC=<domain>...

The attributes of the NTDS Settings object include data representing how the domain controller is identified in respect to its replication partners, the naming contexts that are maintained on the machine, whether the domain controller is a global catalog server, and the default query policy. The NTDS Settings object is also a container that may have child objects that represent the domain controller's direct replication partners. This data is required for the domain controller to operate in the environment, but is retired upon demotion.

If the NTDS Settings object is removed incorrectly (for example, if the NTDS Settings object is removed incorrectly from a demotion attempt), the administrator can manually remove the metadata for a server object. In Windows Server 2008, and Windows Server 2008 R2, the administrator can remove the metadata for a server object by removing the server object in the Active Directory Users and Computers snap-in.

In Windows Server 2003 and Windows 2000 Server, the administrator can use the Ntdsutil.exe utility to manually remove the NTDS Settings object. The following steps list the procedure for removing the NTDS Settings object in Active Directory for a particular domain controller. At each Ntdsutil menu, the administrator can type help for more information about the available options.

Windows Server 2003 Service Pack 1 (SP1) or later service packs – Enhanced version of Ntdsutil.exe

The version of Ntdsutil.exe that is included with Service Pack 1 or later service packs for Windows Server 2003 has been enhanced to make the metadata cleanup process complete. The Ntdsutil.exe version that is included with SP1 or later service packs does the following when metadata cleanup is run:

• Removes the NTDSA or NTDS Setting subject.
• Removes inbound AD connection objects that existing destination DCs use to replicate from the source DC being deleted .
• Removes the computer account .
• Removes FRS member object.
• Removes FRS subscriber objects.
• Tries to seize flexible single operations master roles (also known as flexible single master operations or FSMO) held by the DC that are being removed .

Caution The administrator must also make sure that replication has occurred since the demotion before manually removing the NTDS Settings object for any server. Using the Ntdsutil utility incorrectly may result in partial or complete loss of Active Directory functionality.

Procedure 1: Windows Server 2003 SP1 or later service packs only

1. Click Start, point to Programs, point to Accessories, and then click Command Prompt.
2. At the command prompt, type ntdsutil, and then press ENTER.
3. Type metadata cleanup, and then press ENTER. Based on the options given, the administrator can perform the removal, but additional configuration parameters must be specified before the removal can occur.
4. Type connections and press ENTER. This menu is used to connect to the specific server where the changes occur. If the currently logged on user does not have administrative permissions, different credentials can be supplied by specifying the credentials to use before making the connection. To do this, type set creds DomainNameUserNamePassword, and then press ENTER. For a null password, type null for the password parameter.
5. Type connect to server servername, and then press ENTER. You should receive confirmation that the connection is successfully established. If an error occurs, verify that the domain controller being used in the connection is available and the credentials you supplied have administrative permissions on the server.
   
   Note If you try to connect to the same server that you want to delete, when you try to delete the server that step 15 refers to, you may receive the following error message:
   Error 2094. The DSA Object cannot be deleted0x2094
6. Type quit, and then press ENTER. The Metadata Cleanup menu appears.
7. Type select operation target and press ENTER.
8. Type list domains and press ENTER. A list of domains in the forest is displayed, each with an associated number.
9. Type select domain number and press ENTER, where number is the number associated with the domain the server you are removing is a member of. The domain you select is used to determine whether the server being removed is the last domain controller of that domain.
10. Type list sites and press ENTER. A list of sites, each with an associated number, appears.
11. Type select site number and press ENTER, where number is the number associated with the site the server you are removing is a member of. You should receive a confirmation listing the site and domain you chose.
12. Type list servers in site and press ENTER. A list of servers in the site, each with an associated number, is displayed.
13. Type select server number, where number is the number associated with the server you want to remove. You receive a confirmation listing the selected server, its Domain Name System (DNS) host name, and the location of the server's computer account you want to remove.
14. Type quit and press ENTER. The Metadata Cleanup menu appears.
15. Type remove selected server and press ENTER. You should receive confirmation that the removal completed successfully. If you receive the following error message, the NTDS Settings object may already be removed from Active Directory as the result of another administrator removing the NTDS Settings object or replication of the successful removal of the object after running the DCPROMO utility.
    Error 8419 (0x20E3)
    The DSA object could not be found
    
    
    Note You may also see this error when you try to bind to the domain controller that will be removed. Ntdsutil has to bind to a domain controller other than the one that will be removed with metadata cleanup.
16. Type quit, and then press ENTER at each menu quit the Ntdsutil utility. You should receive confirmation that the connection disconnected successfully.
17. Remove the cname record in the _msdcs.root domain of forest zone in DNS. Assuming that DC will be reinstalled and re-promoted, a new NTDS Settings object is created with a new GUID and a matching cname record in DNS. You do not want the DCs that exist to use the old cname record.
    
    As best practice, you should delete the host name and other DNS records. If the lease time that remains on Dynamic Host Configuration Protocol (DHCP) address assigned to offline server is exceeded then another client can obtain the IP address of the problem DC.
18. In the DNS console, use the DNS MMC to delete the A record in DNS. The A record is also known as the Host record. To delete the A record, right-click the A record, and then click Delete. Also, delete the cname record in the _msdcs container. To do this, expand the _msdcs container, right-click cname, and then click Delete.
    
    Important If this is a DNS server, remove the reference to this DC under the Name Servers tab. To do this, in the DNS console, click the domain name under Forward Lookup Zones, and then remove this server from the Name Servers tab.
    
    Note If you have reverse lookup zones, also remove the server from these zones.
19. If the deleted computer is the last domain controller in a child domain, and the child domain was also deleted, use ADSIEdit to delete the trustDomain object for the child. To do this, follow these steps:
    1. Click Start, click Run, type adsiedit.msc, and then click OK
    2. Expand the Domain NC container.
    3. Expand DC=Your Domain, DC=COM, PRI, LOCAL, NET.
    4. Expand CN=System.
    5. Right-click the Trust Domain object, and then click Delete.
20. Use Active Directory Sites and Services to remove the domain controller. To do this, follow these steps:
    1. Start Active Directory Sites and Services.
    2. Expand Sites.
    3. Expand the server's site. The default site is Default-First-Site-Name.
    4. Expand Server.
    5. Right-click the domain controller, and then click Delete.
21. When you use DFS Replication in Windows Server 2008 and in later versions, the current version of Ntdsutil.exe does not clean up the DFS Replication object. In this case, you can use Adsiedit.msc to correct the DFS Replication objects for Active Directory Domain Services (AD DS) manually. To do this, follow these steps:
    1. Logon a domain controller as a domain administrator in the affected domain.
    2. Start Adsiedit.msc.
    3. Connect to the default naming context.
    4. Locate the following DFS Replication topology container:
       CN=Topology,CN=Domain System Volume,CN=DFSR-Globalsettings,CN=System,DC=Your Domain,DC=Domain Suffix
    5. Delete the msDFSR-Member CN object that has the old computer name.

Procedure 2: Windows 2000 (All versions) Windows Server 2003 RTM

1. Click Start, point to Programs, point to Accessories, and then click Command Prompt.
2. At the command prompt, type ntdsutil, and then press ENTER.
3. Type metadata cleanup, and then press ENTER. Based on the options given, the administrator can perform the removal, but additional configuration parameters must be specified before the removal can occur.
4. Type connections and press ENTER. This menu is used to connect to the specific server where the changes occur. If the currently logged on user does not have administrative permissions, different credentials can be supplied by specifying the credentials to use before you make the connection. To do this, type set creds DomainNameUserNamePassword, and then press ENTER. For a null password, type null for the password parameter.
5. Type connect to server servername, and then press ENTER. You should receive confirmation that the connection is successfully established. If an error occurs, verify that the domain controller being used in the connection is available and the credentials you supplied have administrative permissions on the server.
   
   Note If you try to connect to the same server that you want to delete, when you try to delete the server that step 15 refers to, you may receive the following error message:
   Error 2094. The DSA Object cannot be deleted0x2094
6. Type quit, and then press ENTER. The Metadata Cleanup menu appears.
7. Type select operation target and press ENTER.
8. Type list domains and press ENTER. A list of domains in the forest is displayed, each with an associated number.
9. Type select domain number and press ENTER, where number is the number associated with the domain the server you are removing is a member of. The domain you select is used to determine whether the server being removed is the last domain controller of that domain.
10. Type list sites and press ENTER. A list of sites, each with an associated number, is displayed.
11. Type select site number and press ENTER, where number is the number associated with the site the server you are removing is a member of. You should receive a confirmation listing the site and domain you chose.
12. Type list servers in site and press ENTER. A list of servers in the site, each with an associated number, is displayed.
13. Type select server number, where number is the number associated with the server you want to remove. You receive a confirmation listing the selected server, its Domain Name System (DNS) host name, and the location of the server's computer account you want to remove.
14. Type quit and press ENTER. The Metadata Cleanup menu appears.
15. Type remove selected server and press ENTER. You should receive confirmation that the removal completed successfully. If you receive the following error message:
    Error 8419 (0x20E3)
    The DSA object could not be found
    the NTDS Settings object may already be removed from Active Directory as the result of another administrator removing the NTDS Settings object, or replication of the successful removal of the object after you run the Dcpromo utility.
    
    Note You may also see this error when you try to bind to the domain controller that will be removed. Ntdsutil has to bind to a domain controller other than the one that will be removed with metadata cleanup.
16. Type quit at each menu to quit the Ntdsutil utility. You should receive confirmation that the connection disconnected successfully.
17. Remove the cname record in the _msdcs.root domain of forest zone in DNS. Assuming that DC will be reinstalled and re-promoted, a new NTDS Settings object is created by using a new GUID and a matching cname record in DNS. You do not want the DC's that exist to use the old cname record.
    
    As best practice you should delete the hostname and other DNS records. If the lease time that remains on Dynamic Host Configuration Protocol (DHCP) address assigned to offline server is exceeded then another client can obtain the IP address of the problem DC.

Now that the NTDS Settings object has been deleted, you can delete the computer account, the FRS member object, the cname (or Alias) record in the _msdcs container, the A (or Host) record in DNS, the trustDomain object for a deleted child domain, and the domain controller.

Note You do not need to manually remove the FRS member object in Windows Server 2003 RTM because the Ntdsutil.exe utility has already removed the FRS member object when you run the utility. Additionaly, the metadata of the computer account cannot be removed if the computer account of the DC contains another leaf object. For example, Remote Installation Services (RIS) might be installed on the DC.

The Adsiedit utility is included with the Windows Support Tools feature in both Windows 2000 Server and Windows Server 2003. To install the Windows Support Tools, following these steps:

• Windows 2000 Server: On the Windows 2000 Server CD, open the Support\Tools folder, double-click Setup.exe, and then follow the instructions that appear on the screen.
• Windows Server 2003: On the Windows Server 2003 CD, open the Support\Tools folder, double-click Suptools.msi, click Install, and then follow the steps in the Windows Support Tools Setup Wizard to complete the installation.

1. Use ADSIEdit to delete the computer account. To do this, follow these steps:
   1. Click Start, click Run, type adsiedit.msc in the Open box, and then click OK.
   2. Expand the Domain NC container.
   3. Expand DC=Your Domain Name, DC=COM, PRI, LOCAL, NET.
   4. Expand OU=Domain Controllers.
   5. Right-click CN=domain controller name, and then click Delete.
   If you receive the "DSA object cannot be deleted" error message when you try to delete the object, change the UserAccountControl value. To change the UserAccountControl value, right-click the domain controller in ADSIEdit, and then click Properties. Under Select a property to view, click UserAccountControl. Click Clear, change the value to 4096, and then click Set. You can now delete the object.
   
   Note The FRS subscriber object is deleted when the computer object is deleted because it is a child of the computer account.
2. Use ADSIEdit to delete the FRS member object. To do this, follow these steps:
   1. Click Start, click Run, type adsiedit.msc in the Open box, and then click OK
   2. Expand the Domain NC container.
   3. Expand DC=Your Domain, DC=COM, PRI, LOCAL, NET.
   4. Expand CN=System.
   5. Expand CN=File Replication Service.
   6. Expand CN=Domain System Volume (SYSVOL share).
   7. Right-click the domain controller you are removing, and then click Delete.
3. In the DNS console, use the DNS MMC to delete the A record in DNS. The A record is also known as the Host record. To delete the A record, right-click the A record, and then click Delete. Also delete the cname (also known as the Alias) record in the _msdcs container. To do so, expand the _msdcs container, right-click the cname, and then click Delete.
   
   Important If this was a DNS server, remove the reference to this DC under the Name Servers tab. To do this, in the DNS console, right-click the domain name under Forward Lookup Zones, click Properties, and then remove this server from the Name Servers tab.
   
   Note If you have reverse lookup zones, also remove the server from these zones.
4. If the deleted computer was the last domain controller in a child domain and the child domain was also deleted, use ADSIEdit to delete the trustDomain object for the child. To do this, follow these steps:
   1. Click Start, click Run, type adsiedit.msc in the Open box, and then click OK
   2. Expand the Domain NC container.
   3. Expand DC=Your Domain, DC=COM, PRI, LOCAL, NET.
   4. Expand CN=System.
   5. Right-click the Trust Domain object, and then click Delete.
5. Use Active Directory Sites and Services to remove the domain controller. To do this, follow these steps:
   1. Start Active Directory Sites and Services.
   2. Expand Sites.
   3. Expand the server's site. The default site is Default-First-Site-Name.
   4. Expand Server.
   5. Right-click the domain controller, and then click Delete.

Advanced optional syntax with the SP1 or later versions of Ntdsutil.exe

Windows Server 2003 SP1 introduced a new syntax that can be used. By using the new syntax, it is no longer required to bind to the DS and select your operation target. To use the new syntax, you must know or obtain the DN of the NTDS settings object of the server that is being demoted. To use the new syntax for metadata cleanup, follow these steps:

1. Run ntdsutil.
2. Switch to the metadata cleanup prompt.
3. Run the following command
   remove selected server <DN of the server object in the config container>
   An example of this command is as follows.
   
   Note The following is one line but has been wrapped.
   
   Remove selected server cn=servername,cn=servers,cn=sitename,cn=sites,cn=configuration,dc=<forest_root_domain>
4. Remove the cname record in the _msdcs.root domain of forest zone in DNS. Assuming that DC will be reinstalled and re-promoted, a new NTDS Settings object is created by using a new GUID and a matching cname record in DNS. You do not want the DCs that exist to use the old cname record.
   
   As best practice, you should delete the host name and other DNS records. If the lease time that remains on Dynamic Host Configuration Protocol (DHCP) address assigned to offline server is exceeded, another client can obtain the IP address of the problem DC.
5. If the deleted computer was the last domain controller in a child domain, and the child domain was also deleted, use ADSIEdit to delete the trustDomain object for the child. To do this, follow these steps:
   1. Click Start, click Run, type adsiedit.msc, and then click OK.
   2. Expand the Domain NC container.
   3. Expand DC=Your Domain Name, DC=COM, PRI, LOCAL, NET.
   4. Expand CN=System.
   5. Right-click the Trust Domain object,, and then click Delete.
6. Use Active Directory Sites and Services to remove the domain controller. To do this, follow these steps:
   1. Start Active Directory Sites and Services.
   2. Expand Sites.
   3. Expand the server's site. The default site is Default-First-Site-Name.
   4. Expand Server.
   5. Right-click the domain controller, and then click Delete.
   
   Original Post:

Delete Failed DCs from Active Directory

When you try to remove a domain controller from your Active Directory domain by using Dcpromo.exe and fail, or when you began to promote a member server to be a Domain Controller and failed (the reasons for your failure are not important for the scope of this article), you will be left with remains of the DCs object in the Active Directory. As part of a successful demotion process, the Dcpromo wizard removes the configuration data for the domain controller from Active Directory, but as noted above, a failed Dcpromo attempt might leave these objects in place.
The effects of leaving such remains inside the Active Directory may vary, but one thing is sure: Whenever you'll try to re-install the server with the same computername and try to promote it to become a Domain Controller, you will fail because the Dcpromo process will still find the old object and therefore will refuse to re-create the objects for the new-old server.
In the event that the NTDS Settings object is not removed correctly you can use the Ntdsutil.exe utility to manually remove the NTDS Settings object.
If you give the new domain controller the same name as the failed computer, then you need perform only the first procedure to clean up metadata, which removes the NTDS Settings object of the failed domain controller. If you will give the new domain controller a different name, then you need to perform all three procedures: clean up metadata, remove the failed server object from the site, and remove the computer object from the domain controllers container.
You will need the following tool: Ntdsutil.exe, Active Directory Sites and Services, Active Directory Users and Computers.
Also, make sure that you use an account that is a member of the Enterprise Admins universal group.
Caution: Using the Ntdsutil utility incorrectly may result in partial or complete loss of Active Directory functionality.
To clean up metadata

1. At the command line, type Ntdsutil and press ENTER.

C:\WINDOWS>ntdsutil
ntdsutil:

1. At the Ntdsutil: prompt, type metadata cleanup and press Enter.

ntdsutil: metadata cleanup
metadata cleanup:

1. At the metadata cleanup: prompt, type connections and press Enter.

metadata cleanup: connections
server connections:

1. At the server connections: prompt, type connect to server <servername>, where <servername> is the domain controller (any functional domain controller in the same domain) from which you plan to clean up the metadata of the failed domain controller. Press Enter.

server connections: connect to server server100
Binding to server100 ...
Connected to server100 using credentials of locally logged on user.
server connections:

Note: Windows Server 2003 Service Pack 1 eliminates the need for the above step.

1. Type quit and press Enter to return you to the metadata cleanup: prompt.

server connections: q
metadata cleanup:

1. Type select operation target and press Enter.

metadata cleanup: Select operation target
select operation target:

1. Type list domains and press Enter. This lists all domains in the forest with a number associated with each.

select operation target: list domains
Found 1 domain(s)
0 - DC=dpetri,DC=net
select operation target:

1. Type select domain <number>, where <number> is the number corresponding to the domain in which the failed server was located. Press Enter.

select operation target: Select domain 0
No current site
Domain - DC=dpetri,DC=net
No current server
No current Naming Context
select operation target:

1. Type list sites and press Enter.

select operation target: List sites
Found 1 site(s)
0 - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dpetri,DC=net
select operation target:

1. Type select site <number>, where <number> refers to the number of the site in which the domain controller was a member. Press Enter.

select operation target: Select site 0
Site - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dpetri,DC=net
Domain - DC=dpetri,DC=net
No current server
No current Naming Context
select operation target:

1. Type list servers in site and press Enter. This will list all servers in that site with a corresponding number.

select operation target: List servers in site
Found 2 server(s)
0 - CN=SERVER200,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dpetri,DC=net
1 - CN=SERVER100,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dpetri,DC=net
select operation target:

1. Type select server <number> and press Enter, where <number> refers to the domain controller to be removed.

select operation target: Select server 0
Site - CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dpetri,DC=net
Domain - DC=dpetri,DC=net
Server - CN=SERVER200,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dpetri,DC=net
 DSA object - CN=NTDS Settings,CN=SERVER200,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=dpetri,DC=net
 DNS host name - server200.dpetri.net
 Computer object - CN=SERVER200,OU=Domain Controllers,DC=dpetri,DC=net
No current Naming Context
select operation target:

1. Type quit and press Enter. The Metadata cleanup menu is displayed.

select operation target: q
metadata cleanup:

1. Type remove selected server and press Enter.

You will receive a warning message. Read it, and if you agree, press Yes.


Original Post:

Universal groups, global groups, domain local groups

AD Group types: universal groups, global groups, domain local groups

Groups 

Distribution Groups — Used for email. Useful for programs such as MS Exchange.

Security Groups – Used to secure file/folders, printers, etc.

Local – Stored on the local SAM (Local Computers)
Domain Local – Stored on Domain Controllers.
Global Groups – Gives you a greater group scope.
Universal – Gives you an even broader group scope.

Group Scopes

Group scope normally describes the type of users that should be clubbed together in a way that is easy for their administration. Therefore, groups play an important part in domain. One group can be a member of other group(s), which is known as Group nesting. One or more groups can be members of any group in the entire domain(s) within a forest.

• Domain Local Group: Use this scope to grant permissions to domain resources that are located in the same domain in which the domain local group was created. Domain local groups can exist in all mixed, native, and interim functional level of domains and forests. Domain local group memberships are not limited as users can add members as user accounts and universal and global groups from any domain. Nesting cannot be done in a domain local group. A domain local group will not be a member of another Domain Local or any other groups in the same domain.
• Global Group: Users with similar functions can be grouped under global scope and can be given permission to access a resource (like a printer or shared folder and files) available in local or another domain in the same forest. Simply put, global groups can be use to grant permissions to gain access to resources that are located in any domain but in a single forest as their memberships are limited. User accounts and global groups can be added only from the domain in which the global group is created. Nesting is possible in Global groups within other groups as users can add a global group into another global group from any domain. They can be members of a Domain Local group to provide permission to domain specific resources (like printers and published folder). Global groups exist in all mixed, native, and interim functional level of domains and forests.
• Universal Group Scope: these groups are precisely used for email distribution and can be granted access to resources in all trusted domain as these groups can only be used as a security principal (security group type) in a windows 2000 native or windows server 2003 domain functional level domain. Universal group memberships are not limited like global groups. All domain user accounts and groups can be a member of a universal group. Universal groups can be nested under a global or Domain Local group in any domain. 

Universal Group: can contain users and groups (global and universal) from any domain in the forest.  Universal groups do not care about trust.  Universal groups can be a member of domain local groups or other universal groups but NOT global groups.
Global Group: can contain users, computers and groups from same domain but NOT universal groups.  Can be a member of global groups of the same domain, domain local groups or universal groups of any domain in the forest or trusted domains.
Domain Local Group:  Can contain users, computers, global groups and universal groups from any domain in the forest and any trusted domain, and domain local groups from the same domain.  Can be a member of any domain local group in the same domain.
The short answer is that domain local groups are the only groups that can have members from outside the forest. And use global groups if you have trust, universal groups if you don’t care about trust.

When do we need to use local, global and universal group permission?

Use global security groups to group user (or computer) accounts with similar characteristics, for example members of Sales department.
Use domain local security groups to define access to resources (share, NTFS, printer),
for example you would create domain local group “DL ColorPrinter Print” and assign print permission to this group. Then you would put global security group Sales in “DL ColorPrinter Print” group to enable printing for sales department. If marketing department wants to use the same printer you have to create global group Marketing and put this group in “DL ColorPrinter Print” group. This strategy is called A-G-DL-P. Put accounts in global groups, global groups in domain local groups and assign permissions to domain local groups and you will assign permission only once. Everything else happens in Active Directory Users and Computers when you modify groups memberships.
Universal groups should only be used in multiple domain forest. Universal groups are used to nest global groups. Group strategy is then called A-G-U-DL-P.
In shot below are the details
Global Groups:
Use these to group users with similar needs within the organisation, sales people, finance people, manager’s etc
Domain Local Groups:
Use these to specify access to resources e.g. database users, Colour Printer Users.
Universal Groups
Use only in mulitiple domains to give forest wide privileges.

Original Post:

Kerberos in Active Directory Revealing the underpinnings of AD authentication

Although Kerberos might seem like black magic to many systems administrators, it’s one of Active Directory’s (AD’s) key underpinnings. Nearly all of Kerberos’s configuration is abstracted, making actual interaction with the protocol uncommon. However, Kerberos is used every time you log on to an AD-joined machine, as well as when you access network resources such as file shares and applications.
Rather than transmit your actual password over the network, Kerberos operates with a series of tickets. At a high level, when you log on to a machine you generate a series of exchanges with the domain controller (DC) that, if successful, ultimately grants you a ticket-granting ticket (TGT). Each time you subsequently want to access a service, such as a file share or application, you use the TGT to apply for a service ticket to the service or application you want to access.

Authentication

When you sit down at your workstation and press Ctrl+Alt+Del to log on and enter your credentials, your machine begins the process of authentication. At this step, the first thing that happens is your machine sends an AS_REQ or Authentication Service Request Kerberos message to the DC. In Kerberos, we call the DC a Key Distribution Center (KDC). Figure 1 shows the critical contents of such a request.
The client name is either the user’s user principal name (UPN) or the user’s legacy username (sAMAccountName). The service name in this case is always the same, a request to the krbtgt service in the user’s domain (or realm in Kerberos parlance). To prevent replay attacks whereby an attacker recycles an AS_REQ message, the current time is encrypted using a hash of the user’s password. This is where the five-minute clock skew tolerance most AD administrators are familiar with comes into play. If the encrypted timestamp isn’t within five minutes of the current time, the request is rejected.
When the KDC receives an AS_REQ message, the first thing it tries to do is decrypt the encrypted timestamp using its local copy of the user’s password hash. If this operation fails, then an error is returned to the client and the request doesn’t proceed any further. If the decryption is successful and the timestamp is within acceptable limits, the KDC returns an AS_REP (Authentication Service Reply) message to the user, with an embedded TGT. Figure 2 shows the contents of the AS_REP message. At this point, the user’s machine caches the TGT and session key for the lifetime of the TGT and disposes of the user’s password. By default, TGTs issued by AD KDCs expire after ten hours.
It’s important to note that AD’s Kerberos implementation requires the encrypted timestamp in the AS_REQ message. This initial exchange is known as pre-authentication. Kerberos as a standard doesn’t require the encrypted timestamp and instead is perfectly happy with an AS_REQ message that simply contains the client name and service name. The problem with this approach is that an attacker could mount a dictionary attack because each request containing a unique client name would either return an error stating the client wasn’t found or would yield a valid TGT for a given user.
As Figure 2 shows, the AS_REP message contains two pieces of encrypted data. The first component is encrypted with a hash of the user’s password and contains a session key and ticket expiry timestamp. The session key will be used to encrypt future communication with the KDC. The second component, the TGT, is encrypted with the KDC’s secret. The KDC’s secret in AD’s Kerberos implementation is stored as the password to the krbtgt user account that exists in every AD domain. The krbtgt account is created when the first DC in a domain is promoted; this account is crucial to the domain’s operation.

Obtaining a Service Ticket

After you log on, you probably have a myriad of applications and services that you want to access. In the world of Kerberos, anything you want to access is called a service. Common examples of services include file and print servers, database servers, and internal web applications. To access a service, you need to present a service ticket to the service. The first step is to identify the service principal name (SPN) of the service you want to access. Your machine or the application involved (e.g., Internet Explorer) is responsible for forming the SPN.
In the case of a file server called srv01.contoso.com, the SPN for the file service would be cifs/srv01.contoso.com. Likewise for a web application at web01.contoso.com, the SPN might be http/web01.contoso.com. A common problem that AD administrators encounter is one of duplicate SPNs, in which more than one user or computer in the directory has the same SPN registered in its servicePrincipalName attribute. When this happens, the KDC doesn’t know how to respond to a service ticket request because multiple services with the same name exist.
If you look at the servicePrincipalName attribute in AD, you’ll notice that neither of the two sample SPNs mentioned are defined on any computer account in AD. To reduce the amount of duplicate data stored in the directory, AD maintains a forest-level mapping of default SPNs to every computer account in the directory. Literally dozens of built-in SPNs apply to every computer defined in the attribute. The data is stored in the spnMappings attribute of the Directory Service object in the Configuration partition (under CN=Directory Service, CN=Windows NT, CN=Services, CN=Configuration); this attribute maps each computer object’s HOST service to a variety of other services. These services include the CIFS and HTTP services. If you wanted to define a particular service on every machine in your forest, you could easily modify this attribute to add the service to the list of predefined services.
Figure 3 shows the contents of a TGS_REQ (Ticket Granting Service Request) message that the KDC receives from a client when the client attempts to access a service. The first piece of information is the SPN of the service the client is requesting a ticket for. Encrypted with the session key the client received as part of the AS_REP earlier is the client’s name and a timestamp. This information is again used to prevent replay attacks whereby an attacker reuses a request message. Also included is a copy of the TGT the client received earlier.
When the KDC receives a TGS_REQ message, if a single entry for the SPN is specified, the timestamp is within range, and the TGT is valid (and unexpired), the client will receive a service ticket as part of a TGS_REP message, as Figure 4 shows. Inside the TGS_REP message is everything the client needs to access the service that it’s requesting access to.
Encrypted with the session key provided in the AS_REP message that Figure 2 shows is a second session key for use when communicating with the service the client has a ticket for. Encrypted with the service’s secret (e.g., the password of the machine account or service account) is a service ticket that the client will cache and use whenever it needs to access the service. Much like the TGT, service tickets have a maximum lifetime (which is ten hours by default in AD’s implementation of Kerberos) for which they can be reused. With a service ticket in hand, the client can now request access to the service.

Accessing Services

After the client has a service ticket, the application accessing the service can present that ticket to the service and request access. The mechanics of presenting the service ticket aren’t nearly as standardized as for obtaining the ticket because every application is different. In the case of an HTTP service, the service ticket is embedded in the headers of the HTTP request.
The service ticket is presented to the application in the form of a Kerberos AP_REQ message, as Figure 5 shows. The service decrypts the service ticket and obtains the session key, which it can use to decrypt the timestamp and client name fields, which are in turn used to validate the authenticity of the service ticket itself. It’s important to note that even if the service accepts the service ticket, at this point the client has merely authenticated to the service. The task of authorization is still up to the service, based on the information it has about the client.
The service ticket typically also includes data known as the Privilege Attribute Certificate, or PAC. In Figure 5, the PAC is called Token Information. If you refer back to Figure 2, this is the same token information the KDC included in the user’s TGT. The PAC is composed of information such as the user’s SID, group membership information, and user security rights/privileges. When a user presents a TGT to the KDC to request a service ticket, the KDC copies the token information from the TGT and includes it in the service ticket’s PAC field. This is the information that the service uses to construct an access token for the user and to verify the user’s authorization, typically based on group membership.
An additional Kerberos message known as an AP_REP or Application Reply is permissible after the user presents a service ticket in the AP_REQ message that Figure 5 shows. The Application Reply message is optional; in general, the application won’t send such a message unless an error occurs. One example of when an AP_REP message would be generated is in the case of a client that requests (in the AP_REQ message) that a service prove its identity through a process known as mutual authentication.

Process Overview

Figure 6 shows a recap of the message flow when a user decides to access a service on an application server. The user logs on to his or her workstation, generating an AS_REQ and AS_REP message sequence to the KDC, where the user receives a TGT if the credentials are valid. The user’s TGT is subsequently cached in memory and each time the user wants to access a service (such as a file server, print server, or web application), the user presents the TGT back to the KDC and requests a service ticket for the service. The user receives the service ticket and presents it to the application to request access.
If you’re using read-only domain controllers (RODCs) in your environment, the message flow is a bit different from what Figure 6 shows, depending on your password replication policies and where the passwords are cached. Remember that the KDC needs access to the service’s and user/computer’s secrets to issue service tickets and TGTs, respectively. By default, an RODC caches no passwords, so it has no access to the necessary secrets.
In the event that an RODC receives a request for a TGT or service ticket that it can’t fulfill (because of an uncached password), it passes the request back to a writeable DC that holds the necessary secrets to encrypt the response. The writeable DC sends the response to the RODC, which in turn sends it back to the client. If the RODC has the password cached for either the user or the service the user is trying to access, the RODC simply issues the TGT and/or service ticket in the same manner as shown in Figure 6.
If you refer back to Figure 2, you’ll see that the user’s TGT is encrypted using the KDC secret. This secret is the password to the krbtgt account, which all AD domains have. Considering the baseline design assumption of an RODC (i.e., the fact that it's compromised by default), it would be potentially catastrophic if the RODC contained the password to the domain-wide krbtgt account. If the RODC were compromised, the attacker could issue TGTs independently.
To mitigate this risk, each RODC has its own krbtgt account and is never aware of the passwords for either the domain-wide krbtgt account or another RODC’s krbtgt account. Writeable DCs have access to the passwords for all the RODC krbtgt accounts so they can decrypt TGTs issued by any RODC in the domain.

Transparent Authentication

Kerberos is implemented in such a way as to be almost transparent to AD administrators. Unlike many authentication schemes, Kerberos never requires that a password traverse the network, nor does it require a user’s password to be stored in memory after the initial logon. Both these benefits greatly reduce the inherent risk of other authentication protocols.
In addition, Kerberos gives users a single sign-on (SSO) experience. In a subsequent article, I’ll examine Kerberos delegation and protocol transition, as well as discuss common errors and troubleshooting techniques related to Kerberos. Delegation and protocol transition are features that many application developers use to extend SSO to enterprise resources without having to involve end users. Although these features work seamlessly, initially translating an application’s requirements into tangible tasks in the directory is a daunting task for many AD administrators.

Original Post:

Using Perfmon to View Authentication Requests on a Windows DC

Q: We want to quantify the authentication requests that are processed by each of the Windows domain controllers (DCs) in our Active Directory (AD) forest. Is there an easy way to get this information?
A: An easy way to view the authentication load on a Windows DC is to use the built-in Windows performance monitor (perfmon). Perfmon includes the following authentication-related performance counters:

• The Kerberos Authentications/sec counter, which shows the number of times per second a client uses a Kerberos client ticket to authenticate to a DC.
• The NTLM Authentications/sec counter, which shows the number of NT LAN Manager (NTLM) authentications serviced by a DC per second.

Original Post:

Q: What is the krbtgt account used for in an Active Directory (AD) environment?

A: The Kerberos authentication protocol uses session tickets that are encrypted with a symmetric key derived from the password of the server or service to which a Windows user requests access. To request a session ticket, the user must present a special ticket, called the ticket-granting ticket (TGT) to the Kerberos Key Distribution Center (KDC) service on a domain controller (DC). All Windows users get a TGT from the KDC at the start of their Windows login session after they successfully authenticate to the KDC by using their password.
The KDC encrypts a user's TGT with a key it derives from the password of the krbtgt AD domain account. The krbtgt account and its password are shared between the KDC services of all DCs in a domain. The krbtgt account is automatically created as part of the dcpromo AD installation process on the first DC in a domain. It shows up in the Users container of the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in and is disabled by default. Unlike other AD user accounts, the krbtgt account can't be used to log on interactively to the domain. Because it's a built-in account, krbtgt also can't be renamed.
A read-only domain controller (RODC) is a new type of DC that Microsoft introduced in Windows Server 2008. An RODC hosts read-only partitions of the AD database. It doesn't store the password hashes of all user accounts in a Windows domain; instead, an RODC stores only the password hashes of the accounts that are defined in the RODC's Password Replication Policy (PRP). This method means that the compromise of an RODC represents much less risk than the compromise of a classic read/write DC (RWDC) that holds copies of the password hashes of all user accounts in a domain. That's why an RODC can be deployed in a way that might be considered less secure. Organizations typically deploy them in branch offices or in their demilitarized zones (DMZs).
An RODC acts as a Kerberos KDC for a branch office or DMZ, and as such it also requires a krbtgt account. To ensure that the krbtgt of a compromised RODC can't be leveraged to request tickets to other RODCs or RWDCs, each RODC has a special local krbtgt account. This account has the format krbtgt123, where "123" is a string of random numbers. This random string uniquely identifies the RODC and is generated when an RODC is installed.
The different local krbtgt accounts of the RODCs in a domain are stored in AD and show up in Active Directory Users and Computers under the Users container. All RWDCs in the domain also keep a copy of the password hashes of the krbtgt accounts of the RODCs in the domain. Therefore, a TGT that's issued by an RODC is valid for requesting session tickets against the same RODC and also against any other RWDC in the domain.
If an RODC receives a session ticket request that's based on a TGT that isn't valid -- meaning that the TGT wasn't issued by the RODC itself -- it returns a Kerberos error asking the client computer to request a new TGT request against the RODC itself. If the RODC doesn't have a copy of the user's password hash, the RODC forwards the TGT request to a RWDC. In this case, the RODC acts as a proxy, whereby it forwards the answer from the RWDC directly to the client computer. At the same time, the RODC triggers the process of caching the user password hash so that the RODC will be able to create a TGT for that particular user in the future. The caching succeeds if the RODC's PRP allows the user account's password hash to be cached on the RODC.


Original Post:

Active Directory Group Scope - Local Domain, Global Group, Universal Group

Domain Local-

You can add members from any domain in your forest but you can give them access to the resources which are available only in  the domain where you create this DL.

Global- 

You can add members only from the domain where you create this DL, and this DL can be given acess to any resources in any other domains in the forest.
For ex, you have Domain A and B. Your users in domain A , need to access a resource in Domain B. How to accomplish this?
From your domain A ,create a Global DL--- create a Domain Local DL in domain B. Add the Domain 'A's Global DL as a member to the Domain B's Domain Local Group.. Give access to the resource in Domain B. It's done..


Universal- 

Add members from any domain, access resources in any domain of the forest.

Hope it helps.. :)

Use Wireshark to inspect packets on your network

Takeaway: Scott Reeves illustrates how you can use Wireshark to inspect packets, looking specifically at various points in the OSI layer, to troubleshoot network issues.

I’ve been using Wireshark in a number of my posts to show aspects of network performance and to illustrate areas of TCP/IP such as the three way TCP handshake. This week, I thought I’d delve a little more into Wireshark itself and illustrate how the OSI layer works.
Two previous posts have shown the TCP three-way handshake (see, for example, my previous post “Using jperf and Wireshark for troubleshooting network issues“), so I will omit covering it in this post. What I will do is draw attention to the way you can look inside a packet captured using Wireshark. For this example, I used a capture of a network session run using a jperf client and a server. Figure A is a sample from this capture.

Figure A

Click to view larger versions of images.

Looking at Figure A, you can see that the first line shows a summary of the frame. The other lines show the data link layer, the network layer, the transport layer, and finally, the actual data contained within the frame. I will step through each line in order.
One note before beginning: Wireshark will highlight the bytes in hex in the bottom pane (as shown in Figure A). You can change this to binary if desired.

Data Link

Figure B

Moving to the Ethernet layer (shown in Figure B), we can see that it is pretty simple. It contains a destination address and a source address. The data link layer is relatively simple in that it is only concerned with getting a frame to the next adjacent node on the physical medium. The main point of interest is the Organizational Unique Identifier (OUI), which takes up the first three bytes of an Ethernet address. The IEEE assigns the OUI to manufacturers of Ethernet equipment. If you want to take a look at assigned OUIs, the list is maintained at http://standards.ieee.org/develop/regauth/oui/oui.txt.
Wireshark makes it easy for you to check on the manufacturer of a card; you can highlight the field (as shown in Figure B) and extract the OUI. You can then plug the number into the website, http://www.wireshark.org/tools/oui-lookup.html, and obtain the manufacturer.

Network

The Ethernet layer is concerned with node to node. The IP layer is concerned with moving between networks, hence the original meaning of the term internetwork, from whence Internet was derived. Highlighting the network layer shows more details. From Figure C, we can see the source and destination IP addresses as well as the IP header length (20 bytes in this case).

Figure C

We can also see the Differentiated Services (DiffServ) area. This would be where extra information relating to the packet’s type of service goes. For most packets on a LAN this is set to zero, which means best effort. There are several other levels, such as Expedited Forwarding, which generally has low loss, low delay, and low jitter. Diff Serv levels can be used when looking to implement a Quality of Service on IP networks.

Transport

The transport layer is where applications communicate via the use of ports. Looking at the capture shown in Figure D, we can see that the source port is 40519, while the destination port is 5001.

Figure D

Other areas of interest are the header length (32 bytes in this case) and the sequence number.  The sequence number generally will change for each packet.

Data

The final part of the capture is the data part; this is shown in Figure E. Here you will see what data is being sent over the medium. This is where you will find applications such as ssh are very important: using ssh means that a login name and password are encrypted.  In contrast, rsh and rlogin are not encrypted; data is sent in clear text, meaning that you can capture a packet and read the login name and/or password from the data section of the captured packet.

Figure E

Overhead

The size of the data part of the frame is 1448 bytes in this case. There is some overhead due to the headers used by TCP, IP and Ethernet. From Figure E, we can see that the actual frame size is 1514 bytes, whereas the size of the data is 1448 bytes. The overhead in this case is 64 bytes. Of this, 12 bytes is Ethernet, 20 bytes is IP and 32 bytes is TCP.
Wireshark offers many other features, other than the ability to inspect frames. This post touches on how to look at various points in the OSI layers, which can act as an aid in troubleshooting network problems. It can also help you to understand what sort of traffic is going over the network.

Original Post:

Windows Memory Dump

Windows Memory Dump

Hello Techies,

It is very often we see the blue screen on the Microsoft based OS.Basically we called this blue screen as 
Blue Screen Of Death (BSOD).

I have asked the question "what is BSOD" from many guys during the interviews but usually they replied
that it happened due to RAM or HDD failure, they simply reply that in this case they will replace either RAM or HDD to fix this issue on the server. 

So today i will give a idea about this BSOD and how to analyze this issue on windows platform.

->What is BSOD ?
->The Blue Screen of Death , displayed by the Microsoft Windows family of operating systems upon encountering a critical error,of a non-recoverable nature, that causes the system to crash.Stop errors are hardware or driver related, causing the computer to stop responding in order to prevent damage to the hardware or data.

->Type of memory dump ?
->There are three type of dumps created

1. Complete Memory Dump
2. Kernal Memory Dump
3. Small Memory Dump

1. Complete Memory Dump:-A Complete Memory Dump is the largest kernel-mode dump file. This file contains all the physical and virtual memory for the machine at the time of the fault.If you select the complete memory dump option, you must have a paging file on the boot volume The Complete Memory Dump file is written to %SystemRoot%\Memory.dmp by default.The Complete memory dump option is not available on computers that are running a 32-bit operating system and that having 2 gigabytes (GB) or more of RAM (by default).

2. Kernal Memory Dump:  A Kernel Memory Dump contains all the memory in use by the kernel at the time of the crash.The dump file will be around one-third the size of the physical memory on the system. This dump will not include unallocated memory or any memory allocated to applications. It only includes memory allocated to Windows kernel.The Kernel Memory Dump file is written to %SystemRoot%\Memory.dmp by (default)

3. Small Memory Dump:- A Small Memory Dump is much smaller than the other two crash dump files. It is exactly 64 KB in size (128KB on 64-bit systems) .This kind of dump file can be useful when space is greatly limited. However, it contains very less information for the reason of the crash.

                              How to enable memory dump on a windows server

Here i am going to configure the memory dump on Win-7/server 2008

1. Right click on my computer and click on properties then click on 2. Advance system setting option on left side ,then click on 3. Advance tab, Now click on 4. setting under Startup and recovery.Below are the screenshot

Same you can configure from the registery as well from the location as mentioned below

HKLM\System\CurrentControlSet\Control\CrashControl
All the things that you can configure via GUI can be configured via registery as well.

• Write an event to the System Log checkbox = LogEvent
• Automatically Restart checkbox = AutoReboot
• Write Debugging Information drop-down = CrashDumpEnabled
• Dump File text box = DumpFile
• Overwrite any existing file checkbox = Overwrite 

                              How to Crash the server manually using keyboard

Now you have configured the memory dump on the server and now you can check as well if it is creating the memory dump file on the server or not.Also when you need to create memory dump file manually after a crash ,do the following to configure the same.

Using PS/2 keyboard :-


1. Start Registry Editor.
2. Locate the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters

3. On the Edit menu, click Add Value, and then add the following registry entry:

Name: CrashOnCtrlScroll
Data Type: REG_DWORD
Value: 1

4. Exit Registry Editor, and then restart the computer.


 Using USB keyboad:

1. Start Registry Editor.
2. Locate the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\kbdhid\Parameters

3. Make sure that the following registry entry is enabled:

Name: CrashOnCtrlScroll
Data Type: REG_DWORD
Value: 1

4. Exit Registry Editor.

If You can generate a system memory dump by holding down the right CTRL key and pressing the SCROLL LOCK key twice. (Ctrl+Scroll lock twice)

Note: Pressing left CTRL key does not generate the system memory dump.



Will come with new Blog shortly on How to Analyze the memory dump....... ;)

Original Post: