At least I think I mean ADFS?!
ok so I have created and deployed a simple asp.net web app that staff use.
It uses windows authentication. The windows account is local to the server as this server is in the DMZ.
This works fine but has become more popular that I thought and is now being used across the Organisation.
Obviously I now have an issue whereby any staff that leave the organisation will still have access to this web app. Not good! Rather than have a whole new forms based account management system I though ADFS may be the answer. This is not my area of expertise so bear with me if I go up the wrong road or use nonsense jargon. Our AD is on premise but we sync this to the MS cloud so we can use NT accounts for 365 apps and SSO for a 3rd party web based product. I would like my web app to do the same as the 3rd party web based app.
I have Googled plenty but soon get lost among the ADFS/OWIN/OAuth speak.
If I knew the exact search term to fit my scenario I could go back to my research... If someone could point me to an article that shows how to do exactly what I need without me having to do a crash course on SAML etc that would be awesome too.
Firstly, agree on on/off-boarding policy, ADFS will not fix that since ADFS authenticates against AD. Neither will Azure AD.
You can go two ways:
Install ADFS. Then you get SSO across all apps. But rather go with Azure AD.
Use Azure AD. Your users are already synched up to Azure AD for O365.
You can use OpenID Connect rather than SAML.
There are a number of samples to guide you here.
Think you want to still use windows authentication but instead of local accounts create and use domain user accounts. The DC will be able to validate accordingly. As far as staff leaving and still having access you need a policy in place which disables/deletes the user account object in the AD when they leave the company so the account no longer exists or is enabled.
Related
I have built a web-based MVC application in .Net 6.0 that has been in use for years within my company (upgraded recently to 6.0, of course). One of the functions of the app has allowed internal users to send emails and this was working through the Office 365 SMTP until recently. Our parent company introduced MFA and since then, the email function is broken and alternative methods I have implemented are only half working. Based on my research, Microsoft Graph seems to be a good way to replace this email functionality, however I'm lost on how to implement it with my current app.
The application is hosted on our own server with IIS and uses Windows Authentication. What I have not been able to find is a step-by-step guide on how to implement Microsoft Graph API with this setup. I'm completely self-taught and maintain this app on the side, rather than as my main job. All of the examples I've found aren't particularly helpful on the "here's how".
What I do know is that I need to have the app registered in Azure AD. I've spoken with our admin, and that won't be a problem once I know what I need to do. With .NET Core (.NET 6.0), MVC, Windows Authentication, hosted on an internal server with IIS:
Is it possible to implement the Microsoft Graph API? (I believe the answer is yes)
Is there a good step-by-step guide on exactly what I would need to do?
The closest thing I've found is this: https://learn.microsoft.com/en-us/samples/azure-samples/active-directory-dotnet-iwa-v2/active-directory-dotnet-iwa-v2/
Unfortunately, I'm mostly just staring at the code, not able to figure out how I can make use of most of it. I'd appreciate any guidance or recommendations.
Let's tidy up the ideas first.
You have realized windows authentication, that means you can know who is signed in now, or in other words, your sending-email funtion knows who is the sender. Then you also need a page to let users set receive and CC list, subject and email content.
Then you want to use graph api to send email. This required you to have an azure ad application which has Mail.Send permission which permission type is Application(I think using this kind of permission is a good choice in your scenario). By the way, you also need to make sure email senders has their corresponding accounts in azure ad. Because graph api need to know who is the sender, and sender is required to be a member in the tenant which the azure ad application is registered(users outside the tenant can't use the resource in the tenant, right?). For example, users' account information are stored in your local database, and your app linked to your localbase, so your app knows who is the user, but when you try to use graph api/azure ad, you also make sure azure ad know who is the user, so azure ad can authenticate and graph api can know who is the user than allow the user call api.
Normally, in our application, we try to integrate azure ad so that users in azure ad can use their azure ad accounts to sign in, then use the authentication by azure ad, they can call graph api to do some actions. In you scenario, you didn't integrate azure ad authentication, so that using client credential flow to authenticate your app to call graph api is better, so I said give "Application" permission is better. You may refer to this answer and try the sample code in it.
In the code sample, it requires you to set user id as one of the input parameter. If the user passed windows authentication, I trust you can get the user id, but you need to make sure the user id is the same in azure ad. If not, you may also need to set up a matching relationship.
I want to create a new .NET application with implemented Individual User Accounts.
Actually, there is no more possible to create it with users stored in local DB so Active Directory is necessary.
I created AD on Azure but have no clue how to fill this form.
I have a problem with all three inputs.
I have 3 question:
How to fill this form?
Is there any reason why I should implement Authentication by myself.
Is there other solution to get authentication out of the box? (like template with already implemented authentication)
To answer your first question, filling out the form, you will need to get these details from the Azure AD you setup. The Domain Name is the domain you created in Azure Ad. The Application ID is the guid you got when you registered your application in your Azure AD. The last field, Sign-up or sign-in policy, is the Azure AD policy you want to use to manage people signing up for your service as well as signing into your service.
The problem is, setting up your Azure AD is only one step out of many. What you should be learning how to do is setting up Single Sign On (SSO) using Azure AD. For that, I suggest looking at Authentication Scenarios for Azure AD, What is application access and single sign-on with Azure Active Directory? and Azure Active Directory B2C: Built-in policies. These series of articles should put you on the right path to get started with using Azure AD.
Your second question can be subjective, so I'll simply point things you will need to concern yourself with if you try to implement your own authentication. The biggest problem with doing it your self is making sure you have addressed the necessary security concerns. You will need to have your passwords stored securely which means salting and hashing them (I suggest Googling if you aren't aware of those term). You will also need to handle scenarios like password reset, forgetting user name and/or handling inactive or disabled user accounts. Many organizations and developers like using third party providers for SSO so they don't have to deal with such issues.
For your last question, yes there are. Microsoft does include a basic one with their web project templates (if you choose) and there are other providers out there such as Google or Facebook. There are many other options out there that are open source. A quick search on NuGet yielded over 2k results (https://www.nuget.org/packages?q=user+authentication).
I'm using ADFS 3.0 on Windows Server 2012 R2
I'm setting up ADFS for federation across several organizations. I've got a single ADFS instance in my org that has claim providers trusts to other ADFS instances external. The overall experience is good and functional, except that when I'm at the ADFS login page, all claim providers are listed. I need to narrow this down, because we cannot show all of them.
My first thought was to inject a javascript into the onload, and do a quick redirect, however, savvy users will still have access to the full list of providers through networking tools like Fiddler.
I'm not leaning toward adding a relying partner trust to my app for each claim provider, and using some business logic in my app to send the user to an appropriate url that will have a shorter list. This is more of a maintenance headache, though.
Any thoughts on how this should be achieved? In ADFS 2.0, you could manually edit the aspx to take care of this.
You can enable an organizational suffix on each CP trust using set-adfsclaimsprovidertrust cmdlet and the OrganizationalAccountSuffix parameter. https://technet.microsoft.com/en-us/library/dn479371.aspx has details of cmdlet. This is available in 2012 R2 AD FS onwards. See https://technet.microsoft.com/en-us/library/dn280950(v=ws.11).aspx too.
Then when users end up accessing AD FS and a HRD is required, they wont see the CP list but will be asked to enter a UPN. based on the suffix, they are redirected.
I have a .NET web application, authentication is typically done through windows authentication. Normally it's placed on a local lan and is a member of a domain so users authenticate directly to AD. However I was told that I had to figure out to authenticate to the domain when the web server is on a perimeter network. I was told that adfs is the way to go. However I'm unsure of how to implement this. I read about the web application proxys but those would have the application on the lan. A relying trust sounds like what I want but it's not clear on technet how this works and how to integrate with anything other than a sharepoint site. I was told not to use something like a rodc because they don't want to extend the domain any further, which makes sense. Any suggestions on how to authenticate to active directory through adfs with the application being on the perimeter
There is a free and well known e-book on federated authentication from the Patterns & Practices group, Claims based identity and access control
https://msdn.microsoft.com/en-us/library/ff423674.aspx
The book covers all you need to set up federated applications, write federated clients and servers and much more. When you are done with reading, come back with more specific questions.
I have a requirement to integrate an ASP.NET web application with active directory - basically they want to be able authenticate and authorize with AD.
I realise this is relatively simple, but what I want to know is how I can simulate the AD for developing and testing against. I don't have AD available to me (right now) and don't cherish the thought of setting it up even if I had hardware available to run it on.
What other options are available to me? I've seen ADAM mentioned in a couple of places but this doesn't seem to provide the federation services I need (and seems a little out dated). Would it be possible to use Azure for this? I want to keep costs (time-wise as well as money) to a minimum.
I have managed to set up an active directory environment suitable for development using a Microsoft Azure VM.
A brief summary of the steps I went through to get this working are below. Although it sounds scary setting up AD and ADFS, the windows server 2012 interface makes it incredibly easier, barring a few gotcha's I mention below - it takes a while for them to install as well.
Create a new azure windows server 2012 VM and add endpoints for http and https.
Install the AD role on the VM
Install the ADFS role on the VM
Create an ASP.NET MVC 4 app (on your dev machine) and verify it is working correctly.
Run the app through IIS (not IIS express - this just makes SSL etc easier).
Ensure the site has a https binding set up
Install the Identity and Access tool for VS2012
Right click your project to select the identity and access tool.
The path to the STS meta document will be https://<your VM url>/FederationMetadata/2007-06/FederationMetadata.xml (you may need to download this file manually if your certificates are self signed).
Back on your VM, in ADFS create a relying party trust for your application.
Run your MVC app again and you should be redirected to your VM for authentication and then back to your app again (but this time using https).
If you are using the default MVC template, in the top right corner assuming you have set up the claims correctly, you should see Hi, <user>#<domain>
The main articles that I followed to achieve this are as follows:
http://blogs.rondewit.com/post/MVC-2b-ADFS-20-Federated-Authentication.aspx
http://garymcallisteronline.blogspot.co.uk/2013/01/aspnet-mvc-4-adfs-20-and-3rd-party-sts.html
Below is a list of gotcha's that I hit (in no particular order).
When setting up the relying party trust enter the data manually and ensure you set the Relying part WS-Federation Passive protocol URL and the relying party trust identifiers correctly. The first is simply the https url that ADFS will redirect back to after authentication has completed - https://localhost for example. The second is an identifier used to identify the application that is trying to authenticate. One of the identifiers entered must match the realm attribute of the wsFederation node in your MVC 4 apps web.config.
When logging in the username should be of the form <domain>\<username>
I couldn't get Windows Authentication to work with any browser other than IE. For this set up to work with Chrome I had to change the order of the local authentication types in the web.config of the adfs/ls application so that forms authentication appeared first. To get to this, open up IIS manager on your VM, expand default web site/adfs/ls, right click ls and select explore.
At the time of writing I haven't been able to login with an AD user I created myself - I've probably just not set it up correctly. When setting this up initially, I'd suggest trying to connect with the admin user you created through the azure portal when you created the VM.
Once I finally managed to authenticate correctly AntiForgeryToken html helper started throwing an exception, talking about missing claims. Ensure that you have added a claim rule to your relying party trust, that sets either the name or name id claim. Then in Application_Start do the following: AntiForgeryConfig.UniqueClaimTypeIdentifier = ClaimTypes.Name; as explained here.
It is also worth noting that the Identity and Access tool allows you to setup authentication with Azure ACS and more noteworthy, a development STS. For my requirements, I need to be able to integrate with ADFS, but if you're just experimenting with claims based authentication, one of these may be a better option than the process that I have gone through above.
Consider ADFS and ws-federation.
Ws-federation is an enterprise sso protocol that gives you cross domain authentication/authorization in a sso manner. Adfs is a free implementation of the protocol that sits on top of the active directory. It is relatively easy to set up.
But having a client application that expects a ws-federation identity provider, you can substitute the provider with any compliant provider, your own or the identityserver which is another free implementation but can use a membership provider. The completely custom implementation on the other hand would give you a chance to set up and serve an
arbitrary identities.
The is a small learning curve for this approach but benetifs are:
cross domain sso
support for multiple browsers for free (kerberos/ntlm based ad authentication could be unsupported on some browsers)
works in an intranet and the internet
support for advanced scenarios like for example you can set up your cloud Office365 to authenticate against your local adfs
adfs 2.0 is free component dowloadable from msdn