Samba 4 supports the same kind of schema extensions as Microsoft Active Directory. Schema updates in AD are a sensitive action and you must be prepared to do a full restore of the DC holding the role of schema master if something goes wrong.
This is even more true in Samba 4 given it does not always generate some critical attributes that are generated on Microsoft AD and this lack of attributes can lead to a un-start-able samba provision. This is why schema updates in Samba 4 are currently disabled by default.
In order to allow them, the option dsdb:schema update allowed must be set to true in the smb.conf or passed on the command line.
Donc il semble qu’on puisse mettre à jour les schémas avec une option explicite.
Cela dit, ce qu’ils disent est intéressant, s’il est si risqué que ça de toucher aux schémas parce que ça peut mener très facilement à des incompatibilités avec Microsoft, alors utiliser volontairement un LDAP tiers n’apporte que la possibilité d’avoir ces mêmes risques.
Il est probable que j’installe un samba sur une machine virtuelle qui ne tienne que le rôle du KDC et du LDAP, et que mes serveurs samba actuels (qui servent des fichiers etc.) ne fassent que la gestion des fichiers en déléguant désormais leur authentification au Samba/KDC. si plus tard j’ai besoin de faire du LDAP avancé, il me sera très probablement possible de monter un OpenLDAP à coté qui authentifie ses utilisateurs auprès du Samba/KDC.
L’idée est de séparer le rôle du KDC pour pouvoir le maintenir indépendamment du reste, comme je ferais avec un Kerberos qui ne ferait que ça, mais en utilisant Samba comme ça ça limite la complexité de la solution (un seul type de logiciel à maintenir, même s’il y a plusieurs instances).
ce commentaire est sous licence cc by 4 et précédentes
[^] # Re: Microsoft Active Directory
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse au journal Disputatio : Samba, Kerberos et LDAP. Évalué à 2. Dernière modification le 04 novembre 2015 à 17:33.
Hum, j’ai lu ici https://wiki.samba.org/index.php/Samba_AD_schema_extensions
Donc il semble qu’on puisse mettre à jour les schémas avec une option explicite.
Cela dit, ce qu’ils disent est intéressant, s’il est si risqué que ça de toucher aux schémas parce que ça peut mener très facilement à des incompatibilités avec Microsoft, alors utiliser volontairement un LDAP tiers n’apporte que la possibilité d’avoir ces mêmes risques.
Il est probable que j’installe un samba sur une machine virtuelle qui ne tienne que le rôle du KDC et du LDAP, et que mes serveurs samba actuels (qui servent des fichiers etc.) ne fassent que la gestion des fichiers en déléguant désormais leur authentification au Samba/KDC. si plus tard j’ai besoin de faire du LDAP avancé, il me sera très probablement possible de monter un OpenLDAP à coté qui authentifie ses utilisateurs auprès du Samba/KDC.
L’idée est de séparer le rôle du KDC pour pouvoir le maintenir indépendamment du reste, comme je ferais avec un Kerberos qui ne ferait que ça, mais en utilisant Samba comme ça ça limite la complexité de la solution (un seul type de logiciel à maintenir, même s’il y a plusieurs instances).
ce commentaire est sous licence cc by 4 et précédentes