Archive for August 1, 2011

Kerberos Troubleshooting Tools

Posted: August 1, 2011 in Active Directory, Security, Server 2008, System Information
Tags: , , ,
2

Windows Server 2008 provides several tools that can be used when troubleshooting Kerberos Authentication

 

Klist.exe: Kerberos List: This tool is installed on Windows Server 2008 domain controllers and is available for download as part of the Windows Server 2003 Resource Kit tools.

 

Kerberos List is a command-line tool that is used to view and delete Kerberos tickets granted to the current logon session. To use Kerberos List to view tickets, you must run the tool on a computer that is a member of a Kerberos realm.

 

Kerbtray.exe: Kerberos Tray: Kerberos Tray is available for download as part of the Windows Server 2003 Resource Kit tools.

 

Kerberos Tray is a graphical user interface tool that displays ticket information for a computer running Microsoft’s implementation of the Kerberos version 5 authentication protocols. You can view and purge the ticket cache by using the Kerberos Tray tool icon located in the notification area of the desktop. By positioning the cursor over the icon, you can view the time left until the initial TGT expires. The icon also changes in the hour before the Local Security Authority (LSA) renews the ticket.

 

Tokensz.exe: Kerberos Token Size: Kerberos Token Size is available for download from the Microsoft download center.

 

You can use Kerberos Token Size to verify if the source of the Kerberos errors stems from a maximum token size issue. The tool will simulate an authentication request and report the size of the resulting Kerberos token. The tool will also report the maximum supported size for the token.

 

Setspn.exe: The Setspn utility is installed on Windows Server 2008 domain controllers and is included in the Windows Server 2003 Support Tools.

 

The Setspn utility allows you to read, modify, and delete the Service Principal Names (SPN) directory property for an Active Directory service account. Because SPNs are security-sensitive, you can only set SPNs for service accounts if you have domain administrator privileges.

 

Ksetup.exe: The Ksetup utility is installed on Windows Server 2008 domain controllers and is included in the Windows Server 2003 Support Tools.

 

The Ksetup utility configures a client connected to a server running Windows Server 2008 to use a server running Kerberos V5. The client then uses a Kerberos V5 realm instead of a Windows Server 2008 domain.

 

Ktpass.exe: The Ktpass utility is installed on Windows Server 2008 domain controllers and is included in the Windows Server 2003 Support Tools.

 

The Ktpass utility is used to configure a non–Windows Server Kerberos service as a security principal in the Windows Server 2008 AD DS.

 

W32tm.exe: Windows Time: This tool is included in Microsoft Windows server and client operating systems.

 

W32tm.exe is used to configure Windows Time service settings. It can also be used to diagnose problems with the time service.

Advertisement

Intrasite and Intersite Replication

Posted: August 1, 2011 in Active Directory, Server 2008, System Information
Tags: , , , ,
3

The description of how AD DS replication works applies to both intrasite and intersite replication. In both cases, the domain controllers use the same processes to optimize the replication process. However, one of the main reasons to create additional sites in AD DS is to manage replication traffic. Because all of the domain controllers within a site are assumed to be connected with fast network connections, replication between these domain controllers is optimized for maximum speed and reduced latency. However, if the replication traffic has to cross a slow network link, conserving network bandwidth is a much more significant issue. Creating multiple sites allows for this conservation of network bandwidth by enabling features such as data compression and scheduled AD DS replication.

 

Intrasite Replication

 

The primary goal for replication within a site is to reduce replication latency, that is, to make sure that all domain controllers in a site are updated as quickly as possible. To accomplish this goal, intrasite replication traffic has the following characteristics:

 

  • The replication process is initiated by a notification from the sending domain controller. When a change is made to the database, the sending computer notifies a destination domain controller that changes are available. The changes are then pulled from the sending domain controller by the destination domain controller using a remote procedure call (RPC) connection. After this replication is complete, the domain controller notifies another destination domain controller, which then pulls the changes. This process continues until all the replication partners have been updated.
  • Replication occurs almost immediately after a change has been made to the AD DS information. By default, a domain controller will wait for 15 seconds after a change has been made and then begin replicating the changes to other domain controllers in the same site. The domain controller will complete replication with one partner, wait 3 seconds, and then initiate replication with another partner. The reason the domain controller waits 15 seconds after a change is to increase the efficiency of the replication in case additional changes are made to the partition information.
  • The replication traffic is not compressed. Because all the computers within a site are connected with fast network connections, the data is sent without compression. Compressing the replication data adds an additional load on the domain controller server. Uncompressed replication traffic preserves server performance at the expense of network utilization.
  • Replication traffic is sent to multiple replication partners during each replication cycle. Whenever a change is made to the directory, the domain controller will replicate the information to all direct replication partners, which might be all or some of the other domain controllers in the site.

 

Intersite Replication

 

The primary goal of replication between sites is to reduce the amount of bandwidth used for replication traffic. This means that intersite replication traffic has the following characteristics:

 

  • Replication is initiated according to a schedule rather than when changes are made. To manage replication between sites, you must configure a site link connecting the two sites. One of the configuration options on the site link is a schedule for when replication will occur. Another is the replication interval setting for how often replication will occur during the scheduled time. If the bandwidth between company locations is limited, the replication can be scheduled to happen during nonworking hours.
  • Replication traffic is compressed down to about 40 percent of the noncompressed size when replication traffic is more than 32 KB in size. To save bandwidth on the network connection, the bridgehead servers in each site compress the traffic at the expense of additional CPU usage.
  • Notifications are not used to alert a domain controller in another site that changes to the directory are available. Instead, the schedule determines when to replicate. Note You can disable compression for intersite replication and enable notifications.
  • Intersite replication connections can use either an Internet Protocol (IP) or a Simple Mail Transfer Protocol (SMTP) transport. SMTP can be used as a transport protocol only for the configuration, schema, and application directory partitions, not for the domain partition. The connection protocol you use is determined by the available bandwidth and the reliability of the network that connects company locations.
  • Replication traffic is sent through bridgehead servers rather than to multiple replication partners. When changes are made to the directory in one site, the changes are replicated to a single bridgehead server (per directory partition) in that site, and the changes are then replicated to a bridgehead server in the other site. The changes are replicated from the bridgehead server in the second site to all the domain controllers in that site.
  • You can easily modify the flow of replication between sites. Almost every component of intersite replication can be changed.

Encrypting File System in Server 2008

Posted: August 1, 2011 in Active Directory, Server 2008, System Information
Tags: , ,
2

The Encrypting File System (EFS) is one feature made possible by reparse points in Windows Server 2008 that enhances security for local files on NTFS volumes. EFS is useful for securing files on any system, but it is most useful on systems that can easily be stolen or physically compromised, such as notebook and tablet PCs. EFS is integrated within NTFS and therefore is applicable only to files on NTFS volumes. FAT16 and FAT32 volumes do not support EFS. Only files can be encrypted; folders cannot, even on NTFS volumes. However, folders are marked to indicate that they contain encrypted data. EFS are designed to protect files locally, and therefore don’t support sharing of encrypted files. You can store your own encrypted files on a remote server and access those files yourself. The data is not encrypted during transmission across the network, however, unless you use Internet Protocol Security (IPsec) to encrypt IP traffic (assuming you are using TCP/IP as the network protocol for transferring the file).