How to configure windows authentication for multiple or cross domains in IIS. site type: Intranet - asp.net-core

I have an Asp.net website for domain A users with Integrated Windows Authentication.
Now users from domain B need to access the website.
But Domain B users receive a pop-up window to input the authenticated information when they access the website
My question is:
How to configure the IIS or Windows Server to allow Domain B users to access the website without the pop-up windows for authentication, just like the users from Domain A.

There are two requirements:
Domain A needs to trust Domain B, and
On the users' computers, the website needs to be added to the Trusted Sites in the Windows Internet Options. This tells Chrome and Edge that they can automatically send the credentials of the logged in user. Firefox can do it too, but has its own setting for it.

Related

ADFS, Web Application Proxy, application authentication, split DNS

We have internet web applications for our company with which we want to authenticate employees.
We setup ADFS 2016 and and this works internally on the intranet and now we setup Web Application Proxy (WAP) to authenticate the employees externally.
We have a DNS A record on the internet for the WAP server.
When the client tries to access a web app, they get the login page as expected. When the button is clicked for employees (this is the normal MVC template with Identity 2), the client gets redirected to the ADFS url which is not resolvable since there is no DNS record.
I read where we are supposed to use split DNS and I think that means we are supposed to create a public DNS record for the ADFS server. If we do that, what is the purpose of the WAP?
Wap is an adfs proxy too. Externally you access adfs at the wap. Your adfs external DNS should point to wap IP address.

Always error authenticating through ADFS 2.0

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?

User login required accessing SharePoint 2010 inside network with SSL

we have a sharepoint 2010 site and are using the same url to access it from inside and outside the network.
our issue is that we don't want users inside our network to get asked for credentials when accessing the site.
if, for example, the url we wanted to use was https://sp.domain.com, how would we set this up?
You can do this via Alternate Access mappings. Have two zones for your sharepoint site: Intranet and Extranet. In AAM settings:
Intranet : http://sp.domain.com
Extranet: http://extranet.domain.com
You did not specify which authentication scheme if you are using for outside network. If its forms authentication, you can set Windows for 1 and Forms authentication for 2.
However, if its AD only for both, you will have to have sp.domain.com configured as Intranet Url and extranet.domain.com as Internet Url in each of client computer. This can be done using group policy.
Your proxy server will have to do the work of transferring the sp.domain.com from external network to extranet.domain.com internally.
Good to read:
http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=804

AD Single Sign On (SSO), browsers and networks

I'm trying to determine if SSO is what I want to use in my scenario. All of our users are in an AD. I have some web-based services that authenticate via the AD (currently they ask the user for a login when they visit the sites). Key points:
All users have a windows laptops joined to the AD.
Sometimes they access these websites on the LAN (AD server accessible), sometimes via the internet (AD server inaccessible).
Some users may want to access these websites through a non-AD computer (e.g. tablet, phone, home computer)
Users use a range of different browsers.
The websites are mostly running through apache on linux servers
Does AD-based SSO work:
if the client machine cannot contact the AD server directly? e.g. the laptop has logged in using cached credentials?
if the user is using a browser other than IE?
Is it possible to have fallback auth mechanisms in place? e.g. if SSO is not possible, then fall back to http auth or cookie auth?
Cheers,
Victor
Yes, if cached credentials are used, when browser requests a Kerberos service ticket, the cached credentials are used by Windows to get a TGT for the user and then the service ticket is requested. This is transparent to the user, so they get same experience as if they were in office, connected to the LAN, and not using cached credentials.
Some other browsers support the Negotiate protocol, not just IE. I am aware that Firefox does, and I think Safari does also.
You might get more flexibility through ADFS which is a Windows component that allows you to use claims based authentication.
The intra/extranet sceanrios are simpler, the interop story is quite good. (Since your web sites are non Microsoft ones).
Tons of documentation in TechNet

SP2010 mixed authentication, windows and forms, both against AD

I want to have a mixed mode SharePoint 2010 install where intranet users are authenticated via Windows Authentication, and extranet users are authenticated via forms authentication.
There is an existing solution here, http://www.orbitone.com/en/blog/archive/2010/06/23/sharepoint-2010-mixed-authentication-automatic-login.aspx, but I have one unusual difference. In most cases, the Windows authentication goes against an AD server and the forms authentication goes against an ASP.Net membership database. In my case, they're both going against AD servers. The users who use forms authentication are stored on an extranet AD server, and the users who use Windows authentication are stored on an intranet AD server. The extranet AD server has pass through authenciation set up with the intranet AD server, so SharePoint is always directly connected to the extranet AD server.
Is there a better approach to automatic mixed mode authentication in this case?
You are already doing things correctly. When you have internal users on an external farm, SharePoint will look for an available AD server and send the user in question to AD for verification. With the one way trust, AD knows to check the trusted domain for the user in question if it does not exist in its own domain. The whole point of the trust to to avoid calls through the network to your internal domain directly. So technically the users are being authenticated to the domains as you described. If its not working, I would bet your trust is not correctly configured.