All Microsoft Identity SC-300 certification exam dumps, study guide, training courses are Prepared by industry experts. PrepAway's ETE files povide the SC-300 Microsoft Identity and Access Administrator practice test questions and answers & exam dumps, study guide and training courses help you study and pass hassle-free!

External Identities

3. Bulk Invite External Users

So we should also talk about the concept of bulk operations, which we really haven't looked at. So we do have the option of creating users, whether they are regular members or external members, in bulk. We also have the ability to delete bulk users and download these records as a CSV file. If you go into one of these like bulkinvite, you're going to see that there's actually a CSV template that you can follow, and that you can then create your dozens, hundreds, or however many external users that you have using the template. Now, I actually used the template when I was creating these students and teachers.

So I just created a fairly lengthy title, but I just created simple rows of names, email addresses, passwords, and blocked sign-in, which is the enabled or disabled status, and left all the other fields blank. So you can see this was a very simplistic way of bulk creating twelve accounts, and I did that a few lessons ago. But yeah, you do have the option of bulk creating users using the template, filling it out, and even deleting users using a very similar template, or downloading a copy of your users as well in CSV format. And maybe it goes without saying, but there are obviously programmable ways that you can invite external users.

For instance, there are PowerShell script commands so you can use the new Azure AD Msinvitation commandlet to bulk create users. So let's say you have these users; they're not in CSV format, and you don't want to modify them to be in that format, but you can write a little script to go through a database, to go through a list of something, and create these users. So there are definitely programmatic ways as well as CSV template ways of creating users.

4. Manage External Users

So now, in terms of managing these users, you have a lot of the same features and functions as you do when managing regular members. So we have our test user, who is a guest, clearly marked. And if we go into them, we see all of the same sort of management functions right within the Azure ad here.

We can reset their passwords, log them out of sessions, and delete their accounts right from here. We can see records of when they've logged in and the last time that they logged in. I can go into this report. I can see what they've done during the MyApplications, which we saw as part of this course. We can put them into groups if they're students or teachers in our case and assign additional applications to them. We've already got the Adobe one for now. So basically, we've got all of the same management stuff that we do for a full user. Now, they can't obviously login to your on-premises active directory. These external users are not pushed into your organization.

That means they can't log into Windows or any of your devices that are managed by on-premises Active Directory. But beyond that, they have the same powers as any other member of your organisation as you assign them, because they have nothing as we saw you log in. It's a blank screen. They have nothing until you assign it to them. We can even assign them management and administrative powers within Azure ad.So if I wanted this person to be in say, a customer service support type role, So service desk if there's a help desk or service desk Yeah, help desk administrator. And so we could certainly assign them the ability to do things within our organisation again, similar to regular members. So that's basically how you manage users. And as we saw, you can always delete users in bulk if you wish. So you can download all your users, remove all the ones that are guest users, upload them in bulk, perform a delete operation, etc.

5. B2C Social Media Users

So far, we've seen how we can basically enable external users by manually inviting them into your application. And that's more ideal for users who you personally know and who are partners, business partners, or working for partners. But what about your end users? About your customers who can just find you in a search engine, click onto a search result, go to your website, and would like to register, not using a unique account for you but using one of their social media accounts or one of their existing accounts.

Let's talk about how to use BtoC or social media users. So if we go back to your tenant's external identities and we look at this All Identity Providers tab, we can see that by default, we've been given three types of identification. One is Azure Active Directory. So that's just the default authentication. We have users on the users tab, and so AzureAd is managing the user ID and password, and if I click it, there's really nothing to manage. That's an identity provider, and I don't even think you can remove it. Right. The second option you have is a Microsoft account. So a person who's already got a Microsoft account—Outlook, Hotmail Live.com—all of those Microsoft domains can be invited by email, and they sign in and basically don't require it's treated as a social media account. In this particular case, the third option is a bit of a surprise, and that is that guest users can sign in using an email passcode.

And as I click it, I can see that I can actually turn that part off. So for users who don't already have an Azure account, they can sign in without creating an account. And so every time they log in, they're going to be sent an email, and they click a link on the email. This is sometimes called the magic button in some other magic links in some other systems where basically there is no password and you just always have to go to your email account and click on a link. And as you can see, that option is enabled, and I can have it enabled today, a couple of months into the future, or I can just disable it. So this is enabled starting October 2021 in this particular account. Now we can see up here at the top that there are three other options that are not turned on by default. One is that I can allow Google authentication. So if somebody has a Google account, then they can sign into their Google account, and they don't need to create an Azure Active Directory account or use one of their Microsoft accounts. As you can see, there is a system of going to Google, creating an application in the Google system, getting a client ID and secret for that application, and that basically registers your application in Google as a social identity provider and sets up the trust relationship. Facebook has a very similar system. You can basically go to Facebook and get an ID and a secret.

