ฉันควรเปิดเผย Active Directory ของฉันไปยังอินเทอร์เน็ตสาธารณะสำหรับผู้ใช้ระยะไกลหรือไม่


46

ฉันมีลูกค้าที่มีพนักงานซึ่งประกอบด้วยพนักงานระยะไกลทั้งหมดโดยใช้การผสมผสานระหว่าง Apple และ Windows 7 เครื่องคอมพิวเตอร์ / แล็ปท็อป

ผู้ใช้ไม่ได้พิสูจน์ตัวตนกับโดเมนในขณะนี้ แต่องค์กรต้องการย้ายไปในทิศทางนั้นด้วยเหตุผลหลายประการ เหล่านี้เป็นเครื่องที่ บริษัท เป็นเจ้าของและ บริษัท พยายามควบคุมการปิดใช้งานบัญชีนโยบายกลุ่มและการป้องกันการสูญเสียข้อมูลบางส่วน (ปิดการใช้งานสื่อระยะไกล USB ฯลฯ ) พวกเขากังวลว่าต้องใช้การรับรองความถูกต้อง VPN เพื่อเข้าถึง AD จะยุ่งยากโดยเฉพาะอย่างยิ่งที่จุดตัดของพนักงานที่ยกเลิกและข้อมูลประจำตัวที่แคชไว้ในเครื่องระยะไกล

บริการส่วนใหญ่ในองค์กรนั้นใช้ Google (อีเมลไฟล์แชท ฯลฯ ) ดังนั้นบริการโดเมนเดียวคือ DNS และรับรองความถูกต้องสำหรับ Cisco ASA VPN

ลูกค้าต้องการที่จะเข้าใจว่าทำไมไม่ยอมรับการเปิดเผยตัวควบคุมโดเมนของตนต่อสาธารณะ นอกจากนี้สิ่งที่เป็นโครงสร้างโดเมนที่ยอมรับมากขึ้นสำหรับพนักงานที่ทำงานระยะไกลการกระจายอย่างไร

แก้ไข:

Centrifyใช้งานสำหรับลูกค้า Mac จำนวนหนึ่ง


4
มีคำถามที่เกี่ยวข้องคือที่นี่ การอนุญาตให้บริการภายนอกเชื่อมต่อโฆษณาของคุณในการซิงค์หรือรับรองความถูกต้องไม่ใช่วิธีปฏิบัติที่แย่มาก แต่การวางตัวควบคุมโดเมนของคุณไว้บน DMZ ที่เปิดอยู่โดยพื้นฐานแล้วคุณได้ถามว่าไม่ปลอดภัยมาก หากไม่มีการรักษาความปลอดภัยคุณจะขอการโจมตีและปัญหาต่าง ๆ ที่อาจเกิดขึ้น ฉันจะขอแนะนำอย่างยิ่งและแนะนำไคลเอนต์ VPN หรือ VPN จากไฟร์วอลล์เช่น Sonicwall กับผู้ใช้อุปกรณ์ในท้องถิ่น
Mike Naylor

10
ตั้งค่า VPN ที่อิงกับเครื่องตลอดเวลาเชื่อมต่อใหม่อัตโนมัติโดยใช้ใบรับรอง (OpenVPN, DirectAccess และอื่น ๆ ) ดังนั้นการตรวจสอบ VPN จะไม่เชื่อมโยงกับบัญชีผู้ใช้และผู้ใช้ไม่มีการโต้ตอบโดยตรงกับซอฟต์แวร์ VPN
Zoredache

DA นั้นสมบูรณ์แบบ แต่มีข้อกำหนดปลายทางที่ร้ายแรงซึ่งลูกค้าไม่สามารถทำได้ (Mac แน่นอน)
mfinni

1
+10 - สำหรับคำแนะนำของ Zoredache
Evan Anderson

7
หากคุณสำรองข้อมูลอุปกรณ์ของผู้ใช้คุณทำผิด หากคุณสำรองข้อมูลอุปกรณ์ผู้ใช้ผ่าน USB คุณกำลังทำสิ่งนี้ผิดจริงๆ
MDMarra

คำตอบ:


31

