Granikos Technology Blog

This interview Adnan and I talk about the challenges in the current situation with COVID-19. Companies are forced into enabling remote work at a pace they cannot control efficiently. At the same time, the fast-rising numbers of users utilizing collaboration tools put additional load on company networks that those were never planned for. IT departments are required to deliver the same high-quality standard for remote workers as for the on-premises workforce. 

Here is the recording, available on Adnan's iMentorCloud YouTube Channel. Enjoy.

Video-Link: https://go.granikos.eu/iMentorCloudMar2020-1

Adnan Rafique

Adnan Rafique is a Collaboration Architect for Microsoft Exchange and Office 365. He is a subject matter expert in this area since the days of Exchange Server 2007.

Links

• Reach out to Adnan via Twitter: @iMentorCloud
• Visit his website: http://www.exchangeitpro.com/

If you want to share free and busy details between two Exchange organizations, you usually use the Microsoft Federation Gateway. Sometimes this is not possible, e.g., for compliance reasons, or other business reasons. But there exists a way to do this, even without an Active Directory trust between two organizations.

Let us say we have two Exchange organizations: contoso.com and adatum.com.

The prerequisites are:

• you can resolve and access the target AutoDiscover-endpoint from the source domain infrastructure (hint: you can use pin-point DNS zones)
• you can resolve and access the Exchange Web Services (EWS) endpoint from the source domain infrastructure (note that the Availability Service (AS) accesses the InternalUrl)
• you add an account in each Active Directory forest which does not have any specific permissions assigned (membership of "Domain Users" security group is sufficient, no mailbox needed). 

I will use user account freebusy in this example.

Execute the following in contoso.com Exchange organization using Exchange Management Shell:

$TargetSmtpDomain = 'adatum.com'
$TargetDomainAccount = 'adatum.com\freebusy'

Add-AvailabilityAddressSpace - Forest $TArgetSmtpDomain -AccessMethod OrgWideFB -Credentials (Get-Credentials -User $TargetDomainAccount) 

Set-AvailabilityConfig -OrgWideAccount $TargetDomainAccount.Split('\')[1]

Execute the following in adatum.com Exchange organization using Exchange Management Shell:

$TargetSmtpDomain = 'contoso.com'
$TargetDomainAccount = 'contoso.com\freebusy'

Add-AvailabilityAddressSpace - Forest $TargetSmtpDomain -AccessMethod OrgWideFB -Credentials (Get-Credentials -User $TargetDomainAccount) 

Set-AvailabilityConfig -OrgWideAccount $TargetDomainAccount.Split('\')[1]

Exchange Server in the source organization must be able to resolve the recipient address for requesting free/busy information from the target organization. Exchange Server can determine a target address accurately when you create the recipient object as a contact in the source Exchange organization. 

For this example, you create contact objects in adatum.com for all user in contoso.com and vice versa. You can use GalSync or any other identity management (IDM) software that can handle object synchronization.

Problem

When using Exchange Server 2013, or 2016, you may run into a problem.

The HttpProxy log of the requesting Exchange Server log will state that AutoDdiscover failed for generic mailbox 01B62C6D-4324-448f-9884-5FEC6D18A7E2@contoso.com (or adatum.com).

HttpProxy log excerpt:

2019-07-26T07:19:24.649Z,2827102f-75b1-4ecb-ae6c-36b075bb8e93,15,1,1779,2,,Autodiscover,autodiscover.contoso.com,/autodiscover/autodiscover.xml,,Basic,true,CONTOSO\freebusy,,MailboxGuid~01b62c6d-4324-448f-9884-5fec6d18a7e2,ASAutoDiscover/CrossForest/EmailDomain//15.01.1779.002,172.16.0.20,CONTOSO-EX1,404,,MailboxGuidWithDomainNotFound,POST,,,,,AnchorMailboxHeader-MailboxGuidWithDomain-NoUser,,,,381,,,,0,,,0,1;0;,1,,0,1,,0,4,0,,,,,,,,,0,3,0,,3,,3,3,,,,BeginRequest=2019-07-26T07:19:24.646Z;CorrelationID=<empty>;ProxyState-Run=None;AccountForestGuard_contoso.com=1;AccountForestGuard_contoso.com=1;ProxyState-Complete=CalculateBackEnd;SharedCacheGuard=0;EndRequest=2019-07-26T07:19:24.649Z;I32:ADS.C[CONTOSO-DC1]=2;F:ADS.AL[CONTOSO-DC1]=0.8201787,HttpProxyException=Microsoft.Exchange.HttpProxy.HttpProxyException: Cannot find mailbox 01b62c6d-4324-448f-9884-5fec6d18a7e2 with domain contoso.com.    
at Microsoft.Exchange.HttpProxy.AnchorMailbox.CheckForNullAndThrowIfApplicable[T](T ret)    
at Microsoft.Exchange.HttpProxy

Reason

If DNS is used to resolve the AutoDiscover endpoint of the target Exchange organization, the source Exchange organization queries AutoDiscover information for a mailbox with that uid. SCP-based AutoDiscover lookup does not use this dedicated uid-based email address.

Solution

To solve this issue, you add the required SMTP address found in the HttpProxy log to one user mailbox in the target organization.

In the contoso.com organization:

Set-Mailbox -Identity 'someuser@contoso.com' -EmailAddresses @{add='01B62C6D-4324-448f-9884-5FEC6D18A7E2@contoso.com'}

In the adatum.com organization:

Set-Mailbox -Identity 'someuser@adatum.com' -EmailAddresses @{add='01B62C6D-4324-448f-9884-5FEC6D18A7E2@adatum.com'}

Links

• GalSync, https://www.netsec.de/en/products/galsync

Heute wurde mein Gastbeitrag im ENow Exchange & Office 365 Solutions Engine Blog (ESE) zum Thema

Modern Attachments with OneDrive for Business

veröffentlicht.

Ich wünsche viel Spaß beim Lesen.

Hier geht es zum Artikel: http://blog.enowsoftware.com/solutions-engine/modern-attachments-with-onedrive-for-business

The use of certificate-based email encryption is still a challenging task for administrators. When you store end-user certificates stored locally on computers, you accept the risk of the user certificates being deleted or overwritten unintentionally.

The use of smart cards helps to mitigate the risks associated with locally stored certificates. But smart cards are too complicated for large and agile companies. The use of smart cards with mobile devices is even more complicated, if not impossible.

Gateway Encryption

A simple and reliable solution is to use encryption and decryption capabilities at the company email gateway(s). This approach allows for:

• Central management of user and domain certificates or keys
  • S/MIME
  • PGP
• Central management of digital signage and encryption parameters for email communication with partner companies
• Encryption of any outgoing email communication regardless of the client used to compose the message:
  • Outlook
  • OWA
  • Outlook on the web
  • Mobile phone
  • Tablet Application
• Usage of internal eDiscovery solutions as internally stored email communication is still searchable
• No lost user certificates anymore

Besides the option to import certificates manually, the real benefit is provided by automatic certificate provisioning. By using a certificate authority company account the gateway solution handles certificate requests automatically.

The supported S/MIME certificate authorities are:

• D-TRUST
• GlobalSign
• SwissSign

NoSpamProxy by Net at Work is a gateway solution proving this set of features for on-premise SMTP messaging infrastructures.

Office 365

The advantages provided by NoSpamProxy can be used with Office 365 as well. There is no need to have an Exchange Hybrid configuration ins place to benefit from the NoSpamProxy features. The NoSpamProxy gateway can be configured for the use with Office 365 cloud-only tenants.

The following picture illustrates how NoSpamProxy gateway is integrated into such a scenario.

External emails are received by the local NoSpamProxy Gateway server and not by Exchange Online (1). The NoSpamProxy gateway handles the messages and sends the messages to Office 365 using an Office 365 connector (2). Outgoing messages to external recipients are sent to the on-premise NoSpamProxy gateway using a dedicated Office 365 Send Connector (3). The NoSpamProxy gateway handles the messages and sends the messages to the external recipients.

Multiple NoSpamProxy gateway servers can be deployed for a redundant setup.

NoSpamProxy

The NoSpamProxy gateway solution provides more than just S/MIME or PGP encryption capabilities. NoSpamProxy is a robust fully-fledged anti-spam solution that rejects spam emails legally compliant. Each message that is not fully received by the company does not need to be archived.

NoSpamProxy features:

• Legally compliant spam protection
• Legally compliant email communication using digital signage
• Protected email communication using password-protected PDF attachments
• Large attachment support by using a dedicated we portal
• Geographically dispersed gateways with central management

Want to know more about all NoSpamProxy features?
Not yet an Office 365 customer, but keen to know more about gateway-based encryption and a reliable anti-spam solution?

Get to know more about NoSpamProxy here.

Das Blog Cumulative Update für Mai 2020 (CU0520) fasst interessante Themen rund um Cloud Sicherheit, Exchange Server, Microsoft 365, Microsoft Teams und Azure des Monats Mai 2020 zusammen.

Allgemein

• [STICKY] Microsoft Products Reaching End of Support for 2019
• C5 Zertifizierung auch für die Microsoft Cloud in Deutschland
• Microsoft 365 Virtual Marathon - Recap
• Statement on the recent Greenpeace report
• 12 zentrale Assets für mein persönliches Fazit nach 2 Monaten Corona Homeoffice
• 2 years of digital transformation in 2 months

Exchange Server

• [STICKY] Outlook License Requirements for Exchange Features
• Event ID 1 MSExchange Autodiscover
• Demystifying and troubleshooting hybrid mail flow: when is a message internal?

Microsoft 365 | OneDrive | Exchange Online | and more

• [STICKY] Office 365 Network Performance Tool
• [STICKY] Office 365 Support and Recovery Assistant (aka SaRA)
• [STICKY] Office 365 URLs and IP address ranges
• [STICKY] Office 365-Trust Center
• Tech Talk 6 - Abschaltung von Basic Auth in Exchange Online
• Using PowerShell to Find Power Apps that use the SharePoint Connector
• Announcing OAuth Support for POP in Exchange Online
• New collaboration features on OneDrive for web
• Outlook Makes Online Meetings the Norm
• Announcing OAuth Support for POP in Exchange Online
• Reply All Storm Protection in Exchange Online
• Announcing Microsoft Lists - Your smart information tracking app in Microsoft 365
• Graph Mailbox Basics with PowerShell Part 1 Folders
• How to configure the new Room Finder in Outlook
• Multi-page scanning for everyone
• Generate Per-User Audit Reports for SharePoint Online Activity
• Stream Loses Face Detection Feature
• OneDrive | Gruppenrichtlinie Änderung: Synchronisierung von OneDrive
• Datenschutzeinstellungen und Datenschutzprüfung für das Microsoft Whiteboard
• Announcing OAuth 2.0 support for IMAP and SMTP AUTH protocols in Exchange Online

Microsoft Teams

• [STICKY] Security and Compliance in Microsoft Teams
• [STICKY] Keyboard shortcuts for Microsoft Teams
• [STICKY] Surface Hub update history
• [STICKY] Instructor-led training for Microsoft Teams
• Microsoft Teams and teaching
• Contact Center integrations for Microsoft Teams
• New Microsoft Teams Shifts features to build richer Firstline Worker experiences
• What's new in the Microsoft Teams Platform | Microsoft Build 2020
• Automate teams provisioning with the Request-a-team app template
• Teams Real Simple with Pictures: Rethinking Gif’s in Teams
• Automate teams provisioning with the Request-a-team app template
• Getting started with Microsoft Teams Live Events
• Consolidate Teams and SharePoint activity reports
• How to get a moving background in a Microsoft Teams meeting (+ other fun things)

Microsoft Azure

• [STICKY] Azure Latency Test
• [STICKY] Virtual Machines Licensing FAQ
• [STICKY] Azure Architecture Center
• [STICKY] Microsoft Azure Trust Center
• AzUrlShortener: An open source, budget-friendly URL shortener
• Using Azure Active Directory Application Proxy to Publish Internal Apps

Cloud | Cloud Sicherheit

• [STICKY] Microsoft Security TechCenter
• Zero Trust and its role in securing the new normal
• Significant Improvements in Azure AD Connect
• C5 Zertifizierung auch für die Microsoft Cloud in Deutschland
• Free Security Assessment Tools based on CIS Controls
• Building your Security Practice with Microsoft Threat Protection and Azure Sentinel
• Staying safe and smart in the internet-of-things era
• Empowering your remote workforce with end-user security awareness
• Top 5 reasons organizations use OneDrive for data security
• Expanding Azure Active Directory support for FIDO2 preview to hybrid environments
• Announcing general availability of sensitivity labels with protection in SharePoint and OneDrive
• NRW Soforthilfe 2020 und E-Mail-Kommunikation - Die Geschichte eines angekündigten Betruges

Microsoft Training

• [STICKY] MCT Central
• Finding the right Microsoft Azure certification for you
• Microsoft 365 Certification and Exam Updates

Schule | Lernen

• Datenschutz in der digitalen Bildung – Anfrage im Landtag BW
• Schule und Digitalisierung - Wenn die DSGVO missverstanden wird

Docs | Knowledge Base | TechNet

• [STICKY] Getting started with the Cloud Adoption Framework
• Introduction to Teams policy-based recording for callings & meetings
• Use network upload to import your organization's PST files to Microsoft 365
• Azure AD Connect: How to recover from LocalDB 10-GB limit

Skype for Business Server | Communications

• [STICKY] Download: Skype for Business Network Assessment Tool
• List all SfBS & SfBO policies by type
• SfB 2015 Server Update - May 2020

Replay

• April 2020: Licensing Details for Litigation Hold in Office 365

Podcast Empfehlungen

• [STICKY] Collab Talk: #MsftBuzzChat Podcast series
• Episode #63 – Interview with Microsoft MVP Joanne C. Klein
• #MVPbuzzChat with Julie Yack
• UCStatus Podcast Episode 12: with TE-Systems talking Anynode SBC
• Episode #62 – Major Microsoft 365 feature announcements
• Zu Gast beim MVP Kaffeeklatsch
• Episode 61 – Notes from the field on usage and adoption during COVID-19
• Episode #60 – Supporting remote workers through Covid-19 using live events
• Episode #59 – Supporting remote workers through COVID-19
• Sync Up - a OneDrive podcast : Episode 7, "Mobile productivity on Android"
• In Episode 41 of the All About 365 podcast, we’re talking Exchange with Microsoft’s Greg Taylor
• UCStatus Podcast Episode 5: Microsoft Teams Phones & Device Management
• The Cloud Architects - Episode 39: "Do I really need to monitor Office 365?"
• Episode #49 - Microsoft Teams : How did we get here and what’s coming
• The Evolving Discussion around Adoption & Engagement
• Podcast: Episode #42 – Karuana Gatimu – Microsoft 365 Adoption
• Exchange Exposed

Tools

• Network Assessment Tool Plus
• ADFS Rapid Restore Tool
• Active Directory Migration Tool version 3.2
• Microsoft Azure, Cloud and Enterprise Symbol / Icon Set - Visio stencil, PowerPoint, PNG, SVG
• ISESteroids - PowerTheShell
• Mailscape 365 - Exchange Online Monitoring und Reporting
• Mailscape - Exchange Monitoring und Reporting
• Compass - Active Directory Monitoring und Reporting

Gerne unterstützen wir Sie bei der Planung und Durchführung Ihrer Exchange Server Implementierung oder Migration.

Sie denken über einen vollständigen Wechsel zu Microsoft 365 oder eine Hybrid-Konfiguration mit Office 365 nach? Wir beraten Sie umfassend und neutral über die Möglichkeiten der Office 365 Plattform und Microsoft 365.

Sie möchten mehr über Exchange Server 2019 erfahren? Gerne erläutern wir Ihnen die technischen Änderungen und Chancen für Ihr Unternehmen in einem individuellen Workshop. Bis dahin, werfen Sie doch einen Blick in das Microsoft Exchange Server 2019: Das Handbuch für Administratoren.

Weitere Informationen zu unseren Dienstleistungen finden Sie auf unserer Website (https://www.granikos.eu) oder Sie kontaktieren direkt unser Vertriebsteam: info@granikos.eu

In den vorherigen Blog-Artikeln wurde allgemein über die Herausforderungen beim Thema E-Mail Sicherheit, die Möglichkeiten der TLS Übertragungsverschlüsselung und der E-Mail Signierung und Verschlüsselung mit S/MIME gesprochen.

In diesem Blog-Artikel werden die Verschlüsselungskomponenten beschrieben, die sowohl für die Sicherung des Übertragungskanals, als auch für die Nachrichtenverschlüsselung verwendet werden. Der Schwerpunkt des Artikels liegt auf der Security Provider Implementierung von Microsoft.

SCHANNEL - Secure Channel

Secure Channel ist das Security Support Provider Interface (SSPI) von Microsoft und wird von den unterschiedlichen Betriebssystemen bei Authentifizierungsvorgängen und bei verschlüsselter Kommunikation verwendet. Die unterstützen Verschlüsselungsalgorithmen variieren sehr stark, je nach Version des verwendeten Betriebssystems.

Cipher Suite

Eine sog. Cipher Suite beschreibt ein Sammlung von kryptografischen Algorithmen, die zur Schlüsselerstellung, Schlüsselaustausch und zur Verbindungsherstellung verwendet werden. Im Regelfall verwenden Softwarekomponenten auf Windowssystemen (Client und Server) die SCHANNEL Konfigurationen zur Verschlüsselung und Abwicklung der Kommunikation.

Jede zur Verfügung stehende Cipher Suite beschreibt eine festgelegte Kombination von

1. FIPS Mode
2. Unterstütztem Protokoll
3. Algorithmus zum Schlüsselaustausch
4. Algorithmus zur Verschlüsselung
5. Algorithmus zum Hashing der Nachrichten

Die von Windows Server 2012R2 unterstützten Cipher Suites sind:

• TLS_RSA_EXPORT_WITH_RC4_40_MD5
• TLS_RSA_EXPORT1024_WITH_RC4_56_SHA
• TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA
• SSL_CK_RC4_128_EXPORT40_MD5
• SSL_CK_DES_64_CBC_WITH_MD5
• TLS_RSA_WITH_DES_CBC_SHA
• TLS_RSA_WITH_NULL_MD5
• TLS_RSA_WITH_NULL_SHA
• TLS_DHE_DSS_EXPORT1024_WITH_DES_CBC_SHA
• TLS_DHE_DSS_WITH_DES_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA_P521
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA_P521
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P384
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256_P521
• TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384_P521
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P521
• TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384_P521
• TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P384
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P521
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P521
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P521
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384
• TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521

Diese Suites werden zwar unterstützt, stehen aber nach einer Standardinstallation des Betriebssystems nicht zur Verfügung. Hierzu muss die SCHANNEL Konfiguration per Registry angepasst werden. Mehr dazu im Abschnitt "SCHANNEL Konfiguration".

Der Aufbau einer TLS Verbindung gliedert sich in 4 Schritte:

1. Handshake und Cipher Suite Aushandlung
2. Authentifizierung der Teilnehmer
3. Schlüsselaustausch
4. Datenaustausch der Applikation

In der nachfolgenden Beschreibung entspricht der Client dem sendenden (Verbindung aufbauenden) System und der Server dem empfangenden System.

1. Handshake
   • Bei Aufbau einer Verbindung sendet ein Client eine Liste der unterstützten Cipher Suites und der Server wählt eine angebotenen Suites auf Basis seiner konfigurierten, bevorzugten Reihenfolge aus und teilt dem Client das Ergebnis mit.
   • An dieser Stelle wird auch entschieden, ob die aufzubauende Verbindung Perfect Forward Secrecy (PFS) verwendet oder nicht. Wird eine Cipher Suite mit Ephemeral Diffie-Hellman (DHE) oder eine Elliptic-Curve Variante (ECDHE) ausgewählt, steht PFS zur Verfügung.
2. Authentifizierung
   • Der Server sein öffentliches Zertifikat an den Client und fragt ggf. ein Zertifikat vom Client an.
   • Falls der Server an Zertifikat angefragt hat, sendet der Client sein Zertifikat an den Server.
3. Schlüsselaustausch
   • Der Client erstellt ein zufälliges Pre-Master Secret und verschlüsselt es mit dem öffentlichen Schlüssel des Server-Zertifikates und sendet es an den Server.
   • Der Server und der Client erstellen nun auf Basis des Pre-Master Secret das eigentliche Master Secret und die Schlüssel für die Session.
   • Der Client sendet nun eine "Change Cipher Spec" Nachricht an den Server, und teilt so mit, das die neuen Sessionschlüssel für das Hashing und die ausgewählte Verschlüsselung verwendet werden.
   • Der Server empfängt die Nachricht und wechselt auf symmetrische Verschlüsselung unter Verwendung der Sessionschlüssel.
4. Datenaustausch
   • Der sichere Kanal zwischen Client und Server ist hergestellt und Applikationsdaten können verschlüsselt übertragen werden.

Hinweis:
Bei der Konfiguration der Cipher Suites Reihenfolge sollte darauf geachtet werden, dass zwar zuerst Suites mit PFS konfiguriert werden, jedoch ein Fallback ohne PFS ebenfalls angeboten wird.

Cipher Suite Reihenfolge

Die Cipher Suite Reihenfolge legt fest, welche Suite zuerst und welche zuletzt verwendet werden soll.

In der Windows Systemregistrierung die zur Verfügungen stehenden Cipher Suites nach einer Basis Installation nicht konfiguriert. Der nachfolgende Screenshot zeigt den Registrierungsschlüssel SCHANNEL.

Einzig die zur Verfügung stehenden Protokolle (SSL/TLS) sind konfiguriert.

Die verfügbaren Cipher Suites und die eigentliche Reihenfolge der Suites werden in zwei unterschiedlichen Registrierungsschlüsseln konfiguriert.

Verfügbare Cipher Suites:
HKLM\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010002

Reihenfolge der Cipher Suites:
HKLM\SOFTWARE\Policies\Microsoft\Cryptography\Configuration\SSL\00010002

Hinweis: Der Registrierungsschlüssel für die Liste der Cipher Suites ist begrenzt auf 1023 Zeichen.

SCHANNEL Konfiguration

HINWEIS: Die direkte und eventuell fehlerhafte Anpassung der Windows Registry kann zur Instabilität des Betriebssystems führen. Die nachfolgende Beschreibung erfolgt nach bestem Wissen. Jedoch können wir keine Haftung für eventuelle Schäden übernehmen.

1. Erstellen Sie ein Backup des Systems, bevor Sie Änderungen an der Systemregistrierung durchführen
2. Erstellen Sie ein Backup des Systems, bevor Sie Änderungen an der Systemregistrierung durchführen

Die Konfiguration der Cipher Suites erfolgt im nachfolgenden Beispiel unter Verwendung des Tools IIS Crypto.

IIS Crypto ist ein Hilfsmittel, um die Konfiguration in der Windows Registry einfacher zu gestalten. Jedoch muss man bei Einsatz bedenken, dass beim Start des Programmes nicht die tatsächlich vorhandene Konfiguration der Systemregistrierung ausgelesen und angezeigt wird, sondern vielmehr die Standardkonfiguration von IIS Crypto.

IIS Crypto bietet vorkonfigurierte Konfigurationen für:

• FIPS 140-2
• PCI
• Best Practices

Nach der Anpassung der Cipher Suite Konfiguration (im nachfolgenden Beispiel die Best Practices Konfiguration), sind die neuen Schlüssel und Parameter in der Systemregistrierung vorhanden.

Je nach Typ (Protokoll oder Cipher Komponente) werden zur Aktivierung bzw. Deaktivierung folgende Schlüssel verwendet:

• Enabled, 0x0 oder 0xffffffff
• DisabledByDefault, 0 oder 1

Eine Beschreibung zur manuellen Konfiguration der Systemregistrierung finden Sie bei Microsoft hier: http://support2.microsoft.com/default.aspx?scid=kb;EN-US;245030

Fazit

Wenn eine besonderen Anforderungen an die Absicherung der Server-Kommunikation mit externen Systemen besteht, was eigentlich immer der Fall ist, muss eine zusätzlich Konfiguration des Secure Channel Providers erfolgen. Im Normallfall kann die einheitlich über Gruppenrichtlinien erfolgen. Verwenden Sie aber Systeme, die keine Mitgliedsserver einer Domäne sind, so müssen diese Systemen manuell über die Systemregistrierung oder durch Verwendung der lokalen Sicherheitsrichtlinie erfolgen.

Die Konfiguration des Secure Channel hat eine direkte Auswirkung auf die TLS Verschlüsselung aller TCP Protokolle. Durch die unterschiedlichen Implementierungen bei unterschiedlichen Betriebssystemen müssen die Anpassungen mit Bedacht durchgeführt werden.

Sollte es Gründe geben, dass Sie eine FIPS- oder PCI-konforme Konfiguration vornehmen müssen, gibt es allerdings keine Alternative zur Umsetzung der Vorgaben.

Links

• Secure Channel
• Cipher Suites in Windows Server 2008R2 und Windows Server 2012(R2)
• How to restrict the use of certain cryptographic algorithms and protocols in Schannel.dll
• Bewertung der unterschiedlichen Schlüsselaustausch Algorithmen
• IIS Crypto
• FIPS 140-4
• PCI Security Standards

Mini-Serie E-Mail Sicherheit

• E-Mail Verschlüsselung und E-Mail Sicherheit
• E-Mail Verschlüsselung - TLS, S/MIME & Co (Teil 1)
• E-Mail Verschlüsselung - TLS, S/MIME & Co (Teil 2)
• E-Mail Verschlüsselung und Cipher Suites

Fragen zur E-Mail Sicherheit

Haben Sie Fragen rund um das Thema E-Mail Verschlüsselung und E-Mail Sicherheit? Kontaktieren Sie uns unter: emailsecurity@granikos.eu.