AAD Security made easy: Check your Azure AD Security with One-Liner (AZSK.AAD)

You can now scan your AAD tenant security posture with one-liner, and get really detailed and comprehensive report of the results

https://github.com/azsk/DevOpsKit-docs/blob/master/ReleaseNotes/LatestReleaseNotes.md

Install-Module AzSK.AAD -Scope CurrentUser -AllowClobber 
Import-Module AzSK.AAD 
Get-AzSKAADSecurityStatusTenant 
<#Controls available

The following controls are available from the get go!

ControlIDDescription
AAD_Tenant_RBAC_Grant_Limited_Access_To_GuestsGuests must not be granted full access to the directory
AAD_Tenant_RBAC_Dont_Permit_Guests_To_Invite_GuestsGuests must not be allowed to invite other guests
AAD_Tenant_MFA_Required_For_AdminsAdmins must use baseline MFA policy
AAD_Tenant_Apps_Dont_Allow_Users_To_Create_AppsDo not permit users to create apps in tenant
AAD_Tenant_RBAC_Dont_Allow_Users_To_Invite_GuestsDo not permit users to invite guests to the tenant
AAD_Tenant_Misc_Set_Security_Contact_InfoSecurity compliance notification phone and email must be set
AAD_Tenant_Device_Require_MFA_For_JoinEnable ’require MFA’ for joining devices to tenant
AAD_Tenant_Device_Set_Max_Per_User_LimitSet a max device limit for users in the tenant
AAD_Tenant_MFA_Review_Bypassed_UsersReview list of current ’MFA-bypassed’ users in the tenant
AAD_Tenant_MFA_Allow_Users_To_Notify_About_FraudAllow users to send notifications about possible fraud
AAD_Tenant_Apps_Regulate_Data_Access_ApprovalDo not allow users to approve tenant data access for external apps
AAD_Tenant_RBAC_Keep_Min_Global_AdminsInclude at least three members in global admin role
AAD_Tenant_RBAC_Dont_Have_Guests_As_Global_AdminsGuest users must not be made members of global admin role
AAD_Tenant_AuthN_Use_Custom_Banned_PasswordsEnsure that custom banned passwords list is configured for use
AAD_Tenant_AuthN_Enforce_Banned_Passwords_OnPremEnsure that banned password check is enabled on-prem and set to ’Enforce’ level
AAD_Tenant_Privacy_Configure_Valid_Privacy_ContactEnsure that tenant-wide privacy contact email is set to a valid (current) non-guest user
AAD_Tenant_Privacy_Configure_Valid_Privacy_StatementEnsure that a privacy statement is configured and points to a valid URL
AAD_Application_Remove_Test_Demo_AppsOld test/demo apps should be removed from the tenant
AAD_Application_ReturnURLs_Use_HTTPSAll return URLs configured for an application must be HTTPS endpoints
AAD_Application_Review_Orphaned_AppsDo not permit orphaned apps (i.e., apps with no owners) in the tenant
AAD_Application_Require_FTE_OwnerAt least one of the owners of an app must be an FTE
AAD_Application_HomePage_Use_HTTPSThe home page URL for an application must be an HTTPS endpoint
AAD_Application_LogoutURLs_Use_HTTPSThe logout URL configured for an application must be an HTTPS endpoint
AAD_Application_Must_Have_Privacy_DisclosureAll enterprise apps must use a privacy disclosure statement
AAD_Application_Must_Restrict_To_TenantEnterprise (line of business) apps should be tenant scope only
AAD_Application_Minimize_Resource_Access_RequestedApps should request the least permissions needed to various resources
AAD_ServicePrincipal_Use_Cert_CredentialsSPNs must not use password creds – use cert creds instead
AAD_ServicePrincipal_Review_Legacy_SPNSPNs of type legacy should be carefully reviewed
AAD_ServicePrincipal_Check_Key_ExpirySPN key credentials should be renewed before expiry
AAD_Device_Review_Stale_DevicesReview and remove stale devices from the directory
AAD_User_DirSync_Setting_Should_Match_TenantA user’s dirsync-enabled setting must match the tenant level setting
AAD_User_Do_Not_Disable_Password_ExpirationDo not disable password expiration policy for users
AAD_User_Do_Not_Disable_Strong_PasswordDo not disable strong password policy for users
AAD_Group_Use_Security_EnabledAll AAD groups must be security enabled (TBD)
AAD_Group_Require_FTE_OwnerGroup must have at least one non-guest (native) owner

Azure AD Directories and B2B user decision matrix – One-slider

Click for larger version

Ever pondered on how to decide about B2B Account Types? One thing is for sure, If you’re enterprise org, you’re better of having multiple partner account types, because it’s not one size fits all type scenario

  • The matrix makes clear separation between collaboration only, and administrative tasks performing partners
    • This is based on multiple recommendations, but is based mostly on the following Azure Subscription recommendation from Azure Secure DevOps Kit. (Obviously if the account is also homed in Azure AD and you’ve setup B2B conditional access policy for guests, you might consider yourself covered to some extent…)
link
  • Where authentication happens is important part on the picture, and is the main deciding factor on users home directory

Other considerations

  • Licensing is separate discussion… Anyway key takeaway is, that the 1:5 ratio licensing works in the background = If you assign license to guest user its one license gone, and doesn’t benefit from the B2B-Licensing
  • The picture doesn’t consider SSO between the host tenant and its IDP, as it basically wouldn’t add anything to the picture (unless you’d ”multiplex” multiple claims provider against single AD FS, and then via claims pipeline transformations emit claims for the guest type users in you’re tenant)
  • More detailed explanation of all the scenarios (minus the flowchart) can be found here Properties of an Azure Active Directory B2B collaboration user

Please don’t hesitate to comment or send feedback, if you notice any errors or wrong assumptions in the flowchart

”MOAR STUFF”

If you want to check B2B deep diver on user types and authn/authz, then check: https://securecloud.blog/2019/05/06/deep-diver-azure-ad-b2b/

Click for bigger picture