RalphT

Moin, ich habe mal eine Frage, wie ich das am besten lösen kann. Ich habe hier ein paar wenige Smartphones, die ich über das WLAN an das Netz anbinden möchte. Die Smartphones verbinden sich mit dem WLAN und authentifizieren sich am NPS-Server. Dort ist eine Richtlinie hinterlegt, die einmal die AD-Gruppe vom Nutzer, die SSID und die MAC-Adresse vom Smartphone überprüft. Die Smartphones benötigen das ROOT-Zertifkat und ein WLAN-User-Zertifikat. Auf dem NPS-Server ist EAP-TLS eingestellt. Den wenigen Smartphonenutzern würde ich die beiden Zertifikate per Mail zukommen lassen. Das WLAN-Zertifikat muss ich den Nutzern mit einem privaten Schlüssel zustellen lassen. Nun wollte ich ganz gerne, dass der WLAN-Zugriff nicht nicht an Dritte weitergegeben werden kann. Das Zertifikat kann man weitergeben. Um sich am WLAN anzumelden, benötigt man ja auch seinen Loginnamen aus der AD. Das ist ja auch kein großes Geheimnis. Derzeit habe ich nur eine Idee. Ich habe im NPS-Server unter Bedingungen die Anrufer-ID mit den erlaubten MAC-Adressen hinzugefügt. Das funktioniert auch. Der Aufwand hält sich hier auch in Grenzen, da es nur wenige Smartphones sind. Kann man das noch irgendwie anders lösen? Ich dachte auch mal daran, die MAC-Adressen als Nutzer in der AD zu hinterlegen und diese als zusätzliche Gruppe im NPS-Server zu hinterlegen. Aber ich wüsste jetzt nicht wie man im NPS zwei Gruppen hinterlegt, die als UND-Verknüpfung fungieren. Also es muss die AD-Gruppe-Nutzer UND die AD-Gruppe-MAC stimmen, dann würde der NPS den Zugang erlauben. Oder gibt es noch eine ganz andere Möglichkeit? Ich möchte halt nur verhindern, dass der WLAN-Zugang weitergegeben werden kann. Das Ganze soll natürlich auch einigermaßen praktisch durchführbar sein.

Eigentlich interessiert mich das alles nicht. Mir persönlich ist das wurscht, ob da anonymisierte Daten übern Ozean gehen oder nicht. Ich habe hier nur gefragt, da mir hier der Datenschützer auf den Zeiger geht. Ich denke mal nicht, dass da die Gehaltsdaten der Mitarbeiter übertragen werden.

Ja. So hatte ich das bislang auch immer verstanden. Also dann doch die Enterprise-Version installieren. Nach diesem Text, war ich etwas verunsichert.

Wenn ich also die Pro habe und diese beiden Dienste deaktiviere, dann ist zu 100% Ruhe?

Moin, ich habe gerade diesen Beitrag gelesen und bin mir jetzt nicht zu 100% sicher, ob ich das richtig verstanden habe. https://www.gruppenrichtlinien.de/artikel/windows-10-telemetrie-und-diagnosedaten-richtig-abschalten Er schreibt ja, dass ab der Version 20H2 die Abschaltung zu 100% funktioniert. Die 20H2 gibt es ja in der Version Pro und Enterprise. Ich zitiere mal den zweiten Absatz: Gilt das jetzt auch für die Pro-Version? Mich verwirrt der Satz im ersten Absatz: Danke für eure Antworten.

Wegen der aktuellen Situation. Das Video auf der Seite kannte ich noch nicht. Ja klar, das ist ja schon eine Waffe, was da verwendet werden kann. Ich hatte mich ja in den Foren auch schon umgesehen, was andere so machen. Das geht von der Reparatur und über das Neuaufsetzen vom Exchange. Manche vertrauen darauf, dass sie so firm sind, dass man wohl alles gefunden hat. Andere vertrauen auf die Tools die es dafür gibt. Und andere sagen sich, wer weiß, was da alles passiert ist, ich setzte den Exchange neu auf. Aber ich habe noch nicht davon gelesen, dass einer die AD neu aufsetzt. Wie der Frank ja auch auf seiner Seite geschrieben hat. Es ist ein Restrisiko. Ich habe auch noch nichts gelesen, dass einer definitiv Änderungen im AD gefunden hatte.

