cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4806
Views
10
Helpful
8
Replies

Mailbox Auto Remediation for O365 on ESA

Doug Maxfield
Level 1
Level 1

Good Morning,

Reading through the document "How-To Configure Mailbox Auto Remediation for Office 365 on Cisco Email Security".  It talks about "Building a Public and Private Certificate and Key Pair".  We have previously generated these items for SSH access to our Cloud ESA.  Can we use the same Key Pairs or do you recommend generating new Key Pairs?

Thanks in advance,

Doug

1 Accepted Solution

Accepted Solutions

Update on this:

We were able to get the Auto Remediation working correctly.  The step that I questioned about yesterday should be the path in your O365 deployment to get to OWA.  In our case, it was https://outlook.office.com/OWA.  I also believe that we may have missed a step in configuring the required permission.  We set them, but believe that we forgot to select the "Grant Permissions" option.  After doing those 2 items, we were able to successfully connect from cESA to O365 with the Connect Check test.

 

Doug

View solution in original post

8 Replies 8

Robert Sherwin
Cisco Employee
Cisco Employee

You are referencing the following article?

How-to configure Azure AD and Office 365 mailbox settings for ESA

I would recommend just creating a new pair specifically for this operation.  Doesn't need to be anything fancy, just simple self signed cert, export - etc.  In my testing and repros on this, I have seen instances where existing pub/private key pairs caused the .json build to fail.

This white paper gives the same technique I use, using XCA:

https://www.cisco.com/c/dam/en/us/products/collateral/security/email-security-appliance/guide-c07-738370.pdf

I like my steps in my article better to do the actual setup, though.

-Robert

Robert,

Thanks for the reply.  I have both articles printed out and reviewing them.

Doug

We have followed the instructions provided, and believe everything is configured properly, but when running the "Check Connection" test at the very end, we are receiving a failure with the following error message:

Connection Unsuccessful.

Details: 
int() argument must be a string or a number, not 'Sequence'

Not sure if this is a configuration issue on our side, or what, but if you have any insight, or have any idea of how to dig deeper into the problem, it would be appreciated.

Thanks

Hi Doug,

 

have you ever found a solution for this as we are facing the same issue.

 

Thanks

Roland

How did you create the certificate?  Are you Windows user, or Linux/OS X user?

 

Can you try out a script for me, if you are Linux/OS X user ---

https://github.com/robsherw/my_azure

 

The only time I have seen the int() error is when there is issue wrong w/ the certificate, and that sprials into invalidating the whole Azure setup process.  Happy to get some more feedback and see if we can get this corrected for you.

Sorry to bring up an old thread.

 

We are looking at this again and believe that we have gotten much closer.  The "int" error is gone and now it looks likes it's a connection error:

 

Connection Unsuccessful.

Details: 
Unable to connect to Office 365 services with the specified parameters. Please verify Azure AD details and retry.

 

I believe I might know where the problem is but need some clarification.  Going through the Auto Remediation for Office 365 guide, on page 6, in the section "Register your CES Cluster as an Application in Azure", #6 says "Sign-on URL in the form, with a note that says "This is the URL where users can sign in an use your appliance."  

 

What are we looking for here?  I put in our cESA URL and that isn't working.  But our users are not allow access to the cESA except for Spam Quarantine.  Are you looking for our O365 OWA access?  Just need some help to figure it out.

 

The document that I'm using is dated 2016.  Is there a new document to follow?

 

Thanks,

Doug

 

Update on this:

We were able to get the Auto Remediation working correctly.  The step that I questioned about yesterday should be the path in your O365 deployment to get to OWA.  In our case, it was https://outlook.office.com/OWA.  I also believe that we may have missed a step in configuring the required permission.  We set them, but believe that we forgot to select the "Grant Permissions" option.  After doing those 2 items, we were able to successfully connect from cESA to O365 with the Connect Check test.

 

Doug

andrew.brazier
Level 4
Level 4

This document has been updated taking into account Azure changes and with more detail around the certificates process. Much improved! :-)

 

https://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/211404-How-to-configure-Azure-AD-and-Office-365.html#anc9