Una de los laboratorios más bonitos, en el curso de O365 que imparto, es el de la sincronización y federación de un directorio activo on-premise con el directorio activo de O365 (Azure Active Directory).
Sin embargo nos hemos percatado que el manual del trainer (profesor) y las slides se queda corto con los puertos que tenemos que tener abiertos para que funcione el cotarro, y por eso hoy publico esta tabla que viene de esta página de Microsoft.
Puertos a tutiplen
Primero los imprescindibles para hacer funcionar la sincronización entre ambos LDAP:
| Protocolo | Puertos | DESCRIPCIÓN |
|---|---|---|
| HTTP | 80 (TCP/UDP) | Se usa para descargar CRL (listas de revocación de certificados) para comprobar certificados SSL. |
| HTTPS | 443 (TCP/UDP) | Se usa para sincronizar con Azure AD. |
Estos mismos puertos son los que vamos a necesitar si queremos habilitar Pass-trhough
Si hemos montado una granja de servidores ADFS (Federación) y se tienen que comunicar con el servidor de AD Connect (Sincronización), a los puertos anteriores hay que añadirle:
| Protocolo | Puertos | DESCRIPCIÓN |
|---|---|---|
| WinRM | 5985 | Agente de escucha de WinRM |
Si tenemos un proxy por medio (WAP), y tenemos federación o utilizamos autenticación por certificado, otro puerto más:
| Protocolo | Puertos | DESCRIPCIÓN |
|---|---|---|
| TCP | 49443 (TCP) | Se usa para la autenticación de certificados. |
Hasta aquí todo parece bastante bonito, pero no es así. Hay bastante más puertos que debemos abrir, a coste de la úlcera del compañero de seguridad, si tenemos los servidores del Directorio Activo y de Ad Connect separados entre sí por un firewall, ya que debemos abrir todo esto para que se conecten entre ellos:
| Protocolo | Puertos | DESCRIPCIÓN |
|---|---|---|
| DNS | 53 (TCP/UDP) | Búsquedas DNS en el bosque de destino. |
| Kerberos | 88 (TCP/UDP) | Autenticación Kerberos para el bosque de AD. |
| MS-RPC | 135 (TCP/UDP) | Se usa durante la configuración inicial del Asistente para Azure AD Connect, cuando se enlaza con el bosque de AD, además de durante la sincronización de contraseñas. |
| LDAP | 389 (TCP/UDP) | Se usa para la importación de datos de AD. Los datos se cifran con Kerberos Sign & Seal. |
| RPC | 445 (TCP/UDP) | Lo usa el SSO de conexión directa para crear una cuenta de equipo en el bosque de AD. |
| LDAP/SSL | 636 (TCP/UDP) | Se usa para la importación de datos de AD. La transferencia de datos se firma y se cifra.Solo se utiliza si está usando SSL. |
| RPC | 49152- 65535 (Puerto RCP alto aleatorio)(TCP/UDP) | Se usa durante la configuración inicial de Azure AD Connect, cuando se enlaza con los bosques de AD, además de durante la sincronización de contraseñas. Consulte KB929851, KB832017 y KB224196 para más información. |
Resumen
Los dos puertos necesarios para sincronizar, en condiciones normales donde todos los servidores están en el mismo segmento de red, son el 80 y el 443. Si montamos una federación con su proxy, deberemos añadir el 49443.
Si no es este el contexto, y tenemos los servidores separados, entonces sí que nos tenemos que liar a abrir puertos en el firewall.
Espero que sea de utilidad.
4 comentarios
Buenos días,
Si en el Firewall ya tengo ocupados los puertos 80 y 443, estos se pueden redireccionar a otros?
Muchas gracias.
¿En Azure? Si. Lo puedes hacer con un Load Balancer o con un Firewall, ambos dos te permiten hacer un NAT tanto de entrada como de salida. Además de poder utilizar el appliance que más te guste desde la MarketPlace.
Cual es el motivo por el cual el agente AD no acciona automaticamente la salida de data, si este es consultado por el AD azure llevando las credenciales de seguridad , CA
Buenas,
Perdóname por no contestarte. Pensé que nadie leía este blog… 🙁
La verdad, no se cual podrá ser el motivo. Por cierto, hoy en día ya no utilizaría la respuesta que di en los comentarios en el 2018. Ahora utilizaría el firewall de Azure, que hace el NAT tanto de origen como a destino.