Introduction-to-permissions-Part3_SQIn Part 2 of our series on permissions, we looked at how Windows and the *nix operating systems (Linux, Unix, and Macs) deal with file system permissions. In Part 3, we are going to look at application permissions. This is a pretty broad topic, but there are some generic permissions that are relevant across most models.

Generic concepts

Applications need certain permissions to run. Some of these permissions are to the operating system, and some are to data sources. An end-user application will typically run with the same permissions that the user has. If you run Word on your tablet or Photoshop on your laptop, everything those apps do will be logged as if you were the one doing them. What access you have to local or network storage, and what abilities you have to modify your operating system (think install and config) will govern what the app can or cannot do. Applications that run on servers typically will run using either the SYSTEM, Network Service, or a specific service account when on Windows, and as a member of some group or as ROOT when running on *nix. When not running as SYSTEM, Network Service, or ROOT, additional permissions may need to be granted to the specific account including the ability to access files, interact with the operating system, or even to run (logon as a service.) Application installs should document what is required to enable the application to run properly, and you should always read that documentation to ensure you grant the appropriate permissions but not too many. Least privilege applies here.

FULL CONTROL, CHANGE and READ are generic level permissions that can be applied in concept to all applications, though many apps will call these different things. As the terms imply, FULL CONTROL provides whoever holds that permission with full access, CHANGE enables the ability to modify, and READ provides the ability to access but not change data.

Impersonation refers to the ability for an app to run in one context, but to impersonate a user for another. Apps may need to run as a part of the host system, but will need to authenticate as if they were the individual user when accessing specific data, or to update a user’s information. Impersonation rights can be implicit or explicit.

Service accounts

In Windows, a service account is one that is created by the administrator, or by the application install using the administrator’s privileges, and is used by an application to run. When the application starts, it authenticates as the service account, and all permissions needed are assigned to that service account.

Service accounts can be domain accounts or local accounts. Which you use depends upon whether the permissions need only apply to a single machine, or to other systems on the network.

Service accounts should be configured with permissions to log on as a service on every machine which will run the app, access the computer from the network for any machine which they must interact with, and most importantly, they should be configured so that their password never expires. That doesn’t mean that you should keep the same password forever – you will need to manually change the password in Active Directory or on the local system, and then update the log on type for the service manually.

Service accounts in Windows often need to impersonate users when accessing or updating information stored in Active Directory or in Windows applications backed by SQL, including SharePoint.

Active Directory

Active Directory can be considered an application, and there are several built-in groups and users that are necessary for AD to function properly. The default “Administrator” account has full permissions to everything in AD. The Guest account has virtually no permissions at all and is disabled, but it still exists. There are also several built-in groups which come with their own sets of permissions, including Enterprise Admins, Domain Admins, Schema Admins, Server Operators, Account Operators, Print Operators, and Backup Operators, plus Users. See http://technet.microsoft.com/en-us/library/cc756898(v=WS.10).aspx for a complete list.

Website permissions

Websites that host static content available to anyone need only have two levels of permissions. READ for anonymous web visitors, and FULL CONTROL for the webmasters. But apps that are more dynamic and use databases to provide user specific content will need more granular permissions, and may need to impersonate a user in order to update their profile.

Database permissions

Different database management systems have different names for and approaches to permissions, but the Microsoft SQL model is widely deployed and will be used here. MS SQL uses role based access control to apply permissions. See http://technet.microsoft.com/en-us/library/aa905184(v=sql.80).aspx for the predefined roles, which include SQL roles sysadmin, dbcreator, securityadmin, and database roles db_owner, db_datareader, db_datawriter, and more.

Of course, this only scratches the surface of SQL. See http://msdn.microsoft.com/en-us/library/ms191291.aspx for more details on all the specific SQL permissions that exist.

SharePoint Site permissions

SharePoint uses service accounts and impersonation, but also has three specific groups for all SharePoint sites. Site Owners have the ability to do anything in a site, including grant others access, set the appearance of the site, create new subsites, and more. Site members can contribute content to a site. Site visitors have READ ONLY access to all content within a site.

Mobile and Web App permissions

These permissions can be given to access certain data on your system like your email, webcam, or location, or to access certain applications you use on the Internet, such as Facebook or Twitter. If you explicitly grant these applications permissions, you are enabling them to interact with your local data or even modify it, as well as to interact or modify your online data for social media sites and email. When an app asks for permissions to access certain things, consider not only whether you trust the app maker or not, but also why it might need access to your location. An app that provides directions probably needs access to your current location, but why would an e-reader app need to know where you are?

Troubleshooting permissions requires that you know something of both the permissions available, and the security principals involved. In our final post, we will talk about specific troubleshooting steps and best practices.