क्या आईटी को कभी उपयोगकर्ता के डोमेन पासवर्ड की आवश्यकता होगी?

10

क्या एक नए उपयोगकर्ता के लिए वर्कस्टेशन को कॉन्फ़िगर करते समय विंडोज डोमेन व्यवस्थापक को कुछ भी करने की आवश्यकता हो सकती है जो उपयोगकर्ता के डोमेन खाते के पासवर्ड के बिना बिल्कुल नहीं किया जा सकता है? उपयोगकर्ताओं को उनके पासवर्ड के लिए पूछने से बचने के लिए, व्यवस्थापक, सैद्धांतिक रूप से, पासवर्ड बदल सकते हैं, उपयोगकर्ता के रूप में लॉग इन कर सकते हैं, और जो कुछ भी वे करना चाहते हैं, वह करें, लेकिन क्या वास्तव में उन्हें कोई अतिरिक्त अनुमति देगा जो उनके पास पहले से नहीं है डोमेन व्यवस्थापक होने का पुण्य?

अपडेट करें:

अब तक के जवाबों ने "ट्यूनिंग" या उपयोगकर्ता की प्रोफ़ाइल को बदलने का उल्लेख किया है। हालाँकि, डिफ़ॉल्ट प्रोफ़ाइल को संशोधित करने पर Microsoft का यह लेख है जो उपयोगकर्ताओं को पहली बार लॉग ऑन करने पर लागू होता है और किसी भी समय किसी अन्य उपयोगकर्ता की Windows रजिस्ट्री सेटिंग्स बदलने के लिए ये निर्देश । एक उपयोगकर्ता के रूप में लॉग इन करते समय एक व्यवस्थापक क्या बदलेगा कि व्यवस्थापक इन या अन्य उपलब्ध तकनीकों का उपयोग करके नहीं बदल सकता है जो उपयोगकर्ता के रूप में लॉगिंग को शामिल नहीं करता है? उपयोगकर्ता के पासवर्ड पूछने या बदलने के लिए बस "उपयोगकर्ता के रूप में लॉगिंग" एक कारण नहीं है। मैं ऐसा करने के लिए एक व्यावहारिक कारण की तलाश कर रहा हूं ।

windows domain

— इसहाक ट्रुइट
स्रोत

2

यह प्रश्न पूछने से पहले मेरा संदेह यह था कि, हालांकि, विंडोज प्रशासन कई बार हो सकता है, लेकिन ऐसा कुछ भी नहीं था जो किसी व्यवस्थापक के लिए असंभव हो, जो कम-विशेषाधिकार प्राप्त अंतिम उपयोगकर्ता के लिए संभव होगा। उपयोगकर्ता का पासवर्ड पूछने, या उनका पासवर्ड बदलने के लिए प्रेरक, और उनके खाते में लॉग इन करना अनुभवहीनता या सुविधा होगी; या तो व्यवस्थापक यह नहीं जानता कि कुछ कैसे करना है या रजिस्ट्रियों और संपादन कॉन्फ़िगरेशन फ़ाइलों को हाथ से नहीं करना चाहता है और आवश्यक परिवर्तन करने के लिए उपकरण उपलब्ध नहीं है।

— इसहाक ट्रोट

1

आप इस प्रश्न को फिर से लिखना चाहते हैं क्योंकि पहले तो आप उपयोगकर्ता के पासवर्ड के बारे में पूछते हैं, फिर आप लॉगिंग के रूप में उपयोगकर्ता के रूप में बदलते हैं। ये 2 अलग मुद्दे हैं

— जिम बी

उपयोगकर्ता के आउटलुक प्रोफाइल (आउटलुक का उपयोग करने वाले एक सीआरएम ऐप की तरह) तक पहुंचने के लिए एक एप्लिकेशन इंस्टॉल करने के बारे में कैसे? आप एप्लिकेशन डेवलपर की इंस्टॉलर स्क्रिप्ट की दया पर हैं।

— ग्रेवीफेस

