Benutzer können sich nicht mit AD FS über ein externes Netzwerk anmelden.

Dieser Artikel hilft beim Beheben von Anmeldeproblemen mit Active Directory-Verbunddiensten (AD FS) aus einem externen Netzwerk. Verwenden Sie diesen Artikel, wenn Benutzer sich nicht mithilfe von AD FS von einem externen Unternehmensnetzwerk authentifizieren können.

Extranetzugriff überprüfen

Überprüfen Sie, ob Sie sich über den Webanwendungsproxy (WAP) bei den AD FS-Servern authentifizieren können.

Der IdpInitiatedSignOn Parameter kann schnell überprüfen, ob AD FS aktiv ist und ob die Authentifizierung ordnungsgemäß funktioniert.

Wenn Sie AD FS unter Windows Server 2016 ausführen, müssen Sie folgendes manuell aktivieren IdpInitiatedSignOn :

1. Melden Sie sich beim primären AD FS-Server an.
2. Öffnen Sie PowerShell.
3. Führen Sie Set-AdfsProperties -EnableIdPInitiatedSignonPage $true aus.

Führen Sie die folgenden Schritte aus, um zu überprüfen, ob AD FS IdpinitiatedSignOn verwendet:

1. Melden Sie sich beim WAP-Computer an, den Sie testen möchten.
2. Öffnen Sie eine private Browsersitzung.
3. Wechseln Sie zu https://<federation service fqdn>/adfs/ls/idpinitiatedsignon.asp. Ein Beispiel ist https://fs.contoso.com/adfs/ls/idpinitiatedsignon.aspx.
4. Geben Sie die Anmeldeinformationen eines gültigen Benutzers auf der Anmeldeseite ein.

Netzwerkeinstellungen überprüfen

Überprüfen Sie das Domain Name System (DNS) und alle Einstellungen des Lastenausgleichs.

DNS- und Netzwerküberprüfungen auf externen Zugriff

Wenn Sie ÜBER WAP-Server verfügen:

• Pingen Sie den Namen des Verbunddiensts. Vergewissern Sie sich, dass die IP-Adresse, zu der sie aufgelöst wird, zu einem der WAP-Server oder dem Load Balancer vor den WAP-Servern gehört.
• Wenn der DNS-Server den Dienstnamen extern hostt, überprüfen Sie, ob ein A-Eintrag für den Verbunddienst vorhanden ist, der auf den WAP-Server oder den Lastenausgleich vor den WAP-Servern verweist.

Lastverteiler

• Überprüfen Sie, ob die Firewall den Datenverkehr zwischen AD FS und dem Lastenausgleich und zwischen dem WAP und dem Lastenausgleich nicht blockiert.
• Überprüfen Sie, ob der Sonde aktiviert ist.
• Überprüfen Sie, ob Sie Windows Server 2012 R2 ausführen. Vergewissern Sie sich, dass das Windows Server 2012 R2 Update-Rollup (KB.2975719) vom August 2014 installiert ist.
• Überprüfen Sie, ob Port 80 in der Firewall auf den WAP- und AD FS-Servern aktiviert ist.
• Stellen Sie sicher, dass der Prüfpunkt für Port 80 und den Endpunkt /adfs/probefestgelegt ist.

Brandmauer

Sowohl die Firewall zwischen der WAP- und der Verbundserverfarm als auch die Firewall zwischen den Clients und der WAP müssen über den TCP-Port 443 eingehend aktiviert sein.

Überprüfen, ob der Endpunkt aktiviert ist

AD FS bietet verschiedene Endpunkte für verschiedene Funktionen und Szenarien. Nicht alle Endpunkte sind standardmäßig aktiviert. So überprüfen Sie, ob ein bestimmter Endpunkt aktiviert oder deaktiviert ist:

1. Melden Sie sich beim AD FS-Server an.
2. Öffnen Sie die AD FS-Verwaltung.
3. Wählen Sie im linken Bereich "Dienstendpunkte>" aus.
4. Scrollen Sie im rechten Bereich zum Endpunkt, der überprüft werden muss (in der Regel /adfs/ls und /adfs/oauth2).
5. Stellen Sie sicher, dass der Endpunkt aktiviert ist. Wenn z. B. oAuth-Anmeldungen fehlschlagen, überprüfen Sie, ob der /adfs/oauth Endpunkt als Yes unter ProxyEnabledgekennzeichnet ist.

