Exchange Web Services 404 error - exchangewebservices

I'm attempting to connect to Office 365's Exchange Web Services, but it keeps coming up with a 404 error. I'm pretty sure the issue is with the credentials, but I seem to lack the knowledge to resolve it.
I performed a test via testconnectivity.microsoft.com (Service Account Access test under the Office 365 tab) and it is also getting a 404 error. I know from searching online that the format of the credentials is a common problem, however it is in the 'user#company.com' format.
I think the problem may have something to do with the domain or that the authentication goes through my company's server. For example, if I log into outlook.office365.com with the 'user#company.com' format, it forwards me to my company's log on portal (I believe this is a typical setup). In order to log in, I first have to change the user name from the 'user#company.com' format to 'user#domain' or 'domain\user' (the domain is different from the company name).
My question is, since the authentication goes through my company's server, do I need to authenticate to Exchange Web Services in a different manner? (Currently I'm using a WebCredential)
Alternatively, if my company's portal were to accept user#company.com as a valid user name, would that allow me to connect to EWS using a WebCredential?
This is the code I'm using for the connection, however I don't think it is the problem given that Microsoft's test site was also getting a 404 error.
service = new ExchangeService();
service.Credentials = new WebCredentials("user#company.com", "password");
service.Url = "https://outlook.office365.com/ews/exchange.asmx";

Related

sending email using PutEmail processor in Nifi - Failing with Error

