- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
Enhanced Security Measures in Place: To ensure a safer experience, we’ve implemented additional, temporary security measures for all users.
03-23-2018 01:17 PM
I'm testing decryption on our PA-3020 and have found my Office 365 Powershell licensing script is failing to connect with the following error message:
New-PSSession : [ps.outlook.com] Connecting to remote server ps.outlook.com failed with the following error message :
WS-Management cannot process the request. The operation failed because of an HTTP error. The HTTP error (12175) is: A
security error occurred . For more information, see the about_Remote_Troubleshooting Help topic.
I've tried adding an FQDN based Address object for "ps.outlook.com" and assigning it to a No Decrypt rule, but that has not helped.
In the Monitor -> Traffic tab, I see what I think is the corresponding log entry, stating that application soap on port 443 had a session end reason of decrypt-error. The destination address is a Microsoft address, but does not have a DNS reverse lookup entry.
03-23-2018 02:02 PM - edited 03-23-2018 02:04 PM
First and foremost the best way to do this is with a custom URL Cateogry; then add the associated URLs into that new entry. Like this.
<entry name="No-Decrypt"> <list> <member>ps.outlook.com</member> </list>
Then you'll need to create another decryption policy that is setup with an action of no-decrypt, placed higher in your decryption policies than your existing policy.
So essentially it would look like this.
<entry name="No-Decrypt - LTSB"> <category> <member>No-Decrypt</member> </category> <service> <member>any</member> </service> <type> <ssl-forward-proxy/> </type> <from> <member>inside</member> </from> <to> <member>outside</member> </to> <source> <member>yourip</member> </source> <destination> <member>any</member> </destination> <source-user> <member>any</member> </source-user> <action>no-decrypt</action> </entry>
And that should do it. It will now looks specifically for the ps.outlook.com entry, and this will bypass decryption.
03-23-2018 02:02 PM - edited 03-23-2018 02:04 PM
First and foremost the best way to do this is with a custom URL Cateogry; then add the associated URLs into that new entry. Like this.
<entry name="No-Decrypt"> <list> <member>ps.outlook.com</member> </list>
Then you'll need to create another decryption policy that is setup with an action of no-decrypt, placed higher in your decryption policies than your existing policy.
So essentially it would look like this.
<entry name="No-Decrypt - LTSB"> <category> <member>No-Decrypt</member> </category> <service> <member>any</member> </service> <type> <ssl-forward-proxy/> </type> <from> <member>inside</member> </from> <to> <member>outside</member> </to> <source> <member>yourip</member> </source> <destination> <member>any</member> </destination> <source-user> <member>any</member> </source-user> <action>no-decrypt</action> </entry>
And that should do it. It will now looks specifically for the ps.outlook.com entry, and this will bypass decryption.
03-26-2018 02:50 AM
@BPry, Hi...
are you saying that placing this in a url category will act differently than adding it dirctly as an address object or did you miss this part by @CastawayKid.,,,
I've tried adding an FQDN based Address object for "ps.outlook.com"
03-26-2018 05:49 AM
If you add an FQDN based object it will resolve to a set of IP addresses; however when your working with Microsoft there are so many addresses that FQDN doesn't always work for all of them. It's better in these instances to simply utilize a URL Category.
03-26-2018 06:04 AM
@BPry, nice one, many thanks for the info...
is this documented anywhere or just something you've learned along the way....?
03-26-2018 06:11 AM
Something that I've picked up along the way. I think that the article below that @reaper wrote a while back puts a lot of the limits of FQDN objects in place however. The biggest thing with FQDN is that it limits the IPs to the first 10 addresses that it receives in the DHCP request; when working with larger FQDN objects (like anything Microsoft or AWS) then you're generally working with a lot more addresses than that.
03-26-2018 06:22 AM
@BPry, superb, thanks again...
Just one last question,........ if any , what would be a preference between URL category and DAG?
03-26-2018 06:43 AM
OK put that on hold for now...
I really need to understang DAG's first so will keep reading.
03-26-2018 06:48 AM
Almost any time I'm working with external objects I'll utilize a URL Category over DAG. I utilize DAG a lot for things like printer groups, remote offices, and stuff like that so I don't have to sit and update all of the necessary security policies.
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!