O365 AAD - Federation B2B options

Problem: Using O365 as an Extranet.  A basic analysis before starting is a minimal requirement.  The existing Extranet will make a lot of the questions fairly easy to clarify.  You can cover this in tremendous detail but to avoid information paralysis, I recommend a decision maker, and preferably someone that already works on Extranet.  A committee is cool if you have the cash but it's so hard to guess at the future, my preference is to get the broad strokes right and amended once we are in the weeds.  These four points can be answered with the right people in a meeting or may take months for complex organisations especially if there is no clear leader to make decisions.

Consideration Point:
1. Who is using the Extranet?  Clients, partners, vendors, ..., or Client Users
2. How will Client and Company users authenticate? O365 options including ADFS, another federation service e.g. Ping, Passport/Live, Google, Facebook,...
3. Self-registration or known approved Client Users?  Try to figure out what the process for on-boarding your Client User will be.
4. Client User Profile Usage?  Will the client users amend content, have the ability to share permissions or old school, they will read web published pages (read-only).  Will client users have OneDrive, use teams, only SharePoint or other O365 applications.

2.> O365 authentication
The most basic option is to allow O365 to have client users (guests), as long as a user has an O365 account they can be a Client User.  You can also use any Microsoft account for a client user.
Azure has a service that allows for you to connect users as guests, the user shall use their own AAD or ADFS or any federation service including Google and Facebook to authenticate.  Microsoft allows 5 guest accounts on AAD for every 1 member (licence user).

4.> Client Usage Profiles
O365 can share a document anonymously in a link within an email.  Obviously, this means anyone can potentially access the file.  However, to replace attachment in an email and wide distribution this is a great step forward, as you can control versions and retract the access at any point.  Additionally, the link settings can be customised to control who can use the link.  For example, you can set the specific people who get the link or you could specify only internal people get the link.  Once it is set to "Anyone" the email or link can be forwarded and literally anyone can get access.

Governance:  Manage O365 to apply the businesses rules so users comply with governance.  O365 has an easy straight forward configuration to make this happen.  When configuring sharing governance you need to ensure it is done at the O365, SharePoint Admin and Site Admin levels.  If 1 of these says no external sharing you can't share so it is a fairly granular approach.  This allows Extranet and Intranet to live on the same O365 tenant.

Licensing: As a general rule, there tends to be no cost for External users, as 5 client Users for every internal O365 user is allowed for the O365 extranet scenario.  Check with Microsoft as business scenarios play out differently.

Thoughts:

• O365 uses Azure Active Directory (B2C), there is a 1-to-1 relationship between your tenant AAD and you O365 instance.
• External accounts can be connect as guests e.g. Another AAD tenant, Micsrosoft accounts (passport), ADFS or any auth provider (SAML), Facebook, Google+, AAD B2C (separate service from AAD).  There is also a One Time Passcode option.

PowerShell to Create User Accounts for SP Install

Problem:  I keep building this script to setup accounts with permissions to put a SharePoint farm using AutoSPInstaller.  I have decided to post so I don't have to go look for this each time.  My list is based on the accounts for AutoSPInstaller recommended install accounts per Tobias Lekman's blog post series.

Use Powershell to create the accounts (This script was originally given to me by Mark Slavik)

Download the PS file here (rename to be a ps1 file)

Note: ThePowerShell file creates tha accounts in the right groups.  The User Profile Service/Synchronisation Account needs "Replicating Directory Changes" permissions, this can be done in various ways and depends on if the NETBIOS name and domain name match. 

Steps to add "Replicating Directory Permissions" to the User Profile synchronisation account:
1.> Open "Active Directory Users and Computers".  Right click on the domain name in the management console and select "Delegate Control..."

2.> On the "Delegation Control Wizard" click "Next" > On the "Users or Groups" screen used to delegate control.  Click "Add" and add your User Profile Sync account.  Click "Next".

3.> On the "Tasks to Delegate" screen select the option "Create a custom task to delegate" > "Next".

4.> On the "Active Directory Object Type" screen accept the default settings and click "Next".

5.> On the "Permissions" screen check the box to allow "Replicate Directory Changes" and Click "Next".  The last screen is for review and select "Finish".

Check your account has permissions using PowerShell.  I needed to amend Tobias Lekman's script
http://lekman.codeplex.com/releases/view/65930  to make it work for me; this is 99% Tobias's work.  I also check if the account is a domain administrator as if they are you won't need to add the special permission (not recommended).  Your other option is to make the User Profile Synchronisation account a local administrator on the VM where the User Profile Service is running.

Alternatively check the permissions thru the AD User and groups UI:

