Tidak dapat memberikan izin 'kirim-sebagai' di Exchange 2010


11

Saya mencoba memberikan izin 'kirim-sebagai' kepada satu pengguna di Exchange 2010. Ini adalah perintah Powershell yang saya jalankan:

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

Powershell mengembalikan kesalahan ini:

Operasi direktori aktif gagal pada DC.OurDomain.pri. Kesalahan ini tidak dapat ditagih. Informasi tambahan: Akses ditolak. Respons direktori aktif: 00000005: SecErr: DSID-031521D0, masalah 4003 (INSUFF_ACCESS_RIGHTS), data 0 + KategoriInfo: WriteError: (0: Int32) [Add-ADPermission], ADOperationException + FullyQualifiedErrorId: EDG94. AddADPermission

Saya sudah mencoba beberapa alternatif untuk perintah Powershell - yaitu. menggunakan -Identity dll, tapi itu dan wizard EMC semua mengembalikan kesalahan yang sama.

Saya tidak yakin apakah "INSUFF_ACCESS_RIGHTS" merujuk kepada saya yang menjalankan perintah atau pengguna yang saya beri hak kirim-ke?

Saya telah mengikuti halaman web Microsoft Technet "Kelola Izin Kirim Sebagai untuk Kotak Surat" di sini: http://technet.microsoft.com/en-us/library/bb676368.aspx

Jadi, tambahkan dua izin yang perlu Anda lakukan ini:

Manajemen Organisasi

Manajemen Penerima

Tapi itu tidak membantu. Ada ide?

Memperbarui

Jika saya melakukan hal berikut:

  • buka "Pengguna AD & Komputer" dengan tampilan "Fitur Lanjutan"
  • Pergi ke properti User1
  • Tekan "Advanced" pada tab Security
  • Pilih "Tambah"
  • masukkan "User2" dan pilih "Send As" Allow

Itu bekerja, jika saya menutup ADUaC dan membukanya lagi dan memeriksa kembali izin baru itu masih ada. Jika saya kembali sekitar 10 menit kemudian izin itu sekarang hilang - user2 tidak muncul dalam izin keamanan user1 sama sekali.

Jangan berpikir saya pernah melihat perilaku AD semacam ini sebelumnya.


1
Apakah User1 pengguna istimewa dengan kesempatan apa pun (mis. Admin Domain, Admin Perusahaan, Operator Akun)?
Ben Pilbrow

Tidak, mereka hanya anggota Pengguna Domain dan Operator Cetak.
Kieran Walsh

1
Ah, operator cetak adalah salah satu dari kelompok yang dilindungi itu. Saya tidak dalam posisi untuk memperbarui jawaban saya saat ini - beri saya beberapa jam. Sementara itu, saya menduga masalah Anda terkait dengan utas adminSDHolder - Google bahwa jika Anda ingin info lebih lanjut, tetapi jangan terburu-buru! Saya merekomendasikan posting yang luar biasa ini untuk detail yang bagus.
Ben Pilbrow

Benar - Saya belum pernah mendengar tentang adminSDHolder sebelumnya. Saya telah mencoba menghapus pengguna dari Print Operator, tetapi perintah Powershell gagal di tempat yang sama.
Kieran Walsh

Jawaban:


8

Saya akhirnya memperbaiki ini.

Menariknya Kirim-As adalah izin AD - bukan izin pertukaran seperti yang Anda harapkan.

Bagaimanapun, ini adalah langkah-langkahnya:

Jadikan kotak surat target "dapat dibagikan" menggunakan perintah ini di Powershell di Exchange Server Anda:

Set-Mailbox user1 -type:shared

Jika Anda mendapatkan kesalahan ini (sama seperti pada posting pertama saya): Kegagalan AD

Anda harus menemukan pengguna itu dalam AD dan pergi ke properti >> Keamanan >> Lanjutan:

Properti AD

Anda perlu MENGAKTIFKAN opsi untuk "Sertakan izin yang dapat diwarisi dari induk objek ini":

masukkan deskripsi gambar di sini

Setelah selesai, Anda harus dapat menyelesaikan skrip berbagi folder.

Maka sebenarnya berikan hak menggunakan perintah ini:

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

Harapan itu membantu orang lain yang memiliki masalah yang sama.

Kieran


Catatan: Untuk melihat tab "keamanan" di properti pengguna, Anda harus terlebih dahulu mengaktifkan opsi melihat lanjutan di menu.
Andreas Reiff

4

Akses yang ditolak pesan biasanya berasal dari akun yang menjalankan sesi PowerShell yang tidak memiliki cukup izin. Saya mendapatkan ini sepanjang waktu ketika saya baru saja meluncurkan Exchange Management Shell alih-alih menjalankan sebagai akun pengguna administratif saya.

