Azure AD Connect: Reminder All version 1.x is Retiring this August, 2022

Hi fellow friends, hope you guys are having a good day today, everyday is a brand new day.

Today’s article here is to remind you that the Azure AD Connect all version 1 will be expiring soon, on 31st August 2022, this year this month.

What happen if you don’t upgrade before the due date?

Basically you will face service disruption such as accounts, computers objects and passwords will be affected.

Accounts/User objects:
– New users created in Active Directory will no longer synchronized to Microsoft 365 cloud

– New values added into the accounts/user will no longer reflecting the updates/changes into your Microsoft 365 cloud

– Basically any changes you make towards the accounts/user that you would like to sync to Microsoft 365 would not allowed

Computer objects:

– If your environment has Microsoft Intune or Hybrid join devices then you will have issue onboarding new devices to Microsoft Intune

Passwords:

– If your environment allow users to reset their own password from Microsoft 365 and synchronized back the new password to the Active directory would not be not allowed

– This is affecting the environment that has password writeback feature enabled in the Azure AD Connect

Any concerns should I take in for the current configuration before upgrading?

  1. Remember your Microsoft 365 global administrator credential, because you are require to re-establish the connection when you are performing an upgrade of the Azure AD Connect
  2. Make sure your server’s storage, Operating System and RAM size is still following the best practice
  3. Make sure you are following the new version of Azure AD Connects prerequisite

References:

  1. https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-version-history#retiring-azure-ad-connect-1x-versions

Azure AD Connect: What to know about In-place Upgrade from version 1.0 to 2.0 ?

Hi everyone, hope you guys are having a blast weekend. Today I would like to bring to you Azure AD Connect.

In the past, the 1.0 in-place upgrade, I would have to kept a record of the “before” changes of settings, such as the organization units, and etc. This would likely need me to schedule a day to capture the settings.

Anyway, not all of the 1.0 version can support the in-place upgrade to 2.0 version, if you have an older Azure AD Connect, that do not support in-place upgrade you would need to plan a migration or transition, to the 2.0 version. It may sounds simple, but there are few things you would need to take note of, that is avoiding duplicated records sync to Office 365, and duplicated service accounts, else you will likely get more stuff to clean up in the end. Is good to plan your transition and your clean-up first.

*Note: 31st August 2022, 1.0 version will be end of life

For those who are on the supported version of 1.0, that can perform in-place upgrade to 2.0 version, here are some tips or hint you can take note of before performing the upgrade,

  1. Full backup on the server
  2. Make sure you know what are the impacts
  3. Make sure the existing service account has the required permissions based on the 2.0 prerequisites
  4. During the upgrade, the wizard will request you to re-enter the global administrator account from Office 365
  5. You do not need to keep a record of the existing organizational unit because it will automatically bring forward the settings to your 2.0, same goes with your SSO, password hash settings, or device join settings
  6. Yes, version 2.0 does support single-label domain

If you would like to know more about the prerequisites of version 2.0, feel free to refer the references below,

References:

  1. https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-upgrade-previous-version
  2. https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-version-history

Exchange Migration: Outlook kept prompting for password after migration

Hi guys and girls, hope you are doing well, as the pandemic is still on-going, hope that you guys are keeping cleanliness and safety first.

Today’s topic is about exchange migration of mailboxes from on-premises to Office 365. This issue is where the legacy windows client or legacy office apps has issue with their outlook applications keeps prompting for credentials and showing disconnection. The issue also do happen to Windows 10 machines but not as aggressive as the Windows 7 machines.

This environment has the following items,

  1. Exchange server: 1 unit, version 2013, CU23 (latest)
  2. Windows client: Combination of Windows 7 and Windows 10
  3. Office applications: Combination of 2013, 2016, 2019 and Microsoft 365 apps for business in both windows 7 and windows 10 categories
  4. Migration method: Remote move migration
  5. Hybrid establishment: Yes
  6. Microsoft 365 license: Business standard/basic

As we all know that the major pre-requisites must met before starting the hybrid and perform migration.

We notice intermittent connections while running the Wireshark on Windows 7 with M365 business apps, while trying to login using the migrated account credential on an Outlook app. We ran a re-creation of the outlook profile and the prompt for credential has stops. This is definitely not the right solution. Solutions is dependent with what caused the issue.

