We have a Active Directory(AD) environment where we use ADFS to secure our websites.
Is there a way to automatically create a user account for a website within ADFS if the current account has passed authentication from the AD machine.
So someone would in effect sign in with their domain account which would be checked against the ADFS machine. If they do not have a logon for the website, then the system would create an account using the same logon and password, but also bring across properties such as given name, etc.
Some clarification.....
We have a website that uses ADFS for authentication it is an intranet based application.
This application is used by some of our customers and they already have a AD configuration, so our ADFS solution will effectively be setup as a third party relaying party. The intranet app currently has a dashbaord where new users can be created.
The application is used off site.
One of my bosses thought it would be a good idea to see if we could dynamically add users to our app as they are already authenticated by the customers AD installation.
Does that make more sense?
This question does not make sense. As a result it needs to be closed. If a moderator sees this response, can they close this question.
Related
Are Azure Active Directory app roles only supported for accounts in the same tenancy?
I am trying to use Azure Active Directory to authenticate users both on my tenancy, others, and social accounts, and be able to manually assign different app-level roles.
What I would like:
Users would sign up using any of these methods, and I would see them in the 'Users and groups' blade of the Enterprise Application in Azure portal (or I could invite them). I would assign app roles (roles specific to my app, eg engineer/technician/residential user) via the 'Add user/group' button.
When logging in to my app, I retrieve the app roles via idTokenClaims.roles[]
What happens instead:
This works fine for user accounts already in my Azure tenancy. But for other Microsoft accounts (eg theirname#outlook.com or MS accounts created with any email address), the user doesn't appear in Azure portal after logging in unless I manually invite them. After inviting them (and accepting the invite), I see a user like theirname_outlook.com#EXT##mytenancy.onmicrosoft.com. I can assign app roles to this user, but their idTokenClaims.roles[] is not returned.
Other social accounts (eg Twitter, facebook) seem to not be supported at all
What else I tried
I also investigated AD B2C, which gives the developer more control over the login flow, and supports other social accounts other than MS (which looks good), but it seems that doesn't support app roles at all.
Am I trying to use the wrong tool for the job?
All I want to do is support any user to sign up to my app, and for an admin to set what their app-specific roles should be.
Update
I am using the MSAL auth library, following the instructions
https://login.microsoftonline.com/Enter_the_Tenant_Id_here should be one of the following:
If your application supports accounts in this organizational directory, replace this value with the Tenant ID or Tenant name. For example, contoso.microsoft.com.
If your application supports accounts in any organizational directory, replace this value with organizations.
If your application supports accounts in any organizational directory and personal Microsoft accounts, replace this value with common.
To restrict support to personal Microsoft accounts only, replace this value with consumers.
Because I wanted this to work with any social account, I chose https://login.microsoftonline.com/common. This shows a UI that allows you to use any organisation or personal MS account, or sign up for a personal MS account with any email address. But I noticed the objectId returned for personal accounts is different to the id when I manually invite the account in azure portal. I changed to use my TenantID instead, and that worked. Personal accounts that have been previously invited via portal can log in. Other personal accounts get an error and cant log in. App roles are now returned for these personal accounts. This now partially solves my original problem, but I still have some unsolved issues:
this method shows a slightly different UI that doesn't allow the user to sign up for a new MS account in this flow
I still can't use other oauth accounts eg Twitter/Facebook. Do these not support app roles at all?
the instructions quoted above seem incorrect, clearly it is possible to log in using "accounts in any organizational directory and personal Microsoft accounts" via TenentID, not common, once they've been invited to the app
App roles absolutely support guest accounts. But as you can see, the id token of the guest account does not seem to contain the roles claim, and it is not clear whether this is by design. But the roles claim will appear in the access token.
I think an access token you can be used, and the access token also contains user information.
I created a "Web app / API" app in our organization's "xxx.onmicrosoft.com" Azure Active Directory. The app's "Multi-tenanted" property has been set to "Yes".
We configured OpenID Connect (we use https://github.com/mitreid-connect/) to use the following URLs:
https://login.microsoftonline.com/common/oauth2/authorize
https://login.microsoftonline.com/common/oauth2/token
Please note that we used "common" in the URLs and we didn't use "xxx.onmicrosoft.com" because we want people from outside "xxx.onmicrosoft.com" to be able to authenticate and access our app.
With those settings, the people from xxx.onmicrosoft.com can properly authenticate and access the app.
However, when I use my personal live.com account (with username xxx#gmail.com) to access the app, I get AADSTS50020 error. I am able to properly authenticate with my xxx#gmail.com account, but I do not get redirected to the Reply URL. I'm stuck on Microsoft's Web page with the following error msg:
AADSTS50020: User account 'xxx#gmail.com' from identity provider
'live.com' does not exist in tenant 'xxx.onmicrosoft.com' and cannot
access the application '391e7103-ZZZZ-zz87-xxxx-7xxxxxd5xxxx' in that
tenant. The account needs to be added as an external user in the
tenant first. Sign out and sign in again with a different Azure Active
Directory user account.
What configuration do I need to change if I want people from any identity provider to be able to access my app ?
Like it has been stated here, I expected that people from anywhere could access my app without requiring more configuration on my side.
I'm asking this question because I'm in the process of getting certified for AppSource and this currently blocks me from being able to do so.
AppSource only requires work accounts to sign-in. You are using an #gmail account - which is a personal account - and because you are using the Azure Active Directory v1 endpoint in addition to common (https://login.microsoftonline.com/common), it can't accept personal accounts to sign-in directly - only work accounts.
You have three options:
If sign-in personal accounts is not a requirement for your application, then you can continue using the v1 endpoint and use a work account to sign-in/test your application. This will make you ready for AppSource certification.
If you need/ want to allow personal accounts in your application in addition to work accounts, then you can consider using the v2 endpoint (https://login.microsoftonline.com/common/v2.0) for Azure Active Directory. The v2 endpoint allow both personal accounts and work accounts to sign-in with no effort.A note is the v2 endpoint has some limitations: if you can live with these limitations (for example, your application only needs to sign-in users and eventually make queries against Graph API), then in general it should be fine to use, but if you need extra features like protecting your own Web API with scopes, then this feature is not released at this point (as November 2017). Please read this document for an updated list of limitations of the v2 endpoint.
A third (but less recommended option for AppSource) is to keep using the v1 endpoint and make your application to be single tenant - which is to change the endpoint from https://login.microsoftonline.com/common to https://login.microsoftonline.com/{yourtenantid}, and then use B2B invitations API to invite every external users (including work and personal accounts) to be part of your Azure AD tenant/organization. More information about B2B here as well.
The option '3' above have some consequences for management as well for AppSource: by using this option, you are required to have one Azure Active Directory tenant (if you don't have a tenant already, you can get one using these instructions), and the users being invited will be guests accounts of this tenant - this mean that you need to invite every external user to your application/ tenant. A multi-tenant application allows any user from any organization to sign-in to your application with less management on your side. In general for SaaS applications, multi-tenant configuration is recommended.
For AppSource, also the option '3' leads to a less-immersive user experience (Partner led trial), where the end user won't be able to access your application's demo right away - mainly because that they have to wait for the invitation's email and accept it (user has to accept being guest of your tenant) so that they can access your application.
For more information about AppSource requirements and trial options - please see this article.
I'm very new to LDAP and Active Directory and I'm probably understanding something completely wrong.
I know ASP.NET Identity and forms authentication (however, I'm also quite new to that) and my question is actually if it is possible to use certain features you can use with forms authentication (explanation further below) with Active Directory.
I'm building an MVC web application and I'd like to authenticate my users against Active Directory. That would be possible with ADFS. The template you get when using ASP.NET Identity in VS2013 uses passive authentication. Is it however possible to not do this redirect to the Active Directory domain but create a custom login page for the user?
Is it also possible to do user management with Active Directory like that is possible with forms authentication? I was thinking about:
A page where the user can register himself
Ability for the user to change his password (I know this is possible with ADFS, but the user may not be logged in. I want him to do this when he's logged in, with a self-made page.)
Logging in on a new computer should ask for a code specified in an email
Set up password policy in the application
... (Other things that I might have forgotten)
When these things aren't implicitly possible with Active Directory, please advise on how to configure the application to acquire this functionality (when possible with Active Directory).
Thank you very much in advance for helping me!
EDIT 1:
To leave my question not too open, I maybe better just start with that custom login page. When I understand it well, the normal flow when using ADFS to authenticate your users against is:
A user tries to access a web page of an application for which he needs to be authenticated
(Passive) redirect to a login page provided by ADFS -> user enter his AD credentials
ADFS returns token
Token is sent to the web application (that ADFS trusts)
When the web application thinks everything is ok, it stores an authentication cookie in the user's browser (I guess), and the user can access the web page
What I would like:
A user tries to access a web page of an application for which he needs to be authenticated
Redirect to a login page of that same web application where the user can enter his credentials
The entered credentials are sent to ADFS (I guess) and it returns something (a token?) with information about whether the login succeeded or not (This step could be preceded by a call to some (self-made) service (a Web API application) that multiple client applications could use for their authentication against the same directory)
When the login succeeded, the web application stores a cookie in the user's browser and the user is able to access the page
I don't know if that makes sense? I'm just wondering how companies that use Active Directory to store user information can still have a custom login page, registration page and other user management stuff. (Or don't they use AD but do they just have their own databases?)
Normally if you want a custom login page you use an ADFS active profile implementation (e.g. WCF) to do the authentication.
User provisioning is not part of ADFS. To do this you need an Identity Manager e.g. PingFederate, OpenIDM.
If you are using ADFS 2.0 or 2.1, you can customize the pages (because they run on IIS) and add these features or redirect to a separate website which does.
Most of what you want is OOTB AD functionality. Refer: Everything in Active Directory via C#.NET 3.5 (Using System.DirectoryServices.AccountManagement).
Password policy can be extremely complex. I don't know of any API's that explicitly do this.
If you are using ADFS 3.0, these is no ISS so you are pretty much out of luck.
It's not really an answer to my question here, but if someone is interested in what I eventually did: you can read it (very briefly) here.
I'm struggling with my MVC5 webapp that is hosted on Azure. I need to secure it (of course) but I don't want to let the users create yet another account, with another password they can forget.
So I've looked into Azure Access Control (ACS). It looks nice, but the Identity Providers provided are very limited. I'm missing LinkedIn as an IP for example. Therefore a lot of users will have to create a new account with a company emailaddress. Facebook user typically use their private emailaddress.
So Azure Active Directory looks fine. You can federate with a local Active Directory. But after diving into it, it seems that you cannot create a tenant from you code. So the user must first do thing in the Azure portal, and that is confusing and I want to make things as easy as possible.
What do I need:
authentications of users without storing their password myself
creation of new users by code
be able to federate to a customer's Active Directory (on premise or Azure Active Directory)
user must be able to use whatever emailaddress they're using
Do you have good suggestions to accomplish this?
You can manage users in AAD using the Graph API.
Using DirSync or AADSync, you can propagate your on-premise users to AAD.
User will have to logon on-premise and again in the cloud but using the same credentials. (Same Sign On).
Adding ADFS to the mix gives you SSO. (Single Sign On).
Typically, only the corporate domain can be used for email address.
For other applications, look at: Azure Active Directory applications.
We are planning to create two sharepoint web applications using SharePoint 2010 Enterprise Edition.
All Users that have access to web app 1, should also be able to access web app 2.
This authentication shall be powered by server 2003 active directory.
--> do I need to use claims based authentication?
If so --> can I use Windows Based Authentication with NTLM for that?
The only thing I really want is that users navigating from web app 1 to web app 2 (and vice versa) do not have to authenticate twice.
I do NOT want to configure Kerberos if it is not absolutely necessare though...
Can you give me any hints?
Thanks!
EDIT:
ok - I'll try to be more precise:
In our SharePoint 2010 environment, we've got two web applications running
http(s)://humanresources.domain.com
http(s)://sales.domain.com
Both are running on the same IIS and have host headers configured (with wildcard domain certificate for HTTPS).
Both apps provide a link to the other web application (sales -> humanresources and humanresources -> sales)
Now whenever someone logged in to sales navigates to humaresources, I do not want that that person needs to login again. Therefore I thought I would need claims based authentication???...
Please enlight my brain! :D
EDIT 2:
Thank you for your answers!
#Panagiotis Kanavos - yes we have Users accessing the site from outside our environment: 1) Users which have an AD accound and are working on their laptops outside of our building (e.g.: they have been all day at a customer and are working at home for the remaining hours) 2) We plan to have users without an AD Accound --> Forms Based Authentication: (e.g.: customers accessing our TFS 2010 project protals to get an overview of the project). As far as I know, if you want FBA and WIN-Auth you need to configure Claims Based Authentication...
However configuring a Web Application with Claims Based Authentication did not work. I chose "Enable Windows Authentication" together with "Integrated Windows authentication -> NTLM" as we do not have Kerberos configured (and I'd love to leave it like that ;-)).
However the Users could not login to that application sometimes, and five minutes afterwards it worked. Additionally, when I added permissions to an AD user, SharePoint seemed to save the Token instead of the Group-/Account Id:
e.g.: Instead of MyDomain\user1 it saved something like "0|=MyDomain\user1" and for groups it even only saved weird character strings "022-12.3"
Could it be the case, that my 2003 windows AD does not support that?
IF you are using Active Directory and running both sites within your domain you should not be challenged when users go to either site. It just becomes an implementation issue about who has access to what, either via AD Groups or SharePoint groups.
Claims based authentication is a bit of a different animal. You need to have a security token which contains a number of "claims" about the user, for example UserA is a member of HR and UserB is a member of Sales. Based on these claims you can then have your site/application respond correspondingly. Claims based auth is relatively new for SharePoint and Microsoft and is a bit of steeper learning curve. It may make more sense if you have a mixed mode environment, with both AD and Forms Based Users getting access. However with your described heterogeneous environment it doesn't seem like it's needed.
More info on SharePoint 2010 Authentication is available here.
John
The easiest solution is to create an AD group with the users of both sites and add the group as a user to the Members Sharepoint group of each site. This way users will not have to login at all since Sharepoint will detect the identity of the logged-in user automatically.
Why are you asking about login, claims, and why are you using certificates? None of this is necessary in an intranet scenario where the farm and users are in the same domain or if the farm's domain trusts the user's domain. Do you have users accessing the site from outside your domain?