I have a web application using windows authentication. I also want to authenticate non-domain users against AD. Can I have domain members can enter site directly, and non-members enter their domain username and password.
How can I do this?
It is possible to do this but you probably want to have 2 distinct web applications running accessing a similar set of application code.
Web application 1 is configured to use Windows authentication.
Web application 2 is configured to use Forms authentication. You need to have some additional code in this application which allows a user to authenticate themselves using LDAP against the active directory. This code is placed in an authentication provider if you use ASP.NET.
Assuming your using ASP.NET, you can write a custom provider that first auths against your AD, then a non AD store.
Or you can use multiple providers, ActiveDirectoryMembershipProvider and then for example SqlMembershipProvider.
Related
I have a requirement for a new MVC5 web app am working on.
I need to use active directory based authentication for the back-end,and SQL server based authentication for regular users.
in our company's local applications I use forms authentication and I integrate it with active directory using custom authorize attribute, but now i have to add SQL server authentication and make them work at the same time.
is there anyone had to solve a similar problem, and if so how did you go about it ?
I have identity server and 2 asp mvc applications.
I'm using openId Hybrid flow to authenticate. Each application has it's own client id.
Both applications are not connected and both are using different user account to log in.
Is it possible to sign in to app A without having access to app B which is the case. Currently SSO kick in when I log in to one of the apps(either A or B).
Is it possible to disable SSO ?
I assume your requirement is to perform some sort of Role check before allowing the user to access MVC APP 2. This is possible in IdentityServer3 using extensibility point called ICustomTokenRequestValidator.
For further details refer to this discussion here. Also a similar SO question here
I'm using Visual Studio 2013, .NET 4.5. and trying to find out if it's possible to authenticate against Azure Active Directory with a web app using windows authentication instead of organizational authentication? I don't need a separate sign on page or registration, so rather than send them to an azure login page I would like to just bring up the browser prompt to athenticate.
It appears that the organizational authentication option relies on the reply url from the azure login page. Windows authentication works against a windows active directory but wondering if anyone has ever successfully used it against AAD?
As long as your AAD tenant is federated with your onpremises AD and your user is accessing from within the corporate network, where Windows auth works, you can absolutely do that. You can skip the interstitial page by simply specifying in advance the domain of your tenant. See http://www.cloudidentity.com/blog/2014/11/17/skipping-the-home-realm-discovery-page-in-azure-ad/
No, Windows authentication depends on Kerberos (or NTLM), which needs an Active Directory domain to authenticate the user in. Azure Active Directory does not handle Kerberos tokens.
You can have your users authenticate against ADFS using the Kerberos protocol and federate the security token in ACS.
I have a website (azure), that has a login page for the user to insert it's username and password.
Currently, the login is using LDAP to autenticate the user.
Now the client wants to use/activate the single sign on functionality, but using their Windows Server Active Directory (they don't want to use the Azure Active Directory).
Is this possible to do? Whats the best approach?
These are the two options I know:
You can use Microsoft Active Directory Federation Services (aka ADFS). This is a component that should be installed in your customer infrastructure and talks with the AD, your website will talk WS-Federation with ADFS. Authenticating a user means basically redirecting the user to a ADFS, if the user is in the LAN and is already authenticated to AD, ADFS will login automatically, but if is outside it will prompt user credentials.
Another approach will be to use a third party authentication broker. Auth0 is an authentication broker that you can add from the azure store, you will need to create an AD "Connection", which will require to install an small MSI on your customer infrastructure. For this case it works more or less like ADFS but your application talks OAuth with Auth0 rather than Ws-Federation so in lot of cases it is easier to implement.
Disclaimer: I work for Auth0.
I am currently trying to understand the combination of Azure ACS with Claims-based Auth and the option of using a custom STS and I am only slowly getting through the (unfortunately few) info sources.
Before I spend more hours on this I would like to confirm if my plan is even possible.
I have multiple azure roles (web+worker) that are being accessed over the internet by both employees and customers. Additionally, employees access these roles and desktop apps from inside our local network.
User data comes from two sources. Our azure app has user data about customers and employees, our (local) AD only from employees.
To make the login experience as efficient (and ergonomic) as possible, when accessed via our local network, employees should be automatically authenticated (Windows Integrated Auth?) on both the desktop app (automatically because of Windows User Profile Context) and on the azure apps (hopefully w/o login page).
Customers, on the other hand, should enter their user credentials when accessing the azure app, but should not have to decide between different "Credential-sources", they should just get the username+password form.
In other words
Employee visits Azure app from local network -> Auto-login with Integrated Auth / AD data
Employee visits Azure app from internet -> Username+Password form
Customer visits Azure app from internet -> Username+Password form
While writing this question, two more came to mind:
1) Is it even possible to auto-login based on source/cookie/wizardry or would that require a manual user choice for selecting the "Credential-Source"?
2) If Azure ACS "knows" that AD account with Username X is the same as Azure App User Y, does it matter with which one logins? Can the app access the same claim-data on either login route?
Are you sure you need a custom STS? It sounds like to start you just want to enable your AD users to sign in to your azure applications using their windows credentials if they are on the domain (no password prompt). ADFS 2.0 and WIF will facilitate this. In addition, if you set up an ADFS proxy server so that when those same users browse to your app from outside of the domain they will get prompted for their domain credentials.
Now your AD users are set up, but if you want your applications to be accessible to users outside of your domain, you can federate ADFS with another organization's ADFS server, or use ACS to enable login using consumer identity providers such as Google, Yahoo, and LiveID, which are provided as built in options. If you did introduce ACS like this, you would configure your corporate ADFS server as an identity provider on your ACS instance alongside google, yahoo and what not, so that when your users browse to your site they will be prompted to select which identity provider they wish to sign in with.
Here's a fantastic whitepaper that demonstrates using ADFS to authenticate to cloud applications:
http://www.microsoft.com/download/en/details.aspx?id=13789
More detailed info about deploying ADFS (such as deploying the ADFS proxy) can be found in technet.
And for ACS, there are guides and samples on how to integrate it into azure applications, and how to add ADFS identity providers: http://msdn.com/acs
One thing that you could do is look at the user credentials when a page is requested in order to get the authentication info.
If you look at...
HttpContext.Current.User.Identity
You can get info about the user's identity. If they are on the domain you will see that they have a domain name and you could programmatically choose to direct them to a login page.
Let me also say that I've never tried to do this so I don't know if there's a built in way to do this by simply configuring something in web.config.