locked
Custom endpoint detection scripts RRS feed

  • Question

  • Hi,

    Just working through: http://www.ssl-vpn.de/wiki/(S(xsb1s3b522zo1z3bgpxadimj))/Default.aspx?Page=Custom%20endpoint%20detection%20scripts&Aspx

    [SK] No problem with the line above

    • Add a rule to the InternalSite application firewall ruleset to allow access to the endpoint detection script. Note: Make sure to include the /InternalSite/ prefix in your custom rule!

    [SK] Not sure where we need to do this? Please help

    • Create a file InternalSite/inc/CustomUpdate/<trunk_name><0 for HTTP, 1 for HTTPS>Detect.inc that contains the following code

    [SK] Is this a correct example: TrunkName1Detect.inc

    <%
    
    	g_scriptList.add "/InternalSite/scripts/CustomUpdate/MyScriptName.vbs", "this string does not really matter"
    
    %>
    
    

    [SK] If "this string does not really matter", what do I put in there, can it just be "" ? Space, no space?

    And then the last question...if I have done all the above, don't I need to create an Endpoint Policy for this or something?

    Thanks.

    Thursday, April 29, 2010 9:33 AM

Answers

  • So this is what I have at the moment:

    1. The above listed MUDetection.vbs script in the \von\InternalSite\Scripts\CustomUpdate folder

    2. The TrunkName1Detect.inc file in the \von\InternalSite\Inc\CustomUpdate folder as:

    <%
     g_scriptList("/InternalSite/CustomUpdate/MUDetection.vbs") = false
    %>

    OK, I now notice a discrepancy that I did not notice previously (sorry for that).

    I quoted here above an earlier posting of yours and highlighted the issue. I see that your custom VBS script is in the InternalSite\scripts\CustomUpdate while your Detect.inc piece of scripts points to InternalSite/CustomUpdate. I am not sure this is the cause of the error you get on the client machine, as I think I did try that on my lab machine a few days ago, in trying to repro your issue, and it did not generate such an error for me.

     

    In any case, if this is really your current config, it will not work, so you need to change it: leave the Detect.inc script as it is, and move your VBS script to the \InternalSite\CustomUpdate folder.

     

    -Ran

    • Marked as answer by Erez Benari Wednesday, June 2, 2010 11:58 PM
    Saturday, May 29, 2010 8:08 AM

