Không thể cấp quyền 'gửi dưới dạng' trong Exchange 2010


11

Tôi đang cố gắng cấp quyền 'gửi dưới dạng' cho một người dùng trong Exchange 2010. Đây là lệnh Powershell tôi đang chạy:

Add-ADPermission "User1" -User "Ourdomain\User2" -Extendedrights "Send As"

Powershell trả về lỗi này:

Hoạt động Active Directory không thành công trên DC.OurDomain.pri. Lỗi này không thể truy xuất được. Thông tin bổ sung: Truy cập bị từ chối. Phản hồi thư mục hoạt động: 00000005: SecErr: DSID-031521D0, vấn đề 4003 (vấn đề 4003 (INSUFF_ACCESS_RIGHTS), dữ liệu 0 + CategoryInfo: WriteError: (0: Int32) [Add-ADPermission], ADOperationEx AddADPermission

Tôi đã thử nhiều lựa chọn thay thế cho lệnh Powershell - tức là. sử dụng -Identity, v.v., nhưng điều đó và trình hướng dẫn EMC đều trả về cùng một lỗi.

Tôi không chắc chắn liệu "INSUFF_ACCESS_RIGHTS" đang đề cập đến tôi, người đang chạy lệnh hay người dùng tôi đang trao quyền gửi cho?

Tôi đã theo dõi trang web "Quản lý gửi dưới dạng quyền cho hộp thư" của Microsoft Technet tại đây: http://technet.microsoft.com/en-us/l Library / bb676368.aspx

Vì vậy, đã thêm hai quyền bạn cần để làm điều này:

Quản lý tổ chức

Quản lý người nhận

Nhưng điều đó không có ích. Có ý kiến ​​gì không?

Cập nhật

Nếu tôi làm như sau:

  • mở "Người dùng và máy tính quảng cáo" với chế độ xem "Tính năng nâng cao"
  • Chuyển đến thuộc tính của User1
  • Nhấn "Nâng cao" trên tab Bảo mật
  • Chọn "Thêm"
  • nhập vào "User2" và chọn "Gửi dưới dạng" Cho phép

Điều đó hoạt động, nếu tôi đóng ADUaC và mở lại và kiểm tra lại các quyền mới thì chúng vẫn còn đó. Nếu tôi quay lại khoảng 10 phút sau thì các quyền đó đã biến mất - user2 hoàn toàn không hiển thị trong các quyền bảo mật của user1.

Đừng nghĩ rằng tôi đã từng thấy loại hành vi AD này trước đây.


1
Người dùng1 có phải là người dùng đặc quyền bởi bất kỳ cơ hội nào (ví dụ: Quản trị viên tên miền, Quản trị viên doanh nghiệp, Nhà điều hành tài khoản)?
Ben Pilbrow

Không, họ chỉ là thành viên của Người dùng tên miền và Nhà điều hành in.
Kieran Walsh

1
Ah, các nhà khai thác in là một trong những nhóm được bảo vệ. Tôi không ở vị trí để cập nhật câu trả lời của mình vào lúc này - xin chào vài giờ. Trong lúc này, tôi nghi ngờ vấn đề của bạn có liên quan đến chủ đề adminSDHolder - Google rằng nếu bạn muốn biết thêm thông tin, nhưng đừng làm gì phát ban! Tôi đề nghị bài viết tuyệt vời này cho một số chi tiết tốt.
Ben Pilbrow

Phải - Tôi chưa bao giờ nghe nói về adminSDHolder trước đây. Tôi đã thử xóa người dùng khỏi Toán tử in, nhưng lệnh Powershell không thành công tại cùng một nơi.
Kieran Walsh

Câu trả lời:


8

Cuối cùng tôi đã sửa cái này.

Thú vị gửi là một quyền AD - không phải là quyền trao đổi như bạn có thể mong đợi.

Dù sao, đây là các bước:

Làm cho hộp thư đích "có thể chia sẻ" bằng cách sử dụng lệnh này trong Powershell trên Exchange Server của bạn:

Set-Mailbox user1 -type:shared

Nếu bạn gặp lỗi này (giống như trong bài viết đầu tiên của tôi): Thất bại

Bạn sẽ cần tìm người dùng đó trong AD và đi đến các thuộc tính >> Bảo mật >> Nâng cao:

Thuộc tính quảng cáo

Bạn cần ENABLE tùy chọn "Bao gồm các quyền kế thừa từ cha mẹ của đối tượng này":

nhập mô tả hình ảnh ở đây

Khi đã xong, bạn sẽ có thể hoàn thành tập lệnh chia sẻ thư mục.

Sau đó, thực sự cấp các quyền bằng cách sử dụng lệnh này:

Add-ADPermission user1 -User Ourdomain\User2 -ExtendedRights "Send As"

Hy vọng rằng sẽ giúp những người khác có cùng một vấn đề.

Kieran


Lưu ý: Để xem tab "bảo mật" trong thuộc tính của người dùng, trước tiên bạn cần bật xem các tùy chọn nâng cao trong menu.
Andreas Reiff

4

Truy cập các tin nhắn bị từ chối thường đến từ tài khoản chạy phiên PowerShell không có đủ quyền. Tôi nhận được điều này mọi lúc khi tôi chỉ khởi chạy Exchange Management Shell thay vì chạy như tài khoản người dùng quản trị của mình.

Theo cập nhật của bạn, điều tôi nghi ngờ có thể xảy ra là User1 là một phần của nhóm được bảo vệ (Nhà khai thác in) vì vậy Exchange không cho phép bạn cấp Send As trên User2 vì nó biết rằng nó sẽ chỉ bị gỡ bỏ trong giờ tiếp theo. Có vẻ như bạn đã xác nhận lý thuyết đó bằng cách thêm thủ công Send As bằng cách sử dụng ADUC và thấy nó bị lấy đi một thời gian ngắn sau đó.

Trên Bộ điều khiển miền chạy vai trò FSMO Trình mô phỏng PDC, mỗi giờ một thứ gọi là luồng adminSDHolder chạy. Điều này thực hiện là lấy tất cả các tài khoản (hoặc đã từng tồn tại, ngay cả khi chúng đã bị xóa sau đó) trong các nhóm được bảo vệ (Quản trị viên doanh nghiệp, Quản trị viên tên miền, Nhà điều hành tài khoản, Nhà điều hành in để đặt tên cho một số tài khoản phổ biến hơn) và xóa tất cả quyền được cấp trên các đối tượng và thay thế chúng bằng các quyền được xác định rõ ràng. Ý tưởng là một tài khoản được ủy quyền không thể phá hoại và tước quyền quản trị tên miền của các đặc quyền của họ.

Tôi không hoàn toàn tin rằng bản sửa lỗi cấp phép rõ ràng của bạn sẽ hoạt động và sẽ không được thiết lập lại mỗi giờ, nhưng tôi đã sai trước đây - vì vậy nếu nó làm được thì thật tuyệt! Tuy nhiên, nếu người dùng không cần phải ở trong nhóm Toán tử in, tôi khuyên bạn nên sửa đổi tài khoản của họ bằng Chỉnh sửa ADSI và đặt thuộc tính adminCount thành 0. Sau đó kích hoạt quyền truy cập trên đối tượng người dùng và đặt lại quyền mặc định. Khi bạn đã thực hiện điều đó, hãy thử lại lệnh ghép ngắn Exchange của bạn và với một chút may mắn, nó sẽ hoạt động (rõ ràng là cho đủ thời gian để sao chép AD xảy ra).

Tôi không nghĩ rằng bạn sẽ có thể sửa đổi lệnh ghép ngắn của mình để phù hợp với điều này - như tôi đã nói, tôi tưởng tượng (dù không chắc chắn) rằng nó sẽ không cho phép bạn làm điều đó vì Exchange biết rằng quyền sẽ chỉ bị xóa ngay sau đó và đang cố gắng để tránh sự nhầm lẫn từ phía bạn. Trong các trường hợp "bình thường" (tức là người dùng chuẩn), lệnh ghép ngắn sẽ chỉ hoạt động mà không gặp sự cố vì toàn bộ chuỗi adminSDHolder thậm chí không hoạt động.


CẬP NHẬT: Bài đăng khác của tôi không hoạt động lâu dài như bạn đề xuất. ADSIEdit DO có adminCount được đặt thành 1, vì vậy tôi đã thay đổi thành 0. Sẽ cập nhật thông tin này khi luồng adminSDHolder chạy.
Kieran Walsh

Khoảng 5 giờ sau, thuộc tính ADSIEDIT vẫn được đặt thành 0, nhưng các thay đổi Powershell hoặc EMS của tôi vẫn đưa ra cùng một vấn đề truy cập bị từ chối. :(
Kieran Walsh

1

Bạn đã thấy KB này: Truy cập bị từ chối khi bạn cố gắng cấp cho người dùng quyền "gửi dưới dạng" hoặc "nhận dưới dạng" cho Nhóm phân phối trong Exchange Server 2010 hoặc Exchange Server 2013

Nguyên nhân

Theo mặc định, Exchange Trusted Subystem không được cấp quyền "sửa đổi quyền". Điều này khiến lệnh ghép ngắn Add-ADPermission không thành công với lỗi Truy cập bị từ chối.

Nghị quyết

Để khắc phục sự cố này, hãy thêm quyền "sửa đổi quyền" cho Hệ thống con tin cậy trao đổi vào đơn vị tổ chức (OU) có chứa Nhóm phân phối bằng cách thực hiện theo các bước sau:

  1. Mở Active Directory Users and Computer.
  2. Bấm Xem, rồi bấm Tính năng Nâng cao.
  3. Bấm chuột phải vào OU chứa danh sách phân phối, rồi bấm Thuộc tính.
  4. Trong tab Bảo mật, bấm Nâng cao.
  5. Trong tab Quyền, bấm Thêm.
  6. Trong hộp Nhập tên đối tượng để chọn, nhập Exchange hệ thống con tin cậy, sau đó bấm OK.
  7. Trong tab Đối tượng, chọn Đối tượng này và tất cả các đối tượng con cháu trong danh sách Áp dụng lên, xác định vị trí Sửa đổi quyền trong danh sách Quyền, sau đó đặt đối tượng thành Cho phép.
  8. Nhấn OK.

1

Đã gặp phải 'quyền thừa kế không được kích hoạt' này trên tài khoản của người dùng, trong khi cố gắng thiết lập di chuyển sang o365. Không thể nhập thuộc tính Exchange. Đã viết thói quen nhỏ này để kích hoạt hộp kiểm 'quyền thừa kế'.

$user = Get-ADuser -Filter "(displayname -eq "Joe Cool")
$ou = [ADSI](“LDAP://” + $user)
$sec = $ou.psbase.objectSecurity
If ($sec.get_AreAccessRulesProtected()) {
   $isProtected = $false ## allows inheritance
   $preserveInheritance = $true ## preserver inhreited rules
   $sec.SetAccessRuleProtection($isProtected, $preserveInheritance)
   $ou.psbase.commitchanges()
   Write-Host “$user is now inherting permissions”;
}

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.