ฉันโพสต์สิ่งนี้เป็นคำตอบส่วนใหญ่เพราะทุกคนมี "ความรู้ที่มีการศึกษา" ของตัวเองตามประสบการณ์ข้อมูลบุคคลที่สามคำบอกเล่าและความรู้เกี่ยวกับเผ่าในไอที แต่นี่เป็นรายการอ้างอิงและการอ่าน "โดยตรง" จาก Microsoft ฉันใช้เครื่องหมายคำพูดเพราะฉันแน่ใจว่าพวกเขาไม่ได้กรองความคิดเห็นทั้งหมดที่พนักงานของพวกเขาทำ แต่สิ่งนี้น่าจะพิสูจน์ได้ว่ามีประโยชน์หากคุณauthoritativeอ้างอิงจาก Microsoft โดยตรง


BTWฉันคิดว่ามันเป็นเรื่องง่ายมากที่จะพูดว่า DOMAIN CONTROLLER == ACTIVE DIRECTORY ซึ่งไม่ใช่กรณี AD FS ผู้รับมอบฉันทะและวิธีการอื่น ๆ (การตรวจสอบความถูกต้องตามแบบฟอร์มสำหรับ OWA, EAS และอื่น ๆ ) เสนอวิธีการ "เปิดเผย" โฆษณาบนเว็บเพื่อให้ลูกค้าพยายามอย่างน้อยที่สุดในการรับรองความถูกต้องผ่านโฆษณาโดยไม่เปิดเผย DC เอง ไปที่ไซต์ OWA ของใครบางคนและพยายามที่จะเข้าสู่ระบบและโฆษณาจะได้รับคำขอสำหรับการตรวจสอบความถูกต้องในแบ็กเอนด์ดีซีดังนั้นโฆษณานั้นถูก "เปิดเผย" ... แต่ปลอดภัยด้วย SSL และพร็อกซีผ่านเซิร์ฟเวอร์ Exchange


การอ้างอิง # 1

แนวทางสำหรับการปรับใช้ Windows Server Active Directory บน Windows Azure Virtual Machines

ก่อนที่คุณจะไป "Azure ไม่ใช่โฆษณา" ... คุณสามารถปรับใช้ ADDS บน Azure VM

แต่เพื่อเสนอราคาบิตที่เกี่ยวข้อง:

อย่าเปิดเผย STS โดยตรงกับอินเทอร์เน็ต

ในฐานะที่เป็นแนวปฏิบัติด้านความปลอดภัยที่ดีที่สุดให้วางอินสแตนซ์ STS ไว้หลังไฟร์วอลล์และเชื่อมต่อกับเครือข่ายองค์กรของคุณเพื่อป้องกันไม่ให้เกิดการสัมผัสกับอินเทอร์เน็ต สิ่งนี้มีความสำคัญเนื่องจากบทบาท STS ส่งสัญญาณโทเค็นการรักษาความปลอดภัย ดังนั้นควรได้รับการปกป้องในระดับเดียวกับตัวควบคุมโดเมน หาก STS ถูกโจมตีผู้ใช้ที่ประสงค์ร้ายจะสามารถเข้าถึงโทเค็นการเข้าถึงที่อาจมีการอ้างสิทธิ์ว่าพวกเขาเลือกที่จะใช้แอพพลิเคชั่นปาร์ตี้และเอสทีอื่น ๆ ในองค์กรที่ไว้วางใจ

ดังนั้น ... อย่าเปิดเผยตัวควบคุมโดเมนโดยตรงกับอินเทอร์เน็ต

การอ้างอิง # 2

Active Directory - The UnicodePwd Mystery of AD LDS

การเปิดเผยตัวควบคุมโดเมนไปยังอินเทอร์เน็ตนั้นเป็นเรื่องที่ไม่ดีไม่ว่าการเปิดเผยนั้นมาจากสภาพแวดล้อมการผลิตโดยตรงหรือผ่านเครือข่ายในขอบเขต ทางเลือกที่เป็นธรรมชาติคือการวางเซิร์ฟเวอร์ Windows Server 2008 ด้วยบทบาท Active Directory Lightweight Directory Services (AD LDS) ที่ทำงานในเครือข่ายในขอบเขต

การอ้างอิง # 3 - ไม่ใช่จาก MS ... แต่ยังมีประโยชน์ในการมองไปข้างหน้า

Active Directory-as-a-Service สีฟ้า Intune พูดถึงอนาคตโฆษณาบนคลาวด์

