Gebruikers en groepen voorbereiden voor Azure Information ProtectionPreparing users and groups for Azure Information Protection

Van toepassing op: Azure Information Protection, Office 365Applies to: Azure Information Protection, Office 365

Voordat u Azure Information Protection implementeert voor uw organisatie, moet u ervoor zorgen dat u accounts voor gebruikers en groepen hebt in Azure AD voor de tenant van uw organisatie.Before you deploy Azure Information Protection for your organization, make sure that you have accounts for users and groups in Azure AD for your organization's tenant.

U kunt deze accounts voor gebruikers en groepen op verschillende manieren maken:There are different ways to create these accounts for users and groups, which include:

  • U maakt de gebruikers in Office 365-beheercentrum en de groepen in het Exchange Online-beheercentrum.You create the users in the Office 365 admin center, and the groups in the Exchange Online admin center.

  • U maakt de gebruikers en groepen in Azure Portal.You create the users and groups in the Azure portal.

  • U maakt de gebruikers en groepen met de cmdlets Azure AD PowerShell en Exchange Online.You create the users and group by using Azure AD PowerShell and Exchange Online cmdlets.

  • U maakt de gebruikers en groepen in uw lokale Active Directory en synchroniseert deze vervolgens naar Azure AD.You create the users and groups in your on-premises Active Directory and synchronize them to Azure AD.

  • U maakt de gebruikers en groepen in een andere directory en synchroniseert deze vervolgens naar Azure AD.You create the users and groups in another directory and synchronize them to Azure AD.

Wanneer u gebruikers en groepen maakt via een van de eerste drie methoden, worden ze automatisch gemaakt in Azure AD. Azure Information Protection kan deze accounts vervolgens rechtstreeks gebruiken.When you create users and groups by using the first three methods from this list, they are automatically created in Azure AD, and Azure Information Protection can use these accounts directly. Veel ondernemingsnetwerken maken echter gebruik van een lokale directory voor het maken en beheren van gebruikers en groepen.However, many enterprise networks use an on-premises directory to create and manage users and groups. Azure Information Protection kan deze accounts niet rechtstreeks gebruiken; u moet deze accounts synchroniseren naar Azure AD.Azure Information Protection cannot use these accounts directly; you must synchronize them to Azure AD.

Het gebruik van gebruikers en groepen door Azure Information ProtectionHow users and groups are used by Azure Information Protection

Er zijn drie scenario's voor het gebruik van gebruikers en groepen met Azure Information Protection:There are three scenarios for using users and groups with Azure Information Protection:

Voor het toewijzen van labels aan gebruikers wanneer u het beleid van Azure Information Protection zo configureert dat labels kunnen worden toegepast op documenten en e-mailberichten.For assigning labels to users when you configure the Azure Information Protection policy so that labels can be applied to documents and emails. Alleen beheerders kunnen deze gebruikers en groepen selecteren:Only administrators can select these users and groups:

  • Het standaardbeleid voor Azure Information Protection wordt automatisch toegewezen aan alle gebruikers in de tenant van uw Azure AD.The default Azure Information Protection policy is automatically assigned to all users in your tenant's Azure AD. U kunt echter ook aanvullende labels toewijzen aan bepaalde gebruikers of groepen door gebruik te maken van beleidsregels binnen het bereik.However, you can also assign additional labels to specified users or groups by using scoped policies.

Voor het toewijzen van gebruiksrechten en besturingselementen voor toegang wanneer u de Azure Rights Management-service gebruikt voor de beveiliging van documenten en e-mailberichten.For assigning usage rights and access controls when you use the Azure Rights Management service to protect documents and emails. Beheerders en gebruikers kunnen deze gebruikers en groepen selecteren:Administrators and users can select these users and groups:

  • De gebruiksrechten bepalen of een gebruiker een document of e-mailbericht kan openen en hoe deze kunnen worden gebruikt.Usage rights determine whether a user can open a document or email and how they can use it. U kunt bijvoorbeeld instellen of ze een document of e-mailbericht alleen kunnen lezen, kunnen lezen en afdrukken of kunnen lezen en bewerken.For example, whether they can only read it, or read and print it, or read and edit it.

  • Voor besturingselementen voor toegang geldt een vervaldatum en moet worden opgegeven of een internetverbinding is vereist voor toegang.Access controls include an expiry date and whether a connection to the Internet is required for access.

