Probably the most critical and overlooked portion of SharePoint installation is security. Without a well thought out security strategy and a plan of action, it is likely that SharePoint 2013 will not behave as expected and users will receive unexpected login prompts while administrators will be denied access to areas where they should have access.
In this article, baseline security sufficient to run a SharePoint lab, but still “least privileges” ready, is demonstrated using three accounts.
The accounts configured for SharePoint 2013 include:
ExpertAssist\SPAppPool – Responsible for running SharePoint’s web applications and the SharePoint timer.
ExpertAssist\SPAdmin – The administrative user capable of managing the farm settings. More than likely, this user will also be used for development.
ExpertAssist\SPSetup – The setup user with DBCreator and SecurityAdmin roles on the SQL Server.
ExpertAssist\Ulysses – An end user.
Logging into a server using Remote Desktop is the more common way of interacting with a server. In this session, instead of logging into VMWare, use Remote Desktop.
If the server name does not respond, try the IP address.
In the example below, the command ipconfig is run in the server’s PowerShell window to retrieve its IP address. From there, use the host’s Remote Desktop Connection to connect to the server.
Login as the domain administrator that has rights to add new users.
Open the Start Menu.
The Start Menu will appear when the mouse is held over the bottom left corner of the screen.
Open the Administrative Tools.
Launch Active Directory Users and Computers.
If it fails to load, be sure to login as a user with sufficient rights to manage users, such as Administrator.
Create a new users under Managed Service Accounts.
Create the SPAppPool account.
This account will run SharePoint’s timer service and will serve as the application pool account for the IIS websites.
Create a new user called SPAdmin.
This user will be responsible for day to day operations in SharePoint and it can also be used for development using Visual Studio 2012. This account will NOT be used to install SharePoint.
Create the SPSetup account.
This account will be used to install SharePoint. This account will have local administrative access on the server and will also have dbcreator and securityadmin rights on the SQL Server itself.
One of the requirements for SPSetup is that it needs local admin rights to the machine where SharePoint is to be installed. Because this is a domain controller, however, there is no Local Administrators group option, therefore the SPSetup needs to be added to a group with similar rights, such as Domain Admins.
Open ADUC and click on Domain Admins.
Add SPSetup to Domain Admins.
PLEASE DO NOT DO THIS IN A PRODUCTION ENVIRONMENT!
Grant Right to SQL Server
Login to SQL Server Management Studio.
All apps will appear. Click on SQL Server Management Studio.
Right mouse key on the icon and then pin it to the taskbar.
Connect to the SQL Server (local).
Create a new login. This step grants the windows service accounts rights to the SQL Server.
Create a new login for SPAppPool.
Before installing SharePoint, log out of the Administrator account and log back in as SPSetup.
Ulysses Ludwig is a SharePoint architect with over 16 years in the IT and computer industry. Ulysses' primary focus is SharePoint but he dabbles in the latest web technologies and likes to develop software in his spare time.
So I have noticed that Google refers lots of people to my blog for “Fly Out Menus”. I imagine many of you are disappointed when you find that the article is for enabling the fly out only on the top of the page...
I was lazy and decided to uninstall my Beta SharePoint, delete all of the databases, then re-install SharePoint 2010 RTM on my server. Everything ran perfectly through the install until I ran the SharePoint...