Active Directory Blog : 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)

Taking Out The Trash

Tim Springston — Tue, 24 Mar 2009 18:38:00 GMT

There will be times when you have to make big changes in your Active Directory. Sometimes those big changes mean deleting a lot of objects. I’ve personally needed to match customer environments by creating tens of thousands of AD objects just to have...(read more)

VSS Snapshots and You

Tim Springston — Mon, 23 Feb 2009 17:01:09 GMT

I find myself doing blog posts on things that are not frequent enough for most experienced admins to be aware of since it wouldn’t come across their desk often. The reason for that is that in my role I receive the least common unresolved issues...(read more)

Tabula Rasa

Tim Springston — Wed, 14 Jan 2009 17:15:00 GMT

I was well and truly stumped a few months ago. I joke that once a year I am flat out wrong, and rarely do I have nothing to say on a subject. The 'once a year I may be flat out wrong' statement may be true simply because after 15 years in the IT industry...(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)

Dude, where's my PAC?

Tim Springston — Mon, 21 Jan 2008 17:20:00 GMT

Something that is becoming more prevalent over the past few years has been great investments into our security technologies for application oriented reasons. Impersonation, people, that’s what I’m talking about. If anyone ever asks you what the big deal...(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.

Active Directory in Longhorn Server

Tim Springston — Wed, 14 Feb 2007 07:29:00 GMT

Recently I posted saying that I’d give a preview of Longhorn Server Active Directory. Well, here it is. I will caution all who read this to take into account that we are still in a beta production phase, so some or all of these items could change (or perhaps not make it in the product if they don’t meet the high bar of testing we have) before Longhorn is released to manufacturing and available for your servers. After hearing about the features it will have, though, I strongly suspect that you’ll really want everything to be in the final product as is and in full force. So, let's get started.

Roles

Services in Longhorn are all about roles, which can be loosely defined as sets of features that provide services. Active Directory Services is one role, as is Directory Lightweight Services or LDS (previously known as ADAM). If you’ve been doing your reading then you about Server Core. ADS, LDS and DNS are all installable on Server Core Longhorn installs. In all except for Server Core, roles will be added via Server Manager as a central snapin interface. Look for wizards taking you on through the addition of the role and the specifics of what will be needed to install as you need.

Read-Only Domain Controllers (RODCs)

Longhorn will add a new type of domain controller: RODC. This is a DC which has a read-only copy of the domain partition it is a DC for. The RODC will host an abbreviated copy of the domain partition and will, by default, not host passwords. It can be set to host those as well if you choose. No changes will be written on the RODC, not for SYSVOL and not for AD. All changes (updates, really) will come from other, writable, Longhorn DCs.

The RODC is designed to be provide a smaller security silhouette as well as less manageability concern for smaller, remote business locations and branch offices. RODCs will need Windows 2003 forest functional level (they use LVR), and require at least one Longhorn DC (not RODC) for their own domain to replicate from. From what I understand, Read-Only Partial Attribute Set (PAS) for RODC will be published to MSDN’s schema repository in the same way GC PAS (isMemberOfPartialAttributeSet) items are for reference purposes, and utilizable in a similar manner for your schema. For now, expect frequently accessed attributes to be the defaults as present objects and attributes on a RODC.

As an additional security enhancement the Krbtgt account, used for issuance of TGTs to domain principals (users, computers and the like), will be unique to each RODC. Group membership, useraccountcontrol value and other unique domain controller details will be different for RODC accounts-no “strong” security group memberships like Enterprise Domain Controllers, for example.

RODC replication will be unidirectional with all changes flowing into the RODC from a full writable Longhorn DC of the same domain.

Admin role separation will allow you to make a “branch office admin” capable of administering all aspects of the RODC without fear of compromising your domain, forest or enterprise.

The ADPREP process is essentially the same as in Server 2003 where the domain and forest must be prepared for the introduction of the first Longhorn DCs. The exception is for RODCs: first addition of an RODC will require a /RODCPREP action-but not necessary if you decide not to add RODCs.

DCPROMO

DCPROMO has been lifting weights. Everyone is familiar with the unattended install options where you can provide an answer file to automate the promotion that we’ve had. Longhorn builds on this. For one thing, when you complete a promotion, you can choose to export the selections you chose in that promotion to an answer file for use with other similar promotions-all with the press of a button.

DCPROMO will also have the ability to use NTDSUTIL to create “seed” media for IFM (install from media) DCPROMOs, sanitized for RODC IFM specifically (if you choose), no passwords, or other sensitive data present.

Prestaging of DC accounts will also be an option. You can run through DCPROMO to add a new DC (from another machine), then later rerun it from the actual machine you mean to promote. This can help for RODC installs or if you’d like to prestage (and thereby limit) other particulars of the new DC’s details (like name or site for example).

Enhanced Reliability

DC promotions and demotions previously required reboots for nearly every step. Efforts have been made to reduce the need for reboots for most actions. In addition, Active Directory is a discrete, restartable or stoppable service on the DC in Longhorn. In prior versions you could attempt to prevent some actions (like authentication or replication) by stopping the netlogon service, but this would not necessarily prevent all services from doing their jobs (like FRS for example). Not with Longhorn-just stop the service for downtime if needed or to apply a fix.

Under the hood there is some added error correcting for some less common database page checksum problems which can occur. Also, instead of FRS replication will be DFSR, with the compression it provides, as the new method for replicating SYSVOL to all replicas, including RODCs.

Disaster Recovery

An extremely cool concept: the Snapshot Browser. This is the idea of using Volume Shadow Copy to do a snapshot of your directory and to store that info in the living AD as a reference for comparison purposes. Though not a backup tool itself, this technique can be used to compare items following the recovery from a disaster to verify that all is as it was before the disaster. The idea would be to take a snapshot using NTDSUTIL (which could be batched and ran periodically as a task) and be able to query it using traditional tools like ADSIEDIT.MSC or via a LDAP querying tool or method. There’s also some discussion of a snapshot browser tool for selecting to “undelete” some objects if you aren’t in a full “restore everything” true disaster situation.

Globalization and Standards

Longhorn ADS will support IPV6 inherently for all roles (DNS Server, ADS, LDS et cetera). For folks in regions it will be helpful in, phonetic sorting in the directory is being added (for language usage in Japanese for example).

DNS Server

AD will continue to rely on DNS and so some focus has been on making that experience better as well. A new “Instant On” feature will prevent advertisement delays and service startup timing issues. Another consideration is single label domain names being supported by use of a new “Global Names Zone”.

Also…teasers…

Improved directory auditing

DC locator site locality enhancements

So there we have a good overview of what you can expect with Longhorn AD. It is not a comprehensive list (there’s more), but I hope it wets your appetite.

Now, let’s all recite the Microsoft blog poster mantra together:

These postings are provided "AS IS" with no warranties, and confer no rights.

I encourage you all to provide feedback on these features, as well as the accidental object deletion feature discussed in my prior post this month. Your opinions matter, and your help is appreciated. You can email me directly from this blog, or post your comment.

On a final note, it’s Valentine’s Day here in the USA, so I hope everyone has a significant other to enjoy the holiday with-Happy Valentine’s Day!