Category Archives: Active Directory

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

Obtaining your ImmutabeID the easy way because hard matching is a nightmare

Imagine, your company has just been brought by another organization. The acquiring company what you using Office 365 services as quick as possible so they create you a Cloud Only Account to leverage their existing tenant. Now imagine, you are 12 months into the acquisition and you want to have a single sign-on experience for your end-users.

Now you have a dilemma on your hands, as your primary user principle name on-premises is different from your UPN in the Azure Tenant.

WHAT DO YOU DO!!!

Image result for captain picard head in hand
What did I do??

You engage your Windows PowerShell Console in Administrator Mode and teleport in the Get-ImmutableID.ps1 PowerShell script

Image result for captain picard
Engage!!!
New Features coming soon!!

With this script, you are able to download all the ImmutableIDs from your local Active Directory into a single CSV file to your desktop.

Please Note:

If there are additional fields you would like to see in this script, please submit an update via Github or email alerts@blogabout.cloud

You will need some manual intervention matching your on-premises AD Users and AAD Users but once this is complete you will be able to run the following script to set the ImmutableID in your Azure Active Directory.

PowerShell Script


1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
region File Path
 $Filepath1 = Get-Filename -initialdirectory "$env:USERNAME\desktop"
 $csv1 = Import-Csv -Path $filepath1
 endregion
 
Start-Transcript "env:userprofile\desktop\SetAllUserAADtest.txt"

 ForEach($user in $csv1){
 Try  
{ Get-AzureADUSer -ObjectId $user.primarysmtpaddress -ErrorAction Ignore Write-Host "Success:",$user.PrimarySMTPAddress,"was found and set with",$user.ImmutableID -BackgroundColor DarkGreen
Set-AzureADUser -ObjectID $user.PrimarySMTPAddress -ImmutableID $user.ImmutableID }
catch
{ Write-Host "ERROR:",$user.PrimarySMTPAddress,"could not be found" -BackgroundColor DarkRed }

Stop-Transcript

While this is a tried and tested in my own deployments, I am unable to take responsibility for any potential issues you may encounter. Keep safe with responsible scripting, always test in a lab environment first.

Regards
The Author – Blogabout.Cloud

Do you have Device Writeback enabled on Azure Active Directory Connect? Do you know how to check if a device has been written back?

I have been recently working with a customer and errors within AAD look which pointed to an issue with Device Writeback not being enabled on Azure Active Directory Connect.

But how do you check if the device is writing back? Well, I’m glad you asked. First of all, we need the Device ID which is obtain running a cmd via command prompt.

dsregcmd /status

Once you have this information you will need to run the following command using PowerShell on one of your domain controllers.

$deviceid = “Enter ID here”
Get-ADObject -LDAPFilter “(cn=$deviceid)” -SearchBase = “CN=RegisteredDevices,DC=OfficeC2R,DC=com,”

If you are returned an error i.e Directory Object Not Found. It is safe to say the device hasnt been registered yet.

And its as simple as that

Regards
The Author – Blogabout.Cloud