Merge pull request #7538 from adyavanapalli/fix/fix-instances-where-principle-should-be-principal

Court72 · web-flow · commit 7fc1e7597966 · 2022-05-04T09:27:45.000-06:00
Typos: Fix instances where "principle" should be "principal".
diff --git a/docs/linux/sql-server-linux-security-get-started.md b/docs/linux/sql-server-linux-security-get-started.md
@@ -32,7 +32,7 @@ CREATE LOGIN Larry WITH PASSWORD = '************';
 > [!NOTE]
 >  Always use a strong password in place of the asterisks in the previous command.
 
-Logins can connect to SQL Server and have access (with limited permissions) to the master database. To connect to a user-database, a login needs a corresponding identity at the database level, called a database user. Users are specific to each database and must be separately created in each database to grant them access. The following example moves you into the AdventureWorks2014 database, and then uses the [CREATE USER](../t-sql/statements/create-user-transact-sql.md) statement to create a user named Larry that is associated with the login named Larry. Though the login and the user are related (mapped to each other), they are different objects. The login is a server-level principle. The user is a database-level principal.
+Logins can connect to SQL Server and have access (with limited permissions) to the master database. To connect to a user-database, a login needs a corresponding identity at the database level, called a database user. Users are specific to each database and must be separately created in each database to grant them access. The following example moves you into the AdventureWorks2014 database, and then uses the [CREATE USER](../t-sql/statements/create-user-transact-sql.md) statement to create a user named Larry that is associated with the login named Larry. Though the login and the user are related (mapped to each other), they are different objects. The login is a server-level principal. The user is a database-level principal.
 
 ```
 USE AdventureWorks2014;
diff --git a/docs/machine-learning/install/sql-server-machine-learning-services-2019.md b/docs/machine-learning/install/sql-server-machine-learning-services-2019.md
@@ -39,7 +39,7 @@ As implemented by SQL Server, AppContainers are an internal mechanism. While you
 
 ## Firewall rules created by Setup
 
-By default, SQL Server disables outbound connections by creating firewall rules. In the past, these rules were based on local user accounts, where Setup created one outbound rule for **SQLRUserGroup** that denied network access to its members (each worker account was listed as a local principle subject to the rule_. 
+By default, SQL Server disables outbound connections by creating firewall rules. In the past, these rules were based on local user accounts, where Setup created one outbound rule for **SQLRUserGroup** that denied network access to its members (each worker account was listed as a local principal subject to the rule_. 
 
 As part of the move to AppContainers, there are new firewall rules based on AppContainer SIDs: one for each of the 20 AppContainers created by SQL Server Setup. Naming conventions for the firewall rule name are **Block network access for AppContainer-00 in SQL Server instance MSSQLSERVER**, where 00 is the number of the AppContainer (00-20 by default), and MSSQLSERVER is the name of the SQL Server instance. 
 
diff --git a/docs/machine-learning/security/firewall-configuration.md b/docs/machine-learning/security/firewall-configuration.md
@@ -19,7 +19,7 @@ This article lists firewall configuration considerations that the administrator
 
 By default, the SQL Server Setup disables outbound connections by creating firewall rules.
 
-In SQL Server 2016 and 2017, these rules are based on local user accounts, where Setup created one outbound rule for **SQLRUserGroup** that denied network access to its members (each worker account was listed as a local principle subject to the rule. For more information about SQLRUserGroup, see [Security overview for the extensibility framework in SQL Server Machine Learning Services](../../machine-learning/concepts/security.md#sqlrusergroup).
+In SQL Server 2016 and 2017, these rules are based on local user accounts, where Setup created one outbound rule for **SQLRUserGroup** that denied network access to its members (each worker account was listed as a local principal subject to the rule. For more information about SQLRUserGroup, see [Security overview for the extensibility framework in SQL Server Machine Learning Services](../../machine-learning/concepts/security.md#sqlrusergroup).
 
 In SQL Server 2019, as part of the move to AppContainers, there are new firewall rules based on AppContainer SIDs: one for each of the 20 AppContainers created by SQL Server Setup. Naming conventions for the firewall rule name are **Block network access for AppContainer-00 in SQL Server instance MSSQLSERVER**, where 00 is the number of the AppContainer (00-20 by default), and MSSQLSERVER is the name of the SQL Server instance.
 
diff --git a/docs/relational-databases/system-stored-procedures/sp-getapplock-transact-sql.md b/docs/relational-databases/system-stored-procedures/sp-getapplock-transact-sql.md
@@ -80,7 +80,7 @@ sp_getapplock [ @Resource = ] 'resource_name' ,
   
 -   The database ID of the database containing the lock resource.  
   
--   The database principle specified in the @DbPrincipal parameter.  
+-   The database principal specified in the @DbPrincipal parameter.  
   
 -   The lock name specified in the @Resource parameter.  
   
diff --git a/docs/reporting-services/report-server/rsreportserver-config-configuration-file.md b/docs/reporting-services/report-server/rsreportserver-config-configuration-file.md
@@ -137,7 +137,7 @@ For more information on editing the file, see [Modify a Reporting Services Confi
 |Setting|Description|Mode|  
 |-------------|-----------------|----------|  
 |**AuthenticationTypes**|Specifies one or more authentication types. Valid values are: **RSWindowsNegotiate**, **RSWindowsKerberos**, **RSWindowsNTLM**, **RSWindowsBasic**, and **Custom**.<br /><br /> **RSWindows** types and **Custom** are mutually exclusive.<br /><br /> **RSWindowsNegotiate**, **RSWindowsKerberos**, **RSWindowsNTLM**, and **RSWindowsBasic** are cumulative and can be used together, as illustrated in the default value example earlier in this section.<br /><br /> Specifying multiple authentication types is necessary if you expect requests from a variety of client applications or browsers that use different types of authentication.<br /><br /> Do not remove **RSWindowsNTLM**, otherwise you will limit browser support to a portion of the supported browser types. For more information, see [Browser Support for Reporting Services and Power View](../../reporting-services/browser-support-for-reporting-services-and-power-view.md).|N|  
-|**RSWindowsNegotiate**|The report server accepts either Kerberos or NTLM security tokens. This is the default setting when the report server is running in native mode and the service account is Network Service. This setting is omitted when the report server is running in native mode and the service account is configured as a domain user account.<br /><br /> If a domain account is configured for the Report Server Service account and a Service Principle Name (SPN) is not configured for the report server, this setting might prevent users from logging on to the server.|N|  
+|**RSWindowsNegotiate**|The report server accepts either Kerberos or NTLM security tokens. This is the default setting when the report server is running in native mode and the service account is Network Service. This setting is omitted when the report server is running in native mode and the service account is configured as a domain user account.<br /><br /> If a domain account is configured for the Report Server Service account and a Service Principal Name (SPN) is not configured for the report server, this setting might prevent users from logging on to the server.|N|  
 |**RSWindowsNTLM**|The server accepts NTLM security tokens.<br /><br /> If you remove this setting, browser support will be limited for some of the supported browser types. For more information, see [Browser Support for Reporting Services and Power View](../../reporting-services/browser-support-for-reporting-services-and-power-view.md).|N, S|  
 |**RSWindowsKerberos**|The server accepts Kerberos security tokens.<br /><br /> Use this setting or RSWindowsNegotiate when you use Kerberos authentication in a constrained delegation authentication scheme.|N|  
 |**RSWindowsBasic**|The server accepts Basic credentials and issues a challenge/response when a connection is made without credentials.<br /><br /> Basic authentication passes credentials in the HTTP requests in clear text. If you use Basic authentication, use TLS to encrypt network traffic to and from the report server. To view example configuration syntax for Basic authentication in [!INCLUDE[ssRSnoversion](../../includes/ssrsnoversion-md.md)], see [Authentication with the Report Server](../../reporting-services/security/authentication-with-the-report-server.md).|N|  
diff --git a/docs/reporting-services/security/authentication-with-the-report-server.md b/docs/reporting-services/security/authentication-with-the-report-server.md
@@ -32,7 +32,7 @@ ms.author: maggies
 |-----------------------------|-------------------------------------|---------------------|-----------------|  
 |RSWindowsNegotiate|Negotiate|Yes|Attempts to use Kerberos for Windows Integrated authentication first, but falls back to NTLM if Active Directory cannot grant a ticket for the client request to the report server. Negotiate will only fall back to NTLM if the ticket is not available. If the first attempt results in an error rather than a missing ticket, the report server does not make a second attempt.|  
 |RSWindowsNTLM|NTLM|Yes|Uses NTLM for Windows Integrated authentication.<br /><br /> The credentials will not be delegated or impersonated on other requests. Subsequent requests will follow a new challenge-response sequence. Depending on network security settings, a user might be prompted for credentials or the authentication request will be handled transparently.|  
-|RSWindowsKerberos|Kerberos|No|Uses Kerberos for Windows Integrated authentication. You must configure Kerberos by setting up setup service principle names (SPNs) for your service accounts, which requires domain administrator privileges. If you set up identity delegation with Kerberos, the token of the user who is requesting a report can also be used on an additional connection to the external data sources that provide data to reports.<br /><br /> Before you specify RSWindowsKerberos, be sure that the browser type you are using actually supports it. If you are using Microsoft Edge, or Internet Explorer, Kerberos authentication is only supported through Negotiate. Microsoft Edge, or Internet Explorer, will not formulate an authentication request that specifies Kerberos directly.|  
+|RSWindowsKerberos|Kerberos|No|Uses Kerberos for Windows Integrated authentication. You must configure Kerberos by setting up setup service principal names (SPNs) for your service accounts, which requires domain administrator privileges. If you set up identity delegation with Kerberos, the token of the user who is requesting a report can also be used on an additional connection to the external data sources that provide data to reports.<br /><br /> Before you specify RSWindowsKerberos, be sure that the browser type you are using actually supports it. If you are using Microsoft Edge, or Internet Explorer, Kerberos authentication is only supported through Negotiate. Microsoft Edge, or Internet Explorer, will not formulate an authentication request that specifies Kerberos directly.|  
 |RSWindowsBasic|Basic|No|Basic authentication is defined in the HTTP protocol and can only be used to authenticate HTTP requests to the report server.<br /><br /> Credentials are passed in the HTTP request in base64 encoding. If you use Basic authentication, use Transport Layer Security (TLS), previously known as Secure Sockets Layer (SSL) to encrypt user account information before it is sent across the network. SSL provides an encrypted channel for sending a connection request from the client to the report server over an HTTP TCP/IP connection. For more information, see [Using SSL to Encrypt Confidential Data](/previous-versions/windows/it-pro/windows-server-2003/cc738495(v=ws.10)) on the [!INCLUDE[msCoName](../../includes/msconame-md.md)] TechNet Web site.|  
 |Custom|(Anonymous)|No|Anonymous authentication directs the report server to ignore authentication header in an HTTP request. The report server accepts all requests, but call on a custom [!INCLUDE[vstecasp](../../includes/vstecasp-md.md)] Forms authentication that you provide to authenticate the user.<br /><br /> Specify **Custom** only if you are deploying a custom authentication module that handles all authentication requests on the report server. You cannot use the Custom authentication type with the default Windows Authentication extension.|  
   
diff --git a/docs/reporting-services/security/roles-and-permissions-reporting-services.md b/docs/reporting-services/security/roles-and-permissions-reporting-services.md
@@ -26,7 +26,7 @@ ms.author: maggies
 ## Identity and Access Control for Native Mode  
  Default authentication is based on Windows Authentication and integrated security. You can change the authentication settings to allow the report server to respond to different authentication requests, or even replace the default security features with a custom authentication extension that you provide.  
   
- Authorization is based on roles that you assign to a principle. Each role consists of a set of related tasks, which are in turn composed of related operations. For example, the **Manage reports** task grants access to the following report server operations: view reports, add report, update report, delete report, schedule report, and update report properties.  
+ Authorization is based on roles that you assign to a principal. Each role consists of a set of related tasks, which are in turn composed of related operations. For example, the **Manage reports** task grants access to the following report server operations: view reports, add report, update report, delete report, schedule report, and update report properties.  
   
 ## Identity and Access Control for SharePoint Mode  
  In SharePoint integrated mode, authentication and authorization are handled on the SharePoint site, before requests reach the report server. Depending on how you configure authentication, requests from a SharePoint site include a security token or a trusted user name. Permissions that you set for SharePoint users and groups authorize access to report server items that are placed in SharePoint libraries.  
diff --git a/docs/sql-server/azure-arc/connect-at-scale.md b/docs/sql-server/azure-arc/connect-at-scale.md
@@ -46,7 +46,7 @@ Each machine must have [Azure PowerShell](/powershell/azure/install-az-ps) insta
     $sp
     ```
 
