Beetlejuice

Hallo, nach unserer Migration von Exch 2010 zu Exch 2016 CU 8 haben wir Probleme in Outlook 2016 Std. die zusätzlich eingebunden Postfächern zu durchsuchen. Die extra Postfächer sind nicht via "automapped" eingebunden, sondern direkt in den Mail settings. Outlook 2016 Std. wurde als MSI installiert und ist aktuell die Version "16.0.4639.1000 - 64-bit". Die Suche auf dem eigenen Postfach funktioniert. Jedoch wenn ich ein anderes Postfach auswähle, kann ich dieses nicht immer durchsuchen. Vor der Migration mit Outlook 2016 und Exch 2010 SP3 hatte das immer Problemlos funktioniert. Folgende Szenarien habe ich getestet und unterschiedliche Ergebnisse bekommen. Folgende Tests beziehen sich jeweils auf die Suche in einer "shared Mailbox". - Inbox der shared Mailbox ausgewählt und Suchbereich auf "current Mailbox". Es werden nur Emails aus meinem eigenem Postfach gefunden. Das war vor der mig. definitiv nicht so. Es wurde da immer die Mailbox durchsucht, welche ausgewählt wurde. - Inbox der shared Mailbox ausgewählt und Suchbereich auf "current Folder". Es werden keine Emails gefunden.. :-(. - Inbox der shared Mailbox ausgewählt und Suchbereich auf "Subfolders". Es werden die Emails aus der selektierten Mailbox gefunden Ich habe zwar im Internet was von MS gefunden, aber der Fehler passt nicht ganz und wäre auch nicht meine Outlook Version. https://support.office.com/en-us/article/no-search-results-found-when-using-all-mailboxes-3a982433-cfdf-46f3-bae1-d9c50d79bebd https://social.technet.microsoft.com/Forums/en-US/893d8f02-f4c1-4e8d-b812-fb83b0c57906/outlook-2016-search-not-working-when-searching-all-mailboxes-or-all-outlook-items?forum=Office2016ITPro Bei der Suche über alle Mailboxen werden mir auch tatsächlich mails aus allen Mailboxen angezeigt. Kennt jemand von euch dieses Problem oder hat eine Idee? Danke

Dein Vorschalg... - PFDB unmounten - DB/Log Ordner Umbenennen und mit Originalnamen neu anlegen - Mounten, es wird eine leere PF DB angelegt - Migration wie gehabt durchführen Glücklichsein

Hi Norbert, danke für den Tipp, hat super funktioniert. VG

Ich würde gerne einen einzelnen Öffentlichen Ordner von 2010 nach 2016 migrieren. Aktuell sind da noch sehr viele, welche aber nicht mehr gebraucht werden und als PST archiviert wurden. Jetzt möchte ich aber genau einen davon doch noch migrieren. Gibt es hierfür einen einfachen Trick? Überlegung war zuerst, einfach eine neue DB + PF Mailbox anzulegen und dort einen neuen Ordner (und den PST export importieren). Das geht aber leider nicht, weil Exchange 2016 erkennt, dass es noch Öffentliche Ordner auf dem 2010er gibt. Danke.

Ich habe noch ein wenig rumprobiert und konnte es irgendwie doch zum laufen bringen, dazu gleich mehr. Das umstellen auf MAPI über HTTP hat leider nicht den gewünschten Erfolg gebracht. Ich habe dann die Daten in eine PST Datei gesichert und das Postfach kurzerhand gedroppt und das Postfach mit den gleichen Namen wieder angelegt. Name: Contacts Logon: svc-sync-exchange PW: das gleiche Alias: svc-sync-exchange und damit Primärer SMTP. Ich konnte mir das Postfach nicht einbinden, dieselben Fehler wie zuvor beschrieben. Mal versucht das MAPI umzustellen, auch keine Besserung. Anschließend habe ich den Alias neu gesetzt, ebenfalls auf Contacts. Der Primäre SMTP wurde dadurch ebenfalls geändert. Mit der Konstellation konnte ich mich dann mit Outlook Verbinden. Leider konnte ich das mit einen neuen Benutzer, mit ähnlicher Konfiguration nicht nachstellen. Hier habe ich nur den Logonname auf "svc-sync-exchange2" verändert. Das Problem scheint also irgendwie mit dem Alias "svc-sync-exchange" zusammenzuhängen. Sobald dieser geändert wird, funktioniert das. Ich lasse das jetzt so laufen, aber es wäre dennoch interessant, warum es hier so ein Problem gibt. Zumal ich in der Testumgebung dieses Problem nicht habe und es derart das einzigste Problem ist. Danke

Das Postfach nutzt die gleichen Primären SMTP wie die anderen Benutzer auch, nur der Display-Name ist nicht gleich der SMTP Adresse. Die Home DB sowie der Mailserver sind für das betreffende Postfach korrekt auf dem neuen Server. Database : MBXDB-SYS ServerName : win10065 Name : Contacts PrimarySmtpAddress : svc-sync-exchange@domain.com Wir haben ~ 300 Postfächer migriert und davon macht eines zicken. Ach ja die Serverversion, 2016 CU8 - siehe oben :). Da ich bei diesem Problem nicht so richtig weiterkomme habe ich es mal mit einem neuen Account versucht und die Kontakte dort importiert. Diese werde ich jetzt freigeben, nur muss ich alle Mitarbeiter dazu anleiten, das neue Postfach als "shared contacts" einzubinden.

