Tag Archives: security

Using GraphLicenseManager to view group members and reprocess users…

1 Reply

When using group based licensing errors may arise in the license assignment process. In the Microsoft 365 Administrative Center when selecting a license, expanding groups, the list of groups assigning that license are displayed along with the groups processing status.

To review the errors associated with the license assignment the group may be selected from this view. This will display the list of users that require action and provide information regarding the failure status.

In this example the license assignment is failing due to conflicting service plans. As discussed in other articles this is a common error when two license assignments are occurring and each license contains a plan that conflicts with one another. To reprocess a license assignment the users may be selected in bulk or individually and the reprocess button selected.

When reprocessing is successful the user will be removed from the actions needed dialog. If reprocessing of a user fails a red error banner is displayed.

In the M365 Admin Center when an error is encountered during reprocessing there is little diagnostic information provided as to the cause of the failure. To discover the cause of the failure the audit log entries in the Entra portal for the users must be reviewed.

In the audit log when reviewing the “change user license” activity the license error message provides the feedback necessary to understand the error.

The license can't be assigned because the user has licensed service plans that conflict with plans in the new license. Resolve these conflicting service plan pairs to solve this problem: [7547a3fe-08ee-4ccb-b430-5077c5041653, 2078e8df-cff6-4290-98cb-5408261a760a]. Licenses being added: [314c4481-f395-4525-be8b-2ec4bb1e9d91]

The current design of the M365 Admin Center does not include this verbose information requiring the administrator to utilize multiple tools to understand the nature of the failure.

In version 1.1.3 of the GraphLicenseManager the ability to review group members and reprocess individual license assignments has been added. In addition, any reprocessing failures are presented to the administrator at reprocessing time combining both reprocessing and failure assessment into the same tool.

To utilize the GraphLicenseManager to perform this work:

Set-ExecutionPolicy Unrestricted
Install-Module GraphLicenseManager
Start-GraphLicenseManager -logFolderPath c:\temp

When the GraphLicenseManager starts a logon screen is displayed to connect to Microsoft Graph. The module supports either interactive authentication or certificate based authentication.

When selecting interactive authentication, the administrator may select the scopes required to perform functions in the license manager. The default settings are the least permissions required to perform functions. When using the GraphLicenseManager to view group members, group member errors, and reprocess users the optional user permissions must be specified. Setting any user permissions will enable the option to view group membership and group processing errors. Setting user permissions to Directory.ReadWrite.All or User.ReadWrite.All will enable the reprocessing option in the group members view.

When using certificate authentication, the appropriate permissions must be assigned to the app registration created in Entra. The same permissions for interactive authentication are required for the app registration.

If no user permissions are selected the module will examine all scopes returned in the graph connection. If the scopes returned contain the necessary permissions to view group members and / or reprocess group errors those options are automatically enabled.

After completing the connection to Microsoft Graph the Group License Manager is displayed. Searching a group object id displays the licenses assigned to the group and a table of all license information within the tenant. If the necessary graph scopes are available the “View Group Info” button is enabled in the center of the manager.

Selecting the “View Group Info” button displays the “Group Information Page” Note: As this page enumerates a table of all members for review it can take some time to render the information.

The group information display shows all the members of the group, all group license errors, and basic information regarding the processing status and group statistics. In the “Group License Errors” table a user may be elected for reprocessing. If the necessary graph scopes are abled the “Reprocess Selected Users” and “Refresh License Errors” buttons are enabled.

To reprocess a user select one or more users and the reprocess selected users button.

In this example selecting a user and the reprocess option shows an error message.

This is expected since the users are in error, and nothing has been done to correct the condition. The error message provides information regarding the license plans in conflict. The guids can be searched to determine which plan and sku are generating the conflict. In this example the plans in conflict are the Yammer plans. There are multiple potential methods to resolve this issue but for the sake of this example I will simply remove the offending license.

With the conflict resolve the reprocess option may be utilized. If the license reprocessing is now successful for all users selected a success message is displayed.

To confirm that all errors on the group have been rectified the “Refresh License Errors” button is selected. This refreshes the group license errors. In this example all license errors are now clear.

I hope that by bringing together the ability to manage group licenses and group license errors into a single tool we can make the adoption and management of group-based licensing simpler and more efficient.

Using GraphLicenseManager to generate license reports…

Leave a reply

Microsoft 365 administrators utilize a variety of tools to manage and monitor license usage and assignments. In the Microsoft 365 Admin Center administrators often review and export a list of users assigned to the different SKUs within their tenant. This is done by selecting Billing -> Licenses -> and selecting a license.

The export button allows the administrator to export to CSV the list of users assigned the license. I have recently spoken with several customers that have noticed that the export has changed the information provided. For example, in prior releases of the Microsoft 365 Admin Center the export contained the field Blocked Users (Account Enabled). This field, along with many others, are no longer present in the download offered through the portal.

