Неможливо надати дозволи "надіслати як" у Exchange 2010

Я намагаюся надати дозволу "надіслати" одному користувачеві в Exchange 2010. Ось команда Powershell, яку я виконую:

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

Powershell повертає цю помилку:

Помилка роботи Active Directory на DC.OurDomain.pri. Ця помилка не може бути видалена. Додаткова інформація: У доступі заборонено. Активна відповідь каталогів: 00000005: SecErr: DSID-031521D0, проблема 4003 (INSUFF_ACCESS_RIGHTS), дані 0 + CategoryInfo: WriteError: (0: Int32) [Add-ADPermission], ADOperationException + FullyQualifiedErrorId: EDBB94Aci. Додавання дозволу

Я спробував кілька альтернатив команді Powershell - тобто. використовуючи -Identity тощо, але це і майстер ЕМС повертають ту саму помилку.

Я не впевнений, чи "INSUFF_ACCESS_RIGHTS" посилається на мене, хто виконує команду, або на користувача, якому я надаю права надсилання?

Я стежу за веб-сторінкою Microsoft Technet "Керувати надсилати як дозволи для поштової скриньки" тут: http://technet.microsoft.com/en-us/library/bb676368.aspx

Тому ви додали два дозволи, які вам потрібно зробити для цього:

Управління організацією

Управління реципієнтами

Але це не допомагає. Будь-які ідеї?

Оновлення

Якщо я виконую наступне:

• відкрийте "Користувачі та комп’ютери AD" за допомогою перегляду "Розширені функції"
• Перейдіть до властивостей User1
• Натисніть "Додатково" на вкладці Безпека
• Виберіть "Додати"
• введіть "User2" і виберіть "Надіслати як" Дозволити

Це працює, якщо я закрию ADUaC і знову відкрию його і перевірте ті нові дозволи, які вони все ще є. Якщо я повернусь приблизно 10 хвилин пізніше, ці дозволи тепер уже відсутні - user2 взагалі не відображається в дозволах безпеки користувача1.

Не думаю, що я раніше не бачив подібної поведінки AD.

Я нарешті це виправив.

Цікаво, що Send-As - це дозвіл AD, а не дозвіл на обмін, як ви могли очікувати.

У будь-якому випадку, це такі кроки:

Зробіть цільову поштову скриньку "доступною для доступу", використовуючи цю команду в Powershell на сервері Exchange Server:

Set-Mailbox user1 -type:shared

Якщо ви отримаєте цю помилку (таку ж, як у моєму першому дописі):

Вам потрібно буде знайти цього користувача в AD та перейти до властивостей >> Безпека >> Розширено:

Вам необхідно ВКЛЮЧИТИ опцію «Включити дозволу , успадковані від батьківських об'єктів»:

Після цього ви зможете виконати сценарій спільного використання папки.

Тоді фактично надайте права за допомогою цієї команди:

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

Сподіваємось, що це допоможе іншим, хто має ту саму проблему.

Кірань

Повідомлення, яким заборонено доступ, зазвичай надходять із облікового запису, на якому працює сесія PowerShell, не маючи достатнього дозволу. Я отримую це весь час, коли я просто запускаю оболонку управління Exchange, а не виконуються як мій обліковий запис адміністративного користувача.

Після вашого оновлення, можливо, я підозрюю, що User1 є частиною захищеної групи (Оператори друку), тому Exchange не дозволяє вам надати Send As on User2, оскільки він знає, що вона буде позбавлена ​​лише протягом наступної години. Схоже, ви підтвердили цю теорію, вручну додавши Send As за допомогою ADUC і побачивши, що її забрали через деякий час.

На контролері домену, який виконує роль FSMO емулятора PDC, щогодини запускається щось, що називається потоком adminSDHolder. Для цього потрібно взяти всі облікові записи, які є (або коли-небудь були, навіть якщо вони згодом були видалені) у захищених групах (Enterprise Admins, Administrator доменів, Оператори акаунтів, Оператори друку, щоб назвати декілька більш поширених) та видалити всі дозволи, надані на об'єкти, і замінює їх на певні чітко визначені дозволи. Ідея полягає в тому, що делегований обліковий запис не може спричинити хаос і позбавити адміністратора домену своїх привілеїв.

Я не зовсім переконаний, що виправлення явного надання дозволу буде спрацьовувати і не буде скидатися щогодини, але я раніше помилявся - тож якщо це так, чудово! Якщо користувачеві не потрібно входити до групи Оператори друку, я рекомендую вам змінити його обліковий запис за допомогою редагування ADSI та встановити властивість adminCount на нуль. Потім увімкніть успадковані дозволи на об’єкт користувача та скиньте дозволи за замовчуванням. Щойно ви зробите це, спробуйте свій командлет Exchange ще раз і з трохи удачі це спрацює (очевидно, дайте достатньо часу, щоб відбулася реплікація AD).

Я не думаю, що ви не зможете змінити свій командлет, щоб він міг пристосуватись до цього - як я вже сказав, я думаю, що (не певне, що) він не дозволить вам це робити, оскільки Exchange знає, що дозвіл видаляється лише незабаром після цього намагається врятувати плутанину з вашого боку. За "нормальних" обставин (тобто стандартного користувача) командлет повинен просто працювати без проблем, оскільки вся нитка adminSDHolder навіть не вступає в дію.

Ви бачили цей КБ: Відмовлено в доступі, коли ви намагаєтесь надати користувачеві дозвіл "надіслати як" або "отримати як" для групи розподілу в Exchange Server 2010 або Exchange Server 2013

Причина

За замовчуванням Exchange Trusted Subystem не надає дозволу "модифікувати дозволи". Це призводить до виходу з ладу командлету Add-ADPermission з помилкою Access Denied.

Дозвіл

Щоб вирішити цю проблему, додайте дозвіл "змінити дозволи" для довіреної підсистеми Exchange до організаційного підрозділу (OU), який містить Групу розповсюдження, виконавши наступні кроки:

1. Відкрийте користувачі та комп’ютери Active Directory.
2. Клацніть Перегляд, а потім виберіть Додаткові функції.
3. Клацніть правою кнопкою миші ОУ, що містить списки розповсюдження, а потім натисніть Властивості.
4. На вкладці Безпека натисніть кнопку Додатково.
5. На вкладці "Дозволи" натисніть кнопку "Додати".
6. У полі Введіть ім'я об'єкта для вибору, введіть довірну підсистему Exchange та натисніть кнопку ОК.
7. На вкладці "Об'єкт" виберіть Цей об'єкт та всі об'єкти нащадків у списку "Застосувати до", знайдіть Змінити дозволи в списку Дозволів, а потім встановіть його "Дозволити".
8. Натисніть кнопку ОК.

Зупинив це "успадкування не ввімкнено" в обліковому записі користувача, намагаючись налаштувати міграцію на o365. Не вдалося імпортувати властивості Exchange. Написав цю маленьку процедуру, щоб увімкнути прапорець "успадковані дозволи".

$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”;
}

Наведені вище рішення не вирішили мою проблему, але це зробили: http://support.risualblogs.com/blog/2012/02/07/the-user-has-insufficient-access-rights-error-when-trying- встановити-надіслати-як-дозволи-на-поштовій скриньці в обмін-2010 /

Конкретний обліковий запис користувача AD, на який я намагався встановити perms Send, не мав успадкованих дозволів, перевірених у AD.