Partager via

Considérations relatives à la désactivation et au remplacement de TLS 1.0 dans AD FS

Cet article fournit des conseils et des considérations sur la désactivation et le remplacement de TLS 1.0 dans services de fédération Active Directory (AD FS) (AD FS).

Numéro de base de connaissances d’origine : 3194197

Résumé

De nombreux clients envisagent la possibilité de désactiver le protocole TLS 1.0 et RC4 dans AD FS et de le remplacer par TLS 1.1 ou une version ultérieure. Cet article décrit les problèmes qui peuvent se produire si vous désactivez TLS 1.0 et fournit des conseils pour vous aider à terminer le processus.

Après avoir désactivé TLS 1.0 sur les serveurs de proxy AD FS ou AD FS (WAP), ces serveurs peuvent rencontrer certains des symptômes suivants :

  • La connectivité entre un proxy AD FS et un serveur AD FS échoue. Cela peut entraîner l’une des conditions suivantes :

    • La configuration du proxy échoue dans l’Assistant ou à l’aide de Windows PowerShell.

    • L’ID d’événement 422 est connecté aux proxys AD FS :

      Impossible de récupérer la configuration du proxy à partir du service de fédération.

    • Les proxys ne peuvent pas transférer le trafic vers les serveurs AD FS et le message d’erreur suivant est généré :

      Erreur HTTP 503 : le service n’est pas disponible.

  • AD FS ne peut pas mettre à jour les métadonnées de fédération des approbations de partie de confiance ou des approbations de fournisseur de revendications configurées.

  • Vous recevez un message d’erreur HTTP 503 :

    Le service n’est pas disponible. HTTP 503 accédant aux services Office 365 pour les domaines fédérés.

  • Vous recevez un message d’erreur RDP :

    Connectivité RDP perdue aux serveurs.

Cause

Ce problème se produit si les clients désactivent les anciens protocoles à l’aide de clés de Registre SChannel . Pour obtenir un exemple de cette pratique, consultez la section Désactiver les anciens protocoles dans le Registre .

Résolution

Important

Suivez attentivement les étapes décrites dans cette section. De graves problèmes peuvent se produire si vous modifiez le Registre de façon incorrecte. Avant de le modifier, sauvegardez le Registre afin de pouvoir le restaurer en cas de problème.

ADFS est développé à l’aide de Microsoft .NET Framework. Pour que les applications .NET prennent en charge le chiffrement fort (autrement dit, TLS 1.1 et versions ultérieures), vous devez d’abord installer les mises à jour décrites dans l’avis de sécurité suivant : Avis de sécurité Microsoft 2960358.

Important

Les clients qui exécutent des applications .NET Framework 3.5 sur Windows 10 ou .NET Framework 4.5/4.5.1/4.5.2 sur les systèmes sur utilisant le .NET Framework 4.6 doivent suivre les étapes fournies dans cet avis pour désactiver manuellement RC4 dans TLS. Pour plus d’informations, consultez la section Actions suggérées de l’avis.

Note

  • Les systèmes qui exécutent le .NET Framework 4.6 uniquement sont protégés par défaut et n’ont pas besoin d’être mis à jour.

  • Les étapes supplémentaires de l’avis de sécurité nécessitent la création de la clé de Registre SchUseStrongCrypto , comme décrit dans l’article de conseil.

    Exemples de sous-clés pour cette nouvelle clé de Registre :

    • [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\. NETFramework\v2.0.50727] SchUseStrongCrypto=dword :00000001
    • [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\. NETFramework\v4.0.30319] SchUseStrongCrypto=dword :00000001
    • [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\. NETFramework\v4.0.30319] SchUseStrongCrypto=dword :00000001
    • [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\. NETFramework\v2.0.50727] SchUseStrongCrypto=dword :00000001

  • Pour appliquer la modification, vous devez redémarrer les services et applications suivants :

    • Service ADFS (adfssrv)
    • Service d’inscription d’appareil (drs)
    • Toute autre application .NET qui peut s’exécuter sur le serveur
    • Le pool d’applications Iis (Internet Information Services) pour ADFS (s’applique uniquement à ADFS 2.0 et ADFS 2.1)

Important

Suivez attentivement les étapes décrites dans cette section. De graves problèmes peuvent se produire si vous modifiez le Registre de façon incorrecte. Avant de le modifier, sauvegardez le Registre afin de pouvoir le restaurer en cas de problème.

Désactiver les anciens protocoles dans le Registre

