[Office365] SMTP Auth steeds unsuccessful

[CasGas]

Onlangs overgestapt naar office365 waarbij ik gebruik maak van exchange online plan 1. Om mijn scanner, een applicatie en mijn synology's te laten mailen wil ik gebruik maken smtp.office365.com. Hiervoor heb ik eerst mijn eigen account gebruikt, maar omdat (ik denk) gebruik maak van 2FA op mijn account zal dit waarschijnlijk niet werken. Daarop heb ik een extra exchange online plan 1 user erbij genomen, puur voor het verzenden van email op apparaten. Nu krijg ik in de applicatie alleen terug "kan niet aanmelden", maar op mijn synology krijg ik ook echt de text:

535 5.7.3 Authentication unsuccessfull [*.europrd*.prod.outlook.com]

Bovenstaande server naam verandert natuurlijk steeds omdat ik op een andere server terecht kom.

Dus ik zou verwachten dat misschien 2FA aanstaan op het nieuwe account, voor het gemak noemen we die even [e-mail].

Via de admin tenant kan ik zien dat deze gebruiker alle mail apps ter beschikking heeft, dus ook SMTP AUTH wat ik nodig moet hebben. Via de Azure AD settings heb ik voor alle servers uit staan dat 2FA gebruikt moet worden. Als ik op office.com inlog met mijn [e-mail] en bijbehorende wachtwoord krijg ik altijd nog eerst de melding:

Your organization needs more information to keep your account secure

Die kan ik skippen (14 days until required) en dan kom ik netjes in de mail, maar toch denk ik dat deze melding roet in het eten gooit.
Daarop weer terug naar Azure AD, daar zie ik dat het uit staat dat dit verplicht is en via de user kan ik het (natuurlijk) niet uitschakelen. Nu weet ik niet of het hiermee te maken heeft, maar het heeft er alle schijn van.

Wat heb ik geprobeerd:

inloggegevens:

server: smtp.office365.com
port: 587 (ook 25 geprobeerd)
SSL/TLS aangevinkt
zelfde username en password gebruikt om in te loggen binnen office.com zelf voor [e-mail]

Vanuit meerdere plekken geprobeerd, dus ik ben er vrij zeker van dat het aan het account ligt in plaats van de apparatuur die ik gebruik om het te proberen. Gezocht op google met deze foutmelding, maar dat lijkt altijd te zijn dat iemand of zijn wachtwoord verkeerd heeft getypt, daar ben ik 100% van overtuigd dat dat niet meer het geval kan zijn.

Ook heb ik de [e-mail] geprobeerd, ook op port 25 en 587.

Ik wil liever alles authenticeren via deze maner, dan iets toevoegen aan het spf record of een mail realy (dynamisch ip) wat niet praktisch is.

Heeft iemand nog een idee wat ik hier over het hoofd zie?

[Bart]

Als je gebruik maakt van 2FA kan je "application passwords" aanmaken zodat het in een door jou beschreven situatie, met een NAS die uit wil mailen, gewoon kan werken.

https://support.office.co...a4-4441-a618-b53953ee1183

[CasGas]

@Bart
Ook daarmee krijg ik een foutmelding, ik heb een scriptje gebruikt voor powershell om in ieder geval te kunnen testen op basis van het app password, dan krijg ik:

code:

Send-MailMessage : The SMTP server requires a secure connection or the client was not authenticated. The server
response was: 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM
[AM0PR0402CA0012.eurprd04.prod.outlook.com]
At line:1 char:1
+ Send-MailMessage -From [e-mail] -To [e-mail] ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.Mail.SmtpClient:SmtpClient) [Send-MailMessage], SmtpExcept
   ion
    + FullyQualifiedErrorId : SmtpException,Microsoft.PowerShell.Commands.SendMailMessage

Gebruik ik eenzelfde account van een ander bedrijf waarbij ik zeker weet dat het werkt, dan gaat het scriptje wel goed.

[Bart]

Is die [e-mail] een bestaand adres/alias op de gebruiker waar je de authenticatie mee doet? Het From adres moet een bestaand adres/alias zijn anders wordt dit niet geaccepteerd.

Kan je anders eens op je NAS het TLS/SSL vinkje uitschakelen om issues daarmee uit te sluiten? Ik verwacht niet dat dit een issue is aangezien je een SMTP error terug kreeg (en dus de TLS-handshake al voorbij bent) maar ik zou de settings even zo basic mogelijk maken. Je kan daarbij wel gewoon van smtp.office365.com op poort 587 gebruik maken.