Nein, ich komme nur an die Mailbox ran, wenn diese auf dem alten 2010er Exchange Server liegt. Sobald das Postfach auf dem neuen 1016er migriert wird, kann ich die Mailbox nicht öffnen. Auch Autoermittlung funkioniert hier nicht mehr. Das Problem vorher war, ich wollte das Postfach direkt in ein neues Outlook Profil laden, was mit dem 2016er Exchange nicht ging. Jetzt hatte ich die MBX zurück auf dem 2010er Migriert und das Outlook Profil auf mein Testrechner eingerichtet. MBx zum 2016 Migriert und Outlook gestartet. Es kann keine Verbindung aufgebaut werden, im "Connection Status" wird nur eine Verbindung zum alten Server angezeigt, Test der "Auto-Email Konfiguration" ist ebenfalls fehlgeschlagen. Konnte keine passende Konfiguration finden. Es sieht so aus, als würde das Postfach auf dem neuen 2016er nicht gefunden.

Ja, mailboxrepair als DetectOnly hatte keine Fehler gezeigt.

Es betrifft tatsächlich nur ein User, soweit bekannt. Anbei die Ausgabe vom get-casmailbox: [PS] C:\Windows\system32>get-casmailbox -identity contacts | fl RunspaceId : c9b3e5e1-f59e-4d54-a9bf-ba36a6560c88 EmailAddresses : {smtp:svc-sync-exchange@member.domain.de, smtp:svc-sync-exchange@domain.de, X400:C=DE;A= ;P=Erste Organisati;O=Exchange;S=Agent;G=SyncExchange;, SMTP:svc-sync-exchange@domain.com} LegacyExchangeDN : /o=Erste Organisation/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=svc-sync-exchange59b LinkedMasterAccount : PrimarySmtpAddress : svc-sync-exchange@domain.com SamAccountName : svc-sync-exchange ServerLegacyDN : /o=Erste Organisation/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=WIN10065 ServerName : win10065 DisplayName : Contacts ActiveSyncAllowedDeviceIDs : {} ActiveSyncBlockedDeviceIDs : {} ActiveSyncMailboxPolicy : Default ActiveSyncMailboxPolicyIsDefaulted : True ActiveSyncDebugLogging : False ActiveSyncEnabled : True HasActiveSyncDevicePartnership : False ActiveSyncSuppressReadReceipt : False ExternalImapSettings : InternalImapSettings : ExternalPopSettings : InternalPopSettings : ExternalSmtpSettings : InternalSmtpSettings : OwaMailboxPolicy : OWAEnabled : True OWAforDevicesEnabled : True IsOptimizedForAccessibility : False ECPEnabled : True PopEnabled : True PopMessageDeleteEnabled : False PopUseProtocolDefaults : True PopMessagesRetrievalMimeFormat : BestBodyFormat PopEnableExactRFC822Size : False PopSuppressReadReceipt : False PopForceICalForCalendarRetrievalOption : False ImapEnabled : True ImapUseProtocolDefaults : True ImapMessagesRetrievalMimeFormat : BestBodyFormat ImapEnableExactRFC822Size : False ImapSuppressReadReceipt : False ImapForceICalForCalendarRetrievalOption : False MAPIEnabled : True MapiHttpEnabled : MAPIBlockOutlookNonCachedMode : False MAPIBlockOutlookVersions : MAPIBlockOutlookRpcHttp : False MAPIBlockOutlookExternalConnectivity : False UniversalOutlookEnabled : True EwsEnabled : EwsAllowOutlook : EwsAllowMacOutlook : EwsAllowEntourage : EwsApplicationAccessPolicy : EwsAllowList : EwsBlockList : ShowGalAsDefaultView : True Identity : member.domain.de/domain/Technical/CRM/Users/Contacts IsValid : True ExchangeVersion : 0.20 (15.0.0.0) Name : Contacts DistinguishedName : CN=Contacts,OU=Users,OU=CRM,OU=Technical,OU=domain,DC=member,DC=domain,DC=de Guid : ce8943a9-fec2-47e2-91b6-82f81b117823 ObjectCategory : member.domain.de/Configuration/Schema/Person ObjectClass : {top, person, organizationalPerson, user} WhenChanged : 29.01.2018 09:16:40 WhenCreated : 22.06.2015 14:06:55 WhenChangedUTC : 29.01.2018 08:16:40 WhenCreatedUTC : 22.06.2015 12:06:55 OrganizationId : Id : member.domain.de/domain/Technical/CRM/Users/Contacts OriginatingServer : win10061.member.domain.de ObjectState : Changed Danke :)

