NorbertFe

Lesen. Sollte zum Standard gehören, wenn man sich mit Technologie die einem selbst noch nicht so geläufig ist. bspw: https://docs.microsoft.com/de-de/exchange/mail-flow/connectors/internet-mail-send-connectors?view=exchserver-2019

Ja, danach musst du dich noch um den Versand kümmern. :)

Naja ldp auf einem nicht Domain member und schon gar nicht auf dem dc natürlich. Alternativ einfach einen der bekannten LDAP Browser. Also wäre klar, dass es kein serverproblem ist ;) was mich auch stark gewundert hätte.

Usw. ;)

Deswegen würd ich mir einfach mal nen anderen Client nehmen. Dann sieht man recht schnell ob’s ein Client oder ein serverproblem ist.

Nein, aber die findest du bestimmt auch selbst bei ms bspw.

Ja aber das ist dein Problem und keins deiner dcs. Nimm doch einfach mal nen anderen LDAP Client. Zur Not tuts sogar ein ldp.exe.

Man legt die Domain als akzeptierte Domain im exchange an und legt den my record bei strato auf die feste up deiner Firewall. Von da dann entweder als relay oder per nat zum exchange. Und vorher sichergehen, dass man kein Open relay oder eine backscatter Möhre ins Netz stellt.

Wozu? Die liefert der ldapserver doch sowieso bei der Verbindung. :/

Sobald die dcs ein Zertifikat haben läuft Windowsseitig alles auch per tls oder ldaps. Den Hinweis von @daabm berücksichtigt? Wenn der LDAP Client keine Funktion zum ignorieren der zertifimatskette hat, muss er dem Root zerr vertrauen. Manche wollen auch noch korrekt die crl erreichen können.

Doch. Oder wie stellst du dir eine ad integrierte ca so vor? Ach die ca war schon da?

Der Hinweis war, dass du dich nicht mit self signed certificates befaßt, sondern mit einer CA. ;) Lustig, dass dir als "Neuem" in der Firma das erst jemand sagen muss, dass man sowas nicht am Produktivsystem "testet".

Geht doch...

Ist das eine ad integrierte ca (Enterprise/Unternehmens-ca)? Falls ja sind die richtigen templates ja per default dabei, falls du nicht händisch eingegriffen hast. Lösche mal domänencontroller und domaincontroller-authentication. Dann bleibt nur die Kerberos Vorlage bestehen und deine dcs ziehen sich die automatisch. Brauchst du nicht. Siehe oben. Nimm die kerberosvorlage. Das ist die aktuellste. Die anderen entfernst du und stellst sie nicht mehr bereit. Nö. Naja die Grundlagen von ca‘s und pki mal eben so lernen ist eben nicht. ein Tipp. Probiere das nicht in der produktivumgebung.

Normalerweise steht da aber auch, time wurde synchronisiert.

net stop w32time w32tm /resync net start w32time Was steht danach im Eventlog?

Hast du nur einen dc? Was steht eigentlich im eventlog?

Ich gehe davon aus, dass du keine Host time Sync in der vm aktiviert hast. Ansonsten de-registriere mal den time Service und registriere ihn dann erneut. Danach sind solche Probleme meist weg. Wozu hast du 3 solche ntp Pools in deinem gpo? Viel hilft viel? edit: naja ich hab jetzt deinen link gelesen und werte das geringfügig anders. Die Wahrscheinlichkeit, dass du bei einem Pool immer vom selben Server die Antworten bekommst ist schon sehr gering. Und ansonsten sollte man sich eben einen Server nehmen, dem man vertraut. Aber garantiert nicht x Pools in der Hoffnung, dass die sich loadbalancen.

Ja, wobei sich die Lücke auch erst durch Fehlkonfiguration der netscaler zum tragen kam. Ohne Zugriff der Kisten aufs Internet wäre das deutlich geringer ausgefallen der Schaden.

Genau.

Wie deutlich möchtest du hören, dass Gruppenrichtlinien NICHT auf Gruppen sondern auf Benutzer- und Computerkonten wirken?

Das ist unnötig, weil Domaincomputers in Authentifizierte Benutzer enthalten ist. Stecken in der OU denn nun Gruppen oder die Benutzer oder Computer für die das gelten soll?

Der Webserver steht ja hoffentlich auch nicht innerhalb deines LANs und hat Zugriff auf alle Applikationen. Falls doch, würde ich das mal sehr schnell ändern. Sicherheit und Bequemlichkeit liegen nunmal an entgegensetzten Enden einer Linie. RDP gehört weder mit noch ohne NLA direkt ins Internet. Wer das heute noch tut, hats echt nicht anders verdient. Bye Norbert

Viel wahrscheinlicher ist aber der Abfluss solcher Infos über Smartphones und ggf. Auch die andere seite der Kommunikation.

Ja. Wie viele Lücken gabs denn so in letzter Zeit? Das werden auch nicht die letzten gewesen sein. Und jeder mit Firewall kann Port 3389 Scans in Aktion sehen. ;)