Category Archives: Active Directory

Enabling Self Service Password Reset

Hello Reader,

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 Users

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.

Regards
The Author – Blogabout.Cloud

Counting your Active Directory Objects before Azure AD Connect Sync

When working with Active Directory do you know how many objects you have? Are you planning on synchronizing with Azure Active Directory?

If no and yes to the above these quick and easy PowerShell cmdlets can help you. When installing Azure AD Connect Express settings you are limited to only 100,000 objects.

Count Active Directory Users

(Get-ADUser -Filter *).Count

Count Active Directory Groups

(Get-ADGroup -Filter *).Count

Count Active Directory Computers

(Get-ADComputer -Filter *).Count

Count All Active Directory Objects

(Get-ADObject -SearchBase "dc=Mydomain,dc=com" -LDAPFilter "(objectCategory=*)").Count

Regards
The Author – Blogabout.Cloud


Configuring Password Expiry within Microsoft 365 admin center and with PowerShell

In this brief blog post I am going to demonstrate how simple it is to configure or modify password expiry policy within the Microsoft 365 Admin Center or using PowerShell to make the necessary change.

Configure using Admin Center

Launch https://admin.microsoft.com and go to Settings –> Org Settings –> Security & Privacy –> Password expiration policy

Here you can untick Set user passwords to expire which will disable this setting or configure/modify “Days before passwords expire”

Configure using PowerShell

Running the following commands has the same effect as changing the configuration in the Microsoft 365 Admin Center.

# Connect to M365
$cred = Get-Credential
Connect-MsolService -Credential $cred

# Configure Password Policy
Set-MsolPasswordPolicy -ValidityPeriod 60 -NotificationDays 14 -DomainName "contoso.com"

Regards
The Author – Blogabout.Cloud

Ensuring that group owners renew their Office 365 groups every X days

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.

Screenshot of Groups expiration settings in Azure Active Directory

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.

Important

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.

Regards
The Author – Blogabout.Cloud

PowerShell Tip: Obtaining the ImmutableID from your Active Directory Objects on-prem and in the cloud

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.

$reportoutput=@()
$users = Get-ADUser -Filter * -Properties *
$users | Foreach-Object {

    $user = $_
    $immutableid = "[System.Convert]::ToBase64String($user.ObjectGUID.tobytearray())"
    $userid = $user | select @{Name='Access Rights';Expression={[string]::join(', ', $immutableid)}}

    $report = New-Object -TypeName PSObject
    $report | Add-Member -MemberType NoteProperty -Name 'UserPrincipalName' -Value $user.UserPrincipalName
    $report | Add-Member -MemberType NoteProperty -Name 'SamAccountName' -Value $user.samaccountname
    $report | Add-Member -MemberType NoteProperty -Name 'ImmutableID' -Value $immutableid
    $reportoutput += $report
}
 # Report
$reportoutput | Export-Csv -Path $env:USERPROFILE\desktop\ImmutableID4AD.csv -NoTypeInformation -Encoding UTF8 }

Obtaining ImmutableID from Azure Active Directory Object

The following PowerShell script extracts all the ImmutableID’s from every single Azure Active Directory User Object and store in a CSV file on your desktop.

$reportoutput=@()
$users = Get-AzureADUser -All $true
$users | Foreach-Object {

    $user = $_

    $report = New-Object -TypeName PSObject
    $report | Add-Member -MemberType NoteProperty -Name 'UserPrincipalName' -Value $user.UserPrincipalName
    $report | Add-Member -MemberType NoteProperty -Name 'SamAccountName' -Value $user.samaccountname
    $report | Add-Member -MemberType NoteProperty -Name 'ImmutableID' -Value $user.immutableid
    $report | Add-Member -MemberType NoteProperty -Name 'DisplayName' -Value $user.displayname
    $reportoutput += $report
}
 # Report
$reportoutput | Export-Csv -Path $env:USERPROFILE\onedrive\desktop\ImmutableID4AAD.csv -NoTypeInformation -Encoding UTF8 }

