Hot answers tagged

12

The farm account does not need to be a member of the local Administrator group. For a farm it should be a domain user, when you run the configuration wizard it will be granted the required user rights, file permissions, registry permissions, DCOM permissions, and DB permissions. When you do your initial Sync with UPS, you will need to add the farm account ...


12

This is a claims token for Windows Authentication. SharePoint 2013, unlike 2010, uses Claims as default authentication type! More here: http://msdn.microsoft.com/en-us/library/gg481769.aspx


6

A SharePoint Farm is like a Business Park: then Site Collections are Buildings: As Site Collection Owner you have a MasterKey to all information in this building. Permission Profiles can be centrally managed, but alas most often not customized Subsites (Webs) are Rooms: Document Libraries/Lists are Cabinets: Documents-Sets/Folders are File Suspension ...


4

Not entirely sure why you add "except CA". Sure you can automate security using PowerShell. But this gives you only real value if you have multiple farm environments that you want to stay as much "the same" as possible. The important thing here is to harden security for your farm, not really how you do it. As a primer you should read Plan security hardening ...


4

The first thing to keep in mind is that rights are being granted to service accounts, not accounts actually associated with a specific user. So these accounts should not be used to log into a server unless it is a highly specific and unique situation. In fact, you can optionally configure these accounts so that they cannot be used to log on to a server via ...


3

Yes the service account should perform a log in operation at least once on the server that you intend running the User Profile Service application. When establishing the UPSA your service account needs local admin rights. Once you've got it all setup and running you can revoke these rights.


3

PowerShell can, so by implication so can the SharePoint API, check out: http://technet.microsoft.com/en-us/library/ff724280.aspx#section1 and here too: http://social.technet.microsoft.com/Forums/en/sharepoint2010setup/thread/c3e2960c-56e3-4693-bcd2-dc15250bd2a9


3

I would definately start from scratch! The account used for install has special permissions, and if these have been intertwined with farm account it is a mess. You will spend far longer time trying to undo the security related problems in the previous install than starting over. I usually define a managed account for each service application, one for each ...


3

if you ask for the best practice then: Create the SQL_Admin: The SQL Server service account is used to run SQL Server. It is the service account for the following SQL Server services: MSSQLSERVER SQLSERVERAGENT. SQL Admin on the SQL Server. it should be domain user with Local Administrator on the SQL Server. read more about the best practice: SharePoint ...


3

Once you change the service account you have to make sure following things. new service account have DBO rights on the content dB and also have permission on configuration db. account should be part of iiurs_user groups on the sharepoint server object cache settings configured properly(super user n super reader account) perform iisreset on all server if ...


2

That is happening because you are running an service app pool as Network Service or Local System. That account with the $ at the end is your servers identity. You can either authorize that account to access the data or run you service applications as a user that is authorized to access the database. if your Central Admin site root was: http://ca/ then ...


2

This is what we run for a medium/large farm: SP_Farm Farm Account SP_Sandbox Sandboxed Code Service SP_Search Server Search Service, Search Service App Pool SP_Crawl Search Crawl SP_Sync User Profile Sync, User Profile Service Proxy App Pool SP_Usage Web Analytics Processing Service, Web Analytics App Pool SP_MetaData Managed Metadata Service ...


2

The server was previously moved from one OU to another, picking up the GPO policy that sets the log on as batch permissions, but wasn't restarted afterwards or since. The user accounts that were running the previous Web Applications maintained their permissions, and it was only the new user accounts that were blocked. Removed the GPO restrictions, and ...


2

Alerts are generated in two phases. The first phase is done when the item is saved that would generate alert and that is done in the context of the application pool. It creates a summary of what changed on the item and saves that to a table inside SharePoint. The second is a Timer Job that checks all defined alerts against the table of changes and then ...


2

In SharePoint 2010, accounts for Farms, Web Applications and Service App pools can be set from a central location in Central Admin called "Managed Account". Visit this technet blog for the detailed explanation on Managed Accounts - http://blogs.technet.com/b/seanearp/archive/2011/01/25/updating-passwords-on-sharepoint-2010.aspx In your case, follow these ...


2

You have two main options: Give the AppPool access to the database and run your database code inside SPSecurity.RunWithElevatedPrivileges Use Windows impersonation LogonUser around your database code. See section 3. Using Win32 API in Impersonation in SharePoint : An Extreme Overview. The big question is then where to store the username/password. It can ...


2

There are a few more considerations when you are hardening a Sharepoint box. Kerberos, SQL Aliases, firewall policies and fine grained permission policies on the box itself. I recommend that you take a look at http://technet.microsoft.com/en-us/library/cc288143%28v=office.14%29.aspx and get familiar with SQL Hardening as well ...


2

You cannot access this feature if your account is not Local Admin on the SharePoint server even you are Farm Admin. SharePoint grab this information from IIS and if you are not local admin the you cannot access the IIS...another check you can do, try to create a new webapplication that option will be grayed out for you. either add yourself as local admin ...


2

Also, try right click on "SharePoint 2013 Central Administration" and select "Run as administrator".


2

1.) i would recommend to separate set for each farm, your fear is correct and that happens many times. so don't risk your Production. 2.) Best Practice is always recommend to use a separate account which perform Installation, configuration, Routine Maintenance, Pathes/CU and day to day operation i.e powershell. From your list sp_install is the account which ...


2

It's all about the Principle of Least Access. For one thing, you pretty much never want to force your farm account to change passwords every X amount of time because that farm account is used for a ton of internal processes ranging from deciding to run timer jobs on your various servers to (at least prior to 2013) getting permission to crawl over your user ...


2

Form my previous experience, SharePoint Search service account(sp_search in your case) needs to be added to Local admin group when you are configuring search and after configuration, it can be removed from local admin group. This setup is not required for other Service accounts(except User Profile service which also requires a admin access when ...


2

All timer jobs will run under the context of Sharepoint 2010 timerservice context.


2

Yes you can use same set of services accounts. But there is some risk involved in this approach. We used the same concept but after couple of months we have to separate it(one unique set for each farm). Let's say, you have to change the password of the accounts once per year or less( as per the security policy or group policy).In this case you have to ...


1

To set the account associated with a particular Service Instance using Windows PowerShell we simply get the ProcessIdentity property of the Service Instance and set its Username property. Once set we call Update() to update the Configuration Database and then Deploy() to push the change out to all Service Instances. $pi = $svc.Service.ProcessIdentity if ...


1

If your setup account used for the following task: Setup SharePoint Products Configuration Wizard Configure and manage the server farm. Act as the application pool identity for the SharePoint Central Administration Web site. Run the Microsoft SharePoint Foundation Workflow Timer Service. Then make sure the following permission exists. Local ...


1

You could remove it, though it's likely to come back as it will be getting added by a workflow / event receiver type process. The permission is like an NTFS traverse folder permission Either way it will have full access provided by the web application policy. It is normally the account that is running the web app pool or an account that has marked as a ...


1

What is SharePoint\System account? So here is the answer SHAREPOINT\System account is the same account used by application pool of your SharePoint web application in IIS at the time of creation/extension of respective web application. This is the account which is used when you run your code in under elevated privileges by ...


1

Even if you remove the System Account from your site permission settings still it will continue to have the access on the entire site including every content and documents. At a higher level it has the access on the entire web application under whom this site is created. Because this is the same account used by the application pool of the SharePoint web ...


1

The sure way will be to get SPFarm.Local.TimerService.ProcessIdentity.UserName



Only top voted, non community-wiki answers of a minimum length are eligible