michelo82

Am 28.5.2021 um 12:06 schrieb NorbertFe:

Ja, das heißt, dass du auf Port 25 eine authentifizierung zuläßt. Und falls (solls ja geben) das von extern erreichbar ist, hast du schöne eine Variante geschaffen für Brute Force und DoS.

Danke! Port 25 ist von außen nicht erreichbar.

Am 28.5.2021 um 12:31 schrieb winmadness:

Was ich meinte, ich haben neben dem regulären Eintrag "exchange.domain.de" mit den IPv4 und IPv6 Adressen einen zusätzlichen Eintrag smtp.domain.de NUR mit einer IPv4 Adresse. Diesen verwende ich als SMTP-Server für Anwendungen / Aufgaben. Dadurch muss im extra angelegten Receive Connector für "berechtigte Domain-Absender" nur das interne IPv4 Subnet eingetragen werden.

Ich werd verrückt! Das funktioniert!

@massaraksch Danke! Das prüfe ich nochmal, was am Default Connector eingestellt ist. Hat das irgendwelche Nachteile, wenn ich die Exchange User dort erlaube?

@winmadness Einen DNS Eintrag habe ich. Allerdings nicht mit dem Namen smtp.domain.de sondern den Hostnamen exchange.domain.de.

Ich denke wir können hier dicht machen. Ich schaue mich nach einer Alternative um, wie ich Mails senden kann (User + Postfach + Passwort als SecureString oder die Idee von @BOfH_666)

Am 7.5.2021 um 16:12 schrieb winmadness:

Welcher Fehler erscheint, wenn Du als Absenderadresse eine außerhalb Deiner verwalteten Domain und ohne Authentifizierung verwendest - also z.B. "exchange@mail.de".

Auch '530 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM'

@NorbertFe ich habe die IPv6 und IPv4 Adresse in den Connector "internes Relay" eingetragen (mit dem Haken Anonyme Benutzer).

Es wird wieder der Default Frontend Connector benutzt, der ja keine Anoynmen Benutzer mehr zulässt.

Meine Connectoren:

Identity                                        Bindings                 
--------                                        --------                 
EXCHANGE\Client Frontend                  	{[::]:587, 0.0.0.0:587}  
EXCHANGE\Outbound Proxy Frontend          	{[::]:717, 0.0.0.0:717}  
EXCHANGE\Client Proxy                      	{[::]:465, 0.0.0.0:465}  
EXCHANGE\Default                           	{0.0.0.0:2525, [::]:2525}
EXCHANGE\internes Relay MGMT Port 25       	{0.0.0.0:25}             
EXCHANGE\Default Frontend                  	{[::]:25, 0.0.0.0:25}    
EXCHANGE\internes Relay MASCHINEN Port 25 	{0.0.0.0:25}             
EXCHANGE\internes Replay DRUCKER Port 25   	{0.0.0.0:25}             
EXCHANGE\internes Relay Port 25            	{0.0.0.0:25} 

Hi

wenn die Aufgabe über den Aufgabenplaner startet wird der Default Frontend genutzt

