November, 2008

Hi, Rob here. First I want to thank you guys for reading and participating in our blogging efforts. I had one of you e-mail us and ask about the web site I used in the Kerberos Authentication Troubleshooting blogs and if they could get a copy of it.

The web site was created by our IIS support counterparts and it turns out it was released to the web as DelegConfig. Brian Murphy-Booth has a blog about the web site here. We at AskDS do not support the DelegConfig web site, so if you have questions or comments about it leave your feedback at that blog location.

With this web site you can test Kerberos double hop configurations and the newer delegation types of constrained delegation and constrained delegation with protocol transition from IIS to the following services:  SQL, File Server, OLAP Server, or another web server. The reason why this documentation exists is to help customers configure Kerberos delegation to become familiar with all the tasks involved to configure the environment correctly.

Pre-Flight Check-List

• Active Directory Domain Functional Level must be Windows Server 2003 if you want to test constrained delegation.
  
• Name resolution (WINS or DNS) is properly working in the environment.
  
• All computers are within five minutes of time to each other.
  
• All service accounts and server computer accounts (IIS and backend) must exist in the same domain if you are going to configure constrained delegation. Note that the user accessing the resource can be in any domain where Kerberos functions to the domain where the IIS and backend servers exist.
  
• If you are going to test cross-forest Kerberos authentication or delegation then a working two-way forest trust must exist.
  
• The test user account that is going to be delegated must not have the account option Account is sensitive and cannot be delegated configured. You will find this in the Active Directory Users and Computers on the user’s Account tab under the Account options heading.
  
• The default web site in IIS allows Kerberos authentication to be used. If you are not sure review KB 215383.
  
• You are using IIS 6 with the ASP.NET component installed.
  
• You have installed the backend application or service that you want to test.

NOTE: Review Setup and Known issues.txt from the DelegConfig.zip file for proper ASP.NET version to be installed on the IIS Server.

Configuring the Web site and Web Application Pool Account

1. Extract the zip file to a directory on a server running IIS 6. You can specify any location you wish. According to the DelegConfig blog it can be used with IIS 7 however, we are only going to be showing how to configure it with IIS 6.
   
   
   1. When you extract the web site, you need to preserve the folder structure.
      
   2. The server running IIS and back-end service should be installed on separate boxes.
      
   3. You need to have the ASP.NET component checked in Application Server when you install IIS.
      
2. Open Active Directory Users and Computers to create the application pool account.
   
   
   1. We need to create a domain account that will be used for the application pool in IIS. You can name the account anything you wish, for this document we will use the account IISKerbSvc.
      
   2. You will need to configure a password for the service account. Also, you should configure the account’s password to never expire. This is configured under the Account tab.
      
3. Open IIS Manager to add a virtual directory.
   
   
   1. With the Default Web Site highlighted, right-click and select New, then select Virtual Directory.
      
   2. The Virtual Directory Creation Wizard will start, click Next and specify an Alias. For this demo I used KerbDeleg. Then click Next.
      
   3. Navigate to the path folder where you extracted the files for DelegConfig.zip, then click Next.
      
   4. Choose the defaults and click Next then click Finish.
      
4. Now that you have a Virtual Directory named KerbDeleg you need to create an application pool for the web site to use.
   
    
   Figure 1 - Creating a new application pool for the web application
   
   
   1. Right-click Application Pools and select New then select Application Pool.
      
      
   2. The Application Pool ID can be anything and does not have to match the virtual directory name. For this demo I used KerbDeleg. Just name it something unique.
      
5. Once you have the virtual directory and the application pool created, you need to make modifications to the virtual directory that we created in Step 3.
   
   
   1. Right-click the virtual directory you created in Step 4 (KerbDeleg).
      
   2. Select Properties.
      
   3. On the Virtual Directory tab click Create.
      
       
      Figure 2 - KerbDeleg Virtual directory properties tab
      
   4. Change the Application Pool used via the drop-down menu to the one created in Step 4 (KerbDeleg). Note that by default it will be DefaultAppPool.
      
   5. Make sure Execute permissions is set to Scripts only.
      
   6. Click the Documents tab, and select Add.
      
       
      Figure 3 - KerbDeleg - Documents properties tab
      
   7. Type Default.aspx in the dialog box and click OK.
      
   8. Select the Directory Security tab.
      
      
      Figure 4 - Changing the authentication methods
      
   9. Under Authentication and access control click Edit button.
      
   10. Uncheck Enable anonymous access, and check Integrated Windows authentication.
       
   11. Click OK twice.
       
