Czy powinienem udostępniać moją usługę Active Directory publicznemu internetowi dla użytkowników zdalnych?

Mam klienta, którego siła robocza składa się wyłącznie ze zdalnych pracowników korzystających z komputerów PC / laptopów Apple i Windows 7.

Użytkownicy nie uwierzytelniają się obecnie w domenie, ale organizacja chciałaby przejść w tym kierunku z kilku powodów. Są to maszyny należące do firmy, a firma stara się mieć kontrolę nad dezaktywacją konta, polityką grupy i lekkim zapobieganiem utracie danych (wyłączanie zdalnych nośników, USB itp.). Obawiają się, że aby uzyskać dostęp do AD, wymagane jest uwierzytelnienie VPN. byłoby kłopotliwe, szczególnie na skrzyżowaniu zwalnianego pracownika i danych uwierzytelniających w pamięci podręcznej na zdalnym komputerze.

Większość usług w organizacji jest oparta na Google (poczta, pliki, czat itp.), Więc jedynymi usługami domenowymi są DNS i autoryzacja dla ich sieci Cisco ASA VPN.

Klient chciałby zrozumieć, dlaczego niedopuszczalne jest udostępnianie kontrolerów domeny opinii publicznej. Ponadto, jaka jest bardziej akceptowalna struktura domen dla rozproszonej zdalnej siły roboczej?

Edytować:

Centrify jest używany w garstce klientów Mac.

Podaję to jako odpowiedź głównie dlatego, że każdy ma swoją „wykształconą opinię” opartą na doświadczeniu, informacjach zewnętrznych, pogłoskach i wiedzy plemiennej w zakresie IT, ale jest to raczej lista cytatów i odczytów „bezpośrednio” od Microsoft. Użyłem cytatów, ponieważ jestem pewien, że nie filtrują one właściwie wszystkich opinii swoich pracowników, ale powinno to okazać się pomocne, jeśli poszukujesz authoritativereferencji bezpośrednio od Microsoft.

BTW, myślę też, że BARDZO ŁATWE jest powiedzenie KONTROLERA DOMENY == AKTYWNY KATALOG, co nie jest do końca prawdą. Serwery proxy usług AD FS i inne środki (uwierzytelnianie oparte na formularzach dla OWA, EAS itp.) Oferują sposób „ujawnienia” samej usługi AD w Internecie, aby umożliwić klientom przynajmniej próbę uwierzytelnienia za pośrednictwem usługi AD bez ujawniania samych kontrolerów domeny. Idź na czyimś miejscu OWA i próba logowania i AD będzie się żądanie autoryzacji na backend DC, więc AD jest technicznie „narażony” ... ale jest zabezpieczona przez SSL i proxy przez serwer Exchange.

Cytat nr 1

Wytyczne dotyczące wdrażania usługi Windows Server Active Directory na maszynach wirtualnych Windows Azure

Zanim przejdziesz do „Azure not AD” ... MOŻESZ wdrożyć ADDS na maszynie Wirtualnej platformy Azure.

Ale żeby zacytować odpowiednie bity:

Nigdy nie narażaj STS bezpośrednio na Internet.

Najlepszą praktyką bezpieczeństwa jest umieszczanie instancji STS za zaporą ogniową i podłączanie ich do sieci firmowej, aby zapobiec narażeniu na działanie Internetu. Jest to ważne, ponieważ rola STS wydaje tokeny zabezpieczeń. W rezultacie należy je traktować z takim samym poziomem ochrony jak kontroler domeny. W przypadku naruszenia STS złośliwi użytkownicy mogą wydawać tokeny dostępu potencjalnie zawierające oświadczenia o wyborze aplikacji stron i innych STS w zaufanych organizacjach.

ergo ... nie udostępniaj kontrolerów domeny bezpośrednio w Internecie.

Odniesienie nr 2

Active Directory - Tajemnica UnicodePwd AD LDS

Udostępnianie kontrolera domeny w Internecie jest zwykle złą praktyką, niezależnie od tego, czy narażenie pochodzi bezpośrednio ze środowiska produkcyjnego, czy przez sieć obwodową. Naturalną alternatywą jest umieszczenie serwera Windows Server 2008 z rolą usług Active Directory Lightweight Directory Services (AD LDS) w sieci obwodowej.

Odniesienie nr 3 - nie od stwardnienia rozsianego ... ale nadal przydatne w patrzeniu w przyszłość

Usługa Active Directory jako usługa? Azure, Intune podpowiedzi na temat hostowanej w chmurze przyszłości AD

