Okta vs Azure AD Identity Provider - The End-User Experience

hello this is Brian Cheatham this is the first to get cloud savvy video blog I don't know if that's what you call it in the blogging world is a V blog video blog whatever it is anyways this is a video and in this video we're covering octa versus as your ad as an identity provider so what we've done is we've built a lab environment that has both a octa federated domain and an azure ad manage domain and we're gonna look at the different scenarios or what we call activities in this particular blog of you know users doing certain things what it looks like from an octa perspective you federating you know where you're actually logging in through the octa interface and then what it looks like just on the azure ad side to see that tighter integration on the azure ad side of things so let's go ahead and get started so just to kind of set the stage here a little bit I put a just a diagram a Visio diagram together to show you what we have set up in this lab environment so basically we have both octa and we have as your ad connects so if you see off here to the to the right hand side we have as your ad Connect which is synchronizing from a Active Directory domain services this is actually running in Azure so it's a Active Directory domain services running in as your not as your ad and that's our mastered copy and we're synchronizing those objects one way to Azure ad office 365 and then we have octa in the picture - so we have the octa ad agent which does the synchronization and it also does delegated authentication so we have an identity provider here in octa and then we also have an identity provider here in Azure ad so if you notice here we've got an octa sign-in page this is our octave federated domain so anytime you see this domain throughout this demo you know that's an octave federated domain and then we have a as your ad managed domain what we call an azure ad manage domains so that's our this domain here so and then we'll see the regular sign-on page so notice we don't have to go through any third party for authentication we can actually go directly to this this as your ad component as an IDP I probably should have put IDP under here rather than just software-as-a-service but I did identify it as identity as a service that is what as your ad premium provides you and that comes with the Microsoft EMS III so let's move on to the activities that we're gonna cover in this particular blog so what we want to do is we want to look at several different activities what we're gonna call activities these are these are in user activities so this is from an end-user perspective we're gonna look at all of these activities from the perspective of a user logging in via an octa federated domain and an azure ad manage domain so we're gonna look at things like the initial sign in to the portal what does that process look like for both trusted and non trusted sign-in so trusted sign-in meaning that we're coming from a corporate network we're coming from a a pad address or some sort of external IP that that octo and/or azure ad recognizes a corporate type of network and then we're gonna look at the out profile creation or configuration and we're gonna look at the risky sign-on from a tor browser there's several other risky sign-on type of scenarios that are out there but just for simulating the the risky sign-on and how to block that we're gonna use a tor browser and then finally we'll look at the azure mobile application management enrollment and sign-in so we're gonna look at a mobile device and how that process works through both an acht a federated user and an azure ad domain join i'm sorry as your ad manage domain and then we're going to look at restricting applications to corporate own devices so that's where we get into as your domain join or as your what they call as your ad join and then as your at hybrid as your ad domain join so actually synchronizing those computer objects that are added to a domain to as your ad that's an azure ad type of scenario that's something that octave doesn't support so we're gonna take a look and at all those different activities and let's go ahead and get started and take a look at our first activity so the first activity is the initial sign in so signing in to the applications portal for octa and for azure ad users so we have two different examples here so we're going to start with our first demo and this is going to be the sign-in process for a the initial sign in for an octa user this is an octave federated domain so I'm going to launch an incognito web browser and I'm actually going to type in a URL that I have for this octa this octa instance I could actually customize this if I wanted to to have my own customized domain name here okay so here's our first sign-in page and in this case I have a user named Orlando octa very creative with the naming here even with the domain name itself so this is a scenario where I have an on-premises user that is synchronized using an octa agent out to octa and now I'm signing into the cloud octa system it's the first time that I'm logging in so I need to set some additional parameters here I'm not going to specify a secondary email address these favorite food would just say liver I actually don't really mind liver but you know I'm just typing in something to have it I definitely want to add a phone number here so a code was sent to my cell phone I'm going to type in that code if I can get the right dialogue here and I lost the code seven seven nine five three seven here we go verify okay so I added my phone successfully now wants me to select a picture we'll just stick with the top picture here and once they create my account okay so now I'm looking at the octa Applications portal notice how I have all of my office apps these are automatically provisioned for me in the acht interface so both octa and Azure have this capability so octa in Microsoft my apps portal is what we call it so we're gonna look at that in the next example so for now I'm just gonna log out and we will move on to the next scenario our next scenario is the initial sign-in to the Microsoft my apps portal so this is going to be a different user and a different domain for that matter that is not federated with octa it's actually managed by Azure ad so the link for my apps is actually my apps Microsoft com there's my sign-in page and my as your ad user is Adam as your another creative name for you enter the password and again this is an on-premises user that has been synchronized to as your ad via as your ad connect so not the Oktay Junt in this case but via azure ad Connect okay notice how it didn't ask me to set up my multi-factor authentication or or actually I really didn't set up multi-factor authentication I just added a phone number so there are a few more steps to configuring that profile but if I wanted to once I logged in here I could actually come in and in update my profile information so a little bit different than the octa process but we will see here how I have the same type of look and feel the octa interface as far as the portal is concerned is a little bit more mature than what the my apps portal offers you can group some of these applications into into different groups kinda like you can on like an iPhone or something like that so these features were actually coming as part of my apps in future releases so Microsoft is diligently working to to increase the functionality of this but as you can see these are very similar to the two it just to me this looks cleaner just because this is a microsoft application sitting within a Microsoft portal okay so that's the difference between the octa applications portal and the my UPS portal with Microsoft so I'm gonna sign out here and we're gonna close this browser and go back to our presentation here and our next step is to look at a trusted outlook web app so we're signing in to office 365 outlook on the web from a trusted network so this would be a network where we're in in a corporate facility we're within a corporate boundary that is protected by a firewall or deemed safe to our corporation our first test is going to be with an octave federated user so we're actually going to sign in directly to you Outlook top office comm I'm gonna watch a incognito window again and we'll go directly to Outlook office comm waa there's my initial sign-in page so this is the octa scenario so we're gonna log in as the octa user here yep my creative names are getting the best of me they're not really that creative notice how I get redirected to the Sun on page so because it's federated the sign-in page for office 365 is directing me back to octave for sign-in now I'm not an octave octa certified consultant so they don't claim to be one this is a lab environment that I set up just to understand the differences between the two but one of the things that I've noticed here is that I have to type in this username a second time now there's probably a way to preserve that via the session a cookie or maybe even a a a fancy way with a URL or maybe the way the user accesses this but in this case I'm having to type this in again and this is the first time I'm signing into this mailbox so I'm presented with this nice little wizard I'll just leave it at specific time I'll just select something random here let's go with crayons I'm gonna add a signature right now we just want to get logged in and we want to see our our mailbox and maybe send a message so let's go okay come in here and I'm just going to send a quick message I'm gonna send it actually to myself and there's my message that came through okay so that's the octa experience so it's a federated scenario we go to the sign-in page for office 365 or redirected back to octave for sign-in we sign in to octa and then it's a federated it's actually called WS Fed is the type of authentication that we're using for single sign-on to office 365 so we're not actually passing any kind of password or anything like that it's a token exchange so let's sign out and let's look at our as your ad scenario advance our slide here one so this is the azure ad user sign in to Outlook Web App from a trusted network so let's launch a incognito window and do the same thing go to outlook office calm so a and in this case I'm using atom as your enter my password notice how I didn't get redirected anywhere I'm signing into the same system it's all the same back in so notice how we weren't redirected yeah as your ad is actually the underlying directory for office 365 so we're actually signing in to that directory that office 365 sits on top of so let's go through our initial wizard here that's interesting how it looks a little different this time let that finish alright and we'll do the same thing and just send us test message just to make sure everything is working properly there's that majeure and there we go so that's basically our difference between the octa sign-in process and the azure ad so for octave really the difference is is that we're federated for the domain that we've selected so we get redirected to octa for authentication once we're authenticated then it's a single sign-on process via WS fed to office 365 whereas as your ad we're just signed in because has your ad is the underlying or the foundational directory for office 365 so let's move on to the next activity so now we're talking about a non trusted login so a non trusted network somewhere outside the corporate network maybe you're at a Starbucks maybe you're you're somewhere else you know maybe you're at a customer you know customers conference room on guest Wi-Fi somewhere so how can we use per application what we call application conditions to force enforce multi-factor authentication so for octa those are called sign-on policies and they're configured per application for Azure ad we call those conditional access and we're also going to talk about what would happen if we had an octa user which was included in both so it's an octa user that's included in a sign-on policy as well as a conditional access policy in Azure ad so we'll see the combined experience between the octa sign-in policy and the Azure conditional access just to show you how these technologies can step on each other if you're not careful so let's move to the first scenario which is going to be our octave federated user signing into OWA from an entre stood network so I'm basically simulating this just by putting the user in a group typically this would be done with a what we call a trusted network setting so whatever the whatever the pad address is on your outbound router the external address so the address that is actually exposed to office 365 and or octa depending on which identity provider you're using so we sign into our octave user first this is where we're getting redirected to the octa sign-in page I'm having to type this in again I keep forgetting my my very creative domain name I notice what happens here at this point it recognizes that I'm a member of a certain group so it's sending me to the multi-factor authentication setup because I've never used multi-factor authentication before so we're just going to do SMS authentication this in the code make sure I've got this in the right area here verify and sign in and we're logged in and it's interesting that it's making me go through this again okay and there's our original message that we sit that kind of shows you the experience with multi-factor authentication on the octa side of things so how about on the azure ad side close out advance the slide in this case we're looking at an azure ad user sign-in to Outlook Web App from a non trusted network so we're using conditional access for this so this is a per application setting we could actually apply this to multiple applications if we wanted if we want it to and our Adam has your oops that's the wrong domain name I'm gonna get this right I'm sure everybody out there who's a fast typer is like wow this guy really types though you're right I do and here's the multi-factor sign in for Azure ad so I'm going to set up now direct it to a different page here not as clean as the octave process to be honest with you but it still gets the job done so my phone number in here and I'm such a good typer as everybody can tell so far I'm gonna send it to Xcode I could have it call me if I wanted I could also use an Authenticator app just like I can do with octa so very similar functionality between the two and type in my verification code let's see two okay verification was successful so click done okay multi-factor authentication was done and now we're signing into Outlook and it was interesting that I got forwarded back through the wizard at the beginning I'm wondering if it saw it coming from a different maybe so I come in from a different IP or something on the octa side of things as far as sign-in was concerned that's very interesting that I had to go through that process a second time on the octa side so that's the azure ad experience so let's sign out of this now let's look at an example where a user could potentially be assigned both it's an octave federated user that's a that's basically added to a sign on policy and conditional access for the same application that would require a multi-factor authentication I'm going to launch an incognito window [Music] same thing I log in to Outlook I probably should make a bookmark for this but you guys already know I can't type so I think we're good there my user actually copied this one because I couldn't remember off the top of my head what it was so I basically have a user that's Joe octa Azure so there it's it's actually assigned to both so I'm gonna say next it's gonna take me to my sign-in page same thing just paste that in here it's the Joe octa as your okay it's the first time that I've signed in so I'll go ahead and do this the same thing that we had before just so I don't forget add my same phone number send code verify that looks good set a picture we'll just set the same picture and off we go and notice how it says okay you're trying to sign in to an application that requires multi-factor authentication so in this case I'm gonna set up SMS authentication I just need to send the code because I've already provided that's interesting oh I got to provide the phone number see not only do I not know how to type I don't know how to read okay type in the code and let's see what happens here so I'm verifying this and this is gonna send me now to office 365 and look at this because I'm also involved in conditional access on the Azure ad side I also have to provide multi-factor for for the Azure ad side so this is what can happen in these environments where you mix these technologies Microsoft can do all of this for you so just kind of keep that in mind when when you're looking at these scenarios as your ad conditional access actually has a lot of options more options compared to what the octa sign-in policy provides you so if you are an octave federated user or you have an octave federated domain you want to use conditional access you can use it this way just make sure that you're not stepping on top of your your different policies aren't stepping on top of each other so I'm verifying so I went through two verification processes at this point and we're done yes and finally I'm signed in to my mailbox and it's the first time sign-on I'll go ahead and go through this real quick just so we have it I don't think we use this the user in another demo actually you know what we might use it later on for another scenario just show you how these technologies can step on top of each other okay so let's sign out here and move on to the next activity so let's move on to our next activity which will be outlook profile configuration so let's look at the profile configuration for an octave federated user and one for an azure ad managed user so our first scenario is an octave federated user we're creating an outlook profile for an octave federated user smile launch a VM here that I have hosted integer and I just have this is just a workstation scenario it's not joined to a domain or anything like that so it's just a it's just a workstation login so I have a local user set up on this Windows 10 system for this user okay okay so we launched Outlook we're gonna type in our email address our federated email address and watch what happens here we're going to exchange online to see hey where is this account going to authenticate against since it's federated it's going to go back to octa and this is where we should see the octa sign-in page pop up and there's our octa sign-in page i can't believe i'm remembering these all these user names or not remembering them okay so it is a multi-factor scenario again because I'm simulating that with a group I haven't removed it from that group so I'm going to send the code to my cell phone so that's signing me in so look here it's asking me do I want to add this account to Windows so what this basically means is do I want to add the token that I've generated or the credential for that token I guess you'd say to the local credential manager in Windows so we can still do things like remember password for Outlook in a workgroup scenario so I'm not going to setup a mobile phone at this time I'm just going to click OK and it will see that we are now logged in to Outlook okay so this is the first time that we've launched Outlook or any office application for that matter so we need to activate so let's see what the activation process would be like on the octa side and type in my email address is a it's a subscription-based license so we need to authenticate notice how it's sending me back through the octopress for sign-in and still sending me back through multi-factor because that's how I have it configured on the octa side for this particular application and this should complete my activation process for office okay so that is our sign-in process over our first time setup for an Outlook profile for an octave federated user so now let's look at the scenario where we have an azure ad user and as your ad managed user signing in to a workgroup scenario and setting up an outlet profile alright this is an azure ad user creating an Outlook profile for the first time and this is a workgroup scenario logging into a Azure virtual machine that's running Windows 10 and I just have any local user for Adam as you're okay there's our desktop let the spinner stop spinning there we go getting my domains mixed up again as usual so this is the account name email address these should match anywhere possible to avoid user and user confusion and notice what happens here I don't get redirected it's a kind of an integrated experience the dialog that pops appears actually a Windows 10 dialog it's not a web page or anything like that that is asking me for authentication it's it's built into Windows so let's type in our office I'm sorry our ver yeah our office 365 credentials we're logging into Azure ad at this point and this is interesting interesting I must have set a different default because it's actually calling me for multi-factor so I'm going to go ahead and complete this here on my phone you have to press pound and there you go and also I get the same same question if I want to add this account to Windows so again all we're doing here is we're just adding the the token that was generated the the access token as well as a refresh token I believe it's the Refresh token that actually gets added to the local credential manager so that that credential is actually good or that token is actually good for 14 days and we'll talk about that a little bit more in the upcoming demo so it's registering the device that just means that it's incrementing the count because you get up to five copies of office that you can install on your different systems as part of the subscription-based license okay we're not setting up a mobile device we're just saying okay here I probably won't get asked for activation in this case because I've already activated this copy with another user so we went through that process on the octa side but it be something similar on this side I have a feeling though that the locally cached credentials would actually keep us from having to type anything in because it is an integrated experience but either way if we were asked for authentication it would be much the same process that we just went through so that is your azure ad outlook profile creation from a workstation computer so let's move on to the next activity which is risky sign-on so we want to sign in via octa or an octave via an octave federated user from a risky sign-on type of scenario in this case we're gonna use a tor web browser just because this is an easy scenario to demonstrate other risky sign ons would be impossible travel scenarios you log in in the States and then you try and log in and I'll show you five minutes later other things would be leaked credentials to the dark web Microsoft has a cybersecurity team that is cross-referencing that information for you to where if any way shape or form your credentials or your users credentials are leaked they're making those Crofts references to the accounts that you have within Azure ad so I'm not an octa expert I'm not an octave certified consultant I don't know how the octave back-end works with risky sign-on but this is one of the advantages as I see it from my perspective with using Azure ad over octa so we're gonna look at just the base configuration for octa and then we're gonna look at the base configuration for Azure ad engaging that risky sign-on type of conditional access so let's start with our octa scenario so this demo is an octave federated user with a risky sign-on attempt to office 365 or Outlook Web App via a tor web browser so let's take a look here launch our VM that we have in has your and I have a tor browser installed here so I'm going to launch the tor browser so now we are in a tor browser which is basically masking the IP we call it an anonymous IP scenario we're gonna log in to let's just go to Outlook crease our real-estate a little bit here sorry for the refresh delay the as your emi selected is one of the lower tiered VMS so we're gonna start with our octa user as soon as our refresh is done okay and this process is taking me to my organization sign-in page which is going to be octa there's our octave sign-in page so let's sign in here write password at this point we should get redirected to provide our multi-factor authentication code just send code wait for it to come through on my mobile phone and there we go notice what happens here I'm automatically redirected to office 365 and there you go I actually logged in via a tor web browser so I'm coming from an anonymous IP logging in to office 365 via octa so I actually that sign in was possible for me and again there is probably a way for octa to lock down this type of activity on their back-end I'm just using again the base configuration for octa in my lab environment so let's look and see what happens with an azure ad risky sign-on attempt where we're actually telling a conditional access policy that we do not want to allow that we want to block that okay so for this demo the azure ad user it's a risky sign-on to office 365 in this case we're using outlook on the web using a tor web browser so let's launch our VM with the tor browser okay so this time I'm going to leave the tor browser in this kind of UNMIK summize state because it seemed like the Refresh was a little better so let's go to Outlook office.com slash OWA okay here's our sign-in page and this time we're logging in as Adam measures should prompt us per our password I'm sorry for the delays with this again this is a one of the lower tiered as your VMs there's my password because I have two different conditional access policies I have one for multi-factor require multi-factor went on a non trusted network and I have one for the sign in the risky sign-in criteria I'm automatically blocked so your sign in was successful but it does not meet the criteria to access this resource so the conditional access policy itself and as your ad is blocking me from doing this so it's kind of the difference between the octave experience and the Azure ad experience for a risky sign-on now the Tor web browser is probably something that octa cannot can address again on their back-end but you also have other things with risky sign-on that are advantages for azure ad such as the the impossible travel scenario there's also the Leech credentials there's a whole list of risky sign-on attempts that azure ad will detect automatically identity protection policy or in a conditional access policy so let's move on to the next scenario so for the final activity we want to look at restricting applications to corporate devices so say we want to restrict sharepoint online to only corporate devices you might want to restrict other types of applications based upon the device and specifically when we say corporate devices we're talking about a device that is azure ad joined Windows 10 has a new feature called azure ad join so joined to the domain and marked as compliant in Intune or consider hybrid as your ad domain joined which are computers that are members of on-premises Active Directory domains which are synchronized the computer objects in certificates for those computer objects are actually synchronized to Azure ad so you can use them in conditional access so Microsoft Intune and azure ad conditional access allow for this type of configuration let's compare the octave federated experience with an azure ad experience and on the octave federated side of things we're not going to use conditional access we're going to show you just what octa is limited to with their sign and policies per application whereas on the azure ad side of things we're going to show you the conditional access portion which engages that functionality to look for things like as your ad domain join or as your hybrid as your ad domain joined okay so let's take a look at the demo this is octave federated user accessing sharepoint online from a non corporate device so this is something that we don't want to happen right we want to restrict users from accessing sharepoint online so we're looking at only octave functionality here the only thing that's engaging at all on the azure ad side of things is the token exchange or the access to the SAS application SharePoint Online and office 365 so let's take a look at our demo here punch our Windows 10 virtual machine as our octa user okay I'm gonna go straight to the web and I'm going to type in the SharePoint URL so notice how the sign on-screen here is a little bit different this time around because remember when we connected when we configured our outlook profile before we actually connected that account to Windows so octa in this case is really nothing more than an authentication point we actually have a refresh token in the background that's leveraged with Azure ad but for the purposes of this demo we're trying to demonstrate how we can restrict access to a certain application so if you notice here once I click I'm actually taken directly into SharePoint Online and this is something that we don't want as part of our simulated corporate policy so let's take a look at how as your ad handles this without any kind of Aqsa involvement so this is the azure ad user accessing sharepoint online from a non corporate device so really the same scenario we just looked at but this time around we're using all Microsoft functionality so we're gonna launch our Windows 10 VM as our azure user and here we go with my typing skills again and again we're gonna go straight to the web browser and I'm gonna try to access SharePoint Online and right away I'm told that I can't do this your department is ensuring that this device is up-to-date with your organization's corporate policies so this is an example of device compliance this could also be an example of a we have to have a domain join machine or we have to have an azure ad joined machine so this is one of those advantages of using Azure ad conditional access over octave sign-in policy for applications we really have the capability of drilling down to the device level and because everything is of Microsoft technology it integrates a lot better as far as you know controlling what we can access per application on the type of device that we're using what group were in what we're location were coming from so we have a lot more capabilities on the conditional access side of things with Azure ad and Microsoft continues to add to this functionality all right in summary we covered quite a bit in this blog video so we covered the different scenarios octa federated domain or an azure ad managed domain the initial sign in to the portal we saw how we were redirected to octa to sign in so anytime that we're signing in to that federated domain we are redirected to octa trusted and non trusted sign into a web application we used Outlook Web App in this case so trusted and non trusted from an octave federated domain and from an azure ad domain so you got to see that process where you're redirected to octa again in that case outlook profile configuration we saw has a little bit more of an integrated experience on the Microsoft side but not much difference between the two you're just redirected to an octa then' occation page to off indicate against azure ad via WS Federation and then risky sign-on we noticed how octa didn't pick that up by default and just by configuring and conditional access policy on the azure ad side of things the tor browser scenario was actually picked up so octa probably has a way to address this but Microsoft has other things that it does with risky sign-on - we talked about the impossible travel scenario we talked about the anonymous IP which is the tor browser delete credentials that's a big one - right the cyber security team from Microsoft actually looking for credentials on the dark web and correlating those to the ones that are in Azure ad so that's something to think about whenever you're making a decision between octa and Azure ad as it didn't as an identity provider so it's something you can definitely bring up with your ACTA representative to see if they have anything that's coming out on their roadmap again I'm not an octa expert or I'm not certified or anything like that I'm just doing a comparison between the two and then finally the restricting of applications to corporate owned devices so we showed you how we can actually do that with we have more capabilities around the azure ad side of things for that so thank you so much for joining this is the closeout of this blog and there will be more to come I really appreciate everybody hanging in there with me on this blog if you have any questions or anything like that please comment please let me know if there's anything else you would like to see in a video blog any kind of scenario that you have out there that you would like me to lab out and demonstrate for you and thank you again this is brian with get cloud savvy signing off

Channel: Brian Cheatham

Views: 25,271

Keywords: getcloudsavvy

Id: L5Ks5__XABs

Length: 48min 24sec (2904 seconds)

Published: Sun Dec 17 2017