Friday Mail Sack – Missed Week Edition
Hiya folks, Ned again. The mail sack was a no-show last week since I was out of town; I hope you can find it in your heart to forgive me. If not… well, you get what you pay for. To make up for it, this one is longer than usual. Here are some interesting issues from the past two weeks (both from the Internet and internally too).
- DFSR and temporary files
- ADUC defaults
- Inter-CA communication
- Third party software recommendations
- Compatibility mode
Question
I’m replicating files with DFSR. I’ve found a large number of files that have had the TEMPORARY attribute set on them. I know that DFSR won’t replicate those files, so I am going to remove that attribute. What happens after I do that?
Answer
Short answer: they will replicate. :-)
Long answer: DFSR treats temporary files like they do not exist. This means if a file was normal and replicated between servers, then someone sets the temporary attribute on that file, it is no longer there as far as DFSR is concerned. When a file no longer exists, we treat it as - wait for – deleted! So the downstream servers from the originating change are going to delete that file.
Here is the debug log from the server where the temporary attribute was just set:
20100325 17:48:46.067 1836 USNC 2881 UsnConsumer::TombstoneOrDelete LDB Updating ID Record: <— Hmm, looks like it’s being treated as a deletion to me.
+ fid 0x700000000EB52 <— Note the File ID
+ usn 0xfa1ead8
+ uidVisible 1
+ filtered 0
+ journalWrapped 0
+ slowRecoverCheck 0
+ pendingTombstone 0
+ internalUpdate 0
+ dirtyShutdownMismatch 0
+ meetInstallUpdate 0
+ meetReanimated 0
+ recUpdateTime 20100325 21:47:46.739 GMT
+ present 0
+ nameConflict 0
+ attributes 0x20
+ ghostedHeader 0
+ data 0
+ gvsn {16EC84D2-ECEE-4E0D-B6FA-0C4137F65EE4}-v277 <— Note the version
+ uid {F5C8EE4D-3C55-42A4-BB62-63F72E7EEBED}-v50
+ parent {780F3375-CDB0-4583-A3AE-85845086E884}-v1
+ fence Default (3)
+ clockDecrementedInDirtyShutdown 0
+ clock 20100325 21:48:46.067 GMT (0x1cacc64f1e63a10)
+ createTime 20100325 21:47:29.386 GMT
+ csId {780F3375-CDB0-4583-A3AE-85845086E884}
+ hash E30F7F47-58F6FE00-B9846C04-43B82E2A
+ similarity 00000000-00000000-00000000-00000000
+ name ohnoes!.txt <— Note the name
+
20100325 17:48:46.067 1836 USNC 2887 UsnConsumer::TombstoneOrDelete ID record tombstoned from USN_RECORD:
+ USN_RECORD:
+ RecordLength: 96
+ MajorVersion: 2
+ MinorVersion: 0
+ FileRefNumber: 0x700000000EB52 <— Same FID
+ ParentFileRefNumber: 0x1AD000000008E29
+ USN: 0xfa1ead8
+ TimeStamp: 20100325 17:48:46.067 Eastern Standard Time
+ Reason: Basic Info Change Close
+ SourceInfo: 0x0
+ SecurityId: 0x0
+ FileAttributes: 0x120 <— This is 0x20 && 0x100, which is a file with the archive bit and the temporary attribute set. Testify!
+ FileNameLength: 30
+ FileNameOffset: 60
+ FileName: ohnoes!.txt <— Same name
20100325 17:48:46.114 2304 JOIN 1244 Join::SubmitUpdate Sent: uid:{F5C8EE4D-3C55-42A4-BB62-63F72E7EEBED}-v50 gvsn: {16EC84D2-ECEE-4E0D-B6FA-0C4137F65EE4}-v277 name:ohnoes!.txt connId:{2F726EBA-3970-4AA5-AD23-4C07600CE427} csId:{780F3375-CDB0-4583-A3AE-85845086E884} csName:condelrf <— Same name, same version being sent to the server’s partner. Since the last operation was delete, guess what we’re telling the other server to do?
Then later, I remove the temporary attribute:
20100325 17:49:07.523 1836 USNC 2703 UsnConsumer::CreateNewRecord LDB Inserting ID Record: <— Well hello there! Just like a new file got added. It will replicate out momentarily…
+ fid 0x700000000EB52
+ usn 0xfa1eb98
+ uidVisible 0
+ filtered 0
+ journalWrapped 0
+ slowRecoverCheck 0
+ pendingTombstone 0
+ internalUpdate 0
+ dirtyShutdownMismatch 0
+ meetInstallUpdate 0
+ meetReanimated 0
+ recUpdateTime 16010101 00:00:00.000 GMT
+ present 1
+ nameConflict 0
+ attributes 0x20
+ ghostedHeader 0
+ data 0
+ gvsn {16EC84D2-ECEE-4E0D-B6FA-0C4137F65EE4}-v278
+ uid {16EC84D2-ECEE-4E0D-B6FA-0C4137F65EE4}-v278
+ parent {780F3375-CDB0-4583-A3AE-85845086E884}-v1
+ fence Default (3)
+ clockDecrementedInDirtyShutdown 0
+ clock 20100325 21:49:07.523 GMT (0x1cacc64feb0277e)
+ createTime 20100325 21:49:07.523 GMT
+ csId {780F3375-CDB0-4583-A3AE-85845086E884}
+ hash 00000000-00000000-00000000-00000000
+ similarity 00000000-00000000-00000000-00000000
+ name ohnoes!.txt
Craig Landis has written all kinds of interesting stuff about the temporary file attribute and DFSR in this old blog post here and now in the new TechNet Wiki here. Maybe someone will update the Wiki with this new tidbit? Hmmm…. could be you!
Question
Is there a way to make the “AD Users and Computers” snap-in (DSA.MSC) always open in “Advanced Features View” by default? I can’t find any command-line switches or registry settings that handle this scenario.
Answer
Oh MMC, how you taunt us. ADUC stores all of its configuration info inside of a special (read: not well documented and highly proprietary) cache file in your profile. You can see it by opening this folder:
%appdata%\microsoft\mmc
Good luck reading the contents of the DSA file though. The setting is stored in there as binary goo. I suppose you could copy your cache file around from place to place and use that, but seems like it would be a rather risky operation with little gain over the the 2 seconds it takes to click:
Perhaps a better idea is to have an "Admin” Terminal Server that has all your favorite applications configured the way you like ‘em. Maybe even using RemoteApp.
Question
I am looking for documentation on how the Root CA communicates with the Sub CAs in a Microsoft PKI. Once the self-signed certificate has been put on the Root CA, is it enrolled or replicated to the Sub CAs? I guess the question is this: once the self signed certificate has been put on the Root CA is it enrolled or replicated to the Sub CAs? We have NPS installed and are using it as a Radius server for the AP's and Wireless LAN Controller. We have a 802.1x policy configured and have the NPS Server validating the wireless client. The client is getting a Wi-Fi policy and a PKI-Policy through a Domain Group Policy. In this environment the wireless clients are getting a certificate with a PKI Policy but when you look at the certificate on the laptop once the system has been logged on the certificate could be issued from any of the Sub CAs. Is this the normal process?
Answer
Root CAs and subordinate CAs don't "communicate" with each other in quite that fashion. In fact, the only time any user or computer (sub CAs included) would need to contact the Root CA, outside of management tasks, is if they wanted to request a certificate. Within the sphere of the Windows CA itself, the answer to your question is no, the root CA certificate is not automatically propagated to subordinate CAs. This task must be done via another process.
If the Windows root CA has been installed on a domain server then the CA will automatically publish its root CA into Active Directory. Every Windows workstation or server will automatically retrieve the root certificate once its presence is detected and thus trust the new CA. If the Windows root CA was installed on a non-domain server then the root certificate must be published to Active Directory manually. Since you mentioned that enrollment is occurring successfully, I don't believe that trusting the root CA is an issue for you.
The next thing to address is how Windows client select the CA from which they request a certificate. The following discussion assumes that CEP/CES has not been installed and that CAs are installed in Enterprise Mode. This process applies to any version of Windows from Windows XP onwards. First, there are two contexts in which certificates can be requested -- the user context or the local computer context. Users can request certificates manually via the Certificates MMC snap-in or the Web Enrollment pages, or certificates may be assigned by an Administrator and distributed by Autoenrollment. Computer certificates can also be requested manually by a local Administrator using the Certificates MMC snap-in, or also by Autoenrollment. Regardless of the context, or how enrollment occurs, the process is the same.
1. The Windows Certificate Client (WCC) queries Active Directory for a list of certificates for which the account (user or computer) has Enroll (or Autoenroll) permissions. This information may be cached in the registry, but is periodically refreshed.
2. The WCC then queries Active Directory for a list of available CAs in the forest. Each CA publishes an Enrollment Services object that holds the FQDN of the CA server and the list of templates available on that CA.
3. The list of templates and the list of CAs (and their configured templates) are combined to build a list of those templates for which the account has permission to request a certificate AND which are available on some trusted CA in the forest.
4. In the case of the Certificates MMC snap-in, this combined list is presented in the UI as a list from which the user can select. In the case of Autoenrollment, this list is compared against those templates assigned to the account via Group Policy.
5. Once a template and the CA have been selected, the public/private key pair is created, the request is generated, and the request is submitted to the CA. Depending on the template settings, the request may be fulfilled immediately or it may be pended so that the request can be manually approved.
What this means for you is that you need to determine the following:
1. Is the Root CA in Enterprise or Standalone mode? If the latter, it will not issue certificates based on templates which eliminates the ability to request certificates via the MMC, or through Autoenrollment.
2. Do you have a certificate template that you assign specifically through your PKI-Policy? If so, on which CAs is that template configured? Check the Certificate Templates folder in the Certificate Services snap-in. (HINT: If you don't have one, the CA is in Standalone mode.)
So, if your root CA isn't configured to issue certificates based on your PKI-Policy template, or is in Standalone mode, but your subordinate CAs *are* configured to issued certificates based on that template, then it's no surprise all the certificates you've looked at were issued from one of the subordinate CAs. Funnily, this is actually a good thing. The purpose of a root CA is to be a Trust Anchor for your entire PKI. It issues certificates to subordinate CAs, which in turn issue certificates to users and computers on your network.
If you want an old but still decent introduction to PKI concepts check out Microsoft Windows 2000 Public Key Infrastructure (https://msdn.microsoft.com/en-us/library/ms995346.aspx). If you want the latest and greatest info and a lot more depth, you should pick up the book "Windows Server 2008 PKI and Certificate Security" by Brian Komar (https://www.microsoft.com/learning/en/us/book.aspx?ID=9549&locale=en-us)
[If you can’t tell, this came from Jonathan, the man who never uses a sentence when a paragraph will do – Ned]
Question
Hey, there are a bunch of different companies that make software to do X. Can you recommend one?
Answer
Nope! If I recommend one over a bunch of others, the others can get really mad. And in case you haven’t noticed, we, ummm, get sued a lot. Even if the other ones don’t sue and only complain loudly over the Internet, and shaking that bush is a real no-no here in Support. So forgive us if we take a pretty hard line and recommend nothing.
I will say this: any good vendor will be more than happy to let you run a fully functional time-bombed trial edition and give things a whirl. An excellent one will let you access their online knowledgebase and support forums before you buy. I am always suspicious of those who do not want you to see any dirty laundry until the check has cleared. Everyone has a competitor; there are no real monopolies in the software world. Use that to your advantage when evaluating new products.
Question
On a Windows Server 2008 R2 computer I can only get back to Vista for compatibility mode (this computer is running some old stuff via remote desktop services). Why is this and is there a way to at least get back to XP mode?
Answer
You tricked yourself – it depends on the application architecture you are running:
![clip_image001[5]](https://msdntnarchive.blob.core.windows.net/media/TNBlogsFS/BlogFileStorage/blogs_technet/askds/WindowsLiveWriter/FridayMailSackMissedWeekEdition_102E1/clip_image001%5B5%5D.jpg "clip_image001[5]")
The one on the left is a 32-bit program. The one on the right is a 64-bit program. Both are on the same computer. Win2008 R2 runs 64-bit only and when it comes to 64-bit programs, can only pretend back as far as Vista 64-bit RTM. If you need more than this you will need to pay a visit to the Application Compatibility Toolkit. Or, you know, upgrade your crummy old app… ^_^
Hey, sometimes the questions aren’t about DS necessarily. They just need to be interesting enough to make me care. In this case I had no idea, had to figure it out.
Until next time.
- Ned “get to da choppah!” Pyle