Welcome Serena Central users! CLICK HERE
The migration of the Serena Central community is currently underway. Be sure to read THIS MESSAGE to get your new login set up to access your account.
Anonymous_User Absent Member.
Absent Member.
1140 views

Sharepoint 2013 and federation


Hi,

I have done some federation with NAM but I have never worked with
sharepoint and/or WS-Federation/STS. So question is quite simple:
Can I federate with sharepoint 2013 without ADFS or do I have to set up
ADFS also?

I looked at Sharepoint 2013 documentation and it looks like they support
SAML 1.1 and WS-Federation. Well, documentation is not really straight
forward but it looks like ADFS would be Identity provider STS only.
Can NAM play that role (IP-STS) so I wouldn't need ADFS?

Thanks and cheers
Sebastijan


--
sebastijan
------------------------------------------------------------------------
sebastijan's Profile: https://forums.netiq.com/member.php?userid=271
View this thread: https://forums.netiq.com/showthread.php?t=51836

0 Likes
14 Replies
Anonymous_User Absent Member.
Absent Member.

Re: Sharepoint 2013 and federation


sebastijan;249200 Wrote:
> Hi,
>
> I have done some federation with NAM but I have never worked with
> sharepoint and/or WS-Federation/STS. So question is quite simple:
> Can I federate with sharepoint 2013 without ADFS or do I have to set up
> ADFS also?
>
> I looked at Sharepoint 2013 documentation and it looks like they support
> SAML 1.1 and WS-Federation. Well, documentation is not really straight
> forward but it looks like ADFS would be Identity provider STS only.
> Can NAM play that role (IP-STS) so I wouldn't need ADFS?
>
> Thanks and cheers
> Sebastijan


I am in kind of the same boat as you. At some point, we are going to
try federating some Sharepoint instances. I would really love to avoid
ADFS.

In 4 SP1, NAM supports Active WS-Fed and STS, and they specifically
mention Lync, Outlooks, and Sharepoint Online. However, nothing in the
documentation about how one might go about this with Sharepoint
:confused:


--
MatthewEhle
------------------------------------------------------------------------
MatthewEhle's Profile: https://forums.netiq.com/member.php?userid=4
View this thread: https://forums.netiq.com/showthread.php?t=51836

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Sharepoint 2013 and federation


Just to let you know, I have managed to do federation with SP2013
without ADFS. Right now I'm working on one project but I'll try to write
more about SP2013 and federation in following days. If I forget just
ping me. 🙂


--
sebastijan
------------------------------------------------------------------------
sebastijan's Profile: https://forums.netiq.com/member.php?userid=271
View this thread: https://forums.netiq.com/showthread.php?t=51836

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Sharepoint 2013 and federation

sebastijan wrote:

> Just to let you know, I have managed to do federation with SP2013
> without ADFS. Right now I'm working on one project but I'll try to write
> more about SP2013 and federation in following days. If I forget just
> ping me. 🙂


Please if you could write up your notes (or even share a rough draft) that would be great!

--
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below...
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Sharepoint 2013 and federation

sebastijan wrote:

>
> Just to let you know, I have managed to do federation with SP2013
> without ADFS. Right now I'm working on one project but I'll try to
> write more about SP2013 and federation in following days. If I forget
> just ping me. 🙂


Please share them. Currently federating with SP seems to be a bit of a
dark art to most people.

--
Cheers,
Edward
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Sharepoint 2013 and federation


Hi,

let me try to shed some light upon this topic.
First of all I'm not some kind of SharePoint expert. Not even close. In
fact federating NAM with SP was my first contact with SharePoint. Also
there are probably numerous ways to achieve SP-NAM federation, probably
most of them better, so use that post only as general guide, not step by
step instructions on how to do federation.

My goal was to use NAM for user authentication when accessing SP via web
browser. And there was a little wish 🙂 that NAM could also handle
authentication when using thick client, like when Word or Excel access
file on SharePoint server.

First of all I had to understand how SharePoint handles user
authentication. I put some questions around and got very interesting
answer:

