Fix screenshots with masking subscription ID

Author: kasun04

articles/event-hubs/authenticate-shared-access-signature.md

@@ -213,7 +213,7 @@ For example, to define authorization rules scoped down to only sending/publishin
 To authenticate back-end applications that consume from the data generated by Event Hubs producers, Event Hubs token authentication requires its clients to either have the **manage** rights or the **listen** privileges assigned to its Event Hubs namespace or event hub instance or topic. Data is consumed from Event Hubs using consumer groups. While SAS policy gives you granular scope, this scope is defined only at the entity level and not at the consumer level. It means that the privileges defined at the namespace level or the event hub instance or topic level will be applied to the consumer groups of that entity.
 
 ## Disabling Local/SAS Key authentication  
-For certain organizational security requirements, you may have to disable local/SAS key authentication completely and rely on the Azure Active Directory (Azure AD) based authentication which is the recommended way to connect with Azure Event Hubs. You can disable local/SAS key authentication at the Event Hubs namespace level using Azure Portal or Azure Resource Manager template. 
+For certain organizational security requirements, you may have to disable local/SAS key authentication completely and rely on the Azure Active Directory (Azure AD) based authentication which is the recommended way to connect with Azure Event Hubs. You can disable local/SAS key authentication at the Event Hubs namespace level using Azure portal or Azure Resource Manager template. 
 
 ### Disabling Local/SAS Key authentication via Portal 
 You can disable local/SAS key authentication for a given Event Hubs namespace using Azure Portal. 

articles/event-hubs/authorize-access-shared-access-signature.md

@@ -33,7 +33,7 @@ The rights provided by the policy rule can be a combination of:
 > [!NOTE]
 > The **Manage** right includes the **Send** and **Listen** rights.
 
-A namespace or entity policy can hold up to 12 shared access authorization rules, providing room for the three sets of rules, each covering the basic rights, and the combination of Send and Listen. This limit underlines that the SAS policy store isn't intended to be a user or service account store. If your application needs to grant access to Event Hubs resources based on user or service identities, it should implement a security token service that issues SAS tokens after an authentication and access check.
+A namespace or entity policy can hold up to 12 shared access authorization rules, providing room for the three sets of rules, each covering the basic rights, and the combination of Send and Listen. This limit underlines that the SAS policy store isn't intended to be a user or service account store. If your application needs to grant, access to Event Hubs resources based on user or service identities, it should implement a security token service that issues SAS tokens after an authentication and access check.
 
 An authorization rule is assigned a **primary key** and a **secondary key**. These keys are cryptographically strong keys. Don’t lose them or leak them. They’ll always be available in the Azure portal. You can use either of the generated keys, and you can regenerate them at any time. If you regenerate or change a key in the policy, all previously issued tokens based on that key become instantly invalid. However, ongoing connections created based on such tokens will continue to work until the token expires.