2021-05-07T13:11:54.869Z,EXCHANGE\Default Frontend EXCHANGE,08D90B7D716E2276,4,[::1]:25,[::1]:42459,<,AUTH ntlm,
2021-05-07T13:11:54.869Z,EXCHANGE\Default Frontend EXCHANGE,08D90B7D716E2276,5,[::1]:25,[::1]:42459,>,334 <authentication response>,
2021-05-07T13:11:54.873Z,EXCHANGE\Default Frontend EXCHANGE,08D90B7D716E2276,6,[::1]:25,[::1]:42459,*,,Inbound authentication failed because the client MEINEFIRMA.DE\dienstkonto doesn't have submit permission.
2021-05-07T13:11:54.873Z,EXCHANGE\Default Frontend EXCHANGE,08D90B7D716E2276,7,[::1]:25,[::1]:42459,*,,User Name: NULL
2021-05-07T13:11:54.873Z,EXCHANGE\Default Frontend EXCHANGE,08D90B7D716E2276,8,[::1]:25,[::1]:42459,*,Tarpit for '0.00:00:05' due to '535 5.7.3 Authentication unsuccessful',
2021-05-07T13:11:59.889Z,EXCHANGE\Default Frontend EXCHANGE,08D90B7D716E2276,9,[::1]:25,[::1]:42459,>,535 5.7.3 Authentication unsuccessful,
2021-05-07T13:11:59.889Z,EXCHANGE\Default Frontend EXCHANGE,08D90B7D716E2276,10,[::1]:25,[::1]:42459,<,MAIL FROM:<test3@meine-firma.de>,
2021-05-07T13:11:59.889Z,EXCHANGE\Default Frontend EXCHANGE,08D90B7D716E2276,11,[::1]:25,[::1]:42459,*,Tarpit for '0.00:00:05' due to '530 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM',
2021-05-07T13:12:04.900Z,EXCHANGE\Default Frontend EXCHANGE,08D90B7D716E2276,12,[::1]:25,[::1]:42459,>,530 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM,
2021-05-07T13:12:04.900Z,EXCHANGE\Default Frontend EXCHANGE,08D90B7D716E2276,13,[::1]:25,[::1]:42459,-,,Local

Ich habe zum testen localhost als SMTP eingetragen.

Von einem andere Server aus wird sicherlich auch wieder gebastel. Mein Skript soll bestimmte Events aus der Ereignisanzeige des Exchange verschicken.

Hi, ich weiß nicht so recht was ich mit deiner Antwort anfangen soll ?

Der Thread dreht sich doch genau darum, dass ich es nicht hinbekomme, damit ein Skript welches auf dem Exchange selbst gestartet wird keine Mails versendet. Von jedem anderen Server kann ich auf diese Art (gleiches Skript) Mails senden. Nur der Exchange selbst akzeptiert keinen Versand ohne Nutzer mit Postfach. 

Damit komme ich leider keinen Meter weiter.

Ohne im Skript ein AD-Konto + Passwort zu hinterlegen + Port 25: 5.7.57 SMTP; Client was not authenticated to send anonymous mail

mit AD-Konto (ohne Postfach) + Passwort hinterlegt im Skript + Port 587 (dann läuft die Verbindung über den Client Frontend Connector) = funktioniert nicht!

mit AD-Konto (mit Postfach) + Passwort hinterlegt im Skript + Port 587 (dann läuft die Verbindung über den Client Frontend Connector) = funktioniert!

Ich bin um jeden Aussagekräftigen Tipp dankbar, wie ich nun die Mail versenden kann, wenn es denn auch ohne Postfach geht.

Viele Grüße

vor 13 Stunden schrieb NorbertFe:

Und das Password dann im Skript verwursten? Ieeeeee ;)

Wie löst ihr das? Warum kein eigenes AD-Konto inkl Postfach anlegen? Ich nutze für andere Aufgaben gMSA-Konten. Den Task selbst kann ich mit einem gMSA Konto starten. In einem PS-Skript kann ich diesen jedoch nicht verwenden.

Da ich Authentifziert senden muss, weil Exchange es so will, brauche ich ja Credentials im Skript von einem User inkl. Postfach (wenn nicht im Klartext, aber mindestens als SecureString). Wie würdet ihr das machen?

Genutzt wird der Client Frontend Connector.

Ich habe jetzt dem Dienstkonto das Dienstkonto selbst hinzufgefügt mit der Berechtigung "senden als".

Jezt funktioniert es.

Ich muss zugeben, dass mir das vollständig neu ist.

Meinem Verständnis nach muss ich ohne Authentifizierung senden können wenn am "Standard-Connector" (bzw im meinem Fall am "internes Relay PORT 25-Connector") die "Anonymen Benutzer" angehakt sind.

Wenn ich authentifiziert senden möchte, muss ich Port 587 nutzen und irgendein AD-User mit Postfach (welches dann als mein "Dienstkonto" gilt). 😫

