Skorzystaj z aktualnej trasy Service Desk
Ten wpis katalogu używa nazwy Samanage. Procedura wdrożenia ogranicza się do bieżących ustawień poczty elektronicznej SolarWinds Service Desk, którego udokumentowana infrastruktura nadal używa nazw samanage.com . Nie łącz go ze starymi zrzutami ekranu Samanage ani nie zakładaj, że lista kontrolna z ery migracji opisuje obecne konto. Przed wprowadzeniem zmiany zarejestruj usługę, centrum danych, typ konta i odpowiedzialnego administratora.
Obecna nawigacja własna różni się w zależności od organizacji konta. Program ITSM korzysta z opcji Konfiguracja > Konto > Ustawienia poczty e-mail. ESM ma kontekst organizacji lub dostawcy usług wokół tych ustawień. Zapisz, jaki kontekst przeglądasz, aby nie zakładać, że domena skonfigurowana dla jednego usługodawcy obejmuje wszystkich usługodawców. Ustawienia poczty elektronicznej SolarWinds Service Desk
Zidentyfikuj wiadomości, których niezawodność ma znaczenie: odpowiedzi agentów, wiadomości związane z zadaniami, automatyczne powiadomienia o zdarzeniach i wszelkie odrębne ścieżki skierowane do klienta. Zapisz także adresy biletów przychodzących i zasady przekazywania. Uwierzytelnianie wychodzące i tworzenie incydentów przychodzących to różne przepływy; zmiana jednego nie może po cichu niszczyć drugiego.
Zrozumienie kontroli zależnych od uwierzytelniania
Aktualny przewodnik dokumentuje uwierzytelnianie domeny jako warunek wstępny spersonalizowanych adresów e-mail i niestandardowego adresu e-mail odpowiedzi. Odróżnia spersonalizowane nazwy od spersonalizowanych adresów. Na powiadomienia automatyczne nie ma to wpływu w taki sam sposób, jak na wiadomości pochodzące z działań użytkownika. W związku z tym należy przetestować rzeczywiste kategorie wiadomości, zamiast zakładać, że spersonalizowana nazwa wyświetlana agenta opisuje każdego nadawcę. Ustawienia poczty elektronicznej SolarWinds Service Desk
Utwórz listę domen z adresami agentów i stałych tożsamości używanych przez automatyczne powiadomienia. W dziale pomocy technicznej mogą znajdować się agenci z oddziałów lub wykonawców, których domeny e-mail mają różnych właścicieli. Nie autoryzuj domeny tylko dlatego, że jeden agent ma ten adres. Potwierdź, że organizacja ma uprawnienia do wysyłania tożsamości i może ukończyć proces weryfikacji dostawcy.
Traktuj miejsce docelowe odpowiedzi jako zależność funkcjonalną. Adres wsparcia może przekazywać pocztę przychodzącą do skrzynki referencyjnej Service Desk. Zweryfikowany nadawca poczty wychodzącej nie udowadnia, że reguła przekazywania działa lub że odpowiedzi są dołączone do zamierzonego zdarzenia. Dołącz nieszkodliwy test odpowiedzi do wyznaczonego zdarzenia i upewnij się, że nie powiadomi on rzeczywistych użytkowników, których to dotyczy.
Opublikuj wygenerowaną konfigurację składającą się z trzech rekordów
Bieżący udokumentowany przepływ pracy to Ustawienia poczty e-mail > Uwierzytelnianie poczty e-mail > Dodaj domenę niestandardową. Dodaj zatwierdzoną domenę, rozwiń jej ustawienia DNS i skopiuj trzy wygenerowane domeny CNAME dokumentacja. Opublikuj je w autorytatywnym DNS , wróć do konta i użyj opcji Weryfikuj. Oczekiwany pomyślny stan to Zweryfikowano. Ustawienia poczty elektronicznej SolarWinds Service Desk
Używaj generowanych na żywo właścicieli i celów, a nie sfabrykowanych selektorów lub rekord zestaw od innego klienta. Dla każdego wpisu zachowaj dokładną wartość publiczną, powiązaną domenę, TTL i odwołanie do zmiany. Przed wprowadzeniem zmiany poproś administratora DNS o sprawdzenie istniejących danych tego samego właściciela. Konflikt jest powodem do sprawdzenia konfiguracji, a nie pozwoleniem na usunięcie niepowiązanego klucza.
Sprawdź jak konsola DNS obsługuje nazwy względne i pełne. Pomyślny zapis może w dalszym ciągu spowodować utworzenie niewłaściwego właściciela lub celu. Zapytaj o zamierzone nazwy publiczne i w razie potrzeby postępuj zgodnie z ich rozpoznawaniem CNAME . Zapisz, co faktycznie zostało opublikowane i czas obserwacji. Weryfikacja dostawcy i niezależne dowody DNS powinny opisywać ten sam zestaw rekordów.
Jeśli weryfikacja się nie powiedzie, porównaj te wyniki z wartościami wygenerowanymi na koncie bieżącym. Upewnij się, że edytowana usługa DNS jest autorytatywna i że pamięci podręczne miały odpowiedni moment na wygaśnięcie. Nie dodawaj wielokrotnie domeny ani nie nadpisuj rekordów bez zrozumienia istniejącego stanu. Zachowaj dokładny błąd i zaangażuj właściciela usługi, jeśli dostawca nie może rozpoznać prawidłowo opublikowanych rekordów.
Oddzielnie obsługuj kontrolę SPF i lokalnego odbioru
Dokumenty SolarWinds include:_spf.samanage.com w swoim SPF przykład. Przejrzyj jego użycie pod kątem rzeczywistej trasy obwiedni i istniejących autoryzacji organizacji. Nie zastępuj całej polityki organizacji ani nie twórz wielu mających zastosowanie Rekordy SPF. Uwzględnij zagnieżdżoną ocenę DNS i zachowaj legalnych nadawców, którzy już korzystają z tego właściciela. Ustawienia poczty elektronicznej SolarWinds Service Desk SPF RFC 7208
Dostawca wyświetla także listy dozwolonych odbiorów specyficzne dla centrum danych. Kontrole te dotyczą akceptacji przez Twoje własne systemy pocztowe; nie tworzą przechodzącego wyrównanego podpisu dla odbiorców zewnętrznych. Zachowaj wszelkie proponowane zmiany na liście dozwolonych z zespołem ds. bezpieczeństwa i przed użyciem sprawdź aktualne wartości regionalne. Nie stosuj adresów każdego regionu ani ogólnych wyjątków adresów URL w ramach automatycznej naprawy uwierzytelniania.
W szczególności lokalny produkt zabezpieczający może dostarczyć wiadomość z powodu wyjątku, nawet jeśli jego uwierzytelnienie jest nieprawidłowe. Zachowaj podstawowe wyniki uwierzytelniania, a nie tylko rozmieszczenie skrzynki odbiorczej. Zmiany w bezpiecznych linkach, filtrowaniu spamu lub dostępie do załączników mogą mieć szersze skutki dla bezpieczeństwa i wymagać własnego przeglądu. Ten przewodnik nie zaleca omijania tych kontroli, aby test wyglądał na pomyślny.
Nie używaj ponownie harmonogramu migracji na rok 2025
Powiadomienie o migracji firmy SolarWinds opisuje przejście, którego drugi etap datowano na 16 marca 2025 r. Wyjaśnia, dlaczego nieuwierzytelnione konta mogą utracić niestandardowe zachowanie w zakresie odpowiedzi lub zachować spersonalizowane nazwy bez spersonalizowanych adresów. Użyj tego powiadomienia jako historycznego kontekstu diagnostycznego, a nie bieżącego terminu lub dowodu, że konkretna dzierżawa zakończyła migrację. Powiadomienie o migracji usługi e-mail SolarWinds
Jeśli adres zwrotny istniejącego konta nieoczekiwanie zmienił się, porównaj obecne ustawienia z zarejestrowaną wcześniej konfiguracją. Stan uwierzytelnienia może mieć znaczenie, ale nie zakładaj, że jest to jedyna przyczyna. Zapytaj właściciela, czy konto zostało zrestrukturyzowane, dodano usługodawcę lub zmieniono tożsamość agenta. Przed przywróceniem czegokolwiek, udokumentuj aktualną trasę.
Stare rekordy DNS należy usunąć dopiero po ustaleniu, że nie ma aktywnego konta, selektorlub trasa wiadomości zależy od nich. Wiek powiadomienia o migracji nie jest wystarczający, aby określić bezpieczne usunięcie. Oddziel sprzątanie od bezpośredniego zadania polegającego na uzyskaniu zweryfikowanego, działającego nadawcy.
Weryfikuj wiadomości agentów i automatyczne powiadomienia
Utwórz autoryzowany incydent testowy i korzystaj z objętych zakresem ścieżek działań użytkownika i automatycznych powiadomień. Przechwyć oryginalną wiadomość od zaufanego odbiorcy. Zapisz oddzielnie widoczny adres Od i nazwę wyświetlaną, odpowiedź do, tożsamość koperty, wszystko DKIM podpisywanie domen i selektorów oraz zaufane wyniki uwierzytelniania. Dołącz kontekst i zdarzenie dostawcy usług, które wygenerowały wiadomość.
Odczytaj DKIM d= i s= z otrzymanej wiadomości i porównaj je z opublikowaną konfiguracją. Istnienie selektora dowodzi jedynie, że dostępny jest zapis; wiadomość musi faktycznie zawierać ważny podpis. Zachowaj wszystkie istotne podpisy, jeśli odbiorca widzi więcej niż jeden. DKIM RFC 6376
DMARC wymaga przejścia dopasowanej ścieżki uwierzytelniania dla widocznej domeny From. Nazwy Rep-To i wyświetlane nie zastępują tej tożsamości. Przepustka SPF dla domeny kopertowej dostawcy może współistnieć z brakiem SPF wyrównanie, podczas gdy dostosowany DKIM może nadal spełniać DMARC . Oceń rzeczywistą wiadomość w ramach skutecznych zasad. DMARC RFC 9989
Jeśli jedna klasa zakończy się pomyślnie, a inna nie, porównaj tożsamości nadawców przed zmianą współdzielonego DNS . Komunikat o działaniu użytkownika może używać adresu agenta, podczas gdy automatyczne powiadomienie ma inną tożsamość. Jeżeli poczta w ogóle nie została wysłana, sprawdź najpierw zdarzenie powiadomienia i dostępne dowody doręczenia. Rekordy uwierzytelniania nie mogą naprawić braku wyzwalacza ani celowo pominiętego miejsca docelowego.
Fikcyjny przykład mylącej nazwy wyświetlanej
Tylko fikcyjny przypadek pisemny: SW-01 zakłada, że komunikat o działaniu użytkownika wyświetla Alex Support, ale jego faktycznym adresem pozostaje adres usługi dostawcy. Odpowiedź do to help@example.org ; dokładny adres dostawcy, wyniki DKIM i SPF nie są znane. Administrator powinien rozróżnić spersonalizowane nazwy od uwierzytelnionych spersonalizowanych adresów, a następnie osobno przetestować działanie agenta, automatyczne powiadamianie i drogę odpowiedzi na incydent. Nie zmieniaj list dozwolonych otrzymujących, aby zastąpić ten dowód. Nie sprawdzono żadnego konta usługi, zdarzenia ani wiadomości.
Arkusz implementacji i limity wersji
- Kontekst konta: produkt Service Desk, centrum danych, ITSM lub ESM, organizacja lub dostawca usług oraz właściciel.
- Spis tożsamości: domeny agentów, automatyczne powiadomienia z wartości, ustawienia nazw wyświetlanych i adresy zwrotne.
- DNS : wszystkie trzy wygenerowane rekordy CNAME, istniejące dane, dokładne opublikowane nazwy, TTL, czas wyszukiwania i status zweryfikowany.
- Polityka: właściciel SPF i autoryzowane mechanizmy, skuteczna polityka DMARC i oddzielnie zatwierdzone lokalne wyjątki dotyczące odbioru.
- Testy: odniesienie do zdarzenia, działanie wyzwalające, odbiorca, od, odpowiedź do, tożsamość koperty, wartości DKIM d=/s= i wynik dopasowania.
- Odzyskiwanie: wcześniej obsługiwane ustawienia, zależności przekazywania, właściciel wstrzymania powiadomień i przegląd czyszczenia.
Konfiguracja konta na żywo, stan migracji, DNS , otrzymane nagłówki i zrzuty ekranu nie zostały sprawdzone. Ocena wizualna, zatwierdzenie przez MŚP i publikacja pozostają w oczekiwaniu. Ten niepublikowany kandydat obejmuje aktualnie udokumentowaną ścieżkę Service Desk; starsze konfiguracje i nieprzetestowane konteksty dostawców usług pozostają wstrzymane.
Oddziel przekazywaną wiadomość od gotowości do egzekwowania
RFC 9989 Sekcja 7.4 wymaga ważnego DKIM do publikowania w domenie p=reject i ostrzega o interoperacyjności poczty pośredniej. Pojedynczy dopasowany wynik SPF sam w sobie nie uzasadnia wdrożenia zasady odrzucania. Przejrzyj wszystkie legalne trasy i zasady własności niezależnie od konfiguracji tego dostawcy.