Disable BitLocker Active Directory Dependency

Let’s imagine that you have a Windows 7 system that was imaged.  Let’s imagine that the image is designed to easily connect to your infrastructure’s domain.  Let’s also imagine that you don’t want to add this particular system to your domain; you just want to use this system for a separate purpose, but save time by using your primary Windows 7 image.  Let’s also imagine that you want this system to have BitLocker enabled.  Your system meet’s all of Microsoft’s BitLocker requirements, but when you try to enable BitLocker, you get a nasty: BitLocker could not contact the domain.  Ensure that you are connected to the network or contact your system administrator error.

At this point, you have done a ton of research on how to turn off the Active Directory dependency for BitLocker, but have yet to find a solution.  Before you jump off the roof of your building, read below as I have your solution:

  1. Open gpedit.msc
  2. Navigate to: Computer Configuration > Administrative Templates > System > Trusted Platform Module Services.
  3. Disable the setting: Turn on TPM backup to Active Directory Domain Services.  This is probably the evil setting that is causing you all the problems.  But, just in case, continue on to the steps below anyway.
  4. Navigate to: Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption.
  5. Disable the setting: Store BitLocker recovery information in Active Directory Domain Services (Windows Server 2008 and Windows Vista).
  6. You may need to disable 1 more setting.  Navigate to: Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives.
  7. Disable the setting: Choose how BitLocker-protected operating system drives can be recovered.

Once all those Group Policy settings are disabled, your non-domain connected PC should have no (AD related) problems setting up BitLocker.

Solution for Viewing Blocked Media Content on Flash 10.1 Devices?

Recently, an increasing number of media companies have been blocking access to Flash 10.1 content on non-PC devices (i.e. Android Phones, Google TV, PS3, etc.).  The reasoning for this makes no sense as I can plug my laptop into my TV and watch sites like Hulu, Fox.com, and NBC.com content without any problems.  However, doing so on a game console, Google TV device, or even an Android Phone is somehow different in their view.  It shouldn’t be a DRM issue either, as that should be handled by the Flash player itself.

Oh well.  In the past, this could be worked around by simply altering the user-agent string on the browser.  In this case, the browser would basically lie to the server and trick it into thinking that it’s running on a PC web browser.  As a result, the content would play just fine.

However, that no longer works.  Instead of simply relying on the user agent string of the browser, they are now also looking at the version of Flash Player running on the device.  A string of the version of Flash you are running is sent to the server to check if you are using a “supported device.”  You can find out what your Flash version string is by visiting this page: http://kb2.adobe.com/cps/155/tn_15507.html.  Visiting that page should show you something similar to this:

Screenshot of the Flash Player version string

To verify that this string is actually being sent to the server, I opened up Wireshark and sniffed some traffic on Hulu.  While watching an episode of Hells Kitchen on Hulu, I sniffed for HTTP GET requests.  Below is a screenshot of the TCP Stream for the GET request:

TCP Stream of the GET Request

As you can see from the screenshot above, there are a lot of variables appended to the GET request.  The most interesting one is the: flashPlayer=WIN%2010%2C1%2C103%2C19. This tells the server which version of Flash Player the system is running. If you remove the delimiting characters from the GET request, you would see that the version string matches that of the string in the first screenshot above. If you were running Android, the version string would contain AND instead of WIN.

That is not the only GET request of interest.  Indeed, there are others which contain appended variables declaring the OS, and the browser being used.  All of this information together can identify the device accessing the service.  However, remember that because all of this code is coming from the client, it can be altered.

So, in theory, if we were to replace the Flash Player version (as well as any other string sent to the server that could reveal the identity of the device accessing the service) with known values that work (such as one from an ordinary PC), that device should be able to access the service, since the server thinks the device is just a regular, “supported” PC.

Unfortunately, modification of the packet on-the-fly is the problem.  I cannot find any suitable software that is capable of making these changes on-the-fly to the HTTP packets.  A proxy application would be best suitable for this purpose, as it can change the user-agent-string and potentially other variables within the packet before being sent out to the server.  Unfortunately, I cannot locate any software that would easily give me the granular control needed to make this work.

After looking into Squid, and Privoxy, the best application that I have tested so far is TcpCatcher (http://www.tcpcatcher.org/).  This is a great app that basically combines Wireshark with a proxy server for HTTP connections.  It can even perform find-and-replace functionality within the packet.  Unfortunately, as powerful as the application is, it does not have the ability to find-and-replace more than one variable at one time. For example, to make this work, I would need to change the user-agent string, as well as find-and-replace any instances of flashplayer=, flash=, and even os= with known values that work.  However, this application can only allow one or the other to be changed.  If I change the user-agent string, I cannot perform a find-and-replace on the packet.  Thus, it will not work to fix the problem, as we need to completely mask the identity of the accessing device and trick the server into thinking that it’s just an ordinary PC.

If anyone is able to locate software that can make this work, please post it in the comments.

Fix Java apps not finding Java in 64-bit Windows

For Java apps to run in Windows, a JRE (Java Runtime Environment) must be installed.  If it’s installed, but your Java apps are throwing errors that it cannot find the JRE, then you will need to add an environment variable to point to the Java bin directory.

Here is a screenshot of such an error I received when trying to run the Android SDK:

AndroidSDK error showing that Java is not installed -- Even though it is.

(Also notice the typo in the above message: “Checking it it’s installed in …”)

Below are instructions for fixing this error on Windows 7 x64 with the 64-bit JRE installed:

  1. Click the “Start Orb”, and type: about system
  2. In the search results, you should see “System” appear.  Click on it, and you should have the “View basic information about your computer window” appear.
  3. In that window, on the left hand side, you should see a link to “Advanced system settings”.  Click it.  (Accept all UAC prompts)
  4. The “System Properties” window will appear.  Click the “Advanced” tab.
  5. On the “Advanced” tab, click the button towards the bottom of the window titled “Environment Variables…”
  6. The “Environment Variables” window should appear.  In this window, on the bottom half, you should see a section titled: “System variables”.  Scroll down that list for an entry titled: Path. Click the “Edit” button.
  7. The “Edit System Variable” window should appear.  In this window, select the textbox for “Variable value:”.  Scroll to the end of the entry, and add a semicolon (;) to the end of the line (assuming no semicolon is currently there).
  8. You will then need to locate where your Java bin directory is located.  For me, on 64-bit Windows 7 with the 64-bit JRE installed, it is located in the following path: C:\Program Files\Java\jre6\bin (This is the default location if installing the 64-bit JRE)
  9. Copy and paste the path to the bin directory after the semicolon we just added to the “Variable value:” textbox.
  10. Click OK to all the windows, and your application should work.

Copyright © /sarc All Rights Reserved · Using modified version of Green Hope Theme by Sivan & schiy · Proudly powered by WordPress