Skip to main content

Overview:

I was really struggling to configure SMTP with M365. We have a distribution list that our Operations team are all apart of and wanted to receive email notifications from Jamf for a variety of reasons.

Our environment has MFA enabled and I was continuously fighting with both Jamf/Azure to figure out a workaround to the authentication errors I was seeing in the Jamf Server Logs.

It wasn't until after creating a service account without MFA applied it(account being authenticated in Jamf SMTP) and enabling "Send As" and "Send on behalf" in the distribution list by adding the service account to the delegates list that mail was delivered.

Lets look at a couple server logs I was experiencing first.

 

Server Log Error generated from an account with MFA enabled:

  • javax.mail.AuthenticationFailedException: Authentication unsuccessful, the request did not meet the criteria to be authenticated successfully. Contact your administrator.

With the error above I messed around in Azure quite a bit and got no where. I made exceptions with my user for MFA and I attempted trying to configure an "App Password" which doesn't seem to exist anymore? Or at least was not available within my users account settings for some reason.

 

Server log Error generated from authenticating with a service account created in M365 with no MFA enabled.

  • com.sun.mail.smtp.SMTPSendFailedException: SendAsDenied;

The "SendAsDenied" stuck out to me and I remembered in Exchange that you could configure an account to "Send As". It wasn't until after enabling the service account (account being authenticated in Jamf SMTP) to send as the distribution list that I was targeting mail was finally delivered. 

 

Below is the configuration / solution which allowed for mail to be delivered successfully from Jamf Pro to our M365 Server using a service account without MFA.

 

Microsoft 365 Configuration:

Step 1: Navigate to admin.microsoft.com

Step 2: Users > Active Users > Add a User

  • Enter all required information. I added Exchange Admin as Administrator credentials to this service account.
  • Assign a license that will provide this service account a mailbox.
  • In the User settings > Mail > Mail Apps > verify that Authenticated SMTP is enabled.

Step 3: Navigate to Exchange Online Admin Center from M365 Admin Center.

Step 4: Navigate to Recipients > Groups > Distribution List and locate the Distribution List you want to target.

Step 5: Select the Distribution List > Settings > Manage Delegates > Edit Delegates  > Add a delegate > Add the service account you created and choose the “send on behalf” option. Save changes.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Jamf Pro Configuration:

Step 1: Sign into your Jamf Cloud Instance

Step 2: Select the Settings cog in the top right

Step 3: Navigate to System Settings > SMTP Server

Step 4: Enter the following information:

  • Server and port: smtp.office365.com | 587
  • Encryption: TLSv1.2
  • Connection Timeout: 15 You can play around with this depending on what you want/need]
  • Sender Display Name: mUp to you]
  • Sender Email Address: Enter the mailing address you want mail to be sent from. I sent mine from a distribution group.
  • Requires Authentication: Enter the credentials of the service account you’ve created in M365.

  •  

 

 

 

 

 

 

 

 


Step 5:
Save and Test. At this point I received an email.

Note: This is how I accomplished this, it may not work for your environment. If you think I skipped a step or didn't explain something clearly please let me know and I'll take a look.

We got ours to work in Jamf Production and test. We ended up changing a Microsoft Conditional Access policy.


Do you have some details on that? And did that really solve it?


Yesterday i realzied i have not been receiving emails from Jamf when a device goes into\\leaves a particular Smart Group. I went into the smtp settings, and like many of you, it fails with a generic unable to connect to server message. I have tried to increase the timeout as well as change from tls 1.2 to SSL, and both did not work. I also currently have a case open with Support, but so far they have not been much help. 


Like others we noticed our reports from Jamf Pro not getting sent to us and found out our SMTP broke because we were using port 25.  Here is what we did:



- Created a service account, gave it O365 E1 license (Online only).
- Created a mailbox for the account (if you are a hybrid environment do it on your exchange server and sync it to the cloud).
- Changed the login creds from our tenant to "@companyname.onmicrosoft.com"  This allows you to login directly to Microsoft.
- The sender also needs to match up with the username authenticating to the cloud.  Otherwise the Sender will need to be an O365 account as well and be given "sendas" permissions on the SMTP account.
- To limit the access into the service account, we locked down IMAP,POP & Mapi.