With the evolving changes in the Microsoft 365 Admin Center surrounding license management and assignment the interfaces previously responsible for providing this data have been deprecated. With this deprecation arose the need to change the fields contained in the download. Unfortunately, this is not something that is administratively configured.

In order to generate the data previously available I have added functions to the GraphLicenseManager to generate the CSV files. In addition to providing some of the missing fields, I have provided an interface that allows administrators to select all single value attributes returned by get-MGUser.

To begin utilizing the GraphLicenseManager:

Set-ExecutionPolicy Unrestricted

Install-Module GraphLicenseManager

When the graph license manager is installed, the process starts with:

Start-GraphLicenseManager -logFolderPath c:\temp

The graph license manager is a combination of PowerShell and Windows Forms. When the start command is executed the login screen is displayed.

On the logon screen a TenantID is required to establish the graph connection. This can easily be obtained from the EntraID properties in the Entra Portal. To establish permissions either certificate authentication or interactive credentials may be utilized. For those interested in setting up certificate-based authentication for Microsoft Graph see:

Use Certificate Authentication for Microsoft Graph

In the selected operation drop down select “License Assignment Report”. If you are a customer in a different graph environment, use the graph environment selection dropdown to select the environment.

The license report requires a minimum of two permissions:

  • Directory Permission: Organization.Read.All
  • User Permission: User.Read

When using interactive credentials, the user may select any of the roles they qualify for. It is important to note that when establishing the graph connection if the permissions requested are not already assigned to the user an administrator may be required to provide consent to the permissions.

After selecting the authentication method, operation type, and required permissions the Connect Microsoft Graph button completes the connection.

When the connection has completed successfully the License Assignment Report wizard is displayed.

Selecting the Sku Name drop down allows the administrator to view all license assignments associated with all user skus in the tenant. The list updates dynamically with each SKU selected.

The properties dialog allows the administrator to select properties. The refresh button applies the administrator selections to the information displayed for each user.

To retain the data displayed the Export to CSV button may be utilized. When selected all data shown in the users view is exported to a CSV file within the log file directory. If exporting multiple SKUs a CSV file is created for each sku selected. NOTE: If exporting the same sku with different values any previous export for the same sku is overwritten.

When completed the exit button closes the Graph License Manager.

Using the Graph License Manager administrators can produce a variety of customized reports expanding on the information previously offered in the Microsoft 365 Admin Center.

Request to change a users password…

Leave a reply

EntraID provides methods for administrators to enable end users to manage and reset their passwords utilizing Microsoft cloud services. This feature is known as Self Service Password Reset.

Users may begin the password reset process by directly accessing the password reset URL. Microsoft Online Password Reset

The password reset process starts by requesting the user provide their sign on name and complete a character validation.

When the form is completed the next button allows the user to proceed with the process. If the account is valid, enabled for self-service password reset, and meets the authentication methods requirements for the feature the process will continue. If for some reason the users account information cannot be validated, for example they are not enabled for self-service password reset or the user has not proofed up authentication methods that would allow for self-service password reset, the following screen is displayed.

In this dialog the user has the option to “contact an administrator”. When this option is selected the process concludes with the following dialog.

When this option is selected, an email is generated to administrators of the tenant informing them of the request to reset the password. On the surface this email looks highly suspicous.

When the email is received by administrators there are often questions regarding the validity and authenticity. Here are some methods to review the email for ligitimacy.

Review the message header for basic antispam evaluation. For example, errors in the SPF record evaluation or DKIM signing of the message.

4Authentication-Resultsspf=pass (sender IP is 40.93.12.1) smtp.mailfrom=microsoftonline.com; dkim=pass (signature was verified) header.d=microsoftonline.com;dmarc=pass action=none header.from=microsoftonline.com;compauth=pass reason=100

See Anti-spam message headers in Microsoft 365 for more information on interpreting message headers in Microsoft 365.

The EntraID audit logs for the user account may also shed light into the validity of this email. When a user enters the password reset process, if the username is valid, entries are generated in the EntraID audit log.

This entry provides information that the user entered the flow and provided a user name.

Date10/16/2024, 12:59 PM
Activity TypeSelf-service password reset flow activity progress
Correlation IDc6aa42ec-e2d9-4315-8bed-3fe5953def80
CategoryUserManagement
Statussuccess
Status reasonUser submitted their user ID
User Agent
TypeUser
Display Name
Object IDcd7a9aeb-f5b2-494e-b72e-7ae6d8d1af16
IP address20.110.218.7
User Principal NameUPN

The next event in the audit log shows the source of the contact administrator dialog. In this case the user account had insufficient authentication methods to allow the user to perform their own reset. There could be other failure categories here that lead to the contact administrator dialog – this is just one.

Date10/16/2024, 12:59 PM
Activity TypeSelf-service password reset flow activity progress
Correlation IDc6aa42ec-e2d9-4315-8bed-3fe5953def80
CategoryUserManagement
Statusfailure
Status reasonUser’s account has insufficient authentication methods defined. Add authentication info to resolve this
User Agent
TypeUser
Display Name
Object IDcd7a9aeb-f5b2-494e-b72e-7ae6d8d1af16
IP address20.110.218.7
User Principal NameUPN