Voor het configureren van de Azure Rights Management-service ter ondersteuning van specifieke scenario's. Daarom kunnen alleen beheerders deze groepen selecteren.For configuring the Azure Rights Management service to support specific scenarios, and therefore only administrators select these groups. Een aantal voorbeelden van zaken die moeten worden geconfigureerd:Examples include configuring the following:

  • Supergebruikers, zodat aangewezen services of personen indien nodig versleutelde inhoud kunnen openen voor eDiscovery of gegevensherstel.Super users, so that designated services or people can open encrypted content if required for eDiscovery or data recovery.

  • Gedelegeerd beheer van de Azure Rights Management-service.Delegated administration of the Azure Rights Management service.

  • Onboarding besturingselementen ter ondersteuning van een gefaseerde implementatie.Onboarding controls to support a phased deployment.

Vereisten voor Azure Information Protection voor gebruikersaccountsAzure Information Protection requirements for user accounts

Voor het toewijzen van labels:For assigning labels:

  • Alle gebruikersaccounts in Azure AD kunnen worden gebruikt om beleidsregels binnen een bereik te configureren voor de toewijzing van extra labels aan gebruikers.All user accounts in Azure AD can be used to configure scoped policies that assign additional labels to users.

Voor het toewijzen van gebruiksrechten en besturingselementen voor toegang en de configuratie van de Azure Rights Management-service:For assigning usage rights and access controls, and configuring the Azure Rights Management service:

  • Voor de autorisatie van gebruikers worden twee kenmerken in Azure AD gebruikt: proxyAddresses en userPrincipalName.To authorize users, two attributes in Azure AD are used: proxyAddresses and userPrincipalName.

  • Het kenmerk Azure AD proxyAddresses slaat alle e-mailadressen voor een account op en kan op verschillende manieren worden gevuld.The Azure AD proxyAddresses attribute stores all email addresses for an account and can be populated in different ways. Bijvoorbeeld: een Office 365-gebruiker die een Exchange Online-postbus heeft, krijgt automatisch een e-mailadres dat in dit kenmerk wordt opgeslagen.For example, a user in Office 365 that has an Exchange Online mailbox automatically has an email address that is stored in this attribute. Als u een alternatief e-mailadres toewijst voor een Office 365-gebruiker, wordt dit adres ook opgeslagen in dit kenmerk.If you assign an alternative email address for an Office 365 user, it is also saved in this attribute. Het kan ook worden gevuld met de e-mailadressen die zijn gesynchroniseerd vanuit lokale accounts.It can also be populated by the email addresses that are synchronized from on-premises accounts.

    Azure Information Protection kan elke waarde in het Azure AD-kenmerk proxyAddresses gebruiken, op voorwaarde dat het domein aan uw tenant is toegevoegd (een zogenaamd geverifieerd domein).Azure Information Protection can use any value in this Azure AD proxyAddresses attribute, providing the domain has been added to your tenant (a "verified domain"). Ga voor meer informatie over het verifiëren van domeinen naar:For more information about verifying domains:

  • Het kenmerk Azure AD userPrincipalName wordt alleen gebruikt als een account in uw tenant geen waarden in het Azure AD proxyAddresses-kenmerk heeft.The Azure AD userPrincipalName attribute is used only when an account in your tenant doesn't have values in the Azure AD proxyAddresses attribute. Bijvoorbeeld: u maakt een gebruiker in Azure Portal of een gebruiker voor Office 365 die geen postbus heeft.For example, you create a user in the Azure portal, or create a user for Office 365 that doesn't have a mailbox.

Gebruiksrechten en besturingselementen voor toegang toewijzen aan externe gebruikersAssigning usage rights and access controls to external users

Naast het gebruik van de Azure AD proxyAddresses en Azure AD userPrincipalName voor gebruikers in uw tenant, gebruikt Azure Information Protection deze kenmerken ook voor het autoriseren van gebruikers van een andere tenant.In addition to using the Azure AD proxyAddresses and Azure AD userPrincipalName for users in your tenant, Azure Information Protection also uses these attributes in the same way to authorize users from another tenant.

Vereisten voor Azure Information Protection voor groepsaccountsAzure Information Protection requirements for group accounts