Mal eine Frage: Hat von euch schon einen oder mehrere Fälle gesehen, wo die Angreifer auch im AD etwas verändert haben? Oder blieb das bis jetzt nur lokal auf dem Exchange?

Hallo @Nobbyaushb, ich sehe ja gerade, dass du aus Bremen kommst und von New Horizons geschrieben hast. Ich war am Fallturm auch mal viele Monate mal dort. Was du schonmal da und hast Erfahrungen damit? Man bietet dort ja Kurse als Walk-In an, aber auch den Klassiker mit Lehrer an der Tafel.

Danke Sqiure, ja hatte ich falsch verstanden. Jetzt weiß ich auch, warum Norbert aus HB stutzte. Ich habe das abgeändert. Läuft einwandfrei.

Ich habe mich an dieser Seite orientiert: https://www.frankysweb.de/exchange-2010-outlook-anywhere-konfigurieren-rpc-over-https/ Er schreibt dann: Im Feld „Server“ geben wir nun den internen FQDN des Exchange Servers an Nun dachte ich, dass ich den Eintrag outlook,firma.de verwende. Denn dieser Eintrag zeigt auf die interne IP vom Exchange. Dann hatte den tatsächlichen FQDN vom Exchange eingetragen. Danach lief es. Allerdings habe ich das nicht so ganz verstanden. Der tatsächliche FQDN und der Eintrag für die internen URLs zeigen ja auf die gleiche IP-Adresse. Ein Get-OutlookAnywhere | fl *hostname* zeigte ExternalHostname : mail.firma.de InternalHostname: outlook.firma.de

Moin, ich habe hier ein Problem mit Outlook Anywere. Von einem externen PC funktioniert die Einrichtung nicht. Was ich habe: Eine Windows interne Zertifizierungstelle. Das Zertifikat für den Exchange ist von dieser Stelle. Das ROOT-Zertifikat ist auf dem externen PC vorhanden. Der https-Zugriff von extern auf den OWA funktioniert ohne Zertifikatswarnung. Exchange 2013 und Outlook 2013 ist hier im Einsatz. Die virtuellen Verzeichnisse vom Exchange sind wie folgt konfiguriert: outlook.firma.de für alle internen Zugriffe. mail.firma.de für die externen Zugriffe. autodiscover.firma.de outlook.firma.de zeigt im lokalen DNS auf den Exchange. mail.firma.de ist von außerhalb auflösbar und zeigt auf die WAN-Adresse der Firma. Der Port 443 ist zum Excgange freigeschaltet und funktioniert auch. Zugriff OWA funktioniert ja. Im Exchange steht die Authentifizierungsmethode für Outlook Anywhere auf Aushandeln. Das neue Mailkonto im Outlook habe ich folgt angelegt: Bei Server steht der interne DNS-Eintrag, also outlook.firma.de Bei Benutzername der Kontoname vom Nutzer Unter weitere Einstellungen: Reiter Verbindung: Verbindung über http herstellen In der HTTPS-Zeile ist der externe DNS-Name, also mail.firma.de Und unten bei Authentifizierungsmethode steht auf Aushandlungsauthentifizierung Dann alle mit OK bestätigt und im Fenster für Name/Passwort den Namen nach dem Muster meine.internedmoamin.de\Name Anschließend erscheint die Melddung (gekürzt) Die Aktion kann nicht abgeschlossen werden. Es steht keine Verbindung mit Exchange zur Verfügung.... Wo könnte das Problem liegen? Ich hoffe, dass ich hier alle wichtige Daten/Einstellungen erwähnt habe.

Ich weiß, dass das hier keine Rechtsberatung ist. Ich wollte nur mal hören, wie es andere machen. Aber so wie ihr das macht, so dachte ich mir das auch. Denn auch bei uns wurde eine Vereinbarung unterschrieben, dass priv. Mails nicht erlaubt sind.

Sehe ich auch so. Aber der DSB guckt mich immer an. Mal gucken, ob es in dieser Sache hier schon Erfahrungswerte gibt.

