Cryptage SMB trafic avec Samba
Nous utilisons Samba sur Ubuntu 14.04 LTS en tant que PDC (contrôleur de domaine principal) avec des profils itinérants. Tout fonctionne bien, sauf si nous essayons d'imposer le chiffrement via le réglage:
server signing = mandatory
smb encrypt = mandatory
dans le [global] section de /etc/samba/smb.conf. Après cela, gagnez des clients 8.0 et 8.1 (sans en avoir essayé d'autres). Plainte: Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden. Traduction anglaise de ce texte: The trust relationship between this workstation and the primary domain could not be established.
Si nous ajoutons les deux options server signing et smb encrypt uniquement au [profiles] section de smb.conf, puis tcpdump montre que le trafic réel n'est pas chiffré!
Le smb.conf complet:
[global]
workgroup = DOMAIN
server string = %h PDC
netbios name = HOSTNAME
wins support = true
dns proxy = no
allow dns updates = False
dns forwarder = IP
deadtime = 15
log level = 2
log file = /var/log/samba/log.%m
max log size = 5000
debug pid = yes
debug uid = yes
syslog = yes
utmp = yes
security = user
domain logons = yes
domain master = yes
os level = 64
logon path = \\%N\profiles\%U
logon home = \\%N\%U
logon drive = H:
logon script =
passdb backend = ldapsam:ldap://localhost
ldap ssl = start tls
ldap admin dn = cn=admin,dc=DOMAIN,dc=de
ldap delete dn = no
encrypt passwords = yes
server signing = mandatory
smb encrypt = mandatory
## Sync UNIX password with Samba password
ldap password sync = yes
ldap suffix = dc=intra,dc=DOMAIN,dc=de
ldap user suffix = ou=People
ldap group suffix = ou=Groups
ldap machine suffix = ou=Computers
ldap idmap suffix = ou=Idmap
add user script = /usr/sbin/smbldap-useradd -m '%u' -t 1
rename user script = /usr/sbin/smbldap-usermod -r '%unew' '%uold'
delete user script = /usr/sbin/smbldap-userdel '%u'
set primary group script = /usr/sbin/smbldap-usermod -g '%g' '%u'
add group script = /usr/sbin/smbldap-groupadd -p '%g'
delete group script = /usr/sbin/smbldap-groupdel '%g'
add user to group script = /usr/sbin/smbldap-groupmod -m '%u' '%g'
delete user from group script = /usr/sbin/smbldap-groupmod -x '%u' '%g'
add machine script = /usr/sbin/smbldap-useradd -W '%m' -t 1
[homes]
comment = Home Directories
valid users = %S
read only = No
browseable = No
[netlogon]
comment = Network Logon Service
path = /var/lib/samba/netlogon
admin users = root
guest ok = Yes
browseable = No
[profiles]
comment = Roaming Profile Share
path = /var/lib/samba/profiles
read only = No
profile acls = Yes
browsable = No
valid users = %U
create mode = 0600
directory mode = 0700
De l'aide?
La page de manuel smb.conf doit être mise à jour! Il fait référence à l'ancien mécanisme de chiffrement spécifique à Samba qui s'applique uniquement à SMB1 et se fait via des extensions Unix. Ceci peut être utilisé par smbclient.
De nos jours, le "smb encrypt "Les options contrôlent également le chiffrement au niveau SMB qui fait partie de SMB version 3.0 et plus récente. les clients Windows 8 (et plus récents) devraient crypter le trafic avec ces paramètres .
Avez-vous essayé d'utiliser les mêmes paramètres (smb encrypt = mandatory dans le [global] section) sur un membre du domaine Samba ou un serveur autonome?
Assurez-vous de définir smb encrypt = auto dans [global] section (pas la [profiles] section). Ensuite, la disponibilité générale du cryptage est toujours annoncée.
Il est très possible que ce soit un bug dans Samba. Donc, cela devrait probablement être discuté sur liste de diffusion samba-technial ou bugzilla de samba . Si vous utilisez la version Ubuntu de Samba, vous pouvez également vérifier la page du package . Je soupçonne que c'est un véritable problème en amont de Samba.
Il s'agit d'une nouvelle fonctionnalité introduite avec Samba 3.2 et supérieur. Il s'agit d'une extension du protocole SMB/CIFS négocié dans le cadre des extensions UNIX. SMB utilise la capacité GSSAPI (SSPI sous Windows) pour crypter et signer chaque requête/réponse dans un flux de protocole SMB. Lorsqu'il est activé, il fournit une méthode sécurisée de la communication SMB/CIFS, similaire à une session protégée par SSH, mais utilisant l'authentification SMB/CIFS pour négocier les clés de chiffrement et de signature. Actuellement, cela n'est pris en charge que par le client Samba 3.2, et nous espérons que bientôt les clients Linux CIFSFS et MacOS/X. Windows clients do not support this feature.
Cela contrôle si le client distant est autorisé ou requis à utiliser le chiffrement SMB. Les valeurs possibles sont auto, obligatoires et désactivées. Cela peut être défini sur une base par partage, mais les clients peuvent choisir de chiffrer toute la session, pas seulement le trafic vers un partage spécifique. Si cette option est définie sur obligatoire, tout le trafic vers un partage doit être chiffré une fois la connexion établie avec le partage. Le serveur retournerait "accès refusé" à tous les utilisateurs non les demandes chiffrées sur un tel partage. La sélection du trafic chiffré réduit le débit car de plus petites tailles de paquets doivent être utilisées (aucune lecture/écriture de style UNIX énorme n'est autorisée) ainsi que la surcharge de chiffrement et de signature de toutes les données.
Si SMB est sélectionné, le style Windows SMB (voir l'option de signature du serveur) n'est plus nécessaire, car les indicateurs GSSAPI utilisent la signature et le scellage) des données.
Lorsqu'il est défini sur auto, SMB est proposé, mais non appliqué. Lorsqu'il est défini sur obligatoire, SMB est requis et s'il est désactivé, SMB ne peut pas être négocié.
Par défaut: smb encrypt = auto
Source: https://www.samba.org/samba/docs/man/manpages-3/smb.conf.5.html