• Bewerte uns auf OMR Reviews: Klick

  • Achtet bitte in den Beiträgen darauf, dass ihr keine Informationen teilt, die der DSGVO unterliegen können. Verpixelt bitte die entsprechenden Stellen in Screenshots, postet hier auf keinen Fall Messagatracks ohne Rücksprache und auch in den Log Files können persönliche oder sensible Daten enthalten sein.

    Macht uns auch bitte per PN darauf aufmerksam wenn ihr etwas seht. Schreibt mich (@sören) einfach direkt an. 

NT Services Accounts fehlen auf der Gateway Rolle

869288141

Well-known member
Hallo Jan,
dann mache ich im neuen Jahr den Anfang.  :D
Erst einmal wünsche ich dem gesamten NoSpamProxy-Team und allen aktiven Usern ein gutes neues Jahr. 

Die Grundlage meiner Architektur ist Infrastruktur-Empfehlungen in euerem Handbuch
Ich habe die Gateway-Rolle auf einer dedizierte VM in der DMZ installiert. Diese ist in keiner Domäne sondern läuft als Workgroup.

Die Installation der Gateway-Rolle hat problemlos funktioniert. Bei dem Nacharbeiten zum SSL-Zertifikat (Link) bin ich kurz irritiert worden. Die Dienste der Gateway-Rolle laufen bei mir nicht unter dem beschrieben Service Accounts aus eurer Beschreibung.

2023-01-02-00-30-27-VM-125-lab03-n199-admin01-1.png


Auf der einen Seite sind doch NT Service Accounts auch auf Server, welche im WORKGROUP Modus laufen möglich. Auf der anderen Seite dachte ich bis dato, dass die beschriebene Schritte im Docs immer auf Basis der genannten Empfehlungen basieren.

[font=Tahoma, Verdana, Arial, sans-serif]Für mich stellt sich jetzt die Frage, ist das ein Bug oder ein Feature?!


[/font]
Gruß,
Daniel
 
Hallo Daniel,
Dir auch ein frohes neues Jahr.
Zu Deiner Frage: Der Service als solches läuft mit den im Screenshot ersichtlichen Service-Accounts, das ist korrekt so. Bei der Anpassung des Zertifikats wird dann aber der dienstspezifische Account verwendet, so dass nur der entsprechende NoSpamProxy Dienst Zugriff auf den privaten Schlüssel hat. Das ist eine windows-eigene Funktion, die wir hier aus Sicherheitsgründen empfehlen.
Gruß Stefan
 
Hallo Stefan,
Danke für die schnelle Rückmeldung! Jetzt bin ich maximal verwirrt...

Als ich das SSL-Zertifikat von der Gateway-Rolle initial den Konnektoren über das Command Center zuweisen wollte, musste ich den Service Accounts Local Service, Network Service und Local System aus dem Screenshot Leserechte auf dem Private Key geben. Anderenfalls sind die Warnungen und Fehler im Dashboard nicht verschwunden - trotz Neustart der VMs.

Das SSL-Zertifikat ist inzwischen allen Konnektoren bezüglich der Gateway-Rolle zugewiesen. Die Windows Services auf der Gateway-Rolle laufen aber nach wie vor unter dem Services wie du es im Screenshot siehst. Müsste nicht spätestens an der Stelle die Accounts für die Services gewechselt werden?!

Die Service Accounts existieren auf der Gateway-Rolle:
Code:
get-service | Where-Object { $_.Name -Like "*NoSpamProxy*"} | foreach {Write-Host NT Service\$($_.Name)}
NT Service\NoSpamProxyCyrenService
NT Service\NoSpamProxyCyrenUrlService
NT Service\NoSpamProxyLargeFileSynchronization
NT Service\NoSpamProxyManagementService
NT Service\NoSpamProxyPrivilegedService
PS C:\Users\admin.daniel>


Gruß,
Daniel

P.S. Die Namen der Services Accounts im Docs Artikel sind nicht ganz korrekt. Müsste nicht das Wörtchen Netatwork durch NoSpamProxy ersetzt werden?!
P.S.S. Ist der Eintrag "NT Service\NoSpamProxyMailGatewayIntranetRole" an der Stelle im Docs überhaupt richtig? Weil es in dem Abschnitt um Konnektoren geht?!
 
Moin Daniel,
die Berechtigungen für Local Service, Network Service etc. kann ich leider nicht bestätigen. In meiner Demoumgebung sind lediglich die Dienstkonten die mit NT Service\NoSpamProxy anfangen hinterlegt und es funktioniert wunderbar.
Die Doku müssen wir noch anpassen. Guter Hinweis. :)
Gruß Stefan
 
Zurück
Oben