6. Now we need to change the Identity used by the application pool that we created in Step 4 (KerbDeleg).
   
   
   1. Right click on the application Pool you created. In this documentation it is "KerbDeleg", and select "Properties"
      
        Figure5 - Changing the application pool identity to a service account
      
   2. Select the Identity tab.
      
   3. Select Configurable and find the account we created in Step 3 (IISKerbSvc).
   4. Once you have selected the user account and typed in the password for the account, click OK.
      
7. Now, we need to add the user account from Step 2 (IISKerbSvc) to the computer local group IIS_WPG.
   
   
   1. If the server running IIS is a member server, use Compmgmt.msc (Computer Management).
      
   2. If the server running IIS is a domain controller, use Dsa.msc (Active Directory Users and Computers) and this group is located in the Users container.
      
       
      Figure 6 - Adding application pool account to the IIS_WPG group
      
      Note  This step is done to allow the IISKerbSvc (application pool identity) the ability to impersonate the user on the web server. If you look at the computer’s user right assignments you will see Impersonate a client after authentication and the IIS_WPG group is added there by default.
      
8. We now need to configure the user account for delegation within the domain. So we need the Setspn tool in the Windows Support Tools, and access to Active Directory Users and Computers.
   
   
   1. At a command prompt type the following to find out what Service Principal Names (SPNs) are already associated with your IIS application pool service account:
      
      setspn -L <Domain Name>\<Account from Step 2>
      
   2. What we want to see is similar to the following:
      
      http/<IIS Web site Address>
      http/<IIS Web site Address FQDN>
      
      Example:
      
      http/webserver01
      http/webserver01.contoso.com
      
      Or
      
      http/www
      http/www.contoso.com
      
      Note There is no colon (":") anywhere in here when we use HTTP. This is a common mistake that can happen when creating SPNs for web sites.
      
   3. If you do not see any of the above listed for the application pool service account then we need to add them one at a time via the following command:
      
      setspn -A http/<Web site Address > <Domain Name\<Account from Step 2>
      setspn -A http/<Web site Address FQDN> <Domain Name\<Account from Step 2>
      
      Example: 
      
      setspn -A http/webserver01 Contoso\IISKerbSvc
      setspn -A http/webserver01.contoso.com Contoso\IISKerbSvc
      
      Or
      
      setspn –A http/www Contoso\IISKerbSvc
      setspn –A http/www.contoso.com Contoso\IISKerbSvc

For more information on this topic as it relates to IIS you can review the below web site location:

Configuring Constrained Delegation for Kerberos (IIS 6.0)http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/df979570-81f6-4586-83c6-676bb005b13e.mspx?mfr=true

Configuring the SQL Backend

So that this blog is not too long (yeah, I know I am not known for short blogs) we are only going to show you how to configure the SQL server as the backend and how to test it since this is the most common situation where Kerberos delegation is configured. Keep in mind that for learning how Kerberos multi-hop works you do not need to install the full version of SQL. You can use SQL Express, and it can be installed on any operating system.

Registering a Service Principal Name
http://technet.microsoft.com/en-us/library/ms191153.aspx

Kerberos Authentication and SQL Server
http://technet.microsoft.com/en-us/library/cc280744.aspx

The SQL Server Service can run under basically two types of accounts.

1. The Local System also known as the SYSTEM account.
2. A domain user account configured as a service account that the customer creates.

The web site can verify either of these configurations, but there are different steps that need to be followed dependant on which configuration the SQL Server Service is running. Of course with all these configurations it is very important that we have the correct SPNs registered to the correct computer or user account.

User Account (Service Account) SPN Configuration

1. If the SQL Server Service is running as a user account, then we need to make sure that the MSSQLSvc SPN for the computer is not registered to the computer. You can run the following command to determine this:
   
   setspn –L <SQL Server Computer Name>
   
2. If this does come back with a MSSQLSvc SPN registered then you will need to delete that SPN from the computer account, by typing the following command:
   
   setspn –D MSSQLSvc/<Computer Name>:<Port> <Computer Name>
   setspn –D MSSQLSvc/<Computer FQDN>:<Port> <Computer Name>
   
   Here is an example:
   
   setspn –D MSSQLSvc/SQLSrv1:1433 SQLSrv1
   setspn –D MSSQLSvc/SQLSrv1.contoso.com:1433 SQLSrv1
   
   Then you will want to verify that all SPNs are no longer registered by running SetSPN –L command again.
   
