Nie można nadać uprawnień „wyślij jako” w programie Exchange 2010

11

Usiłuję nadać uprawnienia „wyślij jako” jednemu użytkownikowi w programie Exchange 2010. Oto polecenie Powershell, które uruchamiam:

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

Program PowerShell zwraca ten błąd:

Operacja usługi Active Directory nie powiodła się na DC.OurDomain.pri. Tego błędu nie można odtworzyć. Informacje dodatkowe: Odmowa dostępu. Odpowiedź usługi Active Directory: 00000005: SecErr: DSID-031521D0, problem 4003 (INSUFF_ACCESS_RIGHTS), dane 0 + CategoryInfo: WriteError: (0: Int32) [Add-ADPermission], ADOperationException + FullyQualifiedErrorId: EDBB94A3.Zarządzanie. AddADPermission

Próbowałem wielu alternatyw dla polecenia Powershell - tj. przy użyciu opcji -Identity itp., ale to i kreator EMC zwracają ten sam błąd.

Nie jestem pewien, czy „INSUFF_ACCESS_RIGHTS” odnosi się do mnie, kto uruchamia polecenie, czy do użytkownika, któremu przekazuję uprawnienia do wysyłania?

Śledzę stronę internetową Microsoft Technet „Zarządzaj wysyłaniem jako uprawnienia do skrzynki pocztowej” tutaj: http://technet.microsoft.com/en-us/library/bb676368.aspx

Dodałem więc dwa uprawnienia, które musisz zrobić:

Zarządzanie organizacją

Zarządzanie odbiorcami

Ale to nie pomaga. Jakieś pomysły?

Aktualizacja

Jeśli wykonam następujące czynności:

  • otwórz „Użytkownicy i komputery AD” w widoku „Funkcje zaawansowane”
  • Przejdź do właściwości User1
  • Naciśnij „Zaawansowane” na karcie Zabezpieczenia
  • Wybierz „Dodaj”
  • wpisz „User2” i wybierz „Send As” Allow

To działa, jeśli zamknę ADUaC i otworzę go ponownie i ponownie sprawdzę te nowe uprawnienia, które nadal tam są. Jeśli wrócę około 10 minut później, uprawnienia te już zniknęły - użytkownik2 nie pojawia się w uprawnieniach użytkownika 1.

Nie sądzę, że kiedykolwiek widziałem takie zachowanie AD.

Kieran Walsh
źródło
1
Czy Użytkownik1 jest przypadkiem uprzywilejowanym użytkownikiem (tj. Administrator domeny, Administrator przedsiębiorstwa, Operator konta)?
Ben Pilbrow
Nie, są tylko członkami użytkowników domeny i operatorów drukowania.
Kieran Walsh,
1
Ach, operatorzy drukowania to kolejna z tych chronionych grup. Nie jestem w stanie zaktualizować mojej odpowiedzi od razu - daj mi kilka godzin. Tymczasem podejrzewam, że twój problem jest związany z wątkiem adminSDHolder - Google, że jeśli chcesz więcej informacji, ale nie rób nic pochopnego! Polecam ten niesamowity post dla dobrego opisu.
Ben Pilbrow
Racja - nigdy wcześniej nie słyszałem o adminSDHolder. Próbowałem usunąć użytkownika z Operatorów drukowania, ale polecenie Powershell kończy się niepowodzeniem w tym samym miejscu.
Kieran Walsh,

Odpowiedzi:

8

W końcu to naprawiłem.

Co ciekawe, Send-As jest uprawnieniem AD, a nie pozwoleniem na wymianę, jak można się było spodziewać.

W każdym razie są to następujące kroki:

Ustaw docelową skrzynkę pocztową jako „udostępnioną” za pomocą tego polecenia w programie Powershell na serwerze Exchange:

Set-Mailbox user1 -type:shared

Jeśli pojawi się ten błąd (taki sam jak w moim pierwszym poście): Awaria AD

Musisz znaleźć tego użytkownika w AD i przejść do właściwości >> Bezpieczeństwo >> Zaawansowane:

Właściwości AD

Musisz WŁĄCZYĆ opcję „Uwzględnij uprawnienia dziedziczne od obiektu nadrzędnego tego obiektu”:

wprowadź opis zdjęcia tutaj

Po zakończeniu tej czynności powinieneś być w stanie ukończyć skrypt udostępniania folderów.

Następnie faktycznie nadaj uprawnienia za pomocą tego polecenia:

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

Mam nadzieję, że pomaga innym, którzy mają ten sam problem.

Kieran

Kieran Walsh
źródło
Uwaga: Aby zobaczyć kartę „bezpieczeństwo” we właściwościach użytkownika, musisz najpierw włączyć przeglądanie zaawansowanych opcji w menu.
Andreas Reiff
4

Odmowa dostępu wiadomości zwykle pochodzą z konta z uruchomioną sesją PowerShell, która nie ma wystarczających uprawnień. Otrzymuję to przez cały czas, gdy po prostu uruchamiam powłokę Exchange Management Shell zamiast uruchamiać się jako moje konto użytkownika administracyjnego.

