Translated ['src/pentesting-cloud/azure-security/az-basic-information/RE

src/pentesting-cloud/azure-security/az-basic-information/README.md

@@ -8,10 +8,10 @@
 
 ### Management Groups
 
-- इसमें **अन्य प्रबंधन समूह या सदस्यताएँ** हो सकती हैं।
+- इसमें **अन्य प्रबंधन समूह या सदस्यता** हो सकते हैं।
-- यह **शासन नियंत्रण लागू करने** की अनुमति देता है जैसे RBAC और Azure नीति एक बार प्रबंधन समूह स्तर पर और उन्हें समूह में सभी सदस्यताओं द्वारा **विरासत में** लिया जाता है।
+- यह **शासन नियंत्रण** जैसे RBAC और Azure नीति को प्रबंधन समूह स्तर पर एक बार लागू करने की अनुमति देता है और इन्हें समूह में सभी सदस्यताओं द्वारा **विरासत में** लिया जाता है।
 - **10,000 प्रबंधन** समूह एकल निर्देशिका में समर्थित हो सकते हैं।
-- एक प्रबंधन समूह पेड़ **छह स्तर की गहराई** तक का समर्थन कर सकता है। यह सीमा मूल स्तर या सदस्यता स्तर को शामिल नहीं करती है।
+- एक प्रबंधन समूह का पेड़ **छह स्तर की गहराई** तक का समर्थन कर सकता है। यह सीमा मूल स्तर या सदस्यता स्तर को शामिल नहीं करती है।
 - प्रत्येक प्रबंधन समूह और सदस्यता केवल **एक माता-पिता** का समर्थन कर सकती है।
 - कई प्रबंधन समूह बनाए जा सकते हैं, लेकिन **केवल 1 मूल प्रबंधन समूह** है।
 - मूल प्रबंधन समूह **सभी** **अन्य प्रबंधन समूहों और सदस्यताओं** को **धारण करता है** और **इसे स्थानांतरित या हटाया नहीं जा सकता**।
@@ -28,7 +28,7 @@
 
 ### Resource Groups
 
-[From the docs:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) एक संसाधन समूह एक **कंटेनर** है जो एक Azure समाधान के लिए **संबंधित संसाधनों** को रखता है। संसाधन समूह में समाधान के लिए सभी संसाधन शामिल हो सकते हैं, या केवल वे **संसाधन जिन्हें आप समूह के रूप में प्रबंधित करना चाहते हैं**। सामान्यतः, **संसाधनों** को उसी संसाधन समूह में जोड़ें जो **एक ही जीवन चक्र** साझा करते हैं ताकि आप उन्हें समूह के रूप में आसानी से तैनात, अपडेट और हटा सकें।
+[From the docs:](https://learn.microsoft.com/en-us/azure/azure-resource-manager/management/manage-resource-groups-python?tabs=macos#what-is-a-resource-group) एक संसाधन समूह एक **कंटेनर** है जो एक Azure समाधान के लिए **संबंधित संसाधनों** को रखता है। संसाधन समूह में समाधान के लिए सभी संसाधन शामिल हो सकते हैं, या केवल वे **संसाधन जिन्हें आप समूह के रूप में प्रबंधित करना चाहते हैं**। सामान्यतः, **संसाधनों** को उसी संसाधन समूह में जोड़ें जो **एक ही जीवनचक्र** साझा करते हैं ताकि आप उन्हें समूह के रूप में आसानी से तैनात, अपडेट और हटा सकें।
 
 सभी **संसाधन** को **एक संसाधन समूह के भीतर** होना चाहिए और केवल एक समूह का हिस्सा हो सकते हैं और यदि एक संसाधन समूह को हटाया जाता है, तो इसके भीतर सभी संसाधन भी हटा दिए जाते हैं।
 
@@ -50,11 +50,11 @@ Azure Resource ID का प्रारूप इस प्रकार है:
 
 ### Azure
 
-Azure Microsoft का व्यापक **क्लाउड कंप्यूटिंग प्लेटफॉर्म है, जो विभिन्न सेवाओं** की एक विस्तृत श्रृंखला प्रदान करता है, जिसमें वर्चुअल मशीन, डेटाबेस, कृत्रिम बुद्धिमत्ता, और संग्रहण शामिल हैं। यह अनुप्रयोगों को होस्ट और प्रबंधित करने, स्केलेबल बुनियादी ढाँचे बनाने, और क्लाउड में आधुनिक कार्यभार चलाने के लिए आधार के रूप में कार्य करता है। Azure डेवलपर्स और IT पेशेवरों के लिए अनुप्रयोगों और सेवाओं को सहजता से बनाने, तैनात करने और प्रबंधित करने के लिए उपकरण प्रदान करता है, जो स्टार्टअप से लेकर बड़े उद्यमों तक की विभिन्न आवश्यकताओं को पूरा करता है।
+Azure Microsoft का व्यापक **क्लाउड कंप्यूटिंग प्लेटफॉर्म है, जो विभिन्न सेवाओं** की एक विस्तृत श्रृंखला प्रदान करता है, जिसमें वर्चुअल मशीन, डेटाबेस, कृत्रिम बुद्धिमत्ता और स्टोरेज शामिल हैं। यह अनुप्रयोगों को होस्ट और प्रबंधित करने, स्केलेबल बुनियादी ढाँचे का निर्माण करने और क्लाउड में आधुनिक कार्यभार चलाने के लिए आधार के रूप में कार्य करता है। Azure डेवलपर्स और IT पेशेवरों के लिए अनुप्रयोगों और सेवाओं को सहजता से बनाने, तैनात करने और प्रबंधित करने के लिए उपकरण प्रदान करता है, जो स्टार्टअप से लेकर बड़े उद्यमों तक की विभिन्न आवश्यकताओं को पूरा करता है।
 
 ### Entra ID (formerly Azure Active Directory)
 
-Entra ID एक क्लाउड-आधारित **पहचान और पहुंच प्रबंधन सेवा** है जिसे प्रमाणीकरण, प्राधिकरण, और उपयोगकर्ता पहुंच नियंत्रण को संभालने के लिए डिज़ाइन किया गया है। यह Office 365, Azure, और कई तीसरे पक्ष के SaaS अनुप्रयोगों जैसी Microsoft सेवाओं तक सुरक्षित पहुंच को सक्षम करता है। इसमें एकल साइन-ऑन (SSO), बहु-कारक प्रमाणीकरण (MFA), और शर्तीय पहुंच नीतियों जैसी सुविधाएँ शामिल हैं।
+Entra ID एक क्लाउड-आधारित **पहचान और पहुंच प्रबंधन सेवा** है जिसे प्रमाणीकरण, प्राधिकरण और उपयोगकर्ता पहुंच नियंत्रण को संभालने के लिए डिज़ाइन किया गया है। यह Office 365, Azure और कई तीसरे पक्ष के SaaS अनुप्रयोगों जैसी Microsoft सेवाओं तक सुरक्षित पहुंच को सक्षम करता है। इसमें एकल साइन-ऑन (SSO), बहु-कारक प्रमाणीकरण (MFA), और शर्तीय पहुंच नीतियों जैसी सुविधाएँ शामिल हैं।
 
 ### Entra Domain Services (formerly Azure AD DS)
 
@@ -79,7 +79,7 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
 
 आप उन्हें [https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions](https://learn.microsoft.com/en-us/entra/fundamentals/users-default-permissions) में देख सकते हैं लेकिन अन्य कार्यों के बीच एक सदस्य सक्षम होगा:
 
-- सभी उपयोगकर्ताओं, समूहों, अनुप्रयोगों, उपकरणों, भूमिकाओं, सदस्यताओं, और उनके सार्वजनिक गुणों को पढ़ें
+- सभी उपयोगकर्ताओं, समूहों, अनुप्रयोगों, उपकरणों, भूमिकाओं, सदस्यताओं और उनके सार्वजनिक गुणों को पढ़ें
 - अतिथियों को आमंत्रित करें (_बंद किया जा सकता है_)
 - सुरक्षा समूह बनाएं
 - गैर-छिपे समूह सदस्यताओं को पढ़ें
@@ -123,7 +123,7 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
 यहाँ **2 प्रकार के समूह** हैं:
 
 - **सुरक्षा**: इस प्रकार के समूह का उपयोग सदस्यों को अनुप्रयोगों, संसाधनों तक पहुंच देने और लाइसेंस असाइन करने के लिए किया जाता है। उपयोगकर्ता, उपकरण, सेवा प्रमुख और अन्य समूह सदस्य हो सकते हैं।
-- **Microsoft 365**: इस प्रकार के समूह का उपयोग सहयोग के लिए किया जाता है, सदस्यों को एक साझा मेलबॉक्स, कैलेंडर, फ़ाइलें, SharePoint साइट, आदि तक पहुंच प्रदान करता है। समूह के सदस्य केवल उपयोगकर्ता हो सकते हैं।
+- **Microsoft 365**: इस प्रकार के समूह का उपयोग सहयोग के लिए किया जाता है, सदस्यों को साझा मेलबॉक्स, कैलेंडर, फ़ाइलें, SharePoint साइट, आदि तक पहुंच प्रदान करता है। समूह के सदस्य केवल उपयोगकर्ता हो सकते हैं।
 - इसका एक **ईमेल पता** होगा जो EntraID टेनेट के डोमेन के साथ होगा।
 
 यहाँ **2 प्रकार की सदस्यताएँ** हैं:
@@ -148,8 +148,8 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
 
 1. **Application ID (Client ID):** Azure AD में आपके ऐप के लिए एक अद्वितीय पहचानकर्ता।
 2. **Redirect URIs:** URLs जहां Azure AD प्रमाणीकरण प्रतिक्रियाएँ भेजता है।
-3. **Certificates, Secrets & Federated Credentials:** एक गुप्त या प्रमाणपत्र उत्पन्न करना संभव है ताकि अनुप्रयोग के सेवा प्रमुख के रूप में लॉगिन किया जा सके, या इसके लिए संघीय पहुंच प्रदान की जा सके (जैसे Github Actions)।
+3. **Certificates, Secrets & Federated Credentials:** यह संभव है कि एक गुप्त या प्रमाणपत्र उत्पन्न किया जाए ताकि अनुप्रयोग के सेवा प्रमुख के रूप में लॉगिन किया जा सके, या इसके लिए संघीय पहुंच प्रदान की जा सके (जैसे Github Actions)।
-1. यदि एक **प्रमाणपत्र** या **गुप्त** उत्पन्न किया जाता है, तो किसी व्यक्ति के लिए **CLI उपकरणों के साथ सेवा प्रमुख के रूप में लॉगिन करना संभव है** यदि वह **अनुप्रयोग ID**, **गुप्त** या **प्रमाणपत्र** और **टेनेट** (डोमेन या ID) को जानता है।
+1. यदि एक **प्रमाणपत्र** या **गुप्त** उत्पन्न किया जाता है, तो यह संभव है कि एक व्यक्ति **सेवा प्रमुख के रूप में लॉगिन** CLI उपकरणों के साथ कर सके, **अनुप्रयोग ID**, **गुप्त** या **प्रमाणपत्र** और **टेनेट** (डोमेन या ID) को जानकर।
 4. **API Permissions:** निर्दिष्ट करता है कि ऐप किन संसाधनों या APIs तक पहुंच प्राप्त कर सकता है।
 5. **Authentication Settings:** ऐप के समर्थित प्रमाणीकरण प्रवाह को परिभाषित करता है (जैसे, OAuth2, OpenID Connect)।
 6. **Service Principal**: जब एक ऐप बनाई जाती है (यदि इसे वेब कंसोल से किया गया हो) या जब इसे एक नए टेनेट में स्थापित किया जाता है, तो एक सेवा प्रमुख बनाया जाता है।
@@ -161,21 +161,21 @@ Entra Domain Services Entra ID की क्षमताओं को बढ़
 
 - **उपयोगकर्ता सहमति की अनुमति न दें**
 - सभी ऐप्स के लिए एक प्रशासक की आवश्यकता होगी।
-- **सत्यापित प्रकाशकों से ऐप्स के लिए चयनित अनुमतियों के लिए उपयोगकर्ता सहमति की अनुमति दें (अनुशंसित)**
+- **सत्यापित प्रकाशकों, आंतरिक ऐप्स, और केवल चयनित अनुमतियों के लिए अनुरोध करने वाले ऐप्स के लिए उपयोगकर्ता सहमति की अनुमति दें (अनुशंसित)**
-- सभी उपयोगकर्ता "कम प्रभाव" के रूप में वर्गीकृत अनुमतियों के लिए सहमति दे सकते हैं, सत्यापित प्रकाशकों से ऐप्स के लिए या इस संगठन में पंजीकृत ऐप्स के लिए।
+- सभी उपयोगकर्ता केवल उन ऐप्स के लिए सहमति दे सकते हैं जो केवल "कम प्रभाव" के रूप में वर्गीकृत अनुमतियाँ मांगते हैं, सत्यापित प्रकाशकों से ऐप्स और टेनेट में पंजीकृत ऐप्स।
 - **डिफ़ॉल्ट** कम प्रभाव वाली अनुमतियाँ (हालांकि आपको उन्हें कम के रूप में जोड़ने के लिए स्वीकार करना होगा):
 - User.Read - साइन इन करें और उपयोगकर्ता प्रोफ़ाइल पढ़ें
-- offline_access - डेटा तक पहुंच बनाए रखें जिसे उपयोगकर्ताओं ने इसे एक्सेस करने की अनुमति दी है
+- offline_access - डेटा तक पहुंच बनाए रखें जिसे उपयोगकर्ताओं ने इसे पहुंच प्रदान की है
 - openid - उपयोगकर्ताओं को साइन इन करें
 - profile - उपयोगकर्ता की मूल प्रोफ़ाइल देखें
 - email - उपयोगकर्ता के ईमेल पते को देखें
 - **ऐप्स के लिए उपयोगकर्ता सहमति की अनुमति दें (डिफ़ॉल्ट)**
-- सभी उपयोगकर्ता किसी भी ऐप को संगठन के डेटा तक पहुंच प्राप्त करने के लिए सहमति दे सकते हैं।
+- सभी उपयोगकर्ता किसी भी ऐप के लिए संगठन के डेटा तक पहुंच प्राप्त करने के लिए सहमति दे सकते हैं।
 
 **Admin consent requests**: डिफ़ॉल्ट **नहीं**
 
 - उपयोगकर्ता उन ऐप्स के लिए प्रशासक सहमति का अनुरोध कर सकते हैं जिनके लिए वे सहमति नहीं दे सकते
-- यदि **हाँ**: यह संभव है कि उपयोगकर्ताओं, समूहों और भूमिकाओं को संकेतित किया जाए जो अनुरोधों के लिए सहमति दे सकते हैं
+- यदि **हाँ**: यह संभव है कि उपयोगकर्ताओं, समूहों और भूमिकाओं को संकेतित किया जाए जो अनुरोधों पर सहमति दे सकते हैं
 - यह भी कॉन्फ़िगर करें कि क्या उपयोगकर्ताओं को ईमेल सूचनाएँ और समाप्ति अनुस्मारक प्राप्त होंगे
 
 ### **Managed Identity (Metadata)**
@@ -184,10 +184,10 @@ Azure Active Directory में प्रबंधित पहचानें
 
 प्रबंधित पहचान के दो प्रकार हैं:
 
-- **सिस्टम-निर्धारित**। कुछ Azure सेवाएँ आपको **सेवा उदाहरण पर सीधे प्रबंधित पहचान सक्षम करने** की अनुमति देती हैं। जब आप एक सिस्टम-निर्धारित प्रबंधित पहचान सक्षम करते हैं, तो Entra ID टेनेट में एक **सेवा प्रमुख** बनाया जाता है जिसे उस सदस्यता द्वारा विश्वसनीय किया जाता है जहां संसाधन स्थित है। जब **संसाधन** को **हटाया** जाता है, Azure स्वचालित रूप से आपके लिए **पहचान** को **हटा देता है**।
+- **सिस्टम-निर्धारित**। कुछ Azure सेवाएँ आपको **सेवा उदाहरण पर सीधे प्रबंधित पहचान सक्षम करने** की अनुमति देती हैं। जब आप एक सिस्टम-निर्धारित प्रबंधित पहचान सक्षम करते हैं, तो Entra ID टेनेट में एक **सेवा प्रमुख** बनाया जाता है जो उस सदस्यता द्वारा विश्वसनीय होता है जहां संसाधन स्थित है। जब **संसाधन** को **हटाया** जाता है, तो Azure स्वचालित रूप से आपके लिए **पहचान** को **हटा** देता है।
-- **उपयोगकर्ता-निर्धारित**। उपयोगकर्ताओं के लिए प्रबंधित पहचान उत्पन्न करना भी संभव है। ये एक सदस्यता के भीतर एक संसाधन समूह के अंदर बनाई जाती हैं और EntraID में एक सेवा प्रमुख बनाया जाएगा जिसे सदस्यता द्वारा विश्वसनीय किया जाता है। फिर, आप प्रबंधित पहचान को Azure सेवा के एक या **अधिक उदाहरणों** (कई संसाधनों) को असाइन कर सकते हैं। उपयोगकर्ता-निर्धारित प्रबंधित पहचान के लिए, **पहचान उन संसाधनों से अलग से प्रबंधित की जाती है जो इसका उपयोग करती हैं**।
+- **उपयोगकर्ता-निर्धारित**। उपयोगकर्ताओं के लिए प्रबंधित पहचान उत्पन्न करना भी संभव है। ये एक सदस्यता के भीतर एक संसाधन समूह के अंदर बनाई जाती हैं और EntraID द्वारा विश्वसनीय सदस्यता में एक सेवा प्रमुख बनाया जाएगा। फिर, आप प्रबंधित पहचान को Azure सेवा के एक या **अधिक उदाहरणों** (कई संसाधनों) में असाइन कर सकते हैं। उपयोगकर्ता-निर्धारित प्रबंधित पहचान के लिए, **पहचान उन संसाधनों से अलग से प्रबंधित की जाती है जो इसका उपयोग करती हैं**।
 
-प्रबंधित पहचान **स्थायी क्रेडेंशियल्स** (जैसे पासवर्ड या प्रमाणपत्र) उत्पन्न नहीं करती हैं ताकि सेवा प्रमुख से जुड़े इसे एक्सेस किया जा सके।
+प्रबंधित पहचान **स्थायी क्रेडेंशियल्स** (जैसे पासवर्ड या प्रमाणपत्र) उत्पन्न नहीं करती हैं ताकि सेवा प्रमुख से एक्सेस किया जा सके।
 
 ### Enterprise Applications
 
@@ -205,9 +205,9 @@ Azure Active Directory में प्रबंधित पहचानें
 - कार्यान्वयन:
 - प्रत्येक क्षेत्र के लिए प्रशासनिक इकाइयाँ बनाएं (जैसे, "उत्तरी अमेरिका AU", "यूरोप AU")।
 - अपने संबंधित क्षेत्रों के उपयोगकर्ताओं के साथ AUs को भरें।
-- AUs **उपयोगकर्ताओं, समूहों, या उपकरणों** को **धारण कर सकते हैं**
+- AUs **उपयोगकर्ताओं, समूहों, या उपकरणों** को शामिल कर सकते हैं
 - AUs **डायनामिक सदस्यताओं** का समर्थन करते हैं
-- AUs **AUs को नहीं रख सकते**
+- AUs **AUs को शामिल नहीं कर सकते**
 - प्रशासक भूमिकाएँ असाइन करें:
 - क्षेत्रीय IT स्टाफ को "उपयोगकर्ता प्रशासक" भूमिका दें, जो उनके क्षेत्र के AU तक सीमित हो।
 - परिणाम: क्षेत्रीय IT प्रशासक अपने क्षेत्र के भीतर उपयोगकर्ता खातों का प्रबंधन कर सकते हैं बिना अन्य क्षेत्रों को प्रभावित किए।
@@ -215,48 +215,48 @@ Azure Active Directory में प्रबंधित पहचानें
 ### Entra ID Roles & Permissions
 
 - Entra ID का प्रबंधन करने के लिए कुछ **निर्मित भूमिकाएँ** हैं जिन्हें Entra ID प्रमुखों को Entra ID का प्रबंधन करने के लिए असाइन किया जा सकता है
-- भूमिकाएँ देखें [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference)
+- भूमिकाएँ [https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference) में जांचें
 - EntraID द्वारा **`PRIVILEGED`** के रूप में चिह्नित भूमिकाएँ सावधानी से असाइन की जानी चाहिए क्योंकि Microsoft [दस्तावेज़ों में समझाता है](https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/permissions-reference): विशेषाधिकार प्राप्त भूमिका असाइनमेंट का उपयोग सुरक्षित और इच्छित तरीके से नहीं किया गया तो विशेषाधिकार में वृद्धि हो सकती है।
 - सबसे विशेषाधिकार प्राप्त भूमिका **ग्लोबल एडमिनिस्ट्रेटर** है
-- भूमिकाएँ **सूक्ष्म अनुमतियों** को समूहित करती हैं और उन्हें उनके विवरण में पाया जा सकता है।
+- भूमिकाएँ **सूक्ष्म अनुमतियों** को समूहित करती हैं और इन्हें उनके विवरण में पाया जा सकता है।
 - यह **कस्टम भूमिकाएँ** बनाने के लिए संभव है जिनमें इच्छित अनुमतियाँ हों। हालांकि किसी कारण से सभी सूक्ष्म अनुमतियाँ प्रशासकों को कस्टम भूमिकाएँ बनाने के लिए उपलब्ध नहीं हैं।
-- Entra ID में भूमिकाएँ पूरी तरह से **स्वतंत्र** होती हैं Azure में भूमिकाओं से। केवल संबंध यह है कि Entra ID में **ग्लोबल एडमिनिस्ट्रेटर** भूमिका वाले प्रमुख Azure में **उपयोगकर्ता पहुंच प्रशासक** भूमिका में वृद्धि कर सकते हैं।
+- Entra ID में भूमिकाएँ पूरी तरह से **स्वतंत्र** होती हैं Azure में भूमिकाओं से। केवल संबंध यह है कि Entra ID में **ग्लोबल एडमिनिस्ट्रेटर** भूमिका वाले प्रमुख Azure में **यूजर एक्सेस एडमिनिस्ट्रेटर** भूमिका में वृद्धि कर सकते हैं।
 - Entra ID भूमिकाओं में **वाइल्डकार्ड** का उपयोग करना **संभव नहीं है**।
 
 ## Azure Roles & Permissions
 
 - **भूमिकाएँ** **प्रमुखों** को **स्कोप** पर **असाइन** की जाती हैं: `principal -[HAS ROLE]->(scope)`
 - **भूमिकाएँ** समूहों को असाइन की गई हैं जो समूह के सभी **सदस्यों** द्वारा **विरासत में** ली जाती हैं।
-- जिस स्कोप पर भूमिका असाइन की गई थी, उसके आधार पर, **भूमिका** को स्कोप कंटेनर के भीतर **अन्य संसाधनों** पर **विरासत में** लिया जा सकता है। उदाहरण के लिए, यदि उपयोगकर्ता A के पास **सदस्यता पर एक भूमिका** है, तो उसके पास उस **भूमिका** के सभी संसाधन समूहों के भीतर और संसाधन समूह के भीतर **सभी संसाधनों** पर होगी।
+- जिस स्कोप पर भूमिका असाइन की गई थी, उसके आधार पर, **भूमिका** को स्कोप कंटेनर के भीतर **अन्य संसाधनों** पर **विरासत में** लिया जा सकता है। उदाहरण के लिए, यदि उपयोगकर्ता A के पास **सदस्यता पर एक भूमिका** है, तो उसके पास उस **भूमिका** का अधिकार होगा सभी संसाधन समूहों पर जो सदस्यता के भीतर हैं और **सभी संसाधनों** पर जो संसाधन समूह के भीतर हैं।
 
 ### Built-In roles
 
-[From the docs: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure role-based access control (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) में कई Azure **निर्मित भूमिकाएँ** हैं जिन्हें आप **उपयोगकर्ताओं, समूहों, सेवा प्रमुखों, और प्रबंधित पहचान** को **असाइन** कर सकते हैं। भूमिका असाइनमेंट वह तरीका है जिससे आप **Azure संसाधनों तक पहुंच को नियंत्रित करते हैं**। यदि निर्मित भूमिकाएँ आपकी संगठन की विशिष्ट आवश्यकताओं को पूरा नहीं करती हैं, तो आप अपनी [**Azure कस्टम भूमिकाएँ**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles) बना सकते हैं।
+[From the docs: ](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles)[Azure role-based access control (Azure RBAC)](https://learn.microsoft.com/en-us/azure/role-based-access-control/overview) में कई Azure **निर्मित भूमिकाएँ** हैं जिन्हें आप **उपयोगकर्ताओं, समूहों, सेवा प्रमुखों, और प्रबंधित पहचान** को **असाइन** कर सकते हैं। भूमिका असाइनमेंट वह तरीका है जिससे आप **Azure संसाधनों तक पहुंच को नियंत्रित** करते हैं। यदि निर्मित भूमिकाएँ आपकी संगठन की विशिष्ट आवश्यकताओं को पूरा नहीं करती हैं, तो आप अपनी [**Azure कस्टम भूमिकाएँ**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles) बना सकते हैं।
 
-**निर्मित** भूमिकाएँ केवल उन **संसाधनों** पर लागू होती हैं जिनके लिए वे **निर्धारित** हैं, उदाहरण के लिए, Compute संसाधनों पर **निर्मित भूमिकाओं** के इन 2 उदाहरणों की जांच करें:
+**निर्मित** भूमिकाएँ केवल उन **संसाधनों** पर लागू होती हैं जिनके लिए वे **निर्धारित** हैं, उदाहरण के लिए, **कंप्यूट** संसाधनों पर निर्मित भूमिकाओं के 2 उदाहरण देखें:
 
-| [Disk Backup Reader](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader)                 | बैकअप वॉल्ट को डिस्क बैकअप करने की अनुमति देता है।      | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
+| [Disk Backup Reader](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#disk-backup-reader)                 | बैकअप वॉल्ट को डिस्क बैकअप करने की अनुमति प्रदान करता है।      | 3e5e47e6-65f7-47ef-90b5-e5dd4d455f24 |
 | ----------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------- | ------------------------------------ |
 | [Virtual Machine User Login](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles#virtual-machine-user-login) | पोर्टल में वर्चुअल मशीनों को देखें और एक सामान्य उपयोगकर्ता के रूप में लॉगिन करें। | fb879df8-f326-4884-b1cf-06f3ad86be52 |
 
-ये भूमिकाएँ **तार्किक कंटेनरों** (जैसे प्रबंधन समूह, सदस्यताएँ और संसाधन समूह) पर भी असाइन की जा सकती हैं और प्रभावित प्रमुखों को **उन कंटेनरों के भीतर संसाधनों पर** यह प्राप्त होगा।
+ये भूमिकाएँ **प्रबंधन समूहों, सदस्यताओं और संसाधन समूहों** जैसे तार्किक कंटेनरों पर भी असाइन की जा सकती हैं और प्रभावित प्रमुखों को **उन कंटेनरों के भीतर संसाधनों पर** अधिकार प्राप्त होंगे।
 
-- यहाँ [**सभी Azure निर्मित भूमिकाओं**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles) की एक सूची पाएं।
+- यहाँ [**सभी Azure निर्मित भूमिकाओं**](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles) की सूची पाएं।
-- यहाँ [**सभी Entra ID निर्मित भूमिकाओं**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference) की एक सूची पाएं।
+- यहाँ [**सभी Entra ID निर्मित भूमिकाओं**](https://learn.microsoft.com/en-us/azure/active-directory/roles/permissions-reference) की सूची पाएं।
 
 ### Custom Roles
 
 - यह भी संभव है कि [**कस्टम भूमिकाएँ**](https://learn.microsoft.com/en-us/azure/role-based-access-control/custom-roles) बनाई जाएँ
-- ये एक स्कोप के भीतर बनाई जाती हैं, हालाँकि एक भूमिका कई स्कोप (प्रबंधन समूह, सदस्यता और संसाधन समूह) में हो सकती है
+- ये एक स्कोप के भीतर बनाई जाती हैं, हालाँकि एक भूमिका कई स्कोप (प्रबंधन समूहों, सदस्यता और संसाधन समूहों) में हो सकती है
 - यह संभव है कि कस्टम भूमिका के पास सभी सूक्ष्म अनुमतियों को कॉन्फ़िगर किया जाए
-- यह अनुमतियों को बाहर करने के लिए भी संभव है
+- अनुमतियों को बाहर करना संभव है
 - एक प्रमुख के पास एक बाहर की गई अनुमति नहीं होगी भले ही अनुमति कहीं और दी जा रही हो
 - वाइल्डकार्ड का उपयोग करना संभव है
 - उपयोग किया गया प्रारूप JSON है
-- `actions` संसाधनों पर प्रबंधन संचालन के लिए अनुमतियों को संदर्भित करता है, जैसे संसाधन परिभाषाओं और सेटिंग्स को बनाने, अपडेट करने, या हटाने के लिए।
+- `actions` संसाधनों पर प्रबंधन संचालन के लिए अनुमतियों को संदर्भित करता है, जैसे संसाधन परिभाषाओं और सेटिंग्स को बनाने, अपडेट करने या हटाने।
-- `dataActions` संसाधन के भीतर डेटा संचालन के लिए अनुमतियाँ हैं, जिससे आप संसाधन में निहित वास्तविक डेटा को पढ़ने, लिखने, या हटाने की अनुमति देते हैं।
+- `dataActions` संसाधन के भीतर डेटा संचालन के लिए अनुमतियाँ हैं, जो आपको संसाधन में निहित वास्तविक डेटा को पढ़ने, लिखने या हटाने की अनुमति देती हैं।
 - `notActions` और `notDataActions` भूमिका से विशिष्ट अनुमतियों को बाहर करने के लिए उपयोग किए जाते हैं। हालाँकि, **वे उन्हें अस्वीकार नहीं करते**, यदि एक अलग भूमिका उन्हें प्रदान करती है, तो प्रमुख के पास वे होंगी।
-- `assignableScopes` उन स्कोपों की एक सूची है जहाँ भूमिका को असाइन किया जा सकता है (जैसे प्रबंधन समूह, सदस्यताएँ, या संसाधन समूह)।
+- `assignableScopes` उन स्कोपों की एक सूची है जहां भूमिका को असाइन किया जा सकता है (जैसे प्रबंधन समूह, सदस्यताएँ, या संसाधन समूह)।
 
 कस्टम भूमिका के लिए अनुमतियों का JSON का उदाहरण:
 ```json
@@ -310,9 +310,9 @@ Global Administrator भूमिका वाले उपयोगकर्त
 
 ### Deny Assignments
 
-भूमिका असाइनमेंट की तरह, **deny assignments** का उपयोग **Azure संसाधनों तक पहुँच को नियंत्रित करने के लिए** किया जाता है। हालाँकि, **deny assignments** का उपयोग किसी संसाधन तक पहुँच को **स्पष्ट रूप से अस्वीकार करने** के लिए किया जाता है, भले ही किसी उपयोगकर्ता को भूमिका असाइनमेंट के माध्यम से पहुँच दी गई हो। **Deny assignments** की प्राथमिकता **role assignments** पर होती है, जिसका अर्थ है कि यदि किसी उपयोगकर्ता को भूमिका असाइनमेंट के माध्यम से पहुँच दी गई है लेकिन उसे deny assignment के माध्यम से स्पष्ट रूप से पहुँच से वंचित किया गया है, तो deny assignment की प्राथमिकता होगी।
+भूमिका असाइनमेंट की तरह, **deny assignments** का उपयोग **Azure संसाधनों तक पहुँच को नियंत्रित करने के लिए** किया जाता है। हालाँकि, **deny assignments** का उपयोग किसी resource तक पहुँच को **स्पष्ट रूप से अस्वीकार करने** के लिए किया जाता है, भले ही किसी उपयोगकर्ता को भूमिका असाइनमेंट के माध्यम से पहुँच दी गई हो। **Deny assignments** की प्राथमिकता **भूमिका असाइनमेंट** पर होती है, जिसका अर्थ है कि यदि किसी उपयोगकर्ता को भूमिका असाइनमेंट के माध्यम से पहुँच दी गई है लेकिन उसे deny assignment के माध्यम से स्पष्ट रूप से पहुँच से वंचित किया गया है, तो deny assignment की प्राथमिकता होगी।
 
-भूमिका असाइनमेंट की तरह, **deny assignments** कुछ दायरे पर लागू होते हैं जो प्रभावित होने वाले principals और उन अनुमतियों को इंगित करते हैं जो अस्वीकृत की जा रही हैं। इसके अलावा, deny assignments के मामले में, यह संभव है कि **deny को बच्चों के संसाधनों द्वारा विरासत में प्राप्त होने से रोका जाए**।
+भूमिका असाइनमेंट की तरह, **deny assignments** कुछ दायरे पर लागू होते हैं जो प्रभावित होने वाले principals और उन अनुमतियों को इंगित करते हैं जो अस्वीकृत की जा रही हैं। इसके अलावा, deny assignments के मामले में, यह संभव है कि **deny को बच्चों के संसाधनों द्वारा विरासत में प्राप्त होने से रोका जा सके**।
 
 ### Azure Policies
 
@@ -329,14 +329,14 @@ Azure Policies **proactive** हैं: वे अनुपालन न कर
 
 **कुछ उदाहरण:**
 
-1. **Specific Azure Regions के साथ अनुपालन सुनिश्चित करना**: यह नीति सुनिश्चित करती है कि सभी संसाधन विशिष्ट Azure क्षेत्रों में तैनात किए जाएं। उदाहरण के लिए, एक कंपनी यह सुनिश्चित करना चाह सकती है कि उसके सभी डेटा GDPR अनुपालन के लिए यूरोप में संग्रहीत हों।
+1. **Specific Azure Regions के साथ अनुपालन सुनिश्चित करना**: यह नीति सुनिश्चित करती है कि सभी संसाधन विशिष्ट Azure क्षेत्रों में तैनात हैं। उदाहरण के लिए, एक कंपनी यह सुनिश्चित करना चाह सकती है कि उसके सभी डेटा GDPR अनुपालन के लिए यूरोप में संग्रहीत हों।
 2. **Naming Standards को लागू करना**: नीतियाँ Azure संसाधनों के लिए नामकरण मानकों को लागू कर सकती हैं। यह बड़े वातावरण में संसाधनों को व्यवस्थित करने और उनके नामों के आधार पर आसानी से पहचानने में मदद करता है।
-3. **Certain Resource Types को प्रतिबंधित करना**: यह नीति कुछ प्रकार के संसाधनों के निर्माण को प्रतिबंधित कर सकती है। उदाहरण के लिए, एक नीति सेट की जा सकती है जो महंगे संसाधन प्रकारों, जैसे कुछ VM आकारों, के निर्माण को रोकती है, ताकि लागत को नियंत्रित किया जा सके।
+3. **Certain Resource Types को प्रतिबंधित करना**: यह नीति कुछ प्रकार के संसाधनों के निर्माण को प्रतिबंधित कर सकती है। उदाहरण के लिए, एक नीति सेट की जा सकती है जो कुछ महंगे संसाधन प्रकारों, जैसे कुछ VM आकारों, के निर्माण को रोकती है, ताकि लागत को नियंत्रित किया जा सके।
-4. **Tagging Policies को लागू करना**: टैग Azure संसाधनों के साथ जुड़े कुंजी-मूल्य जोड़े होते हैं जो संसाधन प्रबंधन के लिए उपयोग किए जाते हैं। नीतियाँ यह लागू कर सकती हैं कि कुछ टैग मौजूद होने चाहिए, या सभी संसाधनों के लिए विशिष्ट मान होने चाहिए। यह लागत ट्रैकिंग, स्वामित्व, या संसाधनों की श्रेणीकरण के लिए उपयोगी है।
+4. **Tagging Policies को लागू करना**: टैग Azure संसाधनों के साथ जुड़े कुंजी-मूल्य जोड़े होते हैं जो संसाधन प्रबंधन के लिए उपयोग किए जाते हैं। नीतियाँ यह लागू कर सकती हैं कि सभी संसाधनों के लिए कुछ टैग मौजूद होने चाहिए, या उनके पास विशिष्ट मान होने चाहिए। यह लागत ट्रैकिंग, स्वामित्व, या संसाधनों की श्रेणीकरण के लिए उपयोगी है।
-5. **Resources तक सार्वजनिक पहुँच को सीमित करना**: नीतियाँ यह लागू कर सकती हैं कि कुछ संसाधन, जैसे स्टोरेज खाते या डेटाबेस, सार्वजनिक एंडपॉइंट न हों, यह सुनिश्चित करते हुए कि वे केवल संगठन के नेटवर्क के भीतर ही सुलभ हों।
+5. **Resources तक सार्वजनिक पहुँच को सीमित करना**: नीतियाँ यह लागू कर सकती हैं कि कुछ संसाधनों, जैसे स्टोरेज खाते या डेटाबेस, में सार्वजनिक एंडपॉइंट नहीं होना चाहिए, यह सुनिश्चित करते हुए कि वे केवल संगठन के नेटवर्क के भीतर ही सुलभ हैं।
-6. **Automatically Applying Security Settings**: नीतियों का उपयोग संसाधनों पर सुरक्षा सेटिंग्स को स्वचालित रूप से लागू करने के लिए किया जा सकता है, जैसे सभी VMs पर एक विशिष्ट नेटवर्क सुरक्षा समूह लागू करना या यह सुनिश्चित करना कि सभी स्टोरेज खाते एन्क्रिप्शन का उपयोग करें।
+6. **Automatically Security Settings लागू करना**: नीतियों का उपयोग संसाधनों पर स्वचालित रूप से सुरक्षा सेटिंग्स लागू करने के लिए किया जा सकता है, जैसे सभी VMs पर एक विशिष्ट नेटवर्क सुरक्षा समूह लागू करना या यह सुनिश्चित करना कि सभी स्टोरेज खाते एन्क्रिप्शन का उपयोग करें।
 
-ध्यान दें कि Azure Policies को Azure पदानुक्रम के किसी भी स्तर पर जोड़ा जा सकता है, लेकिन ये **आमतौर पर root management group** या अन्य प्रबंधन समूहों में उपयोग की जाती हैं।
+ध्यान दें कि Azure Policies को Azure पदानुक्रम के किसी भी स्तर पर जोड़ा जा सकता है, लेकिन वे **आमतौर पर root management group** या अन्य प्रबंधन समूहों में उपयोग की जाती हैं।
 
 Azure policy json example:
 ```json
@@ -358,19 +358,19 @@ Azure policy json example:
 ```
 ### Permissions Inheritance
 
-Azure में **permissions किसी भी भाग को हायरार्की में सौंपे जा सकते हैं**। इसमें प्रबंधन समूह, सब्सक्रिप्शन, संसाधन समूह, और व्यक्तिगत संसाधन शामिल हैं। **Permissions** उन **resources** द्वारा **inherited** होते हैं जिनमें उन्हें सौंपा गया था।
+Azure में **permissions किसी भी भाग को हायरार्की में असाइन की जा सकती हैं**। इसमें प्रबंधन समूह, सब्सक्रिप्शन, संसाधन समूह, और व्यक्तिगत संसाधन शामिल हैं। **Permissions** उन **resources** द्वारा **inherited** की जाती हैं जिनके लिए उन्हें असाइन किया गया था।
 
-यह हायरार्किकल संरचना **access permissions** के प्रबंधन को कुशल और स्केलेबल बनाती है।
+यह हायरार्किकल संरचना एक्सेस permissions के प्रबंधन को कुशल और स्केलेबल बनाती है।
 
 <figure><img src="../../../images/image (26).png" alt=""><figcaption></figcaption></figure>
 
 ### Azure RBAC vs ABAC
 
-**RBAC** (role-based access control) वही है जो हमने पहले के अनुभागों में देखा है: **एक प्रिंसिपल को एक भूमिका सौंपना ताकि उसे एक संसाधन पर पहुंच मिल सके**।\
+**RBAC** (role-based access control) वही है जो हमने पहले के अनुभागों में देखा है: **एक प्रिंसिपल को एक भूमिका असाइन करना ताकि उसे एक संसाधन पर एक्सेस मिल सके**।\
-हालांकि, कुछ मामलों में आप **और अधिक बारीक पहुंच प्रबंधन** प्रदान करना चाहते हैं या **सौ** से अधिक भूमिका **सौंपने** के प्रबंधन को **सरल** करना चाहते हैं।
+हालांकि, कुछ मामलों में आप **और अधिक बारीक एक्सेस प्रबंधन** प्रदान करना चाहते हैं या **सौ** से अधिक भूमिका **असाइनमेंट्स** के प्रबंधन को **सरल** करना चाहते हैं।
 
-Azure **ABAC** (attribute-based access control) Azure RBAC पर आधारित है, जिसमें **विशिष्ट क्रियाओं के संदर्भ में विशेषताओं के आधार पर भूमिका सौंपने की शर्तें** जोड़ी जाती हैं। एक _भूमिका सौंपने की शर्त_ एक **अतिरिक्त जांच है जिसे आप वैकल्पिक रूप से अपनी भूमिका सौंपने में जोड़ सकते हैं** ताकि अधिक बारीक पहुंच नियंत्रण प्रदान किया जा सके। एक शर्त भूमिका परिभाषा और भूमिका सौंपने के हिस्से के रूप में दी गई अनुमतियों को फ़िल्टर करती है। उदाहरण के लिए, आप **एक शर्त जोड़ सकते हैं जो एक वस्तु को पढ़ने के लिए एक विशिष्ट टैग होने की आवश्यकता होती है**।\
+Azure **ABAC** (attribute-based access control) Azure RBAC पर आधारित है, जिसमें **विशिष्ट क्रियाओं के संदर्भ में विशेषताओं के आधार पर भूमिका असाइनमेंट की शर्तें** जोड़ी जाती हैं। एक _भूमिका असाइनमेंट शर्त_ एक **अतिरिक्त जांच है जिसे आप वैकल्पिक रूप से अपनी भूमिका असाइनमेंट में जोड़ सकते हैं** ताकि अधिक बारीक एक्सेस नियंत्रण प्रदान किया जा सके। एक शर्त भूमिका परिभाषा और भूमिका असाइनमेंट के हिस्से के रूप में दी गई permissions को फ़िल्टर करती है। उदाहरण के लिए, आप **एक शर्त जोड़ सकते हैं जो एक ऑब्जेक्ट को पढ़ने के लिए एक विशिष्ट टैग होने की आवश्यकता रखती है**।\
-आप **विशेष रूप से** **resources** पर **access** को **शर्तों** का उपयोग करके **निषेध** नहीं कर सकते।
+आप **explicitly** **deny** **access** को विशिष्ट संसाधनों के लिए **शर्तों का उपयोग करके** नहीं कर सकते।
 
 ## References
 

src/pentesting-cloud/azure-security/az-unauthenticated-enum-and-initial-entry/az-oauth-apps-phishing.md

@@ -4,11 +4,11 @@
 
 ## OAuth App Phishing
 
-**Azure Applications** उन अनुमतियों के साथ कॉन्फ़िगर की जाती हैं जिनका उपयोग वे तब कर सकेंगी जब एक उपयोगकर्ता एप्लिकेशन की सहमति देता है (जैसे कि निर्देशिका को सूचीबद्ध करना, फ़ाइलों तक पहुँच प्राप्त करना, या अन्य क्रियाएँ करना)। ध्यान दें कि एप्लिकेशन उपयोगकर्ता की ओर से कार्य करेगा, इसलिए भले ही ऐप प्रशासनिक अनुमतियों के लिए पूछ सकता है, यदि **उपयोगकर्ता को इसकी अनुमति नहीं है**, तो ऐप **प्रशासनिक क्रियाएँ करने में असमर्थ होगा**।
+**Azure Applications** उन अनुमतियों के साथ कॉन्फ़िगर की जाती हैं जिनका उपयोग वे तब कर सकेंगी जब एक उपयोगकर्ता एप्लिकेशन की सहमति देता है (जैसे कि निर्देशिका को सूचीबद्ध करना, फ़ाइलों तक पहुँच प्राप्त करना, या अन्य क्रियाएँ करना)। ध्यान दें कि एप्लिकेशन उपयोगकर्ता की ओर से कार्य करेगा, इसलिए भले ही एप्लिकेशन प्रशासनिक अनुमतियों के लिए अनुरोध कर सकता है, यदि **उपयोगकर्ता को इसकी अनुमति नहीं है**, तो एप्लिकेशन **प्रशासनिक क्रियाएँ नहीं कर सकेगा**।
 
 ### App consent permissions
 
-डिफ़ॉल्ट रूप से कोई भी **उपयोगकर्ता ऐप्स को सहमति दे सकता है**, हालाँकि इसे इस प्रकार कॉन्फ़िगर किया जा सकता है कि उपयोगकर्ता केवल **चयनित अनुमतियों के लिए सत्यापित प्रकाशकों के ऐप्स को सहमति दे सकें** या यहां तक कि **उपयोगकर्ताओं के लिए एप्लिकेशन पर सहमति देने की अनुमति को हटाया जा सके**।
+डिफ़ॉल्ट रूप से कोई भी **उपयोगकर्ता ऐप्स को सहमति दे सकता है**, हालाँकि इसे इस प्रकार कॉन्फ़िगर किया जा सकता है कि उपयोगकर्ता केवल **चयनित अनुमतियों के लिए सत्यापित प्रकाशकों के ऐप्स को सहमति दे सकें** या यहां तक कि **उपयोगकर्ताओं के लिए एप्लिकेशनों पर सहमति देने की अनुमति को हटाया जा सके**।
 
 <figure><img src="../../../images/image.png" alt=""><figcaption></figcaption></figure>
 
@@ -29,15 +29,15 @@
 
 ### Users are allowed to consent
 
-ध्यान दें कि आपको यह कमांड टेनेट के अंदर एक उपयोगकर्ता से निष्पादित करने की आवश्यकता है, आप बाहरी टेनेट से इस टेनेट की कॉन्फ़िगरेशन नहीं ढूंढ सकते। निम्नलिखित CLI आपको उपयोगकर्ताओं की अनुमतियों को समझने में मदद कर सकता है:
+ध्यान दें कि आपको यह कमांड टेनेट के अंदर एक उपयोगकर्ता से निष्पादित करने की आवश्यकता है, आप बाहरी टेनेट से इस कॉन्फ़िगरेशन को नहीं ढूंढ सकते। निम्नलिखित CLI आपको उपयोगकर्ताओं की अनुमतियों को समझने में मदद कर सकता है:
 ```bash
 az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/authorizationPolicy"
 ```
-- उपयोगकर्ता सभी ऐप्स के लिए सहमति दे सकते हैं: यदि **`permissionGrantPoliciesAssigned`** के अंदर आप पा सकते हैं: `ManagePermissionGrantsForSelf.microsoft-user-default-legacy` तो उपयोगकर्ता हर एप्लिकेशन को स्वीकार कर सकते हैं।
+- उपयोगकर्ता सभी ऐप्स के लिए सहमति दे सकते हैं: यदि **`permissionGrantPoliciesAssigned`** के अंदर आपको मिले: `ManagePermissionGrantsForSelf.microsoft-user-default-legacy` तो उपयोगकर्ता हर एप्लिकेशन को स्वीकार कर सकते हैं।
-- उपयोगकर्ता सत्यापित प्रकाशकों या आपके संगठन के ऐप्स के लिए सहमति दे सकते हैं, लेकिन केवल उन अनुमतियों के लिए जो आप चुनते हैं: यदि **`permissionGrantPoliciesAssigned`** के अंदर आप पा सकते हैं: `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team` तो उपयोगकर्ता हर एप्लिकेशन को स्वीकार कर सकते हैं।
+- उपयोगकर्ता सत्यापित प्रकाशकों या आपके संगठन के ऐप्स के लिए सहमति दे सकते हैं, लेकिन केवल उन अनुमतियों के लिए जो आप चुनते हैं: यदि **`permissionGrantPoliciesAssigned`** के अंदर आपको मिले: `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team` तो उपयोगकर्ता हर एप्लिकेशन को स्वीकार कर सकते हैं।
-- **उपयोगकर्ता सहमति अक्षम करें**: यदि **`permissionGrantPoliciesAssigned`** के अंदर आप केवल पा सकते हैं: `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-chat` और `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team` तो उपयोगकर्ता किसी भी चीज़ पर सहमति नहीं दे सकते।
+- **उपयोगकर्ता सहमति अक्षम करें**: यदि **`permissionGrantPoliciesAssigned`** के अंदर आपको केवल मिले: `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-chat` और `ManagePermissionGrantsForOwnedResource.microsoft-dynamically-managed-permissions-for-team` तो उपयोगकर्ता किसी भी चीज़ पर सहमति नहीं दे सकते।
 
-यहां प्रत्येक टिप्पणी की गई नीतियों का अर्थ खोजने की संभावना है:
+यहां प्रत्येक टिप्पणी की गई नीति का अर्थ जानने के लिए संभव है:
 ```bash
 az rest --method GET --url "https://graph.microsoft.com/v1.0/policies/permissionGrantPolicies"
 ```
@@ -62,14 +62,14 @@ az rest --method GET --url "https://graph.microsoft.com/v1.0/directoryRoles/0d60
 हमला कई चरणों में एक सामान्य कंपनी को लक्षित करता है। यह इस प्रकार हो सकता है:
 
 1. **डोमेन पंजीकरण और एप्लिकेशन होस्टिंग**: हमलावर एक ऐसा डोमेन पंजीकृत करता है जो एक विश्वसनीय साइट के समान हो, उदाहरण के लिए, "safedomainlogin.com"। इस डोमेन के तहत, एक उपडोमेन बनाया जाता है (जैसे, "companyname.safedomainlogin.com") जो एक एप्लिकेशन को होस्ट करता है जिसे प्राधिकरण कोड कैप्चर करने और एक्सेस टोकन अनुरोध करने के लिए डिज़ाइन किया गया है।
-2. **Azure AD में एप्लिकेशन पंजीकरण**: इसके बाद, हमलावर अपने Azure AD टेनेट में एक मल्टी-टेनेंट एप्लिकेशन पंजीकृत करता है, जिसका नाम लक्षित कंपनी के नाम पर रखा जाता है ताकि यह वैध प्रतीत हो। वे एप्लिकेशन के रीडायरेक्ट URL को उस उपडोमेन की ओर इंगित करते हैं जो दुर्भावनापूर्ण एप्लिकेशन को होस्ट करता है।
+2. **Azure AD में एप्लिकेशन पंजीकरण**: फिर हमलावर अपने Azure AD टेनेट में एक मल्टी-टेनेंट एप्लिकेशन पंजीकृत करता है, जिसका नाम लक्षित कंपनी के नाम पर रखा जाता है ताकि यह वैध प्रतीत हो। वे एप्लिकेशन के रीडायरेक्ट URL को उस उपडोमेन की ओर इंगित करते हैं जो दुर्भावनापूर्ण एप्लिकेशन को होस्ट करता है।
-3. **अनुमतियों की सेटिंग**: हमलावर एप्लिकेशन को विभिन्न API अनुमतियों के साथ सेट करता है (जैसे, `Mail.Read`, `Notes.Read.All`, `Files.ReadWrite.All`, `User.ReadBasic.All`, `User.Read`)। ये अनुमतियाँ, जब उपयोगकर्ता द्वारा दी जाती हैं, तो हमलावर को उपयोगकर्ता की ओर से संवेदनशील जानकारी निकालने की अनुमति देती हैं।
+3. **अनुमतियों की सेटिंग**: हमलावर एप्लिकेशन को विभिन्न API अनुमतियों के साथ सेट करता है (जैसे, `Mail.Read`, `Notes.Read.All`, `Files.ReadWrite.All`, `User.ReadBasic.All`, `User.Read`)। ये अनुमतियाँ, एक बार उपयोगकर्ता द्वारा दी गई, हमलावर को उपयोगकर्ता की ओर से संवेदनशील जानकारी निकालने की अनुमति देती हैं।
 4. **दुर्भावनापूर्ण लिंक वितरित करना**: हमलावर एक लिंक तैयार करता है जिसमें दुर्भावनापूर्ण एप्लिकेशन का क्लाइंट आईडी होता है और इसे लक्षित उपयोगकर्ताओं के साथ साझा करता है, उन्हें सहमति देने के लिए धोखा देता है।
 
 ## उदाहरण हमला
 
-1. एक **नया एप्लिकेशन** पंजीकृत करें। यह केवल वर्तमान निर्देशिका के लिए हो सकता है यदि आप हमले की गई निर्देशिका से उपयोगकर्ता का उपयोग कर रहे हैं या किसी भी निर्देशिका के लिए यदि यह एक बाहरी हमला है (जैसे निम्नलिखित छवि में)।
+1. एक **नया एप्लिकेशन** पंजीकृत करें। यह केवल वर्तमान निर्देशिका के लिए हो सकता है यदि आप हमले की गई निर्देशिका से एक उपयोगकर्ता का उपयोग कर रहे हैं या किसी भी निर्देशिका के लिए यदि यह एक बाहरी हमला है (जैसे निम्नलिखित छवि में)।
-1. **रीडायरेक्ट URI** को उस अपेक्षित URL पर सेट करें जहाँ आप टोकन प्राप्त करने के लिए कोड प्राप्त करना चाहते हैं (`http://localhost:8000/callback` डिफ़ॉल्ट रूप से)।
+1. **रीडायरेक्ट URI** को भी उस अपेक्षित URL पर सेट करें जहाँ आप टोकन प्राप्त करने के लिए कोड प्राप्त करना चाहते हैं (`http://localhost:8000/callback` डिफ़ॉल्ट रूप से)।
 
 <figure><img src="../../../images/image (1).png" alt=""><figcaption></figcaption></figure>
 
@@ -88,11 +88,11 @@ python3 azure_oauth_phishing_example.py --client-secret <client-secret> --client
 ```
 5. **शिकार को URL भेजें**
 1. इस मामले में `http://localhost:8000`
-6. **शिकारों** को **प्रॉम्प्ट स्वीकार करना होगा:**
+6. **शिकार** को **प्रॉम्प्ट स्वीकार करना होगा:**
 
 <figure><img src="../../../images/image (4).png" alt=""><figcaption></figcaption></figure>
 
-7. **अनुरोधित अनुमतियों** तक पहुँचने के लिए **एक्सेस टोकन** का उपयोग करें:
+7. **अनुरोधित अनुमतियों** तक पहुँचने के लिए **एक्सेस टोकन का उपयोग करें**:
 ```bash
 export ACCESS_TOKEN=<ACCESS_TOKEN>
 
@@ -119,15 +119,22 @@ https://graph.microsoft.com/v1.0/me/onenote/notebooks \
 - [**365-Stealer**](https://github.com/AlteredSecurity/365-Stealer)**:** इसे कॉन्फ़िगर करने के लिए [https://www.alteredsecurity.com/post/introduction-to-365-stealer](https://www.alteredsecurity.com/post/introduction-to-365-stealer) पर जाएं।
 - [**O365-Attack-Toolkit**](https://github.com/mdsecactivebreach/o365-attack-toolkit)
 
-## पोस्ट-एक्सप्लोइटेशन
+## पोस्ट-एक्सप्लॉइटेशन
 
-### फ़िशिंग पोस्ट-एक्सप्लोइटेशन
+### फ़िशिंग पोस्ट-एक्सप्लॉइटेशन
 
 अनुरोधित अनुमतियों के आधार पर, आप **टेनेंट के विभिन्न डेटा तक पहुँचने में सक्षम हो सकते हैं** (उपयोगकर्ताओं, समूहों की सूची... या यहां तक कि सेटिंग्स को संशोधित करना) और **उपयोगकर्ता की जानकारी** (फाइलें, नोट्स, ईमेल...)। फिर, आप इन अनुमतियों का उपयोग उन क्रियाओं को करने के लिए कर सकते हैं।
 
-### एप्लिकेशन पोस्ट एक्सप्लोइटेशन
+### Entra ID अनुप्रयोग व्यवस्थापक
 
-पृष्ठ के एप्लिकेशन और सेवा प्रिंसिपल अनुभागों की जांच करें:
+यदि आप किसी तरह एक Entra ID प्रिंसिपल को समझौता करने में सफल हो गए हैं जो Entra ID में अनुप्रयोगों का प्रबंधन कर सकता है, और ऐसे अनुप्रयोग हैं जो टेनेंट के उपयोगकर्ताओं द्वारा उपयोग किए जा रहे हैं। एक व्यवस्थापक **अनुप्रयोग द्वारा अनुरोधित अनुमतियों को संशोधित करने और टोकन चुराने के लिए एक नया अनुमत रीडायरेक्ट पता जोड़ने में सक्षम होगा**।
+- ध्यान दें कि **रीडायरेक्ट URIs जोड़ना संभव है** (वास्तविक को हटाने की आवश्यकता नहीं है) और फिर हमलावर के रीडायरेक्ट URI का उपयोग करके एक HTTP लिंक भेजें ताकि जब उपयोगकर्ता लिंक का पालन करे तो प्रमाणीकरण स्वचालित रूप से हो जाए और हमलावर को टोकन प्राप्त हो।
+- यह भी संभव है कि अनुप्रयोग जो अनुमतियाँ मांगता है उन्हें बदलकर उपयोगकर्ताओं से अधिक अनुमति प्राप्त की जा सके, लेकिन इस मामले में उपयोगकर्ता को **फिर से प्रॉम्प्ट स्वीकार करना होगा** (भले ही वह पहले से लॉग इन हो)।
+- इस हमले को करने के लिए हमलावर को **अनुप्रयोग कोड पर नियंत्रण रखने की आवश्यकता नहीं है** क्योंकि वह बस उपयोगकर्ता को नए URL के साथ अनुप्रयोग में लॉगिन करने के लिए लिंक भेज सकता है **`redirect_uri`** पैरामीटर में।
+
+### अनुप्रयोग पोस्ट एक्सप्लॉइटेशन
+
+पृष्ठ के अनुप्रयोगों और सेवा प्रिंसिपल अनुभागों की जांच करें:
 
 {{#ref}}
 ../az-privilege-escalation/az-entraid-privesc/