@ जय दरअसल, मैंने अपने मूल प्रश्न के दूसरे वाक्य में पासवर्ड रीसेट एवेन्यू को बंद करने की कोशिश की। यदि आप किसी उपयोगकर्ता का पासवर्ड रीसेट करते हैं, तो अब आपके पास उस उपयोगकर्ता का पासवर्ड है। आपके पास उनका OLD पासवर्ड नहीं है। मुझे उपयोगकर्ता की प्रोफ़ाइल बदलने के बारे में अस्पष्ट उत्तर मिल रहे थे, इसलिए मैंने यह दिखाते हुए लिंक प्रदान किए कि आप उपयोगकर्ता को प्रतिरूपण किए बिना ऐसा कैसे कर सकते हैं। मुझे विशेष रूप से "उपयोगकर्ता के रूप में लॉगिंग" के रूप में भी जाना जाता है, क्योंकि यह एक स्वीकार्य अंतिम लक्ष्य नहीं है क्योंकि टिप्पणी में उल्लेख किया गया था कि आप उपयोगकर्ता के पासवर्ड को बदलने / बदलने के बिना कुछ भी नहीं कर सकते।

— इसहाक ट्रोट

@gravyface तो आपका जवाब है "खराब लिखे गए सॉफ़्टवेयर को स्थापित करने के लिए?" दिलचस्प। उत्तर के रूप में पोस्ट करने के लिए देखभाल?

— इसहाक ट्रोट

12

किसी उपयोगकर्ता के पासवर्ड का अनुरोध करने के लिए व्यवस्थापक के लिए यह न तो स्वीकार्य है और न ही आवश्यक है।

उन परिस्थितियों में जहां व्यवस्थापक के लिए उपयोगकर्ता के रूप में लॉग इन करना आवश्यक हो सकता है (और मुझे विश्वास नहीं है कि ऐसी परिस्थितियां मौजूद हैं), उपयोगकर्ता को व्यवस्थापक की गतिविधियों में लॉग इन करना चाहिए और पर्यवेक्षण करना चाहिए।

इसका कारण जवाबदेही है। यह सुनिश्चित करना प्रत्येक उपयोगकर्ता की जिम्मेदारी है कि उनका पासवर्ड सुरक्षित हो। यदि दुर्भावनापूर्ण गतिविधि को किसी उपयोगकर्ता के क्रेडेंशियल में वापस ट्रेस किया गया था, तो उस उपयोगकर्ता को जवाबदेह ठहराया जा सकता है। इसलिए उन्हें यह सुनिश्चित करने की आवश्यकता है कि उनकी साख सुरक्षित रहे।

यह सुनिश्चित करना भी संगठन की जिम्मेदारी है कि इसे न केवल अपनाया जाए, बल्कि इसे लागू किया जाए। एक कानूनी मामला था जहां किसी संगठन में किसी ने किसी और के मेलबॉक्स का उपयोग करके एक दुर्भावनापूर्ण ईमेल भेजा था। मेलबॉक्स के स्वामी को अंततः खारिज कर दिया गया था। जबकि उन्होंने तर्क दिया कि उन्होंने अपना पासवर्ड किसी और को दिया था, कंपनी ने जोर देकर कहा कि यह उनकी जिम्मेदारी है कि वे अपनी साख की अखंडता बनाए रखें, और इसलिए वे जवाबदेह थे, जैसा कि उनकी कंपनी आईटी नीति द्वारा तय किया गया था। यह तब अदालत द्वारा पलट दिया गया जब इस उपयोगकर्ता ने साबित कर दिया कि संगठन के भीतर पासवर्ड साझा करने की संस्कृति थी। अदालत ने फैसला दिया कि अगर कंपनी को अपनी आईटी नीति को सक्रिय रूप से लागू करने के लिए नहीं देखा जा सकता है, तो वे इन परिस्थितियों में जवाबदेही के लिए उस पर भरोसा नहीं कर सकते हैं।