Look at the Jamf Pro Console Server logs if you do an SMTP test and it fails.  That is how we noticed our issue with not having the Authentication account and Sender Email Address the same.


"SendAsDenied; notify@companyname.onmicrosoft.com not allowed to send as jamf_notice@companyname.com;"

Hopefully this helps someone running into this issue.


We got ours to work in Jamf Production and test. We ended up changing a Microsoft Conditional Access policy.


Can you please explain, what changes you have made?


It's wild to me how bad the support answer has been from jamf on Microsoft stopping support for basic auth. App passwords? Disable MFA? Really?

Jamf supports SMTP in their other product (Protect) from what I've read, how in the world are they not supporting it for their SaaS customers?


Like others we noticed our reports from Jamf Pro not getting sent to us and found out our SMTP broke because we were using port 25.  Here is what we did:



- Created a service account, gave it O365 E1 license (Online only).
- Created a mailbox for the account (if you are a hybrid environment do it on your exchange server and sync it to the cloud).
- Changed the login creds from our tenant to "@companyname.onmicrosoft.com"  This allows you to login directly to Microsoft.
- The sender also needs to match up with the username authenticating to the cloud.  Otherwise the Sender will need to be an O365 account as well and be given "sendas" permissions on the SMTP account.
- To limit the access into the service account, we locked down IMAP,POP & Mapi.



Look at the Jamf Pro Console Server logs if you do an SMTP test and it fails.  That is how we noticed our issue with not having the Authentication account and Sender Email Address the same.


"SendAsDenied; notify@companyname.onmicrosoft.com not allowed to send as jamf_notice@companyname.com;"

Hopefully this helps someone running into this issue.


This worked for me.  I had to use a business basic license.  Wish there was a 'free' workaround.


Thanks for the writeup.


This worked for me.  I had to use a business basic license.  Wish there was a 'free' workaround.


Thanks for the writeup.


Could you go into a bit more detail about what you did? We tried this setting with a licensed account but it still wasn't working for us. Did you have to change anything on the tenant?


Could you go into a bit more detail about what you did? We tried this setting with a licensed account but it still wasn't working for us. Did you have to change anything on the tenant?


