Dans certains environnements Exchange, il arrive qu’un utilisateur puisse se connecter en SMTP, s’authentifier correctement… mais se fasse refuser l’envoi avec une erreur :
550 5.7.60 SMTP; Client does not have permissions to send as this sender
Ce comportement est souvent déroutant, car :
- l’authentification fonctionne
- le compte existe
- l’adresse expéditeur est correcte
Dans beaucoup de cas, la cause est liée à un attribut Active Directory peu connu : adminCount.
Le symptôme typique
Dans un scénario classique :
- SMTP AUTH en 587 fonctionne
- TLS fonctionne
- le login passe (
235 Authentication successful) - mais l’envoi échoue au moment du
DATA
Exemple réel :
550 5.7.60 SMTP; Client does not have permissions to send as this sender
Et pourtant, avec un autre utilisateur standard… tout fonctionne immédiatement.
La cause : adminCount = 1
Dans Active Directory, certains comptes sont considérés comme sensibles (administrateurs, opérateurs, etc.).
Quand un compte appartient (ou a appartenu) à un groupe privilégié, AD applique :
adminCount = 1- une protection via AdminSDHolder
- la désactivation de l’héritage des permissions
👉 Résultat : les ACL normales ne s’appliquent plus correctement.
Pourquoi ça casse SMTP
Exchange s’appuie fortement sur les permissions AD pour valider l’expéditeur.
Avec un compte protégé :
- certaines permissions implicites ne sont plus présentes
- les droits effectifs deviennent incohérents
- Exchange refuse l’envoi avec une erreur
Send As
👉 Même si :
- le compte est valide
- l’adresse est correcte
- l’authentification est OK
Comment détecter le problème
Vérifier adminCount
Get-ADUser utilisateur -Properties adminCount | Select Name,SamAccountName,adminCount
Résultat problématique :
adminCount : 1
Vérifier les groupes
Get-ADPrincipalGroupMembership utilisateur | Select Name
Surveille notamment :
- Domain Admins
- Enterprise Admins
- Administrateurs
- Server Operators
- Print Operators
Pourquoi ça arrive même après avoir quitté un groupe admin
C’est un point clé :
👉 adminCount ne revient pas automatiquement à 0
Même si tu retires l’utilisateur des groupes admin :
- l’attribut reste à
1 - les ACL restent figées
- le problème persiste
Solutions
Option 1 — La bonne pratique (recommandée)
👉 Créer un compte dédié pour SMTP
Exemple :
smtp-app@dyb.fr
Avantages :
- pas de dépendance aux comptes admin
- pas d’effet de bord AD
- plus sécurisé (principe du moindre privilège)
Option 2 — Corriger le compte existant
Si tu veux réutiliser le compte :
1. Retirer des groupes privilégiés
Get-ADPrincipalGroupMembership utilisateur
2. Remettre adminCount à 0
Set-ADUser utilisateur -Clear adminCount
3. Réactiver l’héritage (important)
Dans Active Directory Users and Computers :
- Onglet Security
- Advanced
- Activer Enable inheritance
4. Attendre / forcer la réplication AD
Résumé
| Élément | Impact |
|---|---|
adminCount = 1 | compte protégé |
| AdminSDHolder | bloque héritage des permissions |
| Exchange SMTP | peut refuser l’expéditeur |
| Symptôme | 550 5.7.60 Send As denied |
Recommandation DYB
Pour tous les usages applicatifs (scripts, outils, CI/CD, etc.) :
👉 Toujours utiliser un compte technique dédié
Ne jamais utiliser :
- un compte admin
- un compte utilisateur critique
- un compte ayant appartenu à un groupe privilégié
Conclusion
Le problème ne vient pas toujours d’Exchange.
Dans ce cas précis, c’est Active Directory qui modifie silencieusement les permissions, ce qui impacte directement le fonctionnement SMTP.
👉 Si un SMTP AUTH fonctionne avec un user et pas un autre :
pense immédiatement à adminCount.
0 commentaire