I was reading about the IIS CRMAppPool and found this link:
https://community.dynamics.com/crm/b/dynamicscrmtipoftheday/archive/2014/05/13/tip-133-do-not-add-crm-application-pool-account-as-a-user
My question is, if you can´t use the CRMAppPool identity as a user, how do you push data into the CRM server without the mentioned risk when my organization has the load balancing front-end configuration (app pool identity as CRM user)?
Thanks in advance.
Related
We have a situation where we are connecting to SharePoint 2019 using the current user logged in to authenticate (so no hard-coded username/password to pass over CSOM). We do not use the SharePoint UI at all, so everything is done from Web App API to SharePoint 2019 API (via CSOM).
Our current Web Application is secured with Identity Server 4. How can we get authentication working from .NET/CSOM in the Web Application's APIs to use the current user's identity to make the call to SharePoint 2019.
Currently, SharePoint's Authentication is just set to Negotiate/Kerberos, but I have a feeling that it needs to use Identity Server as the Trust Provider (as seen here: https://www.scottbrady91.com/Identity-Server/IdentityServer-4-SharePoint-Integration-using-WS-Federation) The only issue is that this example is using the UI of SharePoint to prompt the logins, and isn't solely from API to API connects nor does it reference any examples of doing that via code.
Thanks in advance!
We have configured Okta as a trusted authentication provider to out SharePoint 2013 On-Premises environment. The user can log into Okta and access the SharePoint 'app' but when it connects them to the homepage, they are met with 'Sorry this site has not been shared with you'. It's like their account does not have access to SP, or is not being recognised. I can see in the logs that a valid SAML token is coming in, but I think we might be missing a step where that is converted to a valid Active Directory account.
In the deployment guide they talk about 'recommending' that we install the Okta People Picker plugin. I don't want to do this if we don't have to, I was under the impression we didn't need to add 'Okta' users into SharePoint as it would map the SAML claim to their Active Directory account and grant them the same access they would have if they were inside the network...
Any help would be appreciated.
First off, in order for users to be able to be looked up you'll need to definitely add the people picker plugin in. The biggest snag that the documentation doesn't accurately describe is that you'll need to import the okta cert chain to the server and establish trust in central admin for 2013 (not just 2010 only). Following all steps in the guide (including certs) got that going.
Okta-SharePoint on-prem guide: https://support.okta.com/help/articles/Knowledge_Article/Microsoft-SharePoint-On-Premises-Deployment-Guide
As for access to the site: once you get the people picker configured then you need to ensure you have migrated your user profile users from AD as the new type of claim for your identity provider. For the most part you can follow the guide below and just update the appropriate spots for Okta:
https://blogs.msdn.microsoft.com/sambetts/2014/09/03/how-to-migrate-sharepoint-users-to-adfs/
For extended troubleshooting I would recommend leveraging a ULS log viewing tool and to filter the results by the name of your claim identity provider.
I am wondering if anyone has faced a similar issue. We are working on enterprise client portal that would be sitting on the internet. We also would like to add managements/client services portal that would be sitting on the local network and would use the same core libraries. For the external clients we would like to use forms authentication and for the internal application we would like to use windows authentication. Right now we are leaning to use sql membership provider on the external site and active directory membership provider on the internal site. We are working with mvc 4 so we use claims principal throughout the app.
The questions are:
1. Is there a way to combine users so we can enforce username uniqueness using existing providers?
2. We are considering using user email as the key. Is this a security issue. Can I get user email from AD membership provider?
I have looked into simplemembership provider. I thought that I could utilize webpages_OAuthMembership table to store "LDAP" users. But there is no oauth provider for that so I would have to write our own.
On another hand it seems that simplemembership is just a temporary solution until ASPNET.Identity come out in Nov.
Do you have any suggestions?
Have you looked into Windows Identity Federation (WIF), ASP.NET Identity, MVC5?
All your cases can be implemented using above.
We have to HNSC https://division1.corp.com https://division2.corp.com on the same SPWebApplication using Claims and Forms Authentication. When logging in to https://division1.corp.com we should have access to https://division2.corp, but we get the logon dialog box again. The UserInformationList are synchronized between this HNSC. By looking at the cookie, they are different.
How shall we solve this?
SharePoint 2010 out of the box does not provide a way to share authentication between its own web applications. This is primarily because each application authenticates users independently and the cookies that it issues are marked with the HTTP Only flag. This means the cookie cannot be accessed by other applications on different DNS names (even if they are part of the same SharePoint farm).
The most common resolution to this is to set up an external federated trusted identity provider (such as ADFS) and have each of your web applications trust it. Then you can configure your federated identity provider to authenticate against your forms provider.
Here's some more detailed info about how the authentication structure in SharePoint works and how you can develop against it: http://msdn.microsoft.com/en-us/library/gg430136.aspx
is it possible to configure federated trust without using ADFS. This article "Claims-Based Single Sign-On for Microsoft SharePoint 2010" link walks you through an example of integrating two web applications into a sso environment for intranet and extranet web users. The article describes how to configure a New-SPTrustedIdentityTokenIssuer where you can add ProviderRealms to SPTrustedIdentityTokenIssuer. In our scenario we set -SignInUrl https://division.corp.com/_layouts/fba/fbalogin.aspx. But I cant find out how to configure the section federatedAuthentication.
I have a custom Windows App (needs to be windows as it runs on a users machine and interfaces with TWAIN devices) which needs to communicate to a Claims Based Authenticated site.
What is the best way to achieve this? Each user already has an account on the site which I want to use to authenticate with on the windows app.
Note: the site is actually a CRM2011 IF Deployment.
CRM 2011 setup
Cloud Hosted
Claims Based Authentication for IFD users
Windows (AD) Based Authentication for services (i.e. running on the same box) and workflows
STS setup is out of our control
Is CRM 2011 already configured to use a STS such as ADFS?
If so, you just need to add your app. to the STS as a Relying Party.
There's a white paper.
Also, this gives a good overview of configuring ADFS and WIF in general.