ในท้ายที่สุดไม่มีคำตอบ "สั้น ๆ " ที่ยอดเยี่ยมซึ่งตรงกับเป้าหมายของการทำลายสำนักงานของเซิร์ฟเวอร์ AD เพื่อแลกกับทางเลือก Azure ในขณะที่ Microsoft กำลังให้ความช่วยเหลือลูกค้าในการโฮสต์ Active Directory Domain Services บน Server 2012 และ 2008 R2 ใน Azure ประโยชน์ของพวกเขานั้นดีพอ ๆ กับการเชื่อมต่อ VPN ที่คุณสามารถรวบรวมให้กับพนักงานของคุณ DirectAccess ในขณะที่เทคโนโลยีที่มีแนวโน้มดีมีมือติดอยู่เนื่องจากข้อ จำกัด ที่โชคร้าย

การอ้างอิง # 4

ปรับใช้ AD DS หรือ AD FS และ Office 365 ด้วย single sign-on และ Windows Azure Virtual Machines

ตัวควบคุมโดเมนและเซิร์ฟเวอร์ AD FS ไม่ควรสัมผัสโดยตรงกับอินเทอร์เน็ตและควรเข้าถึงได้ผ่าน VPN เท่านั้น


นี่เป็นคำตอบที่สมเหตุสมผลแม้ว่าการอ้างอิงแรกเท่านั้นที่พูดถึงสิ่งที่อาจเกิดขึ้นได้หากคุณไม่ปฏิบัติตามคำแนะนำ
Casey

19

Active Directory (AD) ไม่ได้ออกแบบมาสำหรับการปรับใช้แบบนั้น

รูปแบบการคุกคามที่ใช้ในการออกแบบผลิตภัณฑ์จะถือว่ามีการปรับใช้ "behind-the-firewall" โดยมีนักแสดงที่เป็นศัตรูจำนวนหนึ่งถูกกรองที่ชายแดนเครือข่าย ในขณะที่คุณสามารถทำให้ Windows Server แข็งแกร่งต่อการสัมผัสกับเครือข่ายสาธารณะการทำงานที่ถูกต้องของ Active Directory นั้นต้องใช้ท่ารักษาความปลอดภัยที่เข้มงวดกว่าโฮสต์ที่ใช้งานเครือข่ายสาธารณะ บริการจำนวนมากต้องได้รับการเปิดเผยจาก Domain Controller (DC) เพื่อให้ AD ทำงานได้อย่างถูกต้อง

ข้อเสนอแนะของ Zoredache ในความคิดเห็นโดยเฉพาะอย่างยิ่งการอ้างอิงบางอย่างเช่น OpenVPN ที่ทำงานเป็นบริการตรวจสอบใบรับรอง / เครื่องที่ครอบคลุมทั้งเครื่องอาจเป็นสิ่งที่ดี DirectAccess ดังที่คนอื่น ๆ พูดถึงเป็นสิ่งที่คุณต้องการยกเว้นว่าไม่มีการสนับสนุนข้ามแพลตฟอร์มที่คุณต้องการ

นอกเหนือจากนี้: ฉันเคยคิดที่จะใช้ IPSec โหมดการขนส่งตามใบรับรองเพื่อแสดงโฆษณาโดยตรงกับอินเทอร์เน็ต แต่ไม่เคยมีเวลาทำ Microsoft ทำการเปลี่ยนแปลงในกรอบเวลา Windows Server 2008 / Vista ที่คาดคะเนว่าเป็นไปได้ แต่ฉันไม่เคยออกกำลังกายเลย


2
+1 สำหรับ OpenVPN ที่ทำงานเป็นบริการฉันเคยใช้วิธีการนี้กับนักรบถนนสำเร็จในอดีต มีความรู้สึกที่หลากหลายจากผู้ดูแลระบบ SR sys โดยเฉพาะอย่างยิ่งเพราะหากเครื่องถูกบุกรุกแล้วนั่นเป็นแบ็คดอร์อัตโนมัติในเครือข่าย ความกังวลที่ถูกต้องแน่นอนสำหรับแต่ละสภาพแวดล้อม แต่ต้องถามตัวเองว่าผลประโยชน์มีความเสี่ยงมากกว่าหรือไม่?
MDMoore313