Prüfen von WAP-Vertrauensproblemen

Wechseln Sie zu jedem WAP-Server, und führen Sie das Diagnose-PowerShell-Skript aus, das Sie aus den AD FS-Offlinetools heruntergeladen haben.

Melden Sie sich beim primären AD FS-Server an, um festzustellen, ob Probleme mit Bindungen oder vertrauenswürdigen Zertifikaten auftreten. Führen Sie das folgende Skript auf dem primären AD FS-Server aus:

param
(
  [switch]$syncproxytrustcerts = $TRUE
)
function checkhttpsyscertbindings()
{
Write-Host; Write-Host("1 Checking http.sys certificate bindings for potential issues")
$httpsslcertoutput = netsh http show sslcert
$adfsservicefqdn = (Get-AdfsProperties).HostName
$i = 1
$certbindingissuedetected = $FALSE
while($i -lt $httpsslcertoutput.count)
{
        $ipport = $FALSE
        $hostnameport = $FALSE
        if ( ( $httpsslcertoutput[$i] -match "IP:port" ) ) { $ipport = $TRUE }
        elseif ( ( $httpsslcertoutput[$i] -match "Hostname:port" ) ) { $hostnameport = $TRUE }
        # Check for IP specific certificate bindings
        if ( ( $ipport -eq $TRUE ) )
        {
            $httpsslcertoutput[$i]
            $ipbindingparsed = $httpsslcertoutput[$i].split(":")
            if ( ( $ipbindingparsed[2].trim() -ne "0.0.0.0" ) -and ( $ipbindingparsed[3].trim() -eq "443") )
            {
                $warning = "There's an IP specific binding on IP " + $ipbindingparsed[2].trim() + " which may conflict with the AD FS port 443 cert binding." | Write-Warning
                $certbindingissuedetected = $TRUE
            }
           
            $i = $i + 14
            continue
        }
        # check that CTL Store is set for ADFS service binding
        elseif ( $hostnameport -eq $TRUE )
        {
            $httpsslcertoutput[$i]
            $ipbindingparsed = $httpsslcertoutput[$i].split(":")
            if ( ( $ipbindingparsed[2].trim() -eq $adfsservicefqdn ) -and ( $ipbindingparsed[3].trim() -eq "443") -and ( $httpsslcertoutput[$i+10].split(":")[1].trim() -ne "AdfsTrustedDevices" ) )
            {
                Write-Warning "ADFS Service binding doesn't have CTL Store Name set to AdfsTrustedDevices"
                $certbindingissuedetected = $TRUE
            }
        $i = $i + 14
        continue
        }
    $i++
}
if ( $certbindingissuedetected -eq $FALSE ) { Write-Host "Check Passed: No certificate binding issues detected" }
}

function checkadfstrusteddevicesstore()
{
# Check for CA-issued (non-self-signed) certificates in the AdfsTrustedDevices certificate store
Write-Host; Write-Host "2 Checking AdfsTrustedDevices cert store for nonself signed certificates"
$certlist = Get-Childitem cert:\LocalMachine\AdfsTrustedDevices -recurse | Where-Object {$_.Issuer -ne $_.Subject}
if ( $certlist.count -gt 0 )
{
    Write-Warning "The following nonself signed certificates are present in the AdfsTrustedDevices store and should be removed"
    $certlist | Format-List Subject
}
else { Write-Host "Check Passed: No nonself signed certs present in AdfsTrustedDevices cert store" }
}