यह कहा कि सिद्धांत और व्यवहार के बीच स्पष्ट रूप से एक अंतर है। मैंने एक प्रमुख बहु-राष्ट्रीय फर्म के लिए अनुबंध किया है, जो अन्य चीजों, आईटी सलाहकार सेवाओं और एसओई अपग्रेड के लिए प्रलेखित प्रक्रिया के हिस्से के रूप में हमें अंत उपयोगकर्ता के पासवर्ड का अनुरोध करने का निर्देश दिया गया था।

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

— मैट
स्रोत

5

क्या आप गंभीरता से सुझाव दे रहे हैं कि आप जानते हैं कि ग्रह पर हर बोधगम्य स्थिति में क्या स्वीकार्य या आवश्यक है?

— जॉन गार्डनियर्स

3

बिल्कुल नहीं - अगर कोई मुझे इसके विपरीत उदाहरण दे सकता है तो मैं खुशी से इसे स्वीकार करूंगा। मैं ग्रह पर हर बोधगम्य स्थिति के बारे में बात नहीं कर रहा हूं, लेकिन इसके साथ ही मैंने कहा कि मैं संभवतः किसी भी लक्ष्य की कल्पना नहीं कर सकता हूं जो केवल उपयोगकर्ता के लॉगिन क्रेडेंशियल से समझौता करके प्राप्त करने योग्य है।

— मैट

2

आप "बेशक नहीं" कहते हैं, जो आपके उत्तर के पहले वाक्य को पूरी तरह से अमान्य कर देता है। मेरा सुझाव है कि आप इसे तदनुसार संपादित करें।

— जॉन गार्डनियर्स

7

शायद मैं स्पष्ट नहीं था। मैं एक वैज्ञानिक दृष्टिकोण ले रहा हूं। सिर्फ इसलिए कि पिछले पांच अरब वर्षों से हर दिन सूरज उगता है इसका मतलब यह नहीं है कि मैं पूरी निश्चय के साथ कह सकता हूं कि यह कल उठेगा। लेकिन अगर आप मुझसे पूछते हैं, "क्या कल सूरज निकलेगा?", मैं आगे योग्य होने की आवश्यकता महसूस किए बिना हां कहूंगा। तो मैं आपके प्रश्न को "ग्रह पर हर बोधगम्य स्थिति" के बारे में लेता हूं, समान रूप से काल्पनिक और सार योग्यता के लिए।

— मैट

3

मेरे सिर से नया उपयोगकर्ता सेटअप दिमाग में आता है - और आपका दिमाग स्पष्ट रूप से यहाँ अटक जाता है। नया उपयोगकर्ता = "किसी उपयोगकर्ता के पास पासवर्ड नहीं है", इसलिए आईटी उपयोगकर्ता को सेट करता है, फिर उपयोगकर्ता को पासवर्ड देता है (जो तुरंत बदल जाता है)। वे उपयोगकर्ता से कभी नहीं पूछते क्योंकि - इस बिंदु पर उपयोगकर्ता पासवर्ड नहीं जानता है।

— टॉमटॉम

18

आइए स्पष्ट हों: यदि आप एक डोमेन व्यवस्थापक हैं, तो आप सॉफ़्टवेयर का एक टुकड़ा स्थापित कर सकते हैं - एक डिवाइस ड्राइवर के दिमाग में आता है - वह सचमुच कुछ भी कर सकता है। हालांकि, यह अव्यावहारिक की अलग-अलग डिग्री है, "डेस्कटॉप पृष्ठभूमि के लिए रजिस्ट्री कुंजी क्या है, फिर से?" "और फिर हम एन्क्रिप्टेड-प्रोफाइल लेयर के अंदर फाइल रीड कॉल पर हुक लगाते हैं ताकि फ़ायरफ़ॉक्स को यह सोचकर ख़राब किया जा सके कि उनके पास डबलक्लिक से कुकीज़ अक्षम हैं"।

