The many faces of permissions in Microsoft 365

[@kbworks_eu]

Thanks for this great session. I still think there are scenarios where you need the advanced permissions but they are limited and agree should be avoided as much as possible!

[@sympraxisc]

We agree! Thanks for watching.

[@juliemturner]

This session went really deep on all the places we can configure permissions for SharePoint and Microsoft Teams and what all these settings mean. We had a lot of fun, and even educated each other while prepping for this session. Was great to see all the interaction live in the chat.

[@MarcDAnderson]

We learned a lot putting it together, eh?

[@juliemturner]

@@MarcDAnderson I think so, this stuff is always changing so unless you're looking at it all the time and even digging in to validate how things work it's really difficult to keep up.

[@kerirusso120]

It is tough to keep up. Who knew there were just as many “places” as “faces” of permissions!

[@MyCopilot-anthonyrhopkins]

*Generated with Microsoft Copilot* 00:00-00:11 | Introduction and Advanced Permissions Warning: The session begins with a humorous warning to Derek about avoiding the Advanced permissions panel in modern permissions, emphasizing simplicity. 00:11-00:25 | Session Kickoff and Theme Introduction: The host announces the start of the session on October 30th, introducing the theme “The Many Faces of Permissions in Microsoft 365” and expressing optimism about the discussion. 00:25-00:54 | Recap of Previous Conversations: The host reflects on the previous Monday’s bifurcated conversation, highlighting the importance of bringing together different viewpoints to help both the audience and the presenters. 00:54-01:07 | Overview of Session Topics: The session will cover the organization’s permission philosophy, modern vs. classic permissions, public vs. private settings, and various policies, including SharePoint premium features. 01:07-01:46 | Detailed Agenda and Humor: The host outlines the detailed agenda, mentioning the focus on policies and adding a humorous note about “policy shaming” Derek, setting a lighthearted tone for the session. 01:46-02:19 | Philosophy of Keeping Permissions Simple: The host emphasizes the philosophy of keeping permissions simple by setting them at the site level and avoiding breaking inheritance, which historically caused issues. 02:19-02:45 | Site-Level Permissions and Historical Context: The discussion continues on the benefits of site-level permissions, contrasting it with historical practices of using a single site for multiple projects, which complicated permissions. 02:45-03:10 | Importance of Separate Sites for Projects: The host explains the importance of creating separate sites for different projects to simplify permissions, as the composition of work units changes over time. 03:10-03:29 | Simplifying Permissions with Separate Sites: By having separate sites for different units of work, permissions become much simpler. Exceptions to this rule should be carefully considered. 03:29-03:56 | Publishing Content in Appropriate Locations: If a project site requires regular sharing, it might be better to publish that content in another location accessible to the relevant group, impacting site topology. 03:56-04:04 | Concerns About Site Sprawl: The host addresses concerns about site sprawl, emphasizing the need for enough sites to represent different units of work effectively. 04:10-04:24 | Historical Context of Site Management: The discussion touches on the challenges of managing multiple site collections in the on-premises days, highlighting the reluctance to create new sites due to management difficulties. 04:24-04:31 | SharePoint Admins’ Perspective: SharePoint admins were hesitant to create new sites, preferring to stick with a single site collection to avoid complexity. 04:31-04:42 | Management Challenges and Subwebs: The conversation continues with the difficulties of managing numerous site collections and the ease of creating subwebs, which end users could easily make. 04:42-04:54 | Evolution of Site Management Practices: The speakers acknowledge that past practices have influenced current approaches, especially for those who migrated from on-premises to online environments. 04:54-05:02 | Shift to Online Architecture: The transition from on-premises to online often involved lifting and shifting the existing architecture, which impacted how sites were managed. 05:02-05:09 | Preference for More Sites: The current preference is for having more sites rather than fewer, as this simplifies permissions management. 05:09-05:16 | Information Architecture Considerations: While more sites are better for permissions, it introduces challenges in naming conventions and namespaces from an information architecture perspective. 05:16-05:24 | Balancing Permissions and Architecture: The need to balance permissions management with other aspects of information architecture is emphasized. 05:24-05:30 | Microsoft 365 Groups as Membership Objects: Microsoft 365 groups are described as membership objects, meant to include only relevant members, such as the IT team. 05:30-05:44 | Importance of Accurate Group Membership: The importance of keeping group memberships accurate is highlighted, as adding members temporarily can lead to issues. 05:44-05:54 | Misuse of Group Memberships: The speakers note that people often break the rule of keeping group memberships accurate by adding members for short-term access. 05:54-06:02 | Reliance on Accurate Memberships: Accurate group memberships are crucial for relying on these groups in various contexts within Microsoft 365. 06:02-06:07 | Ensuring Proper Access: Ensuring that group memberships accurately reflect the intended team is essential for proper access management. 06:14-06:27 | Careful Group Population: Emphasizes the importance of carefully populating Microsoft 365 groups, ensuring only those with ownership rights can change memberships, and reusing these groups effectively. 06:27-06:33 | Sharing Links and Permission Inheritance: Discusses how sharing links can break permission inheritance depending on settings and usage, highlighting the need for user education. 06:33-06:44 | Educating Users on Sharing Links: Stresses the importance of educating users about sharing links to avoid potential issues with permissions, search, and other functionalities. 06:44-06:55 | Advanced Permissions Warning: Reiterates the warning to avoid clicking on Advanced permissions in the modern permissions panel, suggesting adherence to simpler rules. 06:55-07:02 | Alternative to Advanced Permissions: Suggests adding site collection admins directly instead of navigating through Advanced permissions, using Derek’s experience as an example. 07:02-07:14 | Derek’s Use Case: Derek shares his use case for needing to fix permissions, with a humorous note about never living down the incident. 07:14-07:27 | Avoiding Advanced Permissions: Mark advises against clicking on Advanced permissions, emphasizing the importance of understanding why one might need to do so. 07:27-07:39 | Reflecting on Advanced Permissions Usage: Encourages self-reflection on the necessity of using Advanced permissions, even if it means poking fun at Derek’s expense. 07:39-07:45 | Questioning Advanced Permissions: Reinforces the idea of questioning the need to use Advanced permissions unless changing site collection administrators. 07:45-07:53 | Patterns and Habits: Acknowledges the difficulty of breaking old patterns and habits, with a lighthearted comment about age and experience. 07:53-07:57 | Lighthearted Banter: Ends with a humorous exchange about age and patterns, maintaining a friendly and engaging tone. 07:58-08:06 | Lighthearted Banter Continues: The humorous exchange about age continues, with a playful comment about the small age difference. 08:06-08:12 | Transition to Modern vs. Classic Permissions: The session transitions to discussing modern versus classic permissions in Microsoft 365 SharePoint and Teams. 08:12-08:23 | Stick to Modern Permissions: Emphasizes the importance of using modern permissions, which are simpler and more efficient, and only adding people to groups if they are actual members. 08:23-08:30 | Reiterating Group Membership Rules: Reiterates the rule of only adding actual members to groups, highlighting its importance. 08:30-08:35 | Use Classic Permissions for Cleanup: Advises using classic permissions only for cleaning up messes or specific exceptions like organizational asset libraries. 08:35-08:42 | Exception for Organizational Assets Library: Mentions an exception for using classic permissions when dealing with an organizational assets library. 08:42-08:48 | Caution with Advanced Permission Settings: Encourages careful consideration before clicking on advanced permission settings. 08:48-08:54 | Finding Broken Inheritance: One reason to use advanced permissions is to find where inheritance is broken, which can also be done using tools like ShareGate. 08:54-09:00 | Using ShareGate for Cleanup: Highlights the use of ShareGate to run reports and clean up permissions when inheritance is broken. 09:00-09:07 | Stick to Modern Permissions: Reiterates the importance of sticking to modern permissions as much as possible. 09:07-09:13 | Introduction to Public vs. Private Sites: Introduces the topic of public versus private SharePoint sites and Teams, noting the impact of grouping. 09:13-09:19 | Public vs. Private Grouping: Discusses how grouping has influenced the creation of public and private sites. 09:19-09:26 | Impact of Creating Public Teams or Groups: Explains that creating a public team or group adds everyone except external users to the site members, allowing them to make changes. 09:26-09:32 | Public Teams and Groups: Highlights the implications of creating public teams or groups in Microsoft 365. 09:32-09:38 | Microsoft 365 Group Membership: Clarifies that a public Microsoft 365 group includes everyone except external users. 09:38-09:44 | Everyone Can Make Changes: Notes that in a public site, all members can make changes, which is usually not ideal. 09:44-09:50 | Exceptions for Public Sites: Acknowledges that there are exceptions where public sites make sense, but they are rare. 09:50-09:56 | Preference for Private Sites: Most team sites are private to restrict access to a small group of people. 09:56-10:02 | Reasons for Private Sites: Private sites are preferred to shield content from everyone else or to avoid clutter. 10:02-10:08 | Choosing Public vs. Private Carefully: Emphasizes the importance of carefully choosing between public and private settings for sites.

