No se puede convertir el comando Convert SPWebApplication de notificaciones de Windows para SAML 2013 de SharePoint Server

IMPORTANTE: Este artículo ha sido traducido por un software de traducción automática de Microsoft (http://support.microsoft.com/gp/mtdetails) en lugar de un traductor humano. Microsoft le ofrece artículos traducidos por un traductor humano y artículos traducidos automáticamente para que tenga acceso en su propio idioma a todos los artículos de nuestra base de conocimientos (Knowledge Base). Sin embargo, los artículos traducidos automáticamente pueden contener errores en el vocabulario, la sintaxis o la gramática, como los que un extranjero podría cometer al hablar el idioma. Microsoft no se hace responsable de cualquier imprecisión, error o daño ocasionado por una mala traducción del contenido o como consecuencia de su utilización por nuestros clientes. Microsoft suele actualizar el software de traducción frecuentemente.

Haga clic aquí para ver el artículo original (en inglés): 3042604
Síntomas
Considere el siguiente escenario:
  • Utilice la autenticación de notificaciones de Windows (mediante desafío/respuesta de Windows [NTLM] o Kerberos) en una aplicación web de Microsoft SharePoint Server 2013.
  • Decide cambiar a los créditos de proveedor de confianza mediante un proveedor basado en Secure aplicación de lenguaje de marcado SAML como servicios de federación de Active Directory (AD FS).
  • Revise los pasos de la Migración de Windows solicitudes de autenticación a autenticación de notificaciones basadas en SAML 2013 de SharePoint Server tema en el sitio Web de Microsoft Developer Network (MSDN).
  • Ejecute el siguiente comando:

    Convertir SPWebApplication-id $wa-a reclamaciones de confianza-predeterminado-$tp de reclamaciones-WINDOWS - TrustedProvider - SourceSkipList $csv - RetainPermissions

En este escenario, recibirá el siguiente mensaje de error:

Autenticación de SAML según demanda no es compatible.

Causa
Este problema se produce porque el emisor de tokens identidad de confianza no se creó utilizando la configuración predeterminada. Debe utilizarse la configuración predeterminada para el comando Convert SPWebApplication funcione correctamente.

El comando Convert SPWebApplication requiere una configuración específica para que el proveedor de confianza para sea compatible con la conversión de notificaciones de Windows a SAML o viceversa.

En concreto, el emisor de tokens identidad de confianza debe crearse mediante los parámetros UseDefaultConfiguration y IdentifierClaimIs .

Puede comprobar si el emisor de tokens identidad de confianza se ha creado mediante el parámetro UseDefaultConfiguration al ejecutar las siguientes secuencias de comandos de Windows PowerShell.

Nota: Estas secuencias de comandos se suponen que tiene sólo uno que proveedor de identidad de confianza creada dentro del conjunto de servidores actual.

$tp = Get-SPTrustedIdentityTokenIssuer$tp.claimtypes 

El que esta secuencia de comandos debe dar como resultado los tipos de notificación son los siguientes:
  • http://schemas.Microsoft.com/ws/2008/06/Identity/Claims/windowsaccountname
  • http://schemas.Microsoft.com/ws/2008/06/Identity/Claims/primarysid
  • http://schemas.Microsoft.com/ws/2008/06/Identity/Claims/SIDDeGrupo
  • http://schemas.xmlsoap.org/ws/2005/05/Identity/Claims/emailaddress
  • http://schemas.xmlsoap.org/ws/2005/05/Identity/Claims/upn


#Get the Identity claim:$tp = Get-SPTrustedIdentityTokenIssuer$tp.IdentityClaimTypeInformation 



La notificación de identidad debe ser uno de los siguientes:
  • WindowAccountName
  • EmailAddress
  • UPN

Resultado de ejemplo de $TP IdentityClaimTypeInformation:
DisplayName: correo electrónico
InputClaimType: http://schemas.xmlsoap.org/ws/2005/05/Identity/Claims/EmailAddress
MappedClaimType: http://schemas.xmlsoap.org/ws/2005/05/Identity/Claims/EmailAddress#IsIdentityClaim : True


Debe haber un proveedor de notificaciones personalizadas con el mismo nombre como el emisor de tokens y debe ser de tipo SPTrustedBackedByActiveDirectoryClaimProvider.
Ejecute esto para ver si el proveedor de notificaciones está presente y compatibles:

 $tp = Get-SPTrustedIdentityTokenIssuer$name = $tp.name$cp = Get-SPClaimProvider $nameif($cp.typename -match "SPTrustedBackedByActiveDirectoryClaimProvider"){write-host "Claim provider is present and has TypeName of " $cp.typename " it should be valid"}else{write-host "Claim provider is not present. Trusted Identity Token Issuer" $tp.name " is not compatible with convert-spwebapplication"}

Solución
Para resolver este problema, elimine y vuelva a crear al emisor de tokens identidad de confianza. Para ello, siga estos pasos:
  1. Ejecute el siguiente script:

    $tp = Get-SPTrustedIdentityTokenIssuer$tp | fl$tp.name$tp.IdentityClaimTypeInformation

    Haga una copia del resultado de esta secuencia de comandos en el futuro. En particular, necesitamos el valor para la propiedad Name para que el emisor de tokens nuevos pueden crearse con el mismo nombre, y tenemos la identidad de notificación para que el nuevo proveedor de notificaciones puede crearse usando la misma notificación de identidad. Mientras se utiliza el mismo nombre del emisor de token y la misma afirmación se utiliza como la notificación de identidad, todos los usuarios mantendrán sus permisos dentro de la aplicación web después de que el emisor de tokens se vuelve a crear.

  2. Quitar el proveedor de identidad de confianza actual de proveedores de autenticación de cualquier aplicación web que se está utilizando actualmente.
  3. Eliminar al emisor de tokens ejecutando el comando siguiente:

    Remove-SPTrustedIdentityTokenIssuer -Identity "TheNameOfYourTokenIssuer"

  4. Vuelva a crear al emisor de tokens. Para ello, siga los pasos descritos en el Implementar la autenticación basada en SAML en SharePoint Server 2013 tema en el sitio Web de Microsoft TechNet para obtener más información.

    Importante: Al ejecutar el Nueva SPTrustedIdentityTokenIssuer de comandos, debe utilizar el UseDefaultConfiguration y IdentifierClaimIs parámetros. La UseDefaultConfiguration parámetro es simplemente un interruptor. Posibles valores de la IdentifierClaimIs parámetro son los siguientes:
    • NOMBRE DE LA CUENTA
    • CORREO ELECTRÓNICO
    • NOMBRE PRINCIPAL DE USUARIO


    Secuencia de comandos de ejemplo:

    $ap = New-SPTrustedIdentityTokenIssuer -Name $tokenIdentityProviderName -Description $TrustedIdentityTokenIssuerDescription -realm $siteRealm -ImportTrustCertificate $adfsCert-SignInUrl $signInUrl -UseDefaultConfiguration -IdentifierClaimIs EMAIL -RegisteredIssuerName $siteRealm
  5. En Administración Central, su nueva confianza identidad del emisor de tokens volver a agregar los proveedores de autenticación de la aplicación web que está intentando convertir. La aplicación web debe tener ambos La autenticación de Windows y el destino seleccionado el proveedor de identidad de confianza.
Más información
Additionaltips para una conversión correcta:

Si se utiliza el valor del correo electrónico para la notificación de identificador (es decir, para el parámetroIdentifierClaimIs), se convertirán a sólo aquellos usuarios cuyas direcciones de correo electrónico se rellenan en Active Directory.

Las cuentas de usuario que se enumeran en el archivo .csv que se define en el parámetro SourceSkipList no se convertirán a SAML. Conversión de notificaciones de Windows para SAML, se pueden enumerar los nombres de cuenta de usuario con o sin la notación de reclamaciones. Por ejemplo, cualquier "contoso\usuario1" o "i:0 #. w|contoso\user1" es aceptable. Debe agregar al archivo .csv las cuentas de usuario que desea convertir. Éstas deberían incluir las cuentas de servicio y las cuentas de administrador.

Advertencia: este artículo se tradujo automáticamente

Propiedades

Id. de artículo: 3042604 - Última revisión: 12/01/2015 23:51:00 - Revisión: 2.0

Microsoft SharePoint Foundation 2013, Microsoft SharePoint Server 2013

  • kbexpertiseinter kbprb kbsurveynew kbmt KB3042604 KbMtes
Comentarios