And you can allow people to use their Facebook credentials to log into your applications and have the system identify who they are. The third option is more of a generic option, which is basically either the SAML protocol or the WS Fed standard. Now, SAM'L stands for Security Assertion Markup Language, and it's an open standard that allows identity providers to pass authorization, secrets, and credentials between different websites. The WS Federation language is a very similar protocol, similar to Sam'l, but this is a WS WebServices standard for the Federation of Identity. Federation means you're relying on Entrust, an external identity provider external to Azure Active Directory. And so if we had our own authentication provider provided by a third party, as long as they support one of these standards, then we could set this up for Azure and pass your security credentials to the third party.

And because it trusts the third party, get the token back and say, "Yes, this person has been authenticated by this third party." So let's say that you want to use LinkedIn as your sign-in provider. So your application is perfectly targeted to users of LinkedIn. And so you think that 100% of your end users will have a LinkedIn account. Then you can set that up manually using this Sam'l WS Fed set up. LinkedIn has a developer website called Developer LinkedIn.com. You have to create an app within there, and then that app will be given credentials that can be used to feed into this type of domain. And so you can add LinkedIn, Twitter, or any of these other third-party providers to your Azure Active Directory. Again, users can log in using those credentials, which are not managed by Azure Active Directory. Then you can enable that for your own applications. and that's all dependent on your requirements. You don't have to do it, but it's certainly available to you. And those are called external identity providers.

Hybrid Identity

1. Introduction to Hybrid Identity

So in this video, we're going to talk about the next section of the course, which is "Implement and Manage Hybrid Identity." Now, hybrid identity, in the context of Microsoft Azure, is the amalgamation of your on-premises identity. solution with Microsoft Azure. So you might have a Windows Active Directory server installed on your premises, managing your corporate network, your sign-ins from devices, both users and devices, and other objects within your network. And then the concept is that you can synchronise that with the cloud using Azure Active Directory and Azure Active Directory Connect. So in this section of the course, we're going to go through these concepts and actually demonstrate to you synchronising an Azure Active Directory on premises with Microsoft Azure.

So we're going to go through a number of terms here. We can see this in the requirements. Azure Active Directory Connect password has synchronisation pass through authentication, seamless, single sign on Federation, and AD Connect Healthand how to troubleshoot synchronisation errors. So the first concept is Azure Active Directory Connect. So this is an agent that you install inside your network that actually synchronises your on-premises Active Directory with the cloud. And so you can choose users primarily who then also have accounts within Azure Active Directory.

And Ad Connect runs on a regular schedule and keeps those two sources synchronized. So in fact, the on-premises ad is the primary ad. It's the one that controls the data we used to call the master. And then the Azure ad is just synchronised with that. And any changes that happen on-premises get pushed to the cloud. So it says it synchronises identities primarily. Now, there is a concept called a source anchor, and that is an ID field that is going to uniquely identify an object. And you can then map it with the cloud. So it's not the email address or some other field. It's an immutable ID that is the unique identifier for every object in your online ad.

And so when you're dealing with what's called a "single forest," where it's just one cluster of machines that's managing your Active Directory, then you can use something like an employee ID, which you might have and which is unique, or it's a globally unique identifier that Microsoft provides. And what you then need to do is verify what's called a "routable domain." So you're going to, as we added a custom domain to Azure Active Directory, want to make sure that when you're synchronising to on premises, you've got something that's definitely routeable. You're able to get to it from Azure AD Connect. So the next concept here is what's called password hash synchronization. And so when the on-premises ad is pushing the identities into the cloud, it's not actually pushing the actual passwords. I mean, that would be a security issue nonetheless. But what it's doing is pushing the hashes.