The audit log information should be helpful in determining not only if the email received is legitimate but also if the end user themselves triggered the password reset workflow.

If the information in the audit log and the message header checks out the legitimacy of the message maybe verified.

==================

Entire email contents below for parsing.

==================

Request to reset user’s password

The following user in your organization has requested a password reset be performed for their account:

  • UsageLocation@domain.onmicrosoft.com
  • First Name:
  • Last Name:

Consider contacting this user to validate this request is authentic before continuing.

If you have determined that this is a valid request, use your service’s admin portal (Office 365, Windows Intune, Windows Azure, etc.) to reset the password for this user.

Want to let you users reset their own passwords? Check out how you can enable password reset for users in your organization with just a few clicks.

Sincerely,

E-McMichael

==================

Office 365 – Distribution List Migrations – Part 42

Leave a reply

Increasing the success of Distribution List Migrations

When migrating a distribution list to Office 365 the DLConversionV2 module implements a normalization process for all recipients that are members of the distribution list.

The normalization process attempts to convert the recipient from an Active Directory object to an Exchange Online object. The goal of the normalization process is to ensure that we locate the correct recipient in Exchange Online when creating the distribution list and eliminate ambiguous recipient discovery. If an ambiguous recipient is located in Exchange Online this can lead to a migration failure and require the administrator to correct the condition post migration.

When a user is encountered on the properties of a distribution list being migrated the user is normalized by using the attribute msDS-ExternalDirectoryObjectID. In an Entra Connect Sync environment the msDS-ExternalDirectoryObjectID is populated with the value User_ExternalDirectoryObjectID. The ExternalDirectoryObjectID is the objectID associated with the user in EntraID. This same value is also stamped on all Exchange Online objects in the attribute ExternalDirectoryObjectID.

msDS-ExternalDirectoryObjectID = Entra ObjectID = Exchange Online ExternalDirectoryObjectID

PS C:\> Get-ADUser "DistinguishedName" -Properties msDS-ExternalDirectoryObjectID


DistinguishedName              : DistinguishedName
Enabled                        : False
GivenName                      :
msDS-ExternalDirectoryObjectID : User_8ac654f2-2125-4252-b9b0-d2219b9bb395
Name                           : Name
ObjectClass                    : user
ObjectGUID                     : ObjectGUID
SamAccountName                 : SamAccountName
SID                            : SID
Surname                        :
UserPrincipalName              : UserPrincipalName

When searching Exchange Online using the get-recipient command (or any similar get command) the ExternalDirectoryObjectID can be utilized as a recipient identifier.

In a default Entra Connect installation the attribute msDS-ExternalDirectoryObjectID is written back to Active Directory only on User object types. Groups and Contacts do not have the same attribute written back. When performing a migration if a Contact or Group is encountered the recipients are normalized to their Exchange Online counterparts through the object PrimarySMTPAddress. When locating recipients in Exchange Online get-recipient returns results for all objects that match the identifier specified. If a group has the PrimarySMTPAddress of group@contoso.com and a contact has a target address of group@contoso.com get-recipient will return two objects when specifying get-recipient -identity group@contoso.com. During a migration this can lead to a failure as more than object is returned when attempting to perform normalization.

To increase the efficiency of migrations and eliminate possible failures it is possible to enable writeback of the attribute msDS-ExternalDirectoryObjectID to both Contacts and Groups. Why is this not the default? When the writeback rules were created the goal was to optimize the number of changes written back to Active Directory. A decision was made to only populate this value on User objects as that is where it would most commonly be practical to have it. When writing back the same attribute to Groups and Contacts this allows the normalization process to extract the exact matching recipient in Exchange Online.

Migrators wishing to implement this efficiency may refer to a script published to the Powershell Gallery -> EnableCloudAnchor. This script allows administrators to create the necessary writeback rules in Entra Connect Sync to enable msDS-ExternalDirectoryObjectID on Contacts and Groups. When the script is executed two rules are created for each object type. The first rule is enabled and translates the EntraID value CloudAnchor to the msDS-ExternalDirectoryObjectID attribute. The second rule is created disabled and enables undoing all attributes written back by the script. This ensures that an undo operation is pre-staged should a rollback be necessary.

The script has several parameters to be specified:

  • ForestRootFQDN: This is the Active Directory forest root FQDN. This is utilized to locate the connector to enable writeback on.
  • StartingPrecedence: This is the starting precedence value for rule creation and must be specified as a value 0 – 99. For example, specifying a value of 25 will create the writeback rule at precedence 25 and the undo rule at precedence 26. This value is option. If not specified, the script will automatically locate the least two precedence available and automatically use them.
  • EnableContactProcessing: This enables rule creation for contacts and is the default for script execution. If enabling the rules for groups this value must be set to false.
  • EnableGroupProcessing: This enables rule creation for groups and by default is disabled. If this feature is enabled enableContactProcessing must be set to false.
  • LogFolderPath: The location of where script logging should occur.

