Watch videos with subtitles in your language, upload your videos, create your own subtitles! Click here to learn more on "how to Dotsub"

Introduction to Windows Azure Active Directory

0 (0 Likes / 0 Dislikes)
  • Embed Video

  • Embed normal player Copy to Clipboard
  • Embed a smaller player Copy to Clipboard
  • Advanced Embedding Options
  • Embed Video With Transcription

  • Embed with transcription beside video Copy to Clipboard
  • Embed with transcription below video Copy to Clipboard
  • Embed transcript

  • Embed transcript in:
    Copy to Clipboard
  • Invite a user to Dotsub
So let's get—without further ado, let's get started. [Introduction to Windows Azure Active Directory] [Ross Adams Senior Program Manager] What are we all here for today? Firstly me, I'm Ross Adams. I'm a senior program manager, and I'm based out of Redmond. I work in the Windows Azure Active Directory team. And we're going to talk to you and give you sort of a lowdown on what is Windows Azure Active Directory. It's a bit of a story on how we got here and what we're doing. We'll roll through. To start with, there was a problem. There's always a problem at the beginning of all good stories. So we had this service called Office 365. So who has heard of Office 365? Who has an Office 365 subscription? Excellent, then you all have Windows as your active directory as well. What ended up happening was we sat down and we needed to get all of these cloud services— Exchanged online, SharePoint online, and Lync online. They needed some sort of directory to run from, and it needed to be a pretty good directory, and need to run at Internet scale. It had to provide secure isolation of customer's data so one customer couldn't see another user's data or i.e. the multi-tenancy problems, so that's sharing and isolation. And—you know—as I said, it had to be there for internet scale. Right now Office 365 runs something at about 3 million tenants with close to a billion authentic a day, so we needed to make sure that we had enough scale. So the choice we made was to build our own directory. We now call it Windows Azure Active Directory, okay? Previously we didn't really give it a name. It was just kind of released as part of Office 365, but it was the same directory that underpinned Office 365. And it's really—if you imagine, you'll be confused with thinking that Windows Azure Active Directory is kind of like Active Directory running in the cloud. If you kind of peeled the hood and looked deep underneath the covers, you would find something that resembled Active Directory. However, it's a very revised Active Directory. To make sure that we do run at that Internet scale— that we do have that multi-tenancy, and it was sort of built in conjunction with Office 365. So really when we took Office 365 and we built this directory underneath it, we were building effectively Windows Azure Active Directory. We just didn't have a name to give it at that particular point in time. Now it has a name, but if you've got Office 365, you've got the same thing. And really when you think about Windows Azure Active Directory and the reason that Active Directory is part of it's name— the way we think of it an extension of that on-premise directory, okay? So it's really taking sort of ideas that exist today and pushing it up into the cloud. If you run Exchange on premise, it talks to AD. If you run Exchange online, it talks to Azure Active Directory. So some of those concepts have allowed us to take that Active Directory and project it into the cloud. I'll talk more about that in a little while. So it also doesn't require that you have a directory on premise, so we have a lot of small customers who don't have a directory on premise and don't really want one—don't want to have Windows Server Active Directory running on premise. They just want a directory in the cloud, and Azure Active Directory fulfills that goal for them. And just like all good problems, there was another problem that we found, customers have the same types of issues. So if you think back, we had NT 4.0 domain controllers, and they were wonderful things. And then we got another one, and we had 2 domains. Then we create trusts. And then we had another one—there were 3. And then we had this meshing of trusts. And we said, "Oh, we'll solve that. You can have Active Directory." And of course we got Active Directory, and people consolidated their NT 4.0 forests—domains into forests, and everything looked great. We had this single management HUB above everything. And then we got another forest because we bought somebody and then yet another forest. Before we knew it, we were again dealing with this problem of proliferating directories and user names and passwords. And the cloud has really kind of made that worse, all right? If you're using different cloud systems, you're uploading different users and different credentials potentially to the cloud. So there's some sort of semi-manual automated type of process of trying to propagate your directory data up into the cloud. And then you've got the problem of identity— different user names and different passwords. So effectively cloud solved some problems and created some others. So we looked at the way that we designed Azure Active Directory, and we said, "Hey, there are certain things we can do here. We can take the data that we have in Azure Active Directory and allow it to consolidate as a cloud-based directory for all of the different apps." So obviously we have Office 365. We have different—other Microsoft services up there, so you can use it with Azure, you can use it with InTune, you can use it with the online backup services. So all of the sort of MSFT or the Microsoft cloud apps that are coming through will all start to use the Azure Active Directory as their core directory allowing us to share that single directory data up in the cloud. There's also trying to connect all these different devices, okay? So getting all the different devices to hookup to the service. It's quite easy to do. Certain things we had with on-premise Active Directory, but it was sort of a design requirement for the cloud. We needed to make sure we supported disjointed machines, browsers from all different places, all different types of devices, so pretty much any form factor getting up there. And then being able to share that information across all of these different end products. Your line of business apps that you write in the cloud should be able to leverage this, and we'll talk more. ISV-based apps and obviously the Microsoft apps. So as we sat down to design this, we had a few differences. So if you look at Windows Server Active Directory, there's a number of different services it offers. It offers the sort of core directory services—the directory and identity pieces. You've got ADFS, the federation services sitting in there. You've got certificate services, rights management services, and a few other services that sit in there. But not all of them are destined or usable in the cloud. For example, to talk to Windows server, Active Directory LDAP is a great way of talking to it. Not so good for the cloud— LDAP not being one of the friendliest protocols. And we need to make sure that as part of our design for Windows Azure Active Directory we're able to maximize the reach. So part of maximizing that reach was making sure that we supported nice Internet friendly protocols, so http/web/REST protocols to get there. And we had to get to the multi-tenancy bit, as I mentioned. So multi-tenancy is actually a lot harder than what it seems. There's a concept of isolation, and there's a concept of ownership in there. So we had to make sure that the data that the customer put in the cloud and their tenancy was owned by the customer and not owned by Microsoft. But we had to make sure that that ownership was there as well. We also had to get there for availability, consistent performance, so it really didn't matter where you were, it didn't matter if there were lots of people on the system as it grew. Everything had to continue to operate as they were, which meant we had to keep it nice and simple. Active Directory as it expands can get complicated. The more and more replication data you have, the more data you have to replicate. The more remote places places starts to become a problem. We needed to make sure that it wasn't an issue when we got into the cloud. And we also—and this is a fairly key point, is we know that people have invested a lot of this money and effort in getting a consolidated directory on premises. So we want to make sure that when we design Windows— or when we designed Windows Azure Active Directory that there was a way for you to be able to get all of that information up into the cloud. So let me switch across. This is going to be exciting—here we go—push a button. I believe it's this one. So let me give you a little demo. So just so there's no confusion here, I'm just going to fire off my browser. I'm going to fire off—I'm going to go into Azure first. So that's not where I wanted to go, I wanted to sign in. So if you're using Azure, you can actually— by default it will try to sign you in with a Live ID. You can also tell it I want to use an organizational identity. So I'm going to use my organizational identity, which happens to be in admin and my little tenant. If I can type my user name, we'll get right in here. I'm going to sign in here, and eventually this will load through for me. Now I'm going to tell it I want my Azure Active Directory tenant. Once it figures out where I am. Did I get the right button—I got the right button. And you get a user list here. And just to show that these are all the same things, so for all of you who have Office 365, you'll be familiar with this particular portal. So let's go here. And because I've already signed in using my organizational credentials, I'll get strained off as 365. In this case, I don't have any services, so Office 365 looks a little limited. But if I look in here at my users and groups, I have the same list of users, and I will attempt to add one just for the interest of time. There we go. I've got to buys some licenses. Don't bother sending me an email just go ahead and create the guy. All right. And Bob should be in here. And through the wonders of modern technology— I'll just go back here and tell it to go here. And there's Bob there, okay? So what we've got now is this nice— push the right button. This nice means of ensuring that between all these different cloud systems that— as we call it Windows Azure Active Directory, it's not necessarily an Azure service in the sense that it's controlled and owned only by Azure. There's this cross platform experience there. So how does—how do these 2 things work together? How does Windows Azure Active Directory and Windows Server AD actually—what's their relationship? How do they work together? And there's sort of I guess two way of looking at this. You can really think that you're on-premise and the cloud directory can be managed as a single entity. You need not manage them separately, okay? And there's two parts to that. The first part is sort of what we'll call directory information, so this is users, contacts, groups, these types of objects and getting those synchronized up into the cloud. And as it is today, a lot of that is sort of that big green arrow— today is very much a push-up into the cloud. And you can imagine that green arrow becoming somewhat blurred as we move forward in time. So if you're using Office 365, that sync part is what we call directory sync. And we recently re-branded it to call— recently—I guess August of last year we called it— we started calling it Windows Azure Directory synchronization or something similar. And it's really the same tool. It allows us to get that directory data up there. There is some data it writes back. And there's a talk later on in the week around more details around that. And anything you hear around synchronizing around Office 365 applies equally to Azure Active Directory. The second part of that is your identity, okay? So if you like—Directory Services has that sort of 2 parts to the directory and the identity. And getting that identity up into the cloud so that we can do federation and provide single sign on with those corporate credentials. So this is really taking not only the directory data, which you manage on-premise and sort of propagate up into the cloud, if you will, in a nice sort of automated way, but also allowing us to take your identities that you use in your corporate on-premise environment and pushing those into the cloud. So there's a couple of directory sync options, if you like. So we get that data synchronizing from on-premise up in the online cloud, and there's some backwards and forwards parts to that— some attributes that come back to on-prem. And in the future you can image more of that coming through. We have requests for things such as creating a user in the cloud and having them sync back to on-premises. So these are sort of tightly coupling your Azure Active Directory and your on-premise Active Directory. They're managed on-premise, as I said. One new feature that we've got there is the ability to optionally sync up the password up into the cloud, so you have a single user name and a single credential, okay? You authenticate still. You don't get single sign-on necessarily, but you're still using that same credential. In fact, what we sync is not the password. What's that called, the password sync? We actually do sync the hash of the password from the AD Service. Again, Jono and I will talk about this later in the week—Thursday. And I have a link to it at the end of this. So it allows us really—the directory sync portion of this is really to allow us to reuse those objects that we have on-premises up in the cloud. Things like activating based on group, figuring out who can do what within applications we write. And then we have the sort of federation and single sign-on, as I said. So single sign-on—it's probably worthwhile to annotate what we say when we say single sign-on. There are 2 versions of what I would call single sign-on. It's a very overly used term, and most people think of single sign-on as I enter my username once, and I never enter it again. Unfortunately, the world is not quite at that place. So I think of single sign-on in 2 ways. One is the administrators view of single sign-on. So from an administrators perspective when we federate our directory— our on-premise directory to the cloud, we're really talking about— we're really talking about the credential being on-premise managed and on-premised owned. So from their prospective if you change the password, authentication effectively occurs on-premises. So all of the ownership of that credential exists on-premises. Workstation restrictions, log-in times, all of these types of policies you can apply to that on-premise credential apply to that credential. So from the admin's perspective, single sign-on is very much I have a single point of authentication and a single credential that I manage and I create policies on, and it's my on-premises credential. From an end user's perspective, they have a slightly different view of the world. They Ctrl, Alt, Delete on their computer, they type their user name, and they type their password. Now ideally, there are certain cases where we don't prompt for further credentials. We allow the user to sign-in effectively singularly so that things like link sign through without necessarily asking for any more credentials. But there are certain times that the user will be prompted for credentials, but they do have a single credential. It's their own premise credential into that user name and their password to allow them to authenticate. So single sign-on in our concept has those sort of 2 facets to it. One being the admin's view of it, and one being the end user's view of it. So as it says there, identities are really mastered on-premises. It's the single point of management. It's also the single point of failure, but we'll talk about that later. But it's the single point where they manage them. It's token based, so the single sign-on model is really token based. We effectively moved identity to the on-premises active directory, and a token is issued. We trust the token, therefore we let the user in. There are certain things that you can do within Office 365, and we will cover these in more depth on Thursday— around applying restrictions around IP addressing that you can access. For example, exchange online with. And then there's strong factor, so if you implement strong 2FA factor type or multi-factor authentication in your on-premises environment on top of ADFS or on top of your STS, you can start working down that path. So if I run an app in the cloud, how does this all work? And I guess you could say this is true of Office 365 as it's true of any other app. So you have effectively this sort of dance between the 3 of them. You've got Contoso.com Directory, and in this case it will be a tenant within Azure Active Directory, and you've got a cloud application. The user wants to be able to access a cloud application, the cloud application wants to be able to get to the directory to be able to do things like look up the group, look up more details of the user, find out who their manager is for example, and you've also got the user wanting to authenticate to the directory to prove who they are. So these sort of 3 areas that interact together. So typically what you would do is you would sit down and you would say, all right, I have the account and profile store, which is—but with my own premise directory, and I have sort of a simple way of talking to that. It would either be LDAP or whatever. But my clients actually end up with lots of different— different clients with sort of different types of devices. So browsers—I have a web client. They have to render all the different information. I may use a web service type model in order to be able to deal with mobile or server of rich client apps. So I'm really—I'm running an application. I'm not able to sort of share a lot of the components between the two. What we did within the cloud making it— to sort of overcome this problem by providing an easy means for applications to deal with this was to move to what we call the directory graph. So the directory graph is really a single nice restful interface that allows us to get back objects and query in a standard way. So I can write my application to be able to query this data. Once I have queried that data, I don't have to then— I really—just rendering the data on the presentation layout, I don't have to start trying to figure out this is a web service, so I've got to talk to it slightly differently than the way that my server works, which talks to—you know—in different ways. And this is an example, okay? So this is an example of what a directory graph— I mean, obviously there's a lot more properties than that, and it's not necessarily notated in this way. I'm going to give you a quick look at this in a little second. But this graph allows me to go in and view the data that I'm sharing. What we ended up with was this sort of open connectivity model for cloud-based apps talking to Windows Azure Active Directory. So we have that nice restful HTTP layer, which allows us to create, read, update, delete different data, see the objects and their relationships. If you have a manager, there's a return that says if you want a manager you can follow this link, which will be another graph call. And you'll get back the manager and the manager's details. It uses the OData and authenticates through OAuth— or OAuth 2.0 using JWT tokens. So it's a very simple way of getting data. We also support SMAL 2.0 and the WS-Federation setups. And these—these are predominantly used by the Office 356 services— the SAML 2.0 and the SAML 1.1— sorry, the WS-Federation. However, it's not—if you setup Federation with Office 365, you've also setup Federation as your active directory. We just convert the token into an OAuth token for when you're dealing with graph. Graph likes nice OAuth token. So there's a couple of developer scenarios. You could be an existing cloud app provider, and this—or an exciting on-premise provider if you like. You can say I write apps, and I give them to my on-premise customers. And you can change the way that those applications sign in, and I'm going to give you a look through this. It's a very simple process to move it through. The issue being moving from on-premise to the cloud does mean that things like LDAP then exist, but that's a different story. So you can actually go ahead and integrate that experience of signing in to Windows Azure Active Directory and query graph to get the data you're after. You can also develop new applications. So a lot of the times when you're developing a cloud-based application, you need a store for the profile. So I need to store somewhere their username and store somewhere their password. So Azure Active Directory can provide that if you like. So once the users have a tenant, they effectively accredit a profile story for you, and you can—allow you to query into that directory into that account store without necessarily having to build out from there. So you can allow the user to manage their profile directly within Azure Active Directory, and you simply can tune that data. We also can sign up with using popular web-based identities, so you can use Live ID if you wish, and we'll add more and more of those as we come through. You can check out a couple of links there for those who are trying to develop. And this is not just for people who want to develop ISV-based apps or apps that they can sell to other Azure Active Directory tenants, but also for your own Active Directory apps that use Active Directory today that you're trying to move into the cloud. You can get some more details there at the windowsazure.com site, and there are a bunch of samples that allow you to deal with different formats of information. So let's have a quick look at what this looks like. Let's see here. So I'm going to shoot across to my little demo. I put this together, it took all of about 10 minutes. I cheated, I just used the sample. It actually took me longer to—it took me longer to generate this page. I'm not the HTML expert I thought I was. So certainly generating this page was a lot more difficult. So what we can see here is that I have signed in. I'm using that same account, the admin. My graph demo has picked that up, and there's really very little— this is a darknet app, it's very simple to do. It took me about—literally about 10 minutes to put this together. And then I've integrated basically a simple people pickup, which again just using the sample to allow me to find my users. And just so we can prove this is all hooked up together, we'll take that user I created earlier. Good old Bob. And trash Bob. Yes, I know, it will go into the recycle bin. He was deleted. Now let's see if this refreshes. And there goes Bob. So it's a very simple way of being able to get from one place to another. There's a good talk later on on this one. Let me see if I can bring up this one in graph. There we go, who said I couldn't do it? This is something that you can use if you want to. So I just signed in as the admin user. This one gets my display name. And this is sort of an example where you can actually get some of the raw data of what comes back and forth through graph. So I can look up my users, and you can see there's a fair amount of users in my tenant, and this is sort of all of those details. I can also look at different things likes roles. These are the roles that we support. So the roles within Office 365 are exposed here within the graph as well, so you can allow your applications to integrate the 2 things together. I don't know if I've got any groups—no groups. So this is an easy way. You actually don't even need a tenant for this, you can also use what we call a demo company, which allows you to go through. And you can do simple things in here. Actually, let me just make sure I get to the right— this will help me get there. Let's see, admin. And there's the single user. So this is an easy way of getting— if you're starting to try and write line of business apps, now you've got this directory in the cloud, and you want to start moving your applications up there. You can actually start using this as the means of sort of figuring out how to query the data and graphs. So this a different way, if you will, of looking at the data that exists in your on-premise directory. You'd use LDAP, ADSI, or something of that nature. Here we're using graph. Basically everything has a web browser these days of some description, and you can start making calls of this nature direct from the clients. So how did this all hang together? How does my little cloud app actually work? And it's kind of interesting. So we have to make sure that when we do this work that we don't have any—or that when we build these applications that we make sure that we have the right level of authorization behind them. So in this case, I, as the admin, created what we're calling a service principle for my application, and I gave it a particular role. In my case, I gave it read-write. You can give it read. You can give it just single sign on so it doesn't have any access to the graph. So in this case, I created that principle, so when my end user wanted to login into this application, which I'm assuming it's going to do for me in a second. The first thing they did was they authenticated against the directory. So in this case, they went ahead and got a token, and this—I use username and password. If you have Federated identities, you'll use federated auth to log on. And the user got a token. However they got that token is kind of irrelevant to you, and I'll show you why in a little minute. The next thing they try and do is they try and get a token from my app. My application says in order to get a token from me, I have to go and get a token for you. So the graph goes off, and it asks, hey, I want to get a delegation token for this particular user to talk to this particular application. So it's actually combining the 2 things together, the user and the application together to get that OAuth token. And note, it's a delegation token. So once the app has this delegation token, it can request a refresh for that token. The user doesn't need to be there. It's not impersonation at this point. It's truly a delegation—delegated response. So the cloud application then goes ahead and makes a request to the graph API, so the directory graph end point. It says, hey, I've got this token, and I am this particular application, and I'm going to make this call over to the graph, and it passes across to the graph— the token containing the user delegation, and the graph then makes a decision and says, great, that user app combination has rights to be able to read the directory and returns back that set of data. And that's effectively allows me then to get access across to the profile store— in this case, the Azure Active Directory to get the rest of that data. And you could conceivably put through— once you've actually been to the graph. If you had things like a shoe size— if you were writing some app that stored people shoe size, you could then link the 2 things together, the unique identity that comes from the directory graph back to your profile store. So it's a rich way of building these applications to allow you to authorize cloud-based apps to get to your data. By default they cannot get there unless they've been authorized to do so. So as I said before, we had these different types of— some services that run in Windows Server Active Directory and some services that run in Azure Active Directory. So the—one of those additional services that we have now is what we're calling our Windows Azure Active Authentication. So this is effectively a multi-factor authentication process. So why would you want a sort of multi-factor authentication? It;s usually fairly obvious, but I'll walk through. So your data—particularly if you're putting data or exposing data outside of your environment, there's a good chance that somebody else is going to try and get to it. That's just something that we make sure that within the Azure Active Directory team is something that's a fairly big issue for us. We want to make sure that your data is protected while up there. We also want to make sure that something like passwords— passwords are good, but passwords are guessable, people write them down, and we want to be able to protect against that. And one easy way of protecting against it is to use a multi-factor authentication providing something that you have. So in this case, I'm going to use my mobile phone— something I should have with me most of the time. We are building on that to allow for phone-based apps. You're going to see I get a phone call shortly. In the future we'll have— we're going to have a reliance on getting an actual phone call. You can use text messages as well. I personally prefer the phone call method. The other part of this is that certain consumerization of IT have actually made it more difficult. So it's increased the scope. So now you have devices that they don't necessarily trust on the network. And you might have a number of regulatory requirements calling for strong access to certain pieces of information. We built multi—sorry, we built this multi-factor authentication— this active authentication on top of a phone factor platform. It's trusted by thousands of enterprises, it has a wide range of industries it supports, it's authenticating millions of users each month, so it's a good strong platform to build upon. So let's shoot across here, and we will do my demo. Assuming this all works, so let's just close all of this stuff down. We'll go back to my demo graph. And this time I'm going to login with a different user. And this user has the phone factor active authentication required on it. I type my password. We hope my phone rings. Let's see. Like all good demos, it should work. We're calling your phone. It should ring any moment now. It did work once before. You're going to have to believe me here. I might have to do this through interpretative dance if it doesn't work shortly.

Video Details

Duration: 34 minutes and 34 seconds
Country: United States
Language: English
Genre: None
Views: 8
Posted by: asoboleva99 on Jul 9, 2013

http://channel9.msdn.com/Events/TechEd/NorthAmerica/2013/WAD-B309#fbid=kG7OLm6xV3l

Languages to MT: Fra, Ger, Spa, Bra, Kor, Jpn, Rus, CHT, Ita

Caption and Translate

    Sign In/Register for Dotsub to translate this video.