3. Once that has been verified, we will need to register the MSSQLSvc SPN to the SQL Server service account being used to run the SQL Server by typing the following:
   
   setspn –A MSSQLSvc/<SQL Server Name>:<Port> <Domain Name>\<User Account>
   setspn –A MSSQLSvc/<SQL Server Name FQDN>:<Port> <Domain Name>\<User Account>
   
   Here is an example:
   
   setspn –A MSSQLSvc/SQLSrv1:1433 CONTOSO\MSSQLSvc
   setspn –A MSSQLSvc/SQLSrv1.contoso.com:1433 CONTOSO\MSSQLSvc

Local System SPN Configuration

1. If the SQL Server service account is running as Local System (which is not common today), then we need to make sure that the MSSQLSvc SPN for the computer is registered. You can run the following command to determine this:
   
   setspn –L <SQL Server Name>
   
2. If this does NOT come back with a MSSQLSvc SPN registered then you will need to add the SPN for the computer, by typing the following command:
   
   setspn –A MSSQLSvc/<Computer Name>:<Port> <Computer Name>
   setspn –A MSSQLSvc/<Computer FQDN>:<Port> <Computer Name>
   
   Here is an example:
   
   setspn –A MSSQLSvc/SQLSrv1:1433 SQLSrv1
   setspn –A MSSQLSvc/SQLSrv1.contoso.com:1433 SQLSrv1

Finishing the Configuration for Delegation to Work

1. Open Active Directory Users and Computers.
2. Find the user account that the IIS Web site is using for the web application pool and double-click it.
   
   
   1. If you are in 2000 native mode for the domain, click on the Account tab and check the box Account is trusted for delegation.
      
       
      Figure 7 - Windows 2000 domain functional level delegation setup
      
      
   2. If you are in 2003 domain functional mode, click on the Delegation tab.
      
      NOTE This tab does not exist if you are not in Windows Server 2003 domain functional level or the user account does not have a SPN already defined on the account.
      
      
      Figure 8 - Windows Server 2003 domain functional level delegation setup
      
   3. To enable open delegation select: Trust this user for delegation to any service (Kerberos only).
      
   4. To enable constrained delegation by selecting:  Trust this user for delegation to specified services only.
      
   5. Click the Add button, and then click on the Users or Computers button.
      
   6. If the SQL Service was configured to start as Local System then type in the SQL Servers computer name, and click Check Names. Click OK.
      
   7. If the SQL Service was configured to start as a domain user account then type in the user account name, and then click Check Names. Click OK.
      
      For this discussion remote computer name refers to the backend server that the IIS web site needs to hand the users Kerberos ticket to.
      
3. You will see all available SPNs on the remote system. Select the SPN associated with MSSQLSvc then click OK.
   
4. Click OK on the user properties dialog box.
   
5. Restart the IIS service.

How to Test the Web Site

1. Open Internet Explorer, and type in the address of the http://<web site name>/kerbdeleg
   
   Example:
   
   http://webserver01/kerbdeleg
   http://webserver01.contoso.com/kerbdeleg
   
2. Then click on the Add Backend button. Then you will get the web page to configure the backend you want to talk to.
   
   
   1. Remote address - this should be the SQL Server with which you want to test Kerberos delegation.
      
      Example:
      
      MEMBER1 or MEMBER1.contoso.com
      
   2. Service type - this needs to be set to SQL Server.
      
   3. Listening port - for SQL Server access this port needs to match where SQL Server is listening. By default this is port 1433.
      
   4. Service account:  If the SQL Server service was configured as Local System then this needs to be set to Preferred and Local System. If the SQL Server service was configured for a domain account then this needs to be set to Configured and type in the <domain>\<SQL service account>.
      
3. Click Submit.

Configuring for Protocol Transition

1. You will first need to make sure that constrained delegation is configured and working in your lab environment. Once this has been accomplished then you should be able to continue.
   
2. Bring up Active Directory Users and Computers.
   
   
   1. Find the user account that is being used for the IIS application pool and Edit the user.
      
   2. Click on the Delegation tab, which you can review in Figure 8.
      
   3. And select Use any authentication protocol.
      
   4. Click OK.
      
3. Restart the IIS service.

Common Problems When Configuring the Site

• Prompted for user credentials over and over again – check to make sure that the application pool is correctly configured on the virtual directory. Review Step 5 from above.
  