At first we suspected something got to do whitelisting on the network layer but we had confirmed that the whitelisting are correctly configured. Next, we suspected something go to do with compatibility on windows with/or office apps version. This is not a very good idea. After quick research, I came about modern authentication could be the caused, and there where I had an idea on suggesting to turn off the security default in Azure portal and then turn off the modern authentication in Office 3655 tenant. After 10 to 15 mins, the intermittent connections no longer shows up on the Wireshark.

Modern authentication is enabled by default for every new Office 365 tenants, so please be aware if your environment has legacy windows client running or legacy office applications, do consider to turn them off first before proceeding to deploy Microsoft 365 apps.

Azure portal > Azure AD > Properties > Manage security defaults
Office 365 admin center > Settings > Org Settings > modern authentication

Modern authentication was the one the interfered with the machines and it kept challenging the users to key in credentials due to the compatibility was not met. Once the modern authentication is turn off, the environment now is running basic authentication.

References:

Azure AD Connect: Event code 8344 – Permission issue

Hey guys hope you are doing well today, today blog post is about Azure AD Connect permission issue. If you have been doing new infra deployment for years and very less in terms of troubleshooting and yes you will not expect what is the cause to this problem. The impact of this problem, is that user’s password won’t able to be sync to office 365 and they will have issue login to their office 365 portal and would required reset of their password from office 365 portal.

I had written about this issue before but it was 2018, the version of Azure AD Connect was much older. If you look into the Azure AD Connect deployment Microsoft article, version about 1.148 would required a write permission for the attribute “ms-ds-consistencyguid” to the service account that you are using to deploy the Azure AD Connect.

Minimum permission required for the service account are:

  1. Replicate directory changes
  2. Replicate directory changes all
  3. Write permission , for attribute ms-ds-consistencyguid

After providing the permissions to the service account, you would need to re-run the Azure AD Connect execution file or tool, for the changes that you made to that service account to take reflect.

Example image

After that the sync would start to run and I notice that are still some accounts giving “permission issue” error. So the next dependency was looking into the “inheritance” function, was it disable or not. I was able to identify that the particular OU have its inheritance enabled but on the single user object inside that OU, its inheritance was disabled.

This inheritance is from user’s object > Security tab > Advanced, at bottom.

References:

  1. https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-accounts-permissions

Azure ATP: Azure ATP capabilities and mechanism

Hey everyone, hope you guys had a wonderful day. Starting of a new year 2021. I hope everyone stay healthy and stay safe distance from one another or avoid crowded places.

I know that this pandemic has test us in many ways, in terms of physically and mentally. If you manage to get through year 2020 challenges, then give yourself a pad on the back, you did good.

This blog post I’m going to write about what is Azure ATP, before I jump into the topic, I want to say that security is a journey. If you guys have read about the recent news about attacks rises double/triple in the year 2020 and also the news about solarwinds attack, then these are enough proof that hackers are given more chances to attack in this situation, because they know majority businesses or corporates are still vulnerable or not up to par in terms of securing their environment and providing security training to users. Users mistakes in allowing attackers are also risk to the corporate that is why users training is still important to corporates. Losing money/profit to attackers is twice painful to the corporates then purchasing and implementing security technologies/products in the environment. Let’s take ransomwares as an example for this case. Due to this pandemic, I notice quite an amount of corporates are now implementing the concept of “Zero-trust“. If you would like to know what is “Zero-trust”, do feel free to Google them up.

Anyway, alright lets start our topic. The ATP term has been quite awhile in the security industry, or if you still not too sure what is ATP, ATP stands for Advanced Threat Protection. It contains advanced intelligent technology and combination of algorithms to identify and investigate types of malicious behavior and it will select appropriate action to quarantine/block the malicious actions before doing any harm to the environment and provide deep dive detailed reports to administrators.

Azure ATP has been known quite awhile in Microsoft 365, and Microsoft had given a different naming, Microsoft Identity Defender. It’s capability is to:

  1. Identify compromised accounts
  2. Investigate malicious activities of accounts
  3. Provide best practice security actions to administrators on how to handle accounts that reported by Azure ATP as suspicious or compromised
  4. Provide detail visibility authentication of attacks
  5. Azure ATP able to provide details of attack’s source
  6. Reports are real-time and signals back to Microsoft Identity Defender portal

This is just a summary of the entire structure looks like implementing Azure ATP into the environment with Domain Controllers only.

Azure ATP agent is only for on-premises like Domain controllers and ADFS and the agent will send a signal back to Microsoft Identity Defender if detected malicious activities or compromised accounts. I do recommend that you read more about requirements of deploying Azure ATP, before deploying into your customer’s environment. There is a medium impact required.

