How to re-create the secure channel

We recently had an incident where a CA on a test domain had its computer account deleted. As it was the CA, we couldn't drop it from the domain and rejoin it (system properties showed "Note: The identification of the computer cannot be changed because: - The Certification Authority is installed on this computer."

To solve the issue, I recreated the computer account manually.
Then, on the server itself I reset the machine password a couple of times using:
netdom resetpwd /Server:name of DC /UserD:domain user /PasswordD:password

Then, I reset the secure channel. This is the part that actually fixed the problem:
netdom reset computer to reset /Domain:DNS name of domain /Server:name of DC /UserO:domain user /PasswordO:password

After that, nltest /SC_QUERY:DNS name of domain shows that the secure channel is operative again.

Refreshing Group Membership Without Logging Off and On Again

I haven't done much investigation into what limitations there are with this (for instance, does group policy filtered to a an added security group take effect), but klist allows you to get a new kerberos ticket, with any new access rights added, without logging off and on again.

Run: klist purge - this will purge the existing kerberos ticket.
klist tgt - TGT refresh, should display the ticket.

The user can now access any resources secured by groups they have been added to since they last logged on.

Tools like whoami /groups will still not display the new group membership, but will if you create a new cmd window using runas since the process will be created using the updated security token.
It may be that by launching a new cmd in this way ansd then running gpupdate, that this will also allow group policies targeted to any new groups to also take effect.

TGT Refresh v TGT renewal
Using klist in this way refreshes the TGT, and new group memberships are added.
A TGT is renewed by default every 10 hours, but this will not add the new group memberships as it only extends the old TGT's validity. After 7 days, TGT refresh happens and the new memberships will be added.

VAMT

This is the Volume Activation Management Tool. When KMS is not an option (Technet subscriptions do not provide KMS keys), VAMT can provide a good alternative using MAK keys.

This article describes how I set up VAMT to activate VMs running on a VirtualBox host-only environment. In this example, VMs will be activated using the VAMT server as a proxy.

1. Install a Windows Server 2008 R2 server with both host-only and bridged network adapters.
2. Install VAMT.
3. Open the console and choose how to locate machines (searching AD for example).
4. Once the scan finds some machines, they will be in the "Status Unknown" section on the left hand side of the user interface. At this stage no license scanning has taken place.
5. Highlight a machine, right click and choose "Update Status". You will be able to do this either using the current credentials with which you are logged on with, or you can specify alternative credentials. Ultimately you need to perform this operation with an account with local admin privileges on the remote machine.
6. Once scanned the machine will be placed in either the Licensed, Not Licensed or Unmanaged sections on the left.
7. You can add a product key by entering it in the relevant place (it also requires a description). Click "Add Product Key".
8. You can then right click on the remote computer and choose "Install Product Key".
9. If the remote client has internet connectivity you can then right click on it and choose Activate - Online Activate. Since in this example the remote computers are on a host-only network, I will set up the VAMT as the proxy activation server. to do this, right click on the remote machine and choose Activate - Proxy Activate. The VAMT will then activate on the client's behalf.
10. Once done, save the configuration of VAMT, otherwise you'll tend to find the computers won't be there when you next open it, and neither will the product keys. To do this, choose "Save List as" to save the cli file. Next time you go into VAMT, open this file.

AD Searches with DistinguishedName

I've seen this with both LDAP filters and Get-ADUser:
It seems that you cannot use wildcards when searching with distinguishedName.
So for example the following is not valid:

Get-ADUser -Filter 'distinguishedName -like "CN*"'

The only valid use of wildcards with distinguishedName is to test for existence or non-existence of the value.

e.g. Get-ADUser -Filter 'distinguishedName -like "*"'

The easiest way I have seen to do this is with ADFIND and use the -excldn switch

e.g. adfind -excldn "OU=Admin Accounts,OU=User Management";"OU=Shared Accounts,OU=User Management" -b "OU=User Management,DC=test,DC=com" -f "(&(objectCategory=Person)(objectClass=User))" dn

This will show you just the dn's for the users that are under the OU=User Management,DC=test,DC=com OU structure, but excluding any that have either "OU=Admin Accounts,OU=User Management" or "OU=Shared Accounts,OU=User Management" in their distinguished names.

Challenge - Response authentication in Windows

Specifically, we're talking about LanMan and NTLM responses.
LanMan is really for pre-NT4 clients but has been included for backwards compatibility since then.

Format for challenge-response authentication

1. Client sends a type 1 (NEGOTIATE_MESSAGE) to server, advertising its capabilities.
2. Server sends type 2 (CHALLENGE_MESSAGE) which includes supported features and the challenge itself.
3. Client replies with type 3 (AUTHENTICATION_MESSAGE) which contains information about the client including domain and user name plus 1 or more responses to the challenge.

LanMan responses

