Solutions for External Access (part 2 of 3)

By Ashwin Venugopal -

 





To read part 1, please click here
To read part 3, please click here






Properties of an Azure AD B2B User

According to the inviting organization's requirements, a user with an Azure AD B2B collaboration can have anyone of the following account states:
  • State 1- Here, the B2B users can sign in with the help of an Azure AD account that belongs to the invited tenant. The guest user in Azure AD is still created even if the partner organization don't use Azure AD by simply redeeming their invitation and email address verification by Azure AD. This particular arrangement is also known as Just-in-Time (JIT) tenancy or a "viral" tenancy.

  • State 2- This one allows the guest users to sign in with a Microsoft account or a social account like google.com or similar. The invited user's identity can be created as a Microsoft account in the inviting organization's directory during offer redemption. 

  • State 3- It's homed in the host organization's on-premises AD and synced with the host organization's Azure AD. Azure AD Connect can be used to sync the partner accounts to the cloud as Azure AD B2B users with UserType = Guest. 

  • State 4- Homed in the host organization's Azure AD with UserType = Guest and credentials that the host organization manages. 



Key Properties of the Azure AD B2B Collaboration User

UserType

This property represents the relationship of the user as well as the host tenancy and have following two values:
  • Member- It represents an employee of the host organization and a user in the organization's payroll. For example, if a user expects to have access to internal-only sites, then, it is not considered an external collaborator.

  • Guest- It represents a user who isn't considered internal to the company, like an external collaborator, partner, or customer. This user doesn't receive a CEO's internal memo or receive company benefits, etc.

Source

It represents how the user signs in.
  • Invited User- This user has been invited but has not yet redeemed an invitation.

  • External Azure AD- This user is homed in an external organization and authenticates with the help of an Azure AD account that belongs to the other organization. This type of sign-in is similar to State 1.

  • Microsoft Account- As the name suggests, this user is homed in a Microsoft account and authenticates with the Microsoft account as well. This type of sign-in is similar to State 2.

  • Windows Server AD- This user is signed-in from on-premises AD that belongs to this organization. This type of sign-in is similar to State 3.

  • Azure AD- This user authenticates with the help of an Azure AD account that belongs to this organization and this type of sign-in is similar to State 4.  








To read part 1, please click here
To read part 3, please click here

































Comments

Post a Comment

Popular posts from this blog

Deployment (Part 3)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 2, please click  here Microsoft Monitoring Agent (MMA) MMA is used across multiple Microsoft solutions and has undergone a few name changes as its features and functionality have evolved. If it is being considered to be used, then following areas should be covered during a Microsoft Sentinel deployment project: Consider the timelines and the strategy for a migration to AMA (Azure Monitor Agent) before the MMA end-of-life.  Consider the central deployment and management methodology for MMA. Determine which endpoints are in scope for deployment as these affect the log ingestion volume significantly.  Azure Monitor Agent (AMA) Organizations with MMA as the main Microsoft Sentinel agent should start planning the migration to AMA as soon as possible to avoid a rushed migration. One of the main advantages of AMA is the ability to control the log collection policy centrally and apply different policies against different...
Read more

Deployment (Part 1)

By Ashwin Venugopal -
Image
  To read part 2, please click  here To read part 3, please click  here Azure Resources Microsoft Sentinel needs following resources to be created: Subscription (if a dedicated subscription(s) will be used) Resource group(s) Log Analytics workspace(s) Automation rules/playbook Alert rules Workbooks Microsoft Sentinel offers hundreds of alert rules, workbooks, and automation playbook templates along with hunting scripts. The templates can be used to activate/deploy schedule alerts, create customized dashboards, create automation playbooks and perform threat-hunting activities. Generally, once deployed, the resources created have to be adjusted to match the existing environment, configure local credentials, etc. Methods of deployment: Manual- Administrator can manually configures the Microsoft Sentinel resources with the help of Azure portal. Any manual process has the inherent risks of human operator error, lack of compliance with potential change control procedures, and u...
Read more

Deployment (Part 2)

By Ashwin Venugopal -
Image
  To read part 1, please click  here To read part 3, please click  here Microsoft Sentinel Content Hub Content in Microsoft Sentinel includes any of the following types: Data connectors offer log ingestion from different sources into Microsoft Sentinel. Parsers give log formatting/transformation into ASIM formats, supporting usage across various Microsoft Sentinel content types and scenarios. Workbooks provide monitoring, visualization, and interactively with data in Microsoft Sentinel, highlighting meaningful insights for users.  Analytics rules give alerts that point to relevant SOC actions via incidents.  Hunting Queries are used by SOC teams to proactively hunt for threats in Microsoft Sentinel. Notebooks help SOC teams in using advanced hunting features in Jupyter and Azure Notebooks. Watchlists support the ingestion of specific data for enhanced threat detection and reduced alert fatigue.  Playbooks and Azure Logic Apps Custom Connectors provide featu...
Read more