Showing posts with label ADFS. Show all posts
Showing posts with label ADFS. Show all posts

Friday 25 January 2019

Sunday 2 December 2018

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.

Friday 9 June 2017

SharePoint on-premise reporting options

Overview:  As always this really depends on the circumstances but my broad view on reporting for SharePoint is outlined below.

Thoughts:

  • Power BI on-prem. has not been release (at the time of this blog) but will work for SSRS reports and have the Power BI functionality that shall be embedded using an iFrame into SharePoint 1st edition only.
  • The upgrade path from SSRS SharePoint integrated mode is going to be hard, whereas the upgrade path from SSRS native mode will be simple.
  • Power-BI on-prem is not going to support SAML.  Use WAP (Web Application Proxy)/reverse proxy to get NTLM ot Kerbros tickets for authentication.  Only config is ADFS+WAP to access PowerBI on the Extranet.  If you use another Federation service will need to do a passive claim.  For Example if you use SiteMinder, you need to pass onto ADFS + WAP
  • SSRS SharePoint integrated mode shall be available only in SP2013 and SP2016 and not have any continued path going forward.


SharePoint 2013 Options:

SharePoint 2013 BI Options SharePoint 2013 SQL BI Options
Excel Services
PerformancePoint
SharePoint KPI/Filters
SSRS SharePoint Integrated Mode
Power Pivot for SharePoint

The table below shows what you client probably uses historically and the challenge is to map them out to a supportable solution on SharePoint going forward.

BI in SharePoint and the Microsoft stack has drastically changed over the past 2 years.  The next 12 months should keep this pace up with the release on Power BI.  As my knowledge in this area improves I'll update this post.

Other Posts that may be useful:
A good post to read as of EOY 2016 on BI  for SharePoint
SP2013 with SSRS 2012 SharePoint integrated Mode Overview
Installing SSRS on SP2013 Reporting Post

Monday 6 June 2016

Hybrid SharePoint and Office 365 Authentication Thoughts

Overview: Hybrid scenarios allow enterprise users to seamlessly interact between SP Online and SP on-prem instances, provide search across on-prem and online sites, access data on-prem. while using Office365/SP Online, use Office 365 apps like Flow, Video, Graph and utilise OneDrive.  Picking the right authentication allows users to have a seamless high-value experience bringing together secure access quickly.  Pretty important and to make this happen you need to deal with access.

Organisations have internal authentication mechanisms such as Microsoft's Active Directory.  Large organisations have a tough time migrating to the cloud and with the rapid changes in Security and the cloud this post aims to broadly define paths or options for architects such as myself to follow.

Options 1. Do nothing.
The 1st option is to ignore the cloud but I am going to presume you want to take advantage of Office 365.

Options 2.  Only use the cloud/O365.
Office 365 is huge and for a small or new business, I would strongly look at only using O365 using Azure AD (AAD) credentials.  This means no or little management of Active Directory (AD) and you can pretty much connect to the whole Microsoft SaaS offering quickly.  Most large SaaS offering can work with Microsoft AAD.  Generally, this option is not suitable for large enterprises.

Option 3.  Internal AD and externally use Office 365 Azure AD.
Easy to implement as the internal and external credentials do not link.  Your users do not get a single sign-on (SSO) experience.  Users use the Azure AD credentials when working with Office 365 and your internal credentials when working on the internal network.  The user needs two accounts and to know when to use them.

Option 4.  Internal AD synchronized and creates similar accounts on Azure AD.
Pretty much the same option as option 3 but the usernames appear to be the same to the end users. There are a few variations in this space, you can simply create the accounts with the same name either manually, using a CSV import or using Directory Sync (DirSync).  At this stage, the passwords and accounts are managed separately, the DirSync reduces effort and provisions and removes accounts in Azure AD to match the companies on-prem. AD.  DirSync will reach the end of support in April 2017.

Option 5.  Internal AD automatically syncronises with Azure AD including password sync.
You still have 2 accounts but the accounts on both sides are kept aligned using DirSync and password synchronization.  The same password is stored both in your on-prem. AD and in Microsoft's Azure AD for each user.  The advantage here is that the user name and password for a user is the same if using internal or external applications secured by on-prem. AD or AAD.  This is not SSO enabled, the user needs to login to both AD's separately.