Voor het toewijzen van labels:For assigning labels:

  • Als u beleidsregels met bereik wilt configureren waarmee extra labels worden toegewezen aan groepsleden, kunt u elk type groep in Azure AD gebruiken met een e-mailadres dat een geverifieerd domein voor de tenant van de gebruiker bevat.To configure scoped policies that assign additional labels to group members, you can use any type of group in Azure AD that has an email address that contains a verified domain for the user's tenant. Een groep met een e-mailadres wordt vaak een groep met e-mail genoemd.A group that has an email address is often referred to as a mail-enabled group.

    U kunt bijvoorbeeld een beveiligingsgroep met e-mail gebruiken, een distributiegroep (deze kan statisch of dynamisch zijn) of een Office 365-groep.For example, you can use a mail-enabled security group, a distribution group (which can be static or dynamic), and an Office 365 group. U kunt geen beveiligingsgroep (dynamisch of statisch) gebruiken, omdat dit type groep geen e-mailadres heeft.You cannot use a security group (dynamic or static) because this group type doesn't have an email address.

Voor het toewijzen van gebruiksrechten en besturingselementen voor toegang:For assigning usage rights and access controls:

  • U kunt elk type groep in Azure AD gebruiken met een e-mailadres dat een geverifieerd domein voor de tenant van de gebruiker bevat.You can use any type of group in Azure AD that has an email address that contains a verified domain for the user's tenant. Een groep met een e-mailadres wordt vaak een groep met e-mail genoemd.A group that has an email address is often referred to as a mail-enabled group.

Voor de configuratie van de Azure Rights Management-service:For configuring the Azure Rights Management service:

  • U kunt elk type groep in Azure AD gebruiken met een e-mailadres van een geverifieerd domein in uw tenant, met één uitzondering.You can use any type of group in Azure AD that has an email address from a verified domain in your tenant, with one exception. De uitzondering is wanneer u onboarding besturingselementen voor een groep configureert. Dit moet een beveiligingsgroep in Azure AD voor uw tenant zijn.That exception is when you configure onboarding controls to use a group, which must be a security group in Azure AD for your tenant.

  • U kunt elke groep in Azure AD gebruiken (met of zonder e-mailadres) van een geverifieerd domein in uw tenant voor gedelegeerd beheer van de Azure Rights Management-service.You can use any type of group in Azure AD (with or without an email address) from a verified domain in your tenant for delegated administration of the Azure Rights Management service.

Gebruiksrechten en besturingselementen voor toegang toewijzen aan externe groepenAssigning usage rights and access controls to external groups

Naast het gebruik van de Azure AD proxyAddresses voor groepen in uw tenant, gebruikt Azure Information Protection dit kenmerk ook voor de autorisatie van gebruikers van een andere tenant.In addition to using the Azure AD proxyAddresses for groups in your tenant, Azure Information Protection also uses this attribute in the same way to authorize groups from another tenant.

Accounts van Active Directory lokaal gebruiken voor Azure Information ProtectionUsing accounts from Active Directory on-premises for Azure Information Protection

Als u lokaal beheerde accounts hebt die u wilt gebruiken met Azure Information Protection, moet u deze accounts synchroniseren naar Azure AD.If you have accounts that are managed on-premises that you want to use with Azure Information Protection, you must synchronize these to Azure AD. Voor een eenvoudige implementatie, raden wij aan dat u Azure AD Connect gebruikt.For ease of deployment, we recommend that you use Azure AD Connect. U kunt elke synchronisatiemethode voor mappen gebruiken. Hiermee behaalt u hetzelfde resultaat.However, you can use any directory synchronization method that achieves the same result.

Als u uw accounts synchroniseert, hoeft u niet alle kenmerken te synchroniseren.When you synchronize your accounts, you do not need to synchronize all attributes. Zie het gedeelte Azure RMS in de Azure Active Directory-documentatie voor een lijst kenmerken die moeten worden gesynchroniseerd.For a list of the attributes that must be synchronized, see the Azure RMS section from the Azure Active Directory documentation.

In de lijst kenmerken voor Azure Rights Management ziet u dat voor gebruikers de on-premises AD-kenmerken mail, proxyAddresses en userPrincipalName zijn vereist voor synchronisatie.From the attributes list for Azure Rights Management, you see that for users, the on-premises AD attributes of mail, proxyAddresses, and userPrincipalName are required for synchronization. De waarden voor mail en proxyAddresses worden gesynchroniseerd met het proxyAddresses-kenmerk van Azure AD.Values for mail and proxyAddresses are synchronized to the Azure AD proxyAddresses attribute. Zie How the proxyAddresses attribute is populated in Azure AD (Hoe het kenmerk proxyAddresses wordt gevuld in Azure AD) voor meer informatieFor more information, see How the proxyAddresses attribute is populated in Azure AD