Am Exchange ausgeführte "Powershell-Skripts mit dem Send-Mail" durchlaufen scheinbar wohl gar nicht erst den Connector für "Anoynmen" Versand.

Jetzt ist es zwar möglich authentifiziert zu senden, jedoch muss ich mich um das Passwort kümmern (als Klartext im Skript, Hash etc). Auch nicht so toll.

Der Absender im Skript ist Dienstkonto@meine-fima.de. Der Task wird ausgeführt mit Dienstkonto@meine-fima.de.

Wem trage ich dann bei "Senden als" ein?

Das habe ich auch probiert! Also ein AD-Konto welches ein Postfach besitzt in die Anmeldedaten der Aufgabe eingetragen. Zusätzlich habe ich diese Anmeldedaten noch in das Skript selbst gepackt. Das Postfach ist erreichbar - hab es mittels OWA geprüft.

Mail geht nicht raus: "Postfach nicht verfügbar. Die Serverantwort war: 5.7.60 SMTP; Client does not have permissions to send as this sender"

Ich kapier es nicht. Ich kann von jedem Server, Drucker etc senden. Nur nicht vom Exchange selbst. Ich habe den gleichen Task ja auch auf anderen Systemen am laufen.

Gebe ich Credentials im Skript an erhalte ich nun das: "Postfach nicht verfügbar. Die Serverantwort war: 5.7.60 SMTP; Client does not have permissions to send as this sender""

Hi, das bringt leider nichts.

Okay das leuchtet ein. Aber ich sende doch ohne Auth? Die stellen sind doch im Skript auskommentiert. Oder hab ich da einen Denkfehler?

Hi, danke.

vor 17 Minuten schrieb Dukel:

Man muss immer unterscheiden:

Empfänger intern -> Kein Problem (wenn nichts verstellt wurde) - Funktioniert!

Empfänger extern -> Hier gibt es noch eine unterscheidung:

   Per Authentifizierung senden -> Kein Problem (wenn nichts verstellt wurde)

   Kann nur Anonym senden -> Hier benötigt man einen Relaying Receive Connector und grenzt das auf die Systeme ein, die Mails verschicken müssen - Funktioniert! Wurde über einen weiteren Connector gelöst (Add-ADPermission -User “NT AUTHORITYANONYMOUS LOGON” -ExtendedRights “Ms-Exch-SMTP-Accept-Any-Recipient”)

Damit funktioniert es jedenfalls nicht (egal mit oder eben ohne Credentials):

$EmailFrom = "Exchange <exchange@meine-firma.de>"
$EmailTo = "ich@meine-firma.de"
$Subject ="Alarm: $who - $Detail - auf $MachineName"
$Body = "Message: $Message"
$SMTPServer = "exchange.meine-firma.de"
$SMTPClient = New-Object Net.Mail.SmtpClient($SmtpServer, 25) #587
#$SMTPClient.EnableSsl = $true
#$SMTPClient.Credentials = New-Object System.Net.NetworkCredential("ich@meine-firma.de", Passwort");
$SMTPClient.Send($EmailFrom, $EmailTo, $Subject, $Body)

Empfangsconnector:

Links die Konsolenausgabe wenn ich das Sendmail direkt in der Powerstell-ISE ausführe (Mailversand funktioniert!), rechts wenn der Task als Dienstkonto das Skript ausführt (Mailversand funktioniert nicht):

Das ist ja das blöde. Die anderen Server dürfen unauthentifziert senden. Das funktioniert.

Am Exchange aber funktioniert es weder unauthentifiziert noch mit Authentifizierung. In der PS-Konsole als Exchange-Admin funktioniert es. Auch wenn ich die Anmeldaten des Exchange-Admins in der Aufgabenplanung eingebe funktioniert es. Ich möchte aber so ein hochprivilegiertes Konto dafür nicht verwenden.

Hi,

generell kann ich von anderen z.b. Servern senden, sobald ich die IP-Adresse im entsprechenden Connector erlaubt habe. Für die Aufgabenplanung nutze ich Dienstkonten, die nach dem hinzufügen zur Sicherheitsrichtlinie "Anmelden als Stapelverarbeitung" das PS-Skript ausführen können und die Mail wird versendet.