I followed this exactly.  I didnt change anything in the process other than I had to use a different M$ license type for my M$ account (Business Basic vs OP's E1 license).


Like others we noticed our reports from Jamf Pro not getting sent to us and found out our SMTP broke because we were using port 25.  Here is what we did:



- Created a service account, gave it O365 E1 license (Online only).
- Created a mailbox for the account (if you are a hybrid environment do it on your exchange server and sync it to the cloud).
- Changed the login creds from our tenant to "@companyname.onmicrosoft.com"  This allows you to login directly to Microsoft.
- The sender also needs to match up with the username authenticating to the cloud.  Otherwise the Sender will need to be an O365 account as well and be given "sendas" permissions on the SMTP account.
- To limit the access into the service account, we locked down IMAP,POP & Mapi.



Look at the Jamf Pro Console Server logs if you do an SMTP test and it fails.  That is how we noticed our issue with not having the Authentication account and Sender Email Address the same.


"SendAsDenied; notify@companyname.onmicrosoft.com not allowed to send as jamf_notice@companyname.com;"

Hopefully this helps someone running into this issue.


@stutz  @llitz123  are you jamf cloud customers? We can't seem to get past the error we have in logs " 535 5.7.139 Authentication unsuccessful, basic authentication is disabled" and jamf support hasn't helped beyond talking about app passwords which AFAIK isn't a thing anymore? Are you using those?


Could you go into a bit more detail about what you did? We tried this setting with a licensed account but it still wasn't working for us. Did you have to change anything on the tenant?


I thought I replied to this?


I followed the exact steps by @stutz above.  I didnt change anything in the process.


@stutz  @llitz123  are you jamf cloud customers? We can't seem to get past the error we have in logs " 535 5.7.139 Authentication unsuccessful, basic authentication is disabled" and jamf support hasn't helped beyond talking about app passwords which AFAIK isn't a thing anymore? Are you using those?


I am a cloud basic customer if that's what it is?  I think there are multiple tiers for cloud and we're basic or whatever?


I assume this was in beta release notes for awhile and we missed it - and jamf support didn't mention it despite us asking for a solution now for weeks. It's an interesting solution for jamf not wanting to provide SMTP themselves, I guess.

 

https://learn.jamf.com/en-US/bundle/technical-articles/page/Configuring_Jamf_Pro_to_Use_Microsoft_Graph_API_with_SMTP.html


I assume this was in beta release notes for awhile and we missed it - and jamf support didn't mention it despite us asking for a solution now for weeks. It's an interesting solution for jamf not wanting to provide SMTP themselves, I guess.

 

https://learn.jamf.com/en-US/bundle/technical-articles/page/Configuring_Jamf_Pro_to_Use_Microsoft_Graph_API_with_SMTP.html


Well that looks like fun.  Thanks for finding it.  We'll give it a shot.


I assume this was in beta release notes for awhile and we missed it - and jamf support didn't mention it despite us asking for a solution now for weeks. It's an interesting solution for jamf not wanting to provide SMTP themselves, I guess.

 

https://learn.jamf.com/en-US/bundle/technical-articles/page/Configuring_Jamf_Pro_to_Use_Microsoft_Graph_API_with_SMTP.html


Thanks for sharing, scheduling a meeting with our M365 team to see if this is something they can get on board with since App Passwords seems like a non-starter.


I assume this was in beta release notes for awhile and we missed it - and jamf support didn't mention it despite us asking for a solution now for weeks. It's an interesting solution for jamf not wanting to provide SMTP themselves, I guess.

 

https://learn.jamf.com/en-US/bundle/technical-articles/page/Configuring_Jamf_Pro_to_Use_Microsoft_Graph_API_with_SMTP.html


I just tried to set it up yet it failed to send.  I guess I'll open a ticket to see what - if anything I did wrong in that extensive and annoying process...  


I just tried to set it up yet it failed to send.  I guess I'll open a ticket to see what - if anything I did wrong in that extensive and annoying process...  


We WERE able to get it working, but the internal M365 tech I worked with did 98% of the work so I can't really offer any assistance with troubleshooting.


Anyone have feedback on the Graph API solution working well (or not) before we dive into it?


Anyone have feedback on the Graph API solution working well (or not) before we dive into it?


Its working. But it need to most power :(


Anyone have feedback on the Graph API solution working well (or not) before we dive into it?


It works yet I'm not sure what the benefit is.  We still use a basic MS license for the service account for email sends.


It works yet I'm not sure what the benefit is.  We still use a basic MS license for the service account for email sends.


@llitz123 the account sending the email doesn't need licensing in my test. The benefit is not having to exclude any account from MFA policies like the old way required.

For anyone else trying it, the directions I think are flawed and #6 should be modified for $ObjectID from enterprise apps, not secret like the directions say. Maybe jamf will correct it, I entered a ticket.

https://learn.jamf.com/en-US/bundle/technical-articles/page/Configuring_Jamf_Pro_to_Use_Microsoft_Graph_API_with_SMTP.html


@llitz123 the account sending the email doesn't need licensing in my test. The benefit is not having to exclude any account from MFA policies like the old way required.

For anyone else trying it, the directions I think are flawed and #6 should be modified for $ObjectID from enterprise apps, not secret like the directions say. Maybe jamf will correct it, I entered a ticket.

https://learn.jamf.com/en-US/bundle/technical-articles/page/Configuring_Jamf_Pro_to_Use_Microsoft_Graph_API_with_SMTP.html


Can confirm the directions are wrong and your edit is spot on.


Reply