-2. Give the service principle permissions to access Microsoft Graph.
+2. Give the service principal permissions to access Microsoft Graph.
 
    > [!NOTE]
    > - When you create a service principal, your account must be an Owner or User Access Administrator in the subscription that you want to use for onboarding. If you don't have sufficient permissions to create role assignments, the service principal might be created, but it won't be able to onboard machines. The instructions on how to create a custom role are provided in [Required permissions](overview.md#required-permissions).
diff --git a/docs/ssms/menu-help/options-azure-services.md b/docs/ssms/menu-help/options-azure-services.md
@@ -30,7 +30,7 @@ Use this page to specify options related to Azure cloud services. To access this
 | Graph Endpoint | `https://graph.windows.net` | Specifies the URL for Azure Active Directory Graph requests. |
 | Management Portal URL | `https://portal.azure.com` | Specifies the URL for the Management Portal. |
 | Publish Setting File URL | `https://go.microsoft.com/fwlink/?LinkID=335839` | Specifies the URL from which the `.publishsettings` file can be downloaded. |
-| SQL Database Service Principle Name | `https://database.windows.net/` | The Azure SQL Database SPN to obtain a token when using AAD authentication. Also the audience of the JSON Web Token (JWT) for server-side JSON Web Token (JWT) parsing/validation. |
+| SQL Database Service Principal Name | `https://database.windows.net/` | The Azure SQL Database SPN to obtain a token when using AAD authentication. Also the audience of the JSON Web Token (JWT) for server-side JSON Web Token (JWT) parsing/validation. |
 
 ## Resource Management
 
diff --git a/docs/t-sql/functions/is-rolemember-transact-sql.md b/docs/t-sql/functions/is-rolemember-transact-sql.md
@@ -25,7 +25,7 @@ monikerRange: ">=aps-pdw-2016||=azuresqldb-current||=azure-sqldw-latest||>=sql-s
 # IS_ROLEMEMBER (Transact-SQL)
 [!INCLUDE [sql-asdb-asdbmi-asa-pdw](../../includes/applies-to-version/sql-asdb-asdbmi-asa-pdw.md)]
 
-  Indicates whether a specified database principle is a member of the specified database role.  
+  Indicates whether a specified database principal is a member of the specified database role.  
   
  ![Topic link icon](../../database-engine/configure-windows/media/topic-link.gif "Topic link icon") [Transact-SQL Syntax Conventions](../../t-sql/language-elements/transact-sql-syntax-conventions-transact-sql.md)  
   
@@ -70,7 +70,7 @@ The **IS_ROLEMEMBER** function is not supported for an Azure AD administrator wh
   
  When the *database_principal* parameter is a based on a domain login or based on a Windows group and the domain controller is inaccessible, calls to IS_ROLEMEMBER will fail and might return incorrect or incomplete data.  
   
- If the domain controller is not available, the call to IS_ROLEMEMBER will return accurate information when the Windows principle can be authenticated locally, such as a local Windows account or a [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] login.  
+ If the domain controller is not available, the call to IS_ROLEMEMBER will return accurate information when the Windows principal can be authenticated locally, such as a local Windows account or a [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] login.  
   
  **IS_ROLEMEMBER** always returns 0 when a Windows group is used as the database principal argument, and this Windows group is a member of another Windows group which is, in turn, a member of the specified database role.  
   
diff --git a/docs/t-sql/functions/is-srvrolemember-transact-sql.md b/docs/t-sql/functions/is-srvrolemember-transact-sql.md
@@ -77,7 +77,7 @@ IS_SRVROLEMEMBER ( 'role' [ , 'login' ] )
   
  When the login parameter is a domain login or based on a Windows group and the domain controller is inaccessible, calls to IS_SRVROLEMEMBER will fail and might return incorrect or incomplete data.  
   
- If the domain controller is not available, the call to IS_SRVROLEMEMBER will return accurate information when the Windows principle can be authenticated locally, such as a local Windows account or a [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] login.  
+ If the domain controller is not available, the call to IS_SRVROLEMEMBER will return accurate information when the Windows principal can be authenticated locally, such as a local Windows account or a [!INCLUDE[ssNoVersion](../../includes/ssnoversion-md.md)] login.  
   
  **IS_SRVROLEMEMBER** always returns 0 when a Windows group is used as the login argument, and this Windows group is a member of another Windows group which is, in turn, a member of the specified server role.  
   
diff --git a/docs/t-sql/statements/create-workload-classifier-transact-sql.md b/docs/t-sql/statements/create-workload-classifier-transact-sql.md
@@ -65,7 +65,7 @@ WITH
  The security account used to classified against.  Security_account is a sysname, with no default. Security_account can be a database user, database role, Azure Active Directory login, or Azure Active Directory group.
 
 > [!NOTE]
-> Use the ```user_name()``` function, when connected to the system, to verify the membername that the classification process will use to classify the request.  Verifying the membername with the ```user_name()``` function can be helpful troubleshooting AAD or service principle classification issues.  If ```user_name()``` returns "dbo" you can use "dbo" as the membername to classify the requests.  Keep in mind all members of the "dbo" role will be classified.  Additional classification parameters such as *WLM_LABEL* or *WLM_CONTEXT* can also be used to specifically classify requests from multiple AAD accounts mapping to the "dbo" role.
+> Use the ```user_name()``` function, when connected to the system, to verify the membername that the classification process will use to classify the request.  Verifying the membername with the ```user_name()``` function can be helpful troubleshooting AAD or service principal classification issues.  If ```user_name()``` returns "dbo" you can use "dbo" as the membername to classify the requests.  Keep in mind all members of the "dbo" role will be classified.  Additional classification parameters such as *WLM_LABEL* or *WLM_CONTEXT* can also be used to specifically classify requests from multiple AAD accounts mapping to the "dbo" role.
  
  *WLM_LABEL*   
  Specifies the label value that a request can be classified against.  Label is an optional parameter of type nvarchar(255).  Use the [OPTION (LABEL)](/azure/sql-data-warehouse/sql-data-warehouse-develop-label) in the request to match the classifier configuration.