So there's a one-way function that takes the passwords and stores them as hashes. And then, when someone tries to log in, you hash that login field and compare the hashes together. And then that's how you verify their identity. So with password hash synchronization, what you're doing is pushing the passwords into the cloud. And then from that point on, anyone who logs into an application in the cloud, like Office 365 or your own applications, or any of these enterprise applications, doesn't have to go on premises to check the password. Everything is done on the cloud. So that's how we're able to do the logins entirely in the cloud, which is through a process called password hash synchronization. And that's probably the default setup or the way that you want to do it, unless you need to do something like pass-through authentication or federation. There are other ways to do it, but let's say the first way is the password hash synchronization. Now the other way to do it is through passthrough authentication. The concept here is that when someone logs into their account in the cloud, be it Office 365 or any of these enterprise apps, that login is actually passed through your firewall into your on-premises environment. And that on-premises Active Directory is the one that does the checks. So even though the identities are synchronized, the login has to be verified by the on-premises Active Directory.

That means that the connection between Azure and your premises has to be active. That means that there are no network errors or any other kind of downtime on your premises that's going to bring your public cloud applications down as well. So that is an alternative way of doing this, which is called pass-through authentication. The third way of doing identity management in the cloud in a hybrid fashion is called federation. So federation is the concept of basically delegating your identity to a third party. So we could, for instance, say you have multiple offices and they each have their own authentication methods. So basically, a person tries to log in, and the domain that they're logging in with is not what your primary Active Directory domain is. And so that means we need to know, well, who is the federation server for this domain. And so again, as we can see in this diagram, the sign-in gets redirected to what's called a "proxy," and the proxy then has a connection to a federation server, which does the sign-in.

Now, when we were talking about cloud models such as Google, LinkedIn, or even Microsoft itself, that's kind of a federation model where that authentication is being done by a third party. And so you can set this up so that it's being done by a partner. So let's say you have a trusted partnership with a third-party company, then you can use federation authentication to verify their users with their Active Directory or other authentication server. Now, single sign-on, as we know, is just the concept of using the same credentials in the cloud that you use on premises. And when your password changes in the cloud, then that's automatically reflected in the cloud. And we get that through password hash synchronisation and pass-through authentication. But the seamless nature of single sign-on is that you don't even have to log in because it's already identified that you are an authenticated user on your local machine, and your credentials are passed to the cloud, where we recognise them as valid.

And so that's a seamless single sign-on. And so what this requires, of course, is that we can't use traditional on-premises authentication methods like LDAP through the Internet. We need internet-friendly protocols, and one of those is what's called a "Radius Server." We're not going to demonstrate installing a Radius server in this course, but it is a big concept where if you need to have corporate desktop users' credentials recognised in the cloud, then you need a way of passing those credentials in an internet-friendly manner, and that would be through a Radius server. Now, the last concept that we'll talk about is monitoring this whole setup, because we already identified that as one of the top security concerns.

Now, one thing you don't want is for Auser, who left the company three months ago, to still be able to access their credentials in the cloud because the synchronisation is broken. And so the synchronisation does introduce another vector for attack. And so making sure that that connection is up and notifying people when it isn't is going to be a relatively big factor. And so there's a tool called AAD Connect Health. So AAD Connect is the software that synchronises your on-premises ad with the cloud, and AAD Connect Health is what's going to monitor that connection, make sure that the connection is healthy, and set up a basic alert feature when something is not working. So let's say your synchronisation failed for the last 2 hours. Well, somebody needs to be notified about that. And so you can basically set up Ad Connect Health. Now, since Ad Connect Health is something that's running within the cloud, you can basically set various permissions without using role-based access control, and your administrators and other people in the team can be notified and go in there and see what those types of errors are.

Now, you are going to need various licenses. We're going to see this as a recurring theme in this course and in this exam: what is the licence required? So basic password synchronisation comes with AdConnect and does not require a premium license. When you need Federation Services, you're going to need a P1 license. And those health agents for Ad ConnectSync Health are also requiring licenses. And the last topic of this section has to do with where you're going to find errors, and so various attributes do basically raise certain errors. And so when you're basically doing synchronization, you might find that an identity already exists in the cloud; for instance, the user principal name might already exist. And so it says the attribute must be unique, depending on the type of error you're going to get. You're going to have federation errors with proxies, and so those values are required. You can only have one synchronisation to the single proxy, and the premises security identifier also must be unique. And so these are the types of errors that you're going to see in error logs when you do these synchronizations. So let's demonstrate setting up an Azure Active Directory connection synchronisation and see what that's about.

Microsoft Identity SC-300 practice test questions and answers, training course, study guide are uploaded in ETE Files format by real users. Study and Pass SC-300 Microsoft Identity and Access Administrator certification exam dumps & practice test questions and answers are to help students.