Un exemple de désactivation des anciens protocoles à l’aide de clés de Registre SChannel serait de configurer les valeurs des sous-clés de Registre dans la liste suivante. Celles-ci désactivent les protocoles SSL 3.0, TLS 1.0 et RC4. Étant donné que cette situation s’applique à SChannel, elle affecte toutes les connexions SSL/TLS vers et depuis le serveur.

reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0 » /f
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client » /f
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server » /f
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client » /v Enabled /t REG_DWORD /d 000000000
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server » /v Enabled /t REG_DWORD /d 000000000
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0 » /f
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client » /f
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server » /f
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client » /v Enabled /t REG_DWORD /d 000000000
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server » /v Enabled /t REG_DWORD /d 000000000
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128 » /f
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 40/128 » /v Enabled /t REG_DWORD /d 000000000
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128 » /f
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 56/128 » /v Enabled /t REG_DWORD /d 000000000
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128 » /f
reg add « HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers\RC4 128/128 » /v Enabled /t REG_DWORD /d 000000000

Note

Vous devez redémarrer l’ordinateur après avoir modifié ces valeurs.

Pour vérifier qu’un serveur connecté à Internet a correctement désactivé les anciens protocoles, vous pouvez utiliser n’importe quel vérificateur de test SSL en ligne tel que Qualys SSL Labs. Pour plus d’informations, consultez test du serveur SSL.

Autre solution

En guise d’alternative à l’utilisation de la clé de Registre SchUseStrongCrypto , vous pouvez utiliser la clé de Registre SystemDefaultTlsVersions lorsque vous utilisez le .NET Framework 3.5.1.

SystemDefaultTlsVersions est disponible après l’installation du 3154518 de mise à jour.

Une fois les clés de Registre définies, le service ADFS respecte les valeurs par défaut et le travail de SChannel.

Effets secondaires connus

Voici les effets secondaires.

Les applications clientes ne peuvent pas se connecter au serveur ADFS ou au proxy ADFS pour l’authentification

Lorsque vous désactivez TLS 1.0 et versions antérieures sur les serveurs ADFS et les proxys, les applications clientes qui tentent de se connecter doivent prendre en charge TLS 1.1 ou versions ultérieures.

Cela est vrai, par exemple, d’Android mobile 4.1.1 lorsque vous utilisez l’application Portail d’entreprise Intune pour inscrire cet appareil. L’application Intune ne peut pas afficher la page de connexion ADFS.

Cela est attendu dans cette version Android, car TLS 1.1 est désactivé par défaut.

Vous pouvez obtenir plus d’informations sur ces problèmes potentiels en collectant les traces réseau sur le serveur ADFS ou les proxys pendant que vous reproduisez l’échec de connexion. Dans ce scénario, vous pouvez travailler avec le fournisseur du système d’exploitation client ou le fournisseur d’applications pour vérifier que les versions tls plus récentes sont prises en charge. ADFS ne peut pas mettre à jour les métadonnées de fédération.

Scénario 1

  • ADFS ne peut pas récupérer automatiquement les Federationmetadata.xml des approbations de partie de confiance ou des approbations de fournisseur de revendications.

  • Lorsque vous essayez de mettre à jour le fichier XML manuellement, vous recevez le message d’erreur suivant :

    Une erreur s’est produite lors d’une tentative de lecture des métadonnées de fédération.

  • Vous recevez également le message d’erreur suivant lorsque vous utilisez Windows PowerShell :

    La connexion sous-jacente a été fermée. Une erreur inattendue s’est produite lors de la réception.

En analysant plus étroitement l’exception sous-jacente, nous pouvons voir les informations suivantes :

PS C :> Update-AdfsRelyingPartyTrust -TargetName « Microsoft Office 365 Identity Platform »
Update-AdfsRelyingPartyTrust : la connexion sous-jacente a été fermée : une erreur inattendue s’est produite sur une réception.
À la ligne : 1 caractère : 1
+ Update-AdfsRelyingPartyTrust -TargetName " Microsoft Office 365 Identity Platform ... + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified : (Microsoft.Ident... lyingPartyTrust :RelyingPartyTrust) [Update-AdfsRelyingP artyTrust], WebException
+ FullyQualifiedErrorId : la connexion sous-jacente a été fermée : une erreur inattendue s’est produite sur une réception.,Microso ft. IdentityServer.Management.Commands.UpdateRelyingPartyTrustCommand