References

  1. What is Microsoft Defender for Identity? | Microsoft Docs
  2. Microsoft Defender for Identity architecture | Microsoft Docs

OneDrive and Active Directory: Error Code 0x8004de40

First time experience such error and behaviour, so the situation is that this user has problem getting her OneDrive to work on her desktop, it was her first time setting it up and she receive the above error code after she sign in and authenticate her account.

Capture

Well from Azure AD, it will shows that her login activity for OneDrive is successful, but Azure AD doesn’t shows that her setup was failed. At first I suspect it could be network issue, tested another account it went through the setup successfully. Hence, running PowerShell (Msol), to query the user account information and perform comparison and everything was showing in good condition.

Another thing is that she can successfully use the web based on SharePoint Online and OneDrive online.

As I went through to the Exchange Admin center and notice her email addresses missing a type, that is the SPO. This type of email address is generated once the user is assigned with the Office 365 license with Sharepoint Online and OneDrive online features.

The only resolution to this is to recreate the account. 

  1. Backup mailboxes to PST and files to a local drive or external drive
    • There are many ways to backup
  2. Unassign the user license
  3. Go to Active Directory and disable the account and move it to a unsync Organization Unit
  4. Go to Azure AD Connect Server and perform the sync
  5. Go to Office 365 make sure that the account has been move to deleted users, well you could use PowerShell to query -ReturnDeletedUsers.
    • Get-MsolUser -UserPrincipalName <username>@domain.com.my -ReturnDeletedUsers
    • Once it is found, then run the remove command, you can use GUI to remove them at the Azure portal “portal.azure.com”
      • Get-MsolUser -UserPrincipalName <username>@domain.com.my -ReturnDeletedUsers | Remove-MsolUser -RemoveFromRecycleBin -Force
  6. Go back to your Active Directory and recreate the user account, and make sure it is in the sync OU
  7. Run another sync at your Azure AD Connect Server
  8. Go to Office 365 > Active Users > Search for the user and assign the license

 

There are few reasons why this happen, for my case was the old Azure AD Connect server died or corrupted and had to re-provision a new one. Users are some still on Exchange on-premise and some are in cloud, due to budget. Sometime things happen.

Anyway, hope this helps! 

 

Azure Active Directory: Troubleshoot Immutable ID Matching Error “AttributeMustBeUnique”.

Nowadays there are becoming lots of tools to convert objectGUID to immutable ID. However, one of my friend was facing a problem “AttributeMustBeUnique” in the Azure AD Connect (AADC). Mostly the articles that talk about this error “AttributeMustBeUnique“, is asking people to look at the “Deleted User” or Query the duplicate account from Recycle Bin.

For this case, is slight different.

To understand what is he facing,

  1. A user account was created at cloud first.
  2. A user account status is “in cloud” in Office 365 > Active Users
  3. There is no duplicated account in the Recycle Bin
  4. My friend he empty the Immutable ID and replace it with a new Immutable ID that is covert from objectGUID, to match the account in cloud with its account in on-premise
  5. He used a tool to convert the objectGUID to Immutable ID.
  6. Replace the empty Immutable ID with the converted ones and run a full sync from AADC server. However, he was still getting the error.

After checking upon it was the objectGUID that he copied wrongly. Thus, converted the Immutable ID value wasn’t matching the ones that Azure AD detected.

Azure AD Sync error detection able to detect, identify and provide the suppose correct value of Source Anchor (Immutable ID). Every deployment of Azure AD Connect will match the account via source anchor.

04

What is source anchor? In layman term is the Unique ID from cloud.

References:

  1. http://guid-convert.appspot.com/
  2. https://docs.microsoft.com/en-us/azure/active-directory/hybrid/plan-connect-design-concepts

Office 365: Disable Office 365 Group, the year 2019 way

Mockup-Banner2_0209

Yesterday, I discovered that Microsoft has change the way how to disable office 365 group creation from users. You may refer from this Microsoft Docs and it was last updated in September 2019. It seems that it requires a minimum license of Azure AD Premium Plan 1. You may find this plan in your M365 E3 license. Before this, this was the way on how to disable office 365 group creation from users.

Looking through this blog post, on the Azure portal image, and comparing the current one has changed a lot. Now the group settings in the current Azure portal looks like this;

capture.png

As you can see above the Office 365 Groups settings, you can only control users from creating office 365 groups via Access Panel or Azure portals.

This is an Access Panel;

accesspanel

Identify Azure Active Directory Connect in the Environment (Sync Service)

