Partager via

Friday Mail Sack: Walking Tall Edition

  • Article

Hello folks, Ned here again. After a week in Las Colinas Texas, the blog migration, and Jonathan’s attempted coup, we are still standing. Since I’m sure your whole day has been designed around this post I won’t keep you waiting.

Question

I am testing RODC’s in a WAN scenario, where the RODC is in a branch site. When the WAN is taken offline, some users cannot logon even when I have cached their passwords. Other users can logon but not access other resources using Kerberos authorization, like file shares and what not.

Answer

Make sure that the computers in that branch site are allowed to cache their passwords also. This means that those computers need to be added into the Password Replication Policy allow list via DSA.MSC. For example:

image

image

If a user tries to logon to a computer that cannot itself create a secure channel and logon to a DC, that user will receive the error “The trust relationship between this workstation and the primary domain failed”.

If users can logon to their local computers, but then try to access other resources requiring a Kerberos ticket granting service ticket for those computers, and those computers are not able to logon to the domain, users will see something like:

image

The error “The system detected a possible attempt to compromise security” is the key, the dialog may change – in this case I was trying to connect to a share.

You will also see “KDC_ERR_SVC_UNAVAILABLE” errors in your network captures from the RODC. Here I am using a workstation called 7-04-x86-u to try and browse the shares on a file server called 2008r2-06-fn (which is IP address 10.70.0.106). My RODC 2008r2-04-f has a KDC that keeps getting TGS requests that it cannot fulfill since that 06 server cannot logon. So now you see all the SMB (i.e. CIFS) related TGS issues below:

image

Question

Does DFSR talk to the PDCE Emulator like DFS Namespace root servers?

Answer

Nope, it locates DC’s just like your computer does when you logon – through the DC Locator process. So if everything is working correctly, any DC’s in the same site are the primary candidates for LDAP communication.

Question

I understand that DFSR uses encrypted RPC to communicate, but the details are kind of lacking. Especially around what specific cipher suite is used. Can you explain a bit more?

Answer

DFSR uses RPC_C_AUTHN_GSS_NEGOTIATE with Kerberos required, with Mutual Auth required, and with Impersonation blocked. The actual encryption algorithm depends on the OS’s supported algorithms used by Kerberos. On Windows 2003 that would be AES 128 (and RC4 or DES technically, but that would never be used normally). On Win2008 and Win2008R2 it would be AES-256. DFSR doesn’t really care what the encryption is, he just trusts Kerberos to take care of it all within RPC (and this means that you can replace “DFSR” here with “Pretty much any Windows RPC application, as long as it uses Negotiate with Kerberos”). Both AES 128 and AES 256 are very strong block cipher suites that meet FIPS compliance and no one is close to breaking them in the foreseeable future.

Proof!

Question

Not really an AD thing, but is Windows 7 able to use the Novell IPX network protocol?

Answer

Nope. Windows XP/2003 were the last Microsoft operating systems to include IPX support. Novell stopped including IPX when they released their client for Vista/2008:

https://www.novell.com/documentation/vista_client/pdfdoc/vista_client_admin10/vista_client_admin10.pdf

Novell Client for Windows XP/2003 Features Not Included in the Novell Client for Windows Vista/2008

  • IPX/SPXTM protocols and API libraries.

Question

What settings should I configure for Windows Security Auditing? What’s recommended?

Answer

That’s a biiiiig question and it doesn’t have a simple answer. The most important thing to consider when configuring auditing – and the one that hardly anyone ever asks – is “what are you trying to accomplish?” Just turning on a bunch of auditing is wrong. Just turning on one set of auditing you find on the internet, a government website, or through some supposed “security auditing” company is also wrong – there is no one size fits all answer, and anyone that says there is can be discarded.

  • Decide what type of information you want to gain by collecting audit events – what are you going to do with this audit data.
  • Consider the resources that you have available for collecting and reviewing an audit log – not just cost of deployment, but reviewing, acting upon it, etc. Operational costs.
  • Collect and archive the logs using something like ACS. The forensic trail is very short in the event log alone.

Don’t just turn on auditing without having a plan for those three points. Start by reviewing our auditing best practices guide. Then review Eric Fitzgerald’s excellent blog post “Keeping the noise down in your security log.” It has one of the best points ever written about auditing:

“5. Don't enable "failure" auditing, unless you have a plan on what to do when you see one (that doesn't involve emailing me ;-) and you are actually spending time on a regular basis following up on these events.

You might or might not realize, that auditing in general is a potential denial-of-service attack on the system.  Auditing consumes system resources (CPU & disk i/o and disk space) to record system and user activity.  Success auditing records activity of authenticated users performing actions which they've been authorized to perform.  This somewhat limits the attack, since you know who they are, and you've allowed them to do whatever it is that you're auditing.  If they try to abuse the system by opening the audited file a million times, you can go fire them.

Failure auditing allows unauthenticated or unauthorized users to consume resources.  In the worst case, a logon failure event, a remote user with no credentials can cause consumption of system resources.”

Make sure you are not impacting performance with your auditing – another good Eric read here. Understand exactly what it is your auditing will tell you by reviewing:

Finally, for some general sample template security settings, take a look at the Security Compliance Manager tool.

There must have been something in the water this week, as I got asked this by a dozen different customers, askds readers, and MS internal folks. Weird.

Question

When running AD PowerShell cmdlet get-adcomputer -properties * it always returns:

Get-ADComputer : One or more properties are invalid.
Parameter name: msDS-HostServiceAccount
At line:1 char:15
+ Get-ADComputer <<<<  srv1 -Properties *
+ CategoryInfo          : InvalidArgument: (srv1:ADComputer) [Get-ADComputer], ArgumentException
+ FullyQualifiedErrorId : One or more properties are invalid.
Parameter name: msDS-HostServiceAccount,Microsoft.ActiveDirectory.Management.Commands.GetADComputer

Not using –properties * or using other cmdlet’s worked fine.

Answer

Rats! Well, this is not by design or desirable. If you are seeing this issue then you are probably using the add-on "AD Management Gateway" PowerShell service on your Win2003 and Win2008 DC's, and have not yet deployed Windows Server 2008 R2 DC’s yet.  You don’t have to roll out Win2008 R2, but you do need to update the AD schema to version 47 – i.e. Windows Server 2008 R2. Steps here, and as always, test your forest schema upgrade in your lab environment first.

Have a nice weekend.

- Ned “not actually walking tall, per se” Pyle