☁️
Tminus365 Docs
  • 🚀Welcome to Tminus365 Docs
  • 🔐Security
    • Azure AD (Entra)
      • MFA Shall Be Required for All Users
      • MFA is enforced on accounts with Highly Privileged Roles
      • MFA is enforced for Azure Management
      • MFA registration and usage shall be periodically reviewed
      • Legacy Authentication shall be blocked
      • High Risk Users Shall Be Blocked
      • High Risk Sign-Ins Shall Be Blocked
      • Browser Sessions shall not be persistent for privileged users
      • MFA shall be required to enroll devices to Azure AD
      • Managed Devices shall be required for authentication
      • Guest User Access Shall be restricted
      • The number of users with highly privileged roles shall be limited
      • Users assigned highly privileged roles shall not have permanent permissions
      • Activation of privileged roles should be monitored and require approval
      • Highly privileged accounts shall be cloud-only
      • Highly privileged role assignments shall be periodically reviewed
      • Passwords shall not expire
      • Azure AD Logs shall be collected
      • Only Admins shall be allowed to register 3rd party applications
      • Non-admin users shall be prevented from providing consent to 3rd party applications
      • Authorized Applications shall be configured for Single Sign-On
      • Inactive accounts shall be blocked or deleted
    • Teams
      • Private Channels shall be utilized to restrict access to sensitive information
      • External Participants SHOULD NOT Be Enabled to Request Control of Shared Desktops or Windows in Meet
      • Anonymous Users SHALL NOT Be Enabled to Start Meetings
      • Automatic Admittance to Meetings SHOULD Be Restricted
      • External User Access SHALL Be Restricted
      • Unmanaged User Access SHALL Be Restricted
      • Contact with Skype Users SHALL Be Blocked
      • Teams Email Integration SHALL Be Disabled
      • Only Approved Apps SHOULD Be Installed
      • File Sharing and File Storage Options shall be blocked
      • Only the Meeting Organizer SHOULD Be Able to Record Live Events
      • Attachments SHOULD Be Scanned for Malware
      • Link Protection SHOULD Be Enabled
      • Restrict Users who can Create Teams Channels
      • Teams Channels shall have an expiration policy
      • Data Loss Prevention Solutions SHALL Be Enabled
    • Exchange
      • Automatic Forwarding to External Domains SHALL Be Disabled
      • Sender Policy Framework SHALL Be Enabled
      • DomainKeys Identified Mail SHOULD Be Enabled
      • Domain-Based Message Authentication, Reporting, and Conformance SHALL Be Enabled
      • Enable Email Encryption
      • Simple Mail Transfer Protocol Authentication SHALL Be Disabled
      • Calendar and Contact Sharing SHALL Be Restricted
      • External Sender Warnings SHALL Be Implemented
      • Data Loss Prevention Solutions SHALL Be Enabled
      • Emails SHALL Be Filtered by Attachment File Type
      • Zero-Hour Auto Purge for Malware SHOULD Be Enabled
      • Phishing Protections SHOULD Be Enabled
      • Inbound Anti-Spam Protections SHALL Be Enabled
      • Safe Link Policies SHOULD Be Enabled
      • Safe Attachments SHALL Be Enabled
      • IP Allow Lists SHOULD NOT be Implemented
      • Mailbox Auditing SHALL Be Enabled
      • Alerts SHALL Be Enabled
      • Audit Logging SHALL Be Enabled
      • Enhanced Filtering Shall be configured if a 3rd party email filtering tool is being used
    • SharePoint
      • File and Folder Links Default Sharing Settings SHALL Be Set to Specific People
      • External Sharing SHOULD be Set to “New and Existing Guests”
      • Sensitive SharePoint Sites SHOULD Adjust Their Default Sharing Settings
      • Expiration Times for Guest Access to a Site SHOULD Be Determined by specific needs
      • Users SHALL Be Prevented from Running Custom Scripts
    • OneDrive
      • Anyone Links SHOULD Be Turned Off
      • Expiration Date SHOULD Be Set for Anyone Links
      • Link Permissions SHOULD Be Set to Enabled Anyone Links to View
      • Windows and MacOS devices should be prevented from syncing the OneDrive Client on personal devices
      • Legacy Authentication SHALL Be Blocked
    • Intune
      • Personal Devices should be restricted from enrolling into the MDM solution
      • Devices shall be deleted that haven’t checked in for over 30 days
      • Devices compliance policies shall be configured for every supported device platform
      • Noncompliant devices shall be blocked from accessing corporate resources
      • MFA Shall be required for Intune Enrollment
      • Security Baselines should be configured for Windows Devices
      • Windows Update Rings shall be configured for Windows Devices
      • Update Policies shall be configured for Apple Devices
      • App Protection policies should be created for mobile devices
      • Mobile devices shall only be able to access corporate data through approved client apps
      • Lockout screen and password settings shall be configured for each device
      • Encryption shall be required on all devices
      • Windows Hello for Business should be configured where applicable
      • Authorized Applications should be deployed to managed devices
      • Device Use Shall be restricted until required applications are installed
      • Devices and Applications shall be wiped when a user leaves the organization or reports a lost/stolen
  • ⚙️Configurations
    • GDAP
      • My Automations Break with GDAP: The Fix!
      • Vendor Integrations Break with GDAP: The Fix!
      • Adding GDAP Relationships
      • Leveraging PIM with GDAP
      • GDAP Migration with Microsoft 365 Lighthouse
    • GoDaddy
      • Defederating GoDaddy 365
  • 🛡️CIS Controls
    • CIS Mapped to M365
  • 🔌Vendor Integrations
    • Pax8
      • Automating NCE subscription renewal notices
      • Leveraging the Pax8 API in Power Automate
    • IT Glue
      • Automating Intune Device Documentation in IT Glue
      • Automating Microsoft Documentation
    • Huntress
      • Leveraging the Huntress API in Power Automate
    • Syncro
      • Automating Microsoft 365 Documentation in Syncro
      • Custom Connector in Power Automate
      • Creating Tickets for Azure AD Risky Users
Powered by GitBook
On this page
  • Prerequisites
  • Steps:
  • Set up a security group with Azure AD Role assignment
  • Enable Privileged Access on the Group
  • Add Eligible Assignments
  • Add Security Groups to GDAP Workloads
  • Test user activating membership
  • Bonus: More Granular Settings for the Group Membership
  • Final Thoughts
  1. Configurations
  2. GDAP

Leveraging PIM with GDAP

PreviousAdding GDAP RelationshipsNextGDAP Migration with Microsoft 365 Lighthouse

Last updated 1 year ago

In my I talked about the major considerations when adding roles for GDAP relationships. In some instances, you may want to bump up security a step further and pair GDAP with PIM or privileged identity management. This would allow you to have just in time access to customer workloads for users in your organization vs perpetual access. In this article, I would be showing you how to set that up for security groups within your Azure AD environment.

Prerequisites

An Active Azure AD P2 subscription

I’ve mentioned this before, but PIM comes with Azure AD P2 licensing which is for a year for indirect resellers. This is a great time to test out PIM within your organization to help promote a model of least privilege access.

Steps:

  1. Set up a security group with Azure AD Role Assignment

  2. Enable Privileged Access on the Group

  3. Add Eligible Assignments

  4. Add Security Groups to GDAP Workloads

  5. Test user activating membership

Set up a security group with Azure AD Role assignment

The first thing we need to do is establish a security group with Azure AD Role assignments. This type of group then becomes eligible to be used with PIM to add “eligible” members.

Create a new security group and toggle Azure AD Roles to Yes. The group does not need to be assigned any owners, members, or roles to be created. Its possible/likely you will leave these blank and yes perform the next step of adding eligible members.

Enable Privileged Access on the Group

Next we will enable privileged access on the group. Click into the group from the group blade. Select Privileged Access and click Enabled Privileged Access

Add Eligible Assignments

After you click on Enabled Privileged Access, you get the chance to add permanent(Active) or eligible assignments. Eligible means that users can activate this membership for a specified period of time. Click the Eligible tab and click Add Assignments.

From the dropdown, select member and then add the applicable members to the group that could become eligible. These would be members in your Partner Center access those specific workloads for a customer (Global Reader, Exchange, SharePoint, etc.)

After you select the members, you will be able to select the duration of eligibility. The max value is one year and you can set this to be less time

Add Security Groups to GDAP Workloads

In Partner Center, select Customers>Administer>Select Single customer

Select One of your existing GDAP relationships

Click Add Security Groups. Select your recently created security group and click next.

Select the appropriate roles based on the workload you want the security group to have access to. In this example, I made the security group Global Readers, so I am going to grant that role. After you save, the status will go from pending to Active after about 30 seconds (may require page refresh)

Test user activating membership

Now that we have our PIM Group established and assigned to a workload, we can now test a user activating their temporary membership.

From the main page, select My Roles

Select Privileged Access Groups and click Activate to activate the membership

Add the number of hours you will need membership and add a reason for activation. This is great to have as an audit trail for compliance.

Once you activate, Azure AD will automatically walk through steps to activate the membership and refresh your session

You will see on the Active Assignments tab that the membership is active. This also includes the end time and ability to deactivate.

Since that the membership is active, you can test your access via Partner Center. Go to Customers>Administer>Expand the Customer you added the Security group to

The workloads you see here should be reflective of what roles you gave to the security group in the previous section. In this example we gave Global Reader rights. This means we could test going into the M365 Admin Center>Clicking into Users and then being able to view users but not create them. If you did something more specific, like assigning the Exchange Admin role to the security group, the only workload you should be seeing is exchange.

Bonus: More Granular Settings for the Group Membership

We covered the basics above when it comes to creating eligible memberships with groups and PIM. What if you wanted to require approval to activate the membership? What if you wanted to define the maximum duration someone could be eligible vs the 8hr default? What if you wanted to prompt the user for MFA when they try to activate membership? This is all possible from the management section of PIM.

In the Azure AD Portal, go back to Azure AD Privileged identity Management from All Services. Select Privileged access groups and select the security group you made in the previous sections.

Under Manage, select Settings.

Click Member. From here you will be able to select all of the granular settings when it comes to this eligible membership.

Final Thoughts

I hope that this article provided more targeted guidance on setting up PIM security groups that get assigned to GDAP workloads. I believe that PIM should be put into place for higher levels of permissions into customer environments like the Global Reader role that I showed in the example here. You want your techs to access customer environments securely but you also don’t want to lock things down so much that it becomes a huge pain to perform any investigation or administration. For this reason, you may add techs that constantly access these portals to a perpetual security group and then add techs that do not often need access to the eligible membership assignment.

Now that we have our security group created, we need to assign the group to a workload established from a GDAP relationship. This step assumes you have already created that relationship. If you are not familiar with how to establish relationships, .

Sign in to with a user you added as an eligible member. From the left nav, select All Services and Search or select Azure AD Privileged Identity Management

⚙️
check out my previous article
aad.portal.azure.com
previous blog post,
being offered for free