PS C :> $error[0] | fl * -f
writeErrorStream : True
PSMessageDetails :
Exception : System.Net.WebException : la connexion sous-jacente a été fermée : une erreur inattendue s’est produite sur une réception. >--- System.ComponentModel.Win32Exception : le client et le serveur ne peuvent pas communiquer, car ils ne possèdent pas d’algorithme commun
at System.Net.SSPIWrapper.AcquireCredentialsHandle(SSPIInterface SecModule, String package, CredentialUse intent, SecureCredential scc)
chez System.Net.Security.SecureChannel.AcquireCredentialsHandle(CredentialUse credUsage, SecureCredential&secureCredential)
sur System.Net.Security.SecureChannel.AcquireClientCredentials(Byte[]&thumbPrint)
at System.Net.Security.SecureChannel.GenerateToken(Byte[] input, Int32 offset, Int32 count, Byte[]&output)
at System.Net.Security.SecureChannel.NextMessage(Byte[] incoming, Int32 offset, Int32 count)
at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult lazyResult)
at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)
sur System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, État de l’objet)
sur System.Net.TlsStream.ProcessAuthentication(Résultat LazyAsyncResult)
at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)
sur System.Net.ConnectStream.WriteHeaders(asynchrone booléen)
--- Fin du suivi de la pile d’exceptions interne ---
sur System.Net.HttpWebRequest.GetResponse()
sur Microsoft.IdentityServer.Management.Resources.Managers.RelyingPartyTrustManager.ApplyMeta dataFromUrl(RelyingPartyTrust party, Uri metadataUrl, String&avertissements)
à Microsoft.IdentityServer.Management.Commands.UpdateRelyingPartyTrustCommand.OperateOnRely ingPartyTrust(RelyingPartyTrust party)
sur Microsoft.IdentityServer.Management.Commands.RemoveRelyingPartyTrustCommand.ProcessRecord()
TargetObject : Microsoft.IdentityServer.Management.Resources.RelyingPartyTrust
CategoryInfo : NotSpecified : (Microsoft.Ident... lyingPartyTrust :RelyingPartyTrust)
[Update-AdfsRelyingPartyTrust], WebException
FullyQualifiedErrorId : La connexion sous-jacente a été fermée : une erreur inattendue s’est produite sur un receive.,Microsoft.IdentityServer.Management.Commands.UpdateRelyingPartyTrustCommand
ErrorDetails : la connexion sous-jacente a été fermée : une erreur inattendue s’est produite sur une réception. InvocationInfo : System.Management.Automation.InvocationInfo
ScriptStackTrace : sur <ScriptBlock>, <Aucun fichier> : ligne 1
PipelineIterationInfo : {0, 1}

Lorsque nous analysons les traces réseau, nous ne voyons aucun ClientHello. En outre, le client lui-même (ADFS) ferme la connexion (TCP FIN) quand nous nous attendons à ce qu’il envoie le ClientHello :

3794 <DateTime> 4.0967400 (4588) adfs1 nexus.microsoftonline-p.com.nsatc.net TCP 8192 TCP : [Bad CheckSum]Flags=CE.... S., SrcPort=56156, DstPort=HTTPS(443)
4013 <DateTime> 4.1983176 (0) nexus.microsoftonline-p.com.nsatc.net adfs1 TCP 2097152 TCP :Flags=... Un.. S., SrcPort=HTTPS(443), DstPort=56156
4021 <DateTime> 4.1983388 (0) adfs1 nexus.microsoftonline-p.com.nsatc.net TCP 131328 TCP : [Bad CheckSum]Flags=... A...., SrcPort=56156, DstPort=HTTPS(443)
4029 <DateTime> 4.1992083 (4588) adfs1 nexus.microsoftonline-p.com.nsatc.net TCP 131328 TCP : [Bad CheckSum]Flags=... Un... F, SrcPort=56156, DstPort=HTTPS(443)
4057 <DateTime> 4.2999711 (0) nexus.microsoftonline-p.com.nsatc.net adfs1 TCP 0 TCP :Flags=... A.R.., SrcPort=HTTPS(443), DstPort=56156

C’est pourquoi les clés de Registre SChannel ont été créées. Ces suppressions suppriment la prise en charge de SSL 3.0 ou TLS 1.0 en tant que client.

Toutefois, la clé SchUseStrongCrypto n’a pas été créée. Par conséquent, après avoir établi la session TCP/IP, le ClientHello doit être envoyé en ayant les conditions suivantes :

  • .NET à l’aide du chiffrement faible (uniquement TLS 1.0 et versions antérieures)
  • SChannel configuré pour utiliser uniquement TLS 1.1 ou versions ultérieures

