{"id":75,"date":"2019-02-11T07:00:38","date_gmt":"2019-02-11T12:00:38","guid":{"rendered":"https:\/\/blog.markdepalma.com\/?p=75"},"modified":"2019-03-22T13:28:01","modified_gmt":"2019-03-22T17:28:01","slug":"deploying-a-rodc-for-palo-alto-pan-os-credential-phishing-prevention","status":"publish","type":"post","link":"https:\/\/blog.markdepalma.com\/?p=75","title":{"rendered":"Deploying a RODC for Palo Alto PAN-OS Credential Phishing Prevention"},"content":{"rendered":"\n<p>I was recently tasked with setting up the AD side of PAN-OS Credential Phishing Prevention. For some technical reason that I haven&#8217;t been able to find it requires a read-only domain controller (<em>I attempted putting the credential agent on a regular DC just to see if it would work and it seemed to read credentials without issue. If anyone has information about RODC requirement I&#8217;d love to hear it.)<\/em> We don&#8217;t have or use any read-only domain controllers currently, so I had to deploy one for each domain we needed to protect. This brought up a few questions to mind&#8230;<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>How would I decide\/maintain what users have their passwords replicated to the RODC?<\/li><li>How do these passwords get replicated to the RODC? By design passwords are only replicated to an RODC after an initial authentication attempt when they are configured for password replication.<\/li><li>Since the sole reason this domain controller is being deployed is for PAN-OS I don&#8217;t want it to handle logons and I want to make it very lightweight. How do I prevent user logons\/authentication from occurring on this DC?<\/li><li>How are usernames identified? Will it handle all formats (samAccountName, <a href=\"https:\/\/docs.microsoft.com\/en-us\/windows\/desktop\/secauthn\/user-name-formats#user-principal-name\">explicit UPN, implicit UPN<\/a>, and email address)?<\/li><\/ul>\n\n\n\n<p><strong>How would I decide\/maintain what users have their passwords replicated to the RODC?<\/strong><\/p>\n\n\n\n<p>This one is pretty easy for me. I don&#8217;t see any reason to exclude any accounts from credential detection, so I will use &#8216;Domain Users&#8217;. I usually stay away from using default groups, but this is one of the few cases where it makes sense to do so.<\/p>\n\n\n\n<p><strong>How do these passwords get replicated to the RODC?<\/strong><\/p>\n\n\n\n<p>I turned the logging level up to verbose (<strong>HKEY_LOCAL_MACHINE\\SOFTWARE\\Palo Alto Networks\\User-ID Credential Agent\\Log | DebugLevel=5<\/strong>) on the credential agent after full configuration and saw that the agent enumerates all the objects within the &#8216;<strong>msDS-Reveal-OnDemandGroup<\/strong>&#8216; attribute of the RODC computer object (and DNs manually specified in the user-id agent seen in the screenshot below) and executes &#8216;<strong>repadmin<\/strong>&#8216; against each object to force replication. As password changes are detected it re-replicates passwords using the same method.<\/p>\n\n\n\n<p><strong>How do I prevent user logons\/authentication?<\/strong><\/p>\n\n\n\n<p>Clients discover domain controllers using DC Locator. I decided to prevent the domain controller from registering all SRV records except for the two necessary for replication (<strong>LdapIpAddress <\/strong>+ <strong>DsaCname<\/strong>). To do this I set a local policy under &#8216;<strong>Computer Settings \u2192 Administrative Templates \u2192 System \u2192 NetLogon \u2192 DC Locator DNS records<\/strong>&#8216; called &#8216;<strong>DC Locator DNS Records not registered by the DCs<\/strong>&#8216;. The value I set for this policy was:<br><\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">Ldap LdapAtSite Pdc Gc GcAtSite GcIpAddress DcByGuid Kdc KdcAtSite Dc DcAtSite Rfc1510Kdc Rfc1510KdcAtSite GenericGc GenericGcAtSite Rfc1510UdpKdc Rfc1510Kpwd Rfc1510UdpKpwd<br><\/pre>\n\n\n\n<p><strong>How are usernames identified?<\/strong><\/p>\n\n\n\n<p>After experimentation it is clear that when using the domain credential filter method PAN-OS is getting the user from the IP&lt;-&gt;user relationship and only looks for that user&#8217;s password in web site submissions. No matter what username I put in a form the submission triggered a detection as long as the password matched my password. Another user&#8217;s credentials under my session did not trigger a detection. I was happy with this because I do not have to worry about certain username formats not being detected.<\/p>\n\n\n\n<p>After all of these questions\/concerns were addressed came the actual implementation. You are required to install both the <strong>&#8216;User-ID Agent&#8217;<\/strong> and the <strong>&#8216;User-ID Credential Agent&#8217;<\/strong> on the RODC. According to the documentation this instance of the user-id agent should not be used for IP&lt;->user relationship gathering and should only be pulling credentials. The credential agent creates the <strong>&#8216;bloom filter&#8217;<\/strong> and sends it over to the user-id agent. PAN-OS connects to the user-id agent receives the newest version of the bloom filter. <del>One issue I ran into was around permissioning and service accounts. Normally you would assign a domain account with limited permissions to the user-id agent, but the thing to consider here is that credential agent and user-id agent communicate using <\/del><a href=\"https:\/\/docs.microsoft.com\/en-us\/windows\/desktop\/ipc\/named-pipes\"><strong><del>named pipes<\/del><\/strong><\/a><del>.<\/del> <a href=\"https:\/\/docs.microsoft.com\/en-us\/windows\/desktop\/ipc\/named-pipe-security-and-access-rights\">According to the documentation\u00a0on\u00a0named\u00a0pipes<\/a> if no ACL is specified when creating a named pipe the default ACL is:<\/p>\n\n\n\n<ul class=\"wp-block-list\"><li>LocalSystem &#8211; Full Control<\/li><li>Administrators &#8211; Full Control<\/li><li>Creator Owner &#8211; Full Control<\/li><li>Everyone &#8211; Read<\/li><li>Anonymous &#8211; Read<\/li><\/ul>\n\n\n\n<p><del>The issue here is that the credential agent <\/del><strong><del>only runs under LocalSystem<\/del><\/strong><del> and assigning a non-administrator account to the user-id agent service prevents the user-id agent from communicating to the credential agent&#8217;s named pipe. Leaving the user-id agent service running under LocalSystem worked, but created another problem. When running under LocalSystem for some reason it was unable to enumerate the &#8216;<\/del><strong><del>msDS-Reveal-OnDemandGroup<\/del><\/strong><del>&#8216; attribute (seen in the UaDebug.log file) for the RODC meaning it couldn&#8217;t determine what user accounts were allowed to sync to this RODC. I found that if I manually specified a group DN in the user-id agent it would work under LocalSystem. The only other option would be switching to a &#8216;DOMAIN\\Administrators&#8217; service account (since this a domain controller) which I did not want to do. Since I&#8217;m only using &#8216;Domain Users&#8217; this was easy enough to configure.<\/del><\/p>\n\n\n\n<figure class=\"wp-block-image\"><a href=\"https:\/\/blog.markdepalma.com\/wp-content\/uploads\/2019\/02\/image-4.png\"><img loading=\"lazy\" decoding=\"async\" width=\"580\" height=\"375\" src=\"https:\/\/blog.markdepalma.com\/wp-content\/uploads\/2019\/02\/image-4.png\" alt=\"\" class=\"wp-image-107\" srcset=\"https:\/\/blog.markdepalma.com\/wp-content\/uploads\/2019\/02\/image-4.png 580w, https:\/\/blog.markdepalma.com\/wp-content\/uploads\/2019\/02\/image-4-300x194.png 300w\" sizes=\"auto, (max-width: 580px) 100vw, 580px\" \/><\/a><\/figure>\n\n\n\n<p><strong>UPDATE: There seems to be a discrepancy between how the User-ID agent worked previously, the current documentation, and how it works now. In the past the User-ID agent configuration utility would adjust the &#8216;Log on as&#8217; value for the &#8216;User-ID Agent&#8217; service to the account you specified in the agent setup &#8216;Authentication&#8217; tab. It seems now the service continues to run as LocalSystem, but uses the account specified in the configuration to actually probe the DCs and AD. I was able to leave it running as LocalSystem, specify an account with the proper rights in the &#8216;Authentication&#8217; tab, and leave the group DN blank under the &#8216;Credentials&#8217; tab in the user-id agent configuration utility. I verified the agent was using the account via logon events in the security event log on the RODC.<\/strong><\/p>\n\n\n\n<p>After configuring this you can monitor both log files to verify proper operation and then later verify PAN-OS is properly receiving the bloom filters. Be sure to restart the user-id agent after making any changes.<\/p>\n\n\n\n<p>Credential agent log (<strong>UaCredDebug.log<\/strong>) sending bloom filter:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">02\/08\/19 12:43:46:593 [ Info  667]: Sent BF to UaService. 21edc031f4891d2c42c133acded980ba<\/pre>\n\n\n\n<p>User-ID Agent log (<strong>UaDebug.log<\/strong>) receiving bloom filter from credential agent:<\/p>\n\n\n\n<pre class=\"wp-block-preformatted\">02\/08\/19 12:43:46:593[ Info 2896]: Received BF Push. Different from current one.<br>02\/08\/19 12:43:46:593[ Info 2897]: 0829f71740aab1ab98b33eae21dee122-&gt;21edc031f4891d2c42c133acded980ba <\/pre>\n","protected":false},"excerpt":{"rendered":"<p>I was recently tasked with setting up the AD side of PAN-OS Credential Phishing Prevention. For some technical reason that I haven&#8217;t been able to find it requires a read-only domain controller (I attempted putting the credential agent on a regular DC just to see if it would work and it seemed to read credentials [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[64,65],"tags":[24,57,27,60,55,56,58,59],"class_list":["post-75","post","type-post","status-publish","format-standard","hentry","category-active-directory","category-security","tag-active-directory","tag-credential","tag-domain-controller","tag-named-pipe","tag-palo-alto","tag-pan-os","tag-phishing","tag-rodc"],"_links":{"self":[{"href":"https:\/\/blog.markdepalma.com\/index.php?rest_route=\/wp\/v2\/posts\/75","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.markdepalma.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.markdepalma.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.markdepalma.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.markdepalma.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=75"}],"version-history":[{"count":10,"href":"https:\/\/blog.markdepalma.com\/index.php?rest_route=\/wp\/v2\/posts\/75\/revisions"}],"predecessor-version":[{"id":185,"href":"https:\/\/blog.markdepalma.com\/index.php?rest_route=\/wp\/v2\/posts\/75\/revisions\/185"}],"wp:attachment":[{"href":"https:\/\/blog.markdepalma.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=75"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.markdepalma.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=75"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.markdepalma.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=75"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}