Jump to content

michelo82

Members
  • Content Count

    320
  • Joined

  • Last visited

Everything posted by michelo82

  1. Danke! Port 25 ist von außen nicht erreichbar. Ich werd verrückt! Das funktioniert!
  2. @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.
  3. 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)
  4. 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} EXCHA
  5. 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\Def
  6. 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
  7. 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.
  8. 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
  9. 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?
  10. 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.
  11. 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""
  12. Okay das leuchtet ein. Aber ich sende doch ohne Auth? Die stellen sind doch im Skript auskommentiert. Oder hab ich da einen Denkfehler?
  13. Hi, danke. 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)
  14. 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.
  15. 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?
  16. 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
  17. 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-MailMessa
  18. 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\system3
  19. Die Einstellungen der Policy finde ich auch so garnicht in der Registry.
  20. 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".
  21. 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 so
  22. Doch. Nur führen die Links nicht dahin. Aber ich suche mal die 12/2016.
  23. Das wäre eine wichtige Maßnahme die Credentials zu schützen. Danke für die Links - die funktionieren aber leider nicht.
×
×
  • Create New...