Exchange 2010 में 'send-as' अनुमतियां नहीं दे सकते

Question

मैं Exchange 2010 में किसी एक उपयोगकर्ता को 'सेंड-अस-परमिशन' देने की कोशिश कर रहा हूं।

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

पॉवर्सशेल इस त्रुटि को लौटाता है:

सक्रिय निर्देशिका ऑपरेशन DC.OurDomain.pri पर विफल रहा। यह त्रुटि पुनर्प्राप्त करने योग्य नहीं है। अतिरिक्त जानकारी: प्रवेश निषेध है। सक्रिय निर्देशिका प्रतिक्रिया: 00000005: SecErr: DSID-031521D0, समस्या 4003 (INSUFF_ACCESS_RIGHTS), डेटा 0 + श्रेणीइन्फो: WriteError: (0: Int32 [Add-ADPermission], ADOperationException + FullQualifiedErrorId: EDBBD: EDBr_D। AddADPermission

मैंने पॉवर्सशेल कमांड के कई विकल्पों की कोशिश की है - यानी। का उपयोग कर -Identity आदि, लेकिन वह और EMC विज़ार्ड सभी एक ही त्रुटि वापस करते हैं।

मुझे यकीन नहीं है कि अगर "INSUFF_ACCESS_RIGHTS" मुझे संदर्भित कर रहा है जो कमांड चला रहा है या मैं जिस उपयोगकर्ता को भेज रहा हूं, उसे अधिकार दे रहा है?

मैं यहाँ Microsoft टेक्नेट का प्रबंधन कर रहा हूँ "मेलबॉक्स के लिए Send As As अनुमतियाँ" वेब पेज यहाँ: http://technet.microsoft.com/en-us/library/bb676368.aspx

इसलिए आपको यह करने के लिए आवश्यक दो अनुमतियाँ जोड़ी गई हैं:

संगठन का प्रबंधन

प्राप्तकर्ता प्रबंधन

लेकिन वह मदद नहीं कर रहा है। कोई विचार?

अपडेट करें

यदि मैं निम्नलिखित कार्य करता हूं:

• "उन्नत सुविधाएँ" दृश्य के साथ "AD उपयोगकर्ता और कंप्यूटर" खोलें
• User1 के गुणों पर जाएं
• सुरक्षा टैब पर "उन्नत" मारो
• "जोड़ें" चुनें
• "User2" में प्रवेश करें और "Send As" अनुमति चुनें

यह काम करता है, अगर मैं ADUaC को बंद करता हूं और इसे फिर से खोलता हूं और उन नई अनुमतियों की फिर से जांच करता हूं जो वे अभी भी वहां हैं। यदि मैं लगभग 10 मिनट बाद लौटता हूं तो वे अनुमतियां अब चली गईं हैं - user2 उपयोगकर्ता 1 की सुरक्षा अनुमतियों में बिल्कुल भी दिखाई नहीं देता है।

मुझे नहीं लगता कि मैंने पहले कभी इस तरह का विज्ञापन व्यवहार देखा है।

Comments

क्या User1 किसी भी मौका (यानी डोमेन एडमिन, एंटरप्राइज एडमिन, अकाउंट ऑपरेटर) द्वारा एक विशेषाधिकार प्राप्त उपयोगकर्ता है?

— बेन पलब्रो

नहीं, वे केवल डोमेन उपयोगकर्ता और प्रिंट ऑपरेटर के सदस्य हैं।

— कीरन वाल्श

आह, प्रिंट ऑपरेटर उन संरक्षित समूहों में से एक है। मैं मिनट में मेरे जवाब को अपडेट करने की स्थिति में नहीं हूं - कुछ घंटों के लिए। इस समय के दौरान, मुझे संदेह है कि आपकी समस्या व्यवस्थापन फ़ोल्डर से संबंधित है - Google कि यदि आप अधिक जानकारी चाहते हैं, लेकिन कुछ भी न करें! मैं कुछ अच्छे विवरण के लिए इस भयानक पोस्ट की सलाह देता हूं ।

— बेन पलब्रो

सही - मैंने पहले कभी भी व्यवस्थापन फ़ोल्डर के बारे में नहीं सुना। मैंने प्रिंट ऑपरेटर्स से उपयोगकर्ता को हटाने की कोशिश की है, लेकिन पॉवर्सशेल कमांड उसी स्थान पर विफल रहता है।

— कीरन वाल्श

Answer 1

मैंने आखिरकार यह तय कर लिया है।

दिलचस्प रूप से Send-As एक AD अनुमति है - एक विनिमय अनुमति नहीं जैसा कि आपने उम्मीद की थी।

वैसे भी, ये चरण हैं:

अपने Exchange सर्वर पर Powershell में इस कमांड का उपयोग करके लक्ष्य मेलबॉक्स को "साझा करें" बनाएं:

Set-Mailbox user1 -type:shared

यदि आपको यह त्रुटि मिलती है (जैसा कि मेरी पहली पोस्ट में है):

आपको AD में उस उपयोगकर्ता को ढूंढना होगा और उसके गुणों पर जाना होगा >> सुरक्षा >> उन्नत:

आपको "इस ऑब्जेक्ट के माता-पिता से अंतर्निहित अनुमतियों को शामिल करने" के विकल्प को सक्षम करने की आवश्यकता है :

एक बार जो किया जाता है वह आपको फ़ोल्डर साझा स्क्रिप्ट को पूरा करने में सक्षम होना चाहिए।

तब वास्तव में इस कमांड का उपयोग करके अधिकार प्रदान करते हैं:

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

आशा है कि जो दूसरों को एक ही समस्या है मदद करता है।

कीरन

Comments

नोट: उपयोगकर्ता के गुणों में "सुरक्षा" टैब को देखने के लिए, आपको सबसे पहले मेनू में उन्नत विकल्प देखने में सक्षम होना चाहिए।

— एंड्रियास रीफ

Answer 2

अस्वीकृत संदेश आमतौर पर पावरस्ले सत्र चलाने वाले खाते से आते हैं जिनके पास पर्याप्त अनुमति नहीं है। मुझे यह सब समय मिलता है जब मैं सिर्फ अपने प्रशासनिक उपयोगकर्ता खाते के रूप में चलाने के बजाय एक्सचेंज प्रबंधन शेल लॉन्च करता हूं।

आपके अपडेट के बाद, मुझे जो संदेह हो रहा है, वह यह है कि User1 एक संरक्षित समूह (प्रिंट ऑपरेटर्स) का हिस्सा है, इसलिए एक्सचेंज आपको Send2 को User2 के रूप में देने की अनुमति नहीं दे रहा है क्योंकि यह जानता है कि यह केवल अगले घंटे में बंद हो जाएगा। ऐसा लगता है कि आपने ADUC का उपयोग करके सेंड अस को मैन्युअल रूप से जोड़कर उस सिद्धांत की पुष्टि की और इसे थोड़े समय बाद हटा लिया।

डोमेन नियंत्रक पर जो PDC एमुलेटर FSMO भूमिका निभाता है, हर घंटे में कुछ को adminSDHolder थ्रेड रन कहा जाता है। यह क्या करता है सभी खातों को लेता है जो (या कभी भी रहे हैं, भले ही वे बाद में हटा दिए गए हों) संरक्षित समूहों में (एंटरप्राइज एडमीन, डोमेन एडमीन, अकाउंट ऑपरेटर्स, प्रिंट ऑपरेटर कुछ और सामान्य लोगों के नाम) और सभी को हटा दें ऑब्जेक्ट पर दी गई अनुमतियाँ और उन्हें कुछ स्पष्ट रूप से परिभाषित अनुमतियों के साथ बदल देती हैं। यह विचार यह है कि एक प्रत्यायोजित खाता कहर बरपा नहीं सकता है और अपने विशेषाधिकारों के डोमेन व्यवस्थापक को हटा सकता है।

मैं पूरी तरह से आश्वस्त नहीं हूं कि आपकी अनुमति देने का आपका काम स्पष्ट रूप से अनुमति देने वाला है और हर घंटे रीसेट नहीं किया जाएगा, लेकिन मैं पहले भी गलत रहा हूं - इसलिए अगर ऐसा होता है, तो बहुत अच्छा! हालांकि अगर उपयोगकर्ता को प्रिंट ऑपरेटर्स समूह में रहने की आवश्यकता नहीं है, तो मैं आपको ADSI एडिट का उपयोग करके उनके खाते को संशोधित करने की सलाह दूंगा और adminCount संपत्ति को शून्य पर सेट कर दूंगा । फिर उपयोगकर्ता ऑब्जेक्ट पर अंतर्निहित अनुमतियों को सक्षम करें और डिफ़ॉल्ट अनुमतियों को रीसेट करें। एक बार जब आप ऐसा कर लेते हैं, तो अपने Exchange cmdlet को फिर से आज़माएँ और थोड़ी किस्मत के साथ यह काम करेगा (जाहिर तौर पर AD प्रतिकृति होने के लिए पर्याप्त समय देगा)।

मुझे नहीं लगता कि आप इसके लिए अपने cmdlet को संशोधित करने में सक्षम होंगे - जैसे मैंने कहा, मैं कल्पना करता हूं (हालांकि कुछ निश्चित नहीं है) कि यह आपको ऐसा नहीं करने देगा क्योंकि एक्सचेंज जानता है कि अनुमति केवल हटाए जाने की है। जल्द ही बाद में और अपनी ओर से भ्रम को बचाने की कोशिश कर रहा है। "सामान्य" परिस्थितियों (यानी एक मानक उपयोगकर्ता) के तहत cmdlet को केवल समस्या के बिना काम करना चाहिए क्योंकि पूरे adminSDHolder थ्रेड भी खेलने के लिए नहीं आता है।

Comments

अद्यतन: मेरा अन्य पद आपके द्वारा सुझाए गए अनुसार लंबे समय तक काम नहीं करता है। ADSIEdit के पास AdminCount 1 पर सेट होता है, इसलिए मैंने इसे 0. में बदल दिया है, जब adminSDHolder रन चलता है तो यह इसे अपडेट करेगा।

— किरन वाल्श

कुछ 5 घंटे बाद ADSIEDIT संपत्ति अभी भी 0 पर सेट है, लेकिन मेरे पॉवर्सशेल या ईएमएस परिवर्तन अभी भी एक ही एक्सेस अस्वीकृत समस्या देते हैं। :(

— किरन वाल्श

Answer 3

क्या आपने यह KB देखा है: जब आप उपयोगकर्ता को "Send-as" या "Exchange Server 2010 में किसी वितरण समूह के लिए अनुमति" के रूप में प्राप्त करने का प्रयास करते हैं तो एक्सेस अस्वीकृत हो जाता है या Exchange Server 2013

कारण

डिफ़ॉल्ट रूप से एक्सचेंज ट्रस्टेड सबसिस्टम को "अनुमति संशोधित करें" अनुमति नहीं दी गई है। यह ऐड-ADPermission cmdlet को Access अस्वीकृत त्रुटि के साथ विफल करने का कारण बनता है।

संकल्प

इस समस्या को हल करने के लिए, संगठनात्मक इकाई (OU) के लिए एक्सचेंज ट्रस्टेड सबसिस्टम के लिए "संशोधित अनुमति" अनुमति जोड़ें, जिसमें इन चरणों का पालन करके वितरण समूह शामिल है:

1. सक्रिय निर्देशिका उपयोगकर्ता और कंप्यूटर खोलें।
2. दृश्य पर क्लिक करें और फिर उन्नत सुविधाएँ पर क्लिक करें।
3. वितरण सूची में शामिल OU पर राइट-क्लिक करें, और उसके बाद गुण क्लिक करें।
4. सुरक्षा टैब में, उन्नत पर क्लिक करें।
5. अनुमतियाँ टैब में, जोड़ें पर क्लिक करें।
6. बॉक्स का चयन करने के लिए ऑब्जेक्ट नाम दर्ज करें, एक्सचेंज विश्वसनीय सबसिस्टम टाइप करें, और उसके बाद ठीक क्लिक करें।
7. ऑब्जेक्ट टैब में, इस ऑब्जेक्ट को चुनें और सभी वंशज ऑब्जेक्ट्स को सूची में लागू करें, अनुमतियाँ सूची में संशोधित संशोधित करें की स्थिति जानें और फिर अनुमति दें पर सेट करें।
8. ओके पर क्लिक करें।

Answer 4

उपयोगकर्ता के खाते पर इस 'विरासत को सक्षम नहीं किया गया है' का सामना करना पड़ा, जबकि ओ ३६६५ में सेटअप प्रवास की कोशिश कर रहा था। 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”;
}

Answer 5

उपरोक्त समाधानों ने मेरी समस्या का समाधान नहीं किया, लेकिन यह किया: http://support.risualblogs.com/blog/2012/02/07/the-user-has-insufficient-access-rights-error-when-trying- टू-सेट भेजने के रूप में अनुमतियाँ-ऑन-ए-मेलबॉक्स-इन-विनिमय-2010 /

विशेष रूप से AD उपयोगकर्ता खाता जिसे मैं Send As Perms पर सेट करने का प्रयास कर रहा था, उसमें AD में जांचे जाने योग्य अनुमति नहीं थी।