Ich glaube, dass löst hier nicht das Problem Wir können das aber gerne in einem extra Thema konstruktiv diskutieren :). Kann man hieraus ein eigenes Thema öffnen oder einfach ein neues erstellen. Ich werde heute mal den DNS umstellen und das Verhalten testen. Danke!

Wir nutzen 2 verschiedene, einmal ein Externes auf dem Proxy für den OWA, ActiveSync zugriff und ein internes über die eigene PKI. Der Client vertraut dem Zertifikat und die SAN sind ebenfalls eingetragen. DNS Name: win10065.member.domain.de DNS Name: win10065 DNS Name: mail.member.domain.de DNS Name: mailserver.member.domain.de DNS Name: autodiscover.member.domain.de

Wir fahren bei uns 2 unterschiedliche DNS Zonen, ich bin auch kein Freund davon, die Internen IPs für externe DNS Namen zu verwenden. Die Ausnahmen habe ich soweit konfiguriert. Bei sophos ist das nicht ganz einfach, da gibt es tausende von Möglichkeiten, welche Regel oder Exception hier helfen kann. Ich habe mich hier an ein Tut von Frankys Web gehalten.

Hallo, wir haben letzte Woche von Exchange 2010 SP3 auf Exchange 2016 CU8 migriert, soweit auch erfolgreich :). Leider habe ich mit einem Postfach so meine Schwierigkeiten. Es ist ein normaler User der eine menge Kontakte hält, diese wiederum mit der Org. geshared werden. Die Mailbox sowie die Freigabe der Kontakte hatte mit Exch 2010 und Outlook 2016 problemlos funktoniert. Nur nachdem ich das Postfach auf Exchange 2016 Migriert habe, kann ich diese Kontakte von meiner Mailbox oder anderen nicht mehr Öffnen, keine Berechtigungen. Nun habe ich hier schon einiges getestet und verschiedene Ergebniss bekommen, alle ein wenig Deprimierend :(. 1. Berechtigungen für Kontakte mit der Shell geprüfft, vorhanden. -->Berechtigungen wurden auch entzogen und neu gesetzt. 2. FullAccess Permissions auf die Mailbox für mein Account um diese in Outlook zu öffnen und ggf. Berechtigungen kontrollieren. --> Postfach lässt sich nicht als zusätzliches Postfach einbinden, findet keine Verbindungsdaten. 3. Als betreffende Mailbox in Win7/10 angelemdet und Outlook gestartet. --> Profil kann in Outlook nicht erstellt werden, keine Verbindungsdaten. 4. Postfach in OWA geöffnet --> Funktioniert einwandfrei, auch die Kontakte sind vorhanden. 5. Verhalten in der Testumgebung nachgestellt (Kopie der Prod vor Migration). --> Postfach ist ok, Berechtigungen vorhanden, zugriff ist möglich, Outlook Profil lässt sich laden und extern einbinden. --> WTF was ist anders ??? 6. Betreffendes Postfach auf alten Exchange zurückmigriert und mit Outlook geöffnet. --> Funkioniert, berechtigungen sind zwar weg, (ACL Fehler bei der Migration) aber ok, kann man mit arbeiten. 7. Postfach wieder zurück auf neuen Exchange migriert und mit Outlook Öffnen. --> Selbes verhalten wie am Anfang, keine Besserung. Berechtigungen vorhanden und neu gesetzt. 8. New-MailboxRepairRequest mit DetectOnly gestartet --> Bringt keine fehler oder Korrupte Daten zurück. Habt Ihr noch weitere Ideen für mich, wie ich das Postfach wieder zum laufen bringen kann? Danke.

Hallo wir haben "vermutlich" das gleiche Problem. Bei uns kommt es ebenfalls vor, das Outlook 2016 (MSI Installer) keine Verbindung zum Exchange 2016 aufbaut, obwohl das Netzwerk/Firewall korrekt konfiguriert ist. Hintergrund, wir haben vor einer Woche den Exchange von 2010 auf 2016 migriert, vorher hatten wir keine Probleme. Es ist nicht ganz reproduzierbar, aber wenn Outlook dann mal neugestartet wird oder bei der ersten Anmledung, kann es vorkommen dass Outlook sich nicht zum Exchange über MAPI (HTTP/SSL) Verbinden kann. Im "Connection Status" wird dann nur eine oder 2 Verbindungen angezeigt, welche aber nicht verbunden sind. Ein Reconnect hilft da auch nicht. Die Autoermittlung funktioniert. Einzig Geduld hat hier bisher geholfen, wobei ich dass nicht befürworte und Akzeptable finde. Es machte auch kein Unterschied ob der Rechner neugestartet wurde oder Outlook x-mal neugestartet wurde oder Outlook hat sich dann irgendwann von alleine neu verbunden. Viele neue Ideen habe ich auch nicht. Wir versuchen als nächstes die Externen URLs zu deaktivieren oder auf die gleiche wie die interne zu setzten. Outlook muss bei uns nicht von extern erreichbar sein, dafür gibt es bei uns das VPN. Da wir einen Sophos Proxy einsetzen, auf dem aktuell die externen anfragen landen (Hauptsächlich für OWA und ActiveSync), könnte ich mir auch Vorstellen, dass Outlook sich über die Verbindungen (intern/extern) nicht einig wird und daher dieser murks kommt. Auf jedenfall findet eine menge traffic mit dem Proxy statt, owbohl dieser eigentlich nicht notwendig ist. Der Mitarbeiter ist im Internen Netz und kann alle notwendigen Dienste/Ports auf dem Exchange erreichen. VG

Danke für die schnelle Antwort, damit hast du mir geholfen. Die noch vorhandenen Zonen waren tatsächlich im Windows 2000 compatible modus. In dem folgenden Artikel habe ich auch noch interessantes zum veralten von DNS in PowerShell gefunden. http://www.tomsitpro.com/articles/powershell-dns-record-permissions,2-930.html Viele Grüße, Henry

Hallo zusammen, ich möchte gerne die Verwaltung einiger Zonen (Forward + Reverse) an eine spezielle Admin Gruppe delegieren. Jetzt kann ich das zwar über die DNS MMC, die Gruppe einzeln in alle Zonen eintragen, was aber auf dauer aufwendig ist. Jetzt wollte ich das via "dsacls" umsetzten, jedoch findet er hier keine Objekte. dsacls.exe dc=vpn,cn=MicrosoftDNS,cn=system,dc=meine,dc=domain,dc=de Nachdem ich das via ADSIEditor geprüft habe, scheint es so, dass nicht alle DNZ Zonen im AD gespeichert sind, obwohl das für die Zone im DNS angezeigt wird. Ich sehe hier nur wenige Reverse-Zonen und 2 alte Forward Zonen. Die Ad Domain ist ebenfalls nicht enthalten. Gibt es eine andere Application-Partition, wo die Zonen und die Daten gespeichert werden? Sind die Daten versteckt, dass ich diese nicht sehen kann? Gibt es noch eine andere Möglichkeit die Berechtigung zu delegieren? Danke

Hallo, Ich habe heute die Prüfung zur 417 abgelegt und habe leider nicht bestanden. Das Ergebnis der einzelnen Teile waren 410 - 900 411 - 800 412 nur 660 Ich habe mich mit dem Microsoft Buch, Technet, test Umgebung und den virtual Labs von ms vorbereitet. Habt ihr noch Tipps wie ich mich für den Teil 412 - advanced Features vorbereiten kann. Das waren irgendwie fiese fragen. Gruß

Hi, dann passt das ja zu unseren beiden Beobachtungen. es ist aber irgendwie nicht schön 2 verschieden AD Benutzer zu haben. Für die Freigaben wird dann primär der AD-USER verwendet, es sei denn du gibst explizit einen anderen User an. Dies muss ja nicht der VPN-USER sein, sondern kann jeder x-beliebige AD USER sein. Der Zugriff auf den Domain-Stamm (dev.domain.de), um sich am Anmeldeserver zu registrieren oder GPOs zu beziehen, dafür wird dann ausschließlich der VPN-AD-USER verwendet. Das ist natürlich doof, da die GPO's und auch an dem VPN-AD-USER hängen müssen und das ist finde ich eine weitere Schwachstelle, die bei weiteren Konfiguration vom Admin übersehen werden könnte. cu

Moin, vielen dank für Deine Bemühungen. Es ist schade, dass es mit youtube nicht so funktioniert hat, aber ich habe mir das Video auch so angeschaut ;). Aufgefallen ist mir, dass Du eine Verbindung zur Freigabe explizit mit einem anderem User aufbaust. Ich habe die Freigabe immer direkt im Explorer eingegeben, somit wird die Sitzung des angemeldeten AD-USERs verwendet. Deine Vorgehensweise werden ich ebenfalls nochmal nachstellen. Danke und cu