> SharePoint doesn't handle authentication on its own. In the SAML case,
> SharePoint delegates authentication to one (or many) trusted identity
> providers (IdP) and that identity provider must be able to issue SAML
> 1.1 tokens. It just so happens that ADFS is one of those identity
> providers and Microsoft obviously wants you to use it. But you could
> also use Windows Azure Access Control Services or another custom IdP
> such as https://socialconnekt.codeplex.com.


Another interesting thing was answer to my question about user
authentication in Office programs:
> When opening a SharePoint document in Office, if Office doesn't have a
> valid cookie coming from one of the IdPs SharePoint trusts, the Office
> program will open the SharePoint Sign In Selector page in a pop-up
> window (or open the custom Sign In page configure for that web
> application, if any).
> Once the user has selected the appropriate authentication method, the
> pop-up window will open the actual sign in page of the selected
> authentication provider (for instance, the ADFS sign in page) and after
> the user successfully signs in, the Office program eventually opens the
> document.


That made me search a little more and I found very interesting article
about cookies and Office.
http://tinyurl.com/muokzcs
As it turned out, Office uses same "cookie jar" as Internet Explorer. So
if user authenticates in IE he can also access SharePoint files in
Office.

Enough about SharePoint authentications, let's go to federation with
NAM.

I read a lot of stuff, one of most promising links were
http://tinyurl.com/pjkovr8 and http://tinyurl.com/poph5o2.
First one talks about integrating SP with Thinktecture IdentityServer 2
without ADFS and second one about integrating SP and Shibboleth but with
ADFS.

At the end I decided that I'll do federation on SharePoint side like it
is federating with ADFS and on NAM point as any other WS-Federation
service provider. User will be identified using mail and NAM roles will
be used for authorization at SP side. I could also use other attribute
for authorization but I already have roles for defining user access
rights to other web applications.

Before we begin, your SharePoint should have SSL enabled. For
information how to do that you can use this guide:
http://tinyurl.com/ka4un5u
I have done similar, except I used certificate issued by my eDirectory
CA. At the end you should export public key of SharePoint SSL
certificate to file since we will need that when configuring Service
Provider in NAM . Lets call that file "SharePoint signing certificate"
(for future reference).

I'll continue in next post with NAM configuration.


--
sebastijan
------------------------------------------------------------------------
sebastijan's Profile: https://forums.netiq.com/member.php?userid=271
View this thread: https://forums.netiq.com/showthread.php?t=51836

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Sharepoint 2013 and federation

sebastijan wrote:

>
> Hi,
>
> let me try to shed some light upon this topic.
> First of all I'm not some kind of SharePoint expert. Not even close.


You can spell it, you're an expert! 😉

--
Cheers,
Edward
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Sharepoint 2013 and federation


This is part three of my notes about federating SharePoint 2013 and NAM.
I first part I talked about authenticating to SharePoint in general, in
second part about configuring NAM. In this part I'll talk about basic
SharePoint configuration. Please keep in mind that this was my first
encounter with SharePoint so probably most of described tasks could be
done in different and much better ways.

Before we begin we will need public key of NAM signing certificate. Go
to "Identity Servers"->[Identity Server Cluester]->"Edit". Then choose
"Security" under "General" tab and click on "Signing" keystore. Correct
certificate is the one with alias "signing". Click on it and export
public certificate in DER format. Let's call that file "NAM signing
certificate".

Most of SharePoint configuration is done use PowerShell. So fire it up
and first add trusted certificate:

Code:
--------------------
$cert=New-Object System.Security.Cryptography.X509Certificates.X509Certificate2("C:\Users\Administrator\Downloads\NAM signing certificate.der")
New-SPTrustedRootAuthority -Name "NAM signing certificate" -Certificate $cert
--------------------

As you have probably guessed "C:\Users\Administrator\Downloads\NAM
signing certificate.der" is our exported "NAM signing certificate".

Now define some properties:

Code:
--------------------
$realm="urn:identity:sharepoint"
$signinurl = "https://idp.mysite.com/nidp/wsfed/ep"
--------------------

