I would like users inside an organization to connect automatically to a site hosted on a server,
without needing to enter credentials.
the server the site is hosted on, uses a certain AD (Active Directory), with other credentials than those used in the AD of the organization and known with their windows account they login to in the office.
I heard about LDAP over SSL (LDAPS) but not certainly sure that is what I need and not sure how to implement it.
The site is written with Asp.Net Core 5.
Can anyone help me understand if it is what I need or suggest a different solution?
Thanks in advance!
Related
I've managed to setup two virtual machines in my local windows 7 laptop. Both of them are Windows server 2008 R2. One acts as Active Directory Domain controller and also as Active Directory Federation Services, and one other as the web app server. This second one is where I've set up my claims aware asp.net mvc web application and I also plan to setup ThinkTecture Identity Server later as my way to authenticate against custom username and password outside AD.
I've successfully implemented the installation and configuration needed for connecting our ASP.NET MVC apps through ADFS. They include :
Configure first server as Domain Controller and add domain account store (add user as testing -> this user belongs to Domain Users Group).
Configure first server also as active directory federation services.
configure relying party trust identifier from federation metadata generated from FedUtil.exe in second server.
Configure group claim mapping and assign Domain Users to this group.
Configure web apps server to be claims aware agent.
The one that's always troubled me is that every time I access my apps, it successfully prompts login dialog box. Once I enter My AD account and password, it always gives me the following error message : "There was a problem accessing the site. Try to browse to the site again.
If the problem persists, contact the administrator of this site and provide the reference number to identify the problem.
Reference number: c558ed55-b203-42cc-b6bd-3d66bddb96cd".
Any idea from you guys how to get this to work?? Any suggestion and ideas will be highly appreciated.
Have you looked in the event log?
Open Event Viewer > Go to Applications and Services Logs > AD FS 2.0
You'll see an list of errors which should give you some more guidance.
If you see the ADFS login screen, you can get to ADFS so I suspect it's something to do with your RP configuration.
Just to check - you are using ADFS 2.0 which you downloaded?
Overview
Our SharePoint 2010 application will be launched from a 3rd party application, let's call it HealthApp, via an embedded URL. Much of the time the user will be logged into HealthApp from a shared workstation. As a result, SharePoint will not sign in automatically using the Active Directory credentials.
Requirements
We need single sign-on.
We need to continue to use Active Directory as the STS for various reasons.
Authentication from a stand-alone browser on the user's workstation will need to work as it does now.
Authentication Info
HealthApp can pass a username and any other custom identifier information we want as URL parameters.
The username will match the users Active Directory username.
We will not have a password.
We need some way to authenticate the user based only on the username/identifier.
Possible Solutions
Is there any way to bypass the password check in Active Directory?
This would appear to be the simplest solution if possible.
Can we
extend the Active Directory provider to authenticate using a generic
user and then log into SharePoint with the username passed on the
URL?
Any other suggestions?
I would think there would have to be some way to do this but have not had much experience with claims based authentication with SharePoint.
Thanks for any insight.
Me also facing same issue for authenticating users over share point site that uses claims authentication.As per requirements my app needs to access share point data. So to authenticate
over share point server from an app we need to provide some authenticated claims with the request so that share point STS can issue an authorization ticket to access the share point site resources. after spending more than 2 days in googling i found some interested article that may help to authenticate users from client app against identity provider systems.
OAuth library
this resides between app and identity provider system. using this you get an authenticated claims that will further use to authorize over share point server with the help of Share point STS.
We have an application that uses Active Directory for its Authentication. This includes Kerberos multi-hop delegation which the application requires. It consists of a WinForms client, connecting to a set of Web Services via WCF 4.0, hosted under IIS 7.5.
Normally, this all gets installed on our Customers own hardware and integrates with their AD. But we have recently set the Web Services running on private cloud (accessible via IPSec VPN) with its own AD implementation, and where we can set-up a one-way Active Directory Trust between our AD and the customers AD then all is well, and the application works as designed.
However, we have a few customers who are running their AD on Small Business Server, and therefore it is not possible to set-up the trust.
Given the following constraints...
A major re-write of the application to not use AD/Kerberos is not a viable option.
Forcing the Customer to move off SBS to a full Windows Server AD is not a viable option.
... I am looking at ways to solve this problem that require the minimum changes to the core Application as possible.
I can see 3 options that seem immediately obvious:
Active Directory Certificate Services - Clients use a certificate issued from our AD which is linked to an AD account in our domain. But unsure of whether this would allow the Kerberos Delegation.
Active Directory Federation Services - This sounds like it also could do the job, but we have never used it before.
Active Directory Lightweight DS - If the customer was to install this and somehow link it to their AD and we set-up the trust to the LDS instance, could that work? Again, we have never used AD LDS before.
Does anybody have any experience of this situation or something similar?
Does anyone have any recommendations as to which of the 3 routes to look down first?
Does anyone have any other alternatives?
The certificate will work for authentication and delegation. You should also look at protocol transition. This will enable you to do something like a forms based auth on your site and have it transition to Kerberos on the backend.
AD LDS won't do much here. ADFS is going to require alot of rework in your app as well.
I've got a very strange problem with my SharePoint 2010 Web application.
Every users are now logged on my sites as System Account (SharePoint\system). They can access all content of all site collections whatever security is associated to their domain user account.
The ONLY change that happened is that someone changed the App Pool identity password... I still don't know who did this btw...
I've read that this might occur when the Web Application AppPool is running with the farm admin account but thats not my case.
Does anyone ever encounter this problem?? Any hint or ideas would be greatly appreciated.
Thanks,
JP
I found my problem. My web site in IIS was running under the special AppPool account so no users were asked for credentials. I switched back the settings (in basic settings of the web site) to Application user.
I don't know what happen on my environnement, many people can access this server so maybe someone did a few test on my production environnement... I'm not the one managing security so I can't do anything about it... anyway.
Thanks!
After some theoretical help on the best approach for allowing a SaaS product to authenticate users against a tenant's internal Active Directory (or other LDAP) server.
The application is hosted, but a requirement exists that tenants can delegate authentication to their existing user management provider such as AD or OpenLDAP etc. Tools such as Microsoft Online's hosted exchange support corporate AD sync.
Assuming the client doesn't want to forward port 389 to their domain controller, what is the best approach for this?
After doing some research and talking to a few system admins who would be managing this, we've settled on an two options, which should satisfy most people. I'll describe them here for those who were also interested in the outcome.
Authentication Service installed in the origanisation's DMZ
If users wish to utilise authentication with an on-premises active directory server they will be required to install an agent in their DMZ and open port 443 to it. Our service will be configured to hit this service to perform authentication.
This service will sit in the DMZ and receive authentication requests from the SaaS application. The service will attempt to bind to active directory with these credentials and return a status to indicate success or failure.
In this instance the application's forms based authentication will not change, and the user will not be aware of the authentication behind the scenes.
OpenId
Similar to the first approach, a service will be installed in the client's DMZ, and port 443 will be opened. This will be an OpenId provider.
The SaaS application will be an OpenId consumer (already is for Facebook, Twitter, Google etc login).
When a user wishes to log in, the OpenId provider will be presented, asking them to enter their user name and password. This login screen would be served from the client's DMZ. The user would never enter their username or password into the SaaS application.
In this instance, the existing forms based authentication is replaced with the OpenId authentication from the service in the client's DNZ.
A third option that we're investigating is Active Directory Federated Services, but this is proprietary to Active Directory. The other two solutions support any LDAP based authentication across the internet.
Perhaps this might help…
This vendor, Stormpath, offers a service providing: user authentication, user account management, with hookups to your customers’ on-premise directories.
What about an LDAPS connection to the customer's user directory? They can firewall this off so that only your servers have access if they're concerned about it being public. Since it's SSL it's secure end to end. All you need from them is the certificate from their issuing CA (if it's not a public one). I struggled to get this working for an internal web project in the DMZ and there's a real lack of any guides online. So I wrote one up when I'd got it working:
http://pcloadletter.co.uk/2011/06/27/active-directory-authentication-using-ldaps/
Your best bet is to implement a SAML authentication for your SaaS application, and then sign up with identity providers like Okta or OneLogin. Once that's done then you can also connect it with ADFS to provide Single Sign On for your web application through Active Directory.
I'm just doing this research myself and this is what I've came across of, will have more updates once implementation is done. Hope this gives you enough keywords to do another google search
My understanding is that there are three possible solutions:
Installing something on the domain controller to capture all user changes (additions, deletions, password changes) and send updates to the remote server. Unfortunately there's no way for the website to know the initial user passwords - only new ones once they are changed.
Provide access for the web server to connect to your domain controller via LDAP/WIF/ADFS. This would probably mean opening incoming ports in the company's firewall to allow a specific IP.
Otherwise, bypass usernames/passwords and use email-based authentication instead. Users would just have to authenticate via email once every 3-6 months for each device.
I have to begin implementing this for an upcoming project and I'm seriously leaning towards option #3 for simplicity.