Hast du das VPN mit NAP oder ohne gemacht?

Sehr kurios ... Ich habe zuerst in die Security Logs geschaut und nach einem zugriff auf den Fileserver, wurde mit der AD-USER angezeigt. Vom VPN-AD-USER fehlt da jede spur. Als 2. habe ich dann die Freigabe beschränkt dass einmal der AD-USER und einmal der VPN-AD-USER keine Berechtigung haben hier zuzugreifen. Auch wenn der VPN-AD-USER keine Berechtigung hatte konnte ich drauf zugreifen. Aber als der AD-USER keine Berechtigung mehr hatte, konnte ich auch nicht auf die Freigabe zugreifen.

Hi, @Norbert, wie verlief die umstellung? Ich habe nun die TMG mit Radius eingerichtet um die Nutzer gegen das AD zu prüfen. @ Reingucker Der RADIUS VPN-AD-USER wurde für die Anmeldung an der Domäne verwendet, auch wenn sich bereits ein AD Benutzer authentifiziert hat. Ich habe dann mit KLIST nachgeschaut und habe auch Tickets beider User (VPN-AD-USER + AD-USER) gesehen. Wenn ich auf die Domäne zugreife (GPO's / Netlogon) wird dieser VPN-AD-USER verwendet, da sehe ich TGT's für KRB und einige der DC's für den CIFS Dienst. Wenn ich nun auf Fileserver oder andere Dienste (Printserver, Freigaben vom DC usw.) zugreife wird ein TGT für den Angemeldeten AD-USER verwendet bzw. angefordert. #0> Client: ad-user @ DEV.DOMAIN.DE Server: krbtgt/DEV.DOMAIN.DE @ DEV.DOMAIN.DE KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96 Ticketkennzeichen 0x60a00000 -> forwardable forwarded renewable pre_authent Startzeit: 2/10/2015 11:00:01 (lokal) Endzeit: 2/10/2015 20:58:01 (lokal) Erneuerungszeit: 2/17/2015 10:58:01 (lokal) Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96 #1> Client: ad-user @ DEV.DOMAIN.DE Server: cifs/storage2.DEV.DOMAIN.DE @ DEV.DOMAIN.DE KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96 Ticketkennzeichen 0x40a00000 -> forwardable renewable pre_authent Startzeit: 2/10/2015 11:05:09 (lokal) Endzeit: 2/10/2015 20:58:01 (lokal) Erneuerungszeit: 2/17/2015 10:58:01 (lokal) Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96 #2> Client: ad-user @ DEV.DOMAIN.DE Server: cifs/DC1.DEV.DOMAIN.DE @ DEV.DOMAIN.DE KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96 Ticketkennzeichen 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate Startzeit: 2/10/2015 11:00:01 (lokal) Endzeit: 2/10/2015 20:58:01 (lokal) Erneuerungszeit: 2/17/2015 10:58:01 (lokal) Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96 #3> Client: ad-user @ DEV.DOMAIN.DE Server: cifs/DC2.DEV.DOMAIN.DE @ DEV.DOMAIN.DE KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96 Ticketkennzeichen 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate Startzeit: 2/10/2015 11:00:01 (lokal) Endzeit: 2/10/2015 20:58:01 (lokal) Erneuerungszeit: 2/17/2015 10:58:01 (lokal) Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96 #4> Client: ad-user @ DEV.DOMAIN.DE Server: cifs/fileserver.DEV.DOMAIN.DE @ DEV.DOMAIN.DE KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96 Ticketkennzeichen 0x40a00000 -> forwardable renewable pre_authent Startzeit: 2/10/2015 10:58:01 (lokal) Endzeit: 2/10/2015 20:58:01 (lokal) Erneuerungszeit: 2/17/2015 10:58:01 (lokal) Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96 #5> Client: vpn-ad-user @ DEV.DOMAIN.DE Server: krbtgt/DEV.DOMAIN.DE @ DEV.DOMAIN.DE KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96 Ticketkennzeichen 0x60a00000 -> forwardable forwarded renewable pre_authent Startzeit: 2/10/2015 11:04:25 (lokal) Endzeit: 2/10/2015 21:04:24 (lokal) Erneuerungszeit: 2/17/2015 11:04:24 (lokal) Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96 #6> Client: vpn-ad-user @ DEV.DOMAIN.DE Server: cifs/DC1.DEV.DOMAIN.DE @ DEV.DOMAIN.DE KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96 Ticketkennzeichen 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate Startzeit: 2/10/2015 11:04:25 (lokal) Endzeit: 2/10/2015 21:04:24 (lokal) Erneuerungszeit: 2/17/2015 11:04:24 (lokal) Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96 #7> Client: vpn-ad-user @ DEV.DOMAIN.DE Server: cifs/DC2.DEV.DOMAIN.DE @ DEV.DOMAIN.DE KerbTicket (Verschlüsselungstyp): AES-256-CTS-HMAC-SHA1-96 Ticketkennzeichen 0x40a40000 -> forwardable renewable pre_authent ok_as_delegate Startzeit: 2/10/2015 11:04:25 (lokal) Endzeit: 2/10/2015 21:04:24 (lokal) Erneuerungszeit: 2/17/2015 11:04:24 (lokal) Sitzungsschlüsseltyp: AES-256-CTS-HMAC-SHA1-96 Wir vertrauen der ganze sache noch nicht, haben Befürchtungen dass es zu Problemen mit den beiden AD Sitzungen geben könnte und prüfen gerade ob das VPN mit dem eigentlichen AD User authentifiziert werden kann. Hierzu muss jedoch gewährleistet sein, dass sich Benutzer nur von bestimmten PCs aus anmelden können. Dies sollte sich mit NAP auf dem NPS einrichten lassen aber leider wird das VPN immer als "non-NAP capable" aufgebaut. @ Reingucker, hattest Du den test mit NAP gemacht oder einfach nur über NPS ohne NAP Regeln wie SHV usw? Danke

Es ging nicht darum ob es geht oder nicht. Das man in vielen FW das abbilden kann ist mir klar. Es ist nur die Frage wie aufwändig ist das ganz. Als Beispiel, bei IPTables definiere ich meistens source/destiniation und port. Wenn ich aber mehrere Ports erlauben möchte, kann ich entweder mehrere Regeln machen oder muss eine Gruppe mit den Ports definieren und diese dann zuweisen. Ich finde gegenüber der TMG ist das sehr aufwändig und Wartungsintensiv. Als weiteres Feature, was bei vielen FW's nicht so schön ist, ist das Logging und auswerten. Es geht aber in der TMG geht es wesentlich einfacher und besser. Ich mag die Sophos ja nicht schlecht reden, dazu habe ich mir diese zu wenig angeschaut. Jedoch hat mich diese im Gesamteindruck aufs erste nicht überzeugt. Viellicht sollte ich mir diese nochmal in ruhe anschauen um dann besser zu beurteilen können. Wir setzten als weitere FW ebene noch eine SonicWALL (DELL) ein. Die macht einen guten Eindruck, wobei auch hier die Wartung der Regeln viel mehr Zeit verlangt. AD FS ist eine interessante Alternative, welche wir uns auch demnächst anschauen, zumal viele weitere Produkte von MS darauf bauen bzw. profitieren können.

Ist jetzt zwar was Off-Topic, aber ich hatte mir die SOPHOS UTM als abgespeckte Version angeschaut. sie wirkte auf mich sehr langsam und träge. Allzu viel kann ich gar nicht mehr dazu sagen, das war jetzt ein Jahr her. Der erste Eindruck war ganz gut, jedoch hat mich diese weiterhin nicht überzeugt. Wir haben und auch mal die FreeBSD variante "PFSense" angeschaut, ist aber auch keine alternative. Unsere Anforderungen sind z.B. - VPN mit integrierten Windows Client (IPsec/L2TP oder SSTP) - Routing/Firewalling von mehreren Subnetze (~25) - Regeln für unterschiedlichste Zugriffe IN und AUS diesen Netzen mit unterschiedlichsten Ports. - Zugriffe durch Benutzer (VPN-Benutzer) regeln Die meisten System haben Probleme so viele Netze mit einer schnelle Anbindung (mehrere 10 GB NICs) anzubinden und dann noch die Regeln effizient und Wartbar zu Pflegen. Das Regelwerk ist bei den meisten ein ... graus :(

Ja, der Aufwand und der mehrwert sind zu gering um seine eigene Zertifikate Öffentlich und Vertrauenswürdig, für die Globale Masse, zu machen. Jeder müsste deine Root/Sub Zertifikate runter laden und vertrauen. Das ist für die meisten Anwender zu viel Technik.