To utilize the script on the Entra Connect server:

Install-Script EnableCloudAnchor

To create the rules for contacts utilizing auto discovered precedence:

EnableCloudAnchor.ps1 -forestRootFQDN contoso.local -logFolderPath c:\temp

To create the rules for contacts utilizing an administrator provided precedence:

EnableCloudAnchor.ps1 -forestRootFQDN contoso.local -startingPrecedence 24 -logFolderPath c:\temp

To create the rules for groups utilizing an auto discovered precedence:

EnableCloudAnchor.ps1 -forestRootFQDN contoso.local -enableContactProcessing:$FALSE -enableGroupProcessing:$TRUE -logFolderPath c:\temp

In Entra Connect the following rule is created to enable writeback of the cloud anchor attribute (only the relevant screens are displayed):

The following rule is also created in a disabled state to allow undoing the writeback operations:

If the need arises to undo the writeback the first rule would be deleted or placed into a disabled state. The disabled state flag would be unchecked on the second rule. The AuthoritativeNull value is utilized to clear an attribute entirely.

NOTE: Any modification to the rules in Entra Connect Sync will require a full synchronization to occur on the connector associated with the forest specified. This may add significant time to a synchronization option.

When the rules have successfully processed on an object the value Contact_ExternalDirectoryObjectID or Group_ExternalDirectoryObjectID may be found on the objects. 

PS C:\> Get-ADObject DistinguishedName


DistinguishedName              : DistinguishedName
msDS-ExternalDirectoryObjectID : Contact_76b9cf05-510c-4fcc-a1f8-58e4cada17a6
Name                           : Name
ObjectClass                    : contact
ObjectGUID                     : ObjectGUID

When adding the msDS-ExternalDirectoryObjectID to Active Directory objects the normalization process may more accurately identify recipients in Exchange Online increasing the efficiency and success of migrations.

EntraID Group Owners and Exchange Online ManagedBy

Leave a reply

In the EntraID Portal groups that are created directly in Microsoft 365 or synchronized from Active Directory are displayed. One of the attributes that is present on groups in EntraID is the Owners attribute. A common question I receive from customers is that the owners attribute synchronized from Active Directory does not match the owners attribute of the same group in EntraID.

Managers for groups in Active Directory can be established either by setting the Manager field in Active Directory Users and Computers or by using the Exchange Management Shell / Exchange Control Panel. When in ADUC and on the Managed By tab, the name field displays the distinguished name of the manager and is represented in the LDAP attribute managedBy.

In Exchange on-premises installations groups often have more than one manager. Exchange achieves this by writing the first manager to the LDAP attribute managedBy and all subsequent managers to the LDAP attribute msExchCoManagedByLink. ADUC has no knowledge of the additional attributes. The Exchange Management Shell and Exchange Control Panel include managers from both LDAP fields when displaying the managedBy representation.

Get-DistributionGroup ManagedBy | fl managedBy


ManagedBy : {home.domain.com/DLConversion/MigrationTest/Manager User0,
            home.domain.com/DLConversion/MigrationTest/Manager User1,
            home.domain.com/DLConversion/MigrationTest/ManagerGroup}

The managers of an object in Active Directory can be any valid security principal, for example, a user or security group. In the above example the group is managed by two users and a security group. Here is the same representation from Active Directory:

PS C:\> Get-ADGroup -Identity "CN=ManagedBy,OU=MigrationTest,OU=DLConversion,DC=home,DC=domain,DC=com" -Properties managedBy,msExchCoManagedByLink


DistinguishedName     : CN=ManagedBy,OU=MigrationTest,OU=DLConversion,DC=home,DC=domain,DC=com
GroupCategory         : Security
GroupScope            : Universal
ManagedBy             : CN=Manager User0,OU=MigrationTest,OU=DLConversion,DC=home,DC=domain,DC=com
msExchCoManagedByLink : {CN=Manager User1,OU=MigrationTest,OU=DLConversion,DC=home,DC=e-domain,DC=com,
                        CN=ManagerGroup,OU=MigrationTest,OU=DLConversion,DC=home,DC=domain,DC=com}
Name                  : ManagedBy
ObjectClass           : group
ObjectGUID            : c0e9ed6c-22f4-4305-a69a-aee56f0c53b1
SamAccountName        : ManagedBy
SID                   : S-1-5-21-278042269-1514808692-1118015945-448669

In EntraID Connect when an object is synchronized the managedBy and msExchCoManagedByLink attributes are included in the synchronization attribute set. You can observe this by performing a metaverse search on the group and reviewing the attributes discovered during the synchronization process.

A synchronized group is available in the EntraID Portal under groups. When reviewing the group properties a owners field is displayed. The owners field in this case appears empty and no owners are displayed.

If the managers are synchronized, then why is the owners field empty? Owners is not equal to managers. Active Directory Groups or legacy distribution and security groups created in Exchange Online do not have owners they have managers. Managers are not the same as owners at the directory level therefore the owners field is not populated with managers.