Hallo, derzeit wird der Exchange mit Acronis täglich gesichert. Diese Dateien von Acronis werden dann täglich auf Bänder gesichert. Zusätzlich wird in regelmäßigen Abständen immer ein Band zur Seite gelegt. Mal angenommen ein ehemaliger MA verlangt, dass seine E-Mails gelöscht werden sollen. So, wie das derzeit gesichert wird, kann man das ja nicht umsetzen. Gibt es dafür überhaupt Möglichkeiten? Ist das überhaupt realistisch, dass man ggf. ein Postfach aus der Datensicherung löschen muss? Kann das z.B. ein ehemaliger MA überhaupt verlangen? Kann mir dazu jemand etwas sagen?

Wir haben jetzt seit über einem Jahr neue Switche im Einsatz. Im Serverbereich zwei HPE 5700 im Stack und für die Clients 5 Aruba 2930 im Stack. Ich muss sagen, die laufen super. Nicht einmal musste ich da einen Switch neu starten oder geschweige, er war defekt. Was mich so bischen bei der ganzen Diskussion wundert ist, dass hier keiner mit den Switchen von Cisco um die Kurve kommt. Ich dachte immer, dass ist "die" Marke im Netzwerk. Quasi der Mercedes. Ich hatte mir damals die Serie von HPE und Aruba ausgesucht, da wir vorher die Serie ProCurve hatten. Bei Cisco hätte ich bei der Programmierung umdenken müssen. Daher blieb ich bei HP.

Das ist schon seltsam: Ich suche da schon länger danach und jetzt, wo ich hier den Thread aufgemacht habe, ist das Problem gelöst. Hier die Lösung: Computerkonto manuell in der AD anlegen. Anschließend in die Eigenschaften und auf den Reiter "Attribut-Edit". Dort das Attribut "servicePrincipalName" suchen. Hier dann den Hostnamen eintragen. In diesem Fall so: host/PC-TEST host/PC-TEST.zweigstelle.firma.de Danach hat sich der nichtdomänen-Client mit dem WLAN verbunden.

Moin, ich habe hier ein Problem mit WLAN 802.1x mit Zertifikaten. Ich möchte einen Computer, der nicht in der Domäne ist, mit dem WLAN verbinden. Das soll in diesem Fall nur mit Zertifikaten geschehen. Also nicht am Client Name/Passwortabfrage. Mit einem Domänencomputer funktioniert das. Vorhanden ist ein DC, 2-stufige PKI und ein NPS-Server. Auf dem NPS-Server habe ich eine neue Verbindungsanforderungsrichtline erstellt. Dort habe ich unter dem Reiter "Einstellungen" bei EAP-Typen "Microsoft: Smartcard oder anderes Zertifikat" eingestellt. In der Netzwerkrichtlinie habe ich unter dem Reiter Bedingungen eine Computergruppe hinterlegt. In der Computergruppe sind alle Computer, die sich mit dem WLAN verbinden dürfen. Nun habe ich den Computer, der nicht in der Domäne ist, manuell angelegt. (Neuer Computer) Alle Computer also Domänenmitglieder und der Rechner der nicht in der Domäne ist, haben ein Zertifikat. Das Zertifikat hat die EKU Eigenschaft "Clientauthentifizierung". Dieses Zertifikat entstand aus der Vorlage "Computer". Auf allen Clients habe ich eine neue WLAN-Verbindung erstellt. Unter dem Reiter "802.1x-Einstellungen" habe ich unter "Authentifizierungsmodus angeben" Computerauthentifizierung gewählt. Beim Versuch sich mit dem WLAN zu verbinden erscheint im NPS folgende Fehlermeldung (gekürzt): Ich habe derzeit keine Idee, wo der Fehler liegen könnte. Es sieht so aus, dass der NPS-Server nicht den einen Computer in der AD finden kann. Der Netzwerkrichtlinienserver verweigerte einem Benutzer den Zugriff. Wenden Sie sich an den Administrator des Netzwerkrichtlinienservers, um weitere Informationen zu erhalten. Benutzer: Sicherheits-ID: NULL SID Kontoname: host/PC-TEST.zweigstelle.firma.de Kontodomäne: ZWEIGSTELLE Vollqualifizierter Kontoname: ZWEIGSTELLE\host/PC-TEST.zweigstelle.firma.de Clientcomputer: Sicherheits-ID: NULL SID Kontoname: - Vollqualifizierter Kontoname: - Betriebssystemversion: - Empfänger-ID: 00-0B-6B-2A-FF-A3:SSID-WLAN-Name Anrufer-ID: B4-B6-76-14-BE-14 Authentifizierungsdetails: Name der Verbindungsanforderungsrichtlinie: Richtlinie-WLAN-Test Netzwerkrichtlinienname: - Authentifizierungsanbieter: Windows Authentifizierungsserver: Server-NPS.zweigstelle.firma.de Authentifizierungstyp: EAP EAP-Typ: Microsoft: Smartcard- oder anderes Zertifikat Kontositzungs-ID: - Protokollierungsergebnisse: Die Kontoinformationen wurden in die lokale Protokolldatei geschrieben. Ursachencode: 16 Ursache: Authentifizierungsfehler aufgrund der Nichtübereinstimmung von Benutzeranmeldeinformationen. Der angegebene Benutzername ist keinem vorhandenen Benutzerkonto zugeordnet, oder das Kennwort war falsch.

