The Key to My Mind (11/12) a CC image from Tony the Misfit's Flickr stream

The private key is supposed to be private. It is what proves that the services and the certificate belong to each other. As an attacker you want to obtain this key in order to spoof the identity of the service.

When you import a certificate with private key or generate a private key via the Microsoft Crypto API (CAPI) you can mark it as non-exportable. But are these keys really non-exportable or is this just a GUI option to give administrators a false sense of security?

In order to find out how an attacker can export a non-exportable key RSA key, we need to dive into the CAPI calls.

Disassembling the CAPI functions shows that there are flags in memory that specify that the key is not exportable. It appears that these flags are stored on the same memory location and user the same function. And you can actually temper with this information and set these flags back to being exportable.

The situation is a bit different in the CAPI: Next generation (CNG). Again a disassembly of these functions shows that the CliCryptExportKey() via the c_SrvRpcCryptExportKey function get the private key from the KeyISO or KeyIsolation RPC service that is meant to isolate the RSA keys from the client memory.

It turns out that the memory of the lsass.exe process can reliably be manipulated to make the SPPkcs8IsKeyExportable function return 1 and thus allow the key to be exported.

In both CAPI and CNG the offsets to the flags are the same across the last 11 years of Microsoft products.

Jason has demonstrated the technique live on stage.

The code as well as the slides will be released to the www.blackhat.com website together with the presentation slides shortly.

Conclusion:Non-exportable keys are a GUI feature, they do not prevent a attacker from getting the key, they just slow him down.

But what if you have an issue with NFS and you need a network dump? 

In ESXi tipically you don’t have a local datastore where you can write files from the network dump and your datastore over NFS is not availabe!

Before running into the Data Centre and stick a USB disk or even better a SCSI disk you might want to try this.

One trick I used that worked out pretty well for me, with a little help of my a linux machine, is to send the tcpdump output to a FIFO and from a remote host (might be a VM in a different ESXi host) over SSH cat the FIFO to a local file.

How To:
On the ESXi host logon via SSH as root and create a named pipe:

root@yourESXihost# mkfifo /tmp/pipe.dmp

and from a remote linux machine launch the following:

you@yourlinuxhost > ssh root@youresxihost "cat /tmp/pipe.dmp" > capture-for-wireshark.cap

Now from a new ssh session to ESXi as root lauch

root@yourESXihost# tcpdump-uw -n -s 1524 -i vmk# -w /tmp/pipe.dmp

OR even better from the remote machine:

you@yourlinuxhost > ssh root@youresxihost "tcpdump-uw -n -s 1524 -i vmk# -w /tmp/pipe.dmp"
(replace the # with the proper vmk port number)

Reproduce your issue and when you finished just hit  “Cotrol+C” to stop the network dump and the cat.
Now you can open your file directly in wireshark (that’s what I use at least!)

This little trick of course can be used to troubleshoot network problems in a VM as well, dumping the traffic from a VMK# nic for the entire dvPortGroup. You just need to make sure that the the VM’s vNIC and the vmk# nic are connected to the same dvPortGroup and you must remember to allow promiscuous mode (not allowed by default)

Good Luck!

Please note: your network can be very chatty so the file can grow very fast and/or your ESXi host might not like the tcpdump so use it at your own risk and only if you really know what you are doing!

The MSS: settings used to be here...

I recently got involved in a project where I defined the Baseline Security settings for windows and Linux. I used the settings provided by the Center for Internet Security (CIS).

We decided on the following approach:

• Based on the CIS templates we created a baseline document specific to our company
• I, in my security role, created a Nessus .audit file, so we could audit compliance to our own baseline with Seccubus
• The windows administrator created GPOs to apply the settings.

When creating in the GPOs we did a strange discovery. In a windows the settings that are normally marked as MSS: in the category Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options do not appear in a domain if its functional level is Windows 2008.

This made us wonder, have these setting become irrelevant ? If this is not the case, how can we still set them, preferably via group policy?

The settings are not irrelevant, as e.g. Peter van Eeckhoutte’s blog points out. Windows 2008 does not forward IPv4 packets that have source routing on them,  but it does accept them if the machine is the final destination. However for IPv6 Windows 2008 will forward these packets by default.

So if the settings are not irrelevant, how can we apply them if they are not in the Group Policy Editor? For this purpose we created an .adm file, which can be loaded into the Group Policy editor as a Classic Administrative template.

All the MSS settings can be controlled with this Administrative template. When we applied these settings we reached our desired compliancy with our own baselines.

Mission Accomplished!

So what are these MSS setting and what do they do?

My main objective in watching the webcast (which is not my usual habit) was to find out if systems that have the described workaround applied still need to apply the patch. The webcast did not give a definitive answer but this YouTube video and the Netifera website and the twitter accounts Thai Duong provide the answer: Yes you should apply the patch a.s.a.p!

Click here to view the embedded video.

However the Q&A section of the talk did give me, as a security operations guy, quite some food for thought. I made some notes in my own Twitter feed, which I have summarized here.

Q: Why did Microsoft release and OOB update for a vulnerability rated “only” as important?
A: The vulnerability itself is rated as Important because it is not a vulnerability that directly leads to remote code execution on the vulnerable system, however exploitation of the vulnerability will lead to disclosure of all information in the webroot including web.config. This information can be used for session hijacking, compromising backend databases and to attack associations between websites, e.g. the association of a website with PayPal. Hence an out of band patch was warranted.

Q: Why only release to the download center and not to WSUS etc?
A: We felt we needed to get this update out quickly, the people that need to apply this patch quickly are mainly enterprises who are capable of applying patches without the aid of WSUS. Developing the WSUS capabilities would add another few days of delay to the deployment of this patch.

Q: Is the attack actively used?

A: We have seen limited attacks against this vulnerability as well as continuous efforts to to bypass installed workarounds.

Q: Can the patch be uninstalled, does it require a reboot?
A: The patch can be uninstalled and does require a reboot.

Q: If you have multiple versions of .Net installed on the system, do you need to install all patches for each version of .Net?
A: Yes.

Q: If you have 64bit and 32bit version of Asp.Net installed, do you need to apply both 64bit and 32bit patches?
A: No, the 64bit patch will patch the 32bit versions as well.

Q: Should we regard the ASP.NET MachineKey as compromised?
A: Yes, if you have set a static MachineKey it is recommended to replace this key with a new key. (Information on AutoGenerated MachineKeys was not provided)

Q: Will the patch have an effect on end-users?
A: Yes, information stored on the client that is protected by the MachineKey can no longer be validated. This can e.g. mean that users whoo used a ‘remember me’ function will have to login in again.

Q: Does the patch need to be applied to all nodes of a cluster?
A: Yes, because the patch changes the way data in transit (such as e.g. viewstate) is encrypted, this patch needs to be applied to all nodes in a cluster as the same time or users may experience unexpected results.

Q: Does the patch change IIS?
A: No, the patch only changes ASP.NET, not IIS.

Q: Does the patch change the way encrypted data is stored on the server?
A: No, the patch changes the way data in transit is cryptographically protected, both encryption and signing is now applied. It does not effect any encrypted data stored on the server.

Q: Are the patches in the download center “smart” enough to know if they are applicable for the machine you apply them to?
A: No, detection capabilities will be built into the patches once they are deployed to WSUS.

Q: Should the update be applied to all .net installation, not just web servers?
A: The vulnerability only manifests itself via web servers. For now it is recommended to only install patches there, and way for the patches to appear in WSUS before patching other .net installs. But remember a system with an unpatched .net installation will become vulnerable as soon as a webserver is installed.

Q: Should the workaround be removed prior to patching?
A: No, you can apply the patch with the workaround in place. If you need to do so you can then remove the workaround after the patch has been applied. CustomErrors generally does not hurt and neither does UrlScan all though UrlScan is known to break SharePoint and may break other web applicaitons as well

Q: Do customer applications need to be recompiled?
A: No.

Scott Guthrie’s blog has an excellent overview of which patch is applicable to which platform.

lolcat adaptation #3, a Creative Commons Attribution No-Derivative-Works (2.0) image from kevinsteele's photostream

Exploit wednessday ois the day after patch Tuesday, the second Tuesday of the month when Microsoft releases its patches. While some people say it’s impossible to write an attack in one day, Yaniv has seen it happen and tries to explain how.

This process is based on diffing. Diffing means finding the differences between the old and the patched version of the binary file.

This could be done on the same machine, or between two different versions of the OS (e.g. Windows XP and Vista).

The toolkit for a typical patch analysis consists of:

• Diff programs
• Compare programs
• Decompiles  and compilers
• Different versions of windows

Yaniv, then went off to demonstrate a to us the creation of an exploit for MS10-005.

First of all information from public source was gathered to find out which program was effected, what the root cause of the vulnerability was and in which version of Windows the problem is present.

The next part is extracting the patch and analyzing it. First this that needs to be done is finding the files that will be updated. The these files will be compared against the original file, just to find which functions have been changed.

The changed function are then converted to execution graphs which are colored to highlight the amount of change in that part of the code. This is used to determine the interesting area’s of the code. These interesting area’s are then compared byte by byte and the differences analyzed.

If we need to understand how the vulnerability work in order for us to determine how to write the exploit. Since MS10-005 deals with integer overflow in paint using the the jpeg format, understanding if the understanding of the jpeg format is crucial.

Using this knowledge a denial of service exploit could be generated. Yaniv showed us the process in real life.

# 20091218 – vo.o1 – PZO    – Initial hack to delete hardware profiles in Windows Vista/7
#
#————————————————————————————————————————————–
# Let’s see which profiles exist..
#————————————————————————————————————————————–
$i = 0
Write-Host “”
Write-Host “The following hardware profiles have been found on this computer:” -f white
foreach ($profile in (ls -path “HKLM:\SYSTEM\CurrentControlSet\Control\IDConfigDB\Hardware Profiles\”) ) {
Write-Host 000$i – (get-itemproperty -path “HKLM:\SYSTEM\CurrentControlSet\Control\IDConfigDB\Hardware Profiles\000$i”).FriendlyName
$i++
}
#————————————————————————————————————————————–
# Now we can ask which to remove..
#————————————————————————————————————————————–
Write-Host “”
Write-Host “You are strongly advised not to remove profile 0000 – New Hardware Profile” -f red
Write-Host “”
$input = read-host “Which profile is causing you headaches and should be removed?”
Write-Host “deleting.. “HKLM:\SYSTEM\CurrentControlSet\Hardware Profiles\$input”"
Remove-Item -Path “HKLM:\SYSTEM\CurrentControlSet\Hardware Profiles\$input”

Finally: do _not_ remove profile 0000 unless you know what you are doing. YMMV!

[BBG]

While doing a performance test on one of our customer environments we observed the impact of TCP offload and “Receive Side Scaling” (RSS) settings on the interface card on Windows web servers in combination with traffic handling.

Setup:

1. 2x Mercury Load Runner generators hitting public URL of customer

2. Served by 3x Windows2003 SP2 servers, running IIS6

3. Load being balanced by Cisco CSS11503 to web farm.

The CPU performance graph of the web servers with TCP offload and RSS enabled on the internet facing (FRONT) interface:

Similarly but a more outdated graph even more clearly showing that traffic is alternating from one web server to another:

Most interesting right!?

What makes this traffic to alternate if the load balancer has been set up to distribute the load evenly across the farm resp each Load Runner vuser to clear its cookies and session cache after each request?

We then stumbled over this read, knowing that TCP offload to network card is a classic one , but still:
http://blogs.msdn.com/psssql/archive/2010/02/21/tcp-offloading-again.aspx

And found out the characteristic that when TCP offload and RSS were disabled, the load is more evenly spread across the web farm:

I find this pretty cool.

Any comments?

Find out how

To prepare for a specific monitoring user follow these steps:

Create a monitoring profile

Now create your monitor (in the authoring section).
See for basic instructions on how to create a monitor one of my previous posts: http://www.cupfighter.net/index.php/2009/10/check-your-sql-backup-automatically/

Here is a sample script with some basic options for passing the output to the eventlog and to SCOM itself to set the state of the monitor and generate alerts. The script also contains some code to determine the user account that is used.

Option Explicit
Dim checkdotcomma, strStatus
Dim objAPI, propertyBag
Dim objWMIService, colProcesses, objProcess
Dim strCurrentUser, User, Domain, strUserList

On Error Resume next
Const EVENT_TYPE_ERROR = 1
Const EVENT_TYPE_WARNING = 2
Const EVENT_TYPE_INFORMATION = 4

‘ Check if we are using the correct user for this check
Set objWMIService = GetObject(“winmgmts:{impersonationLevel=impersonate}!\\.\root\cimv2″)
Set colProcesses = objWMIService.ExecQuery(“select * from win32_process where Name=’cscript.exe’”)
For Each objProcess in colProcesses
If objProcess.GetOwner (User, Domain ) = 0 Then
strCurrentUser = “Script has run under account: ” & Domain & “\” & User
Else
strCurrentUser = “Problem getting the owner for process ” & objProcess.Caption
End If
strUserList = strUserList & strCurrentUser
Next

Set objAPI = CreateObject(“MOM.ScriptAPI”)
‘ perform check on regional settings if numbers are using dots or commas
‘ replace this with your own code you want to run
checkdotcomma = Mid(1/2,2,1)
If checkdotcomma = “.” Then
strStatus = “Ok”
Call objAPI.LogScriptEvent(“CheckDotComma”,2000, EVENT_TYPE_INFORMATION,”Regional Settings are using a Dot (.). The user list is ” & strUserList )
Else
strStatus = “Error”
Call objAPI.LogScriptEvent(“CheckDotComma”,2001, EVENT_TYPE_ERROR, “Regional Settings are using a Comma (,). The user list is ” & strUserList )
End if

‘ return status to monitor
Set propertyBag = objAPI.CreatePropertyBag ()
Call propertyBag.AddValue (“Status”, strStatus)
Call propertyBag.AddValue (“checkdotcomma”, checkdotcomma)
Call objAPI.Return(propertyBag)

Download the System Center Operations Manager 2007 Authoring Console

http://www.microsoft.com/downloads/details.aspx?FamilyID=6c8911c3-c495-4a03-96df-9731c37aa6d7&displaylang=en

To make it bit more nice, export your management pack, and look up the Secure References.
Replace all instances of the SecureReference ID with a more readable format, see below.

<SecureReferences>
      <SecureReference ID="MonitoringUser" Accessibility="Internal" Context="System!System.Entity" />
    </SecureReferences>


Reimport your managementpack and you are all set.

I figured to remove and reinstall, keeping the database and logs, but every reïnstall kept failing and bombing at about 90% out with a dialogue box stating ‘there is something wrong with your installation package’. As I knew for sure the package was fine (I did try both the SP1 and SP2 install..) it must be something else.

The logfile MWusSetup.log located in the Windows temp folder mentioned: ERROR CustomActions.Dll  RemovePsfsip: Failed to load dll  (Error 0x8007007E: The specified module could not be found.)

After a little googling, I found a lot of references, but not one fully working solution.

What worked for me is this (reboot after every step):

Removed all dotnet installs using a MS utility cleanup_tool.exe
(http://blogs.msdn.com/astebner/attachment/8904493.ashx)

Stop and remove the WsusCertService using the 2003 resource kit utility instsrv.exe
(http://www.microsoft.com/downloads/details.aspx?FamilyID=9D467A69-57FF-4AE7-96EE-B18C4790CFFD&displaylang=en)

Cleaned the registry using ccleaner.
(http://www.ccleaner.com)

Reïnstalled .Net3.5SP1
(http://download.microsoft.com/download/2/0/e/20e90413-712f-438c-988e-fdaa79a8ac3d/dotnetfx35.exe)

Removed the wsus mmc cache files in my profile directory.

This finally allowed me to reïnstall WSUS.

[BBG]

Recently we started evaluating Citrix Edgesight, on a enviroment we are currently building, consisting of XenApp5 2008 x64 and XenDesktop 4 Farms.

After the installation of the EdgeSight agent, suddenly a bunch of applications running within a Java Virtual machine stopped functioning. Throwing the “Could not launch the java virtual machine” error.
These Java apps tried allocating quite some memory using these java arguments (eg: XX:MinHeapFreeRatio=20 -XX:MaxHeapFreeRatio=35 -XX:NewRatio=2″   initial-heap-size=”32m” max-heap-size=”1024m”)

After some investigation a colleague (Hugo Trippaers) found out that there was only 0,9 GB of memory allocatable on our Citrix XenApp machines using the memtest32.exe tool. While our other servers happily reported 1,5 GB of allocatable memory (Within WOW64). (Physical Machine = HP DL380G6 with 48 GB of memory, uh should be enough?)

After some deeper digging using memalloc.exe, I discover some substantial differences in memory allocation between our XenApp Servers with the edgesight agent installed and servers without the EdgeSight agent.

XenApp servers with Edgesight Agent 5.2 SP1 x64: memalloc.exe with edgesight
XenApp Servers without edgesight: memalloc.exe – without edgesight

The main difference here is all the Citrix hooks being loaded, see below.
This apparently consumes so much memory that it was not possible for java to allocate enough memory.

For more insights on WOW64 look here:  http://blogs.msdn.com/gauravseth/archive/2006/04/26/583963.aspx

By default 32bit applications within WOW64 can leverage the full 4 GB of memory availlable, which is not possible on a native 32 bit system because of the separation of kernel and user space.
Applications need to be compiled with /largaddressaware (Visual Studio : http://msdn.microsoft.com/en-us/library/wz223b1z(VS.80).aspx) or patched using editbin (http://bilbroblog.com/wow64/hidden-secrets-of-w0w64-ndash-large-address-space/), to fully use the 4 GB availlable otherwise they can only allocate 1,6 GB of memory.

We will open a case with Citrix on this; to be continued.

Citrix hooks being loaded when edgesight is installed:

Address 61200000, length 1000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\EdgeSight\Agent\Agent\Core\rsintcor32.dll
Address 61201000, length 18000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\EdgeSight\Agent\Agent\Core\rsintcor32.dll
Address 61219000, length 9000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\EdgeSight\Agent\Agent\Core\rsintcor32.dll
Address 61222000, length 1000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\EdgeSight\Agent\Agent\Core\rsintcor32.dll
Address 61223000, length 4000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\EdgeSight\Agent\Agent\Core\rsintcor32.dll
Address 61300000, length 1000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\edgesight\agent\agent\edgesight\esint32.dll
Address 61301000, length 8000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\edgesight\agent\agent\edgesight\esint32.dll
Address 61309000, length 3000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\edgesight\agent\agent\edgesight\esint32.dll
Address 6130c000, length 1000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\edgesight\agent\agent\edgesight\esint32.dll
Address 6130d000, length 2000, state 1000 MEM_COMMIT, type 1000000 module e:\program files\edgesight\agent\agent\edgesight\esint32.dll
Address 67f60000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\CtxSbxHook.DLL
Address 67f61000, length 58000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\CtxSbxHook.DLL
Address 67fb9000, length a000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\CtxSbxHook.DLL
Address 67fc3000, length 4000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\CtxSbxHook.DLL
Address 67fc7000, length 7000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\CtxSbxHook.DLL
Address 6db20000, length 1000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2\MSVCR90.dll
Address 6db21000, length 96000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2\MSVCR90.dll
Address 6dbb7000, length 1000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2\MSVCR90.dll
Address 6dbb8000, length 2000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2\MSVCR90.dll
Address 6dbba000, length 4000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2\MSVCR90.dll
Address 6dbbe000, length 5000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc90.crt_1fc8b3b9a1e18e3b_9.0.30729.4148_none_5090ab56bcba71c2\MSVCR90.dll
Address 751e0000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\twnhook.dll
Address 751e1000, length c6000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\twnhook.dll
Address 752a7000, length 3000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\twnhook.dll
Address 752aa000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\twnhook.dll
Address 752ab000, length e000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\twnhook.dll
Address 752b9000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\twnhook.dll
Address 752ba000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\twnhook.dll
Address 752bb000, length 6000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\twnhook.dll
Address 752c1000, length 5000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\twnhook.dll
Address 75320000, length 1000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4016_none_d0893820442e7fe4\MSVCR80.dll
Address 75321000, length 63000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4016_none_d0893820442e7fe4\MSVCR80.dll
Address 75384000, length 2b000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4016_none_d0893820442e7fe4\MSVCR80.dll
Address 753af000, length 1000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4016_none_d0893820442e7fe4\MSVCR80.dll
Address 753b0000, length 1000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4016_none_d0893820442e7fe4\MSVCR80.dll
Address 753b1000, length 1000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4016_none_d0893820442e7fe4\MSVCR80.dll
Address 753b2000, length 1000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4016_none_d0893820442e7fe4\MSVCR80.dll
Address 753b3000, length 3000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4016_none_d0893820442e7fe4\MSVCR80.dll
Address 753b6000, length 5000, state 1000 MEM_COMMIT, type 1000000 module C:\Windows\WinSxS\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4016_none_d0893820442e7fe4\MSVCR80.dll
Address 753c0000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\scardhook.dll
Address 753c1000, length 1d000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\scardhook.dll
Address 753de000, length 4000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\scardhook.dll
Address 753e2000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\scardhook.dll
Address 753e3000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\scardhook.dll
Address 753e4000, length 3000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\scardhook.dll
Address 753f0000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\wdmaudhook.dll
Address 753f1000, length 2000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\wdmaudhook.dll
Address 753f3000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\wdmaudhook.dll
Address 753f4000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\wdmaudhook.dll
Address 753f5000, length 2000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\wdmaudhook.dll
Address 75400000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\System32\cxinjime.dll
Address 75401000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\System32\cxinjime.dll
Address 75402000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\System32\cxinjime.dll
Address 75403000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\System32\cxinjime.dll
Address 75404000, length 2000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\System32\cxinjime.dll
Address 75420000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\Sfrhook.dll
Address 75421000, length 2000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\Sfrhook.dll
Address 75423000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\Sfrhook.dll
Address 75424000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\Sfrhook.dll
Address 75425000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\Sfrhook.dll
Address 75426000, length 2000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\Sfrhook.dll
Address 75430000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mmhook.dll
Address 75431000, length f000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mmhook.dll
Address 75440000, length 2000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mmhook.dll
Address 75442000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mmhook.dll
Address 75443000, length 3000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mmhook.dll
Address 75450000, length 1000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mfaphook.dll
Address 75451000, length 2c000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mfaphook.dll
Address 7547d000, length 9000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mfaphook.dll
Address 75486000, length 4000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mfaphook.dll
Address 7548a000, length 4000, state 1000 MEM_COMMIT, type 1000000 module E:\program files\Citrix\system32\mfaphook.dll

Since the root CA is in another domain then the issuing CA, it took some fiddling and tweaking around with my CDP and AIA extensions, but that is another blogpost all together.

I knew I was in for some fun when when the following happened:

• I installed my Issuing CA and generated the certificate request
• I issued the request to my Root CA and generated the Issuing CA certificate
• I tried to install the Issuing CA certificate and got the following error:

Cannot verify certificate chain. Do you whish to ignore the error and continue? The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2168885613)

My first reaction was to call one of the network guest and notify him that I needed http access to the Issuing CA to the CDP location. But whil on the phone, I decided to try and to my surprise I was actually able to manually pull down the crl.

Intregued, I decided to check a few things:

• I could download the CRL from both CDP locations with Internet Exporer
• I could open the downloaded CRLs
• I could telnet to port 80 of the both webservers
• I could telnet to port 80 manually issue the GET /crl/CRLname.crl HTTP/1.0 command and get data back

O.K. what is going on here… Lets open PKI view, which is now included in Windows 2008 and Vista and can be downloaded for Windows 2000 and 2003.

It seemed that PKI view as in agreement, it too could not download the CRL from the CDP location

PKI view shows "Unable To Download" for both CDP locations

This did sent me on a wild goose chase:

• Microsoft own documentation, clearly blames it on unavailability of the CDP location, something I, by now, had triple checked four times and refused to believe
• This “Network Builders” forum and many others, simply suggest to turn off revocation checking, but that is clearly not a worthy solution either.
• Apparently there is also an issue with serving delta CRLs threw IIS because the + sign at the end of the basename of a delta CRL file leads to so called “double escaping”. I could rule this out by looking at the IIS logs.
• In the end this technet forum post, about OCSP reponders Brian Komar points out:

But, as stated, I would use certutil to get the “best” answer on how is my configuration.
Certutil -verify -urlfetch “certfile.cer” will check *every* CDP and AIA URL (including OCSP) and tell you how they are all doing *at that specific instance in time” since it goes to the URLs immediately.
Brian

I exported the Issuing CA certificate from the certificate database of the Root CA and ran the command against is and this is what I found

E:\>certutil -verify -urlfetch <certfile>.cer
Issuer:
CN=Root CA
Subject:
CN=Issuing CA
Cert Serial Number: 115d5f6400020000000b
<snip>

—————-  Certificate AIA  —————-
Verified “Certificate (0)” Time: 0
[0.0] http://IIS1.domain1local/crl/Root-CA.crt

Verified “Certificate (0)” Time: 0
[1.0] http://IIS2.domain1.local/crl/Root-CA.crt

—————-  Certificate CDP  —————-
Wrong Issuer “Base CRL (13)” Time: 0
[0.0] http://IIS1.domain1.local/crl/Root-CA.crl

Wrong Issuer “Base CRL (13)” Time: 0
[1.0] http://IIS2.domain1.local/crl/Root-CA.crl

<snip>
E:\>

So while PKI view and the other error messages I was getting all pointed to the most common cause, it actually turned out that the CRl did get downloaded, but was not cryptographically relevant to what the system believes is the Root CA certificate.

Root cause

Inspection of the CRLs generated and the Root certificates installed showed what had caused the problem. In order to test the CDP extensions I had reissued the Root CA certificate, causing the Root CA to have three active certificates. Each with a different key.

This CA has three CA certificates

When validating the Issuing CA certificate, validation would end at the last certificate issued, however the CA still signs its CRLs with the key pair of the first certificate.

I guess for me there is nothing left but to reinstall the entire chain.

Together with another 7000 techies, this is a week of planning, running, eating, experiencing all kinds of (new) technologies presented by Microsoft guys.

Feeling some blisters already, because I’m not used to running so much on a day, especially with a Lenovo T500 on my shoulder. The Berlin Messe is a huge place. But the overall sense of the MCE’s is that we are enjoying the sessions. Not all session are that good, but for instance Mark Minasi is good fun to watch and hear.  The food and beverages (very important) are good and plenty.
Technically we are not always that challenged, in many occasions the depth is lacking, but then again, it is a mass-event and not everybody is a (potential) MCE.

On Monday MS presented a Keynote, and all of us were very disappointed. Nothing new, lots of marketing blabla. Cloud computing (Azure) was the keyword here. (Literally, we counted over 100 times them using the word “cloud”.)
Reading back this sounds a bit negative, but in fact, we are having a good time. Discussing a lot about the statements made in the session, exchanging the different sessions we’ve attended, thus learning a lot. Even writing the blogs is a good learning curve. We are all cupfighters, and don’t want to blog rumors and rubbish, so for each post we do a thorough background check.
Berlin sightseeing is mainly done via U and S-bahn, ample time to discover the city (this is in case our bosses are reading this post .

We’re looking forward to the Country drink on Thursday, organized by our employer together with Microsoft (http://www.schubergphilis.com/countrydrink).

If you’re Dutch IT-pro, come and join us there. You will find the Schuberg Philis style of organizing a party is an experience not to be missed!

Next couple of days more sessions, and we’ll keep you posted if we hear some nice things.

WAIK 2.0 comes with some new tools like DSIM.exe which is a combination of previous WAIK tools like Pkgmgr.exe, Intlcfg.exe, PEimg.exe and has basic functionality to mount and maintain Windows images (either WIM or VHD file format) by adding or removing device drivers, patches, software packages etc..

Other new features in this toolkit:

• BCDboot is a new tool used to quickly set up a system partition, or to repair the boot environment.
• USMT. User State Migration Tool used for doing an in place migration while maintaining all user data and settings.
• Volume Activation Management Tool. Manages volume activation of Windows clients using a Multiple Activation Key (MAK)
• Hardware recognition and driver injection (also during pre-installation stage while booting from WinPE).
• Create image files for media-based deployments from existing deployment shares (WIM and/or ISO image files).

It supports deployment of Windows XP, Vista, Windows 7, Windows Server 2003/2008/2008 R2

Read more about MDT 2010:
http://technet.microsoft.com/en-us/solutionaccelerators/dd407791.aspx

What’s new in MDT 2010 (link to Word doc):
http://go.microsoft.com/fwlink/?LinkId=163309

Of course there was a warning, as all speakers must have done the last couple of years, about the `ending` of IPV4. We are running out of ip addresses, we’ve heard that before.

Here you will find a nice link of where Geoff Huston is predicting the end of time:http://www.potaroo.net/tools/ipv4/index.html 

And in fact, we cannot ignore this. It will happen. And I want to be prepared, so that’s why I attended this session. I cannot longer sit back and hoping this would only happen when I’m retired. (and the Dutch government is not helping as well, as they have decided to extend pensioning from 65 to 67 years..)

Windows has already implemented the IPV6 stack from 2003 (and XP sp2) onwards and IPV6 from Vista onwards is the preferred protocol by default. Of course you can disable this, but in Win2k8 IPV4 is built on the IPV6 stack, so even when you disable IPV6, you’re always able to ping your local-home-address (::1).

Something I found during my research: Exchange 2003 on Windows 2008 needs IPV6, unless you disable it via a reghack (http://msmvps.com/blogs/ehlo/archive/2008/06/12/1634433.aspx).

You need to understand the principles (doh…) but networking is a piece of cake with IPV6

IPV4 is all about routing, IPV6 is all about shouting, was a statement of Mark Minasi.

Motivators to use IPV6:

• China is knocking at the internet-door.
• All European car-manufacturers have agreed to implement IPV6 in their cars as the standart protocol for car applications. (so beware, breaking will done via commands transported via IPV6..)

I don’t want to get in detail here, plenty of explanation on the web, but the modern OS-es all are capable of doing IPV6, and certainly I will dive deeper into this.  

You should too.

Happy scripting!

PowerShell drives for AD will simplify navigation in AD Directory Services. And most of all: certain tasks can only be achieved through PowerShell hurrah for the shell.

AD Web services (ADWS) will create a web service ‘gateway’ for managing windows 2008 R2 servers through PowerShell. Be sure you have port 9289 opened on the firewalls and your home free.

For backward compatibility Active Directory Management Gateway Service (ADMGS) is available for Windows Server 2003 and 2008, however this does not support instances of AD Mounting Tool (get-PSdrive)

AD Administrative Center
The users and computers interface is enriched by progressive disclosure of data, which means, the interface builds up navigation history and anticipates on tasks you’re about to do and fill the interface accordingly. Big plus is that you can connect to multiple domains at the same time.

Managed Service Accounts
Currently using built in accounts for services does not provide service isolation. And in case we run the services using standard user accounts with some extensive privileges. But then again, changing services account passwords on a regular basis did cause some unexpected service failures.

So managed service accounts are presented, though the accounts must be created and managed through Windows PowerShell. J. It’s delivered in three steps. The sweet thing is that a reset of the password is done on a regular basis (default by 30 days) by the system itself.

However:
1: Service / application requiring managed account must be running on Windows 7 or Server 2008 R2
2: Managed accounts cannot be shared across multiple servers

The latter is a major setback since the whole security of the password changes are embedded, so why don’t enable it cross hosts, so keep it simple and transparent does not apply here.

Djoin.exe
Now, Windows 7 or Windows 2008 R2 machines can be joined to a domain while offline, it’s not PowerShell driven though. During deployment the machine has already domain joined the domain at startup, so no reboot required. This will definitely speed up deployment of VMs and scripted installs. The sysprep process will create a new section in unattended.xml to supports offline domain joins which will actually simplifies domain joins to RODCs.

Recycle Bin for AD
Here it is: a fast and decent failsafe of accidently deletion of AD objects; the recycle bin for AD.
You need to promote to 2008 R2 Forest functionality and, of course, it’s PowerShell driven.
Bear in mind, once enabled it cannot be disabled, but then again, it restores all attributes including linked attributes.  Of course it will impact storage, but no more than 5 -10% increase of the AD database. Here is how it will work:

In this interactive lab I learned how to install and configure SQL 2008 on Windows 2008 R2 Core, which has the following technical advantages and characteristics:

-          Running on R2 Core instead of normal setup, limits the need of patching and maintenance of a SQL OS to the minimum R2 core components updated, minimizing the instance downtime.

-          Running several SQL instances is possible as it is on the GUI enabled full OS setup.

-          All installations and configurations needs to be done using Powershell cmdlets, which are limited to installation of .Net framework 3.5, configuring windows firewall to allow 1433 and installing base components of SQL 2008, and of course the GUI components of SQL including management studio is not to run from the R2 core and the instance needs to be managed by remote machine.

-          It makes the life really easy to prepare an R2 image with pre-installation of SQL 2008 using Sysprep for fast deployment of an SQL Server. We have reached an OS/SQL deployment time of 5 minutes in the lab.

-          Running on R2 core is has also security advantages for SQL Server instance as major windows vulnerabilities are related to higher levels and Windows 2008 core is mostly not affected.

-          It is possible to cluster an SQL instance running on R2 core.

-          This implementation is not supported by Microsoft at this moment, but several factors shows it will be supported in the near future.

The how to guide will be shortly available on Codeplex. If not, I will add an installation guide to this blog too.

It was amazing to see that you are actually able to connect to an online SQL server cloud using the normal SQL management studio connecting to the database engine using the FQDN. The SQL Gateway which is manageable by an online web interface and includes all security and firewall settings for the SQL Cloud, the redirector layer which load balance T-SQL traffic and the underlying SQL Fabric which serves the cloud, is fully transparent to the SQL management studio and system administrators can manage all futures of SQL as they do in the normal in-house setups.

The V1 version is targeted for non mission critical SQL databases for middle and large organizations, in the first quarter of 2010 the V2 release will target the mission critical SQL needs and some features like snapshot and restore to the specific point of time, and using multiple database connections using USE <db> which is not available at this moment, will be added.

It is possible to use this service based on “on demand” resource needs, meaning at an specific period of time the database load can be balanced on virtually unlimited resources where the gateway billing mechanism is aware of this short recourse peak time.

There are rumors that the SQL cloud computing technology will also be available for third party organizations in the near future.