In order to review the managers of a group you have to review the properties of the group within Exchange Online. 

PS C:\> Get-DistributionGroup ManagedBy | fl managedBy


ManagedBy : {04cfbcd4-42a0-4c60-8220-4488a6af4431, f7aff7bf-3036-4e26-a193-75a28de751f3}

In this instance the managers are represented by the externalDirectoryObjectID of the recipients. If the recipients existed prior to setting the name attribute to externalDirectoryObjectID the name of the user may be displayed.

PS C:\> Get-Recipient 04cfbcd4-42a0-4c60-8220-4488a6af4431 | fl displayName


DisplayName : Manager User0



PS C:\> Get-Recipient f7aff7bf-3036-4e26-a193-75a28de751f3 | fl displayName


DisplayName : Manager User1

In this example both of the USERS that have manager rights on the group are represented in Exchange Online. Earlier though there were three managers, two were users and the remaining a security group. Unfortunately, Exchange Online does not forward sync any other manager except for user types. The group is synchronized to Entra ID as a manager, but will not be represented on the group in Exchange Online. There is no workaround for this behavior except adding individual members to a manager field in Active Directory.

If the owners field in EntraID does not match the managers then why does the owners field exist? The owners field is utilized to display owners of the Microsoft 365 Group type. These groups are often referred to as modern or universal groups. Setting the owners attribute in EntraID or Exchange Online subsequently adjusts the owners across all Microsoft 365 services. 

PS C:\> Get-UnifiedGroupLinks -Identity ManagedBy-M365Group -LinkType Owners

Name                                 RecipientType
----                                 -------------
04cfbcd4-42a0-4c60-8220-4488a6af4431 MailUser
f7aff7bf-3036-4e26-a193-75a28de751f3 MailUser

Synchronized groups or distribution / security groups created in Exchange Online do not have owners in EntraID.

EntraID / Office 365: Using Graph Powershell to list domain DNS records…

Leave a reply

In the Microsoft 365 Administration center administrators can review the domains they have verified and added to Microsoft 365 services. When a domain is validated and provisioned, the domain name services (DNS) records that are provisioned in Microsoft 365 are displayed for the administrator. This may include records such as the MX record for Exchange Online or the device management records for Intune support.

If the domains blade is not available to you in the Microsoft 365 Administration Center, it is possible to obtain these same records through Microsoft Graph. To obtain the DNS records the command Get-MGDomainServiceConfigurationRecord can be utilized. For API permissions necessary to utilize this command reference the following API permissions guidance.

Whenever utilizing Microsoft Graph commands I always recommend ensuring that the graph commands are running the latest non-preview version. To accomplish this task administrators may run:

Get-InstalledModule Microsoft.Graph.* | update-Module

If you have not yet installed any of the graph modules there are only two modules that are required in order to execute these commands.

Install-Module Microsoft.Graph.Authentication
Install-Module Microsoft.Graph.Identity.DirectoryManagement

Once the necessary modules have been installed or updated a connection to the Microsoft Graph endpoints must be established. In this example interactive authentication is utilized to establish the connection and prompt the user for credentials. The scopes parameter requests the least restrictive permissions to perform this operation. When connecting with graph command if a scope is not consented to for the particular user either consent can be granted by the user (assuming appropriate rights) or an administrator will be required to grant consent. I also provide the tenantID as a part of the connection. The tenantID can be obtained from the Entra ID portal associated with the domain. This ensures that the connection is made with the appropriate tenant.

connect-MGGraph -scopes "Domain.Read.All" -tenantID "00000000-0000-0000-0000-000000000000"

This is a sample consent screen

The command can then be issued using the domain name.

$records = Get-MgDomainServiceConfigurationRecord -DomainId domain.net

The information of particular interest is stored within the additionalProperties of each entry. The following command will help organize and interpret the information:

PS C:\> foreach ($record in $records) { $record.label ; $record.AdditionalProperties | ft}
domain.net

Key          Value
---          -----
@odata.type  #microsoft.graph.domainDnsMxRecord
mailExchange domain-net0c.mail.protection.outlook.com
preference   0


domain.net

Key         Value
---         -----
@odata.type #microsoft.graph.domainDnsTxtRecord
text        v=spf1 include:spf.protection.outlook.com -all


autodiscover.domain.net

Key           Value
---           -----
@odata.type   #microsoft.graph.domainDnsCnameRecord
canonicalName autodiscover.outlook.com


_sip._tls.domain.net

Key         Value
---         -----
@odata.type #microsoft.graph.domainDnsSrvRecord
nameTarget  sipdir.online.lync.com
port        443
priority    100
protocol    _tls
service     _sip
weight      1


sip.domain.net

Key           Value
---           -----
@odata.type   #microsoft.graph.domainDnsCnameRecord
canonicalName sipdir.online.lync.com


lyncdiscover.domain.net

Key           Value
---           -----
@odata.type   #microsoft.graph.domainDnsCnameRecord
canonicalName webdir.online.lync.com