Bevestigen dat uw gebruikers en groepen zijn voorbereid voor Azure Information ProtectionConfirming your users and groups are prepared for Azure Information Protection

U kunt Azure AD PowerShell gebruiken om te bevestigen dat gebruikers en groepen kunnen worden gebruikt met Azure Information Protection.You can use Azure AD PowerShell to confirm that users and groups can be used with Azure Information Protection. U kunt ook PowerShell gebruiken om de waarden te bevestigen die kunnen worden gebruikt voor de autorisatie.You can also use PowerShell to confirm the values that can be used to authorize them.

Voor het gebruik van bijvoorbeeld de V1 PowerShell-module voor Azure Active Directory, MSOnline, in een PowerShell-sessie, moet u eerst verbinding maken met de service en uw referenties als globale beheerder opgeven:For example, using the V1 PowerShell module for Azure Active Directory, MSOnline, in a PowerShell session, first connect to the service and supply your global admin credentials:

Connect-MsolService

Opmerking: als deze opdracht niet werkt, kunt u Install-Module MSOnline uitvoeren om de MSOnline-module te installeren.Note: If this command doesn't work, you can run Install-Module MSOnline to install the MSOnline module.

Vervolgens configureert u de PowerShell-sessie zodat de waarden niet worden afgekapt:Next, configure your PowerShell session so that it doesn't truncate the values:

$Formatenumerationlimit =-1

Bevestigen dat gebruikersaccounts gereed zijn voor Azure Information ProtectionConfirm user accounts are ready for Azure Information Protection

Om de gebruikersaccounts te bevestigen, voert u de volgende opdracht uit:To confirm the user accounts, run the following command:

Get-Msoluser | select DisplayName, UserPrincipalName, ProxyAddresses

Als eerste moet u ervoor zorgen dat de gebruikers die u wilt gebruiken met Azure Information Protection, worden weergegeven.Your first check is to make sure that the users you want to use with Azure Information Protection are displayed.

Vervolgens controleert u of de kolom ProxyAddresses is gevuld.Then check whether the ProxyAddresses column is populated. Als dit het geval is, kunt u de e-mailwaarden in deze kolom gebruiken om het gebruik van de Azure Rights Management-service te autoriseren.If it is, the email values in this column can be used to authorize the user for the Azure Rights Management service.

Als de kolom ProxyAddresses niet is gevuld, wordt de waarde in UserPrincipalName gebruikt voor de autorisatie van de gebruiker voor de Azure Rights Management-service.If the ProxyAddresses column is not populated, the value in the UserPrincipalName is used to authorize the user for the Azure Rights Management service.

Bijvoorbeeld:For example:

WeergavenaamDisplay Name UserPrincipalNameUserPrincipalName ProxyAddressesProxyAddresses
Jagannath ReddyJagannath Reddy jagannathreddy@contoso.com {}{}
Ankur RoyAnkur Roy ankurroy@contoso.com {SMTP:ankur.roy@contoso.com, smtp: ankur.roy@onmicrosoft.contoso.com}{SMTP:ankur.roy@contoso.com, smtp: ankur.roy@onmicrosoft.contoso.com}

In dit voorbeeld:In this example:

  • Het gebruikersaccount voor Jagannath Reddy wordt geautoriseerd door jagannathreddy@contoso.com .The user account for Jagannath Reddy will be authorized by jagannathreddy@contoso.com.

  • Het gebruikersaccount voor Ankur Roy kan worden geautoriseerd met behulp van ankur.roy@contoso.com en ankur.roy@onmicrosoft.contoso.com, maar niet met ankurroy@contoso.com.The user account for Ankur Roy can be authorized by using ankur.roy@contoso.com and ankur.roy@onmicrosoft.contoso.com, but not ankurroy@contoso.com.

