Friday Mail Sack: VROOM VROOM Edition

  • [アーティクル]

Hi folks, Jonathan here again. Ned’s a little busy right now trying to get items off the top shelf of the cabinet, I thought I’d grab some responses he was working on off this desk and put this week’s Mail Sack together. Today we talk about:

Let me go get Ned a step stool, and then we’ll get started on the Q & A.

Question

If I use Auditing and remove a user’s group membership, I see Security Group Management events (4729, 4759, etc.). If I delete that user though, I only see “a user account was deleted (4726) events.  There’s no group membership event – is that normal?

Answer

[Carefully crafted by Ned in his little Treebicle.]

User deletion means that the System performs the group membership removal.  You will see the same behavior when you create a user – there is no audit event when they are added to the local Users group, for example. This lack of System update auditing is intentional; otherwise, the log would explode from useless information.

Question

I was reading documentation about the Account Operators group’s default behavior. I have found that despite what it says here, members of the account operators group can delete administrators. Is the documentation wrong or is this expected?

Answer

[Straight from the (tiny) desk of Ned.]

Let’s analyze what the article says versus what the author meant:

Members of this group can create, modify, and delete accounts for users, groups, and computers located in the Users or Computers containers and organizational units in the domain, except the Domain Controllers organizational unit.

Mostly true. If you look at the default permissions on the Users container, for example, you see they definitely have create and delete rights:

clip_image002

It will be similar for your custom OUs, because those OU objects inherit those default permissions from the AD schema upon creation.

clip_image004

If your administrative accounts live in the Users container or a custom OU where you have not modified the default permissions, members of the account operators group can delete those users with impunity. If you want to stop this behavior, place your administrative users in a custom OU where you remove the Account Operators group from the permissions.

Members of this group do not have permission to modify the Administrators or the Domain Admins groups, nor do they have permission to modify the accounts for members of those groups.

True, but sometimes it takes a bit. At first, every user created allows the Account Operators group full control – this comes from the default schema security. They cannot modify administrative users, change their passwords, remove their group memberships, or otherwise manipulate them once AdminSDHolder and SDProp have their way with the account . Moreover, the author did not mean, “modification equals deletion”, even though you and I know as IT pros that it “is the ultimate modification”, of a sort. Modifying its existence. J At no point can Account Operators modify the members of the high security groups like Domain Admins, regardless of SDProp timing. Otherwise an Account Operator could elevate a normal user to the highest privilege levels in the domain.

Members of this group can log on locally to domain controllers in the domain and shut them down.

True (and subsequent <Rodney Dangerfield collar pull> ). If you are dead set on using the Account Operators, removing this right (stored in the Default Domain Controllers policy) is probably a good idea. These users can deny service to your entire network, by shutting down every DC at once.

Because this group has significant power in the domain, add users with caution.

True! The Account Operators group is one of those NT 4.0 legacies that date back to an operating system that didn’t have a hierarchical management structure like X.500/LDAP, and instead a big blob of goo called a SAM database. Using this group is not ideal; it has far too many privileges and based on SDProp timing, can have too much power over brand new admin users for brief periods of time. We spent countless millions of dollars creating AD and Delegation of Control so that our customers could abandon the legacy management systems. If the Account Operators group is awesome, why would we have bothered otherwise?

Question

There are a lot of articles that discuss CIFS interoperability, and they refer to LAN Manager Authentication Level, but there are very few that mention the registry parameter AllowLegacySrvCall. What does this setting actually do?

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0
Value: AllowLegacySrvCall
Type: REG_DWORD
Default: 0x0

Answer

Maybe you should sit down.

When a client attempts to connect to an SMB server the server generates a challenge and sends it to the client. The idea is that the client manipulates the challenge using its secret knowledge (the password) and sends the result back to the server as the response. Local System Authority Subsystem (LSASS) on the server evaluates that response and determines if the user has been properly authenticated. This is standard NTLM challenge/response authentication mechanics. With extended security support, LSASS performs some other checks to evaluate if the response has been tampered with, and if it has, the user is denied access. Unfortunately, this introduced a bug that was discovered in Windows Vista and Windows Server 2008. Creating the registry value AllowLegacySrvCall was our way of resolving this bug.

If the client supports extended security, LanManServer goes back to LSASS to generate the challenge to send to the client. If the client does not support extended security for NTLMv2, then LanManServer optimizes by generating its own challenge to the authentication request. Unfortunately, this challenge wasn't created by LSASS so it is missing some information when LSASS later evaluates the response to the challenge. This causes the response to be considered invalid and so authentication fails.

AllowLegacySrvCall enables logic in LSASS such that it can detect that a particular response was created from a challenge generated by LanManServer (as opposed to LSASS). In this case, LSASS will omit the extended security checks on the response. The effect of this setting is that if you have older SMB clients that do not support extended security then your NTLMv2 security is slightly compromised because there is no way to detect tampering of the authentication response on the wire.

