Active Directory Blog : Vista

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)

Thoughts on Single Sign On and Credential Providers

Tim Springston — Tue, 26 May 2009 19:35:26 GMT

We use the term single sign on (SSO) to describe a variety of behaviors in Windows and other applications where the result is simply to prevent the user from being prompted to provide their credentials again and again; to ideally enter their credentials...(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)

The Domain Logon Dialogue

Tim Springston — Fri, 04 Jan 2008 17:21:00 GMT

Happy New Years everyone! Let’s start the year off with a less strenuous article regarding how the domain logon list gets populated. I’m talking about the user logon dialogue which you see following pressing control, alt and delete at the same time. There...(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)

All The Logging In The World

Tim Springston — Mon, 08 Oct 2007 19:40:00 GMT

There’s normal troubleshooting and then there’s the stuff you do when the basic troubleshooting doesn’t get things resolved. Normal troubleshooting can be things like selecting “last known good” on a reboot after installing a new driver and having a blue screen. Or perhaps uninstalling and then reinstalling an application, or altering settings for the application or operating system to alleviate a problem. Sometimes we have to dig in and find out more. Many admins out there in the world live that every day. Which is why we add methods to find out more into our products. This post is all about listing all of the data gathering methods that a Directory Services person may ever need to know. Since there are so many it will be difficult to organize well in one uber post but I’m going to put out here for you all anyway, disorganized or not....(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!

Vista Issue: Time Skew Error When Logging on Across a Trust

Tim Springston — Fri, 25 May 2007 01:53:00 GMT

One of the cool things about this job is the way we get to trail blaze new issues as they happen and before any solution or workaround is in sight. We’re the pioneers in a way. This is one example.

We’ve had a few customer’s recently mention that they had seen an odd behavior from their Vista clients. When their environment fit certain criteria they found that the Vista workstations could not successfully log into the domain. Those criteria were: logging in across a trust (where user account was in one domain, computer account in another), the workstation was Windows Vista (didn’t occur on other operating system clients of the same domains), and the users account properties in AD were set to “do not require Kerberos preauthentication”. Removing the “do not require Kerberos preauthentication” check box from the user properties would make the problem magically disappear.

So, when a user tried to logon to that “accounts” domain in this manner they would fail to logon successfully and would instead get a message with a white X in a red circle that said “There is a time and/or date difference between the client and server”. This would occur when no significant time difference existed. Keep in mind that the allowed skew (difference in time) here is by default 300 seconds, or 5 minutes.

At first I thought this was simply a result of some uniqueness in their environment, like a custom password filter, since we have seen some surprising behaviors from custom code like that in the past. However, all of our testing resulted in that not being it.

Next, I explored the thought that perhaps this has to do with a new feature in Windows Vista. Specifically, the fact that Vista clients do not automatically send their pre authentication data to the KDC during the initial TGT request traffic (or AS_REQ for your die-hard Kerberos folks out there). This is intentionally done as a method to negotiate using the highest level of encryption that Vista can support to encrypt that preauth data with. Namely, Advanced Encryption Standard (AES). The way this goes is that the DC responds with an AS_REP with the KDC_ERR_PREAUTH_REQUIRED error as well as a list of the encryption methods which the DC supports. For Longhorn DCs the response will also include AES, so when the Vista workstation sees that it resends the AS_REQ-with preauthentication data this time!- but it encrypts it using AES which it now knows the KDC supports. For non-Longhorn DCs it simply resends the AS_REQ encrypted using one of the encryption methods supported by that responding DC.

Sadly, that was not the origin of this little gem of a problem.

Then we discovered that we could reproduce this in our own test environments. Quell surprise that was. This led to a few other revelations, like there is one other unique circumstance needed, in addition to those we already knew about. Namely, if you have a later version of KdcSvc.dll on your Server 2003 domain controller then you will not see this behavior. We found that a security update, and Server 2003 Service Pack 2 includes a newer version of KdcSvc.dll as well, and that also prevents this issue.

So, what do you do if you see this in your environment?

· First, check the time on workstation and server with Mark One Eyeball to make sure that there isn’t in fact any time or date difference.

· Second, makes sure this only occurs for Vista clients.

· Third, verify that the “do not require Kerberos preauthentication” check box is set on the user experiencing the problem, and that deselecting it and logging on as that user makes issue go away.

· Finally, check the version of KdcSvc.dll on the accounts domain (domain where the user account resides). You can do this by going to StartàRunàMSINFO32. Once System Information is open, go to Software EnvironmentàLoaded Modules and look for KDCSVC.DLL.

If you have this version or earlier on your “accounts” domain domain controllers then we would expect you to see the problem occur in this scenario:

kdcsvc 5.2.3790.1830 (srv03_sp1_rtm.050324-1447) 213.50 KB (218,624 bytes) 5/14/2007 5:22 PM Microsoft Corporation c:\windows\system32\kdcsvc.dll

If you have the security update below, or the SP2 version of the file then you should not see this issue:

Security update For Windows Server 2003 KB899587

kdcsvc 5.2.3790.3959 (srv03_sp2_rtm.070216-1710) 214.50 KB (219,648 bytes) 5/11/2007 2:21 PM Microsoft Corporation c:\windows\system32\kdcsvc.dll

Solution then is to update your accounts domain DCs with the latest version of kdcsvc.dll.

***Note: The time and date above are not indicative of version and "newness" of the file. Only the file version and "tree" info (such as 5.2.3790.3959 (srv03_sp2_rtm.070216-1710)) are the valid things to look at. Thanks to my colleague Robert Stampfer in Germany for pointing that out.***

In the off chance that the customers who experienced this issue in their environment see this blog post I’d like to give a big thank you for all of your patience on this issue.

Stay tuned for the next post folks-it’s another unique Vista issue and just as interesting!

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.

How To Cut Down On User Account Control Prompting

Tim Springston — Fri, 23 Mar 2007 22:46:00 GMT

We’ve had a few customers tell us that they would really like to not be prompted in application launch scenarios with some applications. There are some valid reasons why this may not be entirely helpful and reduction in clickage can be good when it doesn’t lessen security.

Say you logon with Group Policy Creator Owner domain security group privileges. If that is the only elevated, or most privileged, security group you have membership to then opening regedit.exe with your standard credentials (saying “don’t elevate” essentially) shouldn’t be a big concern right? Since the security group that got UAC to give you a split token logon doesn’t give you additional privileges to do things with the registry. But you get prompted anyway, every time you open regedit.exe with UAC enabled.

So you may want to make it so that you aren’t prompted for that application and maybe some others. Barring turning off User Account Control what option do you have?

Well, here it is. You’ve got to create a little “shim” and apply it. It’s not difficult and it does the job nicely. Keep in mind that if you do this you will need to right-click the program and choose “Run as administrator” ever after if you want that application to run with high privileges-so this could really impair an application that must have those credentials to run properly. So choose wisely on when to do this, and test it first before deploying to your users!

Here are the steps:

1) Download and install the Application Compatibility Toolkit (link below).

