Basics<\/h1>\n
Let\u2019s take a look at this new fabulous portal, shall we. Pop out your favorite browser and navigate to https:\/\/portal.azure.com<\/a>.<\/p>\n You\u2019ll land on a page like the below.<\/p>\n Where is Azure AD? Click on \u201cMore services\u201d on the left menu, and you\u2019ll find it:<\/p>\n Click on it, and the next blade will open to something to this effect:<\/p>\n As Jeff\u2019s post explains<\/a>, the landing page offers lots of interesting insights on your Azure AD tenant, and various hooks for management actions.<\/p>\n Just for kicks, let\u2019s take a look at the Azure AD landing page in the old portal:<\/p>\n The first thing that jumps to the eye: the old portal shows both VibroDirectory, the Azure AD tenant tied to my Azure subscription, and OsakaMVPDirectory, a test tenant I created when I visited Japan a couple of years ago (I need an excuse to get back there\u2026awesome place, awesome people). That\u2019s because the user I am signed in with, vibro@cloudidentity.net<\/a>, is a user (more: an admin) in both tenants. How do I achieve the same effect in portal.azure.com? Simple. See that user badge on the top right corner, informing you about what user and tenant are you currently signed in with? Click on it:<\/p>\n Together with the usual account operations you expect to find there, you\u2019ll also notice that all the tenants accessible by your user will be available for you to choose. Let\u2019s see what happens if I select OsakaMVPDirectory.<\/p>\n Voila\u2019! The portal changed to reflect the new tenant. As you can see, the landing page is far more barren\u2026 I\u2019ve used that tenant just for playing a bit with Azure AD, nothing more.<\/p>\n In fact, this is far more barren than you would probably expect from something displayed in an Azure portal\u2026 and here there\u2019s the kicker: that\u2019s because this tenant has no Azure subscription associated to it<\/u><\/strong>! Don\u2019t believe me? Click on all subscriptions.<\/p>\n That\u2019s right. This is huge, so let me rephrase to make sure you appreciate the implications:<\/p>\n You now have a portal you can use to manage Azure AD tenants that are NOT associated to an Azure subscription.<\/em><\/u><\/strong><\/p>\n The office developers among you are probably jumping up and down right now Now, don\u2019t get me wrong. Having Azure AD capabilities alongside all the other Azure services you are using in your solution is a huge advantage in itself and I am in no way trying to minimize that. I am just excited that the Azure AD development portal capabilities are no longer strictly subordinated to that.<\/p>\n Enough of this \u2013 let\u2019s take a look at the meat of the developer features: application creation and editing.<\/p>\n Let\u2019s go back to the Azure AD landing page on portal.azure.com. Where are the developer features? If you thought \u201cEnterprise applications\u201d \u2013 sorry, no bonus. The developer features are all available behind the sibylline moniker \u201cApp registrations\u201d. Click on it, and you\u2019ll find yourself on the following blade.<\/p>\n Those are all the apps created in this tenant \u2013 that is applications for which the Application entity resides on this very tenant. Some important differences jump to the eye:<\/p>\n Let\u2019s pick one app and see how it looks like.<\/p>\n The first blade, Essentials, presents a quick summary of the main properties of the app. The settings blade, which opens automatically as soon as you select the app, corrals all the app properties in a neat set of categories. There\u2019s even a nice search field that will show you in which bucket you\u2019ll find the property you need. Most notably, the dev features in the new portal do not offer any of the operations that would affect the ServicePrincipal of your app \u2013 that is to say, the instance of the app in your own tenant. In the old portal, creating an app meant both creating an Application object (the blueprint of your app) and provisioning that app right away in your own tenant. In the new portal, creating an app means just creating the blueprint, the Application. The user assignment, app role assignments etc are available in the admin portion of the portal \u2013 but you\u2019ll be able to use those against your app only if you do provision it in your own tenant after creation. There are lots of neat features tucked in those options, especially in the ones that have been historically difficult to deal with in the old portal. Let\u2019s take a look at my two favorites: permission management and manifest editing.<\/p>\n If you go to the Required permissions blade (finally a good name) and click on Add, you\u2019ll find yourself at the beginning of a nice guided experience:<\/p>\n Clicking on Select an API, I get to a clean list of what\u2019s available \u2013 even including a search box.<\/p>\n Let\u2019s click on the Microsoft Graph and hit Select.<\/p>\n Now, isn\u2019t that super neat! You get a nice list of permissions, subdivided by application and delegated\u2026 and you even get indications on what permissions can only be consented by administrators vs all users! Personally, the colors give me cognitive dissonance: as a developer who isn\u2019t often an admin, the permissions requiring admin consent are the problematic ones. But! The information is there, and that wasn\u2019t the case before.<\/p>\n The other feature I really like, and I am sure it will be your favorite too, is the inline editing of the manifest. There\u2019s even some rudimentary auto completion support, which is great for people like myself with non-existing memory for keywords.<\/p>\n As diligently reported by the header of each and every blade, this stuff is still in preview. Your input is always super valuable \u2013 the right place to provide it in this case is in the \u2018Admin Portal\u2019 section of our feedback forum<\/a>.<\/p>\n![\"image\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2016\/09\/image_thumb.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2016\/09\/image_thumb-1.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2016\/09\/image_thumb-2.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2016\/09\/image_thumb-3.png\" "\\"image\\"")
<\/a><\/p>\n
\nI can easily choose what tenant I want to manage by clicking the corresponding entry.<\/p>\n![\"image\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2016\/09\/image_thumb-4.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2016\/09\/image_thumb-5.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2016\/09\/image_thumb-6.png\" "\\"image\\"")
<\/a><\/p>\n![\"Smile\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2016\/09\/wlEmoticon-smile.png\")
go ahead, try it! Navigate to portal.azure.com and sign in with your office dev account for your Office tenant, I\u2019l wait. See? that\u2019s awesome!<\/p>\nApp creation and editing<\/h1>\n
![\"image\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2016\/09\/image_thumb-7.png\" "\\"image\\"")
<\/a><\/p>\n
\nLet\u2019s compare with the same view on the old portal.<\/p>\n![\"image\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2016\/09\/image_thumb-8.png\" "\\"image\\"")
<\/a><\/p>\n\n
![\"image\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2016\/09\/image_thumb-9.png\" "\\"image\\"")
<\/a><\/p>\n
\nNearly all the old properties are there: the rather large image below shows the mapping between old and new. I recommend you click on the pic to display the full image.<\/p>\n![\"PortalMapping\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2016\/09\/PortalMapping_thumb.png\" "\\"PortalMapping\\"")
<\/a><\/p>\n
\nIf you want to provision your app in your own tenant: you need to run it, attempt signing in with one user from your tenant with the right privileges, and granting consent when prompted. That will lead to the provisioning of the app, that is to say the creation of the ServicePrincipal in your tenant and the assignment of the permissions you consented to (VERY detailed description of the process in this free chapter<\/a>).<\/p>\n![\"image\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2016\/09\/image_thumb-10.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2016\/09\/image_thumb-11.png\" "\\"image\\"")
<\/a><\/p>\n![\"image\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2016\/09\/image_thumb-12.png\" "\\"image\\"")
<\/a><\/p>\n
\nAzure AD applications have lots of settings that can\u2019t be accessed via portal \u2013 and sometimes, it\u2019s just better to be able cut & paste settings directly. For that purpose, the old portal offered the ability to download the app manifest (a JSON dump of the Application object, really), edit it locally, and re-upload it to apply changes.
\nIn the new portal, however, you can edit the manifest in place \u2013 no need to go through the download-edit-upload cycle! You can access the feature by going back to the Essentials blade and clicking on Edit manifest.<\/p>\n![\"image\"](\"https:\/\/www.cloudidentity.com\/blog\/wp-content\/uploads\/2016\/09\/image_thumb-13.png\" "\\"image\\"")
<\/a><\/p>\nTry it out!<\/h1>\n