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.