Friday Mail Sack: Beard-Seconds Edition
Hiya folks, Ned here again. This week we talk:
- DC DNS A Records and Web Servers
- Forwarding Security event log subscriptions
- Domain password filters
- Auditing NTLM vs NTLMv2 on Win2003
- Programmatically determining if UNC is DFS namespace
- DFSR and Excel Shared Workbooks
- DFS, DC, Delegation, and Domain Admins
- Other nonsense
Start the word punching!
We are interested in removing the A records that are created by Domain Controllers in our Windows 2008 R2 environment so that we can have web servers respond to the FQDN without needing WWW, from our users on the internal network. So for example, if our AD forest name is contoso.com, we want to add the contoso.com FQDN to a web server, but can't because the DC A records are currently claimed. Is this possible to do without affecting normal client operations?
Removing the “same as parent folder” A Records from DCs and blocking their further creation using Group Policy is going to cause issues.
For example, you cannot create domain DFS namespaces, as it will explode trying to use the A records to find the domain namespace, with the oh-so-helpful “RPC server is unavailable” error:
Any applications that use generic A records as part of a domain controller lookup, instead of SRV records, will fail. Any apps that “ping” - not necessarily with ICMP - the domain to locate a DC will fail also. Some of these apps are Microsoft: ADMT has that problem too and there are likely others. Mostly though, they will be third party or homegrown apps and therefore unknowable to me. You will need to inventory all your application in the entire environment and try them all out in a test lab. That sounds like fun!
This is the problem with using a public facing domain as the root of your AD forest, rather than building a new root under the FQDN. For example, Microsoft’s main AD forest root is corp.microsoft.com.
- Migrate your entire forest into a different FQDN than your current web server’s FQDN. Not gonna happen.
- Migrate all your web servers into a different FQDN. Not gonna happen.
- Run the web servers and their sites on your DCs. Not gonna happen.
- Run just enough website on your DCs to redirect all traffic to the WWW addresses. Could maybe happen.
- Do nothing, tell internal users to go to a WWW address rather than the domain.name itself, and leave it all as-is. Most likely to happen.
Is it possible to use forwarded event log subscriptions with the DC’s Security event logs? It’s working for other logs, so I know I am doing it correctly in general, but the Security event log specifically never forwards from my DCs to my collector computer.
By default, the Security logs cannot be forwarded due to permissions ACL’ing the log – the service that does the event collection has no rights to it. Being a DC is not relevant, even member servers have slightly more restrictive access to that log. On the servers you want to collect security event logs from (or in your case, on any DC in that domain), run:
net localgroup "Event Log Readers" "NT Authority\Network Service" /add
Let that replicate to all other DCs in the domain. Then restart those DCs. Now you can configure your subscription-collector… goo. And if you set up all the subscriptions and service correctly, will work. Here’s my 01 DC forwarding security events to my 05 member server:
The steps for doing all this event log subscription stuff are here:
Our Mainframe requires that user passwords be no longer than 8 characters and can only use a few special characters. Can Windows AD password policy enforce this type of limitation also, so our users don’t have to remember two passwords?
No, you must create or purchase a password filter DLL to run on your DCs. We talked about the password rules on AD here previously. Our only limit to the maximum password length is the actual max – 128 characters, it’s not configurable. We’re mainly concerned with providing more avenues to complexity, not fewer. As always, I recommend two-factor auth when possible; passwords alone are not safe enough, and third party front-end tools that make the user pick words resistant to dictionary and PII attack are just encouraging users to write them down and tape it to their monitor.
I highly discourage anyone from trying to write their own password filter DLL, by the way, and you should carefully test any third party ones before purchasing. There are a lot of filter vendors, so use that to your advantage at the negotiating table. The DLL has to run in LSASS.EXE on all your DCs. We have worked many a CritSit here where a custom password filter would cause LSASS to crash, which means no more DCs. Not to mention that you need to trust your vendor enough that they are correctly vetting their code, making sure there are no buffer overruns, injection attacks, etc. – you are giving them the highest possible privilege in your entire company. That vendor is effectively running as the DC itself, so they’d better be careful – nor should they like leaving little backdoors in their code. You know, like Siemens did with their nuclear control software.
Some of these vendors also sell GINA or Credential Provider components. Beware any vendor that wants to sell you just those front-end pieces and not a DC password filter DLL. While helpful to the user, those clients are easily bypassed (often by accident, like when going through an Outlook Web Access page) and should not be the only way that passwords are restricted. The DC is the final password arbiter, so that’s where you need to enforce things.
Just toss the Mainframe, this all sounds like too much work. :-P
Does Windows Server 2003 auditing differentiate between NTLM and NTLMv2 as the authentication package recorded in the 528/529 events? I already know about event ID 4624 in Advanced auditing.
No, it will always just say "ntlm". Because that auditing dates back to NT 3 and is exceptionally gross.
I would like to programmatically detect if a given UNC path contains a DFS root or not – is that possible?
NetShareGetInfo is one way, as it’s can return DFS structure SHARE_INFO_1005 if asked. Alternatively, you can also use: NetDfsGetInfo with \\server_or_domain\share and level 1 should tell you if the path is DFS. If success, the path is DFS. Unfortunately, almost any error returned does not necessarily mean that it is or isn’t DFS, just that something is broken. Also, the API is a blocking call and there is no timeout mechanism.
Is it possible to use Excel Shared workbooks with DFSR on Windows Server 2008 R2?
Yes, with the caveats that:
- Users should only be allowed access a single copy of the file – i.e. all users only have one share available for that file, not shares on 20 different DFSR servers. The merging functionality two+ replicated copies of a shared document will not work, based on replication timing. I.e. shared documents accessed by two different users from two different servers. Data loss will result.
- As long as at least one person has the shared notebook open having made their own changes and not saving them, those changes will not replicate. When saved by a user, their changes will commit to the “real” XLSX file and will replicate. Excel creates temporary backing files with tildes that will not replicate with default DFSR filters. This works with shared workbook’s passive auto-save as well as clicking the save button actively.
- I used Excel 2010 shared workbooks – I have no idea if the older versions will be worse, I leave that to you to test.
- This is “practical testing” – I don’t have an official support answer here; only that it works in my repro within these constraints and does not appear to explode. If you want an official answer, you need to open a case with the MS Office Excel team – they ultimately decide supportability of their app, not us in Windows.
From my long understanding, when you host your DFS Namespace on Domain Controllers, you must be member of the Domain Admin Group in order to administer it; you can’t delegate the administration to a standard user. It talks about this in KB258992 and elsewhere. But I just tried delegating a user for a namespace that is hosted on DCs, and they were able to create links, delete them, and even delete the namespace root servers and the namespace itself! He’s not a member of any admin groups.
If I delegate a user, I can modify and delete all aspects of a namespace except share removal. I cannot create new namespaces though, even if the share I want to use already exists and was created for me by an admin. If I try, “service control manager cannot be opened: access is denied” and kaboom:
This is the case with both DCs and non-DCs - it makes no difference. The nugget here is that the KB only states the limitation once, and too loosely:
When you delegate to users the ability to create DFS shares, the configuration of the DFS dictates how delegation must occur. When you configure a stand-alone DFS server, the delegation process involves adding the user who is delegated to the local Administrators group on the DFS server. When you configure a domain DFS, the user who is delegated must be added to the local Administrators group on each of the Root DFS server replicas. If the DFS root is on a domain controller, the user must be added to the Domain Admins group; otherwise, the user will receive an "access denied" error message.
The UI states “Delegate Management Permissions” so it’s a semantic argument over what that means. The fact that you cannot connect to Service Control Manager without admin permissions is not DFSN’s fault, though. And that’s why you need to be a member of the Administrators or Domain Admins group on DCs to fully manage DFS. If you were to do some unsupported hackery that let some delegated user operate the service control manager, you might as well make them be an admin – they can kill all your DCs now by shutting off all the services!
A list of amusing units of measurement. Mention of measure usually drives a European to show up complaining that we still don’t use the metric system in the US. Which is incorrect, but regardless, here’s my offer: we’ll fully mandate the metric system in the US when you abolish the hundreds of languages of Europe and use only English, the language of science, information technology, business, seafaring, aviation, entertainment, radio and diplomacy. Then you will be efficient in a way far more meaningful than hectares and grams. Bwaamp!
Odd, I usually find that swearing makes me feel better. #%@$@&^*! The Car Show is better than Top Gear USA, as long as you start with Episode 3 of TCS.. Neither is fit to hold proper Top Gear’s sweaty Stig helmet.
Finally, my favorite new t-shirt from comic-con 2011…
Have a great weekend folks.
Ned “bring back vector graphics” Pyle