आप एक निरपेक्ष के लिए पूछ रहे हैं, और मुझे लगता है कि यह देखने का गलत तरीका है, क्योंकि इसका उत्तर "आपको उपयोगकर्ता के पासवर्ड की आवश्यकता नहीं है, वास्तव में ," जो बहुत भ्रामक है। वास्तविकता यह है कि जब तक Microsoft * NIX su/ जैसी क्षमता प्रदान करने के लिए (या आप थर्ड-पार्टी सॉफ़्टवेयर स्थापित करते हैं) तब तक sudo, आप कभी-कभार आवश्यकता के बिना, पवित्रता की झलक बनाए रखते हुए सभी उद्देश्यों के लिए उपयोगकर्ता के खाते की पूरी तरह से नकल नहीं कर पाएंगे। उपयोग-नोट मैंने उनके पासवर्ड का "प्रकटीकरण" नहीं कहा।

— BMDan
स्रोत

एक बहुत ही उचित बिंदु। एक बिंदु जो मैं अपने संक्षिप्त रूप से हटाए गए उत्तर में बना रहा था, वह यह था कि इस क्षेत्र में टूल सपोर्ट की कमी प्रतीत होती है।

— इसहाक ट्रोट

जहाँ तक यह जाता है कि सूडो के बिंदु पर, विंडोज़ सुरक्षा मॉडल एक sudo प्रकार की उपयोगिता का उपयोग करता है, क्योंकि इसका मतलब है कि आप किसी अन्य उपयोगकर्ता के संदर्भ में उस उपयोगकर्ता के रूप में प्रमाणिकता के बिना अनुप्रयोग चला सकते हैं (इसके चारों ओर तरीके हैं लेकिन वे सभी सुरक्षा मॉडल के चारों ओर जाने का प्रयास करते हैं)।

— जिम बी

1

+1 - यह उत्तर वास्तविकता, साथ ही सिद्धांत को कवर करता है।

— जॉन गार्डनियर्स

8

हम में से कई ने ऐसे वातावरण में काम किया है जहाँ विभिन्न कारणों से पासवर्ड प्रकटीकरण आवश्यक था। मैं यहां तक कहूंगा कि हम सभी इसे एक बुरा विचार मानते हैं। अगर ऐसी जरूरत पड़ती है, तो अंतिम उपयोगकर्ता को सहमति देने की जरूरत है, जबरदस्ती नहीं।

दिन में वापस, 1998 की तरह, मेरा आईटी विभाग एक उपयोगकर्ता के पासवर्ड का अनुरोध करता था जब हम एक पीसी प्रतिस्थापन कर रहे थे, तो हम इसे ठीक उसी तरह सेट कर सकते थे जैसे कि उनका पुराना था। आइकन स्थानों के नीचे। जैसा कि हम बिना किसी WinNT डोमेन के नोवेल नेटवेअर वातावरण में थे, उनके नेटवर्क पासवर्ड को बदलने से उनके स्थानीय पासवर्ड में बदलाव नहीं हुआ, इसलिए हमें उस पासवर्ड को रखने की आवश्यकता थी यदि हम उस स्तर की सहज सेवा प्रदान करना चाहते थे।

वह 13 साल पहले था। आपने विशेष रूप से विंडोज डोमेन के बारे में पूछा है। एक बड़े विश्वविद्यालय में मैंने जो नौकरी छोड़ी थी, उसमें अंत उपयोगकर्ता तक था कि पासवर्ड का खुलासा किया जाए या नहीं, जो भी काम किया जा रहा था, उसके लिए हो। दूसरे शब्दों में, अंत-उपयोगकर्ता ने आईटी द्वारा मजबूर होने के बजाय इसे चुना । ऑर्ग-चार्ट पर कुछ अति व्यस्त कार्यकारी-प्रकार आम तौर पर उनके लिए उनके व्यवस्थापक सहायक लॉग होते थे, इसलिए आईटी लोगों के लिए (सहमति पहले से ही प्रत्यायोजित किया गया था) में खिसकना आसान था।