function checkproxytrustcerts
{
    param ([bool]$repair=$FALSE)
    Write-Host; Write-Host("3 Checking AdfsTrustedDevices cert store is in sync with ADFS Proxy Trust config")
    $doc = new-object Xml
    $doc.Load("$env:windir\ADFS\Microsoft.IdentityServer.Servicehost.exe.config")
    $connString = $doc.configuration.'microsoft.identityServer.service'.policystore.connectionString
    $command = "Select ServiceSettingsData from [IdentityServerPolicy].[ServiceSettings]"
    $cli = new-object System.Data.SqlClient.SqlConnection
    $cli.ConnectionString = $connString
    $cmd = new-object System.Data.SqlClient.SqlCommand
    $cmd.CommandText = $command
    $cmd.Connection = $cli
    $cli.Open()
    $configString = $cmd.ExecuteScalar()
    $configXml = new-object XML
    $configXml.LoadXml($configString)
    $rawCerts = $configXml.ServiceSettingsData.SecurityTokenService.ProxyTrustConfiguration._subjectNameIndex.KeyValueOfstringArrayOfX509Certificate29zVOn6VQ.Value.X509Certificate2
    #$ctl = dir cert:\LocalMachine\ADFSTrustedDevices
    $store = new-object System.Security.Cryptography.X509Certificates.X509Store("ADFSTrustedDevices","LocalMachine")
    $store.open("MaxAllowed")
    $atLeastOneMismatch = $FALSE
    $badCerts = @()
    foreach($rawCert in $rawCerts)
    {   
        $rawCertBytes = [System.Convert]::FromBase64String($rawCert.RawData.'#text')
        $cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(,$rawCertBytes)
        $now = Get-Date
        if ( ($cert.NotBefore -lt $now) -and ($cert.NotAfter -gt $now))
        {
            $certThumbprint = $cert.Thumbprint
         $certSubject = $cert.Subject
         $ctlMatch = dir cert:\localmachine\ADFSTrustedDevices\$certThumbprint -ErrorAction SilentlyContinue
         if ($ctlMatch -eq $null)
         {
       $atLeastOneMismatch = $TRUE
          Write-Warning "This cert isn't in the CTL: $certThumbprint – $certSubject"
   
       if ($repair -eq $TRUE)
       {
        write-Warning "Attempting to repair"
        $store.Add($cert)
        Write-Warning "Repair successful"
       }
                else
                {
                    Write-Warning ("Please install KB.2964735 or re-run script with -syncproxytrustcerts switch to add missing Proxy Trust certs to AdfsTrustedDevices cert store")
                }
   
         }
        }
    }
    $store.Close()
 
    if ($atLeastOneMismatch -eq $FALSE)
    {
     Write-Host("Check Passed: No mismatched certs found. CTL is in sync with DB content")
    }
}
checkhttpsyscertbindings
checkadfstrusteddevicesstore
checkproxytrustcerts($syncproxytrustcerts)
Write-Host; Write-Host("All checks completed.")

Durchführen einer detaillierten WAP-Prüfung

Die Proxyvertrauensbeziehung zwischen einem WAP-Server und dem AD FS 2012 R2-Server basiert auf Clientzertifikaten. Wenn Sie den WAP-Assistenten nach der Installation ausführen, wird mithilfe der im Assistenten angegebenen Anmeldeinformationen ein selbstsigniertes Clientzertifikat generiert und in den AD FS-Konfigurationsspeicher eingefügt. AD FS verteilt dieses Zertifikat auch an den AdfsTrustedDevices Zertifikatspeicher auf dem AD FS-Server.

Bei jeder Transport Layer Security/Secure Sockets Layer (TLS/SSL)-Kommunikation HTTP.sys wird die folgende Prioritätsreihenfolge für ihre TLS/SSL-Bindungen verwendet:

• IP-Portbindung: Genaue IP- und Port-Übereinstimmung.
• SNI: Genaue Hostnamen-Übereinstimmung.
• CCS: Aufrufen des zentralen Zertifikatspeichers.
• IPV6-Platzhalter: Die Übereinstimmungsverbindung für den IPv6-Platzhalter muss IPv6 sein.
• IP-Platzhalterübereinstimmung: Die Verbindung kann IPv4 oder IPv6 sein.

Gibt es eine bestimmte IPAddress:Port-Zuordnung?

Das IP:Port mapping hat die höchste Priorität. Wenn eine IP:Port Bindung vorhanden ist, ist dies das Zertifikat, das von HTTP.sys allen Zeiten für die TLS/SSL-Kommunikation verwendet wird.

Entfernen der spezifischen IP:Port-Bindung

Überprüfen Sie, ob die Bindung nicht wiederkehrt. Wenn eine Anwendung mit einer solchen Bindung konfiguriert ist, wird dieses Problem möglicherweise automatisch oder beim nächsten Dienststart erneut erstellt.

Verwenden einer hinzugefügten IP-Adresse für AD FS-Datenverkehr

Wenn die IP:Port Bindung erwartet und erforderlich ist, würde die Verwendung einer zweiten IP wie 1.2.3.5 für den AD FS-Dienst und das Auflösen des AD FS-Dienst-FQDN zu dieser IP-Adresse bedeuten, dass die Hostname:port Bindungen verwendet werden.