_sipfederationtls._tcp.domain.net

Key         Value
---         -----
@odata.type #microsoft.graph.domainDnsSrvRecord
nameTarget  sipfed.online.lync.com
port        5061
priority    100
protocol    _tcp
service     _sipfederationtls
weight      1


domain.net

Key           Value
---           -----
@odata.type   #microsoft.graph.domainDnsCnameRecord
canonicalName domain.sharepoint.com


msoid.domain.net

Key           Value
---           -----
@odata.type   #microsoft.graph.domainDnsCnameRecord
canonicalName clientconfig.microsoftonline-p.net


enterpriseregistration.domain.net

Key           Value
---           -----
@odata.type   #microsoft.graph.domainDnsCnameRecord
canonicalName enterpriseregistration.windows.net


enterpriseenrollment.domain.net

Key           Value
---           -----
@odata.type   #microsoft.graph.domainDnsCnameRecord
canonicalName enterpriseenrollment-s.manage.microsoft.com

If the DNS record contains a name within the domain this is represented by the label. The @odata.type provides the type of DNS record expected and the value column lists the value of that record. 

enterpriseenrollment.domain.net

Key           Value
---           -----
@odata.type   #microsoft.graph.domainDnsCnameRecord
canonicalName enterpriseenrollment-s.manage.microsoft.com

The previous example would be interpreted as:

DNS Record Name = enterpriseenrollment.domain.net

DNS Record Type = CNAME

DNS Record Value = enterpriseenrollment-s.manage.microsoft.com

domain.net

Key          Value
---          -----
@odata.type  #microsoft.graph.domainDnsMxRecord
mailExchange domain-net0c.mail.protection.outlook.com
preference   0

The previous example would be interpreted as:

DNS Domain = domain.net

DNS Record Type = MX

DNS Record Value = domain-net0c.mail.protection.outlook.com

DNS Record Preference = 0

In this case an MX record does not have a specific DNS host name unlike other records.

These commands should unblock scenarios where the domains blade is unavailable to you and you need to know the appropriate DNS records to create for your Office 365 integration.

Microsoft account unusual sign-in activity

Leave a reply

Microsoft offers a variety of consumer services that end users may sign up for. For example, Xbox accounts, personal OneDrive accounts, and personal office subscriptions. Users may elect to create an account using a Microsoft owned domain (live.com / outlook.com) or through another domain (gmail.com, etc). 

At one time it was possible for users to utilize addresses that were also registered in Office 365. This would essentially allow a user to take their corporate email address and utilize it as an account both in our commercial services and our consumer services. This ability is now blocked once a domain has been added and registered to an Office 365 tenant.

If a user has both an Office 365 and consumer account registered to the same address this generally means:

  • The user established the account prior to when the domain was registered in Office 365.
  • The user established the account prior to the block demonstrated above.

In recent weeks I have spoked with several customers that have raised escalations regarding “Microsoft Account Unusual Sign-in Activity”. In each of these cases the user received an email to their Office 365 email address indicating that unusual sign on activity occurred. When administrators of the tenant were engaged, they were unable to locate any evidence of abnormal sign-ons. The emails originate from “account-security-noreply@accountprotection.microsoft.com” and are addressed to the Office 365 recipient.

In most cases the email address in the TO: line also matches the email address that is obscured. 

When examining the email there are some methods to determine that this event is related to a consumer account. The first method involves reviewing the links contained in the email. In this case there are two links and in each case the links point to accessing consumer services:

Another easy method of confirming if the user has both an Office 365 and consumer account is to launch a browser in in-private mode. Access https://portal.office.com and specify the account email address. If the user is prompted to access either a “Work or School” and a “Personal Account” the user has both.

The last method of verify that a user has both an Office 365 account and a personal account is for administrators to utilize Powershell and our identity tools module. The command has the ability to extract for administrators the presence of a consumer account associated with an Office 365 identity.

Install-Module -Name MSIdentityTools 
Get-MsIdHasMicrosoftAccount -Mail "use@e-domain.com"


True

In this case the return value of TRUE confirms that the user has a consumer identity. 

The user that owns the consumer account should be advised to access the account and review the sign on activity. Administrators may also recommend that the user disassociate their corporate identity from the consumer account using the following instructions: Change the email address or phone number for your Microsoft account (Opens in new window or tab)

Administrators may also find the following information helpful regarding commercial and consumer account overlap.

Entra Connect and Single Object Deletion

Leave a reply

It may become necessary to purge an object an Entra Connect connector space. A connector space exists for each directory that is added to an Entra Connect installation. Typical installations have two connector spaces, one for the local Active Directory and the other for Entra ID. More complex installations may have more than one connector space for Active Director.

When a user object is synchronized to Entra ID the Active Directory attributes are read into the Active Directory connector space. When the object is successfully written to Entra ID, the Entra ID attributes are read into the Entra ID connector space.