Po aktualizacji mogę podejrzewać, że Użytkownik1 jest częścią chronionej grupy (Operatorzy drukowania), więc Exchange nie zezwala na nadanie opcji Wyślij jako Użytkownik2, ponieważ wie, że zostanie on usunięty w ciągu najbliższej godziny. Wygląda na to, że potwierdziłeś tę teorię, ręcznie dodając Wyślij jako za pomocą ADUC i widząc, że została ona zabrana wkrótce.

Na kontrolerze domeny, który uruchamia rolę emulatora PDC FSMO, co godzinę działa coś zwanego wątkiem adminSDHolder. To powoduje, że wszystkie konta, które są (lub kiedykolwiek były, nawet jeśli zostały później usunięte) w chronionych grupach (Administratorzy przedsiębiorstwa, Administratorzy domeny, Operatorzy kont, Operatorzy drukowania, aby wymienić niektóre z bardziej powszechnych) i usuwa wszystkie uprawnienia przyznane na obiekty i zastępują je pewnymi wyraźnie określonymi uprawnieniami. Chodzi o to, że delegowane konto nie jest w stanie siać spustoszenia i pozbawić administratora domeny ich uprawnień.

Nie jestem do końca przekonany, czy poprawka polegająca na jawnym przyznawaniu uprawnień zadziała i nie będę resetowana co godzinę, ale wcześniej się myliłam - jeśli tak, to świetnie! Jeśli jednak użytkownik nie musi być w grupie Operatorów drukowania, zalecam zmodyfikowanie jego konta za pomocą Edytora ADSI i ustawienie właściwości adminCount na zero. Następnie włącz dziedziczone uprawnienia do obiektu użytkownika i zresetuj uprawnienia domyślne. Gdy to zrobisz, spróbuj ponownie cmdlet Exchange i przy odrobinie szczęścia zadziała (oczywiście daj wystarczająco dużo czasu na replikację AD).

Nie sądzę, że będziesz w stanie zmodyfikować swoje cmdlet, aby to uwzględnić - tak jak powiedziałem, wyobrażam sobie (choć nie jestem pewien), że nie pozwoli ci to zrobić, ponieważ Exchange wie, że pozwolenie zostanie usunięte wkrótce potem i próbuje uratować zamieszanie z twojej strony. W „normalnych” okolicznościach (tj. Standardowy użytkownik) polecenie cmdlet powinno po prostu działać bez problemu, ponieważ cały wątek adminSDHolder nawet nie wchodzi w grę.

Ben Pilbrow
źródło
AKTUALIZACJA: Mój drugi post nie działa długoterminowo, jak sugerowałeś. ADSIEdit ma adminCount ustawiony na 1, więc zmieniłem go na 0. Zaktualizuje to po uruchomieniu wątku adminSDHolder.
Kieran Walsh
Około 5 godzin później właściwość ADSIEDIT jest wciąż ustawiona na 0, ale moje zmiany w PowerShell lub EMS nadal dają ten sam problem odmowy dostępu. :(
Kieran Walsh
1

Czy widziałeś ten KB: Odmowa dostępu, gdy próbujesz dać użytkownikowi „wyślij jako” lub „otrzymaj jako” dla grupy dystrybucyjnej w programie Exchange Server 2010 lub Exchange Server 2013

Przyczyna

Domyślnie Exchange Trusted Subsystem nie otrzymuje uprawnienia do „modyfikowania uprawnień”. Powoduje to niepowodzenie polecenia cmdlet Add-ADPermission z błędem Odmowa dostępu.

Rozkład

Aby obejść ten problem, dodaj uprawnienie „modyfikuj uprawnienia” dla zaufanego podsystemu Exchange do jednostki organizacyjnej (OU), która zawiera grupę dystrybucyjną, wykonując następujące kroki:

  1. Otwórz przystawkę Użytkownicy i komputery usługi Active Directory.
  2. Kliknij opcję Widok, a następnie kliknij opcję Funkcje zaawansowane.
  3. Kliknij prawym przyciskiem myszy jednostkę organizacyjną zawierającą listy dystrybucyjne, a następnie kliknij polecenie Właściwości.
  4. Na karcie Zabezpieczenia kliknij Zaawansowane.
  5. Na karcie Uprawnienia kliknij Dodaj.
  6. W polu Wprowadź nazwę obiektu do wybrania wpisz Exchange zaufany podsystem, a następnie kliknij przycisk OK.
  7. Na karcie Obiekt wybierz Ten obiekt i wszystkie obiekty potomne z listy Zastosuj do, zlokalizuj Modyfikuj uprawnienia na liście Uprawnienia, a następnie ustaw opcję Zezwalaj.
  8. Kliknij OK.
Stacy Reddy
źródło
1

Wystąpił ten „brak dziedziczenia” na koncie użytkownika podczas próby skonfigurowania migracji do o365. Nie można zaimportować właściwości programu Exchange. Napisałem tę małą procedurę, aby włączyć pole wyboru „uprawnienia dziedziczne”.

$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”;
}
Eric W.
źródło