Doorgaans komt de waarde voor UserPrincipalName overeen met een van de waarden in het veld ProxyAddresses.In most cases, the value for UserPrincipalName matches one of the values in the ProxyAddresses field. Dit is de aanbevolen configuratie, maar als u uw UPN niet kunt wijzigen zodat deze overeenkomt met het e-mailadres, moet u de volgende stappen uitvoeren:This is the recommended configuration but if you cannot change your UPN to match the email address, you must take the following steps:

  1. Als de domeinnaam in de UPN-waarde een geverifieerd domein is voor uw Azure AD-tenant, voegt u de UPN-waarde toe als een ander e-mailadres in Azure AD, zodat de UPN-waarde kan worden gebruikt voor de autorisatie van het gebruikersaccount voor Azure Information Protection.If the domain name in the UPN value is a verified domain for your Azure AD tenant, add the UPN value as another email address in Azure AD so that the UPN value can now be used to authorize the user account for Azure Information Protection.

    Als de domeinnaam in de UPN-waarde geen geverifieerd domein voor uw tenant is, kan deze niet worden gebruikt met Azure Information Protection.If the domain name in the UPN value is not a verified domain for your tenant, it cannot be used with Azure Information Protection. De gebruiker kan echter wel worden geautoriseerd als lid van een groep wanneer het e-mailadres van de groep gebruikmaakt van een geverifieerd domein.However, the user can still be authorized as a member of a group when the group email address uses a verified domain name.

  2. Als de UPN-waarde niet routeerbaar is (bijvoorbeeld ankurroy@contoso.local), configureert u de alternatieve aanmeldings-id voor gebruikers en laat u hen weten hoe ze zich moeten aanmelden bij Office via deze alternatieve aanmeldingsprocedure.If the UPN is not routable (for example, ankurroy@contoso.local), configure alternate login ID for users and instruct them how to sign in to Office by using this alternate login. U moet ook een registersleutel instellen voor Office.You must also set a registry key for Office.

    Zie Configuring Alternate Login ID (Alternatieve aanmeldings-id configureren) en Office applications periodically prompt for credentials to SharePoint Online, OneDrive, and Lync Online (Office-toepassingen vragen periodiek om referenties voor SharePoint Online, OneDrive en Lync Online) voor meer informatie.For more information, see Configuring Alternate Login ID and Office applications periodically prompt for credentials to SharePoint Online, OneDrive, and Lync Online.

Tip

Met de cmdlet Export-Csv kunt u de resultaten exporteren naar een spreadsheet voor eenvoudiger beheer, zodat u bijvoorbeeld eenvoudig kunt zoeken en bulksgewijs kunt bewerken voor importeren.You can use the Export-Csv cmdlet to export the results to a spreadsheet for easier management, such as searching and bulk-editing for import.

Bijvoorbeeld: Get-MsolGroup | select DisplayName, ProxyAddresses | Export-Csv -Path UserAccounts.csvFor example: Get-MsolGroup | select DisplayName, ProxyAddresses | Export-Csv -Path UserAccounts.csv

Bevestigen dat groepsaccounts gereed zijn voor Azure Information ProtectionConfirm group accounts are ready for Azure Information Protection

Als u groepsaccounts wilt bevestigen, voert u de volgende opdracht uit:To confirm group accounts, use the following command:

Get-MsolGroup | select DisplayName, ProxyAddresses

Zorg ervoor dat de groepen die u wilt gebruiken met Azure Information Protection, worden weergegeven.Make sure that the groups you want to use with Azure Information Protection are displayed. Voor de weergegeven groepen kan het e-mailadres in de kolom ProxyAddresses worden gebruikt voor het autoriseren van de groepsleden voor de Azure Rights Management-service.For the groups displayed, the email addresses in the ProxyAddresses column can be used to authorize the group members for the Azure Rights Management service.

Controleer vervolgens of de groepen de gebruikers (of andere groepen) bevatten die u wilt gebruiken voor Azure Information Protection.Then check that the groups contain the users (or other groups) that you want to use for Azure Information Protection. U kunt hiervoor PowerShell gebruiken (bijvoorbeeld Get-MsolGroupMember), of uw beheerportal.You can use PowerShell to do this (for example, Get-MsolGroupMember), or use your management portal.

U kunt voor de twee configuratiescenario's voor de Azure Rights Management-service die gebruikmaken van beveiligingsgroepen de volgende PowerShell-opdracht gebruiken om de object-id te vinden en de naam weer te geven die kan worden gebruikt om deze groepen te identificeren.For the two Azure Rights Management service configuration scenarios that use security groups, you can use the following PowerShell command to find the object ID and display name that can be used to identify these groups. U kunt ook Azure Portal gebruiken om deze groepen te vinden en de waarden voor de object-id's en de weergavenaam kopiëren:You can also use the Azure portal to find these groups and copy the values for the object ID and the display name:

Get-MsolGroup | where {$_.GroupType -eq "Security"}

Overwegingen voor Azure Information Protection als e-mailadressen worden gewijzigdConsiderations for Azure Information Protection if email addresses change

