Nota
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
En este artículo se aborda el código de error 0x40 encontrado durante las operaciones de unión a un dominio.
Síntomas
Al intentar unir un equipo a un dominio, recibirá el siguiente mensaje de error:
El nombre de red especificado ya no está disponible.
Al revisar el archivo netsetup.log , encontrará mensajes de error similares a las siguientes entradas:
NetUseAdd to \\dc1.adatum.com\IPC$ returned 64
NetpJoinDomain: status of connecting to dc '\\dc1.adatum.com': 0x40
NetpJoinDomainOnDs: Function exits with status of: 0x40
Detalles del error
| Error hexadecimal | Error decimal | Cadena de error simbólica | Error descriptivo |
|---|---|---|---|
| 0x40 | 64 | ERROR_NETNAME_DELETED | El nombre de red especificado ya no está disponible. |
Causa
Este problema se produce cuando se cumple alguna de las condiciones siguientes:
- Un dispositivo acelerador de WAN responde para confirmar el paquete de solicitud de TGS, pero la respuesta no llega al Centro de Distribución de Claves (KDC). Por lo general, los campos de fotogramas período de vida de IP (TTL) tienen valores de 64 o inferiores, ya que este es el TTL que usan los dispositivos similares a Unix y los aceleradores WAN se basan generalmente en Linux.
- Un dispositivo de red, como un firewall entre el cliente y el controlador de dominio (DC), descartó la respuesta del KDC. Puede encontrar más detalles en el seguimiento de red simultáneo del tráfico de controlador de dominio.
Solución de problemas
El problema está relacionado con la obtención de tickets Kerberos para una sesión de Bloque de Mensajes del Servidor (SMB). Solucione este problema basado en el seguimiento de la red.
- Utilice el comando
net usepara acceder a la misma ruta de acceso de la Convención de Nomenclatura Universal (UNC) y reproducir el problema. - Recopile un seguimiento de red de la ejecución del
net usecomando.
Ejemplo
Este es un ejemplo de un seguimiento de red:
1534 CLIENT1 DC1.ADATUM.COM TCP TCP:Flags=......S., SrcPort=59259, DstPort=Kerberos(88), PayloadLen=0, Seq=1299628969, Ack=0, Win=8192 ( ) = 8192 {TCP:267, IPv4:5}
1537 DC1.ADATUM.COM CLIENT1 TCP TCP:Flags=...A..S., SrcPort=Kerberos(88), DstPort=59259, PayloadLen=0, Seq=2785282675, Ack=1299628970, Win=8192 ( Scale factor not supported ) = 8192 {TCP:267, IPv4:5}
1538 CLIENT1 DC1.ADATUM.COM TCP TCP:Flags=...A...., SrcPort=59259, DstPort=Kerberos(88), PayloadLen=0, Seq=1299628970, Ack=2785282676, Win=64240 (scale factor 0x0) = 64240 {TCP:267, IPv4:5}
1539 CLIENT1 DC1.ADATUM.COM KerberosV5 KerberosV5:TGS Request Realm: ADATUM.COM Sname: cifs/DC1.ADATUM.COM {TCP:267, IPv4:5}
1540 DC1.ADATUM.COM CLIENT1 TCP TCP:Flags=...A...., SrcPort=Kerberos(88), DstPort=59259, PayloadLen=0, Seq=2785282676, Ack=1299628970, Win=64240 (scale factor 0x0) = 64240 {TCP:267, IPv4:5}
1541 CLIENT1 DC1.ADATUM.COM TCP TCP:[ReTransmit #1539]Flags=...A...., SrcPort=59259, DstPort=Kerberos(88), PayloadLen=1460, Seq=1299628970 - 1299630430, Ack=2785282676, Win=64240 (scale factor 0x0) = 64240 {TCP:267, IPv4:5}
1542 CLIENT1 DC1.ADATUM.COM TCP TCP:[ReTransmit #1539]Flags=...A...., SrcPort=59259, DstPort=Kerberos(88), PayloadLen=1460, Seq=1299628970 - 1299630430, Ack=2785282676, Win=64240 (scale factor 0x0) = 64240 {TCP:267, IPv4:5}
1545 CLIENT1 DC1.ADATUM.COM TCP TCP:[ReTransmit #1539]Flags=...A...., SrcPort=59259, DstPort=Kerberos(88), PayloadLen=536, Seq=1299628970 - 1299629506, Ack=2785282676, Win=64240 (scale factor 0x0) = 64240 {TCP:267, IPv4:5}
1546 DC1.ADATUM.COM CLIENT1 TCP TCP:Flags=...A...., SrcPort=Kerberos(88), DstPort=59259, PayloadLen=0, Seq=2785282676, Ack=1299629506, Win=63704 (scale factor 0x0) = 63704 {TCP:267, IPv4:5}
1547 CLIENT1 DC1.ADATUM.COM TCP TCP:[Continuation to #0]Flags=...A...., SrcPort=59259, DstPort=Kerberos(88), PayloadLen=536, Seq=1299629506 - 1299630042, Ack=2785282676, Win=64240 (scale factor 0x0) = 64240 {TCP:267, IPv4:5}
1548 CLIENT1 DC1.ADATUM.COM TCP TCP:[Continuation to #0]Flags=...A...., SrcPort=59259, DstPort=Kerberos(88), PayloadLen=536, Seq=1299630042 - 1299630578, Ack=2785282676, Win=64240 (scale factor 0x0) = 64240 {TCP:267, IPv4:5}
1549 DC1.ADATUM.COM CLIENT1 TCP TCP:Flags=...A...., SrcPort=Kerberos(88), DstPort=59259, PayloadLen=0, Seq=2785282676, Ack=1299630042, Win=63168 (scale factor 0x0) = 63168 {TCP:267, IPv4:5}
1550 CLIENT1 DC1.ADATUM.COM TCP TCP:[Continuation to #0]Flags=...AP..., SrcPort=59259, DstPort=Kerberos(88), PayloadLen=536, Seq=1299630578 - 1299631114, Ack=2785282676, Win=64240 (scale factor 0x0) = 64240 {TCP:267, IPv4:5}
1551 DC1.ADATUM.COM CLIENT1 TCP TCP:Flags=...A...., SrcPort=Kerberos(88), DstPort=59259, PayloadLen=0, Seq=2785282676, Ack=1299630738, Win=64240 (scale factor 0x0) = 64240 {TCP:267, IPv4:5}
1552 CLIENT1 DC1.ADATUM.COM KerberosV5 KerberosV5: {TCP:267, IPv4:5}
1553 DC1.ADATUM.COM CLIENT1 TCP TCP:[Continuation to #0]Flags=...AP..., SrcPort=Kerberos(88), DstPort=59259, PayloadLen=290, Seq=2785284136 - 2785284426, Ack=1299630738, Win=64240 (scale factor 0x0) = 64240 {TCP:267, IPv4:5}
1554 CLIENT1 DC1.ADATUM.COM TCP TCP:Flags=...A...., SrcPort=59259, DstPort=Kerberos(88), PayloadLen=0, Seq=1299632186, Ack=2785282676, Win=64240 (scale factor 0x0) = 64240 {TCP:267, IPv4:5}
1555 DC1.ADATUM.COM CLIENT1 TCP TCP:Flags=...A...., SrcPort=Kerberos(88), DstPort=59259, PayloadLen=0, Seq=2785284426, Ack=1299631114, Win=63864 (scale factor 0x0) = 63864 {TCP:267, IPv4:5}
1556 CLIENT1 DC1.ADATUM.COM TCP TCP:[Continuation to #1552]Flags=...AP..., SrcPort=59259, DstPort=Kerberos(88), PayloadLen=320, Seq=1299632186 - 1299632506, Ack=2785282676, Win=64240 (scale factor 0x0) = 64240 {TCP:267, IPv4:5}
1557 DC1.ADATUM.COM CLIENT1 TCP TCP:Flags=...A...., SrcPort=Kerberos(88), DstPort=59259, PayloadLen=0, Seq=2785284426, Ack=1299632186, Win=62792 (scale factor 0x0) = 62792 {TCP:267, IPv4:5}
1558 DC1.ADATUM.COM CLIENT1 TCP TCP:Flags=...A...., SrcPort=Kerberos(88), DstPort=59259, PayloadLen=0, Seq=2785284426, Ack=1299632506, Win=64240 (scale factor 0x0) = 64240 {TCP:267, IPv4:5}
1559 CLIENT1 DC1.ADATUM.COM TCP TCP:Flags=...A...F, SrcPort=59259, DstPort=Kerberos(88), PayloadLen=0, Seq=1299632506, Ack=2785282676, Win=64240 (scale factor 0x0) = 64240 {TCP:267, IPv4:5}
1563 DC1.ADATUM.COM CLIENT1 TCP TCP:Flags=...A...., SrcPort=Kerberos(88), DstPort=59259, PayloadLen=0, Seq=2785284136, Ack=1299632507, Win=64240 (scale factor 0x0) = 64240 {TCP:267, IPv4:5}
1564 DC1.ADATUM.COM CLIENT1 TCP TCP:Flags=...A.R.., SrcPort=Kerberos(88), DstPort=59259, PayloadLen=0, Seq=2785284136, Ack=1299632507, Win=0 (scale factor 0x0) = 0 {TCP:267, IPv4:5}
En el seguimiento, se puede observar que el controlador de dominio (DC) no responde a la solicitud del servicio de concesión de vales (TGS) del cliente para el nombre de entidad de seguridad de servicio (SPN) CIFS/DC1.ADATUM.COM. Devuelve una confirmación TCP, que sugiere que el controlador de dominio recibió la solicitud de TGS. Sin embargo, no responde con una respuesta TGS válida. Por último, el cliente finaliza la conexión TCP.
Análisis del tráfico de red
Nota:
Una comprensión completa del comportamiento necesita un seguimiento de la red de corriente continua, lo que también podría aclarar por qué el cliente no podría haber restablecido la sesión antes. El siguiente análisis se basa en el fallo en el seguimiento.
En los fotogramas 1541, 1542 y 1545, el cliente retransmite primero el segmento TCP y, a continuación, reduce el tamaño del marco. Los datos del marco 1545 se reconocen en el marco 1546.
El cliente continúa enviando datos hasta el último segmento del marco 1550, que incluye el bit Push y termina con el último byte 1299631114. El servidor reconoce este segmento en el marco 1555.
Mientras tanto, el cliente envía otra solicitud al servidor en fotogramas 1552 y 1556, con el último byte 1299632506. El servidor reconoce esta solicitud en el marco 1558.
Sin embargo, hasta que el cliente decida finalizar la sesión, solo hay un único mensaje del servidor (marco 1553). Los números de secuencia que llegan al cliente indican que el servidor envía otros datos, como se evidencia en los números de secuencia:
2785282676 first in frame 1540
2785284426 first in frame 1555
2785284136 first in frame 1563
El último número de secuencia es inferior al que envía el servidor en el marco 1555. El cliente nunca ve estos datos y, por tanto, reconoce 2785282676 a lo largo del seguimiento de red. Esta discrepancia indica directamente problemas con el flujo correcto del tráfico de red.