विंडोज में, उपयोगकर्ता के प्रोफाइल को ट्यून करने का एकमात्र तरीका उस उपयोगकर्ता के रूप में लॉग इन करना है। यदि उस प्रोफ़ाइल को किसी कारण के लिए हाथ-ट्यूनिंग की आवश्यकता होती है (एक खराब स्थापना रद्द बाकी है जो एक पुनर्स्थापना, या अन्य अजीब सामान के रूप में मिल रही है), तो आईटी व्यक्ति को उस उपयोगकर्ता के रूप में लॉग इन करना होगा। यह एक प्रशासनिक पासवर्ड परिवर्तन के लिए मजबूर किया जा सकता है, उपयोगकर्ता अपने पासवर्ड का खुलासा कर सकता है, या उपयोगकर्ता स्वयं के रूप में आईटी व्यक्ति को लॉग इन कर सकता है और आईटी व्यक्ति को काम करने दे सकता है।

— sysadmin1138
स्रोत

आप किस प्रकार की प्रोफाइल ट्यूनिंग कर सकते हैं जो उपयोगकर्ता उस डिफ़ॉल्ट प्रोफ़ाइल को संशोधित करके नहीं कर सकता जैसा कि उपयोगकर्ता द्वारा लॉग करने से पहले यहाँ बताया गया है?

— इसहाक ट्रोट

अधिकांश भाग के लिए, नहीं, अभी भी ऐसी चीजें हैं जिन्हें उस विशिष्ट उपयोगकर्ता के लिए कॉन्फ़िगर करने की आवश्यकता है। उदाहरण के लिए, Outlook 2007 / Exchange 2007 से पहले, आपको उस उपयोगकर्ता के लिए Outlook को मैन्युअल रूप से कॉन्फ़िगर करना होगा। अब ऑटोडिस्कवर के साथ, आप संभवतः उन पर स्वयं प्रयास करने पर विचार कर सकते हैं, लेकिन फिर भी, अधिकांश प्रशासक नहीं चाहेंगे कि उपयोगकर्ता इसे

— तभी

@KContreau Microsoft का कहना है कि आउटलुक प्रोफाइल रजिस्ट्री में संग्रहीत हैं, जिसे एक व्यवस्थापक अपने स्वयं के खाते से संपादित कर सकता है। कोई अन्य विचार?

— इसहाक ट्रोट

4

@IsaacTruett तकनीकी रूप से सब कुछ सीधे regedit के माध्यम से किया जा सकता है या उन Desktop.ini फाइलों को हाथ से संपादित किया जा सकता है। हालांकि, बहुत सारे आईटी लोग UI टूल के साथ अधिक सहज हैं। शॉर्ट-कट के रूप में, बीमार होने की सलाह दी जा सकती है, हालांकि, आईटी व्यक्ति किसी उपयोगकर्ता को मेरे द्वारा बताई गई तीन चीजों में से कोई भी करने के लिए कह सकता है (उनके लिए लॉगिन करें, पासवर्ड रीसेट के माध्यम से जाएं, या पासवर्ड दें) और टूल का उपयोग करें वे अच्छी तरह से जानते हैं, जीयूआई।

— sysadmin1138

1

@KCotreau @Isaac तकनीकी रूप से आप उनकी रजिस्ट्री हाइव को व्यवस्थापक की प्रोफ़ाइल में अस्थायी रूप से कॉपी कर सकते हैं, इसे संपादित करने के लिए जो भी आवश्यक हो, का उपयोग करें, फिर इसे वापस रख दें। 99% मामलों में यह एक अच्छा विचार नहीं है । मुझे बहुत कम परिस्थितियों का पता है जहाँ इन दिनों उपयोगकर्ताओं का पासवर्ड जानना आवश्यक है; और वे सभी गूंगा उपयुक्तता से संबंधित हैं (जैसे नेटवेयर उदाहरण SysAdmin1138 ने दिया)।

— क्रिस एस