Konfigurieren des AdfsTrustedDevices-Speichers als CTL-Speicher für die spezifische IP:Port-Bindung

Dieser Schritt hat einige Abhängigkeiten davon, warum die spezifische IP:port Bindung vorhanden ist und wenn dieser Schritt auf dem Standardmäßigen Zertifikatvertrauenslistenspeicher (Certificate Trust List, CTL) für die Clientzertifikatauthentifizierung basiert. Eine Option besteht darin, den CTL-Speicher für die IP:port Bindung als AdfsTrustedDevices Speicher festzulegen.

So überprüfen Sie aktuelle TLS/SSL-Zertifikatbindungen:

1. Melden Sie sich beim AD FS-Server an.
2. Öffnen Sie PowerShell.
3. Führen Sie netsh http show sslcert aus. Siehe C:\Users\administrator.CONTOSO> netsh http show sslcert.

 SSL Certificate bindings:


 Hostname:port: adfs.contoso.com:443

 Certificate Hash: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

 Application ID: {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}

 Certificate Store Name: MY

 Verify Client Certificate Revocation: Enabled

 Verify Revocation Using Cached Client Certificate Only: Disabled

 Usage Check: Enabled

 Revocation Freshness Time: 0

 URL Retrieval Timeout: 0

 Ctl Identifier: (null)

 Ctl Store Name: AdfsTrustedDevices

 DS Mapper Usage: Disabled

 Negotiate Client Certificate: Disabled

Ist der CTL-Speichername „AdfsTrustedDevices”?

Wenn der Benutzer Microsoft Entra Connect Sync installiert hat, verwenden Sie den Microsoft Entra Connect-Synchronisierungsserver, um die TLS/SSL-Zertifikatbindungen auf allen Servern zu aktualisieren. Wenn sich kein Microsoft Entra Connect-Synchronisierungsserver in der Umgebung befindet, verwenden Sie das folgende PowerShell-Cmdlet, um die AD FS-Zertifikatbindungen auf dem AD FS-Server neu zu generieren:

Set-AdfsSslCertificate -Thumbprint <thumbprint>

Ist ein von der Zertifizierungsstelle ausgestelltes Zertifikat im AdfsTrustedDevices-Speicher vorhanden?

Der AdfsTrustedDevices Speicher sollte nur das MS-Organization-Access-Zertifikat enthalten, bei dem es sich um das selbstsignierte Zertifikat handelt, das für die Ausstellung von Workplace Join-Zertifikaten verwendet wird, und die Proxyvertrauenszertifikate für jeden WAP-Server. Ein von einer Zertifizierungsstelle ausgestelltes Zertifikat in einem Speicher, in dem normalerweise nur selbstsignierte Zertifikate vorhanden sind, wirkt sich auf die aus diesem Speicher generierte CTL aus. Die CTL enthält dann nur das von der Zertifizierungsstelle ausgestellte Zertifikat.

Löschen Sie das nicht selbstsignierte TLS/SSL-Serverzertifikat aus dem AdfsTrustedDevices Speicher.

Gibt es eine Zeitverschiefe zwischen den AD FS- und WAP-Servern?

Stellen Sie sicher, dass es zwischen den AD FS- und WAP-Servern keine Zeitabweichung gibt.

Gibt es eine TLS/SSL-Beendigung zwischen den AD FS- und WAP-Servern?

Wenn tls/SSL-Beendigung auf einem Netzwerkgerät zwischen AD FS-Servern und WAP erfolgt, wird die Kommunikation zwischen AD FS und WAP unterbrochen, da die WAP- und AD FS-Kommunikation auf Clientzertifikaten basiert.

Deaktivieren Sie die TLS/SSL-Beendigung auf dem Netzwerkgerät zwischen den AD FS- und WAP-Servern.

Manuelles Synchronisieren von Proxyvertrauenszertifikaten aus der Konfiguration mit AdfsTrustedDevices

Verwenden Sie das Skript am Ende des Abschnitts, um die WAP-Zertifikate manuell aus der AD FS-Konfiguration mit dem AdfsTrustedDevices Speicher zu synchronisieren.

Verwandte Inhalte

• AD FS-Problembehandlung
• AD FS-Offlinetools