askando
Goto Top

Ermitteln welcher User mit wie vielen Outlook Clients verbunden ist. (Exchange 2013)

Hallo Zusammen,

eine kurze Frage.Ich muss bei einem neuen Kunden einiges im Bereich IT Sicherheit nachholen, was hier vom alten Admin versäumt wurde.
Beim Exchange 2013 habe ich als erstes für die mobilen Endgeräte Policies erstellt - damit alle neu verbundenen Geräte in Quarantäne kommen und zugelassen werden müssen.
Zudem alle alten Geräte gesperrt - die keine Berechtigung mehr haben.

Jetzt stelle ich mir gerade die Frage was ich tun kann, um eine ähnliche Übersicht zu bekommen bei allen Geräten die sich per Outlook Anywhere außer Haus verbinden / verbunden haben.
Beim Kunden steht ein Exchange 2013 mit Outlook Anywhere und einem selfsigned Zertifikat .

Schon klar das man sich dann nur verbinden kann - wenn man das Zertifikat installiert hat, aber potentiell kann sich jeder Mitarbeiter dieses kopieren und auf einen privaten PC ohne jegliche Richtlinien installieren und das stört mich.

Kennt ihr eine Möglichkeit außer "Get-LogonStatistics -Server" bzw. "Get-MailboxStatistics" aktive oder alte Verbindungen je Postfach am CAS anzuzeigen?

Danke für eure Hilfe

P.s. Ich habe nun ein Script für Exchange 2010 gefunden, womit man aktive CAS Connections auslesen kann.
kann ich es auch bei Exchange 2013 nutzen?

$casservers = Get-ClientAccessServer
 
$stats = @()
foreach ($casserver in $casservers)
{
    $casservername = $casserver.name
 
    $OWA = $NULL
    $RPC = $NULL
    $EAS = $NULL
    $EWS = $NULL
    $POP = $NULL
    $IMAP = $NULL
     
    $OWA = (Get-Counter "\MSExchange OWA\Aktuelle eindeutige Benutzer" -ComputerName $casservername).CounterSamples.CookedValue  
    $RPC = (Get-Counter "\MSExchange RPCClientAccess\Anzahl Benutzer" -ComputerName $casservername).CounterSamples.CookedValue  
    $EAS = (Get-Counter "\MSExchange ActiveSync\Anforderungen/Sek." -ComputerName $casservername).CounterSamples.CookedValue  
    $EWS = (Get-Counter "\MSExchangeWS\Anforderungen/s" -ComputerName $casservername).CounterSamples.CookedValue  
    $POP = (Get-Counter "\MSExchangePOP3(_total)\Aktuelle Verbindungen" -ComputerName $casservername).CounterSamples.CookedValue  
    $IMAP = (Get-Counter "\MSExchangeIMAP4(_total)\Aktuelle Verbindungen" -ComputerName $casservername).CounterSamples.CookedValue  
     
    $OWA = "{0:N0}" -f $OWA  
    $RPC = "{0:N0}" -f $RPC  
    $EAS = "{0:N0}" -f $EAS  
    $EWS = "{0:N0}" -f $EWS  
    $POP = "{0:N0}" -f $POP  
    $IMAP = "{0:N0}" -f $IMAP  
     
    $stats += new-object PSObject -property @{CASServer="$casservername";OWA="$OWA";RPC="$RPC";EAS="$EAS";EWS="$EWS";POP3="$POP3";IMAP4="$IMAP"}  
}

Content-ID: 353350

Url: https://administrator.de/contentid/353350

Ausgedruckt am: 22.11.2024 um 01:11 Uhr

xbast1x
xbast1x 01.11.2017 um 11:18:24 Uhr
Goto Top
interessantes Thema. Gibt es dann eine Möglichkeit die ausgelesenen Clients zu sperren?
certifiedit.net
certifiedit.net 01.11.2017 um 11:46:08 Uhr
Goto Top
Hi,

prinzipiell guter Ansatz, wenn du sagst, dass das ein Sicherheitsthema ist, steht der Kunde doch noch gut da. Ich hoffe, die alten Nutzer (nicht mehr aktiv) sind sowieso gesperrt. Wichtiger wäre wohl die grundsätzliche IT-Richtlinie. Denn, wenn der Benutzer gesperrt ist, bekommt er sowieso keinen Zugriff mehr.