Als u het e-mailadres van een gebruiker of groep wijzigt, is het verstandig dat u het oude e-mailadres toevoegt als een tweede e-mailadres (ook wel bekend als een proxy-adres, alias of alternatief e-mailadres) aan de gebruiker of groep.If you change the email address of a user or group, we recommend that you add the old email address as a second email address (also known as a proxy address, alias, or alternate email address) to the user or group. Als u dit doet, wordt het oude e-mailadres toegevoegd aan het kenmerk proxyAddresses van Azure AD.When you do this, the old email address is added to the Azure AD proxyAddresses attribute. Op deze manier zorgt u voor bedrijfscontinuïteit voor eventuele gebruiksrechten of andere configuraties die zijn opgeslagen tijdens het gebruik van het oude e-mailadres.This account administration ensures business continuity for any usage rights or other configurations there were saved when the old email address was in use.

Als dit niet mogelijk is, krijgt de gebruiker of groep met het nieuwe e-mailadres mogelijk geen toegang tot documenten en e-mailberichten die eerder zijn beveiligd en andere configuraties die gebruikmaakten van deze oude waarde.If you cannot do this, the user or group with the new email address risks being denied access to documents and emails that were previously protected, and other misconfigurations that used the old value. In dit geval moet u de configuratie herhalen voor het opslaan van het nieuwe e-mailadres.In this case, you must repeat the configuration to save the new email address.

Het is overigens zeldzaam dat een groep het e-mailadres wijzigt. Als u gebruiksrechten hebt toegekend aan een groep in plaats van aan individuele gebruikers, maakt het niet uit als het e-mailadres wordt gewijzigd.Note that it's rare for a group to change its email address and if you assign usage rights to a group rather to than individual users, it doesn't matter if the user's email address changes. In dit geval worden de gebruiksrechten toegekend aan het e-mailadres van de groep, niet aan individuele e-mailadressen.In this scenario, the usage rights are assigned to the group email address and not individual user email addresses. Dit is de meest waarschijnlijke (en aanbevolen) methode voor een beheerder om gebruiksrechten te configureren waarmee documenten en e-mailberichten worden beveiligd.This is the most likely (and recommended) method for an administrator to configure usage rights that protect documents and emails. Gebruikers wijzen echter meestal aangepaste machtigingen voor individuele gebruikers toe.However, users might more typically assign custom permissions for individual users. Aangezien u niet altijd kunt weten of een gebruikersaccount of een groep is gebruikt om toegang te verlenen, is het verstandig het oude e-mailadres toe te voegen als een tweede e-mailadres.Because you cannot always know whether a user account or group has been used to grant access, it's safest to always add the old email address as a second email address.

De opslag van groepslidmaatschappen in cache door Azure Rights ManagementGroup membership caching by Azure Rights Management

Uit prestatieoverwegingen worden groepslidmaatschappen in cache opgeslagen door de Azure Rights Management-service.For performance reasons, group membership is cached by the Azure Rights Management service. Dat betekent dat alle wijzigingen aan groepslidmaatschappen in Azure AD pas na maximaal drie uur van kracht worden als deze groepen worden gebruikt door Azure Rights Management. Deze tijd is onderhevig aan wijzigingen.This means that any changes to group membership in Azure AD can take up to three hours to take effect when these groups are used by Azure Rights Management, and this time period is subject to change.

Houd rekening met deze vertraging in wijzigingen en tests die u uitvoert voor groepen voor Azure Rights Management, zoals het toewijzen van gebruiksrechten of de configuratie van de Azure Rights Management-service.Remember to factor this delay into any changes or testing that you do when you use groups for Azure Rights Management, such as assigning usage rights or configuring the Azure Rights Management service.

Volgende stappenNext steps

Zodra u hebt bevestigd dat uw gebruikers en groepen kunnen worden gebruikt met Azure Information Protection en u klaar bent om te beginnen met het beveiligen van documenten en e-mailberichten, activeert u de Rights Management-service om deze gegevensbeveiligingsservice uit te voeren.When you have confirmed that your users and groups can be used with Azure Information Protection and you are ready to start protecting documents and emails, activate the Rights Management service to enable this data protection service. Zie voor meer informatie Azure Rights Management activeren.For more information, see Activating Azure Rights Management.

OpmerkingenComments

Voordat u opmerking invoert, vragen we u onze regels door te lezen.Before commenting, we ask that you review our House rules.