5

इंस्टॉलेशन के दौरान कुछ एप्लिकेशन को% userprofile%, जैसे कि HK_CURRENT_USER, और इसी तरह के मॉडिफ़ाइबल% जैसे पर्यावरण चर का उपयोग करके उपयोगकर्ता की प्रोफ़ाइल (यानी आउटलुक के साथ एकीकृत) के संदर्भ में बदलाव करने की क्षमता की आवश्यकता होती है।

जब आप निश्चित रूप से "रिवर्स इंजीनियर" की स्थापना कर सकते हैं, जैसे कि टूल बुलाना और फिर मैन्युअल रूप से उपयोगकर्ता की प्रोफाइल, रजिस्ट्री आदि को संशोधित करना, इस तथ्य के बाद, यह अत्यधिक अक्षम, अव्यवहारिक और त्रुटि प्रवण है।

— gravyface
स्रोत

1

+1। मैं निश्चित रूप से यह एक कारक होने के नाते देख सकता था। एक सॉफ्टवेयर इंजीनियर के रूप में, मैं तर्क दूंगा कि इंस्टॉलेशन प्रक्रियाओं को लिखने के लिए बेहतर तरीके हैं कि स्थापना के दौरान अंतिम उपयोगकर्ता को लॉग इन करने की आवश्यकता होती है। वास्तव में, मौजूदा सॉफ़्टवेयर उत्पाद हैं जो विभिन्न एकल-उपयोगकर्ता और बहु-उपयोगकर्ता स्थापना प्रक्रियाओं के लिए अनुमति देते हैं, जैसे कि Google क्रोम ।

— इसहाक ट्रोट

@ इस्साक, मेरा मानना है कि आपने प्रति उपयोगकर्ता कॉन्फ़िगरेशन के मूलभूत सिद्धांत की अनदेखी की है, जिसे इंस्टॉलर द्वारा ध्यान नहीं दिया जा सकता है। उदाहरण के लिए एक पैकेज लें जिसका उपयोग किसी दिए गए मशीन पर कई उपयोगकर्ताओं द्वारा किया जा रहा है, जहां प्रत्येक उपयोगकर्ता को एक अलग कॉन्फ़िगरेशन की आवश्यकता होती है / चाहिए और उन उपयोगकर्ताओं को पैकेज का उपयोग शुरू करने से पहले उन्हें जगह की आवश्यकता होती है।

— जॉन गार्डनियर्स

@ जॉन / इसहाक: मैं मान रहा हूं, जॉन, आप उपयोगकर्ता की ओर से इस अनुकूलन को पूरा करने की बात कर रहे हैं? यदि हां, तो आप चाहते हैं या उपयोगकर्ता के रूप में लॉग इन करने की आवश्यकता के लिए एक और अच्छा बिंदु है, खासकर यदि कॉन्फ़िगरेशन एप्लिकेशन के बाहर परिवर्तनीय नहीं है (बाइनरी प्रारूप में संग्रहीत) और वर्तमान में उपयोगकर्ता में लॉग इन करने के लिए बाध्य है।

— ग्रेवीफेस

वह सही है। ऐसी स्थिति में उपयोगकर्ता के पासवर्ड को रीसेट करना केवल समस्या का कारण बनता है, साथ ही साथ जो कुछ वे वर्तमान में दूसरी मशीन में कर रहे हैं, उन्हें करने की उनकी क्षमता में हस्तक्षेप करता है।

— जॉन गार्डनियर्स

4

बिल्कुल 100% नहीं। जो कुछ भी अन्य उपयोगकर्ताओं के खाते के साथ किया जाना चाहिए, उन्हें उपयोगकर्ता पासवर्ड रीसेट करके, लॉग इन करके किया जाना चाहिए, और फिर उपयोगकर्ता को हेल्पडेस्क पर कॉल करना या पासवर्ड को कुछ यूथ उपयोगकर्ताओं को आराम करने के लिए कहा जाना चाहिए और पासवर्ड को बदलने के लिए मजबूर करने के लिए खाता सेट करना चाहिए। अगले लॉगिन पर जबकि मैंने स्वीकार किया है कि मैंने किसी को भी अपना पासवर्ड बताने के लिए काफी बड़े और सुरक्षित वातावरण में काम किया है, आमतौर पर समाप्ति के लिए आधार था (और ज्यादातर स्थितियों में यही होना चाहिए)

