Microsoft's official enterprise support blog for AD DS and more
Hello all, Ned here again. I have returned from Christmas and New Years and laser eye surgery. A Friday Mail Sack is in your future.
Thanks Sean, I missed you too
- Ned “call -151 * p” Pyle
Updated to include SP1 being RTM and some last minute fixes that were included post RC
Hi all, Ned here again. Back in October I joined the Windows Server 2008 R2 Service Pack 1 beta support team. Our job is to support customers in a special early adopters program. As SP1 has now released, I’m frequently asked about what changes were added for Directory Services. Today I address some specifics:
Remember, the QFEs listed below are all publically available, so if you are skimming the list and have a “oh heck, we’re having that issue” moment you can install anytime. Some of these issues are preventable as well so use your best judgment – an update to prevent NTFS corruption doesn’t fix the damaged files, after all.
Release the Kraken!
This scenario referenced by the release notes refers to:
You cannot create or delete managed service accounts in a perimeter network in Windows 7 or in Windows Server 2008 R2 - http://support.microsoft.com/kb/978836
In this case you have RODCs in a network that users can directly access, but those same users cannot access writable DCs (a DMZ or oddly configured branch office). After you apply SP1 the RODC will know how to forward the request on to a writable DC for MSA operations.
To fix it is install SP1 (or that hotfix) on all your RODCs.
A time-out error occurs when many NTLM authentication requests are sent from a computer that is running Windows Server 2008 R2, Windows 7, Windows Server 2008, or Windows Vista in a high latency network - http://support.microsoft.com/kb/975363
This one is more complicated. Netlogon has a "throttle" that controls the maximum number of simultaneous calls over a secure channel. On DCs this includes the secure channels of external trusted domains (i.e. not Kerberos forest trusts). On member computers this is to authenticating DCs for intra-forest requests or requests to other domains/forests. On high latency networks with a ton of NTLM authentication, applications could start having issues authenticating, ranging from slow performance to errors. MaxConcurrentAPI controls this through a registry value:
Key path: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters Value Name: MaxConcurrentApi Data Type: REG_DWORD
The default value if this registry value name does not exist is 1 if a DC, 2 if a member server, and 1 if a client – it has been since NT 4.0 and that has never changed. Until this update is applied, the maximum value is 10. After the update is installed, the maximum value is 150. Generally speaking, since DCs are authenticating users and most companies are not heavily using local member accounts, it only needs to be set on domain controllers.
For all those folks that got scared when we recommended setting the value to 10 in order to fix your issue, this is the proof that you were being paranoid. :) You will see more DC memory usage when you raise the value, but your alternative is obviously far worse.
This has no effect on Kerberos at all and Kerberos is not restricted in this fashion. If you’re using NTLM unnecessarily (misconfigured app, older version app, crummy app, external trust instead of forest trust, etc.) then getting Kerberos in gear is a much better solution than registry band-aids.
There are 795 public fixes that were rolled into SP1 and they’re all listed here:
Hotfixes and Security Updates included in Windows 7 and Windows Server 2008 R2 Service Pack 1.xls
Of these, 104 can be considered “pure” Directory Services updates if you go off the list of what gets supported by the DS team here in Microsoft. Another 59 updates fix things that victimize DS – stuff like networking, file system, SMB, or backups. There are other fixes in SP1 as well. Sometimes issues never get public attention or a QFE would be too expensive or risky; service pack testing is far more comprehensive. I’m not including security updates, you already have those from Windows Update (right?!)
There are some fairly interesting new things here besides the two arbitrary ones in the release notes, I recommend giving these tables a look. For example:
And the issue you are least likely to hit?
KB980598 - Windows Server 2008 R2 cannot be installed or started on a computer that has 1 TB or more of RAM
Holy Schnike, I wish I had that “problem”…
Until next time.
- Ned “640GB ought to be enough for anybody” Pyle
Hello, Dave here. Today I discuss the Access Based Enumeration (ABE) feature in Windows Server and how it may be implemented with Distributed File System Namespaces (DFSN).
First you may ask, "What is ABE, and why would I want to utilize it?" By default, all folders and files will be listed in a folder, even if the browsing user doesn't have permissions to them. For example, three users (Alice, Bob, and Cindy) have folders under a share on file server ‘FS1’.
Each user's folder has permissions such that only the single user has access (icacls.exe output below):
\\fs1\share\Alice CONTOSO\Alice:(OI)(CI)F \\fs1\share\Bob CONTOSO\bob:(OI)(CI)R \\fs1\share\Cindy CONTOSO\Cindy:(OI)(CI)R
The following is what user “Bob” observes when browsing the UNC path \\fs1\share:
If a user attempts to open another user's folder or file within that folder, they will be met with an error as they do not have sufficient permissions. Administrators may not desire this user experience, as it may generate helpdesk calls or confuse users.
ABE is Windows Server feature which causes the server to display only the files and folders that a user has permissions to access. Once ABE is enabled on the share mentioned above, users will only see those folders for which they have access. Below is Bob's view of the share's contents, now with ABE enabled:
ABE is enabled for non-DFS shares via the "Share and Storage Management" snap-in. You may be asking if this feature may be utilized by DFS Namespaces as well. Yes it can!
ABE in DFSN has matured considerably since its original implementation in Windows Server 2003. Back then, you had to install a separate add-on component to expose the necessary UI to configure ABE on a shared folder. Then, you had to follow KB article 907458 in order to make it functional within a DFS namespace. Further complications arose from having to utilize cacls.exe on each namespace server to set link permissions and having to repeat the operation should the namespace be modified in various ways. To say the least, there was significant management overhead.
Fortunately, Windows Server 2008 and 2008 R2 supports ABE in DFSN natively. It may be utilized on a domain-based or standalone namespace such that users will only see DFSN folders for which they have permissions. NOTE: ABE requires the namespace to be in "Windows Server 2008 Mode". If you have existing namespaces that are in "Windows 2000 Server mode" (view the properties of a namespace in the DFS Management snap-in), you will need to convert them to 2008 mode. To do so, please follow the information available here.
As an example, the namespace “ns1” was created and contains DFSN folders for the three user folders discussed previously.
The DFSN folder “Bob” is configured with the target \\fs1\share\bob, as seen below:
By default ABE is not enabled on the namespace, and users are able to see all DFS folders within it. When Bob browses the namespace via the path \\contoso.com\ns1, he will see the three DFS folders defined above: Alice, Bob, and Cindy. By enabling ABE on the namespace, the DFSN service of all namespace servers will automatically enable ABE on their local namespace share and enforce the configured permissions of reparse folders automatically. You will not be burdened with having to run cacls.exe manually on each namespace server.
The commands utilized to enable ABE and set the required permissions are as follows:
dfsutil property abde enable \\contoso.com\ns1 dfsutil property acl grant \\contoso.com\ns1\alice contoso\alice:F protect dfsutil property acl grant \\contoso.com\ns1\bob contoso\bob:F protect dfsutil property acl grant \\contoso.com\ns1\cindy contoso\cindy:F protect
Note: The 'protect' parameter is important as the reparse folders underneath the namespace shared folder will inherit permissions by default and typically not restrict access to the DFSN folders. Also, the “abde” parameter was changed to “abe” in the 2008 R2 and Windows 7 version of dfsutil.
With a Windows 7 client or a 2008 R2 server running RSAT, enabling ABE and setting permissions may be directly performed via the DFS Management MMC. Simply open the properties of a specific DFS folder in the namespace and click the ‘advanced’ tab:
Bob would have the following view of the “NS1” namespace after ABE is enabled and appropriate permissions are set:
In the end, the permissions configured within the namespace ultimately end up on the special reparse folders found within the namespace server's share. It is the enumeration of these reparse folders which dictates if a DFSN folder is observable by a user as they browse through the namespace.
One final note: some DFSN administrators may wish to leverage ABE with a mixture of Windows Server 2003 R2 and 2008/2008 R2 namespace servers using the process detailed in KB 907458. Although possible, you must first deploy a hotfix to any Windows Server 2008 SP2 or 2008 R2 RTM/SP1 namespace servers to prevent the loss of the modified reparse folder permissions. Details about the update are available in KB 2464365.
I hope the information is helpful as you consider implementation of ABE on a DFS namespace. Happy DFSN'ing!
Dave “Honest ABE” Fisher
Hi all, Ned here again. The wonderful folks at RunAs Radio recorded a 30-minute audio interview with yours truly a few weeks ago and it’s now available for streaming and download. RunAs Radio is a weekly Internet audio talk show for MS IT Pros and has been around for almost four years. With nearly 200 broadcasts available as MP3 downloads, they are a great way to use your commute more productively than staring at tail lights.
In the interview I talk about DFSR migrations and other Microsofty stuff. I sound weird and cartoonish, but Richard sounds suave and professional.
Ned “a face for radio” Pyle
Hey all, Ned here again. Welcome back from Christmas, New Years, etc. Today we talk some BitLocker, SSL, DFS, FRS, MS news, and some geeky goo. Despite us being offline for the past few weeks, we weren’t deluged with new questions – glad you took some time off, you deserved it.
Yoink!
Is it possible to have the Windows 7 machines that have been BitLocker’ed before the AD DS backup was setup automatically check in and store their recovery information? I have seen the two manage-bde commands that are needed but I was wondering if there was a script somewhere that could run at logon or system start up to register all those keys.
Yes, our sister site AskCore has a sample VBS you can use:
http://blogs.technet.com/b/askcore/archive/2010/04/06/how-to-backup-recovery-information-in-ad-after-bitlocker-is-turned-on-in-windows-7.aspx
Despite the security and AD nature of BitLocker, it is not supported by us in DS – instead, the core operating system team handles it, as they own storage. Punt!
Please summarize the support (or lack thereof) for receiving fragmented SSL/TLS handshake messages by OS version and service pack. Which, if any, service pack(s) of WinXP or Vista supports receipt of fragmented handshake messages? For each OS/version that supports receipt of fragmented handshake messages:
[From Jonathan, naturally]
Only Windows 7 and Windows Server 2008 R2 have support for SSL record fragmentation, and then only so far as to accept and coalesce fragmented records. This support was introduced in the RTM release, and does not require a service pack update. Previous Windows OS versions do not support SSL record fragmentation of any sort.
Per RFC 2246, message length is an unsigned 24-bit integer, so the maximum message length is 16,777,215 ((1<<24) - 1) bytes.
There is no size limit on a certificate itself, but there is a size limit on each individual extension. On Windows, the size of a certificate extension must not exceed 4096 bytes. For example, 151 25-character DNS name entries, plus the overhead for encoding (~2 bytes per name), comes in at 4,081 bytes, just under the 4KB limit.
Fragmented handshake records are supported (exceptions below), including the following cases:
The exceptions are:
I went to add a new server as a DFS replication partner and noticed that on the "Replication Folders" tab is now says "Not Published". I then looked at all the replication objects and they also say "Not Published". The strange thing is our namespaces is still responding and seems to be conforming to the rules in place. Should I go through and republish all the replication groups to the namespace? What would cause this type of thing to happen?
First, some background. The attribute msDFSR-Dfspath on that replicated folder in AD is what stores a DFS Namespace path and lets the GUI populate those values. This is on the global DFSR RF “content” object within a given replication group. For example, a replicated folder named “primarybit” that exists in a replication group called “warrenpritest1” in the “Contoso.com” domain would show this:
Often though, no one ever set this value and it is only noticed a long time later – a problem that never was. :) The only way this normally gets set is if you use DFSMGMT.MSC to first create a DFS Namespace, create some links, then get prompted to configure replication (or if you create an RG and then select “share and publish in namespace”. If you just setup DFSR by itself, this field doesn’t get populated. It has no real effect on DFSR, DFSN, or end users – the field exists purely as a convenience to the administrator so that they know that the replication and namespace are related; just a visual thing for DFSMGMT.MSC.
You can edit the attribute manually to be the DFS Link path you want using ADSIEDIT, but I recommend instead using:
DFSRADMIN.EXE RF SET /RFDFSPath <other options>
Once that’s done it will all fill in:
If you want to see when it might have been deleted, you can use:
REPADMIN /SHOWMETA <DN of that content set>
It will show when they were modified:
[After a bit further chatting in the above Q & A]
It turns out that happened exactly when I migrated to 2008 mode in DFS. I wonder if I missed a step or something?
Ah! So that would be expected – when you “migrate” DFSN between modes you are actually recreating them from scratch. When the namespace is deleted that value is being cleaned out, but never put back – because the DFSN migration tools have no idea about DFSR at all. If you wanted to fix that as part of your migration, you can just add the DFSRADMIN command above to your steps.
I was using FRSDIAG to look at a system. The connstat.txt log file it created is blank. Do you know what can cause this?
Anything that makes the command NTFRSUTIL.EXE SETS not work normally will cause this; FRSDIAG just calls that command-line tool then parses the NTFRS_SETS.TXT output to make connstat.txt.
In this case it was FRS being in Journal Wrap. Since the NTFRS_SETS.TXT log only showed “DOMAIN SYSTEM VOLUME (SYSVOL SHARE) in state JRNL_WRAP_ERROR... DELETED REPLICA SETS” there was nothing useful to parse.
I’ve also seen it when a server had all of its FRS replica registry settings removed from under the Parameters registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets <-- gone
The service will start up and you will get an FRS event 13516. But then nothing will replicate ever. You will have to use a D2 non-authoritative restore to fix the server.
Want another way to know when the AskDS blog is updated? You can use the NetworkedBlogs Facebook App. This does not mean that I am going to create a Facebook account for myself. Not doing Twitter either. I got into computers 25 years ago to avoid being social.
On that subject, Mark sent in a link that any self-respecting geek should read: “Wake Up Geek Culture. Time to Die”. It’s written by Patton Oswalt, who is awesome and usually totally NSFW; in this case he kept it mostly PG. Just to prime the pump:
When our coworkers nodded along to Springsteen and Madonna songs at the local Bennigan’s, my select friends and I would quietly trade out-of-context lines from Monty Python sketches—a thieves’ cant, a code language used for identification. We needed it, too, because the essence of our culture—our “escape hatch” culture—would begin to change in 1987. That was the year the final issue of Watchmen came out, in October. After that, it seemed like everything that was part of my otaku world was out in the open and up for grabs, if only out of context. I wasn’t seeing the hard line between “nerds” and “normals” anymore. It was the last year that a T-shirt or music preference or pastime (Dungeons & Dragons had long since lost its dangerous, Satanic, suicide-inducing street cred) could set you apart from the surface dwellers. Pretty soon, being the only person who was into something didn’t make you outcast; it made you ahead of the curve and someone people were quicker to befriend than shun. Ironically, surface dwellers began repurposing the symbols and phrases and tokens of the erstwhile outcast underground. Fast-forward to now: Boba Fett’s helmet emblazoned on sleeveless T-shirts worn by gym douches hefting dumbbells. The Glee kids performing the songs from The Rocky Horror Picture Show. And Toad the Wet Sprocket, a band that took its name from a Monty Python riff, joining the permanent soundtrack of a night out at Bennigan’s. Our below-the-topsoil passions have been rudely dug up and displayed in the noonday sun. The Lord of the Rings used to be ours and only ours simply because of the sheer ******* thickness of the books. Twenty years later, the entire cast and crew would be trooping onstage at the Oscars to collect their statuettes, and replicas of the One Ring would be sold as bling.
When our coworkers nodded along to Springsteen and Madonna songs at the local Bennigan’s, my select friends and I would quietly trade out-of-context lines from Monty Python sketches—a thieves’ cant, a code language used for identification. We needed it, too, because the essence of our culture—our “escape hatch” culture—would begin to change in 1987.
That was the year the final issue of Watchmen came out, in October. After that, it seemed like everything that was part of my otaku world was out in the open and up for grabs, if only out of context. I wasn’t seeing the hard line between “nerds” and “normals” anymore. It was the last year that a T-shirt or music preference or pastime (Dungeons & Dragons had long since lost its dangerous, Satanic, suicide-inducing street cred) could set you apart from the surface dwellers. Pretty soon, being the only person who was into something didn’t make you outcast; it made you ahead of the curve and someone people were quicker to befriend than shun. Ironically, surface dwellers began repurposing the symbols and phrases and tokens of the erstwhile outcast underground.
Fast-forward to now: Boba Fett’s helmet emblazoned on sleeveless T-shirts worn by gym douches hefting dumbbells. The Glee kids performing the songs from The Rocky Horror Picture Show. And Toad the Wet Sprocket, a band that took its name from a Monty Python riff, joining the permanent soundtrack of a night out at Bennigan’s. Our below-the-topsoil passions have been rudely dug up and displayed in the noonday sun. The Lord of the Rings used to be ours and only ours simply because of the sheer ******* thickness of the books. Twenty years later, the entire cast and crew would be trooping onstage at the Oscars to collect their statuettes, and replicas of the One Ring would be sold as bling.
For the record, I know the last words of Roy Batty too and it sickens me.
Next, the best Kinect hack yet – Ultra Seven!
Definitely watch the whole thing. Hopefully there will be no Ultraman versus Spectreman slap fights in the comments section. Tokusatsu always seems to get people’s blood up.
If you don’t follow IO9 and Rock Paper Shotgun you are not maximizing your egghead quotient. They have started off the year with a few must-reads if you are a sci-fi or PC gaming spaz like myself:
There was plenty of interesting stuff at CES 2011, but the thing that caught my eye was the new Touch Mouse. How exciting can a mouse with no buttons be, right? Watch this video:
Finally, in case you missed it, we are going to start supporting System on a Chip RISC processors in the next version of Windows – specifically ARM. Everything old is new again! According to NVIDIA this is the end of Intel and AMD, but I wouldn’t start throwing away all your x86 motherboards just yet.
Ned “can you at least fry the chicken head?” Pyle
Quick update for everyone – there were two articles released last week:
KB
Title
2492852
SYSVOL Migrations from FRS to DFSR may fail when migrating on Windows Server 2008 SP1
2459083
Robocopy may report error 1338 "The security descriptor structure is invalid" or error 87 "The parameter is incorrect" when copying data from CIFS file servers.
Hi all, Ned here again. I’ve been asked a few times if other operating systems can utilize DFS Namespaces running on Windows Server. It’s a sticky wicket; as a “voice of Microsoft” my statements carry a lot of weight - deserved or not. It’s not smart or ethical for me to say that something not made by Microsoft works well, works better than something else, or doesn’t work at all. In some cases, lawyers may be summoned from Vhoorl.
With that in mind I am treading lightly. Feel free to discuss further vendor options in the comments area, we have that precedent.
An OS needs to implement a DFS client to use Namespaces. If the OS doesn’t provide one, you will have to find a third party. It’s one thing to support SMB/CIFS these days –it has become the de facto standard for file servers. But it’s something else to support DFS; this requires new logic and an understanding of the referral process.
Microsoft doesn’t make an out of band DFS client anymore, only the one that comes in Windows itself. Because of the requirement to use DFS in Active Directory (for SYSVOL and group policy processing), we have to guarantee an in-box client exists. We do this through the client redirector and a filtering driver called MUP.SYS. This diagram is a bit out of date but it gives you the gist:
Let’s talk about some others.
The current Mac OS is based on the UNIX XNU, Mach, and FreeBSD kernels. OS X implements SMB connectivity - but not through Samba. According to the Apple discussion forums, Apple uses a very old version of FreeBSD smbfs and while it lets you connect to a DFS path starting in 10.5, it does not understand permissions or allow you to access files.
You therefore need to purchase a 3rd party add-on. Apple lists a few on their website, so I consider that their answer and I don’t mind feeding you a search link:
http://www.bing.com/search?q=dfs+site%3Aapple.com%2Fdownloads%2F&form=QBRE&qs=n&sk=&sc=8-29
Make sure you read Apple’s fine print before you try to call them for support:
Apple is providing links to these applications as a courtesy, and makes no representations regarding the applications or any information related thereto. Any questions, complaints or claims regarding the applications must be directed to the appropriate software vendor.
I find a few more that are not listed by Apple:
http://www.bing.com/search?q=DFS+support+for+Mac+&form=QBRE&qs=n&sk=
As far as IOS 4.x native support goes, I found nothing at all. You will need a third party add-on to implement SMB/CIFS on iPad, according to Apple. No word on whether that means DFS too.
By some people’s definition the Linux Kernel does not have a remote file system (or a local file system); it’s all modular goo. In reality, people usually go through a specific distro and in some later kernels CIFS support is becoming standard . In nearly all cases you can use Samba, so I don’t mind pointing you to it:
Interestingly, Samba’s website also points to number of other CIFS clients, most of which no longer seem to exist (see the bottom of this page):
http://samba.org/samba/download/
There was also smbfs for Linux but it has been discarded and is no longer maintained (perhaps why Apple’s OS behaves as it does; from looking around this client is not being maintained in other OSs either).
Update: One of our awesome readers had some more distro-specific experience to share with us. Thanks Bill!
Red Hat added DFS support to their kernel-level CIFS driver in Red Hat Enterprise Linux version 5.3, though the feature was rather underreported (one of the few search results I found that reported the change was http://www.h-online.com/newsticker/news/item/What-s-new-in-Red-Hat-Enterprise-Linux-5-3-739737.html). Instructions for for testing it out are at http://blog.evad.info/2009/02/21/how-to-use-cifs-dfs-in-red-hat-enterprise-linux-53/. Apparently the code was checked in the Linux kernel in version 2.6.25 and is also available in the Ubuntu distribution as of version 8.10. I haven't gone back and tested it in quite a while, but from what I recall, it worked fine with stand-alone DFS namespaces; I never tested it with a domain-based namespace.
Google has not released Chrome OS as of this writing (it slipped to sometime in mid-late 2011). Chromium is an open source project you can build yourself but it is so new and so amorphous I can’t find any statements on its support of DFS or even CIFS/SMB. It’s based on BSD so one might assume it will implement smbfs (with the DFS limitations that this entails), but one hopes that Samba would be possible. With the coming of Android Honeycomb the future is looking cannibalistic so Chrome may never get the backing it needs to bother with DFS. And with both OSs being marketed in a very consumer-oriented fashion (much like Apple), your calls for DFS may end up falling on deaf ears. Let us know how it pans out.
Until next time,
Ned “it hurts when I do this” Pyle
Hi folks, Ned here again with your questions and our answers. This is a pretty long one; looks like everyone is back from vacation, winter storms, and hiding from the boss. Today we talk Kerberos, KCC, SPNs, PKI, USN journaling, DFSR, auditing, NDES, PowerShell, SIDs, RIDs, DFSN, and other random goo.
Rawk!
Is NIC teaming recommended on domain controllers?
It’s a sticky question – MS does not make a NIC teaming solution, so you are at the mercy of 3rd party vendor software and if there are any issues, we cannot help other than to break the team. So the question you need to answer is “do you trust your NIC vendor support?”
Generally speaking, we are not huge fans of NIC teaming, as we see customers having frequent driver issues and because a DC probably doesn’t need it. If clients are completely consuming 1Gbit or 10Gbit network interfaces, the DC is probably being overloaded with requests. Doubling that network would make things worse; it’s better to add more DCs. And if the DC is also running Exchange, file server, SQL, etc. you are probably talking about an environment without many users or clients.
A failover NIC solution is probably a better option if your vendor supports it. Meaning that the second NIC is only used if the first one burns out and dies, all on the same network.
We used to manually create SPNs with IP addresses to allow Kerberos without network name resolution. This worked in Windows XP and 2003 but stopped working in later operating systems. Is this expected?
Yes it is. Starting in Windows Vista and forever more, the OS examines the format of the SPN being requested and if it is only an IP address, Kerberos is not even attempted. There’s no way to override this behavior. If I look at it in practical terms, having manually set an IP Address for SPN:
Then I actually try mapping a driver here with an IP address (which would have worked in XP in this scenario):
No tickets were cached above. And in the network capture below, it’s clear that I am using NTLM:
This is why in this previous post – see the “I want to create a startup script via GPO” and “NTLM is not allowed for computer-to-computer communication” sections – I highly discouraged customers from this sort of hacking. What I didn’t realize when I wrote the old post was that I now have the power to control the future with my mind.
Actual MRI of my head, proving that I have an orange (i.e. “futurasmic”) brain
I see that the DFSR staging folder can be moved, but can the Conflict and Deleted (\dfsrprivate\conflictanddeleted) folder be relocated? If so, how?
It cannot be moved or renamed – this was once planned (and there is even an AD attribute that makes one think the location could be specified) but it never happened in the service code. Regardless of what you put in that attribute, DFSR ignores it and creates a C&D folder at the default location.
For example, here I specified a completely different C&D path using ADSIEDIT.MSC before DFSR even created the folder. Once I started the DFSR service, it ignored my setting and created the conflict folder with defaults:
We are trying to find the best way to issue Active Directory "User" certificates to iPhones and iPads, so these users can authenticate to our third party VPN appliance using their "user" certificate. We were thinking that MS NDES could help up with this. Everything I have read says that NDES is used for non domain "computer or device" enrollment.
[From Rob Greene, author of previous post iPad / iPhone Certificate Issuance]
Just because the certificate template that is used by NDES must be of type computer does not mean you cannot build a SCEP protocol message to the NDES Server for use by a user account on the iPhone in question.
Keep in mind that the SCEP protocol was designed by Cisco for their network appliances to be able to enroll for certificates online. Also understand what NDES means - Network Device Enrollment Service.
Realistically there is no reason why you cannot enroll for a certificate via SCEP interface with NDES and have a user account using the issued certificate. However, NDES is code to specifically only allow for enrollment of computer based certificate templates. If you put a user based template name in the registry for it to issue, it will fail with a not –so-easily deciphered message.
That said, keep in mind that the subject or Subject Alternative Name field identifies the user of the certificate not the template.
So what you could do is:
Now you have a certificate with the EKU of Client Authentication and a subject / SAN of the user account, I don’t see why you could not use that for what you need. Not that I have tested this or can test this, mind you…
Is there a “proper” USN Journal setting versus replicated data sizes, etc. on the respective volumes housing DFSR data? I've come across USN journal wrap issues (that properly self heal ... and then occur again a month or so later). I’m hoping to know a happy medium on USN journal sizing versus size of volume or data that resides on that volume.
I did a quick bit of research - in the history of all MS DFSR support cases, it was necessary to increase the USN journal size for five customers – not exactly a constant need. Our recommendation is not to alter it unless you get multiple 2202 events that can’t be fixed any other way:
Event ID=2202 Severity=Warning The DFS Replication service has detected an NTFS change journal wrap on volume %2. A journal wrap can occur for the following reasons: 1.The USN journal on the volume has been truncated. Chkdsk can truncate the journal if it finds corrupt entries at the end of the journal. 2.The DFS Replication service was not running on this computer for an extended period of time. 3.The DFS Replication service could not keep up with the rate of file changes on the volume. The service has automatically initiated the journal wrap recovery process. Additional Information: Volume: %1
Event ID=2202 Severity=Warning The DFS Replication service has detected an NTFS change journal wrap on volume %2. A journal wrap can occur for the following reasons: 1.The USN journal on the volume has been truncated. Chkdsk can truncate the journal if it finds corrupt entries at the end of the journal. 2.The DFS Replication service was not running on this computer for an extended period of time. 3.The DFS Replication service could not keep up with the rate of file changes on the volume. The service has automatically initiated the journal wrap recovery process.
Additional Information: Volume: %1
Since you are getting multiple 2202 occurrences, I would recommend first figuring out why you are getting the journal wraps. The three reasons listed in the event need to be considered – the first two are avoidable (fix your disk or controller and stop turning the service off) and should be handled without a need to alter the USN journal.
The third one may mean you are not using DFSR as recommended, but that may be unavoidable. In that case, set the USN size value to 1GB and validate that the issue stops occurring. We have no real formula here (remember, only five customers ever), but if you cannot spare another 512MB on the drive you have much more important problems to consider around disk capacity. If still not enough, revisit if DFSR is the right solution for you – the amount of changes occurring would have to be so incredibly rapid that I doubt DFSR could ever realistically keep up and converge. And make sure that nothing else is updating all the files outside of the journal on that drive – there is only one journal and it contains entries for all files, even the ones not being replicated!
Just to answer the inevitable question: you use WMI to increase the USN journal size.
On Win2003 R2 only:
1. Determine the volume in question (USN journals are volume specific) and the GUID for that volume by running the following:
WMIC.EXE /namespace:\\root\Microsoftdfs path DfsrVolumeInfo get VolumePath WMIC.EXE /namespace:\\root\Microsoftdfs path DfsrVolumeInfo get VolumeGUID
This will return (for example:)
VolumePath \\.\C: \\.\E:
VolumeGuid 4649C7A1-82D5-11DA-922B-806E6F6E6963 D1EB0B66-9403-11DA-B12E-0003FFD1390B
2a. Raise the USN Journal Size (for one particular volume):
WMIC /namespace:\\root\microsoftdfs path dfsrvolumeconfig.VolumeGuid="%GUID%" set minntfsjournalsizeinmb=%MB SIZE%
where you replace '%GUID%' with the volume GUID and '%MB SIZE%' with a larger USN size in MB. For example:
WMIC /namespace:\\root\microsoftdfs path dfsrvolumeconfig.VolumeGuid="D1EB0B66-9403-11DA-B12E-0003FFD1390B" set minntfsjournalsizeinmb=1024
This will return 'Property Update Successful' for that GUID.
2B. Raise the USN Journal Size (for all volumes)
WMIC /namespace:\\root\microsoftdfs path dfsrvolumeconfig set minntfsjournalsizeinmb=%MB SIZE%
This will return 'Property Update Successful' for ALL the volumes.
3. Restart server for new journal size to take effect in NTFS.
Update 4/15/2011 - On Win2008 or later:
1. Open Windows Explorer.2. In Tools | Folder Options | View - uncheck 'Hide protected operating system files'. 3. Navigate to each drive's 'system volume information\dfsr\config' folder (you will need to add 'Administrators, Full Control' to prevent access denied error). 4. In Notepad, open the 'Volume_%GUID%.xml' file for each volume you want to increase. 5. There will be a set of tags that look like this: <MinNtfsJournalSizeInMb>512</MinNtfsJournalSizeInMb> 6. Stop the DFSR service. 6. Change '512' to the new increased value. 7. Close and save that file, and repeat for any other volumes you want to up the journal size on. 8. Start the DFSR service back up.
There is a list of DFS Namespace events for Server 2000 at http://support.microsoft.com/kb/315919. I was wondering if there is a similar list of Windows 2008 DFS Event Log Messages?
That event logging system in KB315919 exists only in Win2000 – Win2003 and later OSs don’t have it anymore. That KB is a bit misleading also: these events will never write unless you enable them through registry settings.
Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\MicroSoft\Windows NT\CurrentVersion\Diagnostics Value name: RunDiagnosticLoggingDfs Value type: REG_DWORD Value data: 0 (default: no logging), 2 (verbose logging) Registry Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs Value name: DfsSvcVerbose Value type: REG_DWORD Value data: Any one of the below three values: 0 (no debug output) 1 standard debug output 0x80000000 (standard debug output plus additional Dfs volume call info) Value name: IDfsVolInfoLevel Value type: REG_DWORD Value data: Any combination of the following 3 flags: 0x00000001 Error 0x00000002 Warning 0x00000004 Trace
Registry Key: HKEY_LOCAL_MACHINE\SOFTWARE\MicroSoft\Windows NT\CurrentVersion\Diagnostics Value name: RunDiagnosticLoggingDfs Value type: REG_DWORD Value data: 0 (default: no logging), 2 (verbose logging)
Registry Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dfs Value name: DfsSvcVerbose Value type: REG_DWORD Value data: Any one of the below three values: 0 (no debug output) 1 standard debug output 0x80000000 (standard debug output plus additional Dfs volume call info)
Value name: IDfsVolInfoLevel Value type: REG_DWORD Value data: Any combination of the following 3 flags: 0x00000001 Error 0x00000002 Warning 0x00000004 Trace
Dave and I scratched our heads and in our personal history of supporting DFSN, neither of us recalled ever turning this on or using those events for anything useful. Not that it matters now, Windows 2000 is as dead as fried chicken.
We currently have inherited auditing settings on a lot of files and folders that live on our two main DFSR servers. The short story is that before the migration to DFSR, the audit settings were apparently added by someone to the majority of the files/folders. This was replicated by DFSR and now is set on both servers. Thankfully we do not have any audit policies turned on for those servers currently.
That is where the question comes in: there may be a time in the relatively near future that we will want to enable some auditing for a subset of files/folders. Any suggestions on how we could remove a lot of the audit entries on these servers, without forcing nearly every file to get processed by DFSR?
Nope, it’s going to cause an unavoidable backlog as DFSR reconciles all the security changes you just made – the audit security is part of the file just like the discretionary security. Don’t do that until you have a nice big change control window open. Maybe just do some folders at a time.
In the future, using Global Object Access Auditing would be an option (if you have Win2008 R2 on all DFSR servers). Since it is all derived by LSA and not directly stamped, DFSR won’t replicated the file – the files are never actually changed. It’s slick:
http://technet.microsoft.com/en-us/library/dd772630(WS.10).aspx
In theory, you could get rid of the auditing in place currently currently and just use GOAA someday when you need it. It’s the future of file auditing, in my opinion; using direct SACLs on files should be discouraged forever more.
Does the SID for an object have to be unique across the entire forest? It is pretty clear from existing documentation that the SID does have to be unique within a domain because of the way the RID Master distributes RID pools to the DCs. Does the RID Master in the Forest Root domain actually keep track of all the unique base SIDs of all domains to ensure that there is no accidental duplication of the unique base domain SIDs?
A SID will be unique within a forest, as each domain has a unique base SID that combines with a RID. That’s why there’s a RID master per domain. There is no reasonable way for the domain SIDs to ever be duplicated by Windows, although I have seen some third party products that made it happen. All hell broke loose, we don’t plan for the impossible. :) Even if you use ADMT to migrate users with SID History within a forest, it will not be duplicated as the migration will always destroy the old user when it is “moved”.
The RID Masters don’t talk to each other within the forest (any more than they would between different forests, where a duplicate SID would cause just as many problems when you tried to create a trust). The base SID is a random 48 bit number, so there is no reasonable way it could be duplicated by accident in the same environment. It comes down to us relying on the odds of two domains that know of each other ending up with the same SID through pure random chance – highly unlikely math.
You’ll also find no mention of inter-RID master needs or error messages communication here:
http://msdn.microsoft.com/en-us/library/cc223751(PROT.13).aspx http://technet.microsoft.com/en-us/library/cc756394(WS.10).aspx
I have this message in a health report:
“A USN journal loss occurred 2 times in the past 7 days on E:. DFS Replication monitors the USN journal to detect changes made to the replicated folder. Although DFS Replication automatically recovers from this problem, replication stops temporarily for replicated folders stored on this volume. Repeated journal loss usually indicates disk issues. Event ID: 2204”
Is this how the health report indicates a journal wrap or can I take “loss” literally ?
Ouch. That’s not a wrap, the journal was deleted or irrevocably damaged. I have never actually seen that event in the field, only in a test lab where I deleted my journal intentionally (using the nasty command: FSUTIL.EXE USN DELETEJOURNAL). I would suspect either a failing disk or 3rd party disk management software. It’s CHKDSK and disk diagnostic time for you.
The net recovery process is similar to a wrap for event 2204 ; the journal gets recreated, then repopulated like a wrap recovery (it uses the same code). You get event 2206 to know that it’s fixed.
How come there is no “Set-SPN” cmdlet in AD PowerShell?
Ahh, but there is… sort of. We hide service principal name maintenance off in the Set-ADUser, Set-ADComputer, and Set-ADServiceAccount cmdlets.
-ServicePrincipalNames <hashtable> Specifies the service principal names for the account. This parameter sets the ServicePrincipalNames property of the account. The LDAP display name (ldapDisplayName) for this property is servicePrincipalName. This parameter uses the following syntax to add remove, replace or clear service principal name values. Syntax: To add values: -ServicePrincipalNames @{Add=value1,value2,...} To remove values: -ServicePrincipalNames @{Remove=value3,value4,...} To replace values: -ServicePrincipalNames @{Replace=value1,value2,...} To clear all values: -ServicePrincipalNames $null You can specify more than one change by using a list separated by semicolons. For example, use the following syntax to add and remove service principal names. @{Add=value1,value2,...};@{Remove=value3,value4,...} The operators will be applied in the following sequence: ..Remove ..Add ..Replace The following example shows how to add and remove service principal names. -ServicePrincipalNames-@{Add="SQLservice\accounting.corp.contoso.com:1456"};{Remove="SQLservice\finance.corp. contoso.com:1456"}
-ServicePrincipalNames <hashtable> Specifies the service principal names for the account. This parameter sets the ServicePrincipalNames property of the account. The LDAP display name (ldapDisplayName) for this property is servicePrincipalName. This parameter uses the following syntax to add remove, replace or clear service principal name values. Syntax: To add values: -ServicePrincipalNames @{Add=value1,value2,...} To remove values: -ServicePrincipalNames @{Remove=value3,value4,...} To replace values: -ServicePrincipalNames @{Replace=value1,value2,...} To clear all values: -ServicePrincipalNames $null
You can specify more than one change by using a list separated by semicolons. For example, use the following syntax to add and remove service principal names. @{Add=value1,value2,...};@{Remove=value3,value4,...}
The operators will be applied in the following sequence: ..Remove ..Add ..Replace
The following example shows how to add and remove service principal names. -ServicePrincipalNames-@{Add="SQLservice\accounting.corp.contoso.com:1456"};{Remove="SQLservice\finance.corp. contoso.com:1456"}
We do not have any special handling to retrieve SPNs using Get-AdComputer or Get-Aduser (nor any other attributes – they treat all as generic properties). For example:
get-adcomputer name –properties serviceprincipalnames | select-object –expand serviceprincipalnames
I used select-object –expand because when you get a really long returned list, PowerShell likes to start truncating the readable output. Also, when I don’t know which cmdlets support which things, I sometimes cheat use educated guesses:
I have posted a TechNet forum question around the frequency of KCC nomination and rebuilding and I was hoping you could reply to it.
“…He had made an update to the Active Directory Schema and as a safety-net had switched off one of our domain controllers whilst he did it. The DC (2008 R2) that was switched off was at the time acting as the automatically determined bridgehead server for the site. Obviously the next thing that has to happen is for the KCC to run, discover the bridgehead server is still offline and re-nominate. My colleague thinks that this re-nomination should take upto 2 hours to happen. However all the documentation I can find suggests that this should be every 15 minutes. His argument is that it is a process of sampling, that it realises the problem every 15 minutes but can take upto 2 hours to actually action the change of bridgehead. Can anyone tell me which of us is right please and if we could have a problem?”
“…He had made an update to the Active Directory Schema and as a safety-net had switched off one of our domain controllers whilst he did it. The DC (2008 R2) that was switched off was at the time acting as the automatically determined bridgehead server for the site.
Obviously the next thing that has to happen is for the KCC to run, discover the bridgehead server is still offline and re-nominate. My colleague thinks that this re-nomination should take upto 2 hours to happen. However all the documentation I can find suggests that this should be every 15 minutes. His argument is that it is a process of sampling, that it realises the problem every 15 minutes but can take upto 2 hours to actually action the change of bridgehead.
Can anyone tell me which of us is right please and if we could have a problem?”
We are running an exchange program between MS Support and MS Premier Field Engineering and our current guest is AD topology guru Keith Brewer. He replied in exhaustive detail here:
http://social.technet.microsoft.com/Forums/en/winserverDS/thread/0d10914f-c44c-425a-8344-3dfbac3ed955
Attaboy Keith, now you’re doing it our way – when in doubt, use overwhelming force.
Unless it doesn’t.
Ned “and return to Han shooting first!” Pyle