Summary: Add 10 (or as many as you decide to use) accounts.  SP_Install needs administrator domains permissions all the others just need domain user account access.  The SP_Install account needs SQL roles DBCREATOR and SECURITYADMIN. Lastly, ensure the SP_ProfileSync account has "Replicating Directory Changes" permissions.  These permissions are implicit if the SP_ProfileSync account is a local admin or part of the domains administrators group.

Tip: The Execute method of job definition Microsoft.SharePoint.Diagnostics.SPDiagnosticsMetricsProvider (ID ..) threw an exception. More information is included below. An update conflict has occurred, and you must re-try this action. The object SPWebService was updated by demo\sp_farm, in the OWSTIMER (8140) process, on machine... 

 

Changing Password setting in AD using Group Policy

Problem: On my development machines i often don't want to have to change my password every 42 days or adhere to the default group policy setting for password when using AD.  I have multiple VM on multiple domains and changing passwords is a hassle.

Initial Hypothesis: Passwords are normally lost in one of three ways:
1) data breach
2) social engineering or phishing
3) malware
The following group policy helps open a machine in a dev environment but are obviously bad practice:
Change group policy to not change the default password after X days, disable password complexity, and remove password history.  Also allow users to change passwords immediately.  Use the Group Management Policy Editor on the AD machine.

Resolution:
Start > Run... > gpmc.msc
Navigate to the domain you wish to amend the group policy for (in my case it is demo.dev)
Right Click the default Group Policy as shown below and select "Edit"

Navigate Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy.

Edit the Password Policy as you want it.
Save & Close the windows.
Run the windows command prompt (dos prompt): cmd>gpupdate

Reset your AD Pswd history

Problem:  As a developer I setup a development machine on my own network and the default security policy forces me to change my password every 60 days.

Hypothesis:  Use Powershell to change how often the password needs to be reset in AD.  I don't know this so if anyone has this script please post it.

Resolution: Use the PS to remove you history.  This at lease allows me to reuse pswds repeatedly so I don't ned up with a lot of versions.  I have multiple VM so it's pretty useful to know my passwords are consistant.  Thanks to Brad Turner for posting this script.

# Pass the number of days to retain on the cmdline
param ([string]$NumDaysToKeepPwdHistory = 14)
# Calculate the date to clear password history against
[string]$ClearPwdHistoryDate= [DateTime]::Now.AddDays(-$NumDaysToKeepPwdHistory).ToUniversalTime()
# Get the WMI Object for your sever (use your server name)
$myserver = @(get-wmiobject-class "Win2008R2-machine6" -namespace "root\MicrosoftIdentityIntegrationServer" -computer ".")
# Clear the Password History
Write-Host "Clearing the Password History prior to (UTC)" $ClearPwdHistoryDate
Write-Host "Result: " $myserver[0].ClearPasswordHistory($ClearPwdHistoryDate).ReturnValue
# New line
trap{
Write-Host "'nError: $($_.Exception.Message)'n" -foregroundcolorwhite -backgroundcolordarkred
Exit
}

Tip:  This should not be done in production, only use on development environements.

Read More:
Brad Turner on removing Pswd history

Update: 2 April 2011 - Edit password setting using Group Policy 

AD account password out of sync with the managed service account within SharePoint

Problem: I am trying to start services on a server, when I start the Search Foundation service I get the following error: "The password for the account ...\..., as currently stored in SharePoint, is not the same as the current password for the account within Active Directory.  To fix this with Powershell, run Set-SPManagedAccount -UseExistingPassword."

Initial Hypothesis: The password for the account I am using to run the service using has been changed in AD, this does not match the password stored in the SharePoint.

Resolution: Reset the AD Password



Ensure SharePoint is using the correct pswd i.e. chnage the store managed account password as shown below using the Set-SPManagedAccount cmd.



Extranet user access options - Farm architecture design considerations

Problem: What is the best approach for an extranet?

Hypothesis:
You are implement SharePoint 2010 and you need users to have remote access, the 2 key technology impact areas are:
• Authentication to SharePoint 2010; and
• Remote access mechanism (External users).
I will deal with each question separately for simplicity.

Authentication
SharePoint 2010 has 2 mechanisms for authentication: classic (MOSS approach) and claims based. I would almost always recommend using Claims based authentication as this allows you to hook into any credential provider such as LDAP, AD, SQL or a custom provider. For example a recent project involved authentication from Active Directory & an IBM LDAP provider, this was relatively easy to do using claims based authentication.  If you have a custom Single Sign-On (SSO) solution you can write your own claims provider.
Remote Access
The answer for where to deploy SharePoint is … “It depends on what you have currently, your licencing and security requirements.”