Résolution : appliquez SchUseStrongCrypto et redémarrez.

HTTP 503 dans l’accès aux services Office 365

Scénario 2

  • Seules TLS 1.1 et versions ultérieures sont prises en charge dans le serviceOffice ADFS.
  • Vous disposez d’un domaine fédéré O365.
  • Le client accède à un service O365 qui utilise la proxiedauthentication : l’application cliente a envoyé les informations d’identification à l’aide de HTTP Basic et le service O365 utilise ces informations d’identification dans une nouvelle connexion à ADFS pour authentifier l’utilisateur.
  • Le service cloud envoie un protocole TLS 1.0 à ADFS et ADFS ferme la connexion.
  • Le client reçoit une réponse HTTP 503.

Par exemple, cela est vrai lorsque vous accédez à la découverte automatique. Dans ce scénario, les clients Outlook sont affectés. Cela peut être facilement reproduit en ouvrant un navigateur web et en accédant à https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.

xmlRequest envoyèrent:

GET https://autodiscover-s.outlook.com/Autodiscover/Autodiscover.xml HTTP/1.1
Hôte : autodiscover-s.outlook.com
User-Agent : Mozilla/5.0 (Windows NT 10.0 ; WOW64 ; rv :46.0) Gecko/20100101 Firefox/46.0
Accepter : text/html,application/xhtml+xml,application/xml ;q=0.9 ;/; q=0.8
Accept-Language : en-US,en ; q=0.5
Accept-Encoding : gzip, deflate, br
Connexion : maintenir la vie
Autorisation : De base (REMOVED FOR PRIVACY)

Réponse reçue du service Exchange Online :

Service HTTP/1.1 503 indisponible
Cache-Control: private
Nouvelle tentative après : 30
Serveur : Microsoft-IIS/8.0
request-id : 33c23dc6-2359-44a5-a819-03f3f8e85aae
X-CalculatedBETarget : db4pr04mb394.eurprd04.prod.outlook.com
X-AutoDiscovery-Error : LiveIdBasicAuth :FederatedStsUnreachable :<X-forwarded-for :<IP Address>><FederatedSTSFailure>System.Net.WebException : La connexion sous-jacente a été fermée : une erreur inattendue s’est produite lors d’un envoi. ;
X-DiagInfo : DB4PR04MB394
X-BEServer : DB4PR04MB394
X-AspNet-Version : 4.0.30319
Set-Cookie : X-BackEndCookie2= ; expires=<DateTime> ; path=/Autodiscover ; secure ; HttpOnly
Set-Cookie : X-BackEndCookie= ; expires=<DateTime> ; path=/Autodiscover ; secure ; HttpOnly
X-Powered-By : ASP.NET
X-FEServer : AM3PR05CA0056
Date : <DateTime>
Longueur du contenu : 0

L’analyse des traces réseau sur le serveur WAP permet de voir plusieurs connexions provenant de notre cloud, comme suit. WAP termine (TCP RST) ces connexions peu de temps après réception du client Hello.

3282 <DateTime> 10.802432 (0) 132.245.225.68 62047 (0xF25F) 10.10.1.5 443 (0x1BB) TCP 52 (0x34) 32 8192 TCP :Flags=CE.... S., SrcPort=62047, DstPort=HTTPS(443), PayloadLen=0, Seq=1681718623, Ack=0, Win=8192 ( Négociation du facteur d’échelle 0x8 ) = 8192
3285 <DateTime> 10.8025263 (0) 10.10.1.5 443 (0x1BB) 132.245.225.68 62047 (0xF25F) TCP 52 (0x34) 32 8192 TCP : [Vérification incorrecte]Flags=. E.A.. S., SrcPort=HTTPS(443), DstPort=62047, PayloadLen=0, Seq=3949992650, Ack=1681718624, Win=8192 ( facteur d’échelle négocié 0x8) = 8192
3286 <DateTime> 10.8239153 (0) 132.245.225.68 62047 (0xF25F) 10.10.1.5 443 (0x1BB) TCP 40 (0x28) 20 517 TCP :Flags=... A...., SrcPort=62047, DstPort=HTTPS(443), PayloadLen=0, Seq=1681718624, Ack=3949992651, Win=517
3293 <DateTime> 10.8244384 (0) 132.245.225.68 62047 (0xF25F) 10 .10.1.5 443 (0x1BB) TLS 156 (0x9C) 136 517 TLS :TLS Rec Layer-1 HandShake : Client Hello.
3300 <DateTime> 10.8246757 (4) 10.10.1.5 443 (0x1BB) 132.245.225.68 62047 (0xF25F) TCP 40 (0x28) 20 0 TCP : [Vérification incorrecte]Flags=... A.R., SrcPort=HTTPS(443), DstPort=62047, PayloadLen=0, Seq=3949992651, Ack=1681718740, Win=0 (facteur d’échelle 0x0) = 0

