Cryptage du trafic SMB avec Samba

Nous utilisons Samba sur Ubuntu 14.04 LTS comme PDC (contrôleur de domaine principal) avec des profils itinérants. Tout fonctionne bien, sauf si nous essayons d'imposer le cryptage via la configuration:

    server signing = mandatory
    smb encrypt = mandatory

dans la [global]section /etc/samba/smb.conf. Après cela, gagnez des clients 8.0 et 8.1 (sans en avoir essayé d'autre) se plaignent: Die Vertrauensstellung zwischen dieser Arbeitsstation und der primären Domäne konnte nicht hergestellt werden.Traduction en anglais de ce texte:The trust relationship between this workstation and the primary domain could not be established.

Si nous ajoutons les deux options server signinget smb encryptuniquement à la [profiles]section de smb.conf, cela tcpdumpmontre alors 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. Cela peut être utilisé par smbclient.

De nos jours, les smb encryptoptions " " 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) doivent crypter le trafic avec ces paramètres.

Avez-vous essayé d'utiliser les mêmes paramètres ( smb encrypt = mandatorydans la [global]section) sur un membre de domaine Samba ou un serveur autonome?

Assurez-vous de définir smb encrypt = autodans la [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 la liste de diffusion samba-technial de samba ou bugzilla de samba . Si vous utilisez la version Ubuntu de Samba, vous pouvez également consulter 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. Le chiffrement SMB utilise la capacité GSSAPI (SSPI sous Windows) pour chiffrer et signer chaque demande / réponse dans un flux de protocole SMB. Lorsqu'il est activé, il fournit une méthode sécurisée de communication SMB / CIFS, semblable à 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 smbclient 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, obligatoire et désactivé. Cela peut être défini sur une base par partage, mais les clients peuvent choisir de chiffrer l'intégralité de la session, pas seulement le trafic vers un partage spécifique. Si ce paramètre est défini 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é" à toutes les demandes non chiffrées sur un tel partage. La sélection du trafic chiffré réduit le débit car des tailles de paquets plus petites 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 le cryptage SMB est sélectionné, la signature SMB de style Windows (voir l'option de signature du serveur) n'est plus nécessaire, car les indicateurs GSSAPI utilisent à la fois la signature et le scellage des données.

Lorsqu'il est défini sur auto, le cryptage SMB est proposé, mais pas appliqué. Lorsqu'il est défini sur obligatoire, le cryptage SMB est requis et s'il est défini sur désactivé, le cryptage 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