Solución de problemas de conectividad de Kerberos con PolyBase

Se aplica a: SQL Server (solo Windows) Azure SQL Database Azure Synapse Analytics Analytics Platform System (PDW)

Puede usar el diagnóstico interactivo integrado en PolyBase para ayudar a solucionar problemas de autenticación cuando se usa PolyBase en un clúster de Hadoop protegido con Kerberos.

Este artículo sirve como guía para describir el proceso de depuración de ese tipo de problemas mediante este diagnóstico integrado.

Requisitos previos

1. SQL Server 2016 (13.x) RTM CU6 / SQL Server 2016 (13.x) SP1 CU3 / SQL Server 2017 (14.x) o superior con PolyBase instalado
2. Un clúster de Hadoop (Cloudera o Hortonworks) protegido con Kerberos (Active Directory o MIT)

Introducción

Ayuda a comprender el protocolo Kerberos por encima. Aquí participan tres actores:

1. Cliente Kerberos (SQL Server)
2. Recursos protegidos (HDFS, MR2, YARN, historial de trabajos, etc.)
3. Centro de distribución de claves (que en Active Directory se denomina controlador de dominio)

Cada uno de los recursos protegidos de Hadoop se registra en el Centro de distribución de claves (KDC) con un Nombre de entidad de seguridad de servicio (SPN) único cuando Kerberos se configura en el clúster de Hadoop. El objetivo es que el cliente obtenga un vale de usuario temporal, llamado Vale de concesión de vales (TGT), para solicitar otro vale temporal, llamado Vale de servicio (ST), desde el Centro de distribución de claves contra el nombre de entidad de seguridad de servicio que desea acceder.

En PolyBase, cuando se solicita autenticación con respecto a cualquier recurso protegido con Kerberos, se produce el siguiente protocolo de enlace de cuatro recorridos de ida y vuelta:

1. SQL Server se conecta con el Centro de distribución de claves y obtiene un TGT para el usuario. El TGT se cifra con la clave privada del Centro de distribución de claves.
2. SQL Server llama al recurso protegido de Hadoop, HDFS, y determina para qué nombre de entidad de seguridad de servicio necesita un ST.
3. SQL Server vuelve al Centro de distribución de claves, vuelve a pasar el TGT y solicita un ST para acceder a ese recurso protegido concreto. El ST se cifra con la clave privada del servicio protegido.
4. SQL Server desvía el ST a Hadoop y se autentica para que se cree una sesión contra ese servicio.

Los problemas con la autenticación pertenecen a uno o más de los cuatro pasos mencionados. Para facilitar una depuración más rápida, PolyBase introdujo una herramienta de diagnóstico integrada para permitir la identificación del punto de error.

Solución de problemas

PolyBase tiene los siguientes archivos XML de configuración que contienen las propiedades del clúster de Hadoop:

• core-site.xml
• hdfs-site.xml
• hive-site.xml
• jaas.conf
• mapred-site.xml
• yarn-site.xml

Estos archivos se encuentran en:

\[System Drive\]:{install path}\{MSSQL##.INSTANCENAME}\MSSQL\Binn\PolyBase\Hadoop\conf

Por ejemplo, el valor predeterminado para SQL Server 2016 (13.x) es C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Binn\PolyBase\Hadoop\conf.

Actualice core-site.xml y agregue las tres propiedades siguientes. Establezca los valores según el entorno:

<property>
    <name>polybase.kerberos.realm</name>
    <value>CONTOSO.COM</value>
</property>
<property>
    <name>polybase.kerberos.kdchost</name>
    <value>kerberos.contoso.com</value>
</property>
<property>
    <name>hadoop.security.authentication</name>
    <value>KERBEROS</value>
</property>

Los otros XML también se deberán actualizar más adelante si se desean operaciones de inserción pero, con solo este archivo configurado, al menos se debería poder acceder al sistema de archivos HDFS.

La herramienta se ejecuta de forma independiente de SQL Server, por lo que no es necesario que esté en ejecución ni tampoco es necesario reiniciarlo si se hacen actualizaciones en los archivos XML de configuración. Para ejecutar la herramienta, ejecute los comandos siguientes en el host con SQL Server instalado:

> cd C:\Program Files\Microsoft SQL Server\MSSQL13.MSSQLSERVER\MSSQL\Binn\PolyBase  
> java -classpath ".\Hadoop\conf;.\Hadoop\*;.\Hadoop\HDP2_2\*" com.microsoft.polybase.client.HdfsBridge {Name Node Address} {Name Node Port} {Service Principal} {Filepath containing Service Principal's Password} {Remote HDFS file path (optional)}

set PATH=%PATH%;C:\Program Files\Microsoft SQL Server\MSSQL15.{instance name}\AZUL-OpenJDK-JRE\bin

Argumentos

Ejemplo

java -classpath ".\Hadoop\conf;.\Hadoop\*;.\Hadoop\HDP2_2\*" com.microsoft.polybase.client.HdfsBridge 10.193.27.232 8020 admin_user C:\temp\kerberos_pass.txt

El resultado es detallado para una mejor depuración, pero hay solo cuatro puntos de comprobación que observar, independientemente de si usa MIT o AD. Corresponden a los cuatro pasos descritos anteriormente.

Los extractos siguientes provienen de un Centro de distribución de claves de MIT. Puede hacer referencia a salidas de ejemplo completas de MIT y AD en las referencias que aparecen al final de este artículo.

Punto de comprobación 1

Debe haber un volcado hexadecimal de un vale con Server Principal = krbtgt/MYREALM.COM@MYREALM.COM. Indica que SQL Server se ha autenticado correctamente en el Centro de distribución de claves y ha recibido un TGT. Si no es así, el problema se encuentra estrictamente entre SQL Server y el Centro de distribución de claves, no en Hadoop.

PolyBase no admite relaciones de confianza entre AD y MIT y se debe configurar respecto del mismo Centro de distribución de claves que se configuró en el clúster de Hadoop. En dichos entornos, funcionará la creación manual de una cuenta de servicio en ese Centro de distribución de claves y su uso para realizar la autenticación.

|>>> KrbAsReq creating message 
 >>> KrbKdcReq send: kdc=kerberos.contoso.com UDP:88, timeout=30000, number of retries =3, #bytes=143 
 >>> KDCCommunication: kdc=kerberos.contoso.com UDP:88, timeout=30000,Attempt =1, #bytes=143 
 >>> KrbKdcReq send: #bytes read=646 
 >>> KdcAccessibility: remove kerberos.contoso.com 
 >>> EType: sun.security.krb5.internal.crypto.Des3CbcHmacSha1KdEType 
 >>> KrbAsRep cons in KrbAsReq.getReply myuser 
 [2017-04-25 21:34:33,548] INFO 687[main] - com.microsoft.polybase.client.KerberosSecureLogin.secureLogin(KerberosSecureLogin.java:97) - Subject: 
 Principal: admin_user@CONTOSO.COM 
 Private Credential: Ticket (hex) = 
 0000: 61 82 01 48 30 82 01 44 A0 03 02 01 05 A1 0E 1B a..H0..D........ 
 0010: 0C 41 50 53 48 44 50 4D 53 2E 43 4F 4D A2 21 30 .CONTOSO.COM.!0 
 0020: 1F A0 03 02 01 02 A1 18 30 16 1B 06 6B 72 62 74 ........0...krbt 
 0030: 67 74 1B 0C 41 50 53 48 44 50 4D 53 2E 43 4F 4D gt..CONTOSO.COM 
 0040: A3 82 01 08 30 82 01 04 A0 03 02 01 10 A1 03 02 ....0........... 
 *[...Condensed...]* 
 0140: 67 6D F6 41 6C EB E0 C3 3A B2 BD B1 gm.Al...:... 
 Client Principal = admin_user@CONTOSO.COM 
 Server Principal = krbtgt/CONTOSO.COM@CONTOSO.COM 
 *[...Condensed...]* 
 [2017-04-25 21:34:34,500] INFO 1639[main] - com.microsoft.polybase.client.HdfsBridge.main(HdfsBridge.java:1579) - Successfully authenticated against KDC server. 

Punto de comprobación 2

PolyBase intentará acceder a HDFS, pero no podrá hacerlo porque la solicitud no contenía el vale de servicio necesario.

 [2017-04-25 21:34:34,501] INFO 1640[main] - com.microsoft.polybase.client.HdfsBridge.main(HdfsBridge.java:1584) - Attempting to access external filesystem at URI: hdfs://10.193.27.232:8020 
 Found ticket for admin_user@CONTOSO.COM to go to krbtgt/CONTOSO.COM@CONTOSO.COM expiring on Wed Apr 26 21:34:33 UTC 2017 
 Entered Krb5Context.initSecContext with state=STATE_NEW 
 Found ticket for admin_user@CONTOSO.COM to go to krbtgt/CONTOSO.COM@CONTOSO.COM expiring on Wed Apr 26 21:34:33 UTC 2017 
 Service ticket not found in the subject 

Punto de comprobación 3

Un segundo volcado hexadecimal indica que SQL Server usó correctamente el TGT y adquirió el vale de servicio aplicable para el SPN del nodo de nombre del Centro de distribución de claves.

 >>> KrbKdcReq send: kdc=kerberos.contoso.com UDP:88, timeout=30000, number of retries =3, #bytes=664 
 >>> KDCCommunication: kdc=kerberos.contoso.com UDP:88, timeout=30000,Attempt =1, #bytes=664 
 >>> KrbKdcReq send: #bytes read=669 
 >>> KdcAccessibility: remove kerberos.contoso.com 
 >>> EType: sun.security.krb5.internal.crypto.Des3CbcHmacSha1KdEType 
 >>> KrbApReq: APOptions are 00100000 00000000 00000000 00000000 
 >>> EType: sun.security.krb5.internal.crypto.Des3CbcHmacSha1KdEType 
 Krb5Context setting mySeqNumber to: 1033039363 
 Created InitSecContextToken: 
 0000: 01 00 6E 82 02 4B 30 82 02 47 A0 03 02 01 05 A1 ..n..K0..G...... 
 0010: 03 02 01 0E A2 07 03 05 00 20 00 00 00 A3 82 01 ......... ...... 
 0020: 63 61 82 01 5F 30 82 01 5B A0 03 02 01 05 A1 0E ca.._0..[....... 
 0030: 1B 0C 41 50 53 48 44 50 4D 53 2E 43 4F 4D A2 26 ..CONTOSO.COM.& 
 0040: 30 24 A0 03 02 01 00 A1 1D 30 1B 1B 02 6E 6E 1B 0$.......0...nn. 
 0050: 15 73 68 61 73 74 61 2D 68 64 70 32 35 2D 30 30 .hadoop-hdp25-00 
 0060: 2E 6C 6F 63 61 6C A3 82 01 1A 30 82 01 16 A0 03 .local....0..... 
 0070: 02 01 10 A1 03 02 01 01 A2 82 01 08 04 82 01 04 ................ 
 *[...Condensed...]* 
 0240: 03 E3 68 72 C4 D2 8D C2 8A 63 52 1F AE 26 B6 88 ..hr.....cR..&.. 
 0250: C4 . 

Punto de comprobación 4

Por último, las propiedades de la ruta de acceso de destino se deberían imprimir junto con un mensaje de confirmación. Las propiedades del archivo confirman que Hadoop ha autenticado SQL Server mediante el ST y que se ha concedido una sesión para acceder al recurso protegido.

Si llega a este punto, se confirma que: (i) los tres actores se pueden comunicar correctamente, (ii) los archivos core-site.xml y jaas.conf son correctos y (iii) el Centro de distribución de claves reconoció sus credenciales.

 [2017-04-25 21:34:35,096] INFO 2235[main] - com.microsoft.polybase.client.HdfsBridge.main(HdfsBridge.java:1586) - File properties for "/": FileStatus{path=hdfs://10.193.27.232:8020/; isDirectory=true; modification_time=1492028259862; access_time=0; owner=hdfs; group=hdfs; permission=rwxr-xr-x; isSymlink=false} 
 [2017-04-25 21:34:35,098] INFO 2237[main] - com.microsoft.polybase.client.HdfsBridge.main(HdfsBridge.java:1587) - Successfully accessed the external file system. 

Errores comunes

Si se ejecutó la herramienta y no se imprimieron las propiedades de archivo de la ruta de acceso de destino (punto de comprobación 4), debería haber una excepción a medio camino. Revísela y considere el contexto en que se produjo dentro del flujo de cuatro pasos. Considere los siguientes problemas comunes que pueden haberse producido, en orden:

Sugerencias de depuración

KDC de MIT

Puede ver todos los nombres de entidad de seguridad de servicio registrados con el KDC, incluidos los administradores, si ejecuta kadmin.local> (inicio de sesión de administrador) >listprincs en el host de KDC o en cualquier cliente de KDC configurado. Si Kerberos está configurado correctamente en el clúster de Hadoop, debe haber un SPN para cada uno de los servicios disponibles en el clúster (por ejemplo: nn, dn, rm, yarn, spnego, etc.). Sus archivos keytab correspondientes (los sustitutos de contraseña) se pueden ver en /etc/security/keytabs, de manera predeterminada. Se cifran con la clave privada del Centro de distribución de claves.

Considere también la posibilidad de usar kinit para comprobar las credenciales de administrador en el Centro de distribución de claves localmente. Un ejemplo de uso sería: kinit identity@MYREALM.COM. Un mensaje para una contraseña indica que la identidad existe.
De manera predeterminada, los registros de KDC están disponibles en /var/log/krb5kdc.log, lo que incluye todas las solicitudes de vales, incluida la dirección IP del cliente que hizo la solicitud. Debe haber dos solicitudes desde la dirección IP de la máquina SQL Server en que se ejecutó la herramienta: en primer lugar, para el TGT del servidor de autenticación como AS_REQ, seguido de TGS_REQ para el vale de servicio desde el servidor de concesión de vales.

 [root@MY-KDC log]# tail -2 /var/log/krb5kdc.log 
 May 09 09:48:26 MY-KDC.local krb5kdc[2547](info): **AS_REQ** (3 etypes {17 16 23}) 10.107.0.245: ISSUE: authtime 1494348506, etypes {rep=16 tkt=16 ses=16}, admin_user@CONTOSO.COM for **krbtgt/CONTOSO.COM@CONTOSO.COM** 
 May 09 09:48:29 MY-KDC.local krb5kdc[2547](info): **TGS_REQ** (3 etypes {17 16 23}) 10.107.0.245: ISSUE: authtime 1494348506, etypes {rep=16 tkt=16 ses=16}, admin_user@CONTOSO.COM for **nn/hadoop-hdp25-00.local@CONTOSO.COM** 

Active Directory

En Active Directory, puede ver los nombres de entidad de seguridad de servicio si va a Panel de control > Usuarios y equipos de Active Directory >Mi_dominio_kerberos>Mi_unidad_organizativa. Si Kerberos está bien configurado en el clúster de Hadoop, hay un SPN para cada uno de los servicios disponibles (por ejemplo: nn, dn, rm, yarn, spnego, etc.)

Sugerencias generales de depuración

Resulta útil tener cierta experiencia en Java para revisar los registros y depurar los problemas de Kerberos, que son independientes de la característica PolyBase de SQL Server.

Si sigue teniendo problemas para acceder a Kerberos, siga los pasos que hay a continuación para depurar:

1. Asegúrese de que puede acceder a los datos de HDFS de Kerberos desde fuera de SQL Server. Puede:

   • Escribir su propio programa de Java, o

   • Usar la clase HdfsBridge desde la carpeta de instalación de PolyBase. Por ejemplo:

     -classpath ".\Hadoop\conf;.\Hadoop\*;.\Hadoop\HDP2_2\*" com.microsoft.polybase.client.HdfsBridge 10.193.27.232 8020 admin_user C:\temp\kerberos_pass.txt
     

   En el ejemplo anterior, admin_user solo incluye el nombre de usuario, ningún elemento del dominio.

2. Si no puede acceder a datos de HDFS de Kerberos desde fuera de PolyBase:

   • Hay dos tipos de autenticación Kerberos: autenticación Kerberos de Active Directory y autenticación Kerberos de MIT.
   • Asegúrese de que el usuario existe en la cuenta de dominio y use la misma cuenta de usuario al intentar acceder a HDFS.

3. En el caso de Kerberos de Active Directory, asegúrese de que puede ver el vale en caché con el comando klist en Windows.

   • Inicie sesión en el equipo de PolyBase y ejecute klist y klist tgt en el símbolo del sistema para ver si el KDC, el nombre de usuario y los tipos de cifrado son correctos.

4. Si el Centro de distribución de claves solo puede admitir AES256, asegúrese de que los archivos de directiva de JCE estén instalados.

Consulte también

Integrating PolyBase with Cloudera using Active Directory Authentication (Integración de PolyBase con Cloudera mediante Autenticación de Active Directory)
Cloudera's Guide to setting up Kerberos for CDH (Guía de Cloudera para configurar Kerberos para CDH)
Hortonworks' Guide to Setting up Kerberos for HDP (Guía de Hortonworks para configurar Kerberos para HDP)
Solución de problemas de PolyBase
Errores de PolyBase y posibles soluciones