Utiliser l’itinéraire actuel du Service Desk
Cette entrée de catalogue utilise le nom Samanage. La procédure de mise en œuvre ici s'étend aux paramètres de messagerie actuels de SolarWinds Service Desk, dont l'infrastructure documentée utilise toujours les noms samanage.com . Ne le combinez pas avec d’anciennes captures d’écran de Samanage et ne supposez pas qu’une liste de contrôle de l’ère de la migration décrit le compte actuel. Enregistrez le service, le centre de données, le type de compte et l'administrateur responsable avant d'apporter une modification.
La navigation propriétaire actuelle diffère selon l'organisation du compte. ITSM utilise Configuration > Compte > Paramètres de messagerie. ESM dispose d'un contexte d'organisation ou de fournisseur de services autour de ces paramètres. Enregistrez le contexte que vous consultez afin qu'un domaine configuré pour un fournisseur de services ne soit pas censé couvrir tous les fournisseurs de services. Paramètres de messagerie de SolarWinds Service Desk
Identifiez les messages dont la fiabilité compte : réponses des agents, messages liés aux tâches, notifications automatiques d'incidents et tout itinéraire distinct destiné au client. Enregistrez également les adresses des billets entrants et les règles de transfert. L'authentification sortante et la création d'incidents entrants sont des flux différents ; changer l’un ne doit pas briser l’autre en silence.
Comprendre les contrôles dépendants de l'authentification
Le guide actuel documente l'authentification de domaine comme condition préalable aux adresses e-mail personnalisées et à une adresse e-mail de réponse personnalisée. Il distingue les noms personnalisés des adresses personnalisées. Les notifications automatiques ne sont pas affectées de la même manière que les messages provenant des actions des utilisateurs. Par conséquent, testez les catégories de messages réelles plutôt que de supposer que le nom d'affichage personnalisé d'un agent décrit chaque expéditeur. Paramètres de messagerie de SolarWinds Service Desk
Créez une liste de domaines d'adresses d'agent et d'identités fixes utilisées par les notifications automatisées. Un service d'assistance peut contenir des agents de filiales ou de sous-traitants dont les domaines de messagerie ont des propriétaires différents. N'autorisez pas un domaine simplement parce qu'un agent possède cette adresse. Confirmez que l'organisation est autorisée à envoyer l'identité et peut terminer le processus de vérification du fournisseur.
Traitez la destination de la réponse comme une dépendance fonctionnelle. Une adresse d'assistance peut transférer le courrier entrant vers la boîte de dépôt du Service Desk. Un expéditeur sortant vérifié ne prouve pas que la règle de transfert fonctionne ou que les réponses sont jointes à l'incident prévu. Incluez un test de réponse inoffensif avec un incident désigné et assurez-vous qu'il n'informe pas les utilisateurs réellement concernés.
Publier la configuration à trois enregistrements générée
Le flux de travail documenté actuel est Paramètres de messagerie > Authentification de messagerie > Ajouter un domaine personnalisé. Ajoutez le domaine approuvé, développez ses paramètres DNS et copiez les trois générés CNAME enregistrements. Publiez-les dans DNS faisant autorité, revenez au compte et utilisez Verify. L’état de réussite attendu est Vérifié. Paramètres de messagerie de SolarWinds Service Desk
Utilisez les propriétaires et les cibles générés en direct, et non les sélecteurs fabriqués ou un enregistrement défini par un autre client. Pour chaque entrée, conservez la valeur publique exacte, le domaine associé, la durée de vie et la référence de modification. Demandez à l'administrateur DNS d'inspecter les données préexistantes chez le même propriétaire avant d'effectuer la modification. Un conflit est une raison pour enquêter sur la configuration, et non l'autorisation de supprimer une clé sans rapport.
Vérifiez comment la console DNS gère les noms relatifs et complets. Une sauvegarde réussie peut toujours créer le mauvais propriétaire ou la mauvaise cible. Recherchez les noms publics prévus et suivez leur résolution CNAME si nécessaire. Enregistrez ce qui est réellement publié et l’heure de l’observation. La vérification du fournisseur et la preuve DNS indépendante doivent décrire le même ensemble d'enregistrements.
Si la vérification échoue, comparez ces résultats avec les valeurs générées par le compte actuel. Confirmez que le service DNS modifié fait autorité et que les caches ont eu une opportunité appropriée d'expirer. N'ajoutez pas le domaine à plusieurs reprises ou n'écrasez pas les enregistrements sans comprendre l'état existant. Conservez l'erreur exacte et impliquez le propriétaire du service si le fournisseur ne peut pas reconnaître les enregistrements correctement publiés.
Gérer séparément SPF et les contrôles de réception locaux
Les documents SolarWinds include:_spf.samanage.com dans son SPF exemple. Examinez son utilisation par rapport à l’itinéraire réel de l’enveloppe et à l’autorisation existante de l’organisation. Ne remplacez pas l'ensemble de la politique de l'organisation et ne créez pas plusieurs politiques applicables. Enregistrements SPF. Tenez compte de l'évaluation DNS imbriquée et préservez les expéditeurs légitimes utilisant déjà ce propriétaire. Paramètres de messagerie de SolarWinds Service Desk SPF RFC 7208
Le fournisseur répertorie également les listes autorisées de réception spécifiques au centre de données. Ces contrôles concernent l'acceptation par vos propres systèmes de messagerie ; ils ne créent pas de signature alignée pour les destinataires externes. Conservez toute modification proposée sur la liste blanche avec l'équipe de sécurité et vérifiez les valeurs régionales actuelles avant utilisation. N'appliquez pas les adresses de chaque région ou les exceptions d'URL larges comme réparation automatique de l'authentification.
En particulier, un produit de sécurité local peut délivrer un message en raison d'une exception même lorsque son authentification est erronée. Préservez les résultats d’authentification sous-jacents, pas seulement le placement dans la boîte de réception. Les modifications apportées aux liens sécurisés, au filtrage anti-spam ou à l'accès aux pièces jointes peuvent avoir des effets de sécurité plus larges et nécessiter leur propre examen. Ce guide ne prescrit pas de contourner ces contrôles pour que le test semble réussi.
Ne pas réutiliser le calendrier de migration 2025
L'avis de migration de SolarWinds décrit une transition dont la deuxième phase était datée du 16 mars 2025. Il explique pourquoi les comptes non authentifiés pourraient perdre leur comportement de réponse personnalisé ou conserver des noms personnalisés sans adresses personnalisées. Utilisez cet avis comme contexte de diagnostic historique, et non comme date limite actuelle ou preuve qu'un locataire particulier a terminé la migration. Avis de migration du service de messagerie SolarWinds
Si l'adresse de réponse d'un compte de longue date a changé de manière inattendue, comparez les paramètres actuels avec une configuration antérieure enregistrée. L'état d'authentification peut être pertinent, mais ne présumez pas qu'il s'agit de la seule cause. Demandez au propriétaire si le compte a été restructuré, un fournisseur de services a été ajouté ou l'identité d'un agent a été modifiée. Documentez l'itinéraire actuel réel avant de restaurer quoi que ce soit.
Les anciens enregistrements DNS ne doivent être supprimés qu'après avoir établi qu'aucun compte actif, sélecteur, ou l'itinéraire du message en dépend. L’ancienneté d’un avis de migration ne suffit pas à identifier une suppression en toute sécurité. Séparez le nettoyage de la tâche immédiate consistant à obtenir un expéditeur vérifié et fonctionnel.
Vérifier les messages des agents et les notifications automatiques
Créez un incident de test autorisé et exercez les actions utilisateur et les chemins de notification automatique dans le cadre de la portée. Capturez le message original chez un destinataire fiable. Enregistrez séparément l'adresse d'expéditeur et le nom d'affichage visibles, la réponse à, l'identité de l'enveloppe, le tout DKIM domaines et sélecteurs de signature, ainsi que des résultats d'authentification fiables. Incluez le contexte du fournisseur de services et l'événement qui a généré le message.
Lisez DKIM d= et s= à partir du message reçu et comparez-les avec la configuration publiée. L'existence d'un sélecteur prouve seulement qu'un enregistrement est disponible ; le message doit effectivement utiliser une signature valide. Conservez toutes les signatures pertinentes si le destinataire en voit plusieurs. DKIM RFC 6376
DMARC nécessite un chemin d’authentification aligné pour le domaine visible From. Les noms de réponse et d’affichage ne remplacent pas cette identité. Un pass SPF pour un domaine d'enveloppe de fournisseur peut coexister avec un manque de SPF alignement, bien que DKIM aligné puisse toujours satisfaire DMARC . Évaluez le message réel dans le cadre de la politique efficace. DMARC RFC 9989
Si une classe réussit et une autre échoue, comparez les identités des expéditeurs avant de modifier DNS partagé. Un message d'action utilisateur peut utiliser une adresse d'agent tandis qu'une notification automatique suit une identité différente. Si le courrier n’a pas été envoyé du tout, examinez d’abord l’événement de notification et les preuves de livraison disponibles. Les enregistrements d'authentification ne peuvent pas corriger un déclencheur absent ou une destination intentionnellement supprimée.
Exemple fictif d'un nom d'affichage trompeur
Cas écrit fictif uniquement : SW-01 suppose qu'un message d'action de l'utilisateur affiche Alex Support, mais son expéditeur réel reste une adresse de service du fournisseur. La réponse à est help@example.org ; l'adresse exacte du fournisseur, les résultats DKIM et SPF sont inconnus. L'administrateur doit distinguer les noms personnalisés des adresses personnalisées authentifiées, puis tester séparément l'action de l'agent, la notification automatique et l'itinéraire de réponse à l'incident. Ne modifiez pas les listes d'autorisation de réception pour remplacer ces preuves. Aucun compte de service, incident ou message n'a été inspecté.
Feuille de travail de mise en œuvre et limites de publication
- Contexte du compte : produit Service Desk, centre de données, ITSM ou ESM, organisation ou fournisseur de services et propriétaire.
- Inventaire d'identité : domaines d'agent, valeurs de notification automatique From, paramètres de nom d'affichage et adresses de réponse.
- DNS : les trois CNAME générés, les données existantes, les noms exacts publiés, les TTL, le temps de recherche et le statut vérifié.
- Politique : propriétaire SPF et mécanismes autorisés, politique DMARC efficace et exceptions de réception locale approuvées séparément.
- Tests : référence de l'incident, action déclenchante, destinataire, De, Réponse à, identité de l'enveloppe, valeurs DKIM d=/s= et résultat de l'alignement.
- Récupération : paramètres antérieurs pris en charge, dépendances de transfert, propriétaire de la pause de notification et examen du nettoyage.
La configuration du compte en direct, l'état de la migration, DNS , les en-têtes reçus et les captures d'écran n'ont pas été vérifiés. L’examen visuel, l’approbation de la PME humaine et la publication restent en attente. Ce candidat non publié couvre l'itinéraire documenté actuel du Service Desk ; les configurations héritées et les contextes de fournisseurs de services non testés restent en attente.
Séparez un message qui passe de la préparation à l'application
RFC 9989 La section 7.4 nécessite DKIM valide pour une publication de domaine p=reject et met en garde contre l'interopérabilité du courrier indirect. Un seul résultat SPF aligné ne justifie pas en soi le déploiement d’une politique de rejet. Examinez tous les itinéraires légitimes et la propriété des politiques séparément de la configuration de ce fournisseur.