In some instances, it becomes necessary to purge the information within a connector space in order to fix a synchronization issue. Purging an object from a connector space allows the Entra Connect process to re-read the objects properties from the directory where the deletion occurred. For example, purging an object from the Active Directory and Entra ID connector spaces will force the object to be re-read from both directories and sync operation performed on the refreshed attributes. It is also possible to remove an object from either of the connector spaces without removing it from both.

To facilitate this process, I have released a script to the Powershell Gallery that automates the remove of the object from one or both connector spaces. The script offers several options to execute.

To save this script to your entra connect server perform the following:

Install-Script Reset-EntraConnectObject

This saves the scripts to the local path. 

The script provides a variety of options for execution each performing slightly different functions. 

Option 1:

This option is used when the Active Directory and Entra Connect distinguished names are both known. This information is generally obtained from a metaverse search and copying the respective distinguished names from the connector spaces. When executed the connector space objects are extracted by distinguished name and a deletion from the connector spaces is processed. A single item synchronization is automatically triggered to refresh each connector space with the objects properies.

reset-EntraConnectObject.ps1 -logFolderPath c:\temp -EntraDN "CN={4272736E37395A7742456D3474535578366A746558413D3D}" -ADObjectDN "CN=Tim McMichael,OU=Users,OU=Objects,DC=home,DC=domain,DC=com"

Option 2

This option is used when only Active Directory information is known, and an object deletion should occur from both the Active Directory and Entra connector spaces. When executed an Active Directory call is made to locate the user by either distinguished name, objectGUID, or mail attribute. This call is made using the specified domain controller and credentials. When the user is located the sourceAnchor for the Entra Connect installation is determined and the Entra ID distinguished name is automatically calculated. A deletion from each connector space is processed. A single item synchronization is automatically triggered to refresh each connector space with the object properties. This is helpful if you only have access to the Active Directory information or are unable to perform a metaverse search to determine distinguished name values.

#If get-credential returns an error message "Get-Credential : Cannot process command because of one or more missing mandatory parameters: Credential" do the following:

Set-ItemProperty "HKLM:\SOFTWARE\Microsoft\PowerShell\1\ShellIds" -Name "ConsolePrompting" -Value $True

Option 2A: Remove object by Active Directory Distinguished Name

#The following instructions locate the object by Active Directory Distinguished Name

$cred = get-credential #Provide credential of person with rights to read attributes from active directory

$globalCatalogServer = "DC.domain.com" #FQDN of a global catalog server

$DN = "CN=Tim McMichael,OU=Users,OU=Objects,DC=home,DC=domain,DC=com"

reset-EntraConnectObject.ps1 -logFolderPath c:\temp -ADObjectDN $dn -globalCatalogServer $globalCatalogServer -activeDirectoryCredential $cred

Option 2B: Remove object by Active Directory Mail Attribute

#The following instructions locate the object by Active Directory Mail Attribute 

$cred = get-credential #Provide credential of person with rights to read attributes from active directory

$mail = "tim@domain.com" #Active directory mail attribute

$globalCatalogServer = "DC.Domain.com"

reset-EntraConnectObject.ps1 -logFolderPath c:\temp -ADObjectmail $mail -activeDirectoryCredential $cred -globalCatalogServer $globalCatalogServer

Option 2C: Remove object by Active Directory ObjectGUID

#The following instructions locate the object by Active Directory objectGUID

$cred = get-credential #Provide credential of person with rights to read attributes from active directory

$globalCatalogServer = "DC.domain.com" #FQDN of a global catalog server

$objectGUID = "ef27bb06-70d6-4904-b8b5-2531ea3b5e5c"

reset-EntraConnectObject.ps1 -logFolderPath c:\temp -ADObjectGUID $objectGUID -activeDirectoryCredential $cred -globalCatalogServer $globalCatalogServer

Option 3

This option is utilized when you only want to purge information from the Active Directory connector space. Generally, this is reserved for specific scenarios under the guidance of support. It functions in the same manner as Option 2 with the exception that no Entra ID distinguished name is calculated.

Option 3A: Remove object by Active Directory Distinguished Name

#The following instructions locate the object by Active Directory Distinguished Name

$cred = get-credential #Provide credential of person with rights to read attributes from active directory

$globalCatalogServer = "DC.domain.com" #FQDN of a global catalog server

$DN = "CN=Tim McMichael,OU=Users,OU=Objects,DC=home,DC=domain,DC=com"

reset-EntraConnectObject.ps1 -logFolderPath c:\temp -ADObjectDN $dn -globalCatalogServer $globalCatalogServer -activeDirectoryCredential $cred -calculateEntraDN:$FALSE

Option 3B: Remove object by Active Directory Mail Attribute

#The following instructions locate the object by Active Directory Mail Attribute 

$cred = get-credential #Provide credential of person with rights to read attributes from active directory

$mail = "tim@domain.com" #Active directory mail attribute

$globalCatalogServer = "DC.Domain.com"

reset-EntraConnectObject.ps1 -logFolderPath c:\temp -ADObjectmail $mail -activeDirectoryCredential $cred -globalCatalogServer $globalCatalogServer -calculateEntraDN:$FALSE