The $realm must be the same as "Provider ID" when configuring
WS-Federation Service Provider in NAM console.
The $signinurl is NAM Identity Server Base URL with "/wsfed/ep"
appended.

Next up is to create some claims mappings (like "Attribute Set" in NAM)
and the trusted identity token issuer in SharePoint:

Code:
--------------------
$email=New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailAddress" -IncomingClaimTypeDisplayName "emailAddress" -SameAsIncoming
$role=New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "role" -SameAsIncoming
$x=New-SPTrustedIdentityTokenIssuer -Name "<token issuer name>" -Description "<token issuer description>" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $email,$role -SignInUrl $signinurl -IdentifierClaim $email.InputClaimType
--------------------

Again, be careful with IncomingClaimType URLs since they are different
for emailAddress and role (remember configuring Attribute set and Remote
namespace in NAM?).

Once this is done all we need to do is update our Web Application to use
this new identity provider. This can be done using PowerShell but I have
done it in the UI in Central Administration.
Fire up SharePoint Central Administration and choose
"Security"->"Specify authentication providers". From there choose your
web application and your zone. Somewhere in the middle of the page
you'll see "Trusted Identity provider" and beneath name of your token
issuer. Check box in front of both ("Trusted Identity provider" and your
token issuer name) and click "Save".

After that authentication works but authenticated users are not members
of any SharePoint group so they do not have any access rights. If that
is enough you can stop reading and start testing. For all others let me
show you how you can add users with specific NAM role to SharePoint
group.

For this example we will add users with role "genlan" to SharePoint
group "Local Team Site Members". Let's define some properties:

Code:
--------------------
$web = Get-SPWeb "<sharepoint application URL>"
$group = $web.SiteGroups["Local Team Site Members"]
$sts = Get-SPTrustedIdentityTokenIssuer "<token issuer name>"
--------------------

The $web points to SharePoint application. You can look up URL in
Central Administration under "Web Application"->"Manage web
applications"
The $sts points to trusted identity token issuer we created few steps
before.

Now create virtual user which will describe all users with role (or
Claim in SharePoint world) "genlan". At the end we'll add that virtual
user to group "Local Team Site Members":

Code:
--------------------
$claimPrincipal = New-SPClaimsPrincipal -ClaimValue "genlan" -ClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -TrustedIdentityTokenIssuer $sts
$newUser = New-SPUser -UserAlias $claimPrincipal.ToEncodedString() -Web $web
$group.AddUser($newUser)
--------------------


That's it, time for testing. Open web browser and go to SharePoint web
site. You should be presented with SharePoint login selector page with
two options: "Windows Authentication" and our federated login option.
Select federated login and this will take you to NAM login page.
After successful NAM login you will have access to application if you
have correct roles (you'll need correct role to become member of
SharePoint "Local Team Site Members" group).

That is for federation. In next post you can maybe find some useful tips
and see where I have stopped. Maybe somebody else can give some more
thoughts about SharePoint.


--
sebastijan
------------------------------------------------------------------------
sebastijan's Profile: https://forums.netiq.com/member.php?userid=271
View this thread: https://forums.netiq.com/showthread.php?t=51836

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Sharepoint 2013 and federation


Ok, that was appended to wrong message... 😮


--
sebastijan
------------------------------------------------------------------------
sebastijan's Profile: https://forums.netiq.com/member.php?userid=271
View this thread: https://forums.netiq.com/showthread.php?t=51836

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Sharepoint 2013 and federation


This is part two of my notes about federating SharePoint 2013 and NAM. I
first part I talked about authenticating to SharePoint in general, in
this part I'll talk about configuring NAM.

So let's go to NAM side. I would presume that you have IdP set up and
that authentication using at least one contract is working.

First of all we should create Attribute set with two attributes, mail
and roles.
Go to "Identity Servers" -> "Shared Settings", choose "New" under
"Attribute Sets" and pick your name. For template choose "<None>".
Click "Next" and in Step 2 of 2 add required attributes:
- Click "New", for "Local attribute" choose "LDAP attribute mail", for
"Remote attribute" type in "emailAddress" (without quotes) and for
"Remote namespace"
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/" (again without
quotes). Click "Ok"
- Click "New", for "Local attribute" choose "All Roles", for "Remote
attribute" type in "role" (without quotes) and for "Remote namespace"
"http://schemas.microsoft.com/ws/2008/06/identity/claims/" (again
without quotes). Click "Ok"
Click "Finish"