[@MyCopilot-anthonyrhopkins]

10:14-10:20 | Viewing Group Type in SharePoint Admin Center: In a team site, you can see if a group is public or private in the SharePoint admin center, though it may not always be clearly labeled. 10:20-10:28 | Naming Conventions in Teams: In Microsoft Teams, the group type is not always obvious unless named explicitly, such as “private team” or “public team.” 10:28-10:33 | Difficulty Identifying Group Type in Teams: The speaker notes that in Teams, it can be challenging to tell if a team is public or private without specific naming conventions. 10:33-10:45 | Changing Group Settings Post-Creation: You can change the public or private setting of a group after its creation, which significantly impacts permissions and access control. 10:45-10:52 | Fixing Mistakes in Group Settings: If a mistake is made in setting the group type, it can be corrected, but this change has major implications for permissions. 10:52-11:00 | Impact on Permissions: The difference between public and private settings has a huge impact on permissions for sites, groups, and containers. 11:00-11:07 | Importance of Understanding Group Types: Understanding the difference between public and private groups is crucial, especially with broad groups that include everyone except external users. 11:07-11:13 | Broad Group Membership: Broad groups that include everyone except external users can be useful but need careful management due to their wide access. 11:13-11:20 | Transition to Sharing Settings: The session transitions to discussing sharing settings, with Derek taking over to explain tenant-level settings. 11:20-11:27 | Introduction to Tenant-Level Sharing Settings: Derek introduces the topic of tenant-level sharing settings, describing it as the starting point for managing permissions. 11:27-11:33 | Tenant-Level Sharing Toggle: The tenant-level sharing settings include a toggle to allow or disallow guest users in the organization, which is a fundamental control. 11:33-11:41 | Navigating to Tenant-Level Settings: Explains how to access tenant-level sharing settings through the Microsoft 365 admin center, noting that it’s buried under org settings, then sharing, and finally under security and privacy. 11:41-11:46 | Hidden Location of Settings: Highlights the difficulty in finding these settings, with a personal anecdote about needing to call Mark for help locating them. 11:46-11:52 | Additional Service Level Settings: Mentions that there are additional service level settings for SharePoint and Microsoft 365 groups at the tenant level, which are also important to consider. 11:52-11:57 | Importance of Service Level Settings: Emphasizes the significance of these additional settings for managing permissions and sharing within the organization. 11:57-12:03 | Guest Users and Existing Permissions: Points out that unchecking the box to disallow guest users does not remove existing guest users from the tenant, which is crucial for managing ongoing access. 12:03-12:08 | Managing Existing Guest Users: Clarifies that existing guest users retain their access even if the setting to allow guest users is turned off, which can impact permissions management. 12:08-12:17 | Implications for Sharing and Permissioning: Notes that this detail about guest users becomes particularly relevant when discussing sharing and permissioning settings in the following slides. 12:17-12:23 | Allowing External Users: Explains that allowing external users is a fundamental setting that determines whether these users can be added to sites within the organization. 12:23-12:29 | Adding External Users to Sites: Summarizes that this setting controls the ability to add external users to sites, which is a key aspect of managing permissions and access. 12:29-12:35 | Existing Guest Users Retain Access: Reiterates that unchecking the box to disallow guest users does not remove existing guest users, which is important for managing permissions. 12:35-12:42 | Relevance to Sharing and Permissioning: Highlights that this detail about guest users is particularly relevant when discussing sharing and permissioning settings. 12:42-12:48 | Allowing External Users: Summarizes that allowing external users determines whether these users can be added to sites within the organization. 12:48-12:54 | Transition to Next Topic: Prepares to move on to the next topic, continuing the discussion on tenant-level settings. 12:54-13:00 | SharePoint Admin Settings for Tenant: Introduces the SharePoint admin settings at the tenant level, which affect both SharePoint and Teams. 13:00-13:08 | SharePoint Admin Center: Mentions the SharePoint admin center as the location for setting sharing policies and settings for SharePoint and OneDrive. 13:08-13:14 | Policies and Sharing Settings: Describes how the policies and sharing settings in the SharePoint admin center are crucial for managing permissions. 13:14-13:23 | Default Sharing Limits: Explains the default sharing limits for SharePoint and OneDrive, ranging from the most permissive to the most restrictive settings. 13:23-13:29 | Adjusting Sharing Limits: Notes that these sharing limits can be adjusted to control the level of access, from open sharing to no external sharing. 13:29-13:34 | Permissive Sharing Settings: Describes the most permissive setting, which allows anyone to open anything without requiring a sign-in, and highlights its risks. 13:34-13:41 | Restrictive Sharing Settings: Describes the most restrictive setting, which limits sharing to people within the organization and disallows external sharing. 13:41-13:47 | Dialing Sharing Settings: Explains that sharing settings can be dialed up or down to find the right balance for the organization. 13:47-13:54 | Additional Limitations and Restrictions: Mentions additional limitations and restrictions that can be applied, such as allowing sharing only with specific domains. 13:54-13:59 | Domain-Specific Sharing: Provides an example of allowing external sharing with specific domains, such as a design vendor or help desk. 13:59-14:07 | Allow Lists for Domains: Explains how to set up allow lists for specific domains to control external sharing more precisely. 14:07-14:13 | Security Group Restrictions: Describes how sharing can be restricted to certain security groups, such as allowing only the IT group to share externally. 14:13-14:18 | Default Guest Sharing Setting: Points out that the default setting allows guests to share items they don’t own, which can be risky. 14:18-14:24 | Concerns About Default Setting: Expresses concern about the default setting that allows guests to share items they don’t own, suggesting it should be unchecked. 14:24-14:29 | Guest Sharing Capabilities: Clarifies that guests can share documents they created or viewed, based on the other sharing settings in place. 14:29-14:34 | Recommendation to Uncheck: Recommends unchecking the default setting that allows guests to share items they don’t own to enhance security. 14:34-14:43 | Risks of Guest Sharing: Emphasizes the risks associated with allowing guests to share items they don’t own, highlighting the need for careful management. 14:43-14:50 | Guest Sharing Capabilities: Clarifies that guest users can share documents they created or viewed, based on the existing sharing settings, which can lead to unintended access. 14:50-14:56 | Recommendation to Uncheck Default Setting: Recommends unchecking the default setting that allows guests to share items they don’t own to prevent potential security risks. 14:56-15:03 | Specific Settings for Files and Folders: Discusses specific sharing settings for files and folders, including who can share links and how those links are shared. 15:03-15:11 | Sharing with Specific People: Explains the option to share with specific people, individual users, people within the organization, or anyone with the link, noting the risks of broad sharing. 15:11-15:16 | Preference for Internal Sharing: Suggests setting sharing options to only people within the organization to maintain control and security. 15:16-15:23 | Default Permissions for Shared Links: Describes the default permissions for shared links, whether users get view or edit permissions by default, and the importance of setting this appropriately. 15:23-15:30 | Setting Default Permissions: Recommends setting default permissions to view rather than edit to prevent unauthorized changes. 15:30-15:35 | Moving to Next Topic: Indicates the transition to the next topic due to the extensive content to cover.