Option 3C: Remove object by Active Directory ObjectGUID

#The following instructions locate the object by Active Directory objectGUID

$cred = get-credential #Provide credential of person with rights to read attributes from active directory

$globalCatalogServer = "DC.domain.com" #FQDN of a global catalog server

$objectGUID = "ef27bb06-70d6-4904-b8b5-2531ea3b5e5c"

reset-EntraConnectObject.ps1 -logFolderPath c:\temp -ADObjectGUID $objectGUID -activeDirectoryCredential $cred -globalCatalogServer $globalCatalogServer -calculateEntraDN:$FALSE

Option 4

This option is utilized when you only want to purge information from the Entra ID connector space. Generally, this is reserved for specific scenarios under the guidance of support. The Entra ID distinguished name is determined by locating the object in the connector space and copying the distinguished name value. Note that this option triggers a delta synchronization when the process is complete.

$dn = "CN={4272736E37395A7742456D3474535578366A746558413D3D}"
reset-EntraConnectObject.ps1 -logFolderPath c:\temp -EntraDN $dn

Option 5

This option is utilized when more than one Active Directory connector space is present. If the script detects the presence of more than on Active Directory connector space an error is returned. The connector space name must be specified when running the command to ensure that the desired object is deleted. Depending on the scenario it may be necessary to not perform the single item sync until an object is deleted from all connector spaces.

In this example the user exists in the Active Directory home.domain.com and domain.local. (This is typical for example in a resource forest scenario). To complete purge this object the object must be purged from three connector spaces. The distinguished names were obtained through a metaverse search.

The first command purges the object from one Active Directory connector space and the Entra ID connector space. Note that single object sync is not performed as the object still exists in the second Active Directory connector space.

The second command purges the object from the second Active Directory connector space. At the conclusion of this command the full object sync should be allowed to run (which is the default).

I recommend running these as a single code block to eliminate the possibility that a sync cycle could occur inbetween.

#Establish the DN for the first forest.
$adDN = "CN=Tim McMichael,OU=Users,OU=Objects,DC=home,DC=domain,DC=com"

#Establish the DN for the second forest.
$otherADDN = "CN=Tim McMichael,OU=Users,OU=Objects,DC=domain,DC=local"

#Establish the EntraDN from the metaverse search.
$entraDN = "CN={4272736E37395A7742456D3474535578366A746558413D3D}"

#Provide the connector name for the first forest.
$adConnectorName = "domain.com"

#Provide the connector name for the second forest.
$otherADConnectorName = "domain.local"

#Remove the object from the entra connector space
reset-EntraConnectObject.ps1 -logFolderPath c:\temp -entraDN $entraDN

#Remove the object from the first active directory forest.
reset-EntraConnectObject.ps1 -logFolderPath c:\temp -ADObjectDN $adDN -skipSingleItemSync:$TRUE -ADConnectorName $adConnectorName -calculateEntraDN:$FALSE

#Remove the object from the second active directory forest and perform a single object sync.
reset-EntraConnectObject.ps1 -logFolderPath c:\temp -ADObjectDN $otherADDN -CalculateEntraDN:$FALSE -ADConnectorName $otherADConnectorName

Other information…

For each operation run a folder is created in the log path directory specified. The folder is a file date time stamp. Inside this folder is the operation log file and XML file extractions of all objects discovered during the connector space deletions. If a full single item sync was executed a JSONsummary file of the sync operation is also included in this directory.

I hope this script allows administrators to purge objects from connector spaces for troubleshooting or issue resolution easily.

Office 365 – Distribution List Migration Version 2.0 – Part 41

Leave a reply

Changing email addresses for migrated distribution lists…

When a distribution list is migrated the cloud only list has attributes that are fully managed in Exchange Online. This allows all attributes including the primary SMTP address associated with the group to be changed in Exchange Online.

If the distribution list has been migrated with the -enableHybridMailFlow switch or had enable-hybridMailFlowPostMigration run this results in mail flow objects existing in both Active Directory and Exchange Online. It would be possible for the primary SMTP address to be updated in Exchange Online and hybrid mail flow being broken as a result.

When hybrid mail flow is enabled a dynamic distribution list holds the same primary SMTP address as the migrated distribution list. In order for relay or other Exchange on-premises functions to continue to work the address would need to be updated in both directories. 

Version 2.9.8.26 now enables a command update-HybridMailAddress. This command allows an administrator to specify a new primary SMTP address and alias for a migrated distribution group. The command searches Active Directory to locate the dynamic distribution list created and if found the Exchange Online primary SMTP address is updated. If the primary SMTP address can successfully be updated in Exchange Online the primary SMTP address and mail address of the dynamic distribution list is updated in Active Directory. Changing the alias is optional, and if specified when changing the primary SMTP address the alias is updated in both Exchange Online and Active Directory.

Having a single command ensures that hybrid mail flow works when processing a primary SMTP proxy change.