Recommendation

When I have had to compare the two exports at scale for an entire environment, it can be a complete nightmare but the ImportExcel module was brilliant in getting the data merged into a single sheet.

https://www.powershellgallery.com/packages/ImportExcel/7.1.1

Regards
The Author – Blogabout.Cloud

Where is the Service Connection Point (SCP) set for Microsoft Exchange Server?

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

1
autodiscover
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.

Autodiscover functional process

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;

  • “serviceBindingInformation” attribute
  • keywords” attribute.

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;


1
Set-ClientAccessServer -AutoDiscoverServiceInternalUri $Null

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


1
Set-ClientAccessServer -AutoDiscoverServiceInternalUri https://ex02.officec2r.com/autodiscover/autodiscover.xml

Regards
The Author – Blogabout.Cloud

Configuring Office 365 Service Communications API within your own Azure Active Directory.

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.

Prerequisites

  • Relevant Azure Active Directory Permissions to create an app
    • Global Administrator,
    • Application Administrator
    • Cloud Application administrator
  • Licensed for Power Automate either;
    • Per-user plan
    • 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.

Regards
The Author – Blogabout.Cloud

Understanding Azure Active Directory Connector soft matching

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: 

    Azure AD Connect: When you have an existent tenant

    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:john@contoso.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.

Regards
The Author – Blogabout.Cloud

Going Passwordless with YubiKey by Yubico

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.

Diagram that outlines the steps involved for user sign-in with a FIDO2 security key
  1. The user plugs the FIDO2 security key into their computer.
  2. Windows detects the FIDO2 security key.
  3. Windows sends an authentication request.
  4. Azure AD sends back a nonce.
  5. The user completes their gesture to unlock the private key stored in the FIDO2 security key’s secure enclave.
  6. The FIDO2 security key signs the nonce with the private key.
  7. The primary refresh token (PRT) token request with signed nonce is sent to Azure AD.
  8. Azure AD verifies the signed nonce using the FIDO2 public key.
  9. Azure AD returns PRT to enable access to on-premises resources.

Enabling support for Yubikey

Time to log into your Azure Active Directory via http://portal.azure.com

Select Security
Select Authentication methods
Select FIDO2 Security Key and Enable for your environment

Now thats the easy bit completed, the next step is educating the users.

NOOooooo That's impossible!!!!! - Luke Skywalker - quickmeme

Configuring Yubikey

Each user will need to visit the following your https://myprofile.microsoft.com/

Select Security Info
Click Add Method
Select Security Key –> Add
Select USB device
Press Next
Insert your Security Key into one of your USB ports.
Specify a security key PIN
Touch the button on the security key
Provide a name to identity the security key
All Done!!

Hows does the sign-in work?

Well, really simple. Check out the video below

Regards
The Author – Blogabout.Cloud

Enforcing Cloud Password Policy for Password Synced Users

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

PowerShell Command

Set-MsolDirSyncFeature -Feature EnforceCloudPasswordPolicyForPasswordSyncedUsers -Enable $true

You can verify all your users by running the following commands

PowerShell Command

# Output all users to PowerShell console
Get-AzureADUser | Select-Object DisplayName,DirSyncEnabled, PasswordPolicies, AccountEnabled

# Output all users where DirSyncEnabled equal True
Get-AzureADUser | Select-Object DisplayName,DirSyncEnabled, PasswordPolicies, AccountEnabled | Where-Object {$_.DirSyncEnabled -eq $true}

Now let’s apply the following script to ensure that the Password Policy is not disabling password expiration.

PowerShell Command

Get-AzureADUser -All $true | Where-Object { $_.DirSyncEnabled -eq $true -and $_.PasswordPolicies -eq ‘DisablePasswordExpiration’ } | ForEach-Object {
Set-AzureADUser -ObjectId $_.ObjectID -PasswordPolicies None
}

Regards
The Author – Blogabout.Cloud