Hi folks, Ned here again with some possibly interesting, occasionally entertaining, and always unsolicited Friday mail sack. This week we talk some:
- DNS partition absence
- Controlling DCDIAG event messaging
- Inventorying SYSVOL replication architecture
- Weird WMI DFSR volume paths
- Tightening up your inactive user account queries
- More logon banner info
- Smart card logons working “too well“
- SID history and up-level auditing annoyance
- CA role separation… separation
- Other stuff
We use third party DNS but used to have Windows DNS on domain controllers; that service has been uninstalled and all that remains are the partitions. According to KB835397, deleting the ForestDNSZones and DomainDNSZones partitions is not supported. Soon we will have removed the last few old domain controllers hosting some of those partitions and replaced them with Windows Server 2008 R2 that never had Windows DNS. Are we getting ourselves in trouble or making this environment unsupported?
You are supported. Don’t interpret the KB too narrowly; there’s a difference between deletion of partitions used by DNS and never creating them in the first place. If you are not using MS DNS and the zones don’t exist, there’s nothing in Windows that should care about them, and we are not aware of any problems.
This is more of a “cover our butts” article… we just don’t want you deleting partitions that you are actually using and naturally, we don’t rigorously test with non-MS DNS. That’s your job. 😉
When I run DCDIAG it returns all warning events for the system event log. I have a bunch of “expected” warnings, so this just clogs up my results. Can I change this behavior?
DCDIAG has no idea what the messages mean and has no way to control the output. You will need to suppress the events themselves in their own native fashion, if their application supports it. For example, if it’s a chatty combination domain controller/print server in a branch office that shows endless expected printer Warning messages, you’d use the steps here.
If your application cannot be controlled, there’s one (rather gross) alternative to make things cleaner though, and that’s to use the FIND command in a few pipelines to remove expected events. For example, here I always see this write cache warning when I boot this DC, and I don’t really care about it:
Since I don’t care about these entries, I can use pipelined FIND (with /v to drop those lines) and narrow down the returned data. I probably don’t care about the time generated since DCDIAG only shows the last 60 minutes, nor the event string lines either. So with that, I can use this single wrapped line in a batch file:
dcdiag/test:systemlog | find /I /v “eventid: 0x80040022” | find /I /v “the driver disabled the write cache on device” | find /i /v “event string:” | find /i /v “time generated:”
Voila. I still get most of the useful data and nothing about that write cache issue. Just substitute your own stuff.
See, I don’t always make you use Windows PowerShell for your pipelines. ツ
If I walk into a new Windows Server 2008 AD environment cold and need to know if they are using DFSR or FRS for SYSVOL replication, what is the quickest way to tell?
Just run this DFSRMIG command:
That tells you what the current state of the SYSVOL DFSR topology and migration.
If it says:
… they are using DFSR for SYSVOL. It will show this message even if the domain was built from scratch with a Windows Server 2008 domain functional level or higher and never performed a migration; the tool doesn’t know how to say “they always used DFSR from day one”.
If it says:
… they are mid-migration and using both FRS and DFSR, favoring one or the other for SYSVOL.
If it says:
- “DFSR migration has not yet initialized”
- “Current domain functional level is not Windows Server 2008 or above”
… they are using FRS for SYSVOL.
When using the DFSR WMI namespace “root\microsoftdfs” and class “dfsrvolumeconfig”, I am seeing weird results for the volume path. On one server it’s the C: drive, but on another it just shows a wacky volume GUID. Why?
DFSR is replicating data under a mount point. You can see this with any WMI tool (surprise! here’s PowerShell) and then use mountvol.exe to confirm your theory. To wit:
I notice that the “dsquery user -inactive x” command returns a list of user accounts that have been inactive for x number of weeks, but not days. I suspect that this lack of precision is related to this older AskDS post where it is mentioned that the LastLogonTimeStamp attribute is not terribly accurate. I was wondering what your thoughts on this were, and if my only real recourse for precise auditing of inactive user accounts was by parsing the Security logs of my DCs for user logon events.
Your supposition about DSQUERY is right. What’s worse, that tool’s queries do not even include users that have never logged on in its inactive search. So it’s totally misleading. If you use the AD Administrative Center query for inactive accounts, it uses this LDAP syntax, so it’s at least catching everyone (note that your lastlogontimestamp UTC value would be different):
You can lower the msDS-LogonTimeSyncInterval down to 1 day, which removes the randomization and gets you very close to that magic “exactness” (within 24 hours). But this will increase your replication load, perhaps significantly if this is a large environment with a lot of logon activity. Warren’s blog post you mentioned describes how to do this. I’ve seen some pretty clever PowerShell techniques for this: here’s one (untested, non-MS) example that could be easily adopted into native Windows AD PowerShell or just used as-is. Dmitry is a smart fella. Make sure that you if you find scripts that the the author clearly understood Warren’s rules.
There is also the option – if you just care about users’ interactive or runas logons and you have all Windows Vista or Windows 7 clients – to implement msDS-LastSuccessfulInteractiveLogonTime. The ups and downs of this are discussed here. That is replicated normally and could be used as an LDAP query option.
Windows AD PowerShell has a nice built-in constructed property called “LastLogonDate” that is the friendly date time info, converted from the gnarly UTC. That might help you in your scripting efforts.
After all that, you are back to Warren’s recommended use of security logs and audit collection services. Which is a good idea anyway. You don’t get to be meticulous about just one aspect of security!
I was reading your older blog post about setting legal notice text and had a few questions:
- Has Windows 7 changed to make this any easier or better?
- Any way to change the font or its size?
- Any way to embed URLs in the text so the user can see what they are agreeing to in more detail?
[Courtesy of that post’s author, Mike “DiNozzo” Stephens]
#3 is especially impossible. Just imagine what people would do to us if we allowed you to run Internet Explorer before you logged on!
[The next few answers courtesy of Jonathan “Davros” Stephens. Note how he only ever replies with bad news… – Neditor]
I have encountered the following issue with some of my users performing smart card logon from Windows XP SP3.
It seems that my users are able to logon using smart card logon even if the certificate on the user’s smart card was revoked.
Here are the tests we’ve performed:
- Verified that the CRL is accessible
- Smartcard logon with the working certificate
- Revoked the certificate + waited for the next CRL publish
- Verified that the new CRL is accessible and that the revoked certificate was present in the list
- Tested smartcard logon with the revoked certificate
We verified the presence of the following registry keys both on the client machine and on the authenticating DC:
None of them were found.
First, there is an overlap built into CRL publishing. The old CRL remains valid for a time after the new CRL is published to allow clients/servers a window to download the new CRL before the old one becomes invalid. If the old CRL is still valid then it is probably being used by the DC to verify the smart card certificate.
Second, revocation of a smart card certificate is not intended to be usable as real-time access control — not even with OCSP involved. If you want to prevent the user from logging on with the smart card then the account should be disabled. That said, one possible hacky alternative that would be take immediate effect would be to change the UPN of the user so it does not match the UPN on the smart card. With mismatched UPNs, implicit mapping of the smart card certificate to the user account would fail; the DC would have no way to determine which account it should authenticate even assuming the smart card certificate verified successfully.
If you have Windows Server 2008 R2 DCs, you can disable the implicit mapping of smart card logon certificates to user accounts via the UPN in favor of explicit certificate mapping. That way, if a user loses his smart card and you want to make sure that that certificate cannot be used for authentication as soon as possible, remove it from the altSecurityIdentities attribute on the user object in AD. Of course, the tradeoff here is the additional management of updating user accounts before their smart cards can be used for logon.
When using the SID cloning tools like sidhist.vbs in a Windows Server 2008 R2 domain, they always fail with error “Destination auditing must be enabled”. I verified that Account Management auditing is on as required, but then I also found that the newer Advanced Audit policy version of that setting is also on. It seems like the DSAddSIDHistory() API does not consider this new auditing sufficient? In my test environment everything works fine, but it does not use Advanced Auditing. I also found that if I set all Account Management advanced audit subcategories to enabled, it works.
It turns out that this is a known issue (it affects ADMT too). At this time, DsAddSidHistory() only works if it thinks legacy Account Management is enabled. You will either need to:
- Remove the Advanced Auditing policy and force the destination computers use legacy auditing by setting Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings to disabled.
- Set all Account Management advanced audit subcategories to enabled, as you found, which satisfies the SID cloning function.
We are making sure TechNet is updated to reflect this as well. It’s not like Advanced Auditing is going to get less popular over time.
Enterprise and Datacenter editions of Windows Server support enforcing Role Separation based on the common criteria (CC) definitions. But there doesn’t seem to be any way to define the roles that you want to enforce.
CC Security Levels 1 and 2 only define two roles that need to be restricted (CA Administrator and Certificate Manager). Auditing and Backup functions are handled by the CA administrator instead of dedicated roles.
Is there a way to enforce separation of these two roles without including the Auditor and Backup Operator roles defined in the higher CC Security Levels?
Unfortunately, there is no way to make exceptions to role separation. Basically, you have two options:
- Enable Role Separation and use different user accounts for each role.
- Do not enable Role Separation, turn on CA Auditing to monitor actions taken on the CA.
[Now back to Ned for the idiotic finish!]
My latest favorite site is cubiclebot.com. Mainly because they lead me to things like this:
Boing boing boing
Wait for the pit!
Speaking of cool dogs and songs: Bark bark bark bark, bark bark bark-bark.
Game of Thrones season 2 is April 1st. Expect everyone to die, no matter how important or likeable their character. Thanks George!
At last, Ninja-related sticky notes.
For all the geek parents out there. My favorite is:
It was inevitable.
Finally: I am headed back to Chicagoland next weekend to see my family. If you are in northern Illinois and planning on eating at Slott’s Hots in Libertyville, Louie’s in Waukegan, or Leona’s in Chicago, gimme a wave. Yes, all I care about is the food. My wife only cares about the shopping, that’s why we’re on Michigan avenue and why she cannot complain. You don’t know what it’s like living in Charlotte!! D-:
Have a nice weekend folks,
Ned “my dogs are not quite as athletic” Pyle