Add members to O365 Security Groups using Azure AD Powershell Module

Step 1. Create a CSV file with a column “UserPrincipalName” and add all users under it who are to be added as a member of the group.


Step 2.  Run The below command to import the csv file and get the object IDs for members to be added to group

Import-Csv C:\temp\Members.csv csv  | Foreach {Get-Msoluser -UserPrincipalName $_.Userprincipalname | select Objectid } | Export-csv C:\temp\MembersWithObjectID.csv

This will convert the user’s identity to their unique guid details, and export it to the same CSV file.


Step 3. Collect the guid ID of the security group as well to which you want to add the mebers

The below command will help with the object ID of the Group.

Get-MsolGroup  “SecurityGroupName” | FL

I have my object ID as below.

ObjectId                  : XXXXXX-XXXX-XXXX-XXXXXXXXX


Step 4. Run the below command to Add members in the CSV to the Group.

$sub2 = Import-Csv C:\RAhul\sspruser.com.csv

Import-Csv C:\temp\MembersWithObjectID.csv | Foreach {Add-MsolGroupMember -groupObjectid ‘XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX’ -GroupMemberObjectId $_.ObjectId -GroupMemberType User}


Step 5. Verify the users from the Group just added.

Get-MsolGroupMember -all -groupObjectid ‘XXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX’ | Select DisplayName,EmailAddress,GroupMemberType | Export-csv C:\temp\security-group-members.csv

How to export user photos in O365 / Exchange Online using Exchange Online Powershell

Below small script can be use to export photos from O365 / Exchange Online using powershell.

First you need to connect to exchange online.

#############################################

get-mailbox -ResultSize Unlimited | % {Get-UserPhoto $_.identity} | % {Set-Content -path “C:\Photos\$($_.identity).jpg” -value $_.picturedata -Encoding byte}

####################################################

Azure Active Directory Single Sign-On Using Azure Ad Connect

Azure Active Directory Seamless Single Sign-On: Quick start

Deploy Seamless Single Sign-On

Azure Active Directory (Azure AD) Seamless Single Sign-On (Seamless SSO) automatically signs in users when they are on their corporate desktops that are connected to your corporate network. Seamless SSO provides your users with easy access to your cloud-based applications without needing any additional on-premises components.

To deploy Seamless SSO, follow these steps.

Step 1: Check the prerequisites

Ensure that the following prerequisites are in place:

  • Set up your Azure AD Connect server: If you use Pass-through Authentication as your sign-in method, no additional prerequisite check is required. If you use password hash synchronization as your sign-in method, and if there is a firewall between Azure AD Connect and Azure AD, ensure that:
    • You use version 1.1.644.0 or later of Azure AD Connect.
    • If your firewall or proxy allows DNS whitelisting, whitelist the connections to the *.msappproxy.net URLs over port 443. If not, allow access to the Azure datacenter IP ranges, which are updated weekly. This prerequisite is applicable only when you enable the feature. It is not required for actual user sign-ins.

Note

Azure AD Connect versions 1.1.557.0, 1.1.558.0, 1.1.561.0, and 1.1.614.0 have a problem related to password hash synchronization. If you don’t intend to use password hash synchronization in conjunction with Pass-through Authentication, read the Azure AD Connect release notes to learn more.

  • Use a supported Azure AD Connect topology: Ensure that you are using one of Azure AD Connect’s supported topologies described here.

Note

Seamless SSO supports multiple AD forests, whether there are AD trusts between them or not.

  • Set up domain administrator credentials: You need to have domain administrator credentials for each Active Directory forest that:
    • You synchronize to Azure AD through Azure AD Connect.
    • Contains users you want to enable for Seamless SSO.
  • Enable modern authentication: You need to enable modern authentication on your tenant for this feature to work.
  • Use the latest versions of Office 365 clients: To get a silent sign-on experience with Office 365 clients (Outlook, Word, Excel, and others), your users need to use versions 16.0.8730.xxxx or above.

Step 2: Enable the feature

Enable Seamless SSO through Azure AD Connect.

If you’re doing a fresh installation of Azure AD Connect, choose the custom installation path. At the User sign-in page, select the Enable single sign on option.

Note

The option will be available for selection only if the Sign On method is Password Hash Synchronization or Pass-through Authentication.

clip_image002