Option 1
You can put SharePoint in your DMZ (public area) and use a reverse proxy and allow users access to you SharePoint farm. You will probably want to use SSL between the external end users and the reverse proxy.  The traffic between the SharePoint Farm the proxy won’t be under SSL. This approach is good for easy access, high performance and easy setup. This approach is not as secure as getting users to login to your network using VPN access. The advantage is you merely need SSL setup (my preference is firewall SSL termination i.e BlueCoat, most hardware firewalls offer this including F5’s Big-IP, you can also use the latest ISA/UMG proxy software to do SSL termination. Microsoft’s ISA 2006 has SSL termination built and is a pretty good solution. I believe UMG is the update to ISA.  SharePoint requires sticky sessions so if you are using a hardware or software based load balanced, you must have sticky sessions enabled.

Option 2
Another option is to use SSL NIC’s or my least favourite but most commonly used option is SSL on the server. You can still have your firewall in place but you don’t use a reverse proxy. I would definitely go for a reverse proxy with external access over SSL but this options is available on smaller SharePoint farms.  You can also load balance using NLB.  SSL adds about a 35% overhead to CPU resources on the server and SSL NIC cards can drastically improve CPU utilisation, however I would prefer to terminate at the firewall if possible.

Option 3
VPN solutions – Either IPSec or SSL-VPN’s are a good option but it depends on your infrastructure as setting up a VPN is a program in itself. Remote offices are already on VPN or some tunnelling technology but this doesn’t work for home users or 3rd parties as you need to give them remote access which generally involves RSA token or some sort of security token. This is the most secure option and once a user is on the network they will access your private SharePoint farm over http.

Resolution:  The general answer as always in SharePoint is "It depends ...".
I would recommend profiling all type of possible users something like

Role: Head Office User
Description: Http access from the LAN authenticating using AD.


Role: Satellite Office User
Description: Remote office has a VPN tunnel/MPLS to the head office, employees are authenticated using AD and will use http to access the SharePoint farm.

Role: Employee at home
Description: http (SSL-VPN) AD Employees have SSL-VPN access and once connected used http to view the SharePoint farm.  Authenticated using AD.


Role: 3rd Party users https SQL database or AD
Description: Suppliers need to with SharePoint, they will access 2 SharePoint load balanced servers in the DMZ using https.  The firewall is an ISA server 2006 which offers SSL termination and host header redirection.....

You can also surface the same site using different urls, so have an internal site and then a site in the DMZ.

When doing your farm architecture other points to bear in mind are redundancy, performance & licencing.  This coupled with your existing technology status and your SharePoint will provide a accessible, stable, scalable, preformant, secure SharePoint farm.   Designing your farm will reduce you licencing costs dramatically while providing the best solution to the business.

Number of Accounts needed for SP2010 & Managed service accounts

Problem: How many accounts are required for SharePoint 2010?
Hypothesis: In MOSS I used 7 accounts for farm installs using my default slip-steamed medium/large farm install.  It really depended on what you needed to run.  You can use service accounts to run services in SP2010.
Resolution: SP2010 introduces managed service accounts, that are used for running SharePoint services.  You don't need to know password and it changes the account passwords per your SharePoint policy so a better option in my opinion so I have used them on my 2 installs.  Also pretty nice to only require the 3 accounts for install as shown below:
http://social.msdn.microsoft.com/Forums/en/sharepoint2010general/thread/a740e3ee-6f2d-473e-a63b-d97e52513754
http://technet.microsoft.com/en-us/library/ee662513(office.14).aspx

Summary:
Need AD accounts

1. Administrator account (Admin on local SP boxes, needs domain user account permissions, pref db owner
2. Farm service account/database access account (needs domain user account permissions)
3. Microsoft SharePoint Foundation 2010 search service account (needs domain user account permissions)

SharePoint 2010 membership provider/Claims based authentication

What is Claims based authentication?
Allows SharePoint to communicate with external membership providers over open communication standards to authenticate a user. The membership provide determines if the user is valid. A token either saying the user is valid or invalid is returned. More info
Authorisation is handled by SharePoint or the logic can be applied by external membership providers.
Forms Based Authentication (FBA) works with your membership provider to give users access off a provide such as LDAP providers like Active Directory (AD).
You can also setup Windows Authentication in the "Identity Provider" where you use either NTLM or Kerbros as well as other ASP.NET providers.
The SecurityTokenService (STS) Application ensures claims tokens are being passed correctly between the provider and SharePoint (Our SPSite). STS allows for multiple providers plugged in our site. STS is setup in the web.config. More info.
Tip: Sign in Url - when setting up FBA, you can use a custom page to add business logic, for instance I assign rights/permissions when a user comes from a trusted 3rd party. More info.
Tip: FBA doesn't have to use claims based authentication as in MOSS. If you have AD but need to provide Internet access then Claims based adds no value. More info.
NTLM vs Kerbros: NTLM stands for NT Lan Manager. Microsoft's challenge response authentication protocol. Kerbros is an open standard authentication protocol, it is more secure in that it is encrypted and token are used to validate parties in the communication process. Kerbros requires ADFS.  Kerbros is therefore more secure however you do need to have a network that supports Kerbrose for it to work. Kerbros is more chatty and introduces more points of failure. NTML is more efficient. Depending on usage such as Internet it will determine the protocol.  I tend to lean towards Kerbros in larger SharePoint implementations if the network supports.  Internet scenarios don't expose ADFS to the Internet so Kerbros is not an option.

More Info:
Setting up SQL claims based FBA

Updated: 2014-02-27
Setting up ADFS2.0
Configure an Authentication Provider for a Web App to use ADFS

http://www.sharepointpals.com/post/Creating-an-ADFS20-TrustedIdentityTokenIssuer-using-PowerShell-in-SharePoint-2013
http://www.sharepointpals.com/post/How-to-Add-more-than-One-SharePoint-2013-WebApplication-to-a-SPTrustedIdentityTokenIssuer-on-ADFS-using-PowerShell

Installing Sharepoint 2010 options & Basic SP2010 manual installation tips

You have 4 options for installing SharePoint farms:

1. Manually sun the setup and follow the installation wizard (this is discussed below);
2. Deploy SharePoint 2010 via a slipstream install, this was my prefered method for MOSS.  I ran the install from a batch file that got it's configuration from an xml file;
3. PSConfig installation (sic); or
4. Use PowerShell to Install SharePoint. and technet scripted deployment

 Summary: For environments such as live the PowerShell/Slipstreamed options are best as they allow for recreation and input is always identical.  Manual install is fine for development servers however their is no advantage except for a lower learning curve for the IT admin.

Post below is a Manual Installation:
SP2010 install video
Install the pre-requisites

• Prerequisits will install roles and software you need internet access on the server to fetch the prerequisits software (this can be put on the server to stop the machine going to the Internet).
• Preferably have seperate instance of SQL 2008 R2 but for dev/demo machines. If 1 machine rather setup SQL devleoper or a instance (I dislike using SQL express).

Setup / SP 2010 install tips

• Install "Server farm" option not standalone
• "Complete" installs all component prefered option
• Connect to a new farm
• Database server name us name rather than IP (incase it changes)
• DB account (must already exist in AD)
• Passphrase used to connect new servers to this server farm (remeber/keep it)
• Kerbros - if your network supports it but use NTLM if you aren't sure.
• Wizard - follow screens, services can be heavy so add them when you need them, however for demo I select all services and create a new site collection - a good options is to use the Team Site Template.
• Need 3 accounts for min Best practices: 1) Managed Service account (domain user account) that SQL Server runs in, 2) Managed Service Account (domain user account) all services will be installed on this account (MS suggests using a seperate managed account for each service) on small farm s/dev I use 1 account,  and 3) Farm install account (domain account) this needs to be a local admin on each SP2010 server and have creator & dbsecurity accouts on SQL.
• 5 Accounts is a better option excluding the SQL services account namely:

1. SP-Install - domain account with admin local rights on each WFE also need SQL dbcreator and securityadmin roles (used to login and install binaries, use this account for add new servers to the farm),

2. SP-Farm - domain account no permissions, will be the account to run timer job and other key roles,
3. SP-Web-App-Pool - Content Web app account - Domain account only,
4. SP-Services - Install all services to use the same domain account, this can be seperate for each services but for easy of setup and mainentance use 1 account.  Exception is the User Profiles service, setup seperately using Spence Harbors post as the user domain account needs unique security, and
5. SP-Crawl - Used to crawl SP content.

Additional Info on accounts:

1. SQL Server needs to run as a windows service, you need an account, I would use a managed account in AD with no permissions called SP2010-SQLService.
2. Farm Installation account, you need to create a domain user account in AD, give the account local admin access to each SP2010 machine.  Call it SP2010-Admin.
3. SP2010 Service account/s, you need to create a managed service account with zero permissions in AD.  You can use 1 account or create a seperate account for each service (MS Best Practice).  I call my 1 account SP2010-Services. 

Use slipstreaming for SharePoint it's faster and consistant.
Use:

1. Windows 2008 R2 x64
2. SQL 2008 x64
3. On HyperV/VMWare except the db which should be a seperate physical machine/SAN

Update 08 November 2010:  Notes on deploying a 3 server farm consisting of 2 WFE's that are NLB using Windows NLB.  Installation done using AutoSPInstaller. 
Installation Notes for a 3 server NLB SharePoint 2010 farm

Update 10 November 2010: SharePoint install account - Todd Klindt.
Update 11 May 2011: SharePoint 2010 database management article