* ¿Alguien * tiene Windows SVNServe autenticándose en AD/Kerberos a través de SASL/GSSAPI?

Question

Escenario: servidor de Windows en un dominio AD que aloja un repositorio de Subversion usando SVNSERVE solamente (sin Apache) y no VisualSVN.

Objetivo: Autenticar a los usuarios al repositorio de Subversion a través de SASL a través de GSSAPI a un dominio de Windows a través de Kerberos.

Las publicaciones frecuentes en sitios múltiples indican a los usuarios a menudo un callejón sin salida en esta configuración con una "No se pudo obtener la lista de mecanismos SASL". No he visto ninguna instancia donde esto realmente se está ejecutando. ¿Alguien tiene esto funcionando?

Formulo esta pregunta como resultado de una publicación en 2011 en un foro de Gentoo en el que alguien en este escenario revisó los archivos tar de fuentes relevantes y concluyó que, al mismo tiempo, tal configuración probablemente funcionó, los archivos necesarios porque ya no está en la fuente.

GEntoo forum discussion where poster claims svnserve+gssapi+sasl worked at one time, but no longer does.

Ahora, no afirmo que dicen ser exacta, pero sí sé que estoy atascado, precisamente en el mismo punto, y todavía no he visto ningún post que dicen "victoria" sobre tal configuración. Si tiene, por favor asesorar detalles!

Muchas gracias de antemano.

Answer 1

Después de obtener una insignia "tumbleweed" para esta pregunta sin respuesta, y una considerable investigación adicional por mi cuenta, he llegado a la conclusión de que la combinación de temas para Subversion en Windows no es posible bajo el código actual base. Creo que algo en la capa de autenticación SASL es el problema aquí, con alguna fuente eliminada o significativamente modificada para "romper" lo que funcionaba, creo, en un punto.

Mi solución ha sido agregar Apache a la mezcla con mod_auth_sspi, y aunque desacelera un poco el repositorio, la autenticación funciona perfectamente. Esto parece ser la "solución" para el requisito de autenticación.

Answer 2

He hecho autenticación contra AD con SASL + LDAP, pero no con SASL + GSSAPI, y con una pequeña advertencia: tengo que usar y ejecutar svnserve desde Cygwin en Windows.

1) Fue bastante fácil conseguir que svnserve autenticara usuarios a través de SASL + LDAP/AD en Linux (sé que la pregunta es sobre svnserve en Windows, pero tengan paciencia). La parte importante para que la autenticación funcione contra LDAP/AD es saslauthd, y prueba la autenticación usando testsaslauthd.

Usando Ubuntu como un ejemplo:

1a) /etc/sasl2/svn.conf

pwcheck_method: saslauthd 
mech_list: PLAIN 

Esto le dice a la subversión/svnserve utilizar saslauthd para hacer la autenticación en su nombre.

1b) /etc/saslauthd.conf

ldap_servers: ldap://yourADserver.dept.org 
ldap_search_base: DC=dept,DC=org 
ldap_bind_dn: cn=bindaccount,dc=dept,dc=org 
ldap_bind_pw: passwordOfbindaccount 

ldap_deref: never 
ldap_restart: yes 
ldap_scope: sub 
ldap_use_sasl: no 
ldap_start_tls: no 
ldap_version: 3 
ldap_auth_method: bind 
ldap_filter: sAMAccountName=%u 
ldap_password_attr: userPassword 
ldap_timeout: 10 
ldap_cache_ttl: 5 
ldap_cache_mem: 32768 

1c) hacer una prueba a través de testsaslauthd

testsaslauthd -u myusername -p mypassword 

1d) Si tiene éxito, a continuación, ejecutar saslauthd, e iniciar svnserve. y use el cliente svn para probar la autenticación.

2) El problema es que no existe un puerto nativo de saslauthd de Cyrus para Windows, y probablemente nunca lo será. La respuesta es usar Cygwin, que tiene svnserve, testsaslauthd y saslauthd.

Simplemente repita los pasos anteriores ... pero la ubicación de svn.conf puede ser diferente.

Answer 3

¡Acabo de gestionar (después de casi 30 horas de scratching de cabeza, compilación y depuración sin código fuente para obtener códigos de error decentes) para hacer que svnserve + SASL + GSSAPI funcione! Mi configuración es la siguiente:

• El servidor AD es Samba 4.1.0 en Debian 7.2 (construido desde la fuente).
• El servidor de Subversion es subversión 1.8.5 en Solaris Express (SunOS 5.11 snv_151a i86pc i386 i86pc). Creado para x64 desde la fuente usando SASL nativo (Sun).
• El cliente es Windows 7 x64 con TortoiseSVN 1.8.2 (versión binaria x64) y Heimdal 1.5.1 (x64 binario de puntos finales seguros).
• Al igual que con cualquier cosa que implica Kerberos, es necesario tener directa e inversa DNS en funcionamiento sin problemas, relojes sincronizados, etc.

Pasos en un cuadro de Windows con creds de dominio:

• crear un "svnserve "cuenta de usuario (no cuenta de computadora) para el servidor de Subversion.
• Ejecute "ktpass -princ svn/server.domain.local@DOMAIN.LOCAL -mapuser DOMAIN.LOCAL \ svnserve -crypto RC4-HMAC-NT -pass contraseña -ptype KRB5_NT_PRINCIPAL -out svnserve.keytab". Hace no desea activar DES para esta cuenta o Windows 7 se negará a autenticarse en ella. Lo prendí antes (siguiendo las recetas) y tuve que apagarlo nuevamente para que funcione.

Pasos para el servidor de Subversion:

• Configure /etc/krb5/krb5.conf

  [libdefaults] 
      default_realm = DOMAIN.LOCAL 
  
  [realms] 
      DOMAIN.LOCAL = { 
       kdc = pdc.domain.local 
       admin_server = pdc.domain.local 
      } 
  
  [domain_realm] 
      .domain.local = DOMAIN.LOCAL 
      domain.local = DOMAIN.LOCAL 
  
  # Other defaults left as-is. 
  

• Configurar repo/conf/svnserve.conf:

  [general] 
  anon-access = none 
  authz-db = authz 
  realm = DOMAIN.LOCAL 
  
  [sasl] 
  use-sasl = true 
  min-encryption = 0 
  max-encryption = 256 
  

• Configurar repo/conf/authz: ​​

  [aliases] 
  
  [groups] 
  
  [/] 
  * = 
  # Still investigating whether access to the server can be controlled through an AD group. 
  # Below is for user@DOMAIN.LOCAL, the realm appears to get lost. 
  user = rw 
  

• Establecer /etc/sasl/svn.conf:

  mech_list: GSSAPI 
  

• gota svnserve.keytab a /etc/krb5/krb5.keytab (tabla de claves en la configuración sasl no lo hace parece hacer cualquier cosa).

• Iniciar svnserve.

Pasos para el cliente:

• Instalar TortoiseSVN y Heimdal.
• Editar C: \ ProgramData \ Kerberos \ krb5.conf para que sea como /etc/krb5/krb5.conf en el servidor de Subversion.Hay algunos otros valores predeterminados que dejé en paz.
• ¡Realice la compra, no necesita contraseña!

Un problema con esta disposición es que el proceso svnserve tiene que ser capaz de leer /etc/krb5/krb5.keytab, por lo que los permisos en esa necesidad de ser enrollados hacia atrás un poco. svnserve está yendo a su propia zona, así que esto no es un problema para mí. También tuve mslsa_cc.dll colisionando mientras probaba cosas, pero no he visto ningún bloqueo una vez que tengo todo resuelto.

Con algunas disputas, es posible que también pueda hacer que esto funcione para svnserve en Windows. Probé MIT Kerberos en el cliente de Windows, pero se bloqueó cada vez que se inició, así que renuncié. Quizás tengas mejor suerte.

Actualización: averiguado el problema de choque - que es un error en mslsa_cc.dll (similar a https://github.com/krb5/krb5/commit/7acb524f5aa00274771dbbfac19d2dd779aad409, que también consigue un poco mal como nOutStringLen necesita ser dividido por 2 para la forma en que AnsiToUnicode se llama). parche binario en mslsa_cc.dll es:

• Offset 0xB46: Cambio de FF 15 04 69 00 a D1 EE 0F 1F 40.
• Offset 0xB5E: Cambio de 77 a EB.