UTM ist vorhanden?

LG
Dani
Dani 01.11.2017 aktualisiert um 12:21:46 Uhr
Goto Top
Moin,
Schon klar das man sich dann nur verbinden kann - wenn man das Zertifikat installiert hat, aber potentiell kann sich jeder Mitarbeiter dieses kopieren und auf einen privaten PC ohne jegliche Richtlinien installieren und das stört mich.
ich sehe die Statistik eher als nice to have. Wichtiger ist doch eine technische Konfiguration, welche die Verbindung über das Internet entsprechend erlaubt bzw. verweigert.

Beim Kunden steht ein Exchange 2013 mit Outlook Anywhere und einem selfsigned Zertifikat .
Ich hoffe, dass hat nur einen wirtschaftlichen Grund für die Art des Zertifikats...

Meines Wissens nach ist eine technische Umsetzung nur mit Microsoft ADFS und Microsoft Web Application Proxy (WAP) möglich.
Mit Exchange 2016 gibt es für das cmdlet Set-CASMailbox eine Parameter MAPIBlockOutlookExternalConnectivity, welche eine Steuerung am Exchange-Server erlaubt.


Gruß,
Dani
askando
askando 01.11.2017 um 12:57:35 Uhr
Goto Top
Die Mailkonten liegen beim Provider und werden mit einem Pop Connector an den Exchange weitergeleitet.
Deswegen brauche ich an der Stelle auch keinen Proxy bzw. Spam Filter und genau aus dem Grund (weil kein mx record besteht) macht ein signiertes Zertifikat auch keinen Sinn, sondern würde nur Kosten. Auf gut deutsch ich habe nichts vom signierten Zertifikat.

Generell gibt es Mitarbeiter die per Outlook anywhere arbeiten sollen (Außendienst)- deswegen kann ich nicht dem CAS verbieten MAPI extern zu betreiben.

Also so wie es aussieht nach stundenlangen googlen, kann man nur aktive Verbindungen loggen und schauen wer momentan mit dem CAS verbunden ist. Finde ich von MS Seite aus ziemlich schwach. face-sad
certifiedit.net
certifiedit.net 01.11.2017 um 13:01:04 Uhr
Goto Top
Warum? Der Nutzer, der keine Verbindung aufbauen soll, dem verbietest du es eben?

Ich hab das Gefühl, dass du hier das große Ganze wegen einer vermeintlich guten Idee übersiehst.
Dani
Dani 01.11.2017 aktualisiert um 13:21:42 Uhr
Goto Top
Moin,
Deswegen brauche ich an der Stelle auch keinen Proxy bzw. Spam Filter und genau aus dem Grund (weil kein mx record besteht) macht ein signiertes Zertifikat auch keinen Sinn, sondern würde nur Kosten. Auf gut deutsch ich habe nichts vom signierten Zertifikat.
nur weil das Wort Proxy vorkommt, heißt es nicht dass es auch solch einer im klassichen Sinn ist. Der Modus (Forward, Transparent und Reserve) ist der feine Unterschied. Ich schlage vor du liest (nochmals) nach was ADFS in Verbindung mit WAP kann. Danach können wir diskutieren, ob es das Mittel zum Zweck für dich ist.

Also so wie es aussieht nach stundenlangen googlen, kann man nur aktive Verbindungen loggen und schauen wer momentan mit dem CAS verbunden ist. Finde ich von MS Seite aus ziemlich schwach.
Was ist der Ereignisanzeige des Exchange-Servers? Im Bereich Sicherheit müsstest du eigentlich fündig werden. Unabhängig davon müsste auch das Protokoll des IIS bzw. AppPool entsprechende Prokotolldateien mitschreiben.

Warum dich die Statistiken mehr interessieren, als eine technische Lösung des Problem, erschließt sich mir nicht. Denn in 99% der Fälle werden doch Berechtigungen über Gruppen, Zertifikate oder sogar OTPs abgebildet. Somit hast du jeder Zeit einen Überblick wer wo wie zugreifen darf.


Gruß,
Dani