W końcu nie ma doskonałej „krótkiej” odpowiedzi, która spełniałaby cele polegające na pozbawieniu biura serwera AD w zamian za alternatywę platformy Azure. Podczas gdy Microsoft nie pozwala klientom na hostowanie usług domenowych w usłudze Active Directory na serwerach 2012 i 2008 R2 na platformie Azure, ich przydatność jest tak dobra, jak łączność VPN, którą można zebrać dla swoich pracowników. DirectAccess, choć bardzo obiecująca technologia, ma związane ręce z powodu swoich niefortunnych ograniczeń.

Odniesienie nr 4

Wdróż AD DS lub AD FS i Office 365 z pojedynczym logowaniem i maszynami wirtualnymi Windows Azure

Kontrolery domeny i serwery AD FS nigdy nie powinny być narażone bezpośrednio na Internet i powinny być osiągalne tylko przez VPN

Usługa Active Directory (AD) nie została zaprojektowana dla tego rodzaju wdrożenia.

Modele zagrożeń zastosowane w projekcie produktu zakładają wdrożenie „za firewallem” z pewną liczbą wrogich aktorów filtrowanych na granicy sieci. Chociaż z pewnością możesz zahartować system Windows Server, aby był narażony na działanie sieci publicznej, poprawne funkcjonowanie usługi Active Directory wymaga znacznie bardziej luźnej postawy niż host wzmocniony dla sieci publicznych. Aby usługi AD działały poprawnie, wiele usług musi zostać ujawnionych przez kontroler domeny (DC).

Sugestia Zoredache w komentarzach, szczególnie odnosząca się do czegoś takiego jak OpenVPN działający jako usługa obejmująca cały komputer z uwierzytelnianiem certyfikatów, może być po prostu dobrym rozwiązaniem. DirectAccess, jak wspomnieli inni, jest dokładnie tym, czego potrzebujesz, z wyjątkiem tego, że nie ma obsługi wielu platform, którą chciałbyś.

Nawiasem mówiąc: zastanawiałem się nad wykorzystaniem IPSEC opartego na certyfikatach w trybie transportowym do udostępniania AD bezpośrednio w Internecie, ale tak naprawdę nigdy nie miałem na to czasu. Microsoft wprowadził zmiany w ramach czasowych systemu Windows Server 2008 / Vista, które podobno sprawiły, że było to wykonalne, ale tak naprawdę nigdy tego nie wykorzystałem.

Co wszyscy inni powiedzieli. Szczególnie denerwuję się próbami brutalnej siły, o których wspomniał Christopher Karel. Prezentacja na ostatnim Def Con była na ten temat:

Więc uważasz, że kontroler domeny jest bezpieczny?

JUSTIN HENDRICKS INŻYNIER BEZPIECZEŃSTWA, MICROSOFT

Kontrolery domen są klejnotami koronnymi organizacji. Po upadku wszystko w domenie spada. Organizacje dokładają wszelkich starań, aby zabezpieczyć swoje kontrolery domeny, jednak często nie zabezpieczają odpowiednio oprogramowania używanego do zarządzania tymi serwerami.

Ta prezentacja obejmie niekonwencjonalne metody pozyskiwania administratora domeny poprzez nadużywanie powszechnie używanego oprogramowania do zarządzania, które wdrażają i używają organizacje.

Justin Hendricks pracuje w zespole ds. Bezpieczeństwa Office 365, gdzie bierze udział w czerwonych zespołach, testach penetracyjnych, badaniach bezpieczeństwa, przeglądzie kodu i rozwoju narzędzi.

Jestem pewien, że możesz znaleźć wiele innych przykładów. Szukałem artykułów o kontrolerach domen i hakowaniu w nadziei, że uzyskam opis tego, jak szybko DC zostanie znaleziony itp., Ale myślę, że tak się stanie.

Jeśli próbujesz przekonać kierownictwo, dobrym początkiem byłoby:

It goes against Microsoft's Best Practices for Active Directory Deployment.

Aktualizacja : zobacz ten artykuł technet na temat zabezpieczania kontrolerów domeny przed atakiem oraz sekcję zatytułowaną Perimeter Firewall Restrictions:

Perimeter firewalls should be configured to block outbound connections
from domain controllers to the Internet. 

I sekcja zatytułowana Blocking Internet Access for Domain Controllers:

Launching web browsers on domain controllers should be prohibited not only
by policy, but by technical controls, and domain controllers should not be
permitted to access the Internet

Jestem pewien, że możesz zebrać trochę dokumentacji Microsoft w tej sprawie, więc to tyle. Oprócz tego możesz podać zagrożenia związane z takim ruchem, coś w stylu:

A gaping hole would be created, possibly resulting in severe data loss and/or loss of company secrets.

