Active Directory Blog : Vista, Server 2008

Testing a Credential Provider

Tim Springston — Sat, 11 Jul 2009 00:43:36 GMT

Weeks ago I blogged about how single sign on and credential providers work and a scenario you can run into with them. One reader faced a slightly different scenario but was able to apply that topic toward getting his issue resolved. He had installed a...(read more)

ADMT 3.1 Is Now Available for Download!

Tim Springston — Thu, 10 Jul 2008 21:36:00 GMT

There’s been a lot of interest in the next version of our free migration tool and guide. Well, it’s now available. The link below can get you to the new Migration Guide, ADMT itself, and a link to the Password Export Server (PES) 3.1 in both x86 and x64...(read more)

2008 Web Enrollment and Version 3 Templates

Tim Springston — Tue, 01 Jul 2008 00:00:00 GMT

Certificate Services in Server 2008 has had a lot of changes and enhancements. Some are obvious and documented well, and others are not obvious and not so well documented. Case in point is an additional aspect of Server 2008 certificate web enrollment....(read more)

ADMT 3.1 Beta!

Tim Springston — Wed, 23 Apr 2008 01:04:00 GMT

For folks who have been interested helping test Active Directory Migration Tool version 3.1 your day has come! The ADMT 3.1 Beta is here! This is a beta , not the finished product, so please test it out in your non-production environment and file bugs...(read more)

2008 Certificate Web Enrollment Pages - Available!!

Tim Springston — Tue, 11 Mar 2008 16:00:00 GMT

I am very happy to announce that the Certificate Web Enrollment pages from Server 2008 are available as a free download at last. Just click on the links below to get the pages, then follow the steps in the KB article to install them on your Server 2003...(read more)

ADMT and Server 2008

Tim Springston — Mon, 10 Mar 2008 17:09:00 GMT

Whenever we release a new product or suite of products we at Microsoft want to ease the adoption of it. For that reason we’ve released tools and scripts over the years to help our customers out. We’ve typically given these as free downloads from the internet,...(read more)

The FEK, AES and FIPs: Acronym Heaven!

Tim Springston — Mon, 04 Feb 2008 19:14:00 GMT

I’ve had several blog posts about the improved security in Windows Vista and Server 2008, particularly around cryptography. Here’s one more, albeit a short one. This post is about how, generally, Encrypted File System (EFS) works using Advanced Encryption...(read more)

Server 2008 and Windows Vista: Encryption Better Together

Tim Springston — Fri, 02 Nov 2007 15:00:00 GMT

A while back I did a blog post about some problems that were seen with people testing Windows Vista and then “rolling back” to Windows XP and some problems that could be seen when using the same computer object (also known as account) in AD. If you didn’t get a chance to read it here’s the post. What that scenario highlighted was the added level of encryption, by way of leaving behind a little of the supporting infrastructure in the msds-supported-encryptiontypes attribute value. In this post we’re going to talk about the Big Picture of the new authentication encryption available and a few things to keep in mind....(read more)

Vista Issue: Vista to Vista Terminal Service Logon Failing

Tim Springston — Fri, 08 Jun 2007 00:46:00 GMT

Some of my colleagues recently had a real puzzler of an issue. When they are that good I want to share it out with everyone so that they don’t have to take the time themselves.

The symptoms were when attempting to connect via terminal services from one Vista computer to another Vista computer the connection would fail with an error:

"No authority could be located for authentication. For assistance, contact your system administrator or technical support."

The system administrators were the ones calling us (technical support), and rightfully so. This did not look like it should be happening at all. Some of the additional details on this issue and when it may occur are:

· Both Vista computers must be members of Active Directory domains.

· The user who is logging on is a member of a domain which has had at least one authoritative restore done to the Users container (well, specifically the KrbTgT object which resides there).

· This will occur if you specify the name of the Vista computer you want to log on to remotely (mstsc /v:<computername>)-but not if you use the IP address.

Why is this happening? Well, you may have heard of a little something we’re working on called Windows Server 2008, also known as Longhorn. Longhorn has a new feature (discussed in a prior blog post) called Read Only Domain Controllers (RODCs). RODCs have a read-only copy of the domain naming context that they are domain controllers for. Think of how global catalogs host read only copies, but for the domain and with a few differences.

One of the design considerations for having RODCs is figuring out how client computers will know an RODC from a regular DC. Maybe you have a change to be done that can only be handled by a full DC-like a user account creation, or a password change.

Vista clients have code in some places to help determine if they are communicating with an RODC or a full DC.

Why this little explanation? Because it turns out that the Vista client was thinking that the domain controller that was providing authentication for the terminal service session was an RODC one. So it would look for a non-RODC one and not succeed since it was using the same test to look.