2
Microsoft ใช้เครือข่ายองค์กรของตนเองบนอินเทอร์เน็ตสาธารณะด้วย IPSec ดังนั้นจึงทำได้
Michael Hampton

1
@MichaelHampton แต่ใช้การแยกโดเมนกับ Windows Firewall และ IPSec ดังนั้นจึงไม่ใช่ "โฆษณาบนอินเทอร์เน็ต" นั่นคือ "โฆษณาบนอินเทอร์เน็ตและในโซนความปลอดภัยคล้ายกับที่ไฟร์วอลล์จะให้บริการโดยใช้กฎไฟร์วอลล์ของโฮสต์แทน"
MDMarra

2
@ MDMoore313 - การเพิกถอนใบรับรอง FTW แม้ว่าผู้ใช้จะต้องรายงานว่าเครื่องถูกขโมยอย่างรวดเร็ว
Evan Anderson

นอกจากนี้ยังมีวิธีที่ไคลเอ็นต์ VPN บางตัว (เช่นจูนิเปอร์) บังคับให้ออกจากระบบหลังจากการเชื่อมต่อ มันไม่ดีเท่า Gina เก่า ๆ แต่มันบังคับให้ผู้ใช้ลงชื่อเข้าใช้อีกครั้งในขณะที่ใช้ VPN เพื่อรับรองความถูกต้องของโฆษณาและรับ GPO ฯลฯ คุณเข้าสู่ระบบก่อนด้วยข้อมูลประจำตัวแคชเปิด VPN หากจำเป็นและ มันจะนำคุณออกทันทีและเชื่อมต่ออยู่ในขณะที่คุณกลับเข้าสู่ระบบ
TheCleaner

15

สิ่งที่คนอื่นพูด โดยเฉพาะอย่างยิ่งฉันกังวลเกี่ยวกับความพยายามดุร้ายคริสโตเฟอร์คาเรลกล่าวถึง งานนำเสนอที่ Def Con ล่าสุดอยู่ในหัวข้อ:

ดังนั้นคุณคิดว่าตัวควบคุมโดเมนของคุณปลอดภัยหรือไม่

JUSTIN HENDRICKS วิศวกรรักษาความปลอดภัยไมโครซอฟท์

Domain Controllers เป็นมงกุฎเพชรขององค์กร เมื่อพวกเขาล้มลงทุกอย่างในโดเมนก็จะตก องค์กรต่างๆต้องใช้ความพยายามอย่างมากในการรักษาความปลอดภัยของตัวควบคุมโดเมนอย่างไรก็ตามพวกเขามักจะล้มเหลวในการรักษาความปลอดภัยซอฟต์แวร์ที่ใช้ในการจัดการเซิร์ฟเวอร์เหล่านี้อย่างเหมาะสม

งานนำเสนอนี้จะครอบคลุมวิธีการที่ไม่เป็นทางการสำหรับการดึงดูดผู้ดูแลระบบโดเมนด้วยการใช้ซอฟต์แวร์การจัดการที่ใช้กันทั่วไปที่องค์กรใช้และใช้งานในทางที่ผิด

Justin Hendricks ทำงานกับทีมรักษาความปลอดภัย Office 365 ซึ่งเขามีส่วนร่วมในการทำงานเป็นทีมสีแดงการทดสอบการเจาะการวิจัยด้านความปลอดภัยการตรวจสอบรหัสและการพัฒนาเครื่องมือ

ฉันแน่ใจว่าคุณสามารถหาตัวอย่างอื่น ๆ อีกมากมาย ฉันกำลังมองหาบทความเกี่ยวกับตัวควบคุมโดเมนและการแฮ็คโดยหวังว่าจะได้คำอธิบายว่า DC จะพบได้เร็วแค่ไหนเป็นต้น แต่ฉันคิดว่าจะทำได้ในตอนนี้


1
นี่คือวิดีโอของการนำเสนอของ Mr. Hendricks: youtube.com/watch?v=2d_6jAF6OKQ ฉันต้องการดูวิดีโอ DefCon 21 และฉันคิดว่าฉันจะเริ่มด้วยสิ่งนี้
Evan Anderson

14

หากคุณพยายามโน้มน้าวให้ผู้บริหารเริ่มต้นที่ดีก็คือ:

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

อัปเดต : ดูบทความด้านเทคนิคเกี่ยวกับการรักษาความปลอดภัยของตัวควบคุมโดเมนจากการถูกโจมตีและส่วนที่มีชื่อว่าPerimeter Firewall Restrictions:

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

และหัวข้อ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

ฉันแน่ใจว่าคุณสามารถตีพิมพ์เอกสารของ Microsoft เกี่ยวกับเรื่องนี้ได้ นอกจากนั้นคุณสามารถระบุอันตรายของการเคลื่อนไหวดังกล่าวซึ่งเป็นไปตาม:

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

ข้อมูลรับรองแคชเป็นแบบนั้น - แคช พวกเขาทำงานกับเครื่องในพื้นที่เมื่อไม่สามารถเชื่อมต่อกับโดเมนได้ แต่หากบัญชีนั้นถูกปิดใช้งานพวกเขาจะไม่ทำงานกับทรัพยากรเครือข่ายใด ๆ (svn, vpn, smb, fbi, cia ฯลฯ ) ดังนั้นพวกเขาจึงไม่ต้องกังวลเกี่ยวกับเรื่องนั้น . โปรดจำไว้ว่าผู้ใช้มีสิทธิ์เต็มที่ในไฟล์ใด ๆ ในโฟลเดอร์โพรไฟล์ของพวกเขาในเครื่องท้องถิ่น (และสื่อที่ถอดได้) น่าจะปิดการใช้งานข้อมูลประจำตัวหรือไม่พวกเขาสามารถทำสิ่งที่พวกเขาพอใจกับข้อมูลนั้น พวกเขายังไม่สามารถใช้งานได้กับเครื่องท้องถิ่นเมื่อเชื่อมต่อกับเครือข่ายอีกครั้ง

คุณหมายถึงบริการที่ Active Directory หรือ Domain Controller ให้เช่น LDAP หรือไม่? ถ้าเป็นเช่นนั้น LDAP มักจะถูกแยกออกอย่างปลอดภัยเพื่อวัตถุประสงค์ในการรับรองความถูกต้องและการสืบค้นไดเรกทอรี แต่เพียงปิดไฟร์วอลล์ Windows (หรือเปิดพอร์ตที่จำเป็นทั้งหมดสู่สาธารณะ - สิ่งเดียวกันในตัวอย่างนี้) อาจทำให้เกิดปัญหาร้ายแรง

โฆษณาไม่ได้จัดการ Macs อย่างแท้จริงดังนั้นจึงจำเป็นต้องใช้โซลูชันแยกต่างหาก (คิดว่า OS X Server) คุณสามารถเข้าร่วม Mac กับโดเมน แต่ทำได้น้อยกว่าปล่อยให้พวกเขารับรองความถูกต้องกับเครือข่ายข้อมูลประจำตัวตั้งค่าผู้ดูแลระบบโดเมนเป็นผู้ดูแลท้องถิ่นบน mac ฯลฯ ไม่มีนโยบายกลุ่ม MS กำลังพยายามฝ่าฝืนเรื่องนั้นด้วย SCCM เวอร์ชันใหม่ที่อ้างว่าสามารถปรับใช้แอพพลิเคชั่นให้กับ mac และกล่อง * nix แต่ฉันยังไม่เห็นมันในสภาพแวดล้อมการใช้งานจริง ฉันยังเชื่อว่าคุณสามารถกำหนดค่าแม็คเพื่อเชื่อมต่อกับ OS X Server ซึ่งจะรับรองความถูกต้องกับไดเรกทอรีโฆษณาของคุณ แต่ฉันอาจผิด

ดังที่ได้กล่าวไปแล้วว่าอาจมีการคิดแก้ปัญหาที่สร้างสรรค์เช่น Evan แนะนำให้ใช้ OpenVPN เป็นบริการและปิดการใช้งานเครื่องใบรับรองหาก / เมื่อถึงเวลาที่พนักงานต้องไป

ดูเหมือนว่าทุกอย่างเป็นของ Google ดังนั้น Google จึงทำหน้าที่เป็นเซิร์ฟเวอร์ ldap ของคุณหรือไม่ ฉันอยากจะแนะนำให้ลูกค้าของฉันทำอย่างนั้นถ้าเป็นไปได้ ฉันไม่ทราบลักษณะธุรกิจของคุณ แต่สำหรับแอปที่ใช้เว็บเช่นเซิร์ฟเวอร์คอมไพล์หรือเซิร์ฟเวอร์ Redmine แม้ว่าการติดตั้งในบ้านจะสามารถรับรองความถูกต้องกับ OAuth ได้โดยใช้ประโยชน์จากบัญชี Google

ท้ายสุดการตั้งค่า Roadwarrior เช่นนี้เกือบจะต้องใช้ VPN เพื่อให้สำเร็จ เมื่อเครื่องถูกนำเข้ามาในสำนักงานและกำหนดค่า (หรือกำหนดค่าจากระยะไกลผ่านสคริปต์) พวกเขาต้องการวิธีรับการเปลี่ยนแปลงใด ๆ ในการกำหนดค่า

แม็คจะต้องใช้วิธีการจัดการที่แยกต่างหากนอกเหนือจาก VPN มันแย่เกินไปที่พวกเขาจะไม่สร้างเซิร์ฟเวอร์ mac จริงอีกต่อไป แต่พวกเขามีการใช้นโยบายที่เหมาะสมใน OS X Server ครั้งสุดท้ายที่ฉันตรวจสอบ (สองสามปีที่ผ่านมา )


อันที่จริงCentrifyถูกใช้งานในสภาพแวดล้อมนี้เพื่อจัดการนโยบายบนระบบ Mac จำนวนหนึ่งในขณะนี้
ewwhite

@ ขาวคุณหมายถึงอะไรโดยการจัดการ ดูเหมือนว่าไม่มีอะไรมากไปกว่ายูทิลิตี้การตรวจสอบสิทธิ์กลาง
MDMoore313

@ MDMoore313 คุณมาช้ากว่าสองสามชั่วโมงฉันชนะ: chat.stackexchange.com/transcript/127?m=13626424#13626424 - :)
TheCleaner

@TheCleaner ฮ่าฮ่ามันปรากฏขึ้นแล้วคุณชนะในครั้งนี้คุณรู้ศิลปะของ Google Fu ได้ดี แต่เทคนิคของคุณจะทำให้คุณเข้าใจในกังฟูที่ดีที่สุดของฉัน หลังจากที่คุณโพสต์คำตอบของคุณฉันต้องค้นหาอย่างหนักเป็นสองเท่าเพื่อค้นหาคำที่ไม่ซ้ำกับคุณ!
MDMoore313

2
ฮ่า ๆ ไม่ต้องกังวล ... ครั้งต่อไปที่เราพบกับชัยชนะอาจเป็นของคุณ (ด้วยเสียงคำพูดที่น่ากลัว)
TheCleaner

7

เป็นเรื่องน่าเสียดายที่ DirectAccess นั้นมีเฉพาะใน Win7 + Enterprise Edition เท่านั้นเนื่องจากได้รับการปรับแต่งตามคำขอของคุณ แต่ไม่รู้จักรุ่นของคุณและเห็นว่าคุณมี MacOS นั่นจะไม่ทำงาน

/ แก้ไข - ดูเหมือนว่าบุคคลที่สามอ้างว่าพวกเขามีลูกค้า DA สำหรับ Unices: http://www.centrify.com/blogs/tomkemp/what_is_microsoft_directaccess_and_unix_linux_interoperability.asp

มีโซลูชั่น MDM ที่สามารถทำงานเพื่อตอบสนองความต้องการของคุณ เรากำลังเปิดตัวหนึ่งในนั้น (MAAS360) ออกไปยังลูกค้าที่อยู่ในตำแหน่งที่คล้ายกัน


5

เห็นได้ชัดว่าเป็นความเสี่ยงด้านความปลอดภัยที่สำคัญ นอกจากนี้มันอาจจะไม่ทำงานตามที่คุณต้องการ หากคนที่สุ่มบนอินเทอร์เน็ตสามารถลองเข้าสู่ระบบโฆษณาของคุณได้โอกาสที่ผู้ใช้ทั้งหมดของคุณจะถูกล็อค ตลอดไป และการลบข้อกำหนดการปิดหมายความว่าการได้รับรหัสผ่านอย่างง่ายนั้นค่อนข้างง่าย

ที่สำคัญคุณไม่ควรมีปัญหาในการใช้งานเป้าหมายของคุณ (ผู้ใช้ปลายทางลงชื่อเข้าใช้แล็ปท็อปที่มีข้อมูลรับรองโดเมน) โดยไม่ต้องเข้าถึงเซิร์ฟเวอร์โฆษณาโดยตรง เครื่อง Windows สามารถแคชการเข้าสู่ระบบ X ที่สำเร็จครั้งล่าสุดเพื่อให้ข้อมูลประจำตัวเหล่านั้นทำงานเมื่อตัดการเชื่อมต่อ ซึ่งหมายความว่าผู้ใช้สามารถลงชื่อเข้าใช้และทำงานที่มีประโยชน์โดยไม่จำเป็นต้องแตะเซิร์ฟเวอร์โฆษณาของคุณ เห็นได้ชัดว่าพวกเขาจะต้องใช้ VPN เพื่อเชื่อมต่อกับทรัพยากรขององค์กรสำคัญอื่น ๆ และสามารถรีเฟรชการตั้งค่า AD / GPO ได้ในเวลาเดียวกัน


2
โฆษณาไม่ได้ใช้การออกอากาศ (หรืออย่างน้อยก็ขึ้นอยู่กับ) เพื่ออะไรก็ตามตราบใดที่โฆษณานั้นเป็นความรู้ของฉัน เทคโนโลยีบางอย่างอาจต้องการ WINS ซึ่งสามารถถอยกลับไปยังคำขอออกอากาศหากไม่มีเซิร์ฟเวอร์ WINS แต่ก็ไม่เกี่ยวข้องกับโฆษณาโดยทั่วไป ถ้ามันขึ้นอยู่กับการออกอากาศคุณไม่สามารถมีผู้ใช้ระยะไกลที่ไม่มี DC ท้องถิ่นได้เลย
mfinni

2
แก้ไขบรรทัดนั้น ขอบคุณสำหรับการป้อนข้อมูล Cllearly คนที่แต่งตัวประหลาด Linux เช่นฉันไม่ควรเป็นแขกบน Windows
Christopher Karel

หากเป็นเช่นนั้น "ชัดเจน" จะไม่เป็นคำถามใช่หรือไม่
Casey

2

Ewwhite,

คำถามของคุณมีความถูกต้องเป็นอย่างยิ่งและควรได้รับการพิจารณาอย่างรอบคอบ

ผู้เชี่ยวชาญด้านความปลอดภัยทั้งหมดแนะนำเลเยอร์ความปลอดภัยหน้าทรัพยากรเครือข่ายใด ๆ รวมถึง SPI ไฟร์วอลล์ IDS ไฟร์วอลล์ตามโฮสต์ ฯลฯ คุณควรใช้พร็อกซีปริมณฑลไฟร์วอลล์เกตเวย์เช่น ISA (ตอนนี้ TMG) ​​เมื่อเป็นไปได้

ที่กล่าวว่า Microsoft Active Directory 2003+ ไม่มีช่องโหว่ที่สำคัญที่เปิดเผยต่อสาธารณะ เทคโนโลยี LDAP และอัลกอริธึมการแฮชนั้นมีความปลอดภัยเป็นอย่างมาก เนื้อหามีความปลอดภัยมากกว่า SSL VPN หาก SSL VPN นั้นเรียกใช้ OpenSSL และมีความเสี่ยงที่จะเกิดอาการหัวใจวาย

ฉันจะเตือน 5 สิ่ง:

  1. มีความกังวลเกี่ยวกับบริการอื่น ๆ ที่เผชิญกับเครือข่ายเช่น Terminal Server, บริการ DNS, CIFS และ IIS โดยเฉพาะอย่างยิ่งกับบันทึกความปลอดภัยที่น่ากลัว

  2. ใช้ LDAPS พร้อมใบรับรองความปลอดภัยเพื่อหลีกเลี่ยงการส่งข้อมูลรับรองโดเมนข้อความผ่านสาย สิ่งนี้จะเกิดขึ้นโดยอัตโนมัติหลังจากติดตั้ง Certificate Services (ใช้เครื่องแยกต่างหากสำหรับ PKI)

  3. วางแพ็กเก็ตดมกลิ่นบนอินเทอร์เฟซและดูปริมาณการใช้งานของคุณแก้ไขรหัสผ่านข้อความใด ๆ ที่ชัดเจนเนื่องจากไฟร์วอลล์หรือไม่ถ้าคุณไม่ได้ใช้ VPN หรือ LDAPS บางระบบดั้งเดิมจะส่งรหัสผ่านข้อความที่ชัดเจน

  4. รู้ว่าการโจมตี MITM สามารถบังคับกลไกการพิสูจน์ตัวตนดั้งเดิมเพื่อดาวน์เกรดและเปิดเผยรหัสผ่านเพื่อการพิสูจน์ตัวตน NTLM ที่อ่อนแอกว่า

  5. ระวังช่องโหว่การแจงนับผู้ใช้ที่อาจยังคงมีอยู่