Warum kann dieses Dienstkonto nicht für den Mailversand am Exchange genutzt werden?

Der Trick mit einer Absenderadresse ausserhalb der verwalteten Domain funktioniert leider nicht.

In der PS-Konsole funktioniert übrigens das Skript. Auch wenn der Task als Exchange-Administrator ausgeführt wird.

Aber nicht mit einem Dienstkonto (es ist unter "Anmelden als Stapelverarbeitung" eingetragen.)

Ich vermute sobald der Task läuft, wird ein anderer Empfangsconnector angesprochen?

Nein, die Mails sollen nicht nach extern gehen.

Wenn das nicht Out-of-the-box geht wurde an den Standardconnectoren bereits etwas verändert, oder?

Am Standard-Empfangsconnector sind die "Anonymen Benutzer" abgehakt. Mit dem neuen Empfangsconnector soll verhindert werden, dass alle Systeme senden können. Es sollen nur bestimmte Systeme (über die IP) gezielt zugelassen werden.

Hallo,

ich habe damit diverse Drucker, Server u.s.w ohne Authentifizierung intern Mails senden können, ein internes Relay angelegt. Nach hinzufügen der IP-Adresse des jeweiligen z.b. Druckers im neuen Empfangsconnector funktioniert der Mailversand. Soweit so gut.

Nun möchte ich, dass Exchange selbst über die Aufgabenplanung ein Powershellskript antriggert und mir eine Statusmail sendet. Das funktioniert sowohl unauthentifiziert oder mit Credentials nicht. Die IP des Exchange-Servers ist ebenfalls in dem internen-Relay Connector eingetragen.

Ich erhalte:

Send-MailMessage -To $emailAddress -From $emailFrom -Subject "Status" -SmtpServer "exchchange.meinefirma.de" -Body $tasks
Send-MailMessage : Für den SMTP-Server ist eine sichere Verbindung erforderlich, oder der Client wurde nicht authentifiziert. Die
Serverantwort war: 5.7.57 SMTP; Client was not authenticated to send anonymous mail during MAIL FROM

Was mache ich denn falsch?

Super! Das hat funktioniert. Danke!

Ich habe die DDCP Einstellungen bezüglich der Zeit auf "nicht konfiguriert" gesetzt und die neue GPO wie im Link beschrieben aktiviert.

Auf dem PDC ist die Einstellung korrekt:
 

C:\Windows\system32>w32tm /query /status
Sprungindikator: 0(keine Warnung)
Stratum: 3 (Sekundärreferenz - synchr. über (S)NTP)
Präzision: -23 (119.209ns pro Tick)
Stammverzögerung: 0.0134410s
Stammabweichung: 7.7806677s
Referenz-ID: 0xC0A86424 (Quell-IP:  192.168.100.xx)
Letzte erfolgr. Synchronisierungszeit: 29.04.2021 15:02:40
Quelle: gateway01.meinefirma.de
Abrufintervall: 6 (64s)


C:\Windows\system32>w32tm /query /source
gateway01.meinefirma.de

Einer der alten DCs zeigt es auch korrekt:

C:\Windows\system32>w32tm /query /status
Sprungindikator: 0(keine Warnung)
Stratum: 4 (Sekundärreferenz - synchr. über (S)NTP)
Präzision: -6 (15.625ms pro Tick)
Stammverzögerung: 0.0447388s
Stammabweichung: 7.8287715s
Referenz-ID: 0xC0A86411 (Quell-IP:  192.168.100.xx)
Letzte erfolgr. Synchronisierungszeit: 29.04.2021 15:00:01
Quelle: DC01.meinefirma.de
Abrufintervall: 10 (1024s)


C:\Windows\system32>w32tm /query /source
DC01.meinefirma.de

Nur die beiden anderen "hängen" auch nach einem gpupdate und Neustart des Zeitdienst auf der alten Einstellung.

Die Einstellungen der Policy finde ich auch so garnicht in der Registry.

Danke.