Pamięci podręczne są po prostu buforowane. Działają na komputerze lokalnym, gdy nie może połączyć się z domeną , ale gdyby to konto zostało wyłączone, nie działałyby dla żadnego zasobu sieciowego (svn, VPN, smb, FBI, cia itp.), Więc nie muszą się o to martwić . Pamiętaj również, że użytkownicy mają już pełne prawa do dowolnych plików w swoim folderze profilu na komputerze lokalnym (i prawdopodobnie na nośnikach wymiennych), więc zablokuj poświadczenia, czy nie, mogą zrobić to, co im się podoba z tymi danymi. Nie działałyby również dla komputera lokalnego po ponownym połączeniu z siecią.

Czy masz na myśli usługi świadczone przez Active Directory lub kontroler domeny, takie jak LDAP? Jeśli tak, LDAP jest często bezpiecznie dzielony na potrzeby uwierzytelniania i wyszukiwania w katalogach, ale samo wyłączenie Zapory systemu Windows (lub otwarcie wszystkich wymaganych portów dla społeczeństwa - w tym przykładzie to samo) może spowodować poważne problemy.

AD tak naprawdę nie zarządza komputerami Mac, więc wymagane byłoby osobne rozwiązanie (pomyśl OS X Server). Możesz dołączyć komputer Mac do domeny, ale to niewiele więcej niż pozwala na uwierzytelnianie przy użyciu poświadczeń sieciowych, ustawianie administratorów domeny jako lokalnych administratorów na komputerze Mac itp. Brak zasad grupy. MS próbuje przełamać ten grunt dzięki nowszym wersjom SCCM, które twierdzą, że są w stanie wdrażać aplikacje na komputery Mac i * nix box, ale nie widziałem tego jeszcze w środowisku produkcyjnym. Wierzę również, że możesz skonfigurować Maca, aby łączył się z OS X Server, który uwierzytelniałby się w katalogu opartym na AD, ale mogę się mylić.

Biorąc to pod uwagę, można opracować pewne kreatywne rozwiązania, takie jak sugestia Evana, aby użyć OpenVPN jako usługi i wyłączyć certyfikat maszyny, jeśli / kiedy przyjdzie czas na zwolnienie tego pracownika.

Wygląda na to, że wszystko jest oparte na Google, więc Google działa jak Twój serwer LDAP? Polecam mojemu klientowi, aby zachował to w ten sposób, jeśli to w ogóle możliwe. Nie znam charakteru Twojej firmy, ale w przypadku aplikacji internetowych, takich jak serwer git lub redmine, nawet jeśli konfiguracja wewnętrzna może uwierzytelniać się za pomocą OAuth, korzystając z konta Google.

Wreszcie, konfiguracja roadwarrior, taka jak ta, prawie wymagałaby VPN, aby odnieść sukces. Gdy maszyny zostaną wprowadzone do biura i skonfigurowane (lub skonfigurowane zdalnie za pomocą skryptu), potrzebują sposobu na otrzymanie wszelkich zmian w konfiguracji.

Mac wymaga oddzielnego podejścia do zarządzania oprócz VPN, szkoda, że ​​nie robią już prawdziwych serwerów Mac, ale mieli kilka dobrych implementacji zasad w OS X Server, kiedy sprawdzałem ostatni raz (kilka lat temu ).

Szkoda, że ​​DirectAccess jest dostępny tylko w Win7 + Enterprise Edition, ponieważ jest on dostosowany do twoich potrzeb. Ale nie znając swojego wydania i widząc, że masz MacOS, to nie zadziała.

/ Edytuj - wygląda na to, że niektóre firmy zewnętrzne twierdzą, że mają klientów DA dla Unices: http://www.centrify.com/blogs/tomkemp/what_is_microsoft_directaccess_and_unix_linux_interoperability.asp

Dostępne są rozwiązania MDM, które mogą spełniać Twoje potrzeby; wprowadzamy jednego z nich (MAAS360) do klienta, który ma podobną pozycję.

To oczywiście stanowiłoby poważne zagrożenie bezpieczeństwa. Co więcej, prawdopodobnie nie działałoby tak dobrze, jak byś chciał. Jeśli przypadkowe osoby w Internecie mogą próbować zalogować się do środowiska AD, istnieje duże prawdopodobieństwo, że wszyscy użytkownicy zostaną zablokowani. Na zawsze. A usunięcie wymagań dotyczących blokady oznacza, że ​​sprawdzanie siły prostych prostych haseł jest dość łatwe.

Co ważniejsze, nie powinieneś mieć problemów z realizacją celu (użytkownicy końcowi logują się do laptopa z poświadczeniami domeny) bez bezpośredniego udostępniania serwerów AD. Mianowicie, maszyny Windows mogą buforować ostatnie X udanych logowań, aby te same poświadczenia działały po rozłączeniu. Oznacza to, że użytkownicy końcowi mogą się logować i wykonywać pożyteczną pracę, bez konieczności dotykania serwerów AD. Oczywiście będą musieli użyć sieci VPN, aby połączyć się z innymi głównymi zasobami korporacyjnymi, i jednocześnie mogą odświeżyć ustawienia AD / GPO.

