Application Pool Identity – The Specified Password is Invalid

I was setting up a web application recently, and it was suffering from the ‘double hop‘ issue whereby the windows authenticated NTLM credentials couldn’t ‘hop’ once more to authenticate with the SQL server back-end (which resided on a remote machine).

I drilled into the Advanced Settings of my application pool and opened up the ‘Identity’ section and selected ‘Custom Account’.  For the username I entered [Domain]\[Username] (a dedicated service account with write access to the SQL server) and entered the password.  To my surprise I received the following error message:

The specified password is invalid.Type a new password.

So naturally I typed the credentials again, and again, to the point where I realised it wasn’t my jelly fingers that were causing the issue!

The issue turned out to be that the username was too long!  And to circumvent the issue without changing the username to something shorter, I navigated to Active Directory Users and Computers, found the user account, opened the user account properties, navigated to the ‘Account’ tab and used the pre-windows 2000 username instead!  And bish, bash, bosh.  It worked!  The error message was misleading to say the least!

Word.Application, Excel.Application – You cannot call a method on a null-valued expression

I was writing a simple PowerShell script to automate parts of a Microsoft Word document.  My sample script was simply:

$alkaneDocumentPath = "C:\Temp\word.docx"
$wordApplication = New-Object -ComObject word.application
$document = $wordApplication.documents.open($alkaneDocumentPath);

But every time I ran it, I got:

You cannot call a method on a null-valued expression.

The error message was implying that $wordApplication was null, when in fact it wasn’t!  So what was going on?  Well to see a more descriptive error message, I made my $wordApplication visible like so:

$alkaneDocumentPath = "C:\Temp\word.docx"
$wordApplication = New-Object -ComObject word.application
$wordApplication.Visible = $true
$document = $wordApplication.documents.open($alkaneDocumentPath);

And this brought me back a much more useful error message:

Exception setting “Visible”: “Unable to cast COM object of type ‘Microsoft.Office.Interop.Word.ApplicationClass’ to interface type
‘Microsoft.Office.Interop.Word._Application’. This operation failed because the QueryInterface call on the COM component for the interface with IID
‘{00020970-0000-0000-C000-000000000046}’ failed due to the following error: Library not registered. (Exception from HRESULT: 0x8002801D
(TYPE_E_LIBNOTREGISTERED)).”

To cut a story short, I’d obtained my laptop from another user who had all sorts of junk installed and more recent copy of Microsoft Office (version 2016).  When the laptop was passed to me, I was reverted to an older version of Office (Office 2010).  And the uninstall of Office 2016 had left unwanted remnants.

My version of Office 2010 is a 32-bit version on a 64-bit operating system and as such installs registry to the WOW6432Node node.  So I navigated to:

HKEY_CLASSES_ROOT\WOW6432Node\Interface\{00020970-0000-0000-C000-000000000046}\TypeLib

and the ‘Version’ value was set to 8.5.  This version corresponds to Office 2010 so I was happy with this.  So I looked at the ‘Default’ value, obtained the TypeLib GUID ({00020905-0000-0000-C000-000000000046}) and navigated to:

HKEY_CLASSES_ROOT\WOW6432Node\TypeLib\{00020905-0000-0000-C000-000000000046}

In here should only be a version subkey that corresponds to the installed version of Office – in my case there should just be a subkey called ‘8.5’.  However there was also a subkey call ‘8.7’ which corresponded to Office 2016!  I simply deleted the 8.7 subkey and re-ran my PowerShell script.  Voila – it breathed into life!!

Incidentally I had the exact same issue instantiating Excel.Application.  The relevant interface GUID was {000208D5-0000-0000-C000-000000000046}, the TypeLib version for Excel 2010 was 1.7 but when I navigated to the TypeLib in the registry it included a subkey for ‘1.9’!  I deleted this subkey and Excel also started working.

Java Not Working In Internet Explorer 11

Recently I spent a few days creating and compiling a Java Deployment Rule Set and signing it with an Active Directory certificate.  After much stress it worked like a charm on my development machine.

I tested some of my rules by using the Java verify page, whereby it displayed the version of Java that the browser was currently using.

However in the Live environment the Java verify page just wouln’t render the Java applet.  I added Java.com to the trusted sites zone, and then I got a grey box in place of the applet.

In the Java control panel I navigated to the Advanced tab and made sure to select ‘Show console’.  The next time I launched a new session of the Java verify page in Internet Explorer I could see what was happening:

Proxy Direct

 

 

 

 

 

 

 

 

 

 

I could see that the proxy was returning as: “proxy=DIRECT”.  This should not have been the case since we were using the default LAN Settings which was configured to use an Auto Config PAC file (a JavaScript file that says “if you’re navigating to this URL, use that proxy etc.).  So it should have been returning a valid proxy from the PAC file.

I changed my LAN setting to use a static proxy/port and re-ran the Java Verify page.  This time it worked and the console showed that it was returning a proxy address!