The test used was a look at the version number of the KrbTgT object in the Active Directory. RODCs, by nature, will have a different KrbTgT account with its own password that will change more frequently (or at all) compared a regular domain controllers KrbTgT version number. Vista was assuming that, since the KrbTgT version was large, that the domain controller being used was an RODC.

Of course, the customers who originally called us about this did not have Longhorn RODCs in their environment.

How do you determine the version number of your KrbTgT object? Repadmin.exe is your friend on this. Run the command below and it’s as plain as day (be sure to substitute your own domain controller name for tspringdc1, and your own domain name for the remainder of the distinguished name below):

repadmin /showobjmeta tspringdc1 “CN=krbtgt,CN=Users,DC=tspringtest,DC=com”

…and the result:

35 entries.

Loc.USN Originating DC Org.USN Org.Time/Date Ver Attribute

======= =============== ========= ============= ============

12320 Default-First-Site-Name\TSPRINGDC1 12320 2005-05-27 12:40:46 100001 objectClass

12320 Default-First-Site-Name\TSPRINGDC1 12320 2005-05-27 12:40:46 100001 cn

12325 Default-First-Site-Name\TSPRINGDC1 12325 2005-05-27 12:40:46 100002 description

12320 Default-First-Site-Name\TSPRINGDC1 12320 2005-05-27 12:40:46 100001 instanceType

12320 Default-First-Site-Name\TSPRINGDC1 12320 2005-05-27 12:40:46 100001 whenCreated

12321 Default-First-Site-Name\TSPRINGDC1 12321 2005-05-27 12:40:46 100001 displayName

12320 Default-First-Site-Name\TSPRINGDC1 12320 2005-05-27 12:40:46 100001 showInAdvancedViewOnly

37122 Default-First-Site-Name\TSPRINGDC1 37122 2006-11-09 19:00:42 100003 nTSecurityDescriptor

12320 Default-First-Site-Name\TSPRINGDC1 12320 2005-05-27 12:40:46 100001 name

12322 Default-First-Site-Name\TSPRINGDC1 12322 2005-05-27 12:40:46 100003 userAccountControl

12321 Default-First-Site-Name\TSPRINGDC1 12321 2005-05-27 12:40:46 100001 codePage

12321 Default-First-Site-Name\TSPRINGDC1 12321 2005-05-27 12:40:46 100001 countryCode

12321 Default-First-Site-Name\TSPRINGDC1 12321 2005-05-27 12:40:46 100001 homeDirectory

12321 Default-First-Site-Name\TSPRINGDC1 12321 2005-05-27 12:40:46 100001 homeDrive

12323 Default-First-Site-Name\TSPRINGDC1 12323 2005-05-27 12:40:46 100001 dBCSPwd

12321 Default-First-Site-Name\TSPRINGDC1 12321 2005-05-27 12:40:46 100001 scriptPath

12321 Default-First-Site-Name\TSPRINGDC1 12321 2005-05-27 12:40:46 100001 logonHours

12321 Default-First-Site-Name\TSPRINGDC1 12321 2005-05-27 12:40:46 100001 userWorkstations

12323 Default-First-Site-Name\TSPRINGDC1 12323 2005-05-27 12:40:46 100002 unicodePwd

12323 Default-First-Site-Name\TSPRINGDC1 12323 2005-05-27 12:40:46 100002 ntPwdHistory

12323 Default-First-Site-Name\TSPRINGDC1 12323 2005-05-27 12:40:46 100002 pwdLastSet

12321 Default-First-Site-Name\TSPRINGDC1 12321 2005-05-27 12:40:46 100001 primaryGroupID

12324 Default-First-Site-Name\TSPRINGDC1 12324 2005-05-27 12:40:46 100001 supplementalCredentials

12321 Default-First-Site-Name\TSPRINGDC1 12321 2005-05-27 12:40:46 100001 userParameters

12321 Default-First-Site-Name\TSPRINGDC1 12321 2005-05-27 12:40:46 100001 profilePath

12320 Default-First-Site-Name\TSPRINGDC1 12320 2005-05-27 12:40:46 100001 objectSid

12424 Default-First-Site-Name\TSPRINGDC1 12424 2005-05-27 12:56:07 100001 adminCount

12321 Default-First-Site-Name\TSPRINGDC1 12321 2005-05-27 12:40:46 100001 comment

12321 Default-First-Site-Name\TSPRINGDC1 12321 2005-05-27 12:40:46 100001 accountExpires

12323 Default-First-Site-Name\TSPRINGDC1 12323 2005-05-27 12:40:46 100002 lmPwdHistory