Ik gebruik precies hetzelfde principe op m'n UniFi controller:

- Hostname: smtp.office365.com
- Port: 587
- Username: [e-mail]
- Password: app password horende bij dit account
- From adres: [e-mail] (moet een alias zijn op m'n "bart" account)

[Yeebo]

Heb je een (semi-)vast IP-adres? Dan kan je een connector aanmaken en mailen zonder authenticatie.

[Trommelrem]

Wat is de waarde bij:
• Modern Authentication
• Conditional Access (met name Legacy Authentication)
• Security Defaults

Kun je wel unauthenticated mailen naar je MX?

[misteriks]

daupie schreef op donderdag 30 januari 2020 @ 18:59:
Heb je een (semi-)vast IP-adres? Dan kan je een connector aanmaken en mailen zonder authenticatie.

Precies, geen apart account nodig.
Optie 3 in dit artikel
https://docs.microsoft.co...ing-office-365-smtp-relay

[MarkieNL]

Ik heb zelf een lange tijd ook flink zitten klooien met de smtp van Office365.

Ben er toen achter gekomen dat MFA helemaal los staat van smtp.

Wel had ik in Azure een security policy aan staan welke basic authentication blokkeerde op de tenant. En daar viel de smtp ook onder.
Na het tijdelijk uitschakelen van de security policy werkte smtp meteen zonder problemen.
Controleer dus ook zeker even de security policies op portal.azure.com.

Verder kan je idd smtp.office365.com op poort 587+TLS met de authenticatie van een gelicentieerde mailbox gebruiken vanaf een IP adres die niet in het SPF record staat, zolang het afzender adres gelijk is aan een e-mail adres die onderdeel is van de mailbox.

Andere mogelijkheid is op poort 25 zonder encryptie te verbinden naar de dns naam waar je MX records naar verwijzen.
Hiervoor moet het IP wel toegevoegd worden aan het SPF record en het afzender adres moet aanwezig zijn in de GAL. Je kunt hiermee niet naar een externe ontvanger mailen, alleen naar een interne mailbox binnen je O365 tenant.

Controleer zeker even de security policies in Azure. Grote kans dat dat je oorzaak is.

[intrixius]

MarkieNL schreef op donderdag 30 januari 2020 @ 22:31:

Wel had ik in Azure een security policy aan staan welke basic authentication blokkeerde op de tenant. En daar viel de smtp ook onder.
Na het tijdelijk uitschakelen van de security policy werkte smtp meteen zonder problemen.
Controleer dus ook zeker even de security policies op portal.azure.com.

@MarkieNL Heb je hier meer details over welke policy dit is en waar die kan uitgezet worden?

[Anoniem: 316512]

Je kunt Direct Send proberen:

https://docs.microsoft.co...send-email-using-office-3

[intrixius]

@MarkieNL ik lees trouwens hier dat Basic Authentication vanaf oktober 2020 niet meer zal werken...

Ik heb trouwens hetzelfde probleem als @CasGas en kan ook op geen enkele manier meer inloggen op de smtp.office365.com . In mijn geval wil ik vanuit Azure DevOps via PowerShell Send-MailMessage een mail sturen in één van mijn build pipelines...
Een app password werkt ook niet bijmij en geeft fout 5.7.57 SMTP - Client was not authenticated to send anonymous mail during MAIL FROM error

[CasGas]

Voor de mensen die andere opties geven, bedankt voor het advies maar ik wil per definitie niet dat het in het spf record komt of connectors aanmaken, met dhcp adressen kom ik dan weer in de knoei en om de zoveel tijd weer bijwerken omdat ik er dan opeens achter kom dat het niet werk is niet handig.

Wat @MarkieNL inderdaad zegt zal er mee te maken hebben. Ik heb voor test wel een relay connect aangemaakt, maar ook dat werkte niet. Daarna heb ik via telnet een mail getest
en bleek ik op de blacklist te staan omdat ik het natuurlijk te vaak geprobeerd had. Wel lastig als je dat alleen daar ziet en niet op andere plekken. Blacklist was na een half uurtje na aanmelden eraf, dus de connector werkt, maar ook dan blijven mijn mailtjes in de spam terecht komen omdat ze niet bepaald op de officiele manier gaan.

Dus waar @intrixius tegen aan loopt is nog steeds van toepassing.
@intrixius voor SMTP AUTH (dus optie 1 uit @Anoniem: 316512 zijn lijst) zou het niet moeten gelden, maar toch lukt het voor geen meter..

Please note this change does not affect SMTP AUTH – we will continue supporting Basic Authentication for the time being. There is a huge number of devices and appliances that use SMTP for sending mail, and so we’re not including SMTP in this change – though we are working on ways to further secure SMTP AUTH and we’ll share more on that in due course. Nor does this change affect Outlook for Windows or Mac assuming they are already configured and using Modern Auth (and they really should be).

[intrixius]

@CasGas Ik had dus blijkbaar mijn eigen referentie niet goed nagelezen... Maar nu heb ik nog altijd niet gevonden waar die policy of basic authentication kan geactiveerd worden in azure active directory of in het online exchange admin center; iemand die mij kan leiden?

[MarkieNL]

intrixius schreef op dinsdag 4 februari 2020 @ 14:39:
@MarkieNL ik lees trouwens hier dat Basic Authentication vanaf oktober 2020 niet meer zal werken...

Ik heb trouwens hetzelfde probleem als @CasGas en kan ook op geen enkele manier meer inloggen op de smtp.office365.com . In mijn geval wil ik vanuit Azure DevOps via PowerShell Send-MailMessage een mail sturen in één van mijn build pipelines...
Een app password werkt ook niet bijmij en geeft fout 5.7.57 SMTP - Client was not authenticated to send anonymous mail during MAIL FROM error

Ik denk dat je de Basic Authentication en Legacy Authentication door elkaar haalt.
Althans, hoe Microsoft dat ziet... voor mij lijkt het ook hetzelfde.

Het artikel welke jij benoemt gaat meer over het inloggen op SMTP zonder SSL/TLS. Op poort 143 zeg maar in plaats van 993.

Wat ik bedoel is meer de authenticatie techniek van software. Zo kan je bijvoorbeeld de toegang van Office 2010 naar SharePoint Online, Exchange Online of OneDrive blokkeren, terwijl Office 2016 zonder MFA wel wordt doorgelaten. Blijkbaar zit daar dus ook verschil in.

De policy die ik bedoel vindt je terug op de volgende locatie op het portal.azure.com onder je Azure Active Directory > Security > Conditional Access.

Daar vind je de volgende policy:
Block Legacy Authentication


Deze policy blokkeert dus ook alle protocollen die geen MFA ondersteunen. Hieronder valt dus ook SMTP, IMAP en POP3.


Na het uitschakelen van deze policy kon ik na een 30 tal minuten meteen SMTP op smtp.office365.com op poort 587 met TLS in combinatie met een geldig Office 365 account die minimaal beschikt over een Exchange Online Plan 1 licentie.

Hier is dus geen SPF record voor noodzakelijk.
Zorg er wel voor dat het afzender adres gelijk is aan het e-mail adres van de mailbox die je wilt gebruiken.

Ik hoop dat je er wat aan hebt!

[wagenveld]

Naast bovenstaand kan je in EOL ook service specifiek basic/legacy auth blokkeren:
https://docs.microsoft.co...cation-in-exchange-online
En SMTP auth:
https://docs.microsoft.co...ed-client-smtp-submission

Dus dat zou je nog na kunnen lopen, al staan ze niet standaard aan.

Overigens is basic en legacy idd gwn hetzelfde, de manier om met username/passwd naar binnen te komen. Punt is dat je een hele mooie conditional access policy kunt bedenken met MFA enz enz, maar legacy auth gaat hier omheen omdat CA alleen voor Modern Auth sessies werkt. Dus, legacy auth moet je blanket blokkeren om mee te beginnen. Excepties zou je op basis van user en IP kunnen doen.
Overigens is legacy auth op EOL niveau al blokkeren geen slecht idee omdat je dan ook service specifiek excepties kan maken, plus het scheelt een hoop legacy auth verkeer richting AAD.

edit: Overigens, de baseline policies waar @MarkieNL aan refereert gaan eruit, en worden (of zijn) vervangen door security defaults: https://docs.microsoft.co...mentals-security-defaults
Dus wellicht daar ook even kijken, om het allemaal kristalhelder te maken

[ Voor 13% gewijzigd door wagenveld op 04-02-2020 22:16 ]

[MarkieNL]

wagenveld schreef op dinsdag 4 februari 2020 @ 22:12:
Naast bovenstaand kan je in EOL ook service specifiek basic/legacy auth blokkeren:
https://docs.microsoft.co...cation-in-exchange-online
En SMTP auth:
https://docs.microsoft.co...ed-client-smtp-submission

Dus dat zou je nog na kunnen lopen, al staan ze niet standaard aan.

Overigens is basic en legacy idd gwn hetzelfde, de manier om met username/passwd naar binnen te komen. Punt is dat je een hele mooie conditional access policy kunt bedenken met MFA enz enz, maar legacy auth gaat hier omheen omdat CA alleen voor Modern Auth sessies werkt. Dus, legacy auth moet je blanket blokkeren om mee te beginnen. Excepties zou je op basis van user en IP kunnen doen.
Overigens is legacy auth op EOL niveau al blokkeren geen slecht idee omdat je dan ook service specifiek excepties kan maken, plus het scheelt een hoop legacy auth verkeer richting AAD.

edit: Overigens, de baseline policies waar @MarkieNL aan refereert gaan eruit, en worden (of zijn) vervangen door security defaults: https://docs.microsoft.co...mentals-security-defaults
Dus wellicht daar ook even kijken, om het allemaal kristalhelder te maken

Dank voor deze info!
Blijkbaar komen er meerdere organisaties in aanmerking voor de slogan ‘leuker kunnen we het niet maken, wel makkelijker’

[CasGas]

@MarkieNL

Bedankt voor je input en dan zie ik meteen waar het bij mij mis gaat. Ik heb alleen Exchange Online plan 1 (een aantal keer) en ik heb de optie niet om de policy aan te maken, waardoor ik vermoed dat het standaard dus uit staat:

[Quad]

@CasGas Voor dit soort zaken kan je evt ook een shared mailbox gebruiken en daar een wachtwoord instellen. Hoef je geen licentie te gebruiken. Zo heb ik t werkend voor oa scanner bij mij thuis.

Beste optie is al wel gegeven, gebruik maken van O365 relay en dus IP in de SPF record toevoegen. Maar is niet handig als je een dynamisch WAN IP hebt.

Voor de opties die @MarkieNL weergeeft heb je wel tenminste 1x AzureAD P1 licentie nodig.

[ Voor 39% gewijzigd door Quad op 04-02-2020 23:07 ]

[Anoniem: 316512]

Quad schreef op dinsdag 4 februari 2020 @ 22:35:
@CasGas Voor dit soort zaken kan je evt ook een shared mailbox gebruiken en daar een wachtwoord instellen. Hoef je geen licentie te gebruiken. Zo heb ik t werkend voor oa scanner bij mij thuis.

Beste optie is al wel gegeven, gebruik maken van O365 relay en dus IP in de SPF record toevoegen. Maar is niet handig als je een dynamisch WAN IP hebt.

Voor de opties die @MarkieNL weergeeft heb je wel tenminste 1x AzureAD P1 licentie nodig.

Als je dynamisch WAN hebt zou je dat op kunnen lossen met iets als DynECT misschien.

[intrixius]

Ik heb inderdaad, zoals @Quad voorstelt, om te testen een shared mailbox gebruikt met een wachtwoord (zonder MFA), maar dat blijft hetzelfde probleem, wat ik ook probeer.
Ik kan met deze credentials gewoon inloggen op https://outlook.office.com/, maar niet via onderstaand powershell script:

code:

$parameters = @{
    From = '[e-mail]'
    To = '[e-mail]'
    Subject = 'Email Subject'
    Body = 'Email body'
    BodyAsHTML = $False
    Credential = Get-Credential
    DeliveryNotificationOption = 'onSuccess'
    Encoding = 'UTF8'
    Port = '587'
    Priority = 'High'
    SmtpServer = 'smtp.office365.com'
}
Send-MailMessage @parameters -UseSsl

geeft volgende fout:

Send-MailMessage : The SMTP server requires a secure connection or the client was not authenticated. The server response was: 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM [AM0PR06CA0003.eurprd06.prod.outlook.com]
At line:15 char:1
+ Send-MailMessage @parameters -UseSsl
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (System.Net.Mail.SmtpClient:SmtpClient) [Send-MailMessage], SmtpException
+ FullyQualifiedErrorId : SmtpException,Microsoft.PowerShell.Commands.SendMailMessage

het lijkt zelfs dat verkeerde credentials ook dezelfde fout te geven, dus ik ben helemaal niet meer zeker waar het probleem ligt... Het lijkt dat dit er zelfs helemaal niet geprobeerd wordt om te authenticeren, dus waarschijnlijk toch één of andere policy die dit tegenhoudt.
Ik wil bovenstaand powershell script kunnen uitvoeren vanuit Azure DevOps pipelines, en ik heb in dit scenario geen mogelijkheid om SPF records toe te voegen;
Ik heb, net als @CasGas ook geen optie om een policy toe te voegen zoals @MarkieNL aangeeft.

Ook nog even dit voor de zekerheid gecontroleerd:

PS C:\Users\Me> Get-TransportConfig | Format-List SmtpClientAuthenticationDisabled

SmtpClientAuthenticationDisabled : False

PS C:\Users\Me> Get-CASMailbox -Identity [e-mail] | Format-List SmtpClientAuthenticationDisabled

SmtpClientAuthenticationDisabled : False

Dat lijkt dus toch goed te staan, niet?

[ Voor 0% gewijzigd door intrixius op 05-02-2020 09:02 . Reden: referentie naar post MarkieNL ]

[ImNotnoa]

code:

$Body = "Dit is een testbericht" 
$SmtpServer = 'smtp.office365.com' #smtp server 
$SmtpUser = '[e-mail]' #email login
$smtpPassword = 'apppasswordhier' #email wachtwoord / app password bij 2FA
$MailtTo = '[e-mail]' #verzonden-aan adres
$CC = '[e-mail]' # CC adres
$MailFrom = '[e-mail]' #verzonden-van adres
$MailSubject = "Onderwerp Hier" #Mailonderwerp
$Credentials = New-Object System.Management.Automation.PSCredential -ArgumentList $SmtpUser, $($smtpPassword | 
ConvertTo-SecureString -AsPlainText -Force) 
Send-MailMessage -To "$MailtTo" -CC "$CC" -from "$MailFrom" -Subject $MailSubject -Body "$Body" -Attachments "C:\pad\naar\bijlage.txt"  -SmtpServer $SmtpServer -BodyAsHtml -UseSsl -Credential $Credentials

Ik gebruik deze Powershell code om te mailen via onze (zakelijke) O365 omgeving, wellicht heb je hier iets aan

[wagenveld]

CasGas schreef op dinsdag 4 februari 2020 @ 22:23:
@MarkieNL

Bedankt voor je input en dan zie ik meteen waar het bij mij mis gaat. Ik heb alleen Exchange Online plan 1 (een aantal keer) en ik heb de optie niet om de policy aan te maken, waardoor ik vermoed dat het standaard dus uit staat:

[Afbeelding]

Zo te zien heb jij de baseline policies al niet meer en is je tenant al over naar security defaults (zie vorige post). Daar moet je dan ook even kijken.

[CasGas]

@wagenveld heeft mij op het goede spoor gezet inderdaad, waarvoor dank!

Voor andere en @intrixius :

Ga naar de Azure AD, kies dan properties. Onderin staan een linkje: "Manage Security defaults" en die zal waarschijnlijk standaard op "Yes" staan. Nadat ik deze op "No" had gezet en een test email verstuurde werkt het direct.

Ik ga nu weer 2FA op het account zetten en dan nog eens testen met een app password om te zien of dat dan ook werkt.

wagenveld schreef op woensdag 5 februari 2020 @ 10:40:
[...]


Zo te zien heb jij de baseline policies al niet meer en is je tenant al over naar security defaults (zie vorige post). Daar moet je dan ook even kijken.

Dat is dan wel de "nieuwe standaard" geworden binnen office365 zoals het blijkt..

[ Voor 28% gewijzigd door CasGas op 05-02-2020 11:45 ]

[intrixius]

Helden!
Ik heb net zoals @CasGas de "Security Defaults" uitgeschakeld en ik kan weer gewoon mailen met mijn PowerShell script...
Nu vraag ik me wel af welke andere gevolgen er nog zijn verbonden aan het uitschakelen...

[de.lesse]

Als je volgende krijgt

response was: 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM

is de kans ook groot dat er iets mis is met je wachtwoord. Azure AD heeft nogal wat regeltjes waar niet altijd een logica in zit en daardoor problemen geeft. OutlookWebApp openen lukt dan weer wel. SMTP auth dan weer niet. Dus try and error met wachtwoord en dan kom je in vele gevallen ook al een pak verder.
Dit even ter info