Option 6.  Azure Active Directory Connect.
Similar to option 5 but the Azure AD Connect tooling does all the synchronization of accounts between on-prem. AD and AAD.  This option/method is easier than option 5 and the latest approach but fundamentally it is the same approach with 2 identical accounts for each user.
Note: Only 1 AAD Connect per AAD B2C tenant.  If you have multiple AD's (e.g. AD forest), you use a single instance of AAD connect to grab each AD's objects.
Note: AAD Connect can write back properties to AD on-prem. but it can't create objects/account.
Note: AAD Connect can selectively grab accounts e.g. exclude some OU's.
Note: Default replication is every 30 minutes, but he pswd hash syncs every 2 min, you can config Azure password rest to push back to on-prem. AD if you use password hash sync.

Options 7.  Federate (ADFS)
Active Directory Federation Service (ADFS) provides an Identify Provider and can pass claims based authentication between a trusted Identity Provider.  This post does not explain passive Identity authentication but this is the more advanced option.  There are a lot of federation services but ADFS tends to be the most common (ThinkTexture, Ping, SiteMinder).




Home Realm Discovery (HRD)

When accessing SharePoint Online, you go to AAD as each SPO has it's own AAD.  On AAD you may have ADFS, partners Ping Federation service, other organisations AAD to actually authenticate the user.  So the login experience needs to know where to authenticate the user.  To do this use MS and you can also build custom HRD.  When the user enters the username or email, they are forwarded onto the appropriate ADFS or Federation service to authenticate the user.

Ariel Gordon describes HRD at Microsoft below: 
"How does Home Realm Discovery work?
In the cases above, apps direct users to Azure AD's common endpoint, and Azure AD shows a generic sign-in page. This page waits for users to enter their username then, as soon as the focus moves away from the username field, it makes a server call to look up the configuration for the user's domain. In case of a federated domain, the login page then initiates a redirect to the federation server, such as ADFS. Users then enter their credentials on the federation server's own login page which displays their organization's branding.
When we introduced Company Branding last year, we mimicked this UX behaviour: the Azure AD sign-in page starts off with generic branding then looks up the organization's branding elements after the server call is made. In both cases (federation and company branding) the goal is to ensure that users enter their credentials on a page that reflects their organization's brand.
When does it make sense to bypass Home Realm Discovery?
If your application targets users in a single organization, there's no need to use Azure AD's Home Realm Discovery and you can "accelerate" users to their organization's sign-in page. To do this, your application needs to pass a domain hint to Azure AD, effectively stating "I've already established that the user who's about to sign in is from <this organization>."
When Azure AD receives such a hint, it performs Home Realm Discovery on the domain name hint before rendering a single pixel. If the domain is federated, Azure AD immediately redirects users to the federation server. If the domain is managed, it checks whether Company Branding has been configured for the domain and displays it when found."

Sunday 16 August 2015

FedAuth Notes for Problem Solving

Overview:  These are my notes on FedAuth relating to SharePoint 2013.
SharePoint (SP) 2013 uses Claim Based Authentication (CBA).  In this example, I am looking at SiteMinder (a CA product) as the Federation Service (this is the equivalent to ADFS (Active Directory Federation Service) as the Identity Provider (IdP)).
Basic Flow of SP CBA Authentication:
  1. SP looks for a FedAuth cookie; if  there is no FedAuth cookie for the users, it shall redirect the user to login via the IdP (AAD/SiteMinder/ADFS et al.). 
  2. The IdP returns a valid SAML token to SharePoint's STS.
  3. The STS generated a FEDAUTH cookie for the user to hold the current users session lifespan state (to keep the user log in).  The user holds the STS token not the SAML token.  The FedAuth in is a pointer to the SAML token held in the SharePoint Token Cache.
The default behaviour of SharePoint is to store the FEDAUTH cookie on the user’s disk, with a fixed expiration date. The expiration of the FEDAUTH cooking can be for a fixed time or a sliding session (if the user interacts with SP, the SP session is extended).  FedAuth can be stored on the Disk (default or in memory (not persisted between browser close downs). 

Note:  Changing where the cookie is stored affects the way the user shall login and effects Office application login such as Word.  Test thoroughly before changing)

Note:  Watch the IdP providers expiration policy vs what you set up in SP.  As an example, you could remove a user from the IdP, however, the session is still persisted and the user can still interact with SharePoint.   From MSDN "Make sure that the value of the LogonTokenCacheExpirationWindow property is always less than the SAML token lifetime; otherwise, you'll see a loop whenever a user tries to access your SharePoint web application and keeps being redirected back to the token issuer." 

Note: Closing a browser window with the FEDAuth stored to Disk does not invalidate the SharePoint session.  So the FedAuth shall persist when IE is close.  However, by keeping the session lifespan/FedAuth lifetime relatively short, the  to be relatively short (think less than an hour) your security is better.
Note: Change from FedAuth to session based sessions should taken lightly, Office products need to be thoroughly tested and generally won't work seamlessly.

