Shortcuts in Configuring Technology Solutions

Over the last couple of years, I have reviewed many environments. Very few have been great, some have been good, most have left little to be desired. Most technologies are fairly easy to install but it does take some dedication to the products in order to configure them correctly. Most organizations either take shortcuts out of the lack of experience or because they don’t believe their environment or network is in harms way. No matter the reason, I haven’t met an organization yet who didn’t care about confidentiality, integrity, and availability. Hopefully, it will help those interested in building solutions that are as secure as the technology allows them to be.

Shannon Bray, Microsoft Certified Master

Advertisement

The Aftermath of Launching the SharePoint Farm Configuration Wizard

After installing Microsoft SharePoint and executing the Products and Configuration Wizard, a browser is opened asking if you would like to start the SharePoint Farm Configuration Wizard. If you have been a consultant in Microsoft SharePoint for any period of time, you have certainly heard that using the Farm Configuration Wizard to build non-evaluation or demo sites isn’t a great idea. I have reviewed many SharePoint Farms out there and a great number have indeed been installed using this. After talking to the client, I often find out that they paid someone to do this and often time the engagement took weeks. One of the benefits of the Farm Configuration Wizard is that pretty much anyone can do it without knowing anything about Microsoft SharePoint and have things up and running. The bad part about it is that pretty much anyone can do it without knowing anything about Microsoft SharePoint. But how does one get something that was not recommended to something better? Here we will talk about the affects of the Farm Configuration Wizard and how to address the issues. What I won’t tell you is if it is a bad idea or not because to me, as long as you understand how it configures things then the decision should be yours.

Now before we go to far, there is a “right way” and a “wrong way” to run the Farm Configuration Wizard. The wrong way is to use the same Farm Account (aka Data Access Account) to configure all of the services. This is a little tougher to clean up. It is critical that you create a new SharePoint Managed Account. If you do not, the SharePoint Farm Account is used for absolutely everything! You also want to make sure that the account you use for your Farm Account, isn’t used by anything else and doesn’t have administration rights to anything. The single exception to this rule is that the Farm Account has to be given Local Admin rights to the server that is going to run the User Profile Synchronization Service. It has to be a Local Admin only during the provisioning.

The first tell-tale sign that the Farm Configuration Wizard was used to create your farm is the name of the databases. The wizard applies a GUID behind the database names. While it is quite ugly, technically there is nothing wrong with it. If a service is provisioned multiple times, it would take some work (or Windows PowerShell) to determine which database went with which.

The nice thing about the database naming convention of the Farm Configuration Wizard is that now I have a pretty good idea of how the rest of the farm is configured without having to look at much.  My biggest issue with this type of install in a production environment is that there is a good chance that

• Everything is built as non-encrypted SharePoint sites.
• The SharePoint Services and the SharePoint Web Content Applications are using a shared account
• The wizard does assign ALL of the services to the same Application Pool which is not bad; However, one of these services is the Secure Store Service. Microsoft makes the following recommendation: “Because Secure Store deals with sensitive information, we recommend that you use a separate application server just for the Secure Store Service for better security.”

In reality, I’m not sure either of these last two bullets actually provide any additional security as getting the credentials to a Managed Account is fairly simple. If everything is being hosted over non-encrypted websites, security probably isn’t your priority anyway ~ though, it should be!

The next service to review is Enterprise Search. The Farm Configuration Wizard has configured the Search Content account as the Services Account. This really isn’t that big of an issue as you would most likely need to come in and change this no matter how the service was built. The key here is that:

•  The Search Content account will need to have permissions to read content on your network if you want it searched. This means that you wouldn’t want to use a SharePoint Managed Account to do this because of the ease of gaining these credentials. In addition, the Search Content account doesn’t honor the Managed Account contract any way which means that if you change the account password, Search will be broken until you come in and change the Search Content account.
• The User Profile Service Application (UPA) is also configured for the Service Account to search people, so once you fix the Search Content account, that must be updated in the UPA as well. I have seen several references that say you should delete the UPA and recreate it, but no one says why so I doubt the validity of that statement in the 2013 product. I’ll look more into this.

So in wrapping up, the Farm Configuration Wizard is more of a security hole than anything; it is far removed from the least privileges model but the wizard isn’t designed for security. It is designed to help get you up and running quickly. While the wizard is able to use an additional account other than the Farm Account, many implementations do not exercise this so the Farm Account is over used. When a separate account is used, it too gets used for a little more than it should. No matter how you look at it, Microsoft SharePoint requires some planning beyond just running the wizard. Once this is done, Central Administration and the other web applications should be over SSL. If the sites aren’t being exposed outside, then this is even easier since a domain CA will function just fine.

SharePoint 2013 Ports, Proxies and Protocols Diagram

Lesson: You should know which ports, proxies, and protocols are needed for your particular scenario. Include them in your documentation!

