Łączenie Microsoft AD FS z Sophos Central
Microsoft AD FS może uwierzytelniać istniejące tożsamości Active Directory w Sophos Central. Proces jest inicjowany przez SP: Sophos Central dostarcza Entity ID i Callback URL, a AD FS przetwarza logowanie jako Claims-Aware Relying Party Trust.
AD FS wymaga więcej samodzielnej obsługi niż Entra ID lub zarządzana usługa OIDC. Certyfikaty, metadane, dostępność zewnętrzna, wysoka dostępność i poziom aktualizacji Federation Service pozostają odpowiedzialnością organizacji.
Wymagania
Wymagane są uprawnienia Super Admina w Central, działająca usługa AD FS, zgoda osoby odpowiedzialnej za AD i zweryfikowana domena. Administratorzy i użytkownicy Central muszą istnieć w używanym lesie AD, a ich adresy e-mail muszą odpowiadać adresom zapisanym w Central.
Przed aktywacją opcji logowania Federated credentials only każdy objęty administrator i użytkownik musi być przypisany do zweryfikowanej domeny oraz działającego Identity Provider. W przeciwnym razie zmiana zablokuje te konta. Niezależne konto awaryjne Sophos i pomyślny test pilotażowy należą więc do wymagań wstępnych, a nie dopiero do późniejszej diagnostyki.
Przed zmianą w Central sprawdza się AD FS Metadata URL, certyfikaty Federation Service i zewnętrzne rozwiązywanie nazw. Sophos pokazuje format metadanych https://login.microsoftonline.com/<TenantDomainName>/FederationMetadata/2007-06/FederationMetadata.xml. W przypadku klasycznej własnej usługi AD FS należy jednak użyć rzeczywiście opublikowanego FederationMetadata URL własnej usługi. Przykładu Microsoft Online nie wolno bez kontroli przenosić do lokalnego AD FS.
Przygotowanie domeny i providera w Central
W sekcji Global Settings > Access Control > Sign-in and Identity > Sophos sign-in > Verify domains domenę weryfikuje się za pomocą rekordu DNS TXT. Propagacja może potrwać do 24 godzin, a weryfikacja obowiązuje przez rok.
Następnie należy:
- Otworzyć Federated identity providers i utworzyć nowego providera.
- Wprowadzić nazwę bez problematycznych znaków specjalnych i opis.
- Wybrać Type: Microsoft AD FS i odpowiedniego dostawcę.
- Wprowadzić sprawdzony AD FS metadata URL.
- Wybrać zweryfikowaną domenę.
- Określić, czy AD FS wymusza MFA, czy po udanym logowaniu AD FS własnego MFA wymaga Central.
- Zapisać i skopiować wygenerowane przez Central Entity ID oraz Callback URL z providera.
Providera nie aktywuje się jeszcze w całym tenancie jako jedynej drogi logowania.
Tworzenie Relying Party Trust w AD FS
Na serwerze AD FS uruchamia się kreator Add Relying Party Trust przez Server Manager > Tools > AD FS Management:
- Wybrać Claims Aware.
- Użyć Enter data about the relying party manually.
- Wprowadzić jednoznaczną Display Name.
- Wybrać AD FS profile. W kroku certyfikatu przejść dalej, jeśli nie ma dodatkowego wymagania szyfrowania.
- W sekcji Configure URL aktywować Enable support for the WS-Federation Passive protocol.
- Wprowadzić skopiowany z Central Callback URL jako WS-Federation Passive Protocol URL.
- W Configure Identifiers dodać skopiowany z Central Entity ID jako Relying Party Trust Identifier.
- Skonfigurować MFA zgodnie z własnym projektem AD FS i Conditional Access.
- W etapie pilotażowym zezwolić tylko potrzebnym użytkownikom. Sophos pokazuje Permit all users to access this relying party jako standardową ścieżkę, ale kontrolowana grupa pilotażowa jest bezpieczniejsza.
- Zakończyć konfigurację Trust i bezpośrednio otworzyć okno Edit Claim Rules.
Prawidłowe wydawanie Claims
W Issuance Transform Rules > Add rule wybiera się Send LDAP Attributes as Claims. Jako Attribute Store służy Active Directory. Przypisanie wygląda następująco:
| LDAP Attribute | Outgoing Claim Type |
|---|---|
E-mail-Addresses | Name ID |
Given-Name | Given Name |
Surname | Surname |
E-mail-Addresses | E-mail Address |
Wartość e-mail jest kluczowa dla przypisania do Central. Puste, podwójne lub odmienne adresy należy skorygować przed wdrożeniem. Udane logowanie AD FS bez pasującego E-mail Claim nadal nie prowadzi niezawodnie do właściwego konta Central.
Aktywacja i testowanie providera
Po utworzeniu Trust w AD FS providera aktywuje się w Central przez Turn on. W sekcji Sophos sign-in początkowo pozostawia się wybór między danymi dostępowymi Sophos a logowaniem federacyjnym.
Test rozpoczyna się na stronie logowania Sophos i obejmuje:
- zwykłego administratora,
- Super Admina,
- MFA w AD FS lub Central,
- użytkownika bez uprawnienia Trust,
- wylogowanie i ponowne logowanie,
- wygaśnięcie lub zmianę AD FS Signing Certificate,
- niezależne konto awaryjne z logowaniem Sophos.
Dopiero potem aktywuje się Federated credentials only. W tym momencie wszystkie objęte konta muszą być przypisane do zweryfikowanej domeny i włączonego providera.
Rozwiązywanie problemów
- Metadata URL jest niedostępny: sprawdzić DNS, certyfikat, TLS, Web Application Proxy i Federation Service.
- Relying Party Identifier jest nieprawidłowy: dokładnie skopiować Entity ID z Central i sprawdzić niewidoczne spacje.
- Błąd Callback: porównać WS-Federation Passive URL z aktualnym Central Callback URL.
- AD FS akceptuje użytkownika, ale Central nie: sprawdzić Claims e-mail i Name ID oraz adres e-mail w Central.
- Brakuje MFA lub jest wykonywane podwójnie: wspólnie sprawdzić reguły AD FS i wybór IdP enforced MFA.
- Provider przestał działać po zmianie certyfikatu: zaktualizować Metadata, Signing Certificate i zaufanie Central, a następnie ponownie przeprowadzić test pilotażowy.
Nadrzędny proces dla Sign-in Rules, odzyskiwania MFA i kontrolowanego przejścia na Federated credentials only opisano w artykule Zabezpieczanie logowania Sophos Central za pomocą MFA, Passkeys i IdP.