
Microsoft Self-Service Password Reset (SSPR) पोर्टल के माध्यम से उपयोगकर्ता खातों और पंजीकृत प्रमाणीकरण विधियों की गणना करें
पंजीकृत सत्यापन विधियों की गणना करने और मजबूत दूसरे कारक की कमी वाली विधियों को चिह्नित करने के लिए Microsoft के Self-Service Password Reset (SSPR) एंडपॉइंट की जांच करें। Entra खातों में उपयोगकर्ता गणना और MFA स्थिति का अनुमान प्रदान करता है।
[!NOTE] अगस्त 2026 तक, Microsoft ने SSPR प्रवाह से लीगेसी CAPTCHA हटा दिया है और इसे बैकएंड थ्रॉटलिंग और व्यवहार-आधारित दुरुपयोग पहचान से बदल दिया है (देखें MC1400824)। Microsoft का रुख है कि बैकएंड नियंत्रण स्वचालित दुरुपयोग का पता लगाने और उसे रोकने के लिए पर्याप्त हैं।
# Install pipx if needed
apt install pipx && pipx ensurepath
# From a local clone
git clone https://github.com/mlcsec/ResetSpy.git
cd ResetSpy
pipx install .
python3 -m venv .venv
pip install -r requirements.txt
# Single acc
resetspy [email protected]
# Email file (one per line)
resetspy emails.txt
# Proxy
resetspy emails.txt --proxy http://127.0.0.1:8080
# Export to CSV with increased delay
resetspy emails.txt --csv results.csv --delay 4
# Full HTTP debug — request/response headers and bodies printed to stderr
resetspy [email protected] -v
| Flag | Default | Description |
|---|---|---|
--delay SECONDS | 2.0 | अनुरोधों के बीच आधार विलंब; जिटर स्वचालित रूप से जोड़ा जाता है |
--retries N | 1 | क्षणिक त्रुटियों पर प्रति खाता अधिकतम पुनः प्रयास |
--proxy URL | प्रॉक्सी; SSL सत्यापन स्वचालित रूप से अक्षम करता है | |
--csv FILE | सभी परिणाम CSV में निर्यात करें | |
-v / --verbose | पूर्ण अनुरोध/प्रतिक्रिया हेडर और बॉडी stderr पर प्रिंट करें |
प्रत्येक अनुरोध के बीच --delay के ऊपर एक यादृच्छिक जिटर जोड़ा जाता है।
429 प्रतिक्रियाओं और नेटवर्क त्रुटियों पर एक्सपोनेंशियल बैक-ऑफ (--retries प्रयासों तक) लागू किया जाता है। डिफ़ॉल्ट विलंब 2 सेकंड है; बड़े बैचों के लिए 4-6 सेकंड तक बढ़ाएँ। User-Agent प्रत्येक अनुरोध पर 16 सामान्य एजेंटों (Windows, macOS, iOS, Android) के पूल से बदला जाता है।
Microsoft का संयुक्त सुरक्षा सूचना पंजीकरण अनुभव, जो 2020 से डिफ़ॉल्ट रूप से सक्षम है, SSPR और MFA दोनों के लिए प्रमाणीकरण विधियों को एक ही प्रवाह में पंजीकृत करता है। व्यवहार में इसका मतलब है कि अधिकांश आधुनिक Entra ID टेनेंट पर, SSPR के माध्यम से दिखाई देने वाली विधियाँ वही विधियाँ हैं जो साइन-इन की सुरक्षा करती हैं। जिस खाते में कोई मजबूत SSPR विधि पंजीकृत नहीं है, वह संभवतः ऐसा खाता है जिसमें कोई मजबूत MFA विधि पंजीकृत नहीं है।
संदर्भ:
SSPR और MFA अलग-अलग रजिस्ट्रियाँ हैं। संयुक्त पंजीकरण उन्हें अधिकांश मामलों में ओवरलैप करता है लेकिन वे एक ही चीज़ नहीं हैं। कोई विधि MFA के लिए मौजूद हो सकती है लेकिन यहाँ दिखाई नहीं दे सकती यदि वह संयुक्त पंजीकरण सक्षम होने से पहले पंजीकृत थी, या यदि व्यवस्थापक ने इसे SSPR नीति से बाहर रखा था।
FIDO2 सुरक्षा कुंजियाँ और प्रमाणपत्र-आधारित प्रमाणीकरण SSPR द्वारा समर्थित नहीं हैं। Microsoft ने इन विधियों को कभी SSPR प्रवाह में नहीं जोड़ा है। जिस उपयोगकर्ता का एकमात्र पंजीकृत कारक FIDO2 कुंजी या स्मार्ट कार्ड है, वह यहाँ बिना किसी विधि के दिखाई देगा — एक गलत नकारात्मक। व्यवहार में यह मानक उपयोगकर्ताओं के लिए दुर्लभ है लेकिन उच्च-सुरक्षा या पासवर्डलेस वातावरण में अधिक सामान्य है।
संदर्भ:
प्रति-विधि नीति बेमेल। व्यवस्थापक MFA साइन-इन के लिए किसी विधि की अनुमति दे सकते हैं लेकिन इसे SSPR नीति से बाहर रख सकते हैं, या इसके विपरीत। उदाहरण के लिए कोई संगठन साइन-इन के लिए authenticator push की अनुमति दे सकता है लेकिन पासवर्ड रीसेट के लिए नहीं। टूल केवल वही देखता है जो SSPR प्रदान करने को तैयार है।
SSPR पूरी तरह से अक्षम (SSPR_0011)। यदि SSPR किसी उपयोगकर्ता के लिए लाइसेंस प्राप्त नहीं है या सक्षम नहीं है, तो एंडपॉइंट ViewSsprNotEnabledInUserPolicy लौटाता है और कोई विधि जानकारी उपलब्ध नहीं होती। खाता मौजूद है और संभवतः MFA कॉन्फ़िगर है, लेकिन यह टूल यह निर्धारित नहीं कर सकता कि क्या।
अतिथि और फ़ेडरेटेड खाते। बाहरी उपयोगकर्ता और B2B अतिथि अपने होम टेनेंट के माध्यम से प्रमाणित होते हैं। संसाधन टेनेंट के SSPR एंडपॉइंट को उनके होम टेनेंट के MFA पंजीकरण में कोई दृश्यता नहीं है और यह ViewFeatureNotAvailable लौटाता है। उनकी MFA स्थिति इस एंडपॉइंट से अदृश्य है।
टेनेंट-व्यापी विधि प्रतिबंध। यदि किसी व्यवस्थापक ने SSPR नीति में किसी विधि वर्ग को अक्षम कर दिया है, तो यह व्यक्तिगत पंजीकरण की परवाह किए बिना किसी भी उपयोगकर्ता को प्रदान नहीं की जाएगी, जिससे "विधि पंजीकृत नहीं" और "विधि अक्षम" के बीच अंतर करना असंभव हो जाता है।
व्यवस्थापक खाते हमेशा SSPR-सक्षम होते हैं। Microsoft की SSPR नीति सेटिंग्स केवल मानक अंतिम उपयोगकर्ताओं पर लागू होती हैं। व्यवस्थापक खाते टेनेंट SSPR नीति की परवाह किए बिना हमेशा स्व-सेवा पासवर्ड रीसेट के लिए सक्षम होते हैं, और Microsoft उनसे दो प्रमाणीकरण विधियाँ पंजीकृत करने की आवश्यकता करता है। यह प्लेटफ़ॉर्म स्तर पर लागू किया जाता है और टेनेंट व्यवस्थापकों द्वारा अक्षम नहीं किया जा सकता।
संदर्भ: SSPR policy documentation
[!IMPORTANT] इसका पुनरावलोकन के लिए एक उपयोगी निहितार्थ है। यदि किसी टेनेंट में मानक उपयोगकर्ताओं के लिए SSPR अक्षम है (
ViewSsprNotEnabledInUserPolicyलौटाते हुए), तो कोई भी खाता जो सफलतापूर्वक विधि चयन स्क्रीन तक पहुँचता है, वह संभवतः एक विशेषाधिकार प्राप्त भूमिका का सदस्य है। जब व्यापक टेनेंट नीति अक्षम हो तो SSPR के माध्यम से सफाई से गणना करने वाले खाते संभावित व्यवस्थापक खातों के रूप में अलग दिखते हैं, और उनकी पंजीकृत विधियाँ तब भी दिखाई देती हैं जब मानक उपयोगकर्ता विधियाँ नहीं दिखतीं। यह उच्च-मूल्य लक्ष्यों और विशेषाधिकार प्राप्त खातों की पहचान की अनुमति देता है जिन्हें आगे के लक्षित हमलों के लिए अलग किया जा सकता है।
| Capability | Supported |
|---|---|
| उपयोगकर्ता गणना (खाता मौजूद है या नहीं) | हाँ |
| SSPR विधि गणना | हाँ |
| MFA विधि अनुमान (संयुक्त पंजीकरण के माध्यम से) | अनुमानित — अधिकांश मानक टेनेंट के लिए विश्वसनीय |
| FIDO2 / प्रमाणपत्र-आधारित MFA पहचान | नहीं |
| अतिथि / फ़ेडरेटेड खाता MFA | नहीं |
| SSPR अक्षम वाले खाते | नहीं (खाते का अस्तित्व पुष्ट, विधियाँ अज्ञात) |
| व्यवस्थापक खाता पहचान | आंशिक — व्यवस्थापक हमेशा SSPR-सक्षम होते हैं, इसलिए वे तब अलग दिख सकते हैं जब टेनेंट SSPR अन्यथा अक्षम हो |