OpenLDAP y SVN en MAC OS X sin Kerberos

¡Yo todo! Tengo un server SVN (ejecutándose en MAC OS X Captain). También configuré OpenLDAP, de modo que cuando los usuarios acceden al server SVN con un nombre de usuario y una contraseña, acceden a los repositorys SVN cuando tienen éxito (inputs de la database de wrt openLDAP).

Sin embargo, cuando los usuarios intentan iniciar session en la authentication SVN falla. Ejecuto sldap en modo de debugging para descubrir qué está pasando mal. Descubrí que el usuario y el paso coinciden con las inputs de la database LDAP. Sin embargo, lo que también encontré es que intenta autenticar usuarios con Kerberos. Solo quiero SVN y LDAP. ¿Alguien sabe cómo puedo deshabilitar Kerberos al intentar autenticar?
¡Gracias por adelantado! Leticia

httpd.config recortado (apache 2.4):

<Location /svn/Thesis> DAV svn SVNPath /var/svn/repositories/Thesis AuthType Basic AuthName "Repository" AuthBasicProvider ldap AuthLDAPBindDN "cn=Manager,dc=company,dc=org" AuthLDAPBindPassword pasword1 AuthLDAPURL ldap://158.227.115.33:389/dc=company,dc=org?cn?sub?(objectclass=*) Require ldap-group cn=ActiveMember,ou=Groups,o=company,dc=company,dc=org </Location> 

Slap.conf

 include /private/etc/openldap/schema/core.schema include /private/etc/openldap/schema/cosine.schema include /private/etc/openldap/schema/inetorgperson.schema include /private/etc/openldap/schema/nis.schema include /private/etc/openldap/schema/samba.schema modulepath /usr/libexec/openldap moduleload back_bdb.la # rootdn can always read and write EVERYTHING! access to dn.subtree="o=company,dc=company,dc=org" by dn.base="cn=Manager,dc=company,dc=org" write by self write by users read by anonymous auth access to * by self write by users read by anonymous auth database bdb suffix "dc=company,dc=org" rootdn "cn=Manager,dc=company,dc=org" rootpw {SSHA}dr/1Yu+mRLm6PAHtp+UMqJuJMlMMTFQd directory /private/var/db/openldap/openldap-data # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub 

Ldap.conf

 URI ldap://127.0.0.1/ BASE dc=company,dc=org #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLS_REQCERT demand 

Inicie session cuando los usuarios intenten iniciar session en el SVN (ejecute slapd -d 255)

 ……… 56ec1897 do_bind: version=3 dn="cn=John,ou=Members,o=company,dc=company,dc=org" method=128 56ec1897 ==> bdb_bind: dn: cn=John,ou=Members,o=company,dc=company,dc=org 56ec1897 bdb_dn2entry("cn=John,ou=members,o=company,dc=company,dc=org") 56ec1897 => bdb_search 56ec1897 bdb_dn2entry("cn=kerberoskdc,cn=config,dc=company,dc=org") 56ec1897 => bdb_dn2id("cn=config,dc=company,dc=org") 56ec1897 <= bdb_dn2id: get failed: DB_NOTFOUND: No matching key/data pair found (-30988) 56ec1897 => access_allowed: disclose access to "dc=company,dc=org" "entry" requested 56ec1897 => dn: [1] o=company,dc=company,dc=org 56ec1897 => acl_get: [2] attr entry 56ec1897 => acl_mask: access to entry "dc=company,dc=org", attr "entry" requested 56ec1897 => acl_mask: to all values by "cn=kerberoskdc,cn=config,dc=company,dc=org", (=0) 56ec1897 <= check a_dn_pat: self 56ec1897 <= check a_dn_pat: users 56ec1897 <= acl_mask: [2] applying read(=rscxd) (stop) 56ec1897 <= acl_mask: [2] mask: read(=rscxd) 56ec1897 => slap_access_allowed: disclose access granted by read(=rscxd) 56ec1897 => access_allowed: disclose access granted by read(=rscxd) 56ec1897 send_ldap_result: conn=-1 op=0 p=0 56ec1897 send_ldap_result: err=10 matched="dc=company,dc=org" text="" 56ec1897 Entry *odusers_copy_entry(Operation *): Unable to locate cn=kerberoskdc,cn=config,dc=company,dc=org (32) 56ec1897 odusers_copy_krbrealm: No entry associated with KerberosKDC cn=kerberoskdc,cn=config,dc=company,dc=org 56ec1897 odusers_krb_auth: could not retrieve krb realm while authing John 56ec1897 send_ldap_result: conn=1000 op=2 p=3 56ec1897 send_ldap_result: err=50 matched="" text="" 56ec1897 send_ldap_response: msgid=3 tag=97 err=50 ……. 

¡Finalmente lo resolví!

Aparentemente, si el backend LDAP es bdb, se llama automáticamente a Kerberos (no sé exactamente cómo / por qué). Sin embargo, cuando lo cambio a ldif, no hay llamadas a Kerberos, y todo funciona como se espera. Los pasos que realicé son los siguientes:

  1. Utilizando el directory de Apache Explorador de LDAP de Studio, exporté mi DIT a un file ldif.
  2. Dejé slapd y cambié la línea "database bdb" a "database ldif" (en slap.conf). También eliminé todos los files del directory db, excepto DATABASE_CONFIG.
  3. Empecé slapd, y de nuevo, usando el estudio de directory Apache, importé el file ldif creado previamente (en el paso 1).
  4. voilà 🙂