— जिम बी
स्रोत

1

यह बहुत व्यापक है। ऐसे कई वातावरण हैं जहाँ सिर्फ काम नहीं होगा। मैं शायद 98% के लिए जाऊंगा लेकिन निश्चित रूप से 100% नहीं।

— जॉन गार्डनियर्स

1

@ जॉन क्या आप किसी ऐसी चीज़ का एक विशिष्ट उदाहरण प्रस्तुत कर सकते हैं जिसे अंतिम उपयोगकर्ता के रूप में लॉग इन किए बिना करना असंभव है?

— आइजैक ट्रोट

1

@ आईसैक: कई एप्लिकेशन हैं, जो इंस्टॉलेशन के दौरान, फ़ाइल प्लेसमेंट के लिए संदर्भ% उपयोगकर्ताप्राप्त%, शायद वर्ड या आउटलुक में टूलबार इंस्टॉल करने जैसे बदलाव करते हैं, आदि।, आप वहाँ चल रहे सैल्मन के साथ बैठ सकते हैं, परिश्रम से हर रजिस्ट्री, प्रोफ़ाइल रिकॉर्ड कर सकते हैं। आदि बदल जाते हैं, लेकिन पृथ्वी पर आप क्यों परेशान होंगे?

— ग्रेवीफेस

@ जॉन, क्या आप मुझे एक उदाहरण दे सकते हैं जहां समझाया गया उपयोगकर्ता पासवर्ड रीसेट करना असंभव होगा? मैं सहमत हूँ कि ऐसी जगहें हैं जहाँ उपयोगकर्ता बहुत रूखे हैं या बहुत आलसी भी हैं, लेकिन मुझे अभी भी ऐसी जगह का सामना करना पड़ रहा है जहाँ वह काम नहीं कर सकता।

— जिम बी

1

@Jim, जहां मैं काम करता हूं, हमें अक्सर दूसरों के रूप में लॉग ऑन करने की आवश्यकता होती है और पासवर्ड रीसेट करना बस लोगों को अच्छे कारण के बिना बंद कर देता है। हमारे पास एक ऐसा वातावरण है जहां पासवर्ड (अधिकांश उपयोगकर्ताओं के लिए) कंपनी के भीतर गुप्त नहीं हैं। मुझे पता है कि जो भी बड़ी कंपनियों में काम करता है उसके लिए अनाज के खिलाफ जाता है और जब मैंने यहां शुरुआत की तो मेरे लिए यह एक वास्तविक संस्कृति झटका था। यह एक प्रबंधन पसंद है, मेरा नहीं है, और वह है।

— जॉन गार्डनियर्स

3

इनमें से अधिकांश पद काफी पुराने प्रतीत होते हैं, लेकिन उम्मीद है कि कुछ जानकार अभी भी थ्रेड पर सक्रिय हैं, क्योंकि यह वर्तमान विषय के रूप में जारी रहेगा।

तर्क निश्चित रूप से किया जा सकता है कि आपको कभी भी पासवर्ड का अनुरोध नहीं करना चाहिए । मैं अपने उपयोगकर्ताओं को "कभी साझा न करना" बताना पसंद करूंगा ... और हां, कॉन्फ़िगरेशन उन मामलों में हो सकता है, जो किसी उपयोगकर्ता के लिए व्यवस्थापक द्वारा नियंत्रित किए जा सकते हैं। लेकिन समस्या निवारण एक और मामला है।

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