• Directory Listing Denied error – Check to make sure Execute permissions is to Scripts only under Virtual Directory tab. Review Step 5 from above.
  
• 403 error – check to make sure default.aspx has been added as a default content page. Review Step 5 from above.
  
• 404 error – check to make sure that you have installed support for ASP.NET. Look in Add/Remove Windows Components under Application Server and verify that ASP.NET is checked.
  
  
  • Next in IIS Manager select Web Service Extensions and make sure that ASP.NET is allowed.
    
  • Right-click the Virtual Directory and select Properties.
    
  • Click on the ASP.NET tab, and select an ASP.NET version that is installed.

I hope that you have been able to learn some new things. All the steps outlined here need to be done when configuring Kerberos delegation and this site will definitely help engineers to understand how Kerberos delegation works.

Have fun learning and testing all the different configurations that are possible with this application!

- Rob Greene

Note that this content has also been added to the TechNet Wiki to allow for community editing.

http://social.technet.microsoft.com/wiki/contents/articles/how-to-back-up-and-restore-ntfs-and-share-permissions.aspx 

From time to time we are asked how to backup and restore NTFS file system permissions as well as network share permissions. KB article 125996 talks about the network share piece of it, but it does not talk about NTFS permissions.

One thing that has made the NTFS permissions piece of this simpler is the Icacls tool. Icacls was developed for Windows Vista as a replacement for tools such as Cacls, Xcacls, and Xcacls.vbs. It was also included in Service Pack 2 for Windows Server 2003 and Windows Server 2008.

Backup and Restore of Share Permissions

To backup share permissions, export the Shares registry key.

1. Open Regedit to the following location:
   
   HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
   
2. Right-click the Shares registry key and select Export. Give it a file name such as shareperms.reg.

When you want to restore the permissions, double-click shareperms.reg to import it back into the registry.

Use the Reg tool to backup the registry key from the command line:

reg export HKLM\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares shareperms.reg

If you need to restore it at some point, just run:

reg import shareperms.reg

Backup and Restore of NTFS Permissions

Use this command to backup NTFS permissions:

icacls d:\data /save ntfsperms.txt /t /c

The /T switch allows it to get subfolder permissions too. The /C switch allows it to continue even if errors are encountered (although errors will still be displayed).

Use this command to restore them:

icacls d:\ /restore ntfsperms.txt

Note that in the command to save the permissions, I specified the target folder D:\Data, but when I restored them, I specified just D:\ as the target. Icacls is a little funky like that, and here’s why.

If you open the text file with the exported permissions (ntfsperms.txt in the above example), you’ll see that Icacls uses relative paths (in bold below). Underneath the relative paths are the permissions for the folders in Security Descriptor Definition Language (SDDL) format.

data
D:AI(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;FA;;;SY)(A;OICIIOID;GA;;;SY)(A;OICIID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU)(A;OICIIOID;SDGXGWGR;;;AU)
data\folder1
D:AI(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;FA;;;SY)(A;OICIIOID;GA;;;SY)(A;OICIID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU)(A;OICIIOID;SDGXGWGR;;;AU)
data\folder2
D:AI(A;ID;FA;;;BA)(A;OICIIOID;GA;;;BA)(A;ID;FA;;;SY)(A;OICIIOID;GA;;;SY)(A;OICIID;0x1200a9;;;BU)(A;ID;0x1301bf;;;AU)(A;OICIIOID;SDGXGWGR;;;AU)

Had I specified D:\Data in the command to restore the permissions, it would have failed looking for a D:\Data\Data folder:

D:\>icacls d:\data /restore perms.txt
d:\data\data: The system cannot find the file specified.
Successfully processed 0 files; Failed processing 1 files

You might think specifying D:\ as the target in the restore command may somehow mess up the permissions on other folders at that level, but as you can see from the ntfsperms.txt output file, it only has information about the Data folder and subfolders, so that is all it will change.

- Craig Landis

New KB articles related to Directory Services for the week of 11/16-11/23.

Hi all. This is Sean again and it’s ADFS blog time! Today I’m going to touch on Security Assertion Markup Language (SAML) tokens, and an issue we’ve run into when federating with Tivoli Federated Identity Manager (TFIM). I’ll discuss what a SAML token is, why it’s important, and what happens when TFIM tries to validate one from ADFS.

