Es gibt Szenarien in denen ActiveSync Geräte verwendet werden, aber kein MDM/MAM zur Verfügung steht. Wäre es nicht dennoch schön nur Geräte einen Zugriff auf den on-prem Exchange zu ermöglichen die berechtigt für einen Email-Abruf sind?
Natürlich gibt es die Möglichkeit die Authentifizierung vom Exchange-Server zu Verlagern auf den NetScaler! Damit wird erst der Backend-Zugriff ermöglicht, wenn die Authentication erfolgreich durchlaufen wurden. Aber was ist mit den Zugriffen von verbotenen/unbekannten/alten Geräte die gültige Zugangsdaten verwenden? Diese gelangen bis zum Exchange, belasten die Infrastruktur und können ggf. Angriffe durchführen gegenüber dem IIS/Exchange.
Was nun tun um diesem Szenario gerecht zu werden? Microsoft setzt hier für Exchange auf die ActiveSync Quarantäne - nähere Infos zu Einrichtung hier. Um die Sicherheit zu erhöhen sollen unberechtigte Endgeräte aber gar nicht bis zum Exchange-Server durchgeleitet werden - auch wenn die korrekten Zugangsdaten verwendet werden!
Der NetScaler kann hier fabelhaft unterstützen und filtert alle unberechtigten ActiveSync Geräte! Dazu lesen wir bei der Benutzeranmeldung das Active-Directory-Attribut msExchMobileAllowedDeviceIDs aus und prüfen ob das verwendete Endgerät Zugriff erhalten darf. Ist die ActiveSync Quarantäne aktiviert speichert Microsoft für jedes erlaubte iOS und Android ActiveSync Geräte den Zugriff in dem Attribut. Dies sieht beispielsweise wie folgt aus:
Die Überprüfung und Filterung ist schnell eingerichtet. Dazu sind folgende Punkte vorab einzurichten:
- Aktivierung ActiveSync Quarantäne auf Exchange und pflege der Endgeräte
- Einrichtung NetScaler Content-Switch und Loadbalancer für Exchange-Dienste
- Aktivierung der 401 Based Authentication auf NetScaler für den Exchange ActiveSync-Loadbalancer via LDAP
Diese Punkte sind soweit Standard und in vielen Hersteller-/Foren-Beiträgen beschrieben. Auszugsweise hier die NetScaler Config zur Einrichtung:
- add authentication ldapAction LDAP_Exchange_SAM -serverIP 169.254.0.1 -serverPort 636 -ldapBase "DC=XXX, DC=local" -ldapBindDn XXX -ldapBindDnPassword XXX -ldapLoginName samAccountName -searchFilter "memberOf=OU=XXX,DC=XXX,DC=local" -groupAttrName memberOf -subAttributeName CN -secType SSL -ssoNameAttribute userPrincipalName -passwdChange ENABLED -Attributes msExchMobileAllowedDeviceIDs
- add authentication ldapAction LDAP_Exchange_UPN -serverIP 169.254.0.1 -serverPort 636 -ldapBase "DC=XXX, DC=local" -ldapBindDn XXX -ldapBindDnPassword XXX -ldapLoginName UserPrincipalName -searchFilter "memberOf=OU=XXX,DC=XXX,DC=local" -groupAttrName memberOf -subAttributeName CN -secType SSL -ssoNameAttribute UserPrincipalName -passwdChange ENABLED -Attributes msExchMobileAllowedDeviceIDs
- add authentication Policy AAA_LDAP_Exchange_SAM -rule true -action LDAP_Exchange_SAM
- add authentication Policy AAA_LDAP_Exchange_UPN -rule true -action LDAP_Exchange_UPN
- add authentication vserver AAA_SRV_Exchange SSL 0.0.0.0 -maxLoginAttempts 2 -failedLoginTimeout 5
- bind authentication vserver AAA_SRV_Exchange -policy AAA_LDAP_Exchange_UPN -priority 100 -gotoPriorityExpression NEXT
- bind authentication vserver AAA_SRV_Exchange -policy AAA_LDAP_Exchange_SAM -priority 110 -gotoPriorityExpression NEXT
- add authentication authnProfile AAA_prof_Exchange -authnVsName AAA_SRV_Exchange -AuthenticationHost outlook.XXX.com -AuthenticationDomain outlook.XXX.com
- add serviceGroup lb_srvgrp_Exchange_activesync SSL -maxClient 0 -maxReq 0 -cip ENABLED X-Forwarded-For -usip NO -useproxyport YES -cltTimeout 1800 -svrTimeout 1800 -CKA NO -TCPB NO -CMP NO -appflowLog DISABLED
- bind serviceGroup lb_srvgrp_Exchange_activesync LB_SRV_S-ex2 443 -CustomServerID "\"None\""
- bind serviceGroup lb_srvgrp_Exchange_activesync LB_SRV_S-ex1 443 -CustomServerID "\"None\""
- bind serviceGroup lb_srvgrp_Exchange_activesync -monitorName lb_mon_https-ecv-mail-msa
- set ssl serviceGroup lb_srvgrp_Exchange_activesync -sslProfile ns_default_ssl_profile_backend
- add lb vserver lb_vsrv_Exchange_443_activesync HTTP 0.0.0.0 0 -persistenceType SRCIPDESTIP -cltTimeout 180 -authn401 ON -authnProfile AAA_prof_Exchange
- bind lb vserver lb_vsrv_Exchange_443_activesync lb_srvgrp_Exchange_activesync
Nun kommt der spannende Teil. In der LDAP-Server Konfiguration Zeile 1 und 2 wurden definiert - siehe orangene Markierung -, dass das Attribut msExchMobileAllowedDeviceIDs zusätzlich abgerufen wird.
Um gerade bei der Einrichtung leicht zu Analysieren ob die Filterung ordnungsgemäß funktioniert werden blockierte Anfragen an einen Syslog-Server weitergeleitet. Dabei wird jeder Syslog-Server unterstützt. Im einfachsten Fall tut es auch eine KIWI-Demo-Installation. Die Config für den Syslog sieht so aus:
- add audit syslogAction SysLog_Act_Collector 172.16.10.32 -logLevel DEBUG -dateFormat YYYYMMDD -timeZone LOCAL_TIME -userDefinedAuditlog YES
- add audit syslogPolicy SysLog_Pol_Collector true SysLog_Act_Collector
- add audit messageaction SysLog_Act_Message_Exchange_blocked_Device_ID DEBUG "\"Exchange blocked DeviceID: \" + HTTP.REQ.URL.AFTER_STR(\"&DeviceId=\").BEFORE_STR(\"&DeviceType=\") + \" DeviceID in LDAP-msExchMobileAllowedDeviceIDs: \" + AAA.USER.ATTRIBUTE(\"msExchMobileAllowedDeviceIDs\") + \" from User: \" + AAA.USER.LOGIN_NAME"
In Zeile drei wird aus dem ActiveSync Request die DeviceID extrahiert. Diese befindet sich zwischen "&DeviceId=" und "&DeviceType=" in der URL. Der Syslog-Eintrag wird zudem noch mit dem Anmelde-Namen des Benutzers angereichert. So lässt sich hier einfach erkennen für welchen Benutzernamen unberechtigte Zugriffe erfolgen sollen. Das Log sieht dann wie folgt aus:
- default RESPONDER Message 265051811 0 : Context lb_vsrv_Exchange_443_activesync "Exchange blocked DeviceID: 1I0FA5322xxx DeviceID in LDAP-msExchMobileAllowedDeviceIDs: C66CNOPxxx,GHPJ99GGxxx,GVF6KJQ7xxx from User: demo\testuser"
Im Log sieht man so alle erlaubten DeviceIDs, sowie die blockierte DeviceID für den Benutzernutzer demo\testuser. Die DeviceIDs sind hier im Blog-Eintrag lediglich gekürzt und unkenntlich gemacht 😉 Der Kreativität beim Design des Syslog-Eintrags sind hier kaum Grenzen gesetzt.
Letztendlich kommt hier nun der Filter der als Responder-Policy realisiert wurde. Dieser wird gebunden an den ActiveSync-Loadbalancer. Das war es schon:
- add responder policy Res_Exchange_blocked_DeviceID "AAA.USER.ATTRIBUTE(\"msExchMobileAllowedDeviceIDs\").CONTAINS(HTTP.REQ.URL.AFTER_STR(\"&DeviceId=\").BEFORE_STR(\"&DeviceType=\")).NOT && HTTP.REQ.METHOD.EQ(POST)" DROP -logAction SysLog_Act_Message_Exchange_blocked_Device_ID
- bind lb vserver lb_vsrv_Exchange_443_activesync -policyName Res_Exchange_blocked_DeviceID -priority 100 -gotoPriorityExpression END -type REQUEST
In Zeile 1 wird die DeviceID extrahiert und geprüft diese kein(!) Bestandteil des Attributs msExchMobileAllowedDeviceIDs ist. Falls die Bedingung wahr ist erfolgt direkt auf dem NetScaler ein DROP der Verbindung und ein Log-Eintrag wird dafür erzeugt. Hier könnte auch ein RESET der Verbindung erfolgen je nach persönlichem empfinden.
Wird diese Einrichtung in einer Bestandsumgebung durchgeführt ist anzuraten stattdessen ein NOOP zu verwenden. Hierdurch werden Verbindungen erlaubt, aber die Policy erzeugt dennoch den Log-Eintrag. Somit kann die Einrichtung in Ruhe getestet werden vorab und Endanwender angeschrieben werden die unerlaubte Geräte verwenden. Anschließend die Policy auf DROP oder RESET ändern.
Kommentar schreiben