Die Einstellungen in der Default Domain Controller Policy einfach wieder "zurücknehmen" klappt?

Bei manchen Einstellunge bleiben die ja in der Registry vorhanden und werden nicht "zurückgenommen".

Hallo zusammen,

und zwar bin ich dabei 2x Server 2012 R2 Domänen-Controller gegen zwei frische Server 2019 DC's abzulösen. Aktuell stolpere ich allerdings über ein Problem bei der Zeitsynchronisation.

Das alte Systemhaus hatte "leider" an der Default Domain Controller Policy Hand angelegt und folgende Einstellungen getroffen die jetzt auf alle in Betrieb befindlichen DC's wirken. (2x alte Server 2012R2 und 2x neue Server 2019):

Die IPs sind unsere alten VPN Gateways (inkl. NTP) die demnächst Offline gehen. Also muss hier eine andere Quelle eingetragen werden. Das soll unser Internetgateway (Firewall) werden.

Da ich mir nicht sicher war, ob ich die EInstellungen in der Default Domain Controller Policy einfach wieder auf "nicht konfiguriert" stellen kann, habe ich erstmal die IP des Internetgateways eingetragen.

Soweit so gut.

Leider zeigt mir DCDIAG nach 2 Tagen des "DCPROMO" auf meinem neuen DC01 (besitzt alle FSMO Rollen):

      Starting test: SystemLog
         Warnung. Ereignis-ID: 0x0000008E
            Erstellungszeitpunkt: 04/29/2021   11:42:44
            Ereigniszeichenfolge:
            Der Zeitdienst wird nicht mehr als Zeitquelle angekündigt, da die lokale Systemuhr nicht synchronisiert ist.
         Warnung. Ereignis-ID: 0x00000032
            Erstellungszeitpunkt: 04/29/2021   11:42:44
            Ereigniszeichenfolge:
            Der Zeitdienst hat eine Zeitdifferenz von mehr als 128 ms auf 90 Sekunden festgestellt. Die Zeitdifferenz wurde möglicherweise durch die Synchronisation mit einer ungenauen Zeitquelle oder durch schlechte Netzwerkbedingungen verursacht. Von nun an wird der Zeitdienst nicht mehr synchronisiert, die Zeit keinem weiteren Client mehr zur Verfügung gestellt und die Systemuhr nicht mehr synchronisiert. Sobald ein gültiger Zeitstempel von einem Zeitdienstanbieter empfangen wird, wird der Zeitdienst sich selbst korrigieren.
         Warnung. Ereignis-ID: 0x000003FC

Nach einem:

w32tm /resync

Verschwindet vorest die Fehlermeldung.

Dafür bekomme ich auf einem der alten DC's, nach dem ich dort ebenfalls den Befehl ausgeführt habe, folgenden Fehler im Eventlog:
 

EventID: 142

Der Zeitdienst wird nicht mehr als Zeitquelle angekündigt, da die lokale Systemuhr nicht synchronisiert ist.

Nun ist es doch so, dass nur der PDC mit der externen Zeitquelle synchronisiert werden sollte. Dadurch aber die Zeiteinstellung in der Default Domain Controller Policy konfiguriert ist, erhalten immer alle DCs die externe Quelle.

Wie kann ich die Zeitserver jetzt wieder sauber einstellen?

Bzw. kann ich gefahrlos die Default Domain Controller Policy zurückbauen?

Wenn ich eine GPO verwende dann lieber nach dem Bsp. von Mark: https://www.gruppenrichtlinien.de/artikel/zeitsynchronisation-der-domaene-w32time-zeitserver-per-gpo

Oder manuell:

w32tm /config /syncfromflags:manual /manualpeerlist:"<IP Gateway>" /update

vor 3 Stunden schrieb Dukel:

Kein iX Abo?

 

Dann die iX 12/2016 nachbestellen.

Doch. Nur führen die Links nicht dahin. Aber ich suche mal die 12/2016.

Das wäre eine wichtige Maßnahme die Credentials zu schützen. Danke für die Links - die funktionieren aber leider nicht.