MS 365 Exchange Service Account
Hallo Zusammen,
ich möchte gerne Emails aus einer Microsoft Online Anwendung (z.B. Sharepoint) im Namen diverser User verschicken, sodass die Emails in deren Postfach landen. Ist es möglich dazu einen Service Account einzurichten und diesen dazu zu benutzen? Ich bräuchte dann nur dessen Email Adresse und Passwort dazu.
Danke und Gruß,
Roadmax
ich möchte gerne Emails aus einer Microsoft Online Anwendung (z.B. Sharepoint) im Namen diverser User verschicken, sodass die Emails in deren Postfach landen. Ist es möglich dazu einen Service Account einzurichten und diesen dazu zu benutzen? Ich bräuchte dann nur dessen Email Adresse und Passwort dazu.
Danke und Gruß,
Roadmax
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 2824335447
Url: https://administrator.de/forum/ms-365-exchange-service-account-2824335447.html
Ausgedruckt am: 26.12.2024 um 09:12 Uhr
7 Kommentare
Neuester Kommentar
Servus.
Ja, nennt sich Impersonation
https://docs.microsoft.com/de-de/exchange/client-developer/exchange-web- ...
https://docs.microsoft.com/de-de/exchange/client-developer/exchange-web- ...
Für die echte Automatisierung richtet man dann in der Azure-Konsole eine dedizierte Application-Anmeldung ein die für die Automatisierung von Exchange verwendet wird.
Programmatisch kann man so eine App-Impersonation auch anlegen
Grüße Uwe
Ja, nennt sich Impersonation
https://docs.microsoft.com/de-de/exchange/client-developer/exchange-web- ...
https://docs.microsoft.com/de-de/exchange/client-developer/exchange-web- ...
Für die echte Automatisierung richtet man dann in der Azure-Konsole eine dedizierte Application-Anmeldung ein die für die Automatisierung von Exchange verwendet wird.
Ich bräuchte dann nur dessen Email Adresse und Passwort dazu.
Benutzername und Passwort kommen da aus Sicherheitsgründen schon lange nicht mehr zum Einsatz sondern AppIDs und Secret-Tokens bzw. Zertifikate über OAuth.Programmatisch kann man so eine App-Impersonation auch anlegen
<#
Create new M365 azure application credentials for exchange ews app impersonation
@colinardo administrator.de
#>
# =============================================
# M365 Admin username
$username = 'admin@mydomain.onmicrosoft.com'
$appname = 'MyExchangeOnlineAppImpersonation'
# =============================================
$ErrorActionPreference = 'Stop'
$modulename = 'AzureAD'
if(!(Get-Module -ListAvailable -Name $modulename)){
write-host "Module '$modulename' not found, trying to install module ... " -F Yellow -NoNewline
start powershell -Verb runas -ArgumentList "-EP Bypass -NoP -C Install-Module $modulename -Force" -wait
if(!(Get-Module -ListAvailable -Name $modulename)){
write-host "install failed, please try to install manualy. Exit." -F Red
sleep 2
return
}else{
write-host "Successfully installed $modulename." -F Green
}
}
# connect to azure
$connection = Connect-AzureAD -AccountId $username
# check if admin exists
$AzureAdmin = Get-AzureADUser -Filter "UserPrincipalName eq '$username'"
if (!$AzureAdmin){
write-error -Message "Could not find user '$username' in your tenant." -Category ObjectNotFound
return
}
# check if app with name exists
$app = Get-AzureADApplication -Filter "DisplayName eq '$appname'"
if (!$app){
# add allowed permissions (Exchange Online Application impersonation)
$resource = [Microsoft.Open.AzureAD.Model.RequiredResourceAccess]::new('00000002-0000-0ff1-ce00-000000000000',[Microsoft.Open.AzureAD.Model.ResourceAccess]::new('dc890d15-9560-4a4c-9b7f-a736ec74ec40','Role'))
# add new company application
$newapp = New-AzureADApplication -DisplayName $appname -RequiredResourceAccess $resource -ReplyUrls 'https://login.microsoftonline.com/common/oauth2/nativeclient'
# assign new password
$pass = New-AzureADApplicationPasswordCredential -ObjectId $newapp.ObjectId -EndDate (get-date).AddYears(2)
# create service principal for app
$sPrincipal = New-AzureADServicePrincipal -AppId $newApp.AppId -Tags @("WindowsAzureActiveDirectoryIntegratedApp")
# get objectid of service principle
$resApp = Get-AzureADServicePrincipal -All $true | ? appId -eq $newApp.RequiredResourceAccess.ResourceAppId
# set admin consent approval for access
New-AzureADServiceAppRoleAssignment -ObjectId $sPrincipal.ObjectId -PrincipalId $sPrincipal.ObjectId -ResourceId $resApp.ObjectId -Id $newApp.RequiredResourceAccess.ResourceAccess.id | out-null
write-host "Your application '$appname' has been created, please take note of the following credentials:`n" -F Cyan
write-host "`tCLIENT_ID = $($newapp.AppId)" -F Green
write-host "`tCLIENT_SECRET = $($pass.Value)" -F Green
write-host "The password will expire on $($pass.EndDate.ToString('G'))" -F Gray
}else{
Write-Error -Message "Application already exists" -Category ResourceExists
return
}
Grüße Uwe
Zitat von @NordicMike:
Wie funktioniet das dann mit den Apps, die als "SMTP mailer" fungieren und Zugangsdaten im Sinne von username/passwort haben wollen?
Über individuelle App-Passwörter des Accounts, die sind zwar noch aus Kompatibilitätsgründen vorhanden, werden aber sicher irgendwann auch das Zeitliche segnen.Wie funktioniet das dann mit den Apps, die als "SMTP mailer" fungieren und Zugangsdaten im Sinne von username/passwort haben wollen?
Über individuelle App-Passwörter des Accounts, die sind zwar noch aus Kompatibilitätsgründen vorhanden, werden aber sicher irgendwann auch das Zeitliche segnen.
Ich meinte die SMTP login namen und das SMTP Passwort. Ein simpler SMTP Mailer, wie er in jeder USV, jedem Drucker oder jedem Warenwirtschaftsprogramm vorhanden ist. Sowas ist dann doch keine APP, die man im Admin Center anlegen kann, oder?
Zitat von @NordicMike:
Ich meinte die SMTP login namen und das SMTP Passwort. Ein simpler SMTP Mailer, wie er in jeder USV, jedem Drucker oder jedem Warenwirtschaftsprogramm vorhanden ist.
Schon verstanden.Ich meinte die SMTP login namen und das SMTP Passwort. Ein simpler SMTP Mailer, wie er in jeder USV, jedem Drucker oder jedem Warenwirtschaftsprogramm vorhanden ist.
Sowas ist dann doch keine APP, die man im Admin Center anlegen kann, oder?
Nein, APP-Passwörter sind nur in individuellen Accounts hinterlegt. Das sind zwei paar Schuhe.Für App-Registrierungen muss das Gerät/Anwendung auch moderne Authentifizierung unterstützen und das können die meisten alten SMTP Clients schon gar nicht.
Zitat von @NordicMike:
Gut, im Falle von Roadmax sollte es Sharepoint schon können, jedoch nicht über die SMTP Methode.
Das Verschicken von Mails macht man dort eh direkt mit über die EWS-API oder per REST mit MS Graph, SMTP kommt da gar nicht zum Einsatz.Gut, im Falle von Roadmax sollte es Sharepoint schon können, jedoch nicht über die SMTP Methode.