As you may know, the Active Directory Federation Service (ADFS) uses SAML tokens to represent claims. These claims about a user are made by the Federation Service Account (FS-A) server. The claims located in the SAML token are what allow the Federation Service Resource (FS-R) server to determine what claims to grant the user in the resource’s domain. Generally, the transaction goes something like this:

1. The client requests a SAML token from the FS-A server. The client authenticates to the server using Windows credentials.
   
2. The FS-A creates the SAML token that contains claims for the user (group membership, UPN, etc) and issues the token to the client. This token is signed with the token signing certificate and also has a proof key encrypted for the FS-R server.
   
3. The client receives a copy of the proof key as well. The client will present the SAML token to the FS-R and sign the message with the proof key.
   
4. The signatures allow the FS-R to verify that the SAML token was actually issued by the FS-A to the specific client presenting it.

After this happens, the SAML token is verified, the claims are extracted, and the rest of the ADFS process continues, right?

Well, almost. In addition to validating the SAML token using the public key of the certificate that the FS-A used to sign it, the FS-R also looks at time conditions specified in the token. To view the SAML token, you will need to enable the verbose debug level on the Federation Service Properties page. This can be done on either the FS-A or the FS-R. The log file will be located in the log files directory that you specify.

In the SAML token you will see a condition block close to the top that looks like this:

<saml:Conditions NotBefore="2008-09-11T19:47:41Z" NotOnOrAfter="2008-09-11T20:47:41Z">
<saml:AudienceRestrictionCondition> <saml:Audience>urn:federation:treyresearch</saml:Audience>
</saml:AudienceRestrictionCondition>
</saml:Conditions>

Note the “NotBefore” and “NotOnOrAfter” conditions that are in bold. These mean exactly that. If the SAML token is presented to the FS-R BEFORE the NotBefore time, or ON or AFTER the NotOnOrAfter time, then the SAML token will fail validation. Generally you’ll get an error message on the FS-R to the effect of “Unable to Validate Signature on SAML Token.”

It’s important to note that the time used to check against these values is the local time on the FS-R (whether it’s an ADFS FS-R or another solution like TFIM). The issue comes when the FS-A and the FS-R clocks are not in sync. Let’s explore this with an example.

Let’s say we have a client from Adatum.com trying to access a resource in Treyresearch.net. The client will hit the website, get redirected to the Treyresearch.net federation server, perform the client realm discover, and get redirected to the Adatum.com federation server. At this point we’ll go through the process outlined above for obtaining a SAML token. Now, the Adatum resource server is going to set the NotBefore time to the time the SAML token was issued based on its local time. So, if it has a time of 11:31AM when the SAML token is issued, that’s what the NotBefore time will be set to. When the client gets redirected back to the Treyresearch federation server, the NotBefore time will be compared to its local time. If the time on the Treyresearch federation server is set to something earlier than 11:31AM then the token validation will fail.

Apparently someone in the ADFS development group understood that this could be a common issue. To help mitigate the issue, in a federated environment with ADFS running on the resource side the FS-R will allow for a token that is sent five minutes “in the future.” This eliminates the need for absolutely strict time consistency between two completely separate organizations.

On the other hand, TFIM strictly enforces the NotBefore setting in the token. If the local time is before the NotBefore setting then the SAML token will fail validation. So, if ADFS is setup as the account partner, and TFIM is setup as the resource partner, the ADFS federation server’s time cannot be ahead of the TFIM federation server’s time. Let’s consider this with another example.

Suppose an ADFS FS-A issued a SAML token with a NotBefore time of 11:31. The client then gets redirected to a TFIM FS-R whose local time is 11:29. When the TFIM server goes to validate the SAML token, it will fail because the NotBefore time hasn’t been reached.

To help alleviate this issue Microsoft released hotfix 956279 that makes the allowed time difference between the ADFS server and the TFIM server configurable. Once the hotfix is installed on the FS-A, the web.config file on the FS-A can include the <TokenIssuanceNotBeforeSkewInMinutes> tag inside of the <FederationServerConfiguration> tag. If you wanted to set a 5 minute skew, the web.config file would contain this:

<TokenIssuanceNotBeforeSkewInMinutes>5</TokenIssuanceNotBeforeSkewInMinutes>

Right after this:

<FederationServerConfiguration>

So, what’s the moral of this story? If you’re running ADFS on the account side of a federation and TFIM is hosting the resource side, make sure you’ve got time synced on both servers or download the hotfix to configure a little wiggle room. Otherwise you will be “Unable to Validate Signature on SAML Token” as well.