Updated 11 Feb 2019: rtFA cookie
"The root Federation Authentication (rtFA) cookie is used across all of SharePoint Online and the rtFA cookie is used to authenticate the user silently without a prompt.  So when moving from OneDrive to SPO or Admin sites, the user does not get additional prompts for login.  When a user signs out of SharePoint Online, the rtFA cookie is deleted."

References:
SharePoint Authentication and Session Management
https://msdn.microsoft.com/en-us/library/hh446526.aspx
Remote Authentication for SharePoint Online (RTFA)
Why IE and Office work together in SP
Adding, removing SP claims and managing security using claims  and NB! also
Logout of SharePoint
 NB!  http://blog.robgarrett.com/2013/05/06/sharepoint-authentication-and-session-management/
Check Cookie TimeOut; set by formula:
FedAuth LifeTime = IdP endpoint SAML token lifetime Duration - STS LogonTokenCacheExpirationWindow

Update 04 Feb 2016: screenshot for clarity:


My blog post on changing from FedAuth to session based cookies.  The post also shows how to examine the cookies for Internet Explorer (IE).

Thursday 19 March 2015

Identity Providers for SharePoint

Overview:  I have worked with and evaluated a couple of Services and Federation Server products.  Here is an old pot of setting up claims, at the bottom I have some thoughts on different services/server products.
Background: SAML and WS-Federation protocols are standard Single Sign-On protocols, the following version exist:
  • SAML 1.0, SAML 1.1, SAML 2.0
  • WS-Federation
Security Assertion Markup Language (SAML) is an XML-based protocol for exchanging authentication and authorization data between security domains.
SAML enables web-based authentication scenarios including cross-domain single sign-on (SSO).  SAML is a token representing a principal that normally represents a user but can represent an app.
  
Other terms to understand:
  • Identity provider (IdP) think ADFS/Azure ACS,
  • Service provider (SP) is the SAML consumer in our context this is SharePoint but this can be an MVC app.
  • Realm
OOTB SP2010 and SP2013 support SAML1.1 not SAML2.0, you can write custom code or use a Federation Server like ADFS to convert the SAML2.0 so it will work with SP.
Identity Provider (IdP) Products:
  1. Microsoft ADFS
  2. Ping Federate
  3. ThinkTexture Identity Server
  4. CA-SiteMinder
  5. IBM Tivoli (CAM)
  6. Oracle Access Manager
  7. ComponentSpace
  8. Shibboleth
  9. RSA Federated Identity Manager
  10. Entrust GetAccess
 IdP Services:
  1. Azure Active Directory
  2. LiveId
  3. Google
  4. Facebook
  5. LinkedIn
  6. Yahoo
This list is in no way exhaustive, pls post if you feel I am missing any providers.

Monday 21 February 2011

Mapping internal users (LDAP) to the cloud

Overview: Steve Plank has a great video on "How ADFS and the Microsoft Federation Gateway work together up in the Office 365 Cloud". 

To get your internal ADFS users to authenticate in the Microsoft cloud (Azure and Office 365), you do need ADFS 2.0.  The claims based authentication that can be setup in SharePoint 2010 is how Office 365 and AZURE will authenticate AD users. 

You users will access SP2010/MS Online365/AZURE Web application using their browser.  The end application sends the browser a response redirecting them to the MS Federation Gateway (MFG)/App Fabric/STS web service (SP2010 on site editions), this in turn passes the users browser onto ADFS.

ADFS generates the user a SAML token and the are redirected to the MFG, MFG in turn generates it's own SAML token containing it's claims and the browser is redirect back to the originally requested web application.

For a user trying to access SharePoint Online from their internal network, you can see the user makes several requests to different points along the chain however the key result being the user get securely authenticated against you internal Active Directory (AD).
Steve Planks video is easier to follow than this post but it's worth understanding the process as it applies to Azure, SharePoint claims based authentication and Office 365.  This coupled with custom LDAP providers results in a consistent manner to handle authentication in the cloud using you internal LDAP directory.

Below is an animation describing the process whereby a user is authenticated on their internal network and then they use SharePoint Online (Office 365).
More Info:
http://blogs.msdn.com/b/plankytronixx/archive/2011/01/25/whiteboard-video-how-adfs-and-the-microsoft-federation-gateway-work-together-up-in-the-office-365-cloud.aspx?wa=wsignin1.0

Settingup ADFS for SharePoint Reference: