Cloud Study Notes

Part 1 - Manage Identity and Access
Module 1 - Secure Azure Solutions with AAD

Yes, there are 12 separate sections for the first module. With an intro, try-this exercise, summary and knowledge check, that leaves 8 items to go through for Module 1. There are 5 modules in Part 1.

Unit 2 of 12 - Explore AAD Features

Azure Active Directory comes in four editions—Free, Microsoft 365 Apps, Premium P1, and Premium P2.
Multiple questions can come from this one.

The Premium editions are available through a Microsoft Enterprise Agreement, the Open Volume License Program, and the Cloud Solution Providers program. Azure and Microsoft 365 subscribers can also buy Azure Active Directory Premium P1 and P2 online.

Three things that are common to all four:
Single-sign on, Core Identity and Access Management and B2B Collaboration.
Note that all these things deal with access. No matter what you have in Azure, they want as many people as you want to authorize to be able to access the environment securely (with an account). They want people _using_ the platform.

Directory Objects are restricted to 500,000 for the FREE version only. The other accounts are unlimited. Of course - they're going to limit what they give away for FREE - but don't want to put any restrictions on what you can buy.

The only additional feature for O365 from FREE is the IAM for O365 apps. But that makes sense, right?

All the other features that you learn about will apply to both P1 and P2 ... except for two: Identity Protection and Identity Governance.

So it looks like you can reason out most of the questions on this topic if you just remember the (advanced) _Identity_ features (must have it in the name) are for P2 only.

Unit 3 of 12 - Compare AAD to AD services

This is a very short, but important and powerful page. Note that it doesn't mention any similarities - only differences. I think that would be important.

Because Azure AD is HTTP/HTTPS based, it cannot be queried through LDAP. Instead, Azure AD uses the REST API over HTTP and HTTPS. Because Azure AD is HTTP/HTTPS based, it does not use Kerberos authentication. Instead, it uses HTTP and HTTPS protocols such as SAML, WS-Federation, and OpenID Connect for authentication (and OAuth for authorization). Azure AD includes federation services, and many third-party services (such as Facebook). Azure AD users and groups are created in a flat structure, and there are no Organizational Units (OUs) or Group Policy Objects (GPOs).

I remember when AD first came out and we were all reading up on LDAP to figure out how it worked. And no Kerberos! So basically, if I remember it from before (when I lived in Microsoftie World) - then it relates to on-premise AD. Anything I'm learning new only relates to AAD (for now).

I'm not going down the rabbit hole of digging deep into these yet. I'm sure they will be explained in future sections in detail. If not, I am also reading Modern Authentication with Azure Active Directory for Web Applications to prepare for this test (and bring me up to speed on the topic).

Unit 4 of 12 - Investigate Roles in AAD

This page warrants a closer read:
https://docs.microsoft.com/en-us/learn/modules/azure-active-directory/4-roles-azure-active-directory

The big emphasis is on having a very small number of Global Admins. Global Admins can do everything everywhere so you will want to limit that. But what Microsoft has done here is thoughtfully create a large number of Built-In roles that have permissions over specific functions and are named in ways that are obvious.

This looks to have solved a problem for a lot of people. I remember the battles long ago - where you wanted the Help Desk to be able to fix routine, minor issues - but were afraid to give them too much so they didn't make messes. HD managers always pushing for Admin rights - and Administrators pushing back. You always could make custom roles and give them specific permissions - but who does that? I've never seen a place where they sit down and say, "What does your team do?" and map it to specific permissions. Everyone was always afraid that it wouldn't work because of missing some obscure permission. And once you create the role and they get ONE permissions error, the whole thing "doesn't work" and there's pressure to just put them as Admins. This seems to have solved that problem with really good naming conventions.

One other item of note - is that these specific permissions are not because the users can't be trusted. It was really necessary to limit permissions to limit the damage that is possible with any account. If account credentials are compromised (assume breach philosophy), the amount of damage that could be done is limited. EVEN if you have MFA - accounts can still be compromised. If someone already has your password and knows someone working at a mobile store (or with good social engineering skills)... Simply putting a new sim card in a phone and pointing your phone account at the sim, will put the second factor of your MFA in their hands. So it's best to limit the amount of damage any single account can do to your environment.