Since we’d deduced it wouldn’t work with the PAC file, one potential solution was to use Java network settings (Java control panel > General tab > Network settings) to point to a proxy, and leave the LAN settings as the auto config PAC file for all browing in Internet Explorer.  However when I tested this, once again I saw “proxy=DIRECT”!

Upon further testing I noticed that several versions of Java 7 ignore the Java Network Settings! These are:

Java 7u60
Java 7u67
Java 7u71
Java 7u72
Java 7u75

Finally these three versions honour the Network Settings, and the proxy was correctly used:

Java 7u76
Java 7u79
Java 7u80

But you’ll notice I did say that this was a ‘potential’ solution.  It still wasn’t an ideal solution.  Why wasn’t the auto config PAC file returning a valid proxy?  Well, I debugged our corporate PAC file and lo and behold, I noticed a missing semi-colon!

somevariable = “DIRECT”

should have been

somevariable = “DIRECT”;

So Internet Explorer parsed the PAC file ok, and ‘understood’ that there was a missing semi-colon and carried on routing users correctly when they were browsing the internet.  However Java’s parsing of the PAC file was obviously more strict, noticed a semi-colon was missing and consequently failed and reverted to a ‘DIRECT’ connection!  Once I fixed this issue Java in Internet Explorer burst in to life!

Code Signing Certificates, Expiry Dates and Timestamping

When I set about signing a Java deployment rule set with a code signing certificate, I noticed that my certificate had an expiry date of 1 year from the current date.  My initial thoughts were that I didn’t want all these Java applications to suddenly stop working in a years time because my code signing certificate had expired!  But I needn’t have worried.

Why Do Code Signing Certificates Expire

When a code signing certificate expires, you can no longer sign any content with it.  The reason they expire is for security purposes.  If they didn’t ever expire and the certificate fell into the wrong hands, anybody could impersonate your company forever!

Will Signed Content Stop Working When My Certificate Expires?

If you haven’t added a timestamp during the signing process, the signed content will check the certificate expiration date against the current date and fail if the certificate has expired.

However adding a timestamp during the signing process provides verification that the signing took place when the certificate was valid, and your signed content will be valid indefinitely.  Timestamping is a mechanism that ensures your digital signature remains trusted long after your Code Signing certificate has expired.

AppSense Regular Expression for Microsoft Office

I needed to add a new rule to AppSense recently on process start.  I wanted the rule to only run when a Microsoft Office application was run.

Now I usually eat regular expressions for breakfast (with some ketchup on top for good measure).  However I noticed that my regular expression wasn’t working in AppSense and it turned out to be the flavour of Regular Expression that it uses.

You see, I tend to use JavaScript regular expressions or .Net regular expressions.  But AppSense was presumably written in C++ and uses the CAtlRegExp regular expression of the ATL class which is…..lame.  Grouping syntax is different, and so is character matching syntax.

To test my regular expressions, rather than update the AppSense policy and wait for it to deploy to the machine, I just downloaded the regular expression tester from here.

So this was my first attempt – the MfcRegex tool said it was a successful match!  So I plonked it into AppSense:

.*\\Microsoft Office\\Office\d\d?\\((WINWORD)|(EXCEL)|(POWERPNT)|(MSACCESS)|(OUTLOOK)|(VISIO)|(WINPROJ))\.EXE$

But wait!  AppSense tries to be clever and escapes the brackets with preceding backslashes (I noticed this in the client debug logs), so this RegEx was failing because AppSense was evaluating it to this:

.*\\Microsoft Office\\Office\d\d?\\\(\(WINWORD\)|\(EXCEL\)|\(POWERPNT\)|\(MSACCESS\)|\(OUTLOOK\)|\(VISIO\)|\(WINPROJ\)\)\.EXE$

So by this point I was close to throwing my computer out of the window, until finally I used this syntax which works like a charm:

.*\\Microsoft Office\\Office\d\d?\\{WINWORD}|{EXCEL}|{POWERPNT}|{MSACCESS}|{OUTLOOK}|{VISIO}|{WINPROJ}\.EXE$

Notice that I have changed the brackets and slightly altered the syntax.  If you wanted to limit it to a specific version of Office (2010 in my case) you can use a regular expression similar to this:

.*\\Microsoft Office\\Office14\\((WINWORD)|(EXCEL)|(POWERPNT)|(MSACCESS)|(OUTLOOK)|(VISIO)|(WINPROJ))\.EXE$

 

 

Create a Code Signing Certificate using Active Directory Certificate Services

Ok, this post is shameless plagiarism from this post.  But I couldn’t risk losing sight of good content.  Thanks (and apologies) go to David Barrett!

Enable the Code Signing Certificate Template

  1. On the appropriate server (e.g. the CA root), open Certificate Services Manager.
  2. In the left pane, select Certificate Templates.
  3. Check for a Code Signing template – by default, this isn’t available.  If it isn’t, add it:
    1. From Action menu, select New -> Certificate Template to Issue.
    2. Select Code Signing, then click OK.

 Grant Permissions for User(s) to Create Code Signing Certificates

  1. From the Certificate Services Manager, right click Certificate Templates and select Manage.
  2. From the list of templates, right-click Code Signing and select Properties.
  3. Select the Security tab.
  4. Any users that should be allowed to create code signing certificates need to be granted Read and Enroll permissions, so add users and permissions as necessary.
  5. Apply changes.