Ewwhite,

Twoje pytanie jest niezwykle ważne i zasługuje na uważną recenzję.

Wszyscy specjaliści ds. Bezpieczeństwa zalecają warstwy zabezpieczeń przed wszelkimi zasobami sieciowymi, w tym zaporami SPI, IDS, zaporami opartymi na hoście itp. Zawsze, gdy to możliwe, należy zawsze używać zapory ogniowej bramy proxy, takiej jak ISA (obecnie TMG).

Mimo to Microsoft Active Directory 2003+ nie ujawnił publicznie żadnych istotnych luk w zabezpieczeniach. Technologia LDAP i jej algorytmy mieszające są na ogół bardzo bezpieczne. Jest to prawdopodobnie bezpieczniejsze niż SSL VPN, jeśli SSL VPN działa w OpenSSL i jest podatny na bicie serca.

Przestrzegam 5 rzeczy:

1. Martw się o inne usługi, które mają do czynienia z siecią, takie jak Serwer terminali, Usługi DNS, CIFS, a zwłaszcza IIS ze swoim strasznym zapisem bezpieczeństwa.

2. Użyj LDAPS z certyfikatem bezpieczeństwa, aby uniknąć przekazywania poświadczeń domeny w postaci zwykłego tekstu przez sieć. Dzieje się to automatycznie po zainstalowaniu usług certyfikatów (użyj osobnej maszyny dla infrastruktury PKI)

3. Umieść sniffer pakietów w interfejsie i obserwuj ruch, popraw wszelkie hasła do jawnego tekstu, ponieważ zapora sieciowa lub nie, jeśli nie korzystasz z VPN lub LDAPS, niektóre starsze systemy wyślą hasła do czystego tekstu.

4. Wiedz, że ataki MITM mogą zmusić rodzime mechanizmy uwierzytelniania do obniżenia poziomu i narazić hasła na słabsze uwierzytelnianie NTLM.

5. Należy pamiętać o niektórych lukach w wyliczaniu użytkowników, które mogą nadal istnieć.

To powiedziawszy, Active Directory ma doskonałe osiągnięcia w zakresie bezpieczeństwa. Ponadto MS Active Directory nie przechowuje haseł, tylko skróty, które mogą również złagodzić dotkliwość kompromisu.

Możesz skorzystać z bardziej płynnej infrastruktury bezpieczeństwa, nie musisz ustawiać specjalnych serwerów DNS ani korzystać z domain.local, a swoją rzeczywistą domenę możesz wykorzystać w publicznym Internecie, takim jak domain.com.

Według mojej profesjonalnej opinii, publiczne wdrażanie technologii bezpieczeństwa, takich jak Active Directory, przynosi znaczne korzyści, podczas gdy inne technologie, takie jak Exchange, DNS i serwery WWW, po prostu nie zapewniają korzyści i całego ryzyka.

Uwaga: jeśli wdrożysz usługę Active Directory, będzie ona obejmować serwer DNS. Bądź PEWNY, aby wyłączyć rekursję na swoich serwerach DNS (domyślnie włączone), w przeciwnym razie będziesz absolutnie uczestniczył w atakach typu „odmowa usługi”.

Twoje zdrowie,

-Brian

Dell (poprzez zakup Quest (przez zakup Vintela)) ma wieloplatformowe rozwiązanie, które jest często wdrażane w przedsiębiorstwach F500 w tym wyraźnym celu .

Rzeczy do rozważenia...

1. Czy twoi użytkownicy są zawsze połączeni? Jeśli tak, najlepiej będzie ci działać w elastycznym środowisku hostingowym opartym na maszynach wirtualnych, które może elastycznie, gdy wielu aktywnych użytkowników wbija LDAP
2. Czy działasz w więcej niż jednym fizycznym centrum danych? Rozważ równoważenie obciążenia geograficznego przed usługami AD, aby zmniejszyć liczbę przeskoków między użytkownikami a systemami
3. Ponadto, jeśli odpowiedź na pytanie nr 2 brzmi „tak”, upewnij się, że skonfigurowałeś dedykowane zasoby sieciowe do replikacji lasu, jak pokazano tutaj

I upewnij się, że twoje zapora ogniowa jest w stanie obsłużyć bardzo wysokie prędkości ponownego przesyłania, jeśli masz użytkowników na przepustnicach uplink, łączących się z głośnych centrów Wi-Fi itp.