Ever encounter in an environment where IT does not have visibility of the previous IT actions? Frustrating and irritating right? They were unsure whether is sync service running or not or exist or not.

At first, you will go to portal.office.com to find the DirSync Status, but this is where the funny part, there is a DirSync Management and it has resulted or hint that this Office 365 had Synchronization Service. As you can see below, there is no service account and no last directory sync.

aadc01

Next, I went into their Domain controller > Active Directory Users and Computers > Users OU. I was able to locate 2 Synchronize’s Service accounts, that are not disabled. To locate their location (server), double click on the account to launch the properties. At the description attribute or value, you can identify the location (server name).

  • 1 Service account with no indication of this sync service’s server location in the Description Information
    • Able to locate it, it was inside a Window Server 2008 R2
  • 1 Service account with an indication of its location (inside one of the Domain controller, Windows Server 2012 R2)

I access both of these servers, able to capture

  • Sync tool exist
  • Sync service is running (inside the services.msc)
  • No Operation of sync
  • No connectors in the sync service to be found
  • Windows Server 2008 R2 running Microsoft Online Services Directory Synchronize Service version 2013 year
  • Window Server 2012 R2 running Windows Azure Active Directory Service tool version 2014 year

New version Sync tool naming is “Azure Active Directory Sync Service”.

Another round to proof your findings is to run the PowerShell command to get all attributes of the user list in Active Directory on-premises and Azure Active Directory user list. (If you prefer to filter only a few attributes, then it is up to you.)

For Active Directory

#Run this command in domain controller's windows PowerShell

Get-ADUser -Properties * -Filter * | Export-Csv "filename.csv"

Get one of the oldest (before the year of 2013) and an active employee’s objectGUID.

For Azure Active Directory

Requirements:

  1. .NET Framework installed (latest)
  2. Microsoft  Azure Active Directory Module or PowerShell
  3. Windows PowerShell
#Connect to Azure AD service

Connect-MsolService

#Key in your Global admin credential

#Run this get command to get all user list with its attribute

Get-MsolUser | Export-Csv "filename.csv"

Next, you find the same oldest employee’s immutable id value, if there is value means this environment had sync service running before. You could compare the value that is valid and convert the objectGUID to an immutable ID or the other way around, using this converter.

After locating all this, now you can plan your clean up and recommendations. This may take a longer process, due to you need matching and creation.

 

 

Troubleshoot ADFS Token Signing and Decrypting Cutover

I read through many articles and done much research, and I really thought that the AutomaticRolloverCertificate function would take up its work seamlessly but guess what it didn’t. Well, it did generate the new token correct and changing the new token to the Primary and append the changes to Office 365 federation but it wasn’t able to update the changes in Office 365 federation.

I am not sure whether is this got to do with a single domain environment.

*Note:

Commands/PowerShell you can only run from Primary ADFS unless you had run some PowerShell to allow session establish from another computer. (Which is also fine to proceed, as long as you could establish the connection)

Impact:

  1. Federated Users unable to login

aadc01.PNG

 

Actions are taken:

  1. I have checked the event logs
    • Noticed there is an error about Event ID 111 WS-Trust or Value is null unable to perform the update
    • token01
  2. I have query the output via PowerShell from ADFS server
    • Connect-MsolServices
    • Key in Your Office 365 Global Admin credential (the xx@domain.onmicrosoft.com)
    • Get-MsolFederationProperty -DomainName domain.com

Based on the above 2 actions, I have noticed that it didn’t update the federation in Office 365. It was able to append the changes of the new tokens to the Office 365 but it didn’t update.

Next was;

  1. Run the PowerShell command from primary ADFS to force the update of the new token for Office 365

Connect-MsolServices

#enter your onmicrosoft.com global admin credential

Update-MsolFederatedDomain -DomainName domain.com -SupportMultipleDomain

#Check whether the token in office 365 is updated

Get-MsolFederationProperty -DomainName domain.com

2. Then Restart ADFS services, restart from primary ADFS then to the secondary ADFS

3. Retry to access portal.office.com, then you should be able to access

 

I am trying to simplify this situation with PowerShell Scripting…so stay tuned!

References:

  1. http://terenceluk.blogspot.com/2016/05/the-message-one-of-your-on-premises.html
  2. https://piasys.com/blog/microsoft-office-365-adfs-and-signingencrypting-certificates-renewal/
  3. http://jackstromberg.com/2014/11/office-365-renew-your-certificates-on-premise-adfs-alert/