All replies

  • SK,

    You may want to follow these shorter instructions: http://technet.microsoft.com/en-us/library/ff607423.aspx

    -Ran

    Thursday, April 29, 2010 11:07 AM
  • Actually the instructions I’ve pointed you to are missing the step of adding a rule to your trunk’s rule set, which is needed in order to allow the HTTP GET request from the client for your custom VBS script.

     

    So here is what you need to do:

    1.     Click on the Configure button next to Configure trunk settings

    2.     Go to the URL Set tab

    3.     Click on the Add Primary button, under the URL list

    4.     Create the new rule as follows:

    a.     Give the new rule a name with the prefix “InternalRule_”, for example “InternalRule_CustomDetection”

    b.     Action: Accept

    c.     URL regex: /internalsite/scripts/customupdate/[a-z0-9]+\.vbs

    d.     Parameters: Reject

    e.     Methods: GET

    5.     Click OK to close the Advanced Trunk Configuration

    6.     Activate

     

    After you’re done with this, you need to also create a custom PolicyTemplate.xml, as per the instructions on www.ssl-vpn.de which you mentioned above, in order for the variable(s) used in your custom detection scripts to be displayed in the UAG Policy Editor.

     

    Then you need to create a new policy or modify an existing one, so that it will use this/these variable(s).

     

    HTH,

    -Ran

     

    • Marked as answer by Erez Benari Thursday, April 29, 2010 9:20 PM
    • Unmarked as answer by D Wind Thursday, May 6, 2010 8:50 AM
    Thursday, April 29, 2010 11:37 AM
  • I think I am OK with everything until the PolicyTemplate.xml file....don't know what to replace these values with?

    <Policies>		
    	<Policy>
    		<Name>This is the name that shows up in the editor</Name>
    		<ID>This_is_the_variable_name_you_used_in_the_script</ID>
    		<Type>0</Type>
    		<Value>DefaultValueGoesHere</Value>
    		<Description></Description>
    		<Section>Variables\Where\ItShould\Show\Up\In\The\Editor</Section>
    	</Policy>
    </Policies>
    

     

    Please could someone give me a working example for the xml file, thank you
    Thursday, May 6, 2010 8:50 AM
  • Hi,

    Sorry for not answering sooner.

    Lets assume that in your custom detection VBS script you are using two variables:

    • ContosoCorpFileHash - holds the hash value of a specific file found on the client machine and named
    • ContosoCorpRegistry - holds the data read from a specific registry value on the client machine

    The PolicyTemplate.xml should look like this:

    <Policies>  
      <Policy>
        <Name>Contoso Corporate File Hash</Name>
        <ID>ContosoCorpFileHash</ID>
        <Type>0</Type>
        <Value></Value>
        <Description></Description>
        <Section>Variables\Contoso</Section>
      </Policy>
      <Policy>
        <Name>Contoso Corporate Registry Entry</Name>
        <ID>ContosoCorpRegistry</ID>
        <Type>0</Type>
        <Value></Value>
        <Description></Description>
        <Section>Variables\Contoso</Section>
      </Policy>
    </Policies>

    -Ran

    Wednesday, May 12, 2010 7:30 PM
  • Ran,

    So I should have an 'ID' per variable then?

    In the below example MS Update script, I would need to refer to the following variables in the PoliyTemplate.xml file, is that correct?:

    • criticalCount
    • forWindows
    • Results

    MU Script:

    Whale.DebugEcho("Starting patch detection...")
     
    'declare ojbects
    set objSession = CreateObject("Microsoft.Update.Session")
    set objSearcher = objSession.CreateUpdateSearcher
     
    'query for software updates that are NOT installed
    set objResults = objSearcher.Search("IsInstalled=0 and Type='Software'")
    set colUpdates = objResults.Updates
     
    'set variables
    criticalCount = 0
    forWindows = False
     
    'this is the variable that will pass or fail the user for endpoint detection
    Results("Has_Required_Patches") = False
     
    'loop through the list of updates
    For i = 0 To colUpdates.Count - 1
     
     'check to see if the severity is "critical"
     If (InStr(UCase(colUpdates.Item(i).MsrcSeverity), "CRITICAL")) Then
     
      'get the category i.e. windows, office, etc... if it's not windows, we dont care
      set objCategories = colUpdates.Item(i).Categories
     
      'loop through the categories array to see if "WINDOWS" is mentioned
      For j = 0 To objCategories.Count - 1
       If (InStr(UCase(objCategories.Item(j).Name), "WINDOWS")) Then
        'if we are here, then this patch is critial AND for windows
        forWindows = True
        Exit For
       End If
      Next
     
      'final checking, if forWindows, that means its critical AND for windows
      If forWindows Then
       criticalCount = criticalCount + 1
       'Whale.DebugEcho("Title: " &amp; colUpdates.Item(i).Title)
       'Whale.DebugEcho("Description: " &amp; colUpdates.Item(i).Description)
      End If
     End If
     
     'reset the "forWindows" flag so that we can search the next update
     forWindows = False
    Next
     
    If criticalCount &gt; 0 Then
     'there are critical patches available for the OS to install... we cannot let them proceed
     Results("Has_Required_Patches") = False
     Whale.DebugEcho("There were [" &amp; criticalCount &amp; "] critical updates available for Windows to install.")
    Else
     'there are no critical patches available to install for the OS...good to go
     Results("Has_Required_Patches") = True
     Whale.DebugEcho("There were no critical updates for Windows available to install.")
    End If
     
    Whale.DebugEcho("Finished patch detection...")

    Monday, May 17, 2010 12:29 PM
  • Actually no, you do not need an ID for every variable used in the detection script, just for those variables that you want your custom detection script to populate with some value and return to UAG so that you can use them in your policy Boolean expression.

    So in your “MU script”, the only such variable seems to be "Has_Required_Patches"

     

    -Ran

    Monday, May 17, 2010 7:17 PM
  • Thanks.

    So this is what I have at the moment:

    1. The above listed MUDetection.vbs script in the \von\InternalSite\Scripts\CustomUpdate folder

    2. The TrunkName1Detect.inc file in the \von\InternalSite\Inc\CustomUpdate folder as:

    <%
     g_scriptList("/InternalSite/CustomUpdate/MUDetection.vbs") = false
    %>

    3. Created a URL set as per:

    a.     Click on the Configure button next to Configure trunk settings
    b.     Go to the URL Set tab
    c.     Click on the Add Primary button, under the URL list
    d.     Create the new rule as follows:
    e.     Give the new rule a name with the prefix “InternalRule_MUDetection”
    f.     Action: Accept
    g.     URL regex: /internalsite/scripts/customupdate/[a-z0-9]+\.vbs
    h.     Parameters: Reject
    i.     Methods: GET

    4. Created the PolicyTemplate.xml file in \von\conf\CustomUpdate as:

    <Policies> 
      <Policy>
        <Name>CompanyName Microsoft Update</Name>
        <ID>Has_Required_Patches</ID>
        <Type>0</Type>
        <Value></Value>
        <Description></Description>
        <Section>Variables\CompanyName</Section>
    </Policy>

    Next Problem:

    When we activate UAG, it returns the following error message:

    • "Error(s) occurred while activating the configuration"

    When we looked at the ConfigMessages logfile, it has the same error message.

    • Where can we find more info on the problem?
    • Any suggestions on what to try next?

    Thank you

    Tuesday, May 18, 2010 7:59 AM
  • I don't know if it's just a matter of missing a line when you copy/pasted from the actual file and into the Forum thread, but you are missing the closing tag for <Policies>:

    <Policies> 
      <Policy>
        <Name>CompanyName Microsoft Update</Name>
        <ID>Has_Required_Patches</ID>
        <Type>0</Type>
        <Value></Value>
        <Description></Description>
        <Section>Variables\CompanyName</Section>
      </Policy>

    </Policies>

     

    Tuesday, May 18, 2010 8:07 AM
  • LOL, keen eye there Ran ;-)

    I got so involved with the convoluted directory structure, that I missed a </Policies>!

    OK - so it Activates successfully....but now what?

    Do I now need to create a Policy/Expression?

     

    Just out of curiosity, I connected to the trunk from an 'Internet' client...and the following pop up Warning appeared:

    "Forefront UAG endpoint components could not run on this computer, since the script signature could not be verified. Your user experience while using the site may vary, depending on your organization's security policies"

    Eventually we would like to evaluate for both Anti Virus (which is pretty easy to configure using built-in Policies & Expressions) and Microsoft Updates levels - something like (you need to be a minimum of X patches behind current patch level). I see UAG has a built-in method to determine OS and SP level, but not patch level...hence this post.

     

    Tuesday, May 18, 2010 8:22 AM
  • Remember this rule of thumb, SK: whenever editing an XML, once you saved your edits, double-click the XML file and have it open in IE. This will immediately catch any XML syntax errors like the one you just had.

     

    Back to your question: yes, you definitely need to create a policy that will check the results of your custom detection script. And then you will have to use this policy at the trunk or application level ;-)

     

    As for the warning you are receiving about script signature not being verified: are the client components upgraded from IAG, by any chance? In other words, did this client machine initially have IAG client components installed and then you connected to a UAG trunk?

    Tuesday, May 18, 2010 10:27 AM
  • Thanks,

    So I need to create a new Policy/Expression - I do not know how to call/reference all these .vbs, .xml, .inc files that I created up above...could you point me in the right direction please?

    And no, this was never an IAG deployment, UAG from scratch...XP SP3 client with UAG endpoint components (web ActiveX install)

     

    Tuesday, May 18, 2010 11:38 AM
  • You do not need to call or reference any of these files. In the UAG Management console, access the policy editor and either create a new policy or edit an existing policy. In that policy, use the "CompanyName Microsoft Update" variable that you have configured through your customPolicyTemplate.xml. If you add a new policy, meaning you will have the choice to use the Basic Policy Editor, then this variable will appear on the left-side tree under CompanyName, due to this line in your XML:

    <Section>Variables\CompanyName</Section>

     

    Regards,

    -Ran

    • Marked as answer by Erez Benari Wednesday, May 19, 2010 11:40 PM
    • Unmarked as answer by D Wind Tuesday, May 25, 2010 2:01 PM
    Tuesday, May 18, 2010 1:24 PM
  • So, if I understand correctly, what you are saying is that if I click the "Edit Endpoint Policy" I should see my 'CompanyName' in the 'Policy editor for Windows' section?

    Unfortunately I only see the defaults:

    • General
    • Anti Spyware
    • Anti-Virus
    • ...
    • ...
    • User
    • VPN Client

    Am I looking in the right place?

    Tuesday, May 18, 2010 3:01 PM
  • Hi SK,

    I've just tested using your PolicyTemplate.xml from this thread. The custom variable did appear in the UI. Here is where:

    1.     Click on Edit Endpoint Policies

    2.     On the Manage Policies and Expressions window, click on Add Policy

    3.     In the Policy Editor window, click on Manage Windows Policies

    4.     In the Manage Windows Policies and Expressions, click on Add Policy

    5.     In the Policy Editor for Windows, enter a policy name then click on Create As Script

    6.     Click Yes to continue

    7.     In the Advanced Policy Editor for Windows, on the left-side tree-view, open Windows Variables. At the bottom you will see your CompanyName section, and within it, your custom variable named CompanyName Microsoft Update

    8.     If you click on it, the variable Has_Required_Patches appears on the right-side edit box, so that you can construct a Boolean expression with it

     

    Monday, May 24, 2010 4:26 PM
  • Just saw the light ! Yep, it sure is there !!

    However....

    If I leave "(False) Has_Required_Patches" UAG activates with an error: Syntax error in policy expression: Pol_MicrosoftUpdates= (False) Has_Required_Patches

    If I change the script to "Has_Required_Patches" then UAG activates OK, but when I connect to the website I get the following error message:

    "Forefront UAG endpoint components could not run on this computer, since the script signature could not be verified. Your user experience while using the site may vary, depending on your organization's security policies"

    hmmm...almost home with this one I reckon...

    Any additional advice?

    Tuesday, May 25, 2010 2:01 PM
  • Hi SK,

    What browser are you using, IE or Firefox?

    Do you get this error message even when you do not have the custom detection script configured (just rename/remove the TrunkName1Detect.inc file)?

    -Ran

    Thursday, May 27, 2010 3:28 PM
  • Ran,

    Using Windows XP SP3 IE 6.

    There warning message goes away when I remove the TrunkName1Detect.inc file.

    Here is the .inc file content:

    <%

    g_scriptList("/InternalSite/CustomUpdate/MUDetection.vbs") = false

    %>

    thanks

    Friday, May 28, 2010 2:50 PM
  • So this is what I have at the moment:

    1. The above listed MUDetection.vbs script in the \von\InternalSite\Scripts\CustomUpdate folder

    2. The TrunkName1Detect.inc file in the \von\InternalSite\Inc\CustomUpdate folder as:

    <%
     g_scriptList("/InternalSite/CustomUpdate/MUDetection.vbs") = false
    %>

    OK, I now notice a discrepancy that I did not notice previously (sorry for that).

    I quoted here above an earlier posting of yours and highlighted the issue. I see that your custom VBS script is in the InternalSite\scripts\CustomUpdate while your Detect.inc piece of scripts points to InternalSite/CustomUpdate. I am not sure this is the cause of the error you get on the client machine, as I think I did try that on my lab machine a few days ago, in trying to repro your issue, and it did not generate such an error for me.

     

    In any case, if this is really your current config, it will not work, so you need to change it: leave the Detect.inc script as it is, and move your VBS script to the \InternalSite\CustomUpdate folder.

     

    -Ran

    • Marked as answer by Erez Benari Wednesday, June 2, 2010 11:58 PM
    Saturday, May 29, 2010 8:08 AM
  • Thanks Ran, I will only be able to test this next week.

    Will update forum.

    Monday, May 31, 2010 10:38 AM
  • How do we execute this step from the http://www.ssl-vpn.de/wiki/(S(xsb1s3b522zo1z3bgpxadimj))/Default.aspx?Page=Custom%20endpoint%20detection%20scripts&Aspx

    Add a rule to the InternalSite application firewall ruleset to allow access to the endpoint detection script. Note: Make sure to include the /InternalSite/ prefix in your custom rule!

    Thursday, June 10, 2010 12:04 PM
  • You do not need to do that, if you follow my suggestion above (dated Saturday, May 29, 2010).

    If your custom script is placed in the InternalSite\CustomUpdate folder, no changes are required to the ruleset.

    Thursday, June 10, 2010 12:27 PM
  • It appears that if I set this policy to False, and the machine is not up-to-date the icon is greyed out...if its true, its visible again...so it almost feels like it is working...however on connect to the portal this error message appears:

    "Forefront UAG endpoint components could not run on this computer, since the script signature could not be verified. Your user experience while using this site may vary, depending on your organizations security policies."

    The client is Windows XP SP3.

    Is this normal? Does the script need to be signed? Can we disable the signing requirement perhaps?

    Thursday, June 10, 2010 1:03 PM
  • ...however on connect to the portal this error message appears:

    "Forefront UAG endpoint components could not run on this computer, since the script signature could not be verified. Your user experience while using this site may vary, depending on your organizations security policies."

    The client is Windows XP SP3.

    Is this normal? Does the script need to be signed? Can we disable the signing requirement perhaps?


    Hi.

    You won't believe it but I just discovered the reason for this error message - it's because of the name of the script, ending in "detection"! Just rename your script to something else and the error should go away and the detection should be performed as expected.

    This issue has been fixed already and is included in the next Update that will be released for UAG.

    Regards,

    -Ran

    Wednesday, July 28, 2010 5:04 PM
  • Wow Ran - well done for figuring this one out !!!
    Thursday, July 29, 2010 8:22 PM