Marek Samaj created a diagram of the Microsoft SharePoint 2013 ports, proxies, and protocols and did a fantastic job. I am posting the diagram here so that I have it with other information that I use on often.

Marek Samaj: Original Source

Get the Password of Microsoft SharePoint Managed Accounts

Lesson: Do not use SharePoint Managed Accounts as administration or installation accounts!

From time to time, the folks who built a Microsoft SharePoint farm may not be available or remember the passwords of the SharePoint Managed Accounts. Instead of going through the hassle of resetting everything, you could use the script provided below to get a list of all the SharePoint Managed Accounts and list the various passwords as shown in the image below.

The script does require elevated permissions. If a user tries to execute it without elevation, the SharePoint Managed Accounts are listed, but the passwords are not. The script can be executed on any Microsoft SharePoint server so as an organization, you should limit:

• Who has access to the server(s)
• Who has the ability to execute Windows PowerShell scripts
• Who has the privilege to execute as an Administrator

The important take away here is that this information may not be as secure as you think. You should make sure that these accounts have only the rights that they need and that those who administer the servers understand that security starts with Least Privileges.

——————————————————————————————————————————————–

To download an alternate version that will get the SharePoint Farm account, you may visit here.

You can also retrieve this information from IIS as shown here.

——————————————————————————————————————————————–

## PowerShell Script ###

Add-PSSnapin Microsoft.SharePoint.Powershell -ErrorAction SilentlyContinue

function Bindings()
{
return [System.Reflection.BindingFlags]::CreateInstance -bor
[System.Reflection.BindingFlags]::GetField -bor
[System.Reflection.BindingFlags]::Instance -bor
[System.Reflection.BindingFlags]::NonPublic
}

function GetFieldValue([object]$o, [string]$fieldName)
{
$bindings = Bindings
return $o.GetType().GetField($fieldName, $bindings).GetValue($o);
}

function ConvertTo-UnsecureString([System.Security.SecureString]$string)
{
$intptr = [System.IntPtr]::Zero
$unmanagedString = [System.Runtime.InteropServices.Marshal]::SecureStringToGlobalAllocUnicode($string)
$unsecureString = [System.Runtime.InteropServices.Marshal]::PtrToStringUni($unmanagedString)
[System.Runtime.InteropServices.Marshal]::ZeroFreeGlobalAllocUnicode($unmanagedString)
return $unsecureString
}
Get-SPManagedAccount | select UserName, @{Name=”Password”; Expression={ConvertTo-UnsecureString (GetFieldValue $_ “m_Password”).SecureStringValue}}

Central Administration and SSL

Lesson: ALL Microsoft SharePoint sites should be encrypted. It is easy to do.

In a large number of Microsoft SharePoint farms that I have reviewed over the past few year, most lack encryption. In discussions, most people feel that since the site is not exposed to the outside world, SSL isn’t that important. As I start my argument, I would like to point out that inside Microsoft SharePoint, any page that accepts users credentials over non-SSL shows the following:

“Warning: this page is not encrypted for secure communication. User names, passwords, and any other information will be sent in clear text. For more information, contact your administrator.”

Note: Clear text in this case doesn’t necessary mean that it is easily read, it just means that it isn’t encrypted. Credentials that are hashed are still considered clear text.

To counter the point that since CA is not exposed outside, I would like to state that because of this, it is easier to resolve that an external site. I have often found that some of the servers that hosted Central Administration were actually exposed externally. Here are the steps to correct the issue.

• Ensure you have a server that that has the Active Directory Certificate Services role added.

• Once the role is added, you will be able to create a new domain certificate from with IIS (if you have adequate permissions).
  • Open IIS > Server Certificates
  • Create Domain Certificate > Fill out the wizard
  • The Common Name and the Host-A record will be the same.

• Add a Host-A record in DNS that points to the web server or load balancer IP address.

• Create / Convert Central Administration on port 443

Open up PowerShell ISE as an administrator and then type the following:

              Add-PSSnapin Microsoft.SharePoint.Powershell -EA 0

              Set-SPCentralAdministration -Port 443

Now go to IIS (on every server hosting the site) and modify the bindings.

Once the bindings are set, flush the DNS and test the URL from a server not hosting Central Administration. Remember that https://ca.secsp.us won’t come up on the server hosting it due to the Loopback Check being enabled (or at least it should be).

Finally, you will need to modify your Alternate Access Mappings (AAM) so that the internal URL is using the new one.

How secure is your SharePoint Farm account?

Lesson: The SharePoint Farm account should not be a local or domain administrator. The Farm account should have limited use!

Microsoft SharePoint offers a great deal of features that helps solve many of our business solutions. In reviewing many SharePoint farms over the past years, I have found that while most people think they are security focus, they take short cuts and disregard security recommendations. In doing so, they open up not only their SharePoint to an attack but their entire network; case in point, let’s assume you (or someone in your organization) used the SharePoint 2013 Products Configuration Wizard, in doing so, I am making the following assumptions:

• The Farm Account is probably a local administrator; it may even be a domain admin.
• The Farm Account has complete control of your SharePoint environment.
• The Farm Account is the account for every SharePoint Application Service.
• The Farm Account has more rights than it needs to your SQL Servers.

Now, you may be thinking that this is OK because no one knows the Farm Account password. Before you pat yourself on the back, jump on the SharePoint server hosing Central Administration and open up Internet Information Services (IIS) Manager. There will you find all of the Application Pools and Web Sites that make up your SharePoint server that are hosted on that particular server. Take note of the name ‘SharePoint Central Administration v4’.

If you launch a CMD prompt (with Administrator rights), you can execute the following:

C:WindowsSystem32inetsrvappcmd list apppool “SharePoint Central Administration v4” /text:*

You should see something similar to below.

In case you missed it in the above image, check out the highlighted area below.

Remember that warning in Central Administration Monitoring that states that your Farm Account shouldn’t be a local administrator? Maybe it’s time to go fix that.

 

Gathering Requirements for SharePoint 2013

The implementation of Microsoft SharePoint 2013 will be conducted in several distinct phases that include:

• Discover and Refine Requirements
• Analyze and Prioritize Requirements
• Design a Solution That Meets the Requirements
• Govern Solution Delivery, Operation, and Maintenance

This document will cover the first phase: Discover and Refine Requirements. In order to be successful in the planning of Microsoft SharePoint, we will focus on gathering requirements that focus on these key areas:

• Understanding the Minimum Hardware Requirements
• Understanding BCM Options
• Planning a Successful SharePoint Solution Strategy
• Planning a Governance Strategy
• Planning the Information Architecture
• Discovery of Business Processes that will use Microsoft SharePoint 2010
• Understanding the Security Requirements
• Understanding the Business Intelligence Requirements
• Understanding how the Role of the Office Client
• Understanding the Business Continuity Requirements
• Understanding of Performance and Reliability Requirements

We will break down each of these sections in hopes of capturing all of the requirements in the planning phase as to alleviate any confusion or exclusion of the requirements.

 

https://shannonbray.files.wordpress.com/2012/11/contoso-gathering-requirements.pdf

SPC12 Speaking Schedule …

Like many of you, I am anxiously awaiting SPC 2012. I am presenting three topics this year.

Gathering   Requirements: Asking the Right Questions for Building a SharePoint 2013   Environment			SPC102	Breakout Session	IT Professional	Lagoon EFKL	Breakout Session 04: Tues 9:00am – 10:15am	Shannon   Bray
Implementing   Federated (Cross-Farm) Services in SharePoint 2013			SPC128	Breakout Session	IT Professional	Lagoon ABGH	Breakout Session 11: Wed 1:45pm – 3:00pm	Shannon   Bray
Surfacing   LOB Data in SharePoint 2013 using BCS and Search			SPC232	Breakout Session	IT Professional	Lagoon ABGH	Breakout Session 16: Thur 12:00pm – 1:15pm	Shannon   Bray

 

Microsoft SharePoint 2013: Designing and Architecting Solutions

It has been quite some time since my last blog post. With the release of SharePoint 2013, I spent my focus working on my new book Microsoft SharePoint 2013: Designing and Architecting Solutions; it will be published by MS Press. I also don’t like to blog about a product that hasn’t RTM’d yet. Microsoft has a way of changing the product and many of the early blog posts become meaningless.

My book is due for completion in January and I am hoping for a release around March. The chapter line up looks like this:

Chapter 1: Understanding the Microsoft SharePoint 15 Architecture                   

 Chapter 2: Introducing Windows PowerShell and the Wave 15 cmdlets               

Chapter 3: Gathering Requirements

Chapter 4: Understanding the Service Application Model                                             

 Chapter 5: Designing for SharePoint’s Storage Requirements                                   

Chapter 6: Mapping Authentication and Authorization to Requirements            

Chapter 7: Designing for Platform Security                                                                            

Chapter 8: Planning an Upgrade Strategy                                                                                

Chapter 9: Maintaining and Monitoring Microsoft SharePoint                                    

Chapter 10: Planning your Business Continuity Management Strategy

Chapter 11: Validating Your Architecture

I have learned quite a bit by researching the book and hope to get some blog content out after SPC 2012.

2011 in review

The WordPress.com stats helper monkeys prepared a 2011 annual report for this blog.

Here’s an excerpt:

The concert hall at the Syndey Opera House holds 2,700 people. This blog was viewed about 55,000 times in 2011. If it were a concert at Sydney Opera House, it would take about 20 sold-out performances for that many people to see it.

Click here to see the complete report.