1. The ASCII password is converted to upper case.
2. It is then null padded to 14 bytes.
3. Split into 2 x 7 bytes.
4. These are used to create 2 DES keys.
5. Each of these keys is used to DES-encrypt the constant ASCII string, resulting in 2 x 8 byte ciphertext values. These 2 ciphertext values are concatenated to a 16 byte value. THIS IS THE LM HASH.
6. The 16 byte LM hash is null padded to 21 bytes.
7. This is split into 3 x 7 bytes.
8. These values are then used to create 3 DES keys.
9. Each of these keys is used to DES-encrypt the challenge in the type 2 challenge message. It results in 3 x 8 byte ciphertext values that can be concatenated to form a 24 byte value. THIS IS THE LM RESPONSE.

Weaknesses

• Converted to upper case so all of that complexity is lost.
• If password is 7 characters or fewer, the second value is null, so straight-away half of the LM hash is compromised.
• Not true one-way encryption as password can be obtained from the hash.
• Since LM hashonly changes when password changes, susceptible to pass the hash attacks, where an attacker uses the hash directly to authenticate to a server rather than having to brute force the hashes to obtain the clear text password. This is also true for NTLM authentication. Both NTLM and LM are password equivalent so if you can get the hash from the server you never need to know the actual password.

If the user's password is > 15 characters then the DC will not store the LM hash so the LM response cannot be used to authenticate the user. The LM response is still generated but a 16 byte null value is used as the LM hash in the calculation and then ignored by the server.

NTLM v1

1. Server sends 8 byte challenge.
2. Client uses a shared secret between the client and server, specifically one of the hashes (LM or NT) to return a 24 byte result of this computation.
3. NTLMv1 computations are usually made for both hashes with both 24 byte results sent to the server, unless you configure it not to.
4. Server verifies that the client has computed the correct result. This assumes that they then have possession of the secret and so are authenticated.
5. Both hashes produce 16 byte values.
6. 5 bytes of zeroes appended to them.
7. Separated into 3 x 7 bytes (56 bits). Each of these 56 bit values is used as a key to DES-encrypt teh 64 bit (8 byte) challenge. The 3 encryptions are reunited to form the 24 byte response.

NTLM v2

1. Server sends 8 byte challenge.
2. Client sends 2 x 16 byte response.
3. This response is the HMAC-MD5 hash of the server challenge, a randomly generated client challenge, and a HMAC-MD5 hash of the user's password and other identifying information.
4. The first response is shorter: it's an 8 byte random value for the client challenge. To verify this response the server must receive as part of the response the client challenge. The 8 byte client challenge is appended to the 16 byte response to make a 24 byte package.
5. The second response is a variable length client challenge which includes the current time, an 8 byte random value, domain name and some standard stuff. The response must include a  copy of this client challenge and is therefore of variable length.

NTLM Weaknesses

• As pointed out above, it's susceptible to pass the hash attacks.
• In Feb 2010 several flaws in the Windows implementation of NTLM were proved: one attack included the ability to predict the random numbers/challenges generated by the protocol. These flaws were fixed by MS010-012.

Why Not Just Use Kerberos?

Kerberos relies on a trusted third party. If one is not available (for example where a client is not a member of a domain, local accounts and authentication to an untrusted domain), then NTLM still rules!

Group Policy Loopback Processing

This had me puzzled for a while so I thought it would be worth recording here.

Enabling loopback processing in a GPO affects not just the way that policy is processed, but all policies affecting the user/computer because it changes the way group policy processing is performed - precisely it affects the way in which the GetGPOList function operates.
So therefore if you have one policy targeting a computer with loopback processing enabled, then all policies targeting that computer will be reapplied with user settings (if there are any)

Here are the differences:

Policy processing WITHOUT loopback processing:
1. Computer Node policies from all GPOs in scope for the computer account object are applied during start-up (in the normal Local, Site, Domain, OU order).
2. User Node policies from all GPOs in scope for the user account object are applied during logon (in the normal Local, Site, Domain, OU order).

Policy processing with loopback processing in REPLACE mode:
1. Computer Node policies from all GPOs in scope for the computer account object are applied during start-up (in the normal Local, Site, Domain, OU order), the computer flags that loopback processing (Replace Mode) is enabled.
2. User Node policies from all GPOs in scope for the user account object are NOT applied during logon (as the computer is running loopback processing in Replace mode no list of user GPOs has been collected).
3. As the computer is running in loopback (Replace Mode) it then applies all User Node policies from all GPOs in scope for the computer account object during logon (Local, Site, Domain and OU).

Policy processing with loopback processing in MERGE mode:
1. Computer Node policies from all GPOs in scope for the computer account object are applied during start-up (in the normal Local, Site, Domain, OU order), the computer flags that loopback processing (Merge Mode) is enabled.
2. User Node policies from all GPOs in scope for the user account object are applied during logon (in the normal Local, Site, Domain, OU order).
3. As the computer is running in loopback (Merge Mode) it then applies all User Node policies from all GPOs in scope for the computer account object during logon (Local, Site, Domain and OU), if any of these settings conflict with what was applied during step 2. Then the computer account setting will take precedence.

You can also see here that policies targeted to computers can be applied twice: once during normal application of computer settings and again when the user settings are applied.