Estoy ejecutando un laboratorio de pruebas de AD en casa que tiene un bosque de AD con un solo dominio. El nivel funcional es 2016. Estoy intentando pasar a los controladores de dominio Samba4 por problemas de licencia y también para probar cosas nuevas. Antes de comenzar, me pregunto qué tan compatible es con la infraestructura de Windows existente. La infraestructura actual se detalla a continuación:
- Un controlador de dominio de Windows Server 2019
- Un bosque (Nivel funcional 2019), un dominio
- Varios sitios (actualmente solo estoy usando uno)
- Varios GPO (¿10 ~ 20, creo?)
- ADCS
- <= 5 usuarios
- SQL Server (instalado en un servidor Windows unido a un dominio con autenticación AD)
- WSUS, NPS, recurso compartido de archivos SMB, etc. (varios servidores unidos a un dominio)
- Un clúster de conmutación por error de Hyper-V de dos nodos.
- Conexión AAD
- Actualmente no hay productos de System Center.
- Una o dos PC con Windows 10.
- Usando RSAT para administrar.
¿Funcionarán como están si cambio a Samba DC o habrá algún problema de compatibilidad? ¿Qué tal las ACL de archivos? ¿Qué tal los costos de administración (como administración y resolución de problemas simples, recursos comunitarios enriquecidos, actualización sencilla, etc.)? ¿Es posible cambiar a Samba directamente o necesito crear un nuevo dominio o bosque? Gracias.
Respuesta1
En este momento, Samba 4.15 sólo admiteNivel funcional del servidor 2008, por lo que lo más probable es que no puedas agregar Samba DC a tu dominio existente. Tampoco podrás agregar un nuevo dominio al bosque.
Aparte de eso, puede haber algunos problemas de compatibilidad dependiendo de la versión de Samba; recomiendo encarecidamente la 4.12 o posterior. Aquí está el estado general de Samba 4.15:
Sambahaceadmite unirse a un dominio existente como DC y replicar datos, pero incluso si comienza de nuevo con un dominio solo de Samba, querrá una versión reciente con todas las correcciones relacionadas con la replicación.
Sambano esimplementarServicios web de anuncios, lo que significa que los cmdlets de PowerShell AD no funcionarán. Sin embargo, RSAThacefunciona ya que solo necesita MS-RPC y LDAP tradicionales. (La interfaz de PowerShell
[adsi]también está basada en LDAP, por lo que también funciona).- (Creo recordar que la promoción de Server2012+ como DC parece requerir servicios web de AD por alguna razón, por lo que tampoco funcionará... así que si desea migrar de Samba a Windows Server, es posible que necesite usar Server2008 como un intermediario.)
ACL de archivosvoluntadfuncionan bien, al igual que las ACL de registro, las ACL de impresora, las ACL de GPO, etc. Todas ellas las aplican los propios servidores de archivos, no los DC (el DC solo tiene que informar correctamente las membresías de su grupo).
Servicios de certificados ADvoluntadfunciona, pero no es una característica de DC y no está incluida como parte de Samba; aún necesitará Windows Server para alojar la autoridad de certificación.
- También tenga en cuenta que las versiones anteriores de Samba DC (hasta 4.12) tenían un error que impedía que las computadoras obtuvieran automáticamente "Computadora de dominio" SID, que afectaba a todos los tipos de ACL. Lo más importante es que significaba que la inscripción automática de AD Certificate Services no funcionaría, porque muchas ACL de plantilla de certificado estándar requieren "Equipo de dominio". (Este error se solucionó en 4.13+, por lo que ADCS ahora funciona correctamente , al igual que todos los demás tipos de ACL).
Políticas de grupovoluntadtrabajar. Sin embargo, los datos de GPO no se sincronizarán automáticamente entre varios DC (porque Samba carece de soporte DFS-R), por lo que deberá realizar una robocopia manual de su Sysvol después de cada cambio. (Pero tenga en cuenta el error de ACL "Equipo de dominio").
Conexión de Azure ADprobablementeno funcionará.
No estoy seguro de si la delegación restringida de Kerberos se implementa completamente, lo que puede ser relevante para los clústeres de Hyper-V.
El Hyper-V independiente funciona. La replicación funciona. Migración en vivocasifunciona: hay un pequeño error (hasta 4.16) que impide que los DC de Samba emitan correctamente tickets Kerberos si el SPN contiene espacios.
(Afortunadamente, la migración en vivo de Hyper-V es el único servicio que pensó que sería una buena idea poner espacios en sus SPN. Sin embargo, existe una solución manual:yTambién hay un parche en Bugzilla, pero aún no se ha aplicado).
No tengo idea de si el clustering de Hyper-V funciona o no; podría verse afectado por el error "espacios en SPN", así como por la falta de delegación restringida.