ดังกล่าว Active Directory มีประวัติที่ดีสำหรับความปลอดภัย นอกจากนี้ MS Active Directory ไม่ได้จัดเก็บรหัสผ่านเพียงแฮชซึ่งอาจบรรเทาความรุนแรงของการประนีประนอม

คุณอาจได้รับประโยชน์จากโครงสร้างพื้นฐานความปลอดภัยที่ไร้รอยต่อคุณไม่ต้องตั้งเซิร์ฟเวอร์ DNS พิเศษหรือใช้ domain.local และคุณสามารถใช้โดเมนจริงของคุณบนอินเทอร์เน็ตสาธารณะเช่น domain.com

ในความเห็นของฉันมีประโยชน์อย่างมากในการปรับใช้เทคโนโลยีความปลอดภัยเช่น Active Directory ในที่สาธารณะซึ่งเทคโนโลยีอื่น ๆ เช่น Exchange และ DNS และ Web Servers ก็ไม่ได้ให้ประโยชน์และความเสี่ยงทั้งหมด

หมายเหตุ: หากคุณปรับใช้ Active Directory จะมีเซิร์ฟเวอร์ DNS เป็น CERTAIN เพื่อปิดการใช้งานการเรียกซ้ำบนเซิร์ฟเวอร์ DNS ของคุณ (เปิดใช้งานตามค่าเริ่มต้น) หรือคุณจะเข้าร่วมในการปฏิเสธการโจมตีบริการอย่างแน่นอน

ไชโย

ไบรอัน


-3

Dell (ผ่านการซื้อ Quest (ผ่านการซื้อ Vintela)) มีโซลูชันข้ามแพลตฟอร์มที่ใช้งานบ่อยในองค์กร F500 เพื่อจุดประสงค์นี้

สิ่งที่ต้องพิจารณา ...

  1. ผู้ใช้ของคุณเชื่อมต่ออยู่เสมอหรือไม่? ถ้าเป็นเช่นนั้นคุณจะได้รับบริการที่ดีที่สุดด้วยสภาพแวดล้อมการโฮสต์บน VM ที่ยืดหยุ่นซึ่งสามารถยืดหยุ่นได้เมื่อผู้ใช้จำนวนมากกำลังใช้งาน LDAP
  2. คุณกำลังใช้งานศูนย์ข้อมูลทางกายภาพมากกว่าหนึ่งแห่งหรือไม่ พิจารณาการทำโหลดบาลานซ์ทางภูมิศาสตร์หน้าบริการโฆษณาเพื่อลดจำนวนการกระโดดข้ามระหว่างผู้ใช้และระบบของคุณ
  3. นอกจากนี้หากคำตอบของ # 2 คือใช่ให้แน่ใจว่าคุณตั้งค่าทรัพยากรเครือข่ายเฉพาะเพื่อทำซ้ำฟอเรสต์ของคุณตามที่อธิบายไว้ที่นี่

และตรวจสอบให้แน่ใจว่าโซลูชันไฟร์วอลล์ของคุณสามารถจัดการอัตราการส่งซ้ำสูงมากหากคุณมีผู้ใช้งานในการเชื่อมต่อแบบควบคุมปริมาณการเชื่อมต่อจากศูนย์ wifi ที่มีเสียงดัง ฯลฯ


สิ่งนี้จัดการกับเครื่อง Windows หรือรักษาความปลอดภัยเช่น DC ที่ได้รับจากอินเทอร์เน็ต มันไม่ได้อ่านเหมือนที่เคยทำ
mfinni
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.