[@MyCopilot-anthonyrhopkins]

15:35-15:40 | Introduction to Site-Level Settings: Introduces the SharePoint admin center settings for individual sites, distinct from tenant-wide settings. 15:40-15:46 | SharePoint Admin Center for Sites: Specifies that the discussion will now focus on site-level settings within the SharePoint admin center. 15:46-15:52 | Detailed Site-Level Settings: Describes the site-level settings as the “third ring of Hell,” emphasizing the complexity and importance of these settings. 15:52-15:58 | Tenant vs. Site-Level Settings: Clarifies that the previous settings discussed were tenant-wide, while the current focus is on settings specific to individual sites. 15:58-16:04 | Navigating to Active Sites: Explains how to navigate to active sites in the SharePoint admin center to adjust site-specific sharing settings. 16:04-16:10 | Accessing Site Settings: Describes the process of selecting a site and accessing the settings tab to configure sharing options on a site-by-site basis. 16:10-16:16 | Internal and External Sharing Settings: Highlights the ability to set different sharing settings for internal and external users at the site level. 16:16-16:21 | Tenant-Level Restrictions: Reminds that site-level settings cannot override tenant-level restrictions, such as disallowing external users. 16:21-16:27 | Consistency with Tenant Settings: Emphasizes that site-level sharing settings must be consistent with the overarching tenant-level policies. 16:27-16:32 | External Sharing Limitations: Notes that if external sharing is not allowed at the tenant level, attempts to share externally at the site level will result in errors. 16:32-16:39 | 404 Error for Disallowed Sharing: Explains that users will encounter a 404 error if they try to share externally when it is not permitted by tenant-level settings. 16:39-16:45 | Hidden Advanced Settings: Mentions that more advanced settings are hidden under a dropdown labeled “more sharing settings” within the external file sharing section. 16:45-16:51 | Accessing More Sharing Settings: Explains how to access these hidden settings, which provide additional controls for sharing within a specific site. 16:51-16:59 | Default Sharing Options: Describes the default sharing options available once the advanced settings are accessed, including sharing with anyone, new and existing guests, existing guests only, and only people in your organization. 16:59-17:05 | Setting Sharing Levels: Highlights the ability to set different sharing levels depending on the site’s purpose and the desired level of access control. 17:05-17:12 | Revisiting External Sharing Settings: Recalls the initial discussion on external sharing settings, emphasizing their importance in determining who can share with external users. 17:12-17:17 | Impact of Tenant-Level Settings: Notes that if external sharing is enabled at the tenant level, users can share with existing guests, extending access beyond the current security construct. 17:17-17:22 | Sharing with External Users: Explains that allowing sharing with existing guests permits sharing with external users, depending on the tenant-level settings. 17:22-17:28 | Security Considerations: Emphasizes the need to consider security implications when setting sharing options, especially for external users. 17:28-17:34 | Default Sharing Link Type: Introduces the concept of the default sharing link type, which determines the default permissions for shared links. 17:34-17:42 | Collective Groan Over Default Settings: Mentions that the default sharing link type often causes frustration, as it can lead to unintended permissions. 17:42-17:49 | Importance of Default Link Settings: Stresses the importance of setting the default sharing link type appropriately to avoid creating individual permissions that complicate management. 17:49-17:54 | Setting Default Permissions: Recommends carefully setting the default permissions for shared links to ensure they align with the organization’s security policies. 17:54-18:00 | Avoiding Individual Permissions: Advises against creating individual permissions, as this can lead to a complex and difficult-to-manage permissions structure. 18:00-18:08 | Default Sharing Link to Existing Access: Explains that setting the default sharing link to “people with existing access” prevents the creation of individual permissions on items. 18:08-18:13 | Avoiding Broken Inheritance: Notes that setting the sharing link to anything other than “people with existing access” will break inheritance and create individual permissions. 18:13-18:19 | Impact of Specific Sharing Settings: Highlights that specific sharing settings, such as “specific people” or “only people in the organization,” can complicate permissions by breaking inheritance. 18:19-18:27 | More on Sharing Settings Later: Indicates that there will be further discussion on the implications of different sharing settings later in the session. 18:27-18:33 | Introduction to Site-Level Sharing: Transitions to discussing sharing settings at the site level, emphasizing the complexity involved. 18:33-18:38 | Another Layer of Complexity: Describes site-level sharing settings as another “ring of Hell,” indicating the additional complexity and hidden settings. 18:38-18:45 | Accessing Site-Level Settings: Explains that site-level sharing settings are only accessible by going into the site, navigating to the gear icon, and selecting site permissions. 18:45-18:52 | Hidden Link for Sharing Settings: Mentions a hidden link under site permissions labeled “change how members can share,” which controls sharing settings within the site. 18:52-18:59 | Controlling Who Can Share: Describes how this setting determines who can share and how they can share within the site, based on specific use cases. 18:59-19:06 | Client Use Case Example: Provides an example of a client who restricted sharing to only site owners, limiting the number of people who could share content. 19:06-19:11 | Restricting Sharing to Site Owners: Explains that setting sharing permissions to only site owners can effectively limit who can share content within the site. 19:11-19:18 | Limited Sharing Group: Notes that this approach results in a very limited group of people who can share, enhancing control over content distribution. 19:18-19:23 | Managing Access Requests: Mentions that this is the only place where you can turn on or off the option to allow access requests in the modern environment. 19:23-19:30 | Conclusion of Thread: Concludes the discussion on this particular thread of sharing settings, indicating a wrap-up of the topic. 19:30-19:35 | Realizing Missed Topics: The speakers realize they missed discussing teams and guests, noting that these topics will be covered later. 19:35-19:43 | Transition to Restricted Access Control: The session transitions to Todd discussing restricted access control, a feature under the SharePoint Premium (SAM) offering. 19:43-19:49 | Importance of Restricted Access Control: Todd explains that restricted access control is crucial depending on the organization, and it’s part of the premium features not included out of the box. 19:49-19:56 | Premium Feature Costs: Highlights that restricted access control is a premium feature that requires additional payment, emphasizing its advanced nature. 19:56-20:02 | Setting at SharePoint Tenant Level: Clarifies that restricted access control is set at the SharePoint tenant level, not the site level, which is an important distinction. 20:02-20:08 | Restricting Access to Specific Groups: Describes how this feature allows restricting site access to people in a specific group in Entra ID, which can be a security group or a Microsoft 365 group. 20:08-20:14 | Importance of Group Membership: Explains that if a person is not in the designated group set at the tenant level, they cannot access the site, regardless of their membership status within the site. 20:14-20:21 | Example of Use Case: Provides an example where only members of an IT group can access IT project sites, preventing unauthorized access from other departments. 20:21-20:28 | Preventing Unauthorized Access: Emphasizes that this feature prevents adding unauthorized users, such as someone from accounting or engineering, to specific project sites. 20:28-20:35 | Error Message for Unauthorized Additions: Notes that site owners will receive an error message if they try to add someone not in the designated group, enhancing security.