So when do you need to enable AllowLegacySrvCall?

  1. You are enforcing NTLMv2 for authentication.
  2. Your SMB client does not support extended security. This usually means older Mac OS X, jcifs, and Samba. Note that NT 4.0 would also be affected, here.

Question

I realize this is an old article but couldn't you get around the USN rollback issue by doing an authoritative restore on the DC you bring back from a snapshot? Don't actually restore a backup but just run NTDSUTIL to make the DC authoritative for all objects. That would push all that DC's USNs up by 100,000 and the objects would replicate out -- hence no USN rollback issue.

Answer

Not quite. Consider the scenario where an object is created or an attribute is set on DC1 after the snapshot is taken. This change propagates out to all replication partners with the originating change designated as being on DC1. Now you restore your snapshot and use NTDSUTIL to mark authoritative all the objects and attributes in the Active Directory on DC1. Those objects and attributes will indeed replicate out, but what about the objects (or attributes) on DC1's partners that actually originated on DC1? Those changes will not propagate back to DC1 because the partner must assume that DC1 is already aware of them because the invocation ID of the partner has not changed.

This is why the invocation ID changes when AD is restored using a supported method. A new invocation ID indicates to all partners that this is essentially a new database with some pre-synchronized data in it and it needs to be updated from all partners. It is not just the USN value itself that impacts the rollback status of a DC, but it is also the invocation ID that distinguishes DC1's restored database from its original database. With the new invocation ID, changes that originated on DC1 after the backup was taken will propagate back to DC1 because partners won't think the changes originated on the now restored DC. Restoring a snapshot does not change the invocation ID, and thus basically breaks AD's ability to properly recover from a restore operation.

Long story short…don't do it.

If you have further questions, I recommend Rich Peckham's blog post on the topic of authoritative restores.

Question

I have read the W32Time documentation and blogs but I do not understand one thing. What is the difference in flags 0x1 and 0x8 in the registry parameter below:

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Parameters
Value: NtpServer
Type: REG_SZ
Example: time.windows.com,0x8

Answer

The flags value for NtpServer are briefly documented in the following KB article: Time synchronization may not succeed when you try to synchronize with a non-Windows NTP server in Windows Server 2003.

0x01 - use special poll interval SpecialInterval
0x02 – UseAsFallbackOnly
0x04 - send request as SymmetricActive mode
0x08 - send request as Client mode

You can find more detail about how these flags interact in the Microsoft Communications Protocol Program (MCPP) library on MSDN: [MS-SNTP]: Network Time Protocol (NTP) Authentication Extensions.

If you need to understand the difference between Symmetric Active mode and Client mode, then you should consult RFC 5905. It’ll put hair on your chest.

Other Stuff

Is this the greatest metal album cover of all time? I think so.


Plow tank with gatling guns on a skull road with hardcore driver demanding answers from an uncaring corporate world? Check.

Do you have a set of wheels appropriate for the Zombie Apocalypse? Why not skip the Marauder and buy American?

And here is some stuff that makes me wish I still had a dorm room to decorate.

Until next time, folks.

- Jonathan “Average Height and Build” Stephens with Ned “Not” Pyle.

Comments

  • Anonymous
    February 18, 2012
    Regarding the USN rollback issue. I'm not sure if it's just talk, but will Win Server 8 support restoring snapshots? I've heard it has a built-in mechanism to overcome USN rollback as long as the PDCe is a Win8?  

  • Anonymous
    February 18, 2012
    I'm afraid we aren't allowed to talk about any Windows 8 specifics for a few more weeks. Rest assured that after February 29th, you won't be able to shut us up. :)

  • Anonymous
    February 20, 2012
    The comment has been removed

  • Anonymous
    February 21, 2012
    Looking at the pictures Jonathan included leads me to conclude you guys have a "slightly relaxed" dress-code.

  • Anonymous
    February 21, 2012
    That's fair. There are two people sitting near me right now who are not even wearing shoes. Filthy hippies.

  • Anonymous
    February 21, 2012
    Are they sitting in bean bag chairs?

  • Anonymous
    February 21, 2012
    What's a dress code?

  • Anonymous
    February 21, 2012
    AD Delegation can be an admins best friend.  Figure out "who" needs to do "what", create a handful of standardized named groups, and then delegate out rights to the groups.  Yes it took a bit of time in the beginning, but now we have people only allowed to do specifically what they need to do.  Now if someone needs the ability to say... modify members of a certain type of groups, we can just toss them into that specific admin rights group.  Audit/Security is happy too, because those admin rights groups are audited for any changes.  Good stuff! Seriously can't wait for the Win8 gates to be unlocked!  I imagine you have drafts of posts just waiting to hit "submit" on.   :)