At the end it should look something like that:

Code:
--------------------
Ldap Attribute:mail [LDAP Attribute Profile] <--> emailAddress [http://schemas.xmlsoap.org/ws/2005/05/identity/claims/]
All Roles <--> role [http://schemas.microsoft.com/ws/2008/06/identity/claims/]
--------------------


Please be very careful about "Remote namespace" since role is defined in
different namespace than emailAddress attribute. In beginning I have
missed that and it took me quite some time to find out why user
authenticated but did not have access to any SharePoint application.

Now let's create WS-Federation Service provider
Go to "Identity Servers"->[Identity Server Cluester]->"Edit" and check
that you have enabled "WS Federation" under "Enabled Protocols". I think
you need also other protocols. To be sure you can enable all protocols
and then when everything works disable those that are not needed.
Next choose "WS Federation" tab and then "New"->"Service Provider". For
"Source" leave "Manual Entry" and add your favorite name.
For "Provider ID" enter unique identification for SharePoint (e.g.
"urn:identity:sharepoint"). Please note that settings since we'll need
it when configuring SharePoint 2013. Also be aware that this must be in
URI format.
For "Service provider" certificate browse to "SharePoint signing
certificate" file which you exported when configuring SSL for
SharePoint.
Click "Next" and confirm signing certificate with "Finish".

Open newly created service provider and go to "Attributes" tab. Choose
"Attribute set" you created previously and add both attributes ("LDAP
Attribute: mail" and "All roles") to left side.
Next go to "Authentication Response" tab, for "Name Identifier Format"
choose "E-mail" and for Value "LDAP Attribute: mail".

Go to "Metadata" tab and choose "Edit" button. For "Single-on URL" enter
your SharePoint site with "/_trust/" appended, like
"https://sharepoint.mysite.com/_trust/"

That's all for NAM side, only thing left is to apply settings to server
(of course using "Update All" link) 🙂

I next post I'll discuss SharePoint side (except for SSL configuration
which you already should have done 🙂 )


--
sebastijan
------------------------------------------------------------------------
sebastijan's Profile: https://forums.netiq.com/member.php?userid=271
View this thread: https://forums.netiq.com/showthread.php?t=51836

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Sharepoint 2013 and federation


This is last part of my notes about federating SharePoint 2013 and NAM.

First of all, if you do not know how to set up test SharePoint (like me)
this site could help:
http://tinyurl.com/q3kjn5q
You get configured virtual machine with SharePoint 2013 and Windows
2012. All you have to do is to activate all licenses.

I have also tested access to files from SharePoint site with thick
applications (Word and Excel). SSO works like charm and if you are
authenticated to web site, file will open in Office application without
any prompt. But you should be aware of following limitations:
- You have to use Internet Explorer (IE shares cookies with Office
applications)
- SharePoint web address should be added to local intranet in Internet
Explorer

I was pretty amazed when I tried to open file in Office application
after I have logged out of SharePoint and closed Internet Explorer. Word
showed me SharePoint login selector page and after choosing my Identity
server it opened NAM login page. So I have authenticated with one-time
password inside Word application. Pretty amazing!

There is also one thing called multiple SharePoint Apps. As far as I
have found out different SharePoint apps use different DNS host names.
That also means different Sing-on URLs for federation. I have not tested
that but looking at different web pages federating SP Apps with NAM
should be similar to federating them with ADFS 2.0. That means you
should set up separate WS Federation service providers for each
SharePoint App (I've heard that to simplify that process ADFS 3.0
supports wildcard URLs for SharePoint endpoints).

I have also put SharePoint behind Access Gateway (domain based
multihoming) but without all rewriters and non-redirected logins. I
thought, if we authenticate using federation I will not need to perform
SSO using identity injection. And it worked. The only problem I had was
when I put DNS name of SharePoint Access Gateway resource to local
intranet zone in Internet Explorer. After that IE went to endless loop
and eventually crashed. When I removed DNS name from local intranet
everything worked again but as you suspected I could not perform SSO to
Office applications (since site was not in local intranet 🙂 ). I didn't
have time to troubleshoot that so I cannot tell you what went wrong.

At the end I would also like to thank David Lindgren from Altran Sweden
for giving me a lot of information regarding SharePoint and
authentication. Without his help I would definitely not come so far so
fast.

And finally I hope those notes will help somebody out there but please,
use them as guidelines not step-by-step instructions. 🙂

Regs
Sebastijan


--
sebastijan
------------------------------------------------------------------------
sebastijan's Profile: https://forums.netiq.com/member.php?userid=271
View this thread: https://forums.netiq.com/showthread.php?t=51836

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Sharepoint 2013 and federation

sebastijan wrote:

>
> I have also put SharePoint behind Access Gateway (domain based
> multihoming) but without all rewriters and non-redirected logins. I
> thought, if we authenticate using federation I will not need to perform
> SSO using identity injection. And it worked. The only problem I had was
> when I put DNS name of SharePoint Access Gateway resource to local
> intranet zone in Internet Explorer. After that IE went to endless loop
> and eventually crashed. When I removed DNS name from local intranet
> everything worked again but as you suspected I could not perform SSO to
> Office applications (since site was not in local intranet 🙂 ). I didn't
> have time to troubleshoot that so I cannot tell you what went wrong.


This is something we are interested in, to avoid the need to use identity injection at all.

> And finally I hope those notes will help somebody out there but please,
> use them as guidelines not step-by-step instructions. 🙂


We can possibly reformat this as an "article" on the forums if you are OK with that. Or do you have plans to publish this as a cool solution?
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Sharepoint 2013 and federation


> This is something we are interested in, to avoid the need to use
> identity injection at all.


If you do federation you don't need identity injection. So client talks
to sharepoint directly but authenticates on NAM IdP. But I also wanted
to hide sharepoint behind AG. And there I got that problem.

> We can possibly reformat this as an "article" on the forums if you are
> OK with that. Or do you have plans to publish this as a cool solution?

Yes, I'm OK. These are only notes, but for cool solution I think I would
need to do more. And unfortunately right now I don't have time left for
that...


--
sebastijan
------------------------------------------------------------------------
sebastijan's Profile: https://forums.netiq.com/member.php?userid=271
View this thread: https://forums.netiq.com/showthread.php?t=51836

0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Sharepoint 2013 and federation

sebastijan wrote:

> > This is something we are interested in, to avoid the need to use
> > identity injection at all.

>
> If you do federation you don't need identity injection. So client talks
> to sharepoint directly but authenticates on NAM IdP. But I also wanted
> to hide sharepoint behind AG. And there I got that problem.


We want to hide sharepoint behind AG (well we already have that part setup, but with identity injection)
So you don't need Kerberos Constrained Delegation at all when fronting with AG?
0 Likes
Anonymous_User Absent Member.
Absent Member.

Re: Sharepoint 2013 and federation


alexmchugh;249691 Wrote:
> sebastijan wrote:
>
> > > This is something we are interested in, to avoid the need to use
> > > identity injection at all.

> >
> > If you do federation you don't need identity injection. So client

> talks
> > to sharepoint directly but authenticates on NAM IdP. But I also

> wanted
> > to hide sharepoint behind AG. And there I got that problem.

>
> We want to hide sharepoint behind AG (well we already have that part
> setup, but with identity injection)
> So you don't need Kerberos Constrained Delegation at all when fronting
> with AG?


No, if you are using SAML federation for authentication. If that is the
case authentication on sharepoint is not done using kerberos. SharePoint
does not perform ANY authentication but just trusts NAM IdP.


--
sebastijan
------------------------------------------------------------------------
sebastijan's Profile: https://forums.netiq.com/member.php?userid=271
View this thread: https://forums.netiq.com/showthread.php?t=51836

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.