SharePoint Integration with SiteMinder R12.52

[Anon Anon]

Hi Team,

 

We have a requirement where we need to integrate SharePoint  2013 with SiteMinder R12.52, however below are the requirements.

 

1, Internal users logging in from Internal network will go through the IWA from SharePoint, where they would be authenticated automatically, since either they use device from firm and they are within the internal network, SiteMinder should not interpret the request in this case.

2. External user logging in from external network will use different url(ex: abcportal.abc.com), here the users either the employee or external(partner/customers/contractors) should get authenticated by SiteMinder and allow them to SharePoint to access the authorized pages. SharePoint team has decided to isolate the external ips and route it to SiteMinder. But the question here is what will be the url i will provide them to route the request.

 

So my questions are:

1. Can i install SharePoint agent on the same server where we have agent/waop and servletExec installed, but as per docs, SharePoint cannot be installed on the server which has proxy server.

2. what will be url i should provide them, if i install SharePoint agent in a separate server?

3. do i have to create both application and policy domain, what is CA DLP? or either of the one is enough?

4. what would be the ideal design for this requirements?

5. If we could use Split DNS and route the request from External IP, where will i install the certificate from SiteMinder Federation?

 

Your ideas and help would be greatly appreciated, as this is my first SharePoint integration.

 

-Chris

[Rick_Burnham]

Hi Chris,

 

1.) No, per the documentation the Agent for SharePoint is a standalone proxy solution that cannot be installed on a system with another Web Server.

2.) The URL that the users would use to access SharePoint resources via the Agent for SharePoint would need to point to the Agent for SharePoint system. You can create VirtualHosts on the Agent for SharePoint system, and the URL of the Agent for SharePoint system that will be protecting the Application needs to be defined as the "Public URL" for the SharePoint application in the SharePoint Alternate Access Mapping for the application.

3.) No, per the documentation you either use the Domain Model or you use the Application Model if you are also integrating with DLP. DLP is a Content Classification Service which requires the DataMinder Content Classification Server in the environment that allows you to create access policies based on the content contained in the document being requested. Please contact your CA Account Manager for information on the CA Dataminder Content Classification Service. If you are not integrating with DLP, then you simply need to use the Domain model within SiteMinder to create your Policies.

4.) The SiteMinder Agent for SharePoint must protect the "Default Zone" of an Application using Claims Authentication, so you would need to "extend" the application to another zone within SharePoint and select Windows Authentication/Integrated Windows Authentication for the extended zone for your Internal Users.

5.) With the Agent for SharePoint integration, the Private Key Pair would need to be imported into the Policy Server's Certificate Data Store, and then the certificate (alias) would be associated with the Resource Partner that is automatically created within SiteMinder by the SharePoint Connection Wizard. The certificate would then need to be exported from the SiteMinder Certificate Data Store and copied to the SharePoint Server. The SharePoint Connection Wizard not only creates the Resource Partner in SiteMinder for the SharePoint Connection, but it also generates a ".PS1" script that needs to be modified to point to the certificate and RootCA certificate copied to the SharePoint Server, and when the script is run in the SharePoint Management Shell to create the SiteMinder Trusted Identity Provider (SPTrustedIdentitlyTokenIssuer), the certificates referenced in the modified ".PS1" script are used to create "SPTrustedRootAuthority" objects within SharePoint to allow the assertion signed by SiteMinder to be trusted.The script also associates the Signing Certificate with the SiteMInder Trusted Identity Provider.

 

- Rick Burnham

[Anon Anon]

Thank you so much for the reply Rick.

 

1, SharePoint team doesn't want to "extend" the zone, since they have multiple sites with one certificate. I find they are not comfortable extending the application.

2, we have provided another option of splitting the DNS (DNS Split), so that the external request from external ip will be routed to our federations services and follow the normal federation model, however if thats the case, do i have to still install agent for sharepoint? from what i see we are making sharepoint as SP and siteminder as idp to authenticate.

In this scenario, we will provide a certificate to the sharepoint to authorize the users right. does the sharepoint team need to install the certificate in their sharepoint server?

[Rick_Burnham]

Hi Chris,

 

If you are using SiteMinder Federation Security Services (SMFSS) coupled with ADFS for SharePoint, then no you do not need the Agent for SharePoint, and I would not be the best resource to answer your SiteMinder Federation Security Services questions; I support the SiteMinder Agent for SharePoint product. I will see if I can get someone with a SiteMinder Federation Security Services background to help answer your questions.

 

-Rick

[Anon Anon]

Hi Rick,

 

Thanks again for the reply, no we are not using ADFS, with sharepoint. But we are using AD as userstore to authenticate both external and internal users. However thank you for your help. Will wait for someone to help me out with this scenario.