Thiết kế Active Directory OU cho <500 người dùng, 4 vị trí


8

Chúng tôi đang tìm cách thêm một số cấu trúc logic vào hệ thống phân cấp AD (Win 2003) của chúng tôi. Chúng tôi có một tên miền duy nhất và khoảng 500 người dùng. Tất cả người dùng và máy tính hiện đang được tổ chức thành một OU. Tất cả các nhóm bảo mật và phân phối nằm trong OU thứ hai. Thành viên nhóm về cơ bản là trên cơ sở người dùng cá nhân không có nhóm lồng nhau.

Những câu hỏi của tôi:

  1. Đối với một tổ chức có kích thước này, có đáng để mô tả phân cấp các OU dựa trên bộ phận, địa lý và / hoặc lớp đối tượng (ví dụ: máy tính, người dùng, nhóm) và chuyển người dùng, máy tính và nhóm vào các OU liên quan?
  2. Nếu vậy, làm thế nào bạn sẽ cấu trúc hệ thống phân cấp, ví dụ: bộ phận-> vị trí-> lớp đối tượng?
  3. Chúng ta có nên lồng các nhóm, khi thích hợp, để ánh xạ tốt hơn tới vai trò ứng dụng doanh nghiệp và các mục nhập địa chỉ Exchange?

Câu trả lời:


10

Dưới đây là các nguyên lý cốt lõi của khuyến nghị của Microsoft về thiết kế logic AD:

  • Thiết kế đầu tiên cho ủy quyền kiểm soát, bởi vì đó dựa trên quyền AD và là trục không linh hoạt nhất để sửa đổi. Nếu bạn không thực hiện ủy quyền kiểm soát thì đừng lo lắng về điều này (nhưng dù sao tôi cũng có kế hoạch cho nó - ngay cả trong một tổ chức nhỏ mà bạn có thể cần cho người dùng được chỉ định trong văn phòng chi nhánh để có thể đặt lại mật khẩu, Vân vân).

  • Thiết kế thứ hai để áp dụng chính sách nhóm. Lọc ứng dụng chính sách nhóm theo tư cách thành viên nhóm bảo mật cho phép GPO chỉ áp dụng cho một tập hợp con của người dùng hoặc đối tượng máy tính bên dưới điểm được liên kết trong thư mục, do đó trục này có độ linh hoạt hơn so với quyền AD.

  • Thiết kế cuối cùng cho tổ chức và dễ sử dụng. Giúp bạn dễ dàng tìm thấy những thứ cho bản thân và các quản trị viên khác.

Hãy suy nghĩ về từng cân nhắc khi bạn thiết kế, ưu tiên chúng theo khuyến nghị. Thật dễ dàng để thay đổi mọi thứ sau này (một cách tương đối), và bạn sẽ không bao giờ "làm cho đúng" trong lần thử đầu tiên. Trước khi tôi thậm chí DCPROMO, bộ điều khiển miền đầu tiên của tôi, tôi thường vẽ ra cấu trúc được đề xuất trên giấy hoặc bảng trắng và xem qua các kịch bản sử dụng tiềm năng để xem liệu thiết kế của tôi có "giữ vững" không. Đó là một cách tuyệt vời để giải quyết các vấn đề trong thiết kế.

(Đừng quên ứng dụng chính sách nhóm trên các đối tượng trang web. Bạn phải cẩn thận về ứng dụng GPO tên miền chéo khi bạn liên kết GPO tại các trang web, nhưng nếu bạn là một môi trường tên miền duy nhất, bạn có thể nhận được rất nhiều điều tuyệt vời Chức năng của việc liên kết GPO với các trang web. Làm việc với một số tình huống mẫu với nó-- Tôi thấy rằng thật tuyệt vời khi tải phần mềm có cài đặt "dành riêng cho trang web" hoặc cung cấp tập lệnh đăng nhập cụ thể cho người dùng khi đăng nhập vào máy tính. vị trí thực tế, bằng cách xử lý chính sách nhóm loopback.)


Bạn có thể đưa ra một ví dụ về một cấu trúc đơn giản mà bạn sẽ thực hiện với những thực tiễn tốt nhất này không?
TechGuyTJ

2
Không có nhiều gõ. Có lẽ tôi có thể đăng một trong những câu đố từ khi tôi dạy các lớp thiết kế Active Directory cùng với nỗ lực trả lời. Mặc dù hiện tại, công việc đang đánh bại tôi và tôi không có nhiều thời gian Lỗi Máy chủ. Tôi sẽ gắn cờ này và xem liệu tôi có thể quay lại không.
Evan Anderson

3

Tôi luôn chia người dùng, máy tính và nhóm thành các OU riêng biệt, vì lý do đơn giản là nó giúp quản lý dễ dàng hơn.

Nếu bạn không có lý do thuyết phục cho một cấu trúc AD cụ thể, thì hãy thiết kế AD của bạn theo quan điểm quản trị. Hãy suy nghĩ về nơi bạn sẽ áp dụng các chính sách.

Nếu bạn đang áp dụng hầu hết các chính sách của mình ở cấp bộ phận, hãy sử dụng Bộ \ Vị trí \ Đối tượng

