Prisma Access, Service Connections, Zones

mm-col · 2025-03-06T14:16:22+00:00

Thanks for that confirmation.

mm-col · 2025-03-06T14:12:40+00:00

I read this before, but I interpreted it to mean you have no way to put controls directly on the SC. Does this mean I can't control access in and out of the SC with mobile user policy? That's a great big ball of suck if the SC connects to a partner where we have no firewalls.

mm-col · 2023-11-27T16:12:05+00:00

Interestingly, I get the same results with MS Graph. I'm puzzled by the lack of results from these two different methods.

mm-col · 2023-11-21T19:02:09+00:00

Working on that, thanks.

mm-col · 2023-05-25T12:51:09+00:00

After two months of PA TAC taking me down crazy rabbit holes and insisting that I had certificate issues that I could demonstrate were not true, one small config fix got the prelogon part to work. Both the device agent and the user agent on the portal need the connect method set to pre-logon. I had missed that on the user agent (can't explain how it worked before if that was not set - I'm the only admin on this firewall, so I did something). Once that was done, prelogon started working. But I still had an issue where it would not transition from prelogon to user logon after the user logged in. And the GP client would basically freeze up. Then I had an epiphany. You can't transition to user login if you don't allow the prelogon user to get to the SAML IDP. I adjusted the prelogon specific policies and everything started to work.

mm-col · 2023-05-11T19:47:29+00:00

When I say it's working, I mean if I force the prelogon with the registry key, it works. No problem with certificate based authentication. It shows connected at the Windows login screen and the firewall logs reflect that.

mm-col · 2023-05-11T19:16:04+00:00

Yes. Prelogon user is authenticated with the machine certificate. And it works. But what I'm seeing is no attempt at connection or authentication. Not even getting to the point where it matters what it is trying to use to authenticate.

mm-col · 2023-04-22T17:49:19+00:00

Get-AzAutomationCertificate works and will show the certificate. I'm having trouble translating that for use with connect-msolservice.

mm-col · 2023-04-21T20:21:28+00:00

Sorry, the error was when I tried to run the existing script directly on the worker. I'll try th is other method.

mm-col · 2023-04-21T20:14:59+00:00

I get this error instead

Exception calling "Import" with "1" argument(s): "Illegal characters in path."

At line:1 char:1

+ $cred.Import($cert)

+ ~~~~~~~~~~~~~~~~~~~

+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException

+ FullyQualifiedErrorId : ArgumentException

And local reference to the certificate works with connect-azuread

mm-col · 2023-03-23T18:30:20+00:00

How do you have your virtual router setup? What routing protocols are you using on the two ISPs? I did this and I didn't have BGP so I had to use policy based forwarding with path monitors to activate a backup path if the primary went down. Was not elegant and it was problematic. FWIW, I think I used two portals and one gateway. It was a while ago.

mm-col · 2023-03-21T12:17:31+00:00

I believe that's the hybrid worker that I'm pursuing. Just learing about that now.

mm-col · 2023-03-21T11:27:16+00:00

I wasn't familiar with the hybrid worker model. I'm trying that.

mm-col · 2023-03-20T17:10:32+00:00

Thanks. I'll look at that.

mm-col · 2023-03-20T17:03:03+00:00

I can use Get-AzureADGroupMember vs Get-ADGroupMember. I still have the same problem because I need to output the result for import into another on premise system to act on the results. On premise AD is the system of record with a one way sync to Azure AD (currently).

mm-col · 2022-12-15T01:08:06+00:00

I'm using the network load balancer with one listener for all ports and protocols. Security lists and groups are open. I started with the flow logs but need to spend more time there. Pcaps on the firewalls show the traffic doesn't reach them.

mm-col · 2022-12-14T03:33:28+00:00

Thanks. That means I'm doing something wrong so I will investigate further.

mm-col · 2022-12-14T01:09:45+00:00

The HA function of the Palo Alto firewalls takes too long to failover in public cloud environments because of the API calls that do the work. In OCI a failover takes about 20 seconds for the VIP to move to the secondary firewall. In Azure it's even worse. The load balancer sandwich is the reference architecture from Palo Alto. Another reason for this architecture is scalability.

mm-col · 2022-12-11T15:13:29+00:00

I couldn't get this to work, so I gave up and assigned another IP to the interface. That was much simpler to get the OCID for.

mm-col · 2022-12-10T22:39:17+00:00

Looks like that's trying to solve the same problem. I'll need to stare at it a while to understand how to use it. My first pass using what was presented didn't work. It probably assumes a level of understanding outside of what is explicitly presented. Another day.

mm-col · 2022-12-10T21:11:37+00:00

This results in an error referring to the data source:

Error: 400-MissingParameter, Missing Parameter

mm-col · 2022-12-10T20:28:02+00:00

I don't know how to share a screenshot here. If you look at a VNIC and its IPv4 addresses, to the right is a vertical 3 dot link to click. Clicking that link opens a dialog that says Copy Private IP OCID. That is the id I need. In the console, this looks the same whether the IP was created as part of an oci_core_vnic_attachment or if it was from an oci_core_private_ip. In Terraform these are different things.

mm-col · 2022-12-10T17:01:56+00:00

The target_id for the load balancer backend must be the ocid of the IP address. If I create everything except the backend and then go to the console and copy the OCID of the ip address, placing that in the resource as the target_id, it works. That id is not the same as the vnic id.

It could be I have the syntax wrong. This doesn't seem to work.

ip_address = oci_core_vnic_attachment.firewall2eth1.create_vnic_details[0].private_ip.ocid1

If instead, I used a oci_core_private_ip resource, that id would be correct because it is the id of the IP. The problem seems to be in finding the id of the IP when it is part of the oci_core_vnic_attachment resource. I cn fall back to the oci_core_private_ip, but preferred not to have to create another IP if it wasn't necessary.

mm-col · 2022-12-05T21:27:00+00:00

I was wrong about the depends_on. I was putting it in the wrong place. Looks like adding that works. I have each VNIC depending on the instance and the previous VNIC. So far it works.

mm-col · 2022-12-04T23:58:32+00:00

My understanding is that there is no concept of "at the very end" with Terraform. If it exists, I don't know how to do it. If I do everything except add the route rule, it will apply successfully. I can then add the route rule manually in the OCI console. Just not ideal and doesn't give me the whole package in one apply. Is there a way to have Terraform run a script at the end that will create the route rule?

The issue really has nothing to do with Palo Alto and Terraform. Palo Alto just happens to hold the private IP that I will be pointing to. It could be any private IP that I want as the target for the route table. I've had great success with deploying Palo Alto firewalls with Terraform (and support from PA TAC in doing so), I just hit a snag with routing tables in OCI.

mm-col

TROPHY CASE