# [smbpasswd]-Erreur de 'chgmt' de mot de passe d'AD[Résolu]

## y351

Bonjour,

Ma station n'est pas intégrée pas au domaine géré par l'Active Directory (AD).

Mais normalement, je devrais pouvoir changer le mot de passe du compte dun utilisateur en utilisant la commande :

```

smbpasswd -r server_addr -U toto

```

Mais voici l'erreur que j'obtiens :

 *Quote:*   

> 
> 
> Can't load /etc/samba/smb.conf - run testparm to debug it
> 
> 

 

Ma station ne fait pas de serveur...

 *Quote:*   

> 
> 
> [I] net-fs/samba
> 
>      Available versions:  4.5.16^t{tbz2} ~4.7.12^t 4.8.6-r2^t{tbz2} ~4.8.7^t ~4.8.8^t ~4.9.3^t {acl addc addns ads ceph client cluster cups debug dmapi fam gnutls gpg iprint json ldap pam python quota selinux syslog system-heimdal +system-mitkrb5 systemd test winbind zeroconf ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32" KERNEL="linux" PYTHON_TARGETS="python2_7"}
> ...

 

 *Quote:*   

> 
> 
> tree /etc/samba/
> 
> /etc/samba/
> ...

 

```

emerge --info

```

 *Quote:*   

> 
> 
> Portage 2.3.51 (python 3.6.5-final-0, default/linux/amd64/17.0/hardened/selinux, gcc-7.3.0, glibc-2.27-r6, 4.14.83-gentoo x86_64)
> 
> =================================================================
> ...

 

Merci d'avance pour vos retours.Last edited by y351 on Mon Feb 03, 2020 4:29 pm; edited 2 times in total

----------

## El_Goretto

Je n'ai jamais joué avec AD, mais à vue de nez il y a une erreur de syntaxe dans le fichier de config indiqué. Tu as lancé la commande citée, j'imagine?

C'est un grand classique, les commandes qui sourcent au préaalable un fichier de config qui doit être fonctionnel avant de pouvoir faire quoi que ce soit.

----------

## y351

La station ne fait pas office de serveur Samba.

Pourquoi la commande irait-elle solliciter un fichier de conf à destination d'une config de serveur samba ?

Cela me surprend.

J'ai essayé de jouer avec des flags mais ça n'a rien donné...

A noter que sur quelques autres distrib déjà essayées, cela ne pose pas de problème.

----------

## El_Goretto

 *y351 wrote:*   

> La station ne fait pas office de serveur Samba.
> 
> Pourquoi la commande irait-elle solliciter un fichier de conf à destination d'une config de serveur samba ?
> 
> Cela me surprend.
> ...

 

"Pourquoi?"   :Laughing: 

Et pourquoi pas, alors? Doc: 

 *Quote:*   

> 
> 
> The smb.conf file is a configuration file for the Samba suite. smb.conf contains runtime configuration information for the Samba programs
> 
> 

 

Différentes distros = différentes versions de samba et différents contenus de smb.conf.

Tu peux faire mumuse avec les useflags autant que tu veux, tu as un "pain" dans ton fichier de conf, c'est samba qui ne dit.

----------

## y351

J'avais déjà généré ce fichier puis j'avais réessayé en tant que simple utilisateur, mais cela n'avait pas marché, malgré les droits 0644 de /etc/samba/smb.conf

Je n'avais pas essayé en tant que root après création.

En résumé, générer ce fichier vide, puis relancer la commande avec les droits superutilisateur a marché.

NB: Je suis en Hardening, je n'ai pas vu de blocage au niveau des logs lors du lancement de la commande en simple utilisateur. Cela m'embête de lancer la commande en tant que root ou avec un sudo sans password.

----------

## Syl20

Si je comprends bien, tu es capable de changer le mot de passe d'un utilisateur AD... depuis une station qui n'est pas dans l'AD ?!?  :Shocked: 

Et tu voudrais qu'en plus n'importe quel utilisateur local de ta station, privilégié ou non, puisse aussi le faire ? Tu ne trouves pas que ça ressemble un peu trop à une faille de sécurité ?

Attention, smb.conf ne sert pas que pour le démon smbd. Il sert aussi pour winbind, qui permet entre autres d'ouvrir une session locale avec un compte utilisateur AD.

----------

## y351

Lors d'un changement de mot de passe AD, le serveur demande l'ancien mot de passe avant de permettre un nouveau.

Il ne devrait pas être nécressaire de monter en privilège pour changer un mot de passe d'un quelconque compte distant AD.

----------

## y351

Par contre, si tu vois un trou de sécurité dans le process, je voudrais que tu partages ton analyse.

----------

## Syl20

C'est simple. En environnement "entreprise", si n'importe quelle babasse peut être utilisée pour s'authentifier ou changer un mot de passe sur un AD, rien n'empêche un parfait inconnu d'introduire dans l'infrastructure une ou plusieurs stations... disons... "fait-maison". Avec quelques petits logiciels sympathiques installés dessus. Dont un keylogger, évidemment. Les admins AD ne maîtrisent rien, et ne verront rien.

Et si ça marche depuis une station linux plus ou moins bien configurée, n'importe quel utilisateur de l'AD est capable d'ouvrir une session dessus, et peut-être même d'élever indûment ses privilèges. Là, non seulement tu ne maitrises plus rien, mais en plus, tu deviens responsable/coupable d'une compromission de l'infrastructure.

Bref, j'espère que tu fais tout ça chez toi, sur un AD qui t'appartient, ou sur une maquette déconnectée de la prod.

----------

## y351

Je comprends le contexte d'un attaquant potentiel.

Il faudrait quand même plusieurs paramètres pour que cela aboutisse :

- être un externe qui serait déjà arrivé à entrer dans les locaux

- arriver à faire entrer la machine dans l'entreprise

- dupliquer le template d'accueil d'une machine de l'entreprise

- placer la machine dans un bureau libre ou remplacer une machine existant

- sans la mettre sur le réseau, car sinon elle serait détectée immédiatement s'il y a des systèmes d'authen, de repérage

- le fait qu'une machine de travail ne soit pas dans le réseau, alors qu'il devrait l'être, on alerterait immédiatement le Support qui va fouiller en profondeur sur son origine dans l'inventaire, regarder l'antivirus etc...

- si c'est un interne, il faudrait qu'il cible un admin, et ce n'est pas gagné pour qu'un admin change son mot de passe sur une station étrangère que la sienne

- ...

----------

