Installing Python and Pygame

I had a good couple of hours of frustration trying to get a combination of Python, Pygame and PyScripter to work together (I kept getting module not found for Pygame when importing it in PyScripter code).

So, here is what I had to do to get it to work:

1. Install Python 3.3. This was the latest version at the time. Must make sure that this is the 32 bit version so that it installs in the 32bit part of the registry. Otherwise Pygame won't even find it. Ultimately the important thing here is to keep with 32 or 64bit versions of all 3 components and not mix and match because then you'll hit problems. No need to do anything other than a default installation.
2. Installed pygame for version 3.3 from here https://bitbucket.org/pygame/pygame/downloads. This only seemed available as a 32bit installation. You need to match the versions of Python and Pygame (in this case 3.3). You should not need to change any parts of the installation - just Next all the way through.
3. Install Pyscripter. Again, install the 32bit version since we installed 32bit Python.

So, no need to modify the PythonPath (which probably won't even show up as an environment variable for the computer).

Why a Forest is the Security Boundary in AD (SID Filtering flaw)

Initially, the domain was seen as the security boundary in Active Directory.
However, following discovery of the SID filtering flaw, this has been changed so that the security boundary is now defined at the forest level.

The SID filtering flaw is this:
A trusting domain does not verify that the trusted domain is authoritative for all of the SIDs in the authorisation data. Therefore, if an attacker can populate SIDHistory with SIDs manually, they could elevate their permissions in any trusting domain, even to the point where they could add the SIDs for a domain admin in a trusting domain into their authorisation data.
Within a forest, the trust arrangements mean that SID filtering is not appropriate.
In order to do this an attacker would have to:

• possess administrative privileges in the trusted domain.
• have enough technical knowledge to modify low level OS functions and data structures: SIDHistory does not come with any programming interfaces that would allow an attacker to populate it manually, even if they have admin rights. Therefore the attacker needs to perform a binary edit of the SIDHistory data structures.

With SID filtering, the DCs in the trusting domain remove all SIDs that are not relative to the trusted domain from any authorisation data received from that domain.

So removing SID filtering is a risky step to take as it extends the security boundary outside of the forest.

Preventing crawling of web sites

Robots.txt is a standard way of preventing web crawlers from indexing a page.
However, it is still possible for a website with a robots.txt file to appear in search results.
This usually happens if the site is linked to from other sites, with a description of it in the anchor text. In such a scenario, the site will still not be crawled, but search results can still deduce that it is a useful site for certain queries due to the number of links to it.
In these cases, there will be no snippet of content from the site in the search results since it still can't be crawled.

Alternative ways are to allow the site to be crawled but add a no index mate tag to the pages. This will allow search engines to crawl the site but they will drop it again as soon as they see the no index tags.

You can also use URL removal tools to remove sites from indexes.

Certificate Services and Domain Controllers

When you create a new instance of an Enterprise Certificate server in the forest, you'll find that with a vanilla installation all of your domain controllers start to register certificates based on the Domain Controllers v1 template. This can be troublesome if you already have certificates in the local computer stores on DCs because the DCs may suddenly switch to use these new ones.
This will happen despite the fact that there are no auto-enrollment GPOs in place.

The reason for this is that it is just hard-coded into the operating system for DCs to auto-enroll using the Domain Controller certificate template, regardless of the presence of any policies instructing them to do this.
If there were a policy in place then you would likely find that the DCs would auto-enroll a Domain Controller  Authentication certificate instead as this supersedes the Domain Controller one.

To prevent it, remove that certificate template from the CA.
This can be done by either deleting it from the Certificate Templates container through the Certification Authority snap-in, or by configuring LoadDefaultTemplates=False (or LoadDefaultTemplates=0) in the CAPolicy.inf file so that the default v1 templates are never loaded on to the CA at installation time.
This is my preferred way as I never use the v1 templates (the general practice is to create your own templates). The v1 templates also cannot be auto-enrolled as this permission does not exist on a v1 template.

Creating iSCSI Volumes on Windows clusters

I created this to remind me of all of the steps that need to be done in order to create an iSCSI volume that can be shared across multiple servers (under the assumption that these servers will be clustered).

On the server that will host the shared volume, install Microsoft iSCSI Software Target. This can be dowloaded for free. It will bring up a web page that allows you to install the software. The installation will work out what version of the OS you are running and install the correct software.

Once installed:

1. Launch Microsoft iSCSI Software Target.
2. Right click Devices and Create Virtual Hard Disk.
3. Under File, put in the path to the virtual hard disk and call it whatever you want with a .vhd extension.
4. Put in the size of the volume that you want to create. The description can be whatever you want.
5. There won't be any iSCSI targets yet so just click next on this screen and finish.
6. Then, under iSCSI Targets, this is where we configure who can connect to the disk.
7. Right click - Create iSCSI Target.
8. iSCSI Initiator Identifers - Advanced - Add - specify the IP addresses (or whatever) of the clients that will be connecting. Here, if you are having multiple servers connecting to it, add both IP addresses. Accept the warning and click Finish.
9. Click on the disk that was created under Devices and right click - Assign/Remove Target.
10. Add the iSCSI target that was just created.
11. Next, swap to the client machines that need to connect to the iSCSI volume.
12. In Administrative Tools, launch iSCSI Initiator. It will want to start the service so accept this.
13. In the target field, type the IP address of the machine hosting the iSCSI volume and then Quick Connect - Done. If you are using a separate NIC to make the iSCSI connection, you could find that this stage fails. In my case, the additional NIC was just for this iSCSI connection, and I wasn't publishing this NIC to DNS and hadn't configured DNS servers for it. In order to get it to work I had to disable the production interface first before this step would work.
14. Once working it should show the name of the iSCSI target name as part of the name of the discovered target e.g. iqn.1991-05.com.microsoft:-iSCSITargetName>-target.
15. The Discovery tab will show the targets - no need to do anything on this screen.
16. Volumes - click Autoconfigure to create the volume automatically.
17. This is now complete.
18. Go into Disk Management and you will see the new disk.
19. Right click it to set it Online, and then right click again to Initialize Disk. From there you can create a new simple volume as normal or whatever your partitioning needs.
20. At this point re-enable the primary NIC if you had to previously disable it.

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.

LDAP authentication....

LDAP is primarily a directory access protocol.
It does have a primitive authentication mechanism called a simple bind where usernames and passwords are sent using clear text.

However, LDAP also includes an extensible authentication framework called Simple Authentication and Security Layer (SASL).
The rootDSE includes an attribute called supportedSASLMechanisms that lists the supported SASL features.
AD supports Kerberos v5 and NTLM SASL mechanisms.
GSSAPI = kerberos
GSS-SPNEGO = NT negotiate (so still probably kerberos).
There is also Digest and External for client certificate authentication.

Therefore kerberos is often used by an application during an LDAP bind operation.

Apparently scripts using GetObject("LDAP://...") also use GSS-SPNEGO authentication using current user's credentials, so will use kerberos where possible, though I have not tested this myself.

Unreliability of logonserver variable

When referencing this variable, be aware that it is not updated, so may not show where the secure channel is currently with.
So, you may log on and find that the initial logon is against DC2. However, at some point during the session, the secure channel may be established with DC1. However, the logonserver variable will not be updated to show this.
Therefore, nltest /sc_query: is far more reliable.

Computer Account Password Reset process

This succinctly sums up the process.

Note that resetting a computer account is a client-initiated process, so clients that are turned off for months will still authenticate since they will only change the old password when they come back on line.

Also worth noting that before changing the password locally, they ensure that a valid secure channel exists so lack of connectivity should not cause a password mismatch.

http://blogs.technet.com/b/askds/archive/2009/02/15/test2.aspx

Connecting to DNS on Server 2008 R2 from older OS's

Server 2008 R2 implements RPC integrity. This is not supported in the W2K and W2K3 versions of DNSMGMT.msc or DNSCMD.exe.

http://technet.microsoft.com/en-us/library/ee649281(WS.10).aspx

which suggests that only W2K8R2 machines can be managed from the same OS, and only W2K3 machines can be managed by older OS's.

Which is a pain.

I understand the following would "fix" Server 2008 R2, but by running this you are effectively exposing DNS to man in the middle attacks:

dnscmd.exe /Config /RpcProtocol 7

dnscmd.exe /Config /RpcAuthLevel 0 

I have not attempted this to be able to confirm that it works.

Authentication

This topic could get huge, so let's restrict it to the modes of authentication supported by IIS. They are:

Anonymous - a token is created in IIS to represent all anonymous users with the same anonymous account. The default account is IUSR_NetBIOSNameOfMachine

Basic - credentials are then transmitted in unencrypted Base64-encoded format. This means that they will be sent in clear text. The only way to prevent this is to wrap the credentials using SSL. Since the server receives unencrypted credentials, it can then use them to impersonate the caller and use the same credentials to access network resources.

Integrated windows - uses either NTLM or Kerberos v5. Kerberos is used if the following criteria are met:

The application is using the network service or a domain account (otherwise NTLM used if the application is running under a local user account).

A SPN exists for the domain account used to run the service with which the client is authenticating.

Client and server are W2K+, and are in the same or trusting domain.

NTLM Authentication





Note in the above diagram, the challenge is just a 16 byte random number, so the client then just encrypts it with the password hash of the user and returns it. Then, in step 5, the DC obtains the password hash for the user and then uses it to encrypt the original challenge. If this matches the original response from the client then the DC sends the server confirmation that the user is authenticated.



Kerberos Authentication




Breaking this down further:

1. When a user attempts to log on to client, the kerberos service on the client sends a kerberos authentication request to the KDC. This request will contain user name, service information for which the TGT is requested, and a time stamp that is encrypted with the user password.
2. The DC will decrypt the timestamp with the user password that it gets from AD. If the timestamp is then valid, the user is genuine. The KDC will then create a logon session key, and encrypts the copy with the user password. The authentication service then creates a TGT which includes user info and the logon session key. The authentication service will then encrypt the TGT with its own key and passes both the encrypted session key and encrypted TGT to the client.
3. The client will then decrypt the logon session key using the user password and caches it locally. Also stores the encrypted TGT in its cache. When accessing a network service, the client will send a request to the KDC ticket granting service (TGS) with information that includes the user name, an authenticator message encrypted using the user's session key, the TGT and the name of the service that they want to access.
4. The TGS on the KDC decrypts the TGT using its own key and extracts the logon session key. Using this logon session key it can decrypt the authenticator message (which is usually a timestamp). If this authenticator message is successfully decrypted, the TGS extracts user info from the TGT, and using this user info will create a service session key for accessing the service. One copy of the service session key is encrypted with the user's logon session key, and a service ticket is then created with the service session key and the user info. The service ticket is then encrypted with the server's password. The TGS then sends the encrypted service session key and service ticket to the client.
5. When the client accesses the service, it sends a message to the server containing the authenticator message (timestamp) which is encrypted using the service session key and the service ticket.
6. The server decrypts the service ticket and extracts the service session key, which it then uses to decrypt the authenticator message. It evaluates this. If the authenticator passes the test, the server encrypts the authenticator message using the service session key and then passes the authenticator back to the client. The client decrypts it and if it is the same as the original the service is genuine and the client proceeds with the connection.

Advantages of kerberos

• Mutual authentication - so client is assured that the service is not being impersonated.
• Delegation support - servers that authenticate clients using kerberos can impersonate those clients and use their security context to access network resources.
• Better performance than NTLM.
• In multiple domains, point to point trust relationships are not required.

SPNs
These enable mutual authentication, and allow clients to request tickets to then communicate with a particular service.
SPNs in AD maintain a mapping between the constructed name e.g. MyService/MyServer:1879 and the domain account under which the service you want is running. For this to be impersonated, an attacker would need to disable the real service and remove the actual server from the network. They'd then need to add a new computer with the same name and expose the duplicated service. Since Kerberos v5 uses mutual authentication, the client will not be able to use the duplicated service unless it knows the password for the domain account under which the actual service is configured to run.

Microsoft Secure Desktop

See here http://blogs.msdn.com/b/uac/archive/2006/05/03/589561.aspx for good explanation of how the secure desktop works.

Modifying security settings of GPO directly through SYSVOL

Occasionally you may need to remove some of the security settings applied to a GPO directly.
In this case, navigate to the policy folder in SYSVOL.
Then, inside the policy folder, choose Machine - Microsoft - Windows NT - Secedit and open up the GptTmpl.inf file.
So, for example, to remove all settings associated with services, delete the lines from [Service General Setting] to the end of the last service line.
Saving this file and then opening GPMC (ensuring that the GPMC console is pointing at the same DC that you made the edit on), you'll see that all system service settings have been removed.

When is this useful? Well, if you mess around with the service security settings and decide that you no longer want to touch security of the services through the GPO, it is pretty much impossible to reset to the default permissions without actually explicitly setting the default permissions on the service, at which point you're still controlling access permissions within the GPO.

Group Policy Preferences - Registry Items

 

Specifically focusing on the type of Action that can be selected, and the difference between Update and Replace. Microsoft has the following references to this topic. However, to make it clear the following tests several scenarios under a Replace action compared to an Update action:

Scenario: New registry item defined for HKLM\Software\Newkey. DWORD registry item defined here called NewItem1, with a value of 1.

The Newkey folder does not exist to begin with.

Test	Update	Replace
NewItem1 = 1 defined in GPO.	Registry key and value created in registry	Registry key and value created in registry
Manually add new items into registry under Newkey.	After GPO refresh they remain.	After GPO refresh they remain.
Update GPO so that NewItem1 = 2	Registry updated as well.	Registry updated as well.
Delete NewItem1 from registry.	GPO puts it back.	GPO puts it back.
Manually change NewItem1 = 5 in registry.	GPO changes it back to 2.	GPO changes it back to 2.
Rename NewItem1 to NewItem2 in registry.	GPO creates NewItem1 again, leaving NewItem2 in place.	GPO creates NewItem1 again, leaving NewItem2 in place.
Rename NewItem1 to NewItem5 in GPO.	New item created in registry so that both NewItem1 and NewItem5 are present.	NewItem1 is renamed to NewItem5 in the registry as well.
Delete NewItem1 registry item from the GPO.	Remains in registry.	Deleted from registry.

 

Group Policy Processing - Refresh intervals

Worth having this information to hand as I always tend to forget the default refresh intervals.
They are:

Standard computers - every 90 minutes with a random offset of 0 to 30 minutes. GPO for computers is also updated whenever a restart is performed.

Domain Controllers - every 5 minutes.

This can then be configured differently using GPO:

• Computer Configuration - Administrative Templates - System - Group Policy- Group Policy refresh interval for computers
• Computer Configuration - Administrative Templates - System - Group Policy - Group Policy refresh interval for domain controllers

The refresh interval can be as small as 0 minutes (which means it refreshes every 7 seconds), and as large as 45 days.

Refresh offset times can also be changed for between 0 minutes and 24 hours.