If you already have an installation of Azure AD Connect, select the Change user sign-in page in Azure AD Connect, and then select Next. If you are using Azure AD Connect versions 1.1.880.0 or above, the Enable single sign on option will be selected by default. If you are using older versions of Azure AD Connect, select the Enable single sign on option.

clip_image004

Continue through the wizard until you get to the Enable single sign on page. Provide domain administrator credentials for each Active Directory forest that:

  • You synchronize to Azure AD through Azure AD Connect.
  • Contains users you want to enable for Seamless SSO.

After completion of the wizard, Seamless SSO is enabled on your tenant.

Note

The domain administrator credentials are not stored in Azure AD Connect or in Azure AD. They’re used only to enable the feature.

Follow these instructions to verify that you have enabled Seamless SSO correctly:

  1. Sign in to the Azure Active Directory administrative center with the global administrator credentials for your tenant.
  2. Select Azure Active Directory in the left pane.
  3. Select Azure AD Connect.
  4. Verify that the Seamless single sign-on feature appears as Enabled.

clip_image006

Important

Seamless SSO creates a computer account named AZUREADSSOACC (which represents Azure AD) in your on-premises Active Directory (AD) in each AD forest. This computer account is needed for the feature to work. Move the AZUREADSSOACC computer account to an Organization Unit (OU) where other computer accounts are stored to ensure that it is managed in the same way and is not deleted.

Step 3: Roll out the feature

You can gradually roll out Seamless SSO to your users using the instructions provided below. You start by adding the following Azure AD URL to all or selected users’ Intranet zone settings by using Group Policy in Active Directory:

  • https://autologon.microsoftazuread-sso.com

In addition, you need to enable an Intranet zone policy setting called Allow updates to status bar via script through Group Policy.

Note

The following instructions work only for Internet Explorer and Google Chrome on Windows (if it shares a set of trusted site URLs with Internet Explorer). Read the next section for instructions on how to set up Mozilla Firefox and Google Chrome on macOS.

Why do you need to modify users’ Intranet zone settings?

By default, the browser automatically calculates the correct zone, either Internet or Intranet, from a specific URL. For example, “http://contoso/” maps to the Intranet zone, whereas “http://intranet.contoso.com/” maps to the Internet zone (because the URL contains a period). Browsers will not send Kerberos tickets to a cloud endpoint, like the Azure AD URL, unless you explicitly add the URL to the browser’s Intranet zone.

There are two ways to modify users’ Intranet zone settings:

Option

Admin consideration

User experience

Group policy

Admin locks down editing of Intranet zone settings

Users cannot modify their own settings

Group policy preference

Admin allows editing on Intranet zone settings

Users can modify their own settings

“Group policy” option – Detailed steps

  1. Open the Group Policy Management Editor tool.
  2. Edit the group policy that’s applied to some or all your users. This example uses Default Domain Policy.
  3. Browse to User Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page. Then select Site to Zone Assignment List.

clip_image008

  1. Enable the policy, and then enter the following values in the dialog box:
    • Value name: The Azure AD URL where the Kerberos tickets are forwarded.
    • Value (Data): 1 indicates the Intranet zone.The result looks like this:Value: https://autologon.microsoftazuread-sso.comData: 1

Note

If you want to disallow some users from using Seamless SSO (for instance, if these users sign in on shared kiosks), set the preceding values to 4. This action adds the Azure AD URL to the Restricted zone, and fails Seamless SSO all the time.

  1. Select OK, and then select OK again.

clip_image010

  1. Browse to User Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone. Then select Allow updates to status bar via script.

clip_image011

  1. Enable the policy setting, and then select OK.

clip_image012

“Group policy preference” option – Detailed steps

  1. Open the Group Policy Management Editor tool.
  2. Edit the group policy that’s applied to some or all your users. This example uses Default Domain Policy.
  3. Browse to User Configuration > Preferences > Windows Settings > Registry > New > Registry item.

clip_image013

  1. Enter the following values in appropriate fields and click OK.
    • Key Path: Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoftazuread-sso.com\autologon
    • Value name: https.
    • Value type: REG_DWORD.
    • Value data: 00000001.

clip_image014

clip_image015

  1. Browse to User Configuration > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone. Then select Allow updates to status bar via script.

clip_image016

  1. Enable the policy setting, and then select OK.