12320 Default-First-Site-Name\TSPRINGDC1 12320 2005-05-27 12:40:46 100001 sAMAccountName

12320 Default-First-Site-Name\TSPRINGDC1 12320 2005-05-27 12:40:46 100001 sAMAccountType

12401 Default-First-Site-Name\TSPRINGDC1 12401 2005-05-27 12:41:41 100001 servicePrincipalName

12320 Default-First-Site-Name\TSPRINGDC1 12320 2005-05-27 12:40:46 100001 objectCategory

12320 Default-First-Site-Name\TSPRINGDC1 12320 2005-05-27 12:40:46 100001 isCriticalSystemObject

The above version numbers show that I’ve marked that object authoritative once since we know that we increment the version numbers by 100,000 when we mark an object authoritative.

Now, how do you workaround this? Here’s how:

First, you can use IP address in your MSTSC only. This will circumvent that access check, but may provide less security since it will not be using Kerberos for the authentication in that instance.

Second, you can alter the RDP connection to behave more like the prior version of our terminal services client. Here’s how to do that.

1. Go to StartàRunàMSTSC.

2. Type in the name of the “server” Vista computer you would like to connect to and then Save the RDP.

3. Open the RDP file you just save with Notepad.

4. Alter the line that says “authentication level:i:2” so that the 2 is a 0 like this “authentication level:i:0” (Without the quotes. This prevents the new TS client version from checking for Server Authentication).

5. Add “enablecredsspsupport:i:0” (without the quotes) to the end of the file. (This bypasses entering user credentials prior to creating the connection. The host pc will still prompt for credentials as normal).

6. Save the file.

7. Whenever you want to connect to that Vista computer from Vista use that RDP file to connect.

I want to give homage to my colleague engineers who actually worked this issue (credit where credit is due):

Brian “Loner” Singleton

Paul “The Hut” Hutmacher

Ned “Gomer” Pyle

Thanks guys! As always, please post if you have comments or questions, or email me via the blog. Take care everyone till next time!

Certificate Web Enrollment from Vista

Tim Springston — Thu, 05 Apr 2007 03:29:00 GMT

One of the enhancements in Windows Vista is the new certificate scripting interface called certenroll. In prior client operating system versions we had the xenroll code which would allow users to enroll for certificates via a web page served out by their Windows Server 2003 certificate authority. For Vista and Longhorn, though, a need was seen to enhance the functionality and ease of development in the certificate APIs. It ended up being a radical, but vastly improved, certificate enrollment API simply called Certenroll.

From a file level, you have xenroll.dll on Server 2003 and XP as the resource DLL to be used. Vista and Longhorn use certenroll.dll instead.

Here’s the MSDN start page on the new certificate services interface:

Certificate Enrollment API

http://msdn2.microsoft.com/en-us/library/aa374850.aspx

With all this new and easy to use functionality comes an issue that some folks may have to deal with. Basically, the Windows 2000 and Server 2003 certificate authority web enrollment pages will not allow a Vista client to enroll for a certificate. The fundamental difference is simply the difference in the enrollment interfaces.

Does this mean that certificate web enrollment isn’t an option from Vista clients? Emphatic no! But it does mean that you have some additional considerations to take into account.

We have a published Knowledge Base article on this (below) but I think that getting the word out a bit more on some details would be helpful for everyone.

How to use Certificate Services Web enrollment pages together with Windows Vista

http://support.microsoft.com/kb/922706

The article basically describes the problem and says that you need to remove your Windows Server 2003 CA web enrollment pages in favor of the ones from a Longhorn Server.

Wait! you say. Longhorn isn’t even released yet! How can I get those pages when they aren’t even available?

We have a hotfix package available as a free (my favorite word) download from our web site.

Just go here and use the KB article 922706 as the reference: https://support.microsoft.com/contactus2/emailcontact.aspx?scid=sw;en;1410&WS=hotfix

Here are few caveats or things to keep in mind about the Longhorn Certificate Enrollment pages that may not have been clearly spelled out in the Knowledge Base article:

-The Longhorn pages support web enrollment requests from 2003 and XP clients as well as Vista (xenroll as well as certenroll)

-The article says that you must use a specific version of the Longhorn pages. Rest assured, if we provide them to you they’re the right ones.

-Enroll on Behalf of (this may be available in Vista SP1) is not present in the Longhorn pages

-Enrolling computer certificates is not possible currently (part of the enroll on behalf of difference)

For folks out there who have heavily customized web enrollment pages I encourage you to contact us, obtain the Longhorn pages and then alter that code as needed to replicate what you need for your purposes.

Special thanks to my colleague Seth Scruggs for some of the above bullets.

We welcome feedback on this, so please post a comment if you’d like. If you have questions on this, please also post.