Hot answers tagged

13

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

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 ...


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 ...


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

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 ...


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 ...


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

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

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

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

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

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


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

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 http://social.technet.microsoft....


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

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 configuring)....


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 ...


2

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 SPSecurity....


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

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 ...


1

Can you try this: One thing to remember is that crawling SharePoint sites is different from crawling file shares or non-SharePoint websites. A few other quick pointers: •the sps3: protocol is for crawling user profiles for People Search. You can disregard anything the crawler says about it until you're ready for user profiles. •your crawl account is ...


1

Sounds like you need to read up on SharePoint security :-) You should never ever log in as any service account, that is why they are called service accounts: they are exclusively used for services! There are many good reasons for this, one of them being the one you mention regarding lockout, another being security. This account also have no special ...


1

By Default, Administrator is System Account itself. For security reason, you neither can install nor uninstall the app as a System Account. So, create a new user and assign that user a dbowner permission through SQL server management studio to app management database, SharePoint subscription setting database and the current content database where you are ...


1

AD2012\Administrator was set as the account for the Web Application Pool 80 corresponding to the Sharepoint site. Changing it to another account in CA > Security > Configure service accounts and restarting IIS solved the problem.


1

You should add the account running the application pool. If you look at the guide you linked to, he adds: corp\spwebapp



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