<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: Requiring a certificate for security policy to control access in General Topics</title>
    <link>https://live.paloaltonetworks.com/t5/general-topics/requiring-a-certificate-for-security-policy-to-control-access/m-p/508032#M105787</link>
    <description>&lt;P&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/225914"&gt;@RhinoNetAdmin&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;Two ways off hand that you could accomplish this:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;STRONG&gt;HIP-Profile (Requires GlobalProtect Subscription):&lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;Create a HIP-Object that simply checks for the required certificate and use that detection to build out an appropriate profile for use in the security rulebase. This is the easiest solution as long as you have a subscription and doesn't require any major modifications.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;STRONG&gt;New Gateway:&amp;nbsp;&lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;Assuming you wouldn't want to add a new Portal configuration specific to these users (although that would be ideal), you could just create a new Portal agent configuration and use that to point them at a new gateway specific to these users with ideally a new security zone. Then just control the new security zone for these users as you want going forward.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;The HIP check is going to absolutely be your best path forward, and I'd argue that if you don't already have that subscription it's something you absolutely should have if you're allowing BYOD to sensitive endpoints. Assuming that you have this subscription and can utilize HIP, this is your best path forward.&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Wed, 06 Jul 2022 00:18:51 GMT</pubDate>
    <dc:creator>BPry</dc:creator>
    <dc:date>2022-07-06T00:18:51Z</dc:date>
    <item>
      <title>Requiring a certificate for security policy to control access</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/requiring-a-certificate-for-security-policy-to-control-access/m-p/507986#M105783</link>
      <description>&lt;P&gt;I have been tasked to lock down access to our devops environment for developers over VPN. Developers using non-corporate assigned assets (workstations &amp;amp; laptops) will only be allowed access to their desktop workstations in-house over RDP. Developers using corporate assigned assets can access all services on the devops network (source repos, wikis, project tools, ...).&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I was hoping to be able to install and require a locally generated certificate from our CA on the corporate assets, and block access to everything other than RDP on the devops network. I don't see a way to do this. Is this possible? If not, is there a better approach?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I thought of creating a AD group with workstations that are permitted, but it is too easy to change the name of a workstation by the user. The certificate has the advantage that I can revoke it or have it expire, requiring the developer to contact the IT support to resolve.&lt;BR /&gt;&lt;BR /&gt;Any ideas or suggestions are appreciated.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;-Freeman Pascal&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Tue, 05 Jul 2022 17:38:26 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/requiring-a-certificate-for-security-policy-to-control-access/m-p/507986#M105783</guid>
      <dc:creator>RhinoNetAdmin</dc:creator>
      <dc:date>2022-07-05T17:38:26Z</dc:date>
    </item>
    <item>
      <title>Re: Requiring a certificate for security policy to control access</title>
      <link>https://live.paloaltonetworks.com/t5/general-topics/requiring-a-certificate-for-security-policy-to-control-access/m-p/508032#M105787</link>
      <description>&lt;P&gt;&lt;a href="https://live.paloaltonetworks.com/t5/user/viewprofilepage/user-id/225914"&gt;@RhinoNetAdmin&lt;/a&gt;,&lt;/P&gt;
&lt;P&gt;Two ways off hand that you could accomplish this:&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;STRONG&gt;HIP-Profile (Requires GlobalProtect Subscription):&lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;Create a HIP-Object that simply checks for the required certificate and use that detection to build out an appropriate profile for use in the security rulebase. This is the easiest solution as long as you have a subscription and doesn't require any major modifications.&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&lt;STRONG&gt;New Gateway:&amp;nbsp;&lt;/STRONG&gt;&lt;/P&gt;
&lt;P&gt;Assuming you wouldn't want to add a new Portal configuration specific to these users (although that would be ideal), you could just create a new Portal agent configuration and use that to point them at a new gateway specific to these users with ideally a new security zone. Then just control the new security zone for these users as you want going forward.&amp;nbsp;&lt;/P&gt;
&lt;P&gt;&amp;nbsp;&lt;/P&gt;
&lt;P&gt;The HIP check is going to absolutely be your best path forward, and I'd argue that if you don't already have that subscription it's something you absolutely should have if you're allowing BYOD to sensitive endpoints. Assuming that you have this subscription and can utilize HIP, this is your best path forward.&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 06 Jul 2022 00:18:51 GMT</pubDate>
      <guid>https://live.paloaltonetworks.com/t5/general-topics/requiring-a-certificate-for-security-policy-to-control-access/m-p/508032#M105787</guid>
      <dc:creator>BPry</dc:creator>
      <dc:date>2022-07-06T00:18:51Z</dc:date>
    </item>
  </channel>
</rss>