War gerade durch Zufall hier. Den Link kannte ich noch nicht. Gleich gebookmarked.

Das soll für ein externes Ticketsystem sein. Als Virenscanner habe ich dort Panda Gatedfender installiert. Und als 3rd Party Software ist noch Acronis Backup installiert.

Ich habe sicherheitshalber einmal die FW deaktiviert. Aber daran liegt es nicht. Das Problem meiner Meinung scheint hier, dass der Server auf Port 110 lauscht, obwohl der POP3-Dienst nicht aktiviert ist. Ist der Dienst aus, dann ist die Datei EdgeTransport.exe die Datei, die den Port öffnet.

Moin, ein Konto muss beim Exchgange 2010 für POP3 aktiviert werden. Nun hatte ich den Dienst aktivert. Leider funktioniert das nicht. Der Dienst startet. Outlook meldet beim Abholen einen internen Exchangefehler. Daraufhin habe ich den POP3-Dienst wieder beendet. Anschließend habe ich netstat aufgerufen und dabei festgestellt, dass die Datei EdgeTransport.exe auf Port 110 lauscht. Ich habe das mal auf zwei anderen Exchange 2010 Servern ausprobiert. Dort funktioniert das einwandfrei. Wenn der POP3-Dienst dort gestartet wird, dann zeigt netstat für die IP 0.0.0.0 an, dass dort auf Port 110 gelauscht wird. Bei diesem Exchange ist das auch so, dass beim aktiverten POP3-Dienst auf der IP 0.0.0.0 auf Port 110 abgehört wird. Jedoch wird dann zusätzlich die IP vom Exchangeserver auch noch angezeigt, dass dort Port 110 offen ist. Das ist wie eingangs beschrieben, die Datei EdgeTransport.exe. Das sagt mir jetzt nichts. Einen Neustart kann ich derzeit nicht durchführen. Was könnte denn hier das Problem sein?

Alles klar. Danke!

Vielleicht weil manche Rechner als Anmeldeserver den defekten Server hatten?

Moin, ja, jetzt ist alles gut - Glaube ich zumindest. Ich war doch nochmal neugierig und hatte erst noch einmal den Server neu gestartet. Anschließend mit ntdsutil zuerst die Konsistenz der DB überprüft. Sie war ok. Nach ca. 15 min. kam der gleiche Fehler wieder in der Ereignisanzeige. Hier war mir spätendes klar, dass Ding mach ich platt. Eine Frage habe ich noch: Die ganzen Memberserver liefen die ganze Zeit weiter. Auch der Exchange. Der neue Server hat zwar die gleiche IP wie vorher, jedoch der Name ist jetzt anders. Müssen/sollen alle Memberserver neu gestartet werden? Gerade der Exchange? Stichprobenartige Kontrolle der Ereignisanzeigen zeigten mir nichts Verdächtiges an.

Danke für Deine Antwort. Ok, ich war auch kurz davor. Ich wollte jetzt erst mal abwarten, was hier noch kommt. Daher habe ich noch nichts weiter unternommen. In der Zwischenzeit habe ich auch noch im Internet weiter geforscht und komme eigentlich immer nur auf 3 Möglichkeiten: - Mit ntdsutil versuchen zu reparieren. - Eine Sicherung der AD zurückspielen - DC platt machen und neu aufsetzen Daher noch zwei Fragen: 1. Wäre es nicht zumindest ein Versuch wert, mit ntdsutil einen Reparaturversuch zu wagen? 2. Wie äußert sich der Fehler in der Umgebung? Außer einen Eintrag im Ereignisprotokoll konnte ich nichts festellen.