SharePoint Authentication in a Cloudy Cloud World

SharePoint if you remember is a Microsoft technology. As such, Microsoft authentication usually works relatively well together. With the move to “cloud”, the ever increasing addition of further technologies ensures the thought of… how do I integrate with my “stuff”?

Let’s review a few things first;

Classic vs. Claims Authentication

If you are still the classic world, first, sorry, second, get out. Claims is the way of the new world. You can take an claim and use that in many places like SharePoint, Office 365 or even external services like ServiceNow, SalesForce and Facebook.

SharePoint Authentication

  • Windows Integrated Authentication
    • NTLM: Old school and hacked
    • Kerberos: Setup is a pain, works well and is accepted versus NTLM
  • Forms (This isn’t windows or an “identity” per claims, no thanks)
  • Identity Provider
    • ADFS: ADFS integrates fully with SharePoint and Office 365, great option for internal and external integration. Works similarly to Ping and SiteMinder.
    • Azure AD: Authenticates to Azure AD using an ACS. Great option for a SharePoint Hybrid auth model.
    • PingIdentity: No true hybrid support… Non-Microsoft product.
    • SiteMinder: No true hybrid support… Non-Microsoft product.

While all of these options are great, my suggestion is to pick one and stick with it, no matter what it is. Base your decision on supportable SharePoint applications like UPS, importing users from a single source and switching later is a pain. And as a good course of action, stick with Microsoft products for support in the future.

Gotta love SharePoint…

 

Advertisements

SharePoint Hybrid Search

A recent project prompted I get up to speed on the whole “cloud thing” happening everywhere. And the cloud thing turned out to be SharePoint Hybrid, search specifically with a trickle of MMS and a dash of UPS. However let’s focus on search for now.

While I will cover authentication for search specifically for this later (link), let’s get to the meat and potatoes of search hybrid;

There are essentially 4 options for Hybrid search if not more… I know, Microsoft says there are 3, I am adding a 4th and would add more but for my sanity let’s stick with 4.

Option 1 – Two Way

  • Index exists in both SharePoint Online and on-premises (Same search results no matter search center)
  • Single Sign On to either (if same domain)
  • Supports BCS and Duet (If you care about this?)
  • Requires infrastructure, WAP, F5 or NetScaler (2016 only)
  • SharePoint becomes public endpoint (Access from internet)
  • Windows Integrated Authentication only
  • SSL Certs required here

Option 2 – One-Way, Inbound

  • Index exists in both SharePoint Online and on-premises (Same search results no matter search center)
  • Search index within SharePoint online that contains SharePoint Online and On-Premises index
  • SharePoint on-premises index can not see SharePoint online content
  • Single Sign On to either (if same domain)
  • Supports BCS and Duet (If you care about this?)
  • Requires infrastructure, WAP, F5 or NetScaler (2016 only)
  • SharePoint becomes public endpoint (Access from internet)
  • Windows Integrated Authentication only
  • SSL Certs required

Option 3 – One-Way, Outbound

  • Index exists in both SharePoint Online and on-premises (Same search results no matter search center)
  • Search index within SharePoint online that contains SharePoint Online and On-Premises index
  • Search index within SharePoint on-premises that contains SharePoint Online and On-Premises index
  • SharePoint online index can not see SharePoint on-premises content
  • Single Sign On to either (if same domain)
  • Supports BCS and Duet (If you care about this?)
  • Requires infrastructure, WAP, F5 or NetScaler (2016 only)
  • SharePoint becomes public endpoint (Access from internet)
  • Windows Integrated Authentication only
  • SSL Certs required

Option 4 – Azure Application Proxy

  • Index exists in both SharePoint Online and on-premises (Same search results no matter search center)
  • Single Sign On to either (if same domain)
  • Supports BCS and Duet (If you care about this?)
  • Requires infrastructure, WAP, F5 or NetScaler (2016 only)
  • SharePoint becomes public endpoint (Access from internet)
  • Windows Integrated Authentication only
  • SSL Certs required here
  • Yes, I literally cross off everything here.. let’s talk about the tech first then come back to why it’s good…

Azure Application Proxy is a new kind of proxy server that is more tied into Office 365 and Azure AD. The service works with Azure AD, SharePoint (Or any other technology that is URL based) and App Proxy Connectors. The reason more org’s will be selecting this option is due to conditional access and the ability to publish specific applications. For instance, let’s say you want to only choose a single on-premises SharePoint site instead of an entire web app, you can do that. The auth schema confirms you should have access (Azure AD) and the connectors talk between to securely allow a user through. It’s all technical and cool stuff.

Note this is NOT truly SharePoint hybrid, indexes aren’t shared here by default and a mix of SharePoint hybrid and Azure App Proxy is still needed.

azureappproxxy

The selection…..

While no option is the best option in this situation, every project requires a different set of requirements which in turn define business project definitions.

The following are examples of what you may choose as an organization;

Two-Way: Org’s that are focusing their users online first and are still migrating or naturally moving content to online. This only makes sense if both cloud and local play a key part in an org’s daily life.

Inbound: Org’s that are 90% online and looking to disconnect from their on-premises environment. Usually a selection during a divestiture.

Outbound: Highly secure environments or primary on-premises environments. Serving some users (sales, remote) with online services.

Azure App Proxy: Org’s tied into the cloud move, Azure AD, MDM, RMS, SPOnline… you can control the who, what, where here. While this isn’t a fully integrated solution such as SharePoint Hybrid options, it still gives more granular control on access which org’s are now wanting with the move to online.

 

The Move….

I know this site has never been about one thing or commonly used by many. The most this blog has reached was a few users on a PFSense / Watchguard build. I hope and expect that soon with my move to a new employer, this will show promise and technology that many of you want to experience. Let’s get excited together about the “cloud” and what that means!

UniFi Access Point.. Go Home

I have a UniFi AP’s at home, two to be exact. It’s likely overkill, however I am in “IT” and I have to do everything overboard at home. Plus my plaster walls inside my house are terrible for wireless connectivity. I hard wire what I can, the remaining such as phones and tablets have no choice.

I will be forthright, I really like the system and it’s potential, it has some awesome features and some software bugs I have run into time to time. Hence the post…

I new router at home meant I was changing my IP scheme, relatively easy task once AD/DNS was flipped over. The problem I ran into was once the scheme changed the AP’s lost connectivity with the controller and POW! Wireless Down!

No worries, I thought, reboot, get DHCP, and they are back… No
No worries, I thought, reset to factory defaults, and they are back… No
No worries, … Damn these things were not coming back…

Aside from the factory resets using UniFi Discover to finding a small enough paper clip for resets, no dice. I ended up using SSH and the UniFi default admin UN/PS to access the AP’s. Executing info gives me..

Status: Server Reject (http://1.1.1.1:8080/inform)

 

In troubleshooting I found that the controller was rejecting the AP’s. To fix, do the following in order.

  • Reset (each) AP to factory defaults
  • Remove (each) from the device section of the controller software/site
  • Run “set-inform http://1.1.1.1:8080/inform” on one at a time
  • Within the device section of the controller, select adopt on the AP you ran the command on
  • Wait…
  • Magic

I found a few other posts on the issue, ranging from the obscure to strange. Mine was relatively simple and avoidable. Lesson learned, have putty handy at all times.

AP Firmware: 3.7.39.6089

https://community.ubnt.com/t5/UniFi-Wireless/Adoption-and-Server-Reject/td-p/565829

https://community.ubnt.com/t5/UniFi-Wireless/Troubleshoot-Server-Reject-Error/td-p/888804

https://community.ubnt.com/t5/UniFi-Wireless/UAP-set-inform-Decrypt-error-or-Server-Reject/td-p/1568794

https://community.ubnt.com/t5/UniFi-Wireless/AP-s-can-t-discover-controller/td-p/588425

SharePoint 2013, InfoPath and External Data Connections

I will be brief today, busy day, however I wanted to get this one out there.

Here is the list…

Broken Infopath Form (You do not have permission to access a database that contains data required for this form the function correctly) – Check!
External Data Connection, SQL – Check!
SharePoint 2013 – Check!
Data Connection Library Created – Check!
Secure Store Service Application Setup – Check!

I have run into this quite a few times. SharePoint 2013, Web Applications have kerberos enabled and the form breaks. This usually doesn’t happen “just because” unless you have a residual form that someone found recently… Either way, it’s broken.

Find the UDCX file in the data connection library of the site the form resides in. Generally under site contents. Make a copy of it and edit, notepad works.

Here is the change that is needed.

Before. Uncomment and set the Application ID.

</udc:UpdateCommand>
<!–udc:Authentication><udc:SSO AppId=” CredentialType=” /></udc:Authentication–>
</udc:ConnectionInfo>

After. Enter in the App ID and Cred Type.

</udc:UpdateCommand>
<udc:Authentication><udc:SSO AppId=’InfoPathForms‘ CredentialType=’NTLM‘ /></udc:Authentication>
</udc:ConnectionInfo>

This has fixed it most of the time.

 

 

SharePoint: The INSERT statement conflicted with the FOREIGN KEY SAME TABLE constraint “FK_Objects_Objects”. The conflict occurred in database “SP_Config”, table “dbo.Objects”, column ‘Id’

SharePoint issues… meh

I was provided a standard license for a SharePoint farm in lieu of needing enterprise for Access and Excel services. After the farm build, I attempted to make this right…

I attempted to convert the license, however this option was not available.

sharepoint-the-insert-statement-conflicted-with-the-foreign-key-same-table-constraint-fk_objects_objects-the-conflict-occurred-in-database-sp_config-table-dbo-objects-column-id-a

Attempting to Enable Enterprise Features, the timer job runs which eventually fails to this..

Unknown SQL Exception 547 occurred. Additional error information from SQL Server is included below.

The INSERT statement conflicted with the FOREIGN KEY SAME TABLE constraint “FK_Objects_Objects”. The conflict occurred in database “SP_Config”, table “dbo.Objects”, column ‘Id’.
Table ‘LastUpdate’. Scan count 0, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table ‘Objects’. Scan count 0, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table ‘Classes’. Scan count 0, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
Table ‘Objects’. Scan count 0, logical reads 2, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
The statement has been terminated.

While I found a few posts to fix this, either manipulating the webpage by enabling the disabled functions on the convert license type page or of course the always, not recommended, manual update to the database.

In the end, since this was production, I opted for dropping the attached servers from the farm, deleting the necessary databases (it’s new, so no need to save most), and creating another farm.

After getting central admin online, I now see my farm license is all ok and I can continue on. A more official method would be to uninstall/reinstall the SharePoint bits to properly assign the license, however considering the farm was showing me the correct license and there isn’t any higher to go, I am good with this.

sharepoint-the-insert-statement-conflicted-with-the-foreign-key-same-table-constraint-fk_objects_objects-the-conflict-occurred-in-database-sp_config-table-dbo-objects-column-id-b

 

SharePoint 2013: Error: ID3204: WS-Federation SignIn request must specify a ‘wtrealm’ or ‘wreply’

As you may know, I work with Microsoft products, SharePoint specifically lately. I ran into an issue with the setup of utilizing ADFS as a claim token provider for authentication on a specific URL.

The issue was…

Error: ID3204: WS-Federation SignIn request must specify a ‘wtrealm’ or ‘wreply’

There was more to this with custom errrors on. I like it when I get the full spiel from .NET.

While I care very much for wreply in my situation, I didn’t get initially what was broken… the setup of a token issuer is quite simple, especially ADFS, it’s less fuss and a Microsoft product. Plus my scripts usually don’t fail me much.

After a quick working environment comparison and running a few powershell scripts, I saw that my realm providers did not have the URN attached.

Key                                        Value
—-                                      —–
https://URL1/
https://URL2/
https://URL3/
https://URL4/
https://URL5/
https://URL6/
https://URL7/

Bah Humbug…

A quick clear, of the values.

$ap = Get-SPTrustedIdentityTokenIssuer
$ap.ProviderRealms.Clear()
$ap.Update()

And re-run my script… and voila…

Key                                        Value
—-                                      —–
https://URL1/                     urn:fancy1:fancy1
https://URL2/                     urn:fancy1:fancy1
https://URL3/                     urn:fancy1:fancy1
https://URL4/                     urn:fancy1:fancy1
https://URL5/                     urn:fancy1:fancy1
https://URL6/                     urn:fancy1:fancy1
https://URL7/                    urn:fancy1:fancy1

The urn:fancy1:fancy1 provider realm matches the ADFS relying party I had setup before. Now my site works…