clip_image017

Browser considerations

Mozilla Firefox (all platforms)

Mozilla Firefox doesn’t automatically use Kerberos authentication. Each user must manually add the Azure AD URL to their Firefox settings by using the following steps:

  1. Run Firefox and enter about:config in the address bar. Dismiss any notifications that you see.
  2. Search for the network.negotiate-auth.trusted-uris preference. This preference lists Firefox’s trusted sites for Kerberos authentication.
  3. Right-click and select Modify.
  4. Enter https://autologon.microsoftazuread-sso.com in the field.
  5. Select OK and then reopen the browser.

Safari (macOS)

Ensure that the machine running the macOS is joined to AD. Instructions for AD-joining your macOS device is outside the scope of this article.

Google Chrome (all platforms)

If you have overridden the AuthNegotiateDelegateWhitelist or the AuthServerWhitelist policy settings in your environment, ensure that you add Azure AD’s URL (https://autologon.microsoftazuread-sso.com) to them as well.

Google Chrome (macOS only)

For Google Chrome on Mac OS and other non-Windows platforms, refer to The Chromium Project Policy List for information on how to whitelist the Azure AD URL for integrated authentication.

The use of third-party Active Directory Group Policy extensions to roll out the Azure AD URL to Firefox and Google Chrome on Mac users is outside the scope of this article.

Known browser limitations

Seamless SSO doesn’t work in private browsing mode on Firefox and Edge browsers. It also doesn’t work on Internet Explorer if the browser is running in Enhanced Protected mode.

Step 4: Test the feature

To test the feature for a specific user, ensure that all the following conditions are in place:

  • The user signs in on a corporate device.
  • The device is joined to your Active Directory domain. The device doesn’t need to be Azure AD Joined.
  • The device has a direct connection to your domain controller (DC), either on the corporate wired or wireless network or via a remote access connection, such as a VPN connection.
  • You have rolled out the feature to this user through Group Policy.

To test the scenario where the user enters only the username, but not the password:

  • Sign in to https://myapps.microsoft.com/ in a new private browser session.

To test the scenario where the user doesn’t have to enter the username or the password, use one of these steps:

  • Sign in to https://myapps.microsoft.com/contoso.onmicrosoft.com in a new private browser session. Replace contoso with your tenant’s name.
  • Sign in to https://myapps.microsoft.com/contoso.com in a new private browser session. Replace contoso.com with a verified domain (not a federated domain) on your tenant.

Step 5: Roll over keys

In Step 2, Azure AD Connect creates computer accounts (representing Azure AD) in all the Active Directory forests on which you have enabled Seamless SSO. To learn more, see Azure Active Directory Seamless Single Sign-On: Technical deep dive.

Important

The Kerberos decryption key on a computer account, if leaked, can be used to generate Kerberos tickets for any user in its AD forest. Malicious actors can then impersonate Azure AD sign-ins for compromised users. We highly recommend that you periodically roll over these Kerberos decryption keys – at least once every 30 days.

For instructions on how to roll over keys, see Azure Active Directory Seamless Single Sign-On: Frequently asked questions. We are working on a capability to introduce automated roll over of keys.

Important

You don’t need to do this step immediately after you have enabled the feature. Roll over the Kerberos decryption keys at least once every 30 days.

Create a DLP policy Step by Step in O365

The easiest, most common way to get started with DLP policies is to use one of the templates included in Office 365. You can use one of these templates as is, or customize the rules to meet your organization’s specific compliance requirements.

Office 365 includes over 40 ready-to-use templates that can help you meet a wide range of common regulatory and business policy needs. For example, there are DLP policy templates for:

  • Gramm-Leach-Bliley Act (GLBA)
  • Payment Card Industry Data Security Standard (PCI-DSS)
  • United States Personally Identifiable Information (U.S. PII)
  • United States Health Insurance Act (HIPAA)

You can fine tune a template by modifying any of the existing rules or adding new ones. For example, you can add new types of sensitive information to a rule, modify the counts in a rule to make it harder or easier to trigger, allow people to override the actions in a rule by providing a business justification, or change who notifications and incident reports are sent to. A DLP policy template is a flexible starting point for many common compliance scenarios.

You can also choose the Custom template, which has no default rules, and configure your DLP policy from scratch, to meet the specific compliance requirements for your organization.

Example: Identify sensitive information across all OneDrive for Business sites and restrict access for people outside your organization

OneDrive for Business accounts make it easy for people across your organization to collaborate and share documents. But a common concern for compliance officers is that sensitive information stored in OneDrive for Business accounts may be inadvertently shared with people outside your organization. A DLP policy can help mitigate this risk.

In this example, you’ll create a DLP policy that identifies U.S. PII data, which includes Individual Taxpayer Identification Numbers (ITIN), Social Security Numbers, and U.S. passport numbers. You’ll get started by using a template, and then you’ll modify the template to meet your organization’s compliance requirements—specifically, you’ll:

  • Add a couple of types of sensitive information—U.S. bank account numbers and U.S. driver’s license numbers—so that the DLP policy protects even more of your sensitive data.
  • Make the policy more sensitive, so that a single occurrence of sensitive information is enough to restrict access for external users.
  • Allow users to override the actions by providing a business justification or reporting a false positive. This way, your DLP policy won’t prevent people in your organization from getting their work done, provided they have a valid business reason for sharing the sensitive information.

Create a DLP policy from a template

  1. Go to https://protection.office.com.
  2. Sign in to Office 365 using your work or school account. You’re now in the Office 365 Security & Compliance Center.
  3. In the Security & Compliance Center > left navigation > Data loss prevention > Policy > + Create a policy.Create a policy button
  4. Choose the DLP policy template that protects the types of sensitive information that you need > Next.In this example, you’ll select Privacy > U.S. Personally Identifiable Information ‎(PII)‎ Data because it already includes most of the types of sensitive information that you want to protect—you’ll add a couple later.When you select a template, you can read the description on the right to learn what types of sensitive information the template protects.

    Page for choosing a DLP policy template

  5. Name the policy > Next.
  6. To choose the locations that you want the DLP policy to protect, do one of the following:
  • Choose All locations in Office 365 > Next.
  • Choose Let me choose specific locations > Next. For this example, choose this.To include or exclude an entire location such as all Exchange email or all OneDrive accounts, switch the Status of that location on or off.To include only specific SharePoint sites or OneDrive for Business accounts, switch the Status to on, and then click the links under Include to choose specific sites or accounts. When you apply a policy to a site, the rules configured in that policy are automatically applied to all subsites of that site.

    Options for locations where a DLP policy can be applied

    In this example, to protect sensitive information stored in all OneDrive for Business accounts, turn off the Status for both Exchange email and SharePoint sites, and leave the Status on for OneDrive accounts.

  1. Choose Use advanced settings > Next.
  2. A DLP policy template contains predefined rules with conditions and actions that detect and act upon specific types of sensitive information. You can edit, delete, or turn off any of the existing rules, or add new ones. When done, click Next.                                                                                                                                            Rules expanded in US PII policy template In this example, the U.S. PII Data template includes two predefined rules:
  • Low volume of content detected U.S. PII This rule looks for files containing between 1 and 10 occurrences of each of three types of sensitive information (ITIN, SSN, and U.S. passport numbers), where the files are shared with people outside the organization. If found, the rule sends an email notification to the primary site collection administrator, document owner, and person who last modified the document.
  • High volume of content detected U.S. PII This rule looks for files containing 10 or more occurrences of each of the same three sensitive information types, where the files are shared with people outside the organization. If found, this action also sends an email notification, plus it restricts access to the file. For content in a OneDrive for Business account, this means that permissions for the document are restricted for everyone except the primary site collection administrator, document owner, and person who last modified the document.

    To meet your organization’s specific requirements, you may want to make the rules easier to trigger, so that a single occurrence of sensitive information is enough to block access for external users. After looking at these rules, you understand that you don’t need low and high count rules—you need only a single rule that blocks access if any occurrence of sensitive information is found.

    So you expand the rule named Low volume of content detected U.S. PII > Delete rule.

    Delete rule button

  1. Now, in this example, you need to add two sensitive information types (U.S. bank account numbers and U.S. driver’s license numbers), allow people to override a rule, and change the count to any occurrence. You can do all of this by editing one rule, so select High volume of content detected U.S. PII > Edit rule.                                                                                                                                  Edit rule button
  2. To add a sensitive information type, in the Conditions section > Add or change types. Then, under Add or change types > choose Add > select U.S. Bank Account Number and U.S. Driver’s License Number > Add > Done.Option to Add or change types

 

  1. Add or change types pane
  2. To change the count (the number of instances of sensitive information required to trigger the rule), under Instance count > choose the min value for each type > enter 1. The minimum count cannot be empty. The maximum count can be empty; an empty max value convert to any.When finished, the min count for all of the sensitive information types should be 1 and the max count should be any. In other words, any occurrence of this type of sensitive information will satisfy this condition.Instance counts for sensitive information types
  3. For the final customization, you don’t want your DLP policies to block people from doing their work when they have a valid business justification or encounter a false positive, so you want the user notification to include options to override the blocking action.In the User notifications section, you can see that email notifications and policy tips are turned on by default for this rule in the template.In the User overrides section, you can see that overrides for a business justification are turned on, but overrides to report false positives are not. Choose Override the rule automatically if they report it as a false positive.

    User notifications section and User overrides section

  4. At the top of the rule editor, change the name of this rule from the default High volume of content detected U.S. PII to Any content detected with U.S. PII because it’s now triggered by any occurrence of its sensitive information types.
  5. At the bottom of the rule editor > Save.
  6. Review the conditions and actions for this rule > Next.On the right, notice the Status switch for the rule. If you turn off an entire policy, all rules contained in the policy are also turned off. However, here you can turn off a specific rule without turning off the entire policy. This can be useful when you need to investigate a rule that is generating a large number of false positives.
  7. On the next page, read and understand the following, and then choose whether to turn on the rule or test it out first > Next.Before you create your DLP policies, you should consider rolling them out gradually to assess their impact and test their effectiveness before you fully enforce them. For example, you don’t want a new DLP policy to unintentionally block access to thousands of documents that people require to get their work done.If you’re creating DLP policies with a large potential impact, we recommend following this sequence:
  8. Start in test mode without Policy Tips and then use the DLP reports to assess the impact. You can use DLP reports to view the number, location, type, and severity of policy matches. Based on the results, you can fine tune the rules as needed. In test mode, DLP policies will not impact the productivity of people working in your organization.
  9. Move to Test mode with notifications and Policy Tips so that you can begin to teach users about your compliance policies and prepare them for the rules that are going to be applied. At this stage, you can also ask users to report false positives so that you can further refine the rules.
  10. Turn on the policies so that the rules are enforced and the content’s protected. Continue to monitor the DLP reports and any incident reports or notifications to make sure that the results are what you intend.Options for using test mode and turning on policy
  11. Review your settings for this policy > choose Create.

After you create and turn on a DLP policy, it’s deployed to any content sources that it includes, such as SharePoint Online sites or OneDrive for Business accounts, where the policy begins automatically enforcing its rules on that content.

View the status of a DLP policy

At any time, you can view the status of your DLP policies on the Policy page in the Data loss prevention section of the Security & Compliance Center. Here you can find important information, such as whether a policy was successfully enabled or disabled, or whether the policy is in test mode.

Here are the different statuses and what they mean.

Status Explanation
Turning on… The policy is being deployed to the content sources that it includes. The policy is not yet enforced on all sources.
Testing, with notifications The policy is in test mode. The actions in a rule are not applied, but policy matches are collected and can be viewed by using the DLP reports. Notifications about policy matches are sent to the specified recipients.
Testing, without notifications The policy is in test mode. The actions in a rule are not applied, but policy matches are collected and can be viewed by using the DLP reports. Notifications about policy matches are not sent to the specified recipients.
On The policy is active and enforced. The policy was successfully deployed to all its content sources.
Turning off… The policy is being removed from the content sources that it includes. The policy may still be active and enforced on some sources. Turning off a policy may take up to 45 minutes.
Off The policy is not active and not enforced. The settings for the policy (sources, keywords, duration, etc) are saved.
Deleting… The policy is in the process of being deleted. The policy is not active and not enforced.

Turn off a DLP policy

You can edit or turn off a DLP policy at any time. Turning off a policy disables all of the rules in the policy.

To edit or turn off a DLP policy, on the Policy page > select the policy > Edit policy.

Edit policy button

In addition, you can turn off each rule individually by editing the policy and then toggling off the Status of that rule, as described above.