2) Open the Compatibility Administrator application with elevated credentials.

3) In the left hand pane, right-click on the database under Custom Databases and select Create NewàApplication Fix

4) Enter the name and other details of the application you want to alter behavior on and then browse to it to select it.

5) Click Next until you are in the Compatibility Fixes screen.

6) To prevent being prompted to elevate an application (which means that it will always use the less privileged credential to run) place a checkmark next to RunAsInvoker.

7) Click Next and then Finish.

8) Select File and Save As. Save the file as a filename.SDB type file in a directory you will easily find it.

9) Copy the <filename>.sdb file to the Vista computer you want to alter the elevation prompt behavior on.

10) Open an elevated command prompt.

11) Run the command (without the quotes, assuming you copied the file to the Windows directory on C:): “sdbinst c:\windows\<filename>.sdb” and then press enter.

Microsoft Application Compatibility Toolkit 5.0

http://www.microsoft.com/downloads/details.aspx?FamilyId=24DA89E9-B581-47B0-B45E-492DD6DA2971&displaylang=en

More info on the other options you have in altering application launch behavior are available at the URL below:

Application Compatibility Feature Guide

http://www.microsoft.com/technet/desktopdeployment/bdd/standard/AppCompact_6.msp

I’ve got some really interesting (at least I think so) posts coming up folks-so stay tuned and as always let me know if you have any questions.