I'm new to Azure AD and I'm trying to create an app (that I'm developing) and setup an automated user provisioning (SCIM).
The first thing I need to do is to create an application, so I go the App registration in the Azure AD portal and create one. It's a multi-tent application.
After that I navigated to the Authentication menu and added a Mobile and Desktop configuration only. A Service principal is automatically created in the Enterprise applications menu.
When I go the Provisioning menu that is supposed to allow me to configure the automated user provisioning I get this:
"Out of the box automatic provisioning to AppName is not supported today. Ensure that AppName supports the SCIM standard for provisioning and request support for the application as described here. To determine if the application suports SCIM, please contact the application developer."
Does anyone knows why this is happening? Is it because I've added only a Desktop and Mobile platform configuration? I can't find any good explanation and I can't figure out how to make it work and what I'm supposed to do to make it work.
How am i supposed to make the automatic user provisioning work on my own application?
Thanks!
Provisioning is a feature for Enterprise Applications, which are slightly different in nature from (and have some overlap with) App Registrations. Create an Enterprise Application - a custom/non-gallery app is fine - and you'll be able to enable provisioning on that.
Related
In the past there was both the separate website AND the Azure classic portal for managing Signin Apps. In the Classic portal it would give you the ability to edit the ReplyUrls.
In the new portal no matter how you create an app (Enterprise or Application Registration) you can't edit your ReplyUrls from the UI. (With Application you can set them the first time but then they don't show up in the Application list from then on so it's impossible to edit them)
Meanwhile these same apps can have their replyUrls updated using Powershell without any problem.
To me this is a blocker bug, but maybe I'm doing something wrong? I've successfully gotten only 1 application to show up under application registrations. All others including ones created back in the Azure Classic day show up in Enterprise applications without even the Sign On Option showing up in the list of options for the application per the instructions on Microsoft's website.
I can private message an app Id as an example.
The user experience of the Azure portal changed for the worse (in my opinion).
I also had trouble finding my old apps... turns out they are now "hidden" by default.
they don't show up in the Application list from then on so it's impossible to edit them)
You will find them under "all apps".
I have two applications:
MVC Site (User-facing Web App secured via OAuth -> Google)
Web API Site ("Private" Web Services)
These are hosted in an App Service Plan in Azure. These web services will only be consumed by my own applications - I don't need to worry about outside consumption. In fact, I specifically don't want outside consumption. My Web App is using OAuth to Google - that shouldn't matter here.
So to get to the heart of my question: My web services currently have no authentication/authorization model in the code but I don't want it just publicly available to anybody. On prem, we just lock this down via IIS using Windows Auth and set the service account for the consuming web app to run as a user that Windows Auth allows access to. I'd like to do the equivalent in Azure.
I understand Azure isn't exactly the same but I have to believe this is possible. I have even gotten my web services locked down the way I want using the settings in the Authentication/Authorization tab (I can try to navigate to it but I only get my Swagger UI once I login with a valid organizational account). So half of my battle is solved but I cannot figure out how to do the other half - the equivalent of setting the service account for my consuming MVC application to run as.
Can I do this via the portal without having to code specifically to this scenario? I'd really like a PaaS-level or IaaS-level solution for the security portion of consuming the above locked-down services. I'm also open to other avenues if I'm going down the wrong path in having a PaaS or IaaS security solution to this problem. I'm not against making code changes - we did have a one-liner in our RestSharp code to engage Windows Authentication, but the bulk of the work/configuration was outside of code and that's what I'm going for here.
If going the IaaS path you can host the application inside of an VM in the exact same way as you did before when running it directly on-top of IIS. The benefit is that you can get running the same way as before but you will still need to manage the VM; i.e install updates and take care of its security.
However, if you want to have a PaaS solution, then you need to modify the code of your front-end application to pass on the authentication token to the back-end API, assuming the back-end accepts the same authentication as the front-end. See https://azure.microsoft.com/en-us/documentation/articles/app-service-api-dotnet-get-started/ as an example on how to pass on authentication information from one app to another.
Alternatively you can use the app identity to make calls to your back-end API. This way the calls are not related to any user but are instead done in the context of the app. See https://github.com/Azure-Samples/active-directory-dotnet-daemon for more details on how to set it up, both configuration and needed code.
If you want to allow your users to sign-in using their Google accounts then you could handle authorization to your API using the app identity (second alternative above), assuming the API is independent of the requesting users identity.
Enabling authentication for a Azure Web App directly through the menus in the Azure Portal adds Azure AD authentication in-front of your application and require your to pass an access token generated by Azure AD to your API for it to work.
Even though I've added apps from gallery to Azure AD, I cannot see when I try to pull the data. But I can see the custom apps added. Like if I've added 7 apps; 2 from gallery(Google Docs, One drive) & 5 custom(native/web apps); I am able to see only 5 apps! Am I going wrong any where?
The Graph API that am using is:
https://graph.windows.net/mycustomad.onmicrosoft.com/applications?api-version=beta
I tried with different api versions but no luck.
Can someone suggest me on this?
In graph API, "applications" represent application configuration that developers register in their tenant. Gallery apps are no different (and happen to be registered in a special tenant). When you acquire an application (like a gallery app, or consent to a custom application someone else has developed), an application instance gets created in your tenant so that we can attach policy and permissions to it. This application instance is called a "service principal".
You can query for this using:
https://graph.windows.net/mycustomad.onmicrosoft.com/servicePrincipals?api-version=1.5
This will return ALL acquired apps, and some default Microsoft apps.
Hope this explains why your query of the application entity shows only the custom apps you've registered in your tenant.
Hope this helps
I work for a network management company and I want to write a .Net application (MVC 4) that will allow us to service Active Directory users from a cloud-based application.
As I have never written a cloud-based app, I don't know if I'm using that term correctly or not. I am in the requirements gathering stage. Basically, I'd like to provide our customers with the ability, for example, to change their own password using our cloud-based application.
is this an application that should be written specifically using Azure? If not, what tools and platform(s) should I take into consideration?
What tutorials or other resources are available ?
Actually, I don't even know enough about Active Directory and Cloud computing to ask the right questions. But, I hope someone will point me in the right direction
Read How to Authenticate Web Users with Windows Azure Active Directory Access Control. There are great walk-throughs there. There is more reading and code samples here - Access Control Service 2.0.
That's using ACS.
You could go direct to Azure Active Directory if you wished?
Refer: Adding Sign-On to Your Web Application Using Windows Azure AD.
If you use Office 365, you already have an AAD tenant.
If you follow Microsoft's instructions here to enable RDP on instances in a Cloud Service, they tell you to create a user and set a password for remote desktop purposes.
As this can quickly become a "shared account", I am wondering how one goes about linking this to a person. The Azure Operation logs do not seem to keep track of who RDP'ed or not, and the Windows Security Event Log obviously has no idea what user was connecting other than the user you created. This make traceability difficult.
While I understand RDP should only be enabled for troubleshooting purposes, I am hoping I missed something simple that would allow Azure Cloud Service users to enable RDP without losing all traceability on who is accessing what instance.
Short Version: How do I know who connected over RDP using the shared RDP Account? Azure logs, infrastructure logs maybe?
Thanks
There have been a few changes since the link you mentioned is published:
You can now enable/disable remote desktop through the portal. You don't have to do it at the time of publishing your cloud service. Using this, you can provision remote desktop connections for individual users in your team instead of relying on one shared RDP connection. To do so, click on CONFIGURE tab for your cloud service and then click on Remote icon and follow the instructions.
The thing you do on portal with remote desktop can also be done programmatically using Service Management API. With the latest Service Management API release, RDP functionality is basically an extension which you can enable/disable on the fly. I wrote a blog post not too long ago describing this functionality: http://gauravmantri.com/2013/05/06/windows-azure-cloud-services-extensions-and-service-management-api-fun-with-remote-desktop/
I haven't actually looked at security event logs so I can't say for sure that it would log this activity but I'm assuming it would.