Setelah pembaruan Anda, apa yang saya duga mungkin terjadi adalah bahwa User1 adalah bagian dari grup yang dilindungi (Print Operator) sehingga Exchange tidak memungkinkan Anda untuk memberikan Send As pada User2 karena ia tahu itu hanya akan dilucuti dalam satu jam berikutnya. Sepertinya Anda mengkonfirmasi teori itu dengan secara manual menambahkan Kirim Sebagai menggunakan ADUC dan melihatnya dihapus beberapa saat kemudian.

Pada Kontroler Domain yang menjalankan peran FSMO PDC Emulator, setiap jam sesuatu yang disebut utas adminSDHolder berjalan. Apa yang dilakukan adalah mengambil semua akun yang (atau pernah ada, bahkan jika mereka kemudian dihapus) dalam grup yang dilindungi (Admin Perusahaan, Admin Domain, Operator Akun, Operator Cetak untuk menyebutkan beberapa yang lebih umum) dan menghapus semua izin yang diberikan pada objek dan menggantinya dengan izin tertentu yang didefinisikan secara eksplisit. Gagasannya adalah bahwa akun yang didelegasikan tidak dapat mendatangkan malapetaka dan menghapus admin domain dari hak istimewa mereka.

Saya tidak sepenuhnya yakin perbaikan izin pemberian Anda secara eksplisit akan berhasil dan tidak akan disetel ulang setiap jam, tetapi saya telah salah sebelumnya - jadi jika itu benar, bagus! Namun, jika pengguna tidak perlu berada dalam grup Print Operators, saya sarankan Anda memodifikasi akun mereka menggunakan ADSI Edit dan setel properti adminCount menjadi nol. Kemudian aktifkan izin bawaan pada objek pengguna dan setel ulang izin default. Setelah Anda selesai melakukannya, coba cmdlet Exchange Anda lagi dan dengan sedikit keberuntungan itu akan berhasil (jelas beri waktu yang cukup untuk replikasi AD terjadi).

Saya tidak berpikir Anda akan dapat memodifikasi cmdlet Anda untuk mengakomodasi ini - seperti saya katakan, saya bayangkan (tidak yakin sekalipun) bahwa ia tidak akan membiarkan Anda melakukannya karena Exchange tahu izin hanya akan dihapus tak lama setelah itu dan sedang berusaha menyelamatkan kebingungan di pihak Anda. Di bawah keadaan "normal" (yaitu pengguna standar) cmdlet seharusnya hanya berfungsi tanpa masalah karena seluruh utas adminSDHolder bahkan tidak ikut bermain.


UPDATE: Posting saya yang lain tidak berfungsi dalam jangka panjang seperti yang Anda sarankan. ADSIEdit TIDAK memiliki adminCount yang diatur ke 1, jadi saya telah mengubahnya menjadi 0. Akan memperbarui ini ketika utas adminSDHolder berjalan.
Kieran Walsh

Sekitar 5 jam kemudian properti ADSIEDIT masih diatur ke 0, tetapi perubahan Powershell atau EMS saya masih memberikan masalah akses ditolak yang sama. :(
Kieran Walsh

1

Pernahkah Anda melihat KB ini: Akses ditolak ketika Anda mencoba memberi izin "send-as" atau "terima sebagai" kepada pengguna untuk Grup Distribusi di Exchange Server 2010 atau Exchange Server 2013

Sebab

Secara default Exchange Subsistem Tepercaya tidak diberikan izin "ubah izin". Ini menyebabkan cmdlet Add-ADPermission gagal dengan kesalahan Access Denied.

Resolusi

Untuk mengatasi masalah ini, tambahkan izin "ubah izin" untuk Subsistem Tepercaya Exchange ke unit organisasi (OU) yang berisi Grup Distribusi dengan mengikuti langkah-langkah berikut:

  1. Buka Pengguna dan Komputer Direktori Aktif.
  2. Klik Lihat, lalu klik Fitur Lanjutan.
  3. Klik kanan-atas OU yang berisi daftar distribusi, dan kemudian klik Properti.
  4. Di tab Keamanan, klik Tingkat Lanjut.
  5. Di tab Izin, klik Tambah.
  6. Di kotak Masukkan nama objek untuk memilih, ketik Exchange subsistem tepercaya, lalu klik OK.
  7. Di tab Objek, pilih Objek ini dan semua objek keturunan di daftar Terapkan ke, temukan Ubah Izin dalam daftar Izin, lalu tetapkan untuk Izinkan.
  8. Klik OK.

1

Menemukan 'warisan ini tidak diaktifkan' pada akun pengguna, ketika mencoba mengatur migrasi ke o365. Tidak dapat mengimpor properti Exchange. Tulis sedikit rutin ini untuk mengaktifkan kotak centang 'izin yang dapat diwarisi'.

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

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.