Create a Code Signing Certificate

  1. On the development machine (logged in as a user who has been granted permissions to create a code signing certificate), open Microsoft Management Console.
  2. From File menu, select Add/Remove Snap-in…
  3. From Available snap-ins, select Certificates and then click Add.
  4. Select My user account, and then click Finish.
  5. OK out of the Add/Remove snap-in window.
  6. You will now see Certificates listed in the console view on the left.  Right-click Personal, select All Tasks, then Request New Certificate.
  7. Click Next on the first screen (Before You Begin).
  8. Click Next on the Select Certificate Enrolment Policy screen (Active Directory Enrolment Policy will be applied).
  9. In the Request Certificates screen, tick Code Signing, and then click Enrol.  A certificate will be created and placed in the user’s Personal store.

Browsium Ion and Authentication

I set up a Browsium rule recently to render a SharePoint 2010 site in IE8 Standards mode.

Without the Browsium rule in place the site loaded fine but one of the Web Parts didn’t work.  However when the Browsium rule was enabled, the Web Part worked fine but the user was prompted for authentication when the site initially loaded!  It was as if Browsium wasn’t passing the Windows authenticated credentials during the request.

Specifying AutoAuth

To resolve the authentication issue we can specify an ION profile flag under Advanced Profile Set which details what credentials are sent to the upstream server when automatically replying to an authentication challenge.

x-AutoAuth=(default)

Browsium AutoAuth

Browsium Ion, HTTPS and Proxy Authentication

I’ve been playing around with Browsium Ion recently and I was testing a HTTPS URL, trying to force the default ‘Edge’ emulation mode to run in ‘IE8’ emulation mode instead.  For HTTP URLs it worked fine.  However with HTTPS URLS, when a new instance of iexplore.exe launched (presumably after being intercepted and spawned by Browsium Ion) the user was prompted for proxy authentication.  Even upon entering correct credentials it still didn’t authenticate.  After clicking ‘cancel’ dozens of times, the authentication prompt eventually went away and we saw the page rendering successfully in IE8 Emulation mode.

Specifying a Proxy Host and Port

To resolve the authentication issue we can specifically provide a proxy host and port (one that authenticates for the user) by adding the following to Advanced Profile Set for the profile in question:

x-overrideGateway=alkanehost:8080

Browsium Proxy

Disable ‘Managed Mode’ in Mcafee

I was testing an app on a Virtual Machine (a P2V of the client build) and I had a feel McAfee was preventing something from functioning.  To test this I needed to disable ‘Managed Mode’ in Mcafee.  This is how I did it:

Step 1: Login in as an admin user

Step 2: Run: c:\Program Files (x86)\McAfee\Common Framework\x86\FrmInst.exe /forceuninstall

Step 3: Reboot into safe mode

Step 4: Open Regedit and delete:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\McAfee\ePolicy Orchestrator\Application Plugins\VIRUSCAN8800

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Network Associates\ePolicy Orchestrator\Application Plugins\VIRUSCAN8800

In

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\McAfee\DesktopProtection

set

UIP to blank

UIPMode to 0

Step 5: Reboot

We can now log back in as an administrator and ‘disable’ McAfee via the VirusScan console (Right-Click ‘Access Protection’, click Disable).

Add a Right-click Context Sub Menu

I’ve been creating a few tools recently for a client – scripted tools which perform specific tasks on MSI (Windows Installer) files. Because we’re likely to create multiple tools and I don’t want the context menu to get too long and too ugly, so I decided to add a right-click context sub menu.  Here’s what it produces:

context

And here’s the registry that made it happen:

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Msi.Package\Shell\AlkaneTools]
"MUIVerb"="Alkane Tools"
"SubCommands"="CustomTool1;"
"icon"="\\\\server\\pathtoicons\\alkane.ico"
"Position"=-

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\CommandStore\shell\CustomTool1]
@="Custom Tool 1"
"icon"="\\\\server\\pathtoicons\\alkane.ico"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\CommandStore\shell\CustomTool1\command]
@="mshta.exe \"\\\\server\\pathtotools\\mycustomtool.hta\" \"%1\""

If you look closely, you should see that this context menu will only show for MSI files because we use the Msi.Package progid.  You’ll also note that when we export registry into a .reg file like above, all quotes in the registry values are escaped by a preceeding backslash as indeed are all backslashes!  So a quote would be \” and a backslash would be \\!  As an example (taken from above) the value:

mshta.exe \”\\\\server\\pathtotools\\mycustomtool.hta\” \”%1\”

when imported will resolve to:

mshta.exe “\\server\pathtotools\mycustomtool.hta” “%1”