Nếu bạn đang áp dụng hầu hết các chính sách của mình ở cấp vị trí, hãy sử dụng Location \ Department \ Object

Nếu bạn đã làm theo cách khác, điều đó có nghĩa là bạn sẽ phải liên kết các chính sách của mình tại nhiều OU, liên quan đến công việc không cần thiết.

Các nhóm làm tổ là hoàn toàn tốt, và một lần nữa, làm cho việc quản lý AD dễ dàng hơn nhiều.

Tôi có xu hướng thiết kế các cấu trúc AD với ý tưởng 'làm cho nó dễ quản lý' hơn là phản ánh cấu trúc công ty vật lý, tuy nhiên cả hai thường giống nhau.


Mặc dù vậy, hãy nhớ rằng, dù bạn thiết kế cấu trúc AD tốt đến đâu, họ sẽ luôn là một ngoại lệ :-)
Tubs

3

Tôi nghĩ rằng, nếu tôi phải thiết kế lại AD của mình một lần nữa, có một vài điều tôi sẽ làm khác đi, nhưng tôi đã thấy rằng:

Người dùng - Chia luận án thành các phòng ban, nhưng cũng có diện tích / s cho nhân viên tạm thời hoặc nhân viên đại lý. Vị trí cho những thứ này sẽ không quan trọng bằng việc mọi người sẽ di chuyển.

Máy tính - Chia chúng thành các vị trí và vị trí phụ. Tức là OfficeComputers / LondonOffice / Room103 (Tài chính). Điều này có nghĩa là bạn có thể áp dụng cài đặt cho một vị trí hoặc văn phòng - ví dụ: máy chủ proxy khác hoặc cài đặt chống vi-rút khác nhau (tất nhiên chỉ khi chương trình quản lý AV sử dụng AD) - mà không cần tổ chức lại và hy vọng sẽ không phải mở có thể của sâu được xử lý loopback.

Tôi cũng thấy hữu ích khi không sử dụng nhóm người dùng hoặc máy tính tích hợp, không phải bất kỳ vấn đề kỹ thuật nào, nhưng chỉ để bạn có thể dễ dàng nhìn thấy những thứ không nên có.

Cuối cùng, cũng phân tách máy chủ của bạn, tôi đã chọn vị trí / vai trò có vẻ như đã hoạt động khá tốt.


2

Như đã trả lời, đây là ví dụ của tôi, hãy nhớ rằng bạn không có đúng hay sai, tất cả phụ thuộc vào nhu cầu - tức là tổ chức hoặc địa điểm trước? Tôi thích vai trò tổ chức đầu tiên ngay cả đối với vai trò máy tính / máy chủ. Tôi cũng thích khả năng chỉ ra một OU duy nhất để có được tất cả nhân viên và không có rác để điền vào danh sách nhân viên mạng nội bộ từ đó. Hãy chỉnh sửa!

  • Người (người dùng / loại = người)
    • Nội bộ
      • Khoa A
        • Vị trí X
        • Vị trí Y
      • Khoa B
      • Khoa C
    • Bên ngoài
      • Công ty 1
      • Công ty 2
  • Máy (người dùng / loại = bất kỳ bao gồm cả máy tính)
    • Khách hàng
      • Máy tính xách tay
      • Máy tính để bàn
    • Người phục vụ
      • Ứng dụng
        • Vị trí T
        • Vị trí V
      • Cơ sở hạ tầng
      • Cơ sở dữ liệu
    • Dịch vụ
    • Tài khoản quản trị (nếu được sử dụng)
  • Danh sách (nhóm và liên hệ)
    • Tiếp xúc
    • Phân phối
    • Bảo vệ

@Oskar - cảm ơn vì ví dụ Tôi nghĩ bạn có nghĩa là Máy (tài khoản máy tính) chứ không phải Máy (tài khoản người dùng).
EFT

Chà, thực ra không phải là một sản phẩm tốt .. Tôi nghĩ rằng tôi có nghĩa là "tài khoản người dùng" nói chung (đối với tài khoản máy tính, tài khoản dịch vụ, v.v.), trái ngược với các nhóm hoặc liên hệ ... đã được sửa
Oskar Duveborn

Tôi hiểu ý của bạn lúc này - cảm ơn vì đã làm rõ
vào

0

Tôi chỉ cần chia chúng theo vị trí trong trường hợp này. Cấu trúc OU kết quả sẽ trông giống như thế này:

Location1
-Computers
-Groups
-Users

Location2
-Computers
-Groups
-Users

Vân vân.

Tôi thực sự không thấy bất kỳ nhu cầu nào cho các bộ phận tiếp theo ở đây, ví dụ như của Bộ, vì nó sẽ tạo thêm chi phí quản trị viên mà không thực sự mang lại nhiều lợi nhuận. Tuy nhiên, việc phân chia theo vị trí sẽ cho phép bạn triển khai ủy quyền tại mỗi trang web.


0

Một dòng hướng dẫn tôi sử dụng là: Người dùng; tổ chức theo Nhóm biểu đồ nhân sự; tổ chức theo quy trình làm việc Máy tính; tổ chức theo vị trí địa lý

Các câu trả lời khác trong chủ đề này là rất tốt mặc dù.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.