For more information about setting up ADFS and TFIM check out the ADFS Step-by-step Guide: Federation with IBM Tivoli Federated Identity Manager.

- Sean “Lurch” Ivey

We’ve been at this for over a year (since August 2007), with more than 100 posts (127 to be exact), so maybe we can indulge in a little metablogging to look back on what we’ve done.

First let’s look at the posts that sparked the most conversation – because that is what blogging is all about right? If we wanted to simply publish information, we could just as easily create KB or Technet articles. Well, ok, there are decidedly fewer hoops to jump through to post a blog, but by blogging we also get to hear from you. Being in tech support, we hear from you quite a bit already. But I’m guessing many of you take pride in how infrequently you call us, so the blog opens up conversations with people we may never hear from otherwise.

The big winner here was Ned’s Top 10 Common Causes of Slow Replication with DFSR. It has five times the number of comments as the next highest post. It basically became a support forum for DFSR issues, and Ned was nice enough to oblige. To a lesser degree that is what happened with the other most-commented posts.

Top 10 AskDS Posts by Comments (Aug. 07 – Nov. 08)

1. Top 10 Common Causes of Slow Replication with DFSR
2. New DFSR Data Restoration Script
3. Remote Server Administration Tools Released for Windows Vista SP1 (Hurray!)
4. Vista’s MoveUser.exe replacement
5. Get out and push! Getting the most out of DFSR pre-staging
6. Kerberos for the Busy Admin
7. What are the Schema Extension Requirements for running Windows Server 2008 DFSR?
8. How to Enable Remote Administration of Server Core via MMC using NETSH
9. Fun with WMI Filters in Group Policy
10. “Lag site” or “hot site” (aka delayed replication) for Active Directory Disaster Recovery support

Not surprisingly, the same post topped the list for page views. But there are several that show up here with high page views that didn’t generate much conversation at all.

Top 10 AskDS Posts by Page Views (Aug. 07 – Nov. 08)

1. Top 10 Common Causes of Slow Replication with DFSR
2. Not enough storage is available to complete this operation
3. Deploying Custom Registry Changes through Group Policy
4. Documenting Active Directory Infrastructure the Easy Way
5. Which KB articles resolve the most Directory Services issues?
6. Troubleshooting High LSASS CPU Utilization on a Domain Controller (Part 1 of 2)
7. How to troubleshoot Certificate Enrollment in the MMC Certificate Snap-in
8. Kerberos Authentication problems – Service Principal Name (SPN) issues - Part 1
9. Managing Power with Group Policy: Part 3 of 3
10. Kerberos for the Busy Admin

Our goal with this blog is to get information in the hands of customers so they can more effectively use our products, and hopefully save some of you from having to call us for support. If you have any thoughts about topics you would like to see more (or less) about, please leave us a comment.

Ned here again. I recently spent a week with Microsoft Support Engineers from all over the world, and bumped into a colleague that works in MS Spain, out of Madrid. She mentioned that they had a Spanish-language blog focused on Directory Services, networking, and other Windows Platform topics. For all of our Spanish-speaking readers, I highly recommend you visit them; they have some very interesting articles and techniques they offer.

Platformas (Consulta con el equipo de Windows)

¡Hola Paula! :-)

- Ned Pyle

New KB articles related to Directory Services for the week of 11/9-11/16.

Ned here again. We recently had a very lively discussion about 'Lag Sites' as a disaster recovery option. If you've been digging around the MS Download Center, you may have already come across Introduction to Windows Server 2008 R2.  After some digging, you'll come across:

Improvements in Active Directory Domain Services
The Active Directory Domain Service server role in Windows Server 2008 R2 includes the following improvements:

• Recovery of deleted objects. Domains in Active Directory now have a Recycle Bin feature that allows you to recover deleted objects. If an Active Directory object is inadvertently deleted, you can restore the object from the Recycle Bin. This feature requires the updated R2 forest functional level.

So while this won't be a replacement for solid backups, it certainly should augment them well and allow admins to get data back quickly without the need for complex lag site arrangements, or worries that the deletion has occured before the backups have had a chance to capture it. As always, this is pre-release documentation and there are no guarantees made about the component availablity or even if it will be included yet. Definitely keep your eyes open for it though. :-)

Definitely skim that document, there are all sorts of interesting tid-bits in there for the sharp-eyed. More news to come...

- Ned Pyle