I am trying to send email using PutEmail processor in Nifi. Below is the configuration of the processor.
However, emails are not sent and getting this error. It would be great help if addressed.
#techno_mad - I would trust the error message. Test with a known working smtp combo with 100% confirmed smtp access. I also suggest, paste the nifi error as text, not an image. Your peers need to visit the link and are likely not typing it out.
https://support.google.com/mail/thread/5621336?hl=en
Test enabling “Access for less secure apps” (which just means the
client/app doesn’t use OAuth 2.0 - https://oauth.net/2/) for the
account you are trying to access. It's found in the account settings
on the Security tab, Account permissions (not available to accounts
with 2-step verification enabled):
https://support.google.com/accounts/answer/6010255?hl=en

How to POST to another site with just a url

A service provider is supposed to forward messages on to an endpoint (specified by me) but all I get to give them is a URL. How can I make this work.
I have signed up to a satellite service and I am trying make the first steps with their cloud API. I have hardware which sends simple messages over their satellite infrastructure to their cloud services. The provide the user (me) with a dashboard type interface to register the hardware as well as a desitnation (or multiple destinations) each destination is a single url. I dont get to specify usernames, passwords, code or anything just a single url. The service says
"the data will be forwarded to the pre-registered http(s) endpoint (the URL I have given them). Data is sent as a http POST request with Content-Type: application/json. All data is accompanied by an endpoint reference, timestamp, a unique identifier (UUID), and a digital signature that may be used to verify that the data originated from Myriota. Multiple packets may be batched into a single request."
I have a website so to start with I just want to get a single message to display on my page. I have completed and tested the code to display posts by GETing from https://www.mywebsite.com/wp-json/wp/v2/posts. This works.
the URL that I have given the service provider is the same as above. But none of the data reaches my site.
I dont really know how the data exchange or handshaking works here but I assume that for a third party to post to my site, they would need to include some sort of authentication. can this authentication data be included in the url? what is the authentication data? is it my Wordpress username and password? Is it safe send this data in a url? Can I turn off authentication so that anyone can post to my site? surely that isnt safe?
I have minimal experience with web development but plenty with embedded systems, I am working with a young software engineer and he is stumped also. together we have burned nearly a whole week on this so I have bit the bullet and turned to stackoverflow to see if anyone can help

Autodiscovery url for same domain users

I am using EWS managed API to implement notification subscription with exchange server. So, I am trying to figure out if I can assume that the autodiscovery url for users within the same domain will be same?
Yes
Autodiscover is used to get necessary information on how to connect to the exchange server by itself, with minimal user input required. It does so by taking the domain from the users e-mail address and is testing various standard EWS Exchange-Endpoints with it.
An example:
"https://" + domain + "/autodiscover/autodiscover" + fileExtension
Because users within the same domain communicate with the same exchange server, the AutodiscoverURL stays the same for all of them.
You should be using Autodiscover to work out the endpoint for ever user unless you have a very simple network topology (eg one server etc) so making that assumption woudn't be best practice. The URL that Autodiscover will return can be different for a number of reasons eg different Internal and External exchange configuration https://technet.microsoft.com/en-us/library/hh529912(v=exchg.150).aspx (so depending on the client location). Also if your using notifications on Exchange 2013 and up for multiple users then you should be using Autodiscover to get the grouping information for the users https://msdn.microsoft.com/en-us/library/office/dn458789(v=exchg.150).aspx so you can maintain affinity correctly.

Posible pitfalls when switching from Gmail smtp to Gmail rest api

Google offers two systems for accessing Gmail. IMAP and SMTP and a the Gmail rest api Gmail - Scope for SMTP is https://mail.google.com/. However with Gmail rest API, just the required scope (like send, modify) can be used.
What are the main differences between the implementation of these two for sending an email? I've been using SMTP to send the mails without any issues but since that involves having a bigger scope for OAuth2, I want to know if there are any possible risks involved in moving to the API approach.
Users.messages: send says there's a restriction on attachment size.
This method supports an /upload URI and accepts uploaded media with
the following characteristics:
Maximum file size: 35MB Accepted Media MIME types: message/rfc822
Are there any other differences that I should know about if I start using Gmail APIs instead of using SMTP connection for OAuth2.
Also, what is the reasoning behind providing full access as the only possible scope for SMTP/IMAP?
Note: I only requirement is the ability to send emails.
Using SMTP you are directly accessing the mail server located at mail.google.com. SMTP servers have been around since the 60's they don't have the ability to limit what access you have. When you log in you have full access to do what ever the mail server in question is capable of. To login to the SMTP server you need the login (most often email address) and password of the account you wish to access. Drawback to using the SMTP to connect to Gmail is that if the user changed the password you would then loose access. This day in age it is also considered by most to be bad practice for third party developers to be storing a users login and password in your system. For example: I would never give any application access to my login and password to Google. How could you ever prove to me that your system is secure? If your hacked so am I.
Now on to Oauth2. Oauth came about sometime around 2005 when people wanted to be able to access APIs without having to do something stupid like
http://awsom.api.com?login=xxx&password=XXX
If memory services it was originally created for the twitter API developers wanted to be able to access their users twitter account without having to store their login in and password. Again the main problem with this was the developer in question would then have full access to a users twitter account and if the user or the developer changed the password things would break.
So they created OAuth. The main features with OAuth are:
You can limit access you give an application: (readonly, read write)
Password change does not affect access
No sharing account credentials with developers of third party apps
So the main point for me as a developer using Oauth with any Google API would be not having to store the login and password of my users and not being affected by a password change. My users would probably say not having to share their login with me and being able to give my application limited access to their account.
Now back to Gmail. Google made a change about two months ago any refresh token(oauth2) that was created using a Gmail scope will automatically expire when the user changes their password. To my knowledge this is only Gmail. so that removes point number two from the features of oauth.
Which should you use is really up to you, assuming you need to be able to send emails. Then limiting access to read only in your application isn't something you need (point one). However in my opinion from a security standpoint I would never ask my users to give me their login and password and would always choose oauth2. Yes SMTP works, will Google shut it down, probably not users have always been given access to the direct SMTP server of their email provider its how applications like outlook work.
as for OAuth support with SMTP unfortunately I haven't done much research into that guess I need to read RFC 4422 . If you can use OAuth with SMTP servers then again I guess the question would have to come down to speed is it faster to access the SMTP server or the REST API server? I can really think of no differences. Attachments with the Rest API can be tricky. I may do a bit more digging on the subject.

EWS: getting past Forefront security trying to access /EWS/Exchange.asmx

I have this app that uses EWS to access mail, using the standard /EWS/Exchange.asmx SOAP endpoint.
One my user's mail servers is protected by Microsoft Forefront, and the initial HTTP request to
https://server_name/EWS/Exchange.asmx
is redirected (HTTP 302) to:
https://server_name/
CookieAuth.dll?GetLogon?curl=Z2FEWSZ2FExchange.asmx&reason=0&formdir=3
which is an regular HTML page, the point of which, I guess, is to make the user authenticate "manually".
I've not heard about Forefront until today, not sure how to handle it.
Is this normal behavior for Forefront (i.e. it always redirects the initial HTTP request), or is it triggered by something in my app? For example, user-agent?
If it's normal, how am I supposed to get past this page and access /EWS/Exchange.asmx?
If it's triggered by something my app is doing, how can I find out what it is?
My code runs on Android and forms its own XML requests without using any SOAP library. At the transport level, I use Apache HTTP client components. The code works fine with Office 365/Exchange Online, and, according to user reports, "self-hosted" corporate Exchange servers with NTLM.
However, in this case, I'm not even getting an HTTP 401: the HTTP 302 is returned by the very first HTTP roundtrip.
Trying to preemptively authenticate the initial request using Basic authentication didn't make any difference.
The user who reported this issue also mentioned that another EWS based app works, so there must be a solution to it.