In this post, I will show you how to configure Self Service Password Reset for your organization. This option is designed to reduce the workload on Service Desks and provide a solution whereby end-users are able to reset this account password.
Launch Azure Portal https://portal.azure.com
Go to Azure Active Directory
Select Password Reset
For users to authenticate to reset their password you need to define the best security method for your organization. Click on Authentication methods and select whether you want 1 or 2 methods to be required to reset. Then select the options you want available as shown below
We now need to ensure that users are required to register for Password Reset –> Select Registration and select Yes. You can also get users to reconfirm their authentication information after a set amount of days.
Some additional steps you can make are;
Notifications Notify a user when their password has been reset Notify all admins when another admin resets their password
Customization Provide a link to your helpdesk for the end-user if they are having difficulties.
On-premises integration If you are using Password Writeback with Azure Active Directory Connect. You can able users to write back their password to an on-premises directory and allows users to unlock accounts without resetting their password.
With the increase in usage of Microsoft 365 groups and Microsoft Teams, administrators and users need a way to clean up unused groups and Teams more effectively. A Microsoft 365 groups expiration policy can help remove inactive groups from the system and make things cleaner.
When a group expires, all of its associated services (the mailbox, Planner, SharePoint site, team, etc.) are also deleted.
When a group expires it is “soft-deleted” which means it can still be recovered for up to 30 days.
Modifying the Groups | Expiration
By default, a group has 180 day lifetime and renewal notifications are set to the group owners, 30, 15 and 1 day prior to expiration. Providing 3 chances before the group is removed.
If there are any groups with no owners specified you can configure an email address which will receive the notification renewal alerts.
Now for the most important element, you can configure expiration for all groups, a selection number or not have the setting enabled at all.
Groups that are actively in use are renewed automatically. Any of the following actions will trigger an auto-renew a group:
SharePoint – view, edit, download, move, share, or upload files. (Viewing a SharePoint page does not count as an action for automatic renewal.)
Outlook – join group, read or write group message from the group, and like a message (Outlook on the web).
Microsoft Teams – visiting a Teams channel.
Important: The only Yammer activity that will trigger an automatic group renewal is the upload of a document to SharePoint within the community.
When you change the expiration policy, the service recalculates the expiration date for each group. It always starts counting from the date when the group was created, and then applies the new expiration policy.
It’s important to know that expiration is turned off by default. Administrators have to enable it for their organization if they want to use it.
When working with Azure Active Directory Connect you may experience issues with account duplicating due to the ImmutableID not matching. If it does happen its is a pain to resolve as you have to;
Desynchronize the affected accounts Delete from the Deleted Users OU in Azure Active Directory Obtain the on-premises ImmutableID Obtain the cloud ImmutableID Compare the IDs Set the cloud ID with the on-premises ID
Now wouldnt it be easier if someone had a bunch of PowerShell commands to help you get the ImmutableID. This is where I come in
Obtaining ImmutableID from on-premises Active Directory Object
The following PowerShell script extracts all the ImmutableID’s from every single Active Directory User Object and store in a CSV file on your desktop.
Every IT Administrator will have heard the term “Service Connection Point” or SCP when autodiscover is mentioned especially if you are still running Exchange Server On-Premises.
What is SCP? Where can I find it? What is it used for?
Whenever a Client Access Server is installed into a Greenfield or exisiting Exchange organisation. Exchange automatically creates at installation the virtual directory
in IIS, the frontend Client Access services web site that clients connect to. This allows Outlook to discover the Exchange mailbox settings so that users don’t have to deal with manually configuring advanced settings.
The SCP object is also created in Active Directory at the same time as the Autodiscover service virtual directory. The SCP stores and provides authoritative URLs of the Autodiscover service for domain-joined computers.
Where can I find SCP?
You can view the SCP object using Active Directory Sites and Services, after you have enabled the “View Services Node” option from the “View” tab.
You will have a list of SCPs if you have more than one CAS server in your environment. If you right click and take the properties of the SCP object (Attribute Editor tab), it contains two two pieces of information which is of interest;
The “serviceBindingInformation” attribute has the Fully Qualified Domain Name (FQDN) of the Client Access server in the form of https://ex02.officec2r.com/autodiscover/autodiscover.xml, where ex02.officec2r.com is the FQDN of the CAS server.
This url is mostly changed to one that is covered by the SAN/UCC certificate. It is this url which internal Outlook client uses to connect to the mailbox and other Exchange features published using autodiscover.
The “keywords” attribute specifies the Active Directory sites to which this SCP record is associated. By default, this attribute specifies the Active Directory site to which the Client Access server belongs.
What is it used for?
When using a domain joined client, Outlook client authenticates to Active Directory and tries to locate the SCP objects by using the user’s credentials. After the client obtains and enumerates the instances of the Autodiscover service, it connects to the first Client Access server in the enumerated list and obtains the profile information in the form of XML data that is needed to connect to the user’s mailbox and available Exchange features.
If you require to remove the ServiceBindingInformation at any point this can be completed by;
Once Active Directory replication has completed, the SCP object will be updated with the Null Value and if you need to reinstate the AutoDiscoverServiceInternalUri run the same command again but with the require value
Office 365 Service Communications API enables an organization to gather data about the Microsoft 365 tenancy and in this post we will be looking at Service Health.
Relevant Azure Active Directory Permissions to create an app
Cloud Application administrator
Licensed for Power Automate either;
Per-user plan with attended RPA
Per Flow plan
Configuring Azure Active Directory
Login into the Azure Portal via http://portal.azure.com and browser to Azure Azure Directory then select App Registrations –> New Registration
Now enter a Name for the application i.e. Office 365 Service Communications API, select Accounts in this organizational directory only
The Redirect URI can be ignored as it no longer necessary and then click Register.
The registered app you just created will now be displayed – click on API permissions on the left hand menu. Click on the Add a permission button in the Configured permissions section. Select Office 365 Management API in the Request API permissions section.
Select Application permissions as the type of permissions your application requires. Then Select ServiceHealth.Read as the permissions required and then select the Add permissions button.
Granting Tenant Admin Consent
The application is now configured with the permissions it needs to use the Office 365 Management APIs but first it needs an admin to grant these permissions. A Global Administrator, Application Administrator or Cloud Application administrator must explicitly grant your application these permissions. This is granting the app permissions to use the APIs to access your tenant’s data.
If you do not have the necessary role please advise the admin to follow this link and provide them with the name of your App Registration to review and approve.
If you have the necessary Global Administrator, Application Administrator or Cloud Application administrator role click on the Grant admin consent to <tenant name> button.
Generate a new key / client secret for your application
Navigate to the main page for the App Registration you just created, now make a note of the Application (client) ID and Directory (tenant) ID as you will need these later to access the Office 365 Management API using the app just created. Now Client secret needs to be generated to be used for authentication to the APIs – click on Certificates & Secrets on the left hand menu.
IMPORTANT: Now make a note of the Client Secret created i.e. BlahBlah-BlahBlah. It is important that this is done now as once this window is closed the Client secret will no longer be visible.
This completes the process for configuring Office 365 Service Communications API. The next step will be using either PowerShell or Power Automate to present the data.
If you would to utilize Power Automate check out this blog post I created.
It is has become very common across most organizations that they set up an Office 365 tenancy or Azure tenancy without configuring integration with their own on-premises Active Directory or another scenario an organization has been brought by another company. The end-users are then given cloud-only accounts until such a time where they can be fully integrated. In going down this road it can potentially cause a number of issues that need to be resolved by either soft matching or hard matching the on-premises AD User with the Cloud Account.
How do I soft match?
Soft matching is driven by the SMTP Address of the user account and usually, the UPN matches the SMTP Address. So in the diagram below that, I have created you can see I have captured the two scenarios organizations move their on-premises identities to Azure Active Directory. What I have also done is put a deliberate mistake into the images, can you spot what it is?
So User D and Cloud D are the same users but the UPN is different, why have I done this? This is to explain the behavior that will happen if the account cannot be correct identified with its cloud account. User A to C will all synchronize successfully and correctly however, User D will not succesfully be synchronized as the UPN that doesn’t match Cloud D. While this isn’t a bad issue for this scenario but if you were actioning at scale, I hope you are ready for a host of complaints from users.
Its is important to ensure that the SMTP Addresses on-premises vs. the cloud but please be aware there are limitations like in any Microsoft product
SMTP matching limitations
The SMTP matching process has the following technical limitations:
SMTP matching can be run on user accounts that have a Microsoft Exchange Online email address. For mail-enabled groups and contacts, SMTP matching (Soft match) is supported based on proxy addresses. For detailed information, refer to the “Hard-match vs Soft-match” section of the following Microsoft Azure article:
Note This doesn’t mean the user must be licensed for Exchange Online. This means that a mailbox that has a primary email address must exist in Exchange Online for SMTP matching to work correctly.
SMTP matching can be used only one time for user accounts that were originally authored by using Office 365 management tools. After that, the Office 365 user account is bound to the on-premises user by an immutable identity value instead of a primary SMTP address.
The cloud user’s primary SMTP address can’t be updated during the SMTP matching process because the primary SMTP address is the value that is used to link the on-premises user to the cloud user.
SMTP addresses are considered unique values. Make sure that no two users have the same SMTP address. Otherwise, the sync will fail and you may receive an error message that resembles the following: Unable to update this object because the following attributes associated with this object have values that may already be associated with another object in your local directory services: [ProxyAddresses SMTP:email@example.com;]. Correct or remove the duplicate values in your local directory.
Hard-match works in a simalar way but uses the ImmutableID of the user accounts. This is unique value that each account has, so to hard match the on-premises ImmutableID to the cloud account would mean that you modify every single Cloud account with the correct on-premises account value. I know this from experience as I had to do just that for one of my customers and created a powershell script to enable the change.
This has been on my To-Do list for such a long time and because of Covid-19 I have finally found the hours required to get this done. A while back I received two Yubico and never got around to testing them 🙁 naughty I know. So let’s look at Yubico;
Microsoft and Yubico have been created a path for a passwordless future for organizations of all shapes and sizes. With a technology standard called FIDO2 and U2F which Yubico co-authored with, Microsoft and Google. Yubico became a founding member of the FIDO Alliance.
How does it all work, I hear you
The Yubikey supports multiple methods for authentication, enabling and the same key to be used across services and applications. With an out of the box native integration for the Microsoft environment provides a rapid deployment.
The user plugs the FIDO2 security key into their computer.
Windows detects the FIDO2 security key.
Windows sends an authentication request.
Azure AD sends back a nonce.
The user completes their gesture to unlock the private key stored in the FIDO2 security key’s secure enclave.
The FIDO2 security key signs the nonce with the private key.
The primary refresh token (PRT) token request with signed nonce is sent to Azure AD.
Azure AD verifies the signed nonce using the FIDO2 public key.
Azure AD returns PRT to enable access to on-premises resources.
Did you know that Enforce Cloud Password Policy for Password Synced Users exists? and that it is also disabled by default. This means that any user that you sync using Azure Active Directory Connect will not have an expiration timer set against their account. This can be a nightmare for an organization that has strict password policies.
So let’s switch it on and get all your synced users applied
First of all, you will need to run the following command after you have ran Connect-MsolService