Los montajes de "unidad doméstica" SMB no se montan automáticamente en el inicio de sesión de ldap, configuración de monta en perfiles de grupos de usuarios

0

En Profile Manager para montar las unidades domésticas predeterminadas establecidas para el usuario en Server.app, marca una casilla de verificación "Agregar red Inicio" ," pero entonces. ¿Alguien sabe cuál es la lista del sistema, etc., a la que realmente hace referencia? porque no me funciona, y las unidades domésticas no se montan automáticamente.

Al hacer clic en "agregar red a casa", se agrega texto como {{{home drive}}} a la lista de puntos de montaje (se ve exactamente así, pero con menos de y más que signos en lugar de corchetes) .

Esta pregunta específica se refiere a una red pequeña donde, al iniciar sesión, los usuarios obtienen varios puntos de montaje autenticados y uno no autenticado (originalmente se configuraron con archivos .mobilconfig generados en el administrador de perfiles y anteriormente en Workgroup Manager).

Ahora he limitado esta pregunta para centrarme en las "unidades domésticas", porque creo que hasta ahora, ese dispositivo superpuesto & los perfiles de grupos de usuarios causaron algunos de estos problemas, pero los he eliminado, y ahora, el Usuario OSX / unidades domésticas de OSX aún no son automáticos -mount.

Como una buena referencia para los 2 pasos necesarios para configurar esto, consulte la pregunta y la respuesta en esta publicación en los foros de Server Fault . También debo agregar que el montaje no parece ser en absoluto coherente, y algunas veces no aparecen otros puntos de montaje, pero esto parece estar relacionado posiblemente con otros factores.

Inicio de sesión de usuarios, la mayoría de las veces obtienen estos recursos compartidos SMB, que a través de los perfiles de configuración pueden aparecer en el escritorio (configuración del Finder), así como auto-montados en Users & Los grupos ¡El problema es que simplemente no aparecen a veces! Los registros del servidor están bastante limpios, dnslookup está bien, todos los nombres del servidor coinciden con el fqdn, por lo que los problemas habituales relacionados con LDAP están en jaque.

El servidor OSX se ejecuta en un Mac Mini que ejecuta Yosemite con Server v. 5.0.1 (el mismo problema también existía en el servidor 4), con los clientes en su mayoría en El Capitain, aunque he visto esto también en una mezcla medio ambiente Esto ocurre solo en aproximadamente el 20% de las cuentas de usuario, sin patrón en la información de servicio de directorio que puedo ver.

    
pregunta forgotstackxpassword 14.09.2016 - 21:59

1 respuesta

1

Estoy empezando a formar mis propias respuestas sobre esto, pero la comprensión completa requerirá mucha investigación y revisión de registros, así que edite, publique otras respuestas y / o comentarios aquí.

En una guía anterior para el servidor OSX , he leído estos comentarios, pero seguramente en lugar de ser requerido para permitir el acceso de invitados a esos recursos compartidos, una cuenta local en el Servidor puede montarlos, o tal vez esa información sea de antes de que el montaje autenticado llegara a OSX:

  

Asegúrese de habilitar el acceso de invitado tanto para el punto compartido como para el   Protocolo bajo el cual se comparte.

     

Nota: los puntos compartidos automatizados están disponibles para los clientes solo cuando sus computadoras se inician.

Un elemento de este problema puede explicarse leyendo Abrir documentación LDAP , en el que se basa el Open Directory de Apple. He visto de vez en cuando, al menos una vez, los mensajes que describen, en los registros de Open Directory .

En lo profundo de OSX, puede haber inconsistencias en las versiones de BerkleyDB, que para el usuario final simple en un mundo perfecto podría resolverse entre la combinación ideal de versiones de OSX en el cliente, OSX (en el servidor) , y Server.app u otros componentes modificables, también en el servidor.

desde el enlace:

  

C.2.9. ldap_sasl_interactive_bind_s: No puedo contactar al servidor LDAP (-1)

     

Al usar SASL, cuando un cliente se pone en contacto con el servidor LDAP, el servicio slapd muere   Inmediatamente y el cliente recibe un error:

 SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) Then check the slapd service, it stopped.
     

Esto puede ser incompatible con el uso de diferentes versiones de   BerkeleyDB para la instalación de SASL y la instalación de OpenLDAP. los   El problema surge en caso de usar múltiples versiones de BerkeleyDB.   Solución: compruebe qué versión de BerkeleyDB instala Cyrus SASL.

     

Reinstale OpenLDAP con la versión de BerkeleyDB anterior.    enlace

    
respondido por el forgotstackxpassword 17.09.2016 - 14:32

Lea otras preguntas en las etiquetas