स्मार्टकार्ड के बारे में क्या? क्या 2010-201 AD के वातावरण में कोई व्यवहार्यता है कि एक स्मार्टकार्ड को डोमेन खाते के साथ (अस्थायी रूप से) जोड़ा जा सकता है? यह विशेष रूप से उनके पासवर्ड को उजागर नहीं करते हुए पूरी वास्तविकता में उपयोगकर्ता के खाते तक पहुंच की अनुमति देगा। समस्या निवारण पूर्ण होने पर कार्ड को तब निष्क्रिय किया जा सकता है। तकनीशियन खाते का उपयोग कर सकते हैं, लेकिन कार्डों की अच्छी देखरेख की जा सकती है।

हमने सालों से फिंगरप्रिंट रीडर का उपयोग किया है, लेकिन एक विशिष्ट तकनीक के लिए सेट करने की प्रक्रिया, फिर उस प्रिंट को साफ़ करना संभव नहीं है। मुझे यकीन नहीं है कि यह प्रक्रिया "अधिकृत" करने के लिए कितनी जटिल होगी और फिर किसी विशेष उपयोगकर्ता के लिए स्मार्ट कार्ड को "निष्क्रिय" करेगी, लेकिन ऐसा लगता है कि यह एक सभ्य समझौता हो सकता है।

— JABlaine
स्रोत

StackExchange पारंपरिक मंचों की तुलना में एक अलग मॉडल पर काम करता है जिसमें यह एक चर्चा धागा नहीं है, बल्कि संभावित उत्तर के चयन के बाद एक प्रश्न है। नकारात्मक पक्ष पर यह हमारे एफएक्यू प्रति प्रश्न का एक खराब उदाहरण है ।

— स्कॉट पैक

1

हां: जो कुछ भी उनकी प्रोफ़ाइल के लिए किया जाना चाहिए। जब ऐसा होता है, तो आपको या तो उनका पासवर्ड पता होना चाहिए, या इसे सेट करना होगा, जैसा आपने कहा था। तब वे इसे बदल सकते हैं जब आप कर रहे हैं।

यदि आप उस उपयोगकर्ता के रूप में लॉग इन करते हैं, तो आप उन्हें अतिरिक्त अनुमति नहीं दे रहे हैं। आप उनकी अनुमति से उन्हें लॉग इन कर रहे हैं।

— KCotreau
स्रोत

मुझे इससे हराएं। विशेष रूप से आउटलुक के साथ एकीकृत करने वाले अनुप्रयोगों के बारे में सोच रहा था।

— ग्रेवीफेस

हां, जाहिर है कि आप उपयोगकर्ता को अतिरिक्त अनुमति नहीं दे रहे हैं। सवाल यह है कि एक व्यवस्थापक किसी उपयोगकर्ता की अनुमतियों के साथ क्या कर सकता है कि वे, व्यवस्थापक, अपने स्वयं के व्यवस्थापक अनुमतियों के साथ नहीं कर सकते हैं? तो, एक उपयोगकर्ता की प्रोफ़ाइल के लिए एक व्यवस्थापक क्या करेगा जो वे अपने स्वयं के व्यवस्थापक खाते से नहीं कर सकते हैं?

— आइजैक ट्रोट

आपके प्रश्न का उत्तर जो व्यवस्थापक नहीं कर सकता है: बस उस उपयोगकर्ता के रूप में लॉग इन करें। जब वह उपयोगकर्ता लॉग इन करता है, तभी उस उपयोगकर्ता के साथ संबद्ध प्रोफ़ाइल में परिवर्तन किया जा सकता है। जब आप व्यवस्थापक के रूप में लॉग इन करते हैं, तो आप अपने व्यवस्थापक प्रोफ़ाइल के साथ लॉग इन करते हैं।

— KCotreau

मुझे लगा कि मैंने प्रश्न को गलत बताया है, लेकिन नहीं, आपको प्रोफ़ाइल के लिए कुछ भी करने के लिए उपयोगकर्ताओं के पासवर्ड की आवश्यकता नहीं है।

— जिम बी