[@MyCopilot-anthonyrhopkins]

20:35-20:42 | Restricting File Sharing: Mentions that this setting can also restrict who files can be shared with, although this feature is not enabled by default. 20:42-20:47 | Disagreement with Default Setting: Expresses disagreement with the default setting that does not restrict file sharing, suggesting it should be an overarching restriction. 20:47-20:49 | Sharing Individual Files: Explains that individual files can still be shared with users outside the designated groups unless this is specifically restricted. 20:49-20:55 | Using PowerShell for Restrictions: Indicates that the only way to enforce these sharing restrictions is through PowerShell, despite the promise to avoid mentioning it. 20:55-22:02 | PowerShell for Advanced Settings: Concludes by acknowledging the necessity of using PowerShell to implement advanced sharing restrictions, despite its complexity. 22:02-22:07 | Permissions and Co-Pilot: Greg mentions an interesting point about permissions and Co-Pilot, noting that if someone is added to a site but restricted access control is later applied, it can cause issues. 22:07-22:13 | Access Issues with Restricted Control: Explains that if someone has access to something but can’t get through due to restricted access control, it will show up in search but they won’t be able to access it, leading to an error message. 22:13-22:19 | Broken Promise Scenario: Describes this as a “broken promise” situation where users see items in search but can’t access them due to restricted permissions. 22:19-22:25 | Scenario Explanation: Discusses how this situation might occur, such as users being added before restricted access control is applied and not being removed afterward. 22:25-22:31 | Error Messages for Restricted Access: Notes that users will receive an error message if they try to access something they are restricted from, despite it appearing in search results. 22:31-22:37 | Reflecting on the Scenario: Reflects on the scenario, suggesting it likely happens when restricted access is applied after users have already been added. 22:37-22:42 | Importance of Cleanup: Emphasizes the importance of cleaning up permissions after applying restricted access control to avoid such issues. 22:42-22:47 | SharePoint Tenant Setting: Reiterates that restricted access control is a SharePoint tenant setting, which supersedes site-level settings. 22:47-22:54 | Applicability to Group and Non-Group Sites: Clarifies that this setting can be used on both group-connected and non-group-connected sites. 22:54-22:59 | Preventing Unauthorized Access: Highlights that this setting is another way to prevent unauthorized access to sites and content. 22:59-23:05 | Summary of Restricted Access Control: Summarizes the discussion on restricted access control, noting its importance and implications for permissions management. 23:05-23:11 | Transition to Permissions Extras: Transitions to discussing additional permissions extras and callouts in Microsoft 365. 23:11-23:19 | Tidbits on Permissions: Introduces a few additional tidbits on permissions, starting with a reference to “anyone in this organization” links. 23:19-23:26 | Preferred Sharing Default: Reiterates that “anyone with existing access” is the preferred default for sharing links to avoid creating individual permissions. 23:26-23:33 | Limitations at SharePoint Admin Level: Notes that this preferred setting is not available at the SharePoint admin level, requiring site-by-site configuration. 23:33-23:40 | Site-by-Site Configuration: Explains that the need for site-by-site configuration often leads to broken links because users may not follow the extra steps. 23:40-23:49 | Impact of Missing Configuration: Highlights the impact of not configuring sharing settings properly, resulting in broken links and permissions issues. 23:49-23:55 | Provisioning Services: Mentions that using provisioning services like ShareGate or Orchestry can help automate these settings during site creation. 23:55-24:06 | Automating Settings with Provisioning Services: Suggests that provisioning services can ensure consistent application of preferred sharing settings, reducing the risk of broken links and permissions issues. 24:15-24:20 | Provisioning Services Copy Settings: Explains that provisioning services like ShareGate and Orchestry copy the preferred sharing settings, ensuring consistency. 24:20-24:27 | Handling Settings Automatically: Notes that these services might handle the settings automatically, but if users create sites manually, this consistency might not be maintained. 24:27-24:34 | Correct Default Setting: Emphasizes the belief that “anyone with existing access” is the correct default setting to avoid breaking permissions and creating mixups. 24:34-24:40 | Impact on Permission Structure: Highlights how incorrect default settings can change the permission structure and lead to permission mixups. 24:40-24:48 | Clarification on “Anyone in This Organization” Link: Discusses a common misconception about the “anyone in this organization” link, clarifying its actual function. 24:48-24:56 | Misconception About Access: Explains that the “anyone in this organization” link does not grant immediate access to everyone; instead, it initiates a process to grant permission. 24:56-25:02 | Permission Process: Clarifies that clicking the link starts a process that grants permission to the site or file, making it more restricted than initially thought. 25:02-25:08 | Restricted Access Process: Emphasizes that the link only grants access after the permission process is completed, which is more secure than assumed. 25:08-25:14 | Understanding Both Options: Reflects on the realization that the “anyone in this organization” link is not as open as the “everyone” link, making it a safer option. 25:14-25:20 | Limited Permission Granting: Explains that the link only grants access to those who click it and complete the permission process, not to everyone automatically. 25:20-25:27 | Reassessing Security Concerns: Reassures that the “anyone in this organization” links are not as risky as they seem, as they require user action to grant access. 25:27-25:33 | Controlled Access: Highlights that access is only granted to individuals who follow the link, ensuring controlled and limited permissions. 25:33-25:39 | Mini Membership Creation: Describes how clicking the link adds users to a “mini membership” for that specific link’s access, maintaining security. 25:39-25:46 | Example of Controlled Access: Provides an example where sending the link to one person grants them access, but they cannot extend it to others without sharing the link. 25:46-25:53 | Misunderstanding of Link Function: Reflects on the initial misunderstanding that the link granted access to everyone, clarifying that it does not. 25:53-25:58 | Realization of Limited Access: Concludes with the realization that the link does not automatically grant access to everyone, but only to those who click and follow it. 26:05-26:13 | Comfort in Limited Access: Discusses the comforting aspect of knowing that links only grant access to those who click and follow them, especially in the context of Co-Pilot.