Nous voyons également que Client Hello utilise TLS 1.0 :

Frame : Number = 3293, Captured Frame Length = 271, MediaType = NetEvent
+ NetEvent :
+ MicrosoftWindowsNDISPacketCapture : Packet Fragment (170 (0xAA) octets)
+ Ethernet : Etype = IP Internet (IPv4),DestinationAddress :[00-0D-3A-24-43-98],SourceAddress :[12-34-56-78-9A-BC]
+ Ipv4 : Src = <Adresse> IP, Dest = <Adresse> IP, Protocole suivant = TCP, ID de paquet = 31775, Longueur IP totale = 156
+ Tcp : Flags=... AP..., SrcPort=62047, DstPort=HTTPS(443), PayloadLen=116, Seq=1681718624 - 1681718740, Ack=3949992651, Win=517
TLSSSLData : Données de charge utile TLS (Transport Layer Security)
- TLS : Tls Rec Layer-1 HandShake : Client Hello.
- TlsRecordLayer : Tls Rec Layer-1 HandShake :
ContentType : HandShake :
- Version : TLS 1.0
Major : 3 (0x3)
Mineur : 1 (0x1)
Longueur : 111 (0x6F)
- SSLHandshake : SSL HandShake ClientHello(0x01)
HandShakeType : ClientHello(0x01)
Longueur : 107 (0x6B)
- ClientHello : TLS 1.0
+ Version : TLS 1.0
+ Octets aléatoires :
SessionIDLength : 0 (0x0)
CipherSuitesLength : 14
+ TLSCipherSuites : TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA { 0xC0,0x14 }
+ TLSCipherSuites : TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA { 0xC0,0x13 }
+ TLSCipherSuites : TLS_RSA_WITH_AES_256_CBC_SHA { 0x00, 0x35 }
+ TLSCipherSuites : TLS_RSA_WITH_AES_128_CBC_SHA { 0x00, 0x2F }
+ TLSCipherSuites : TLS_RSA_WITH_3DES_EDE_CBC_SHA { 0x00,0x0A }
+ TLSCipherSuites : TLS_RSA_WITH_RC4_128_SHA { 0x00,0x05 }
+ TLSCipherSuites : TLS_RSA_WITH_RC4_128_MD5 { 0x00,0x04 }
CompressionMethodsLength : 1 (0x1)
CompressionMethods : 0 (0x0)
ExtensionsLength : 52 (0x34)
- ClientHelloExtension : Server Name(0x0000)
ExtensionType : Nom du serveur(0x0000)
ExtensionLength : 19 (0x13)
NameListLength : 17 (0x11)
NameType : Nom d’hôte (0)
NameLength : 14 (0xE)
Nom_serveur : sts.contoso.net
+ ClientHelloExtension : Courbes elliptiques (0x000A)
+ ClientHelloExtension : EC Point Formats(0x000B)
+ ClientHelloExtension : SessionTicket TLS(0x0023)
+ ClientHelloExtension : Type d’extension inconnu
+ ClientHelloExtension : Renegotiation Info(0xFF01)

Dans ce scénario, il est attendu que le proxy ADFS rejette la connexion. Ce problème a été signalé à l’équipe Exchange Online et est en cours d’investigation.

Solutions de contournement :

  • Utilisez l’authentification moderne.

    Note

    Cela n’a pas été testé. Toutefois, conceptuellement, la connexion à ADFS provient directement de l’application cliente. Par conséquent, il doit fonctionner s’il prend en charge TLS 1.1.

  • Réactivez le serveur TLS 1.0 dans le proxy WAP/ADFS.

References

Exclusion de responsabilité de tiers

Les produits tiers mentionnés dans le présent article sont fabriqués par des sociétés indépendantes de Microsoft. Microsoft exclut toute garantie, implicite ou autre, concernant les performances ou la fiabilité de ces produits.