Azure Active Directory – Sabrina Kay's Blog

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:

Replicate directory changes
Replicate directory changes all
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.

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:

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:

Identify compromised accounts
Investigate malicious activities of accounts
Provide best practice security actions to administrators on how to handle accounts that reported by Azure ATP as suspicious or compromised
Provide detail visibility authentication of attacks
Azure ATP able to provide details of attack’s source
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

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.

Backup mailboxes to PST and files to a local drive or external drive
- There are many ways to backup
Unassign the user license
Go to Active Directory and disable the account and move it to a unsync Organization Unit
Go to Azure AD Connect Server and perform the sync
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
```
Go back to your Active Directory and recreate the user account, and make sure it is in the sync OU
Run another sync at your Azure AD Connect Server
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,

A user account was created at cloud first.
A user account status is “in cloud” in Office 365 > Active Users
There is no duplicated account in the Recycle Bin
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
He used a tool to convert the objectGUID to Immutable ID.
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.

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

References:

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;

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:

.NET Framework installed (latest)
Microsoft Azure Active Directory Module or PowerShell
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:

Federated Users unable to login

Actions are taken:

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
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;

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:

Azure AD: How to permanent or force delete user from recycle bin via GUI?

As you may know Office 365 admin center doesn’t provide the capability to remove/delete deleted user from recycle bin and you may need to run powershell to do it.

Some of the IT admins may find using power shell is not very efficient than GUI. Currently you could perform the remove at Azure active directory.

Steps:

Sign in to https://portal.azure.com
At the side bar, select “Azure Active Directory”

4. Than select “Users”

5. Select “Deleted Users”

6. Next, select the users that you wish to permanently remove

Yes, Microsoft default of permanent remove of deleted user’s account is after 30 days.

Office 365: Email address with random numbers attached UPN (user123@contoso.onmicrosoft.com)

Why do some of my users have random numbers attach with their UPN? Well the only answer to this question is, duplication occur because you haven’t force delete the old account from Office 365 recycle bin. And by default there is a setting in Azure AD to detect duplication is set to false, so this is another reason that even there are duplication in AD created and a sync has been trigger the duplication will also be sync to the Office 365.

To prevent any duplication in future to be sync to the Office 365, is to set the duplication checking in Azure AD to true. So that any duplication is scan will be rejected to be sync to the Office 365. To resolve the duplication currently having is to delete the account and resync it to Office 365.

*Note: These random numbers in your smtp has no implication or effects to your mailbox/account, but it is only not nice to see it that way. It is up to your choice to do it or not.

*Azure Module Power Shell needed

Open Azure power shell
Type the following command to get the sync feature

Connect-MsolService

Get-MsolDirSyncFeatures

dirsyncfeature

3. Next, enable both of the feature to true

Set-MsolDirSyncFeatures -Feature DuplicateUPNResiliency -Enabled $true

Set-MsolDirSyncFeatures – Feature DuplicateProxyAddressResiliency -Enabled $true

*Note:

Situation 1: If the mailbox is still new, you will only need to delete the account and force delete from the recycle bin, then do a resync

Situation 2: If user have the mailbox for very long, you have to break the dirsync wait for the account’s status change from “Sync from on premise” to “on cloud“, then from Office 365 you can edit its smtp address but make sure you have your recycle bin clear from the old account. (Yes this is much troublesome than Situation 1)

Step by step for situation 1

Locate the account from Office 356
Unassign the mailbox license
At Active Directory, move the account to a unsync organization unit
At Azure AD Connect, run a manual sync command

Start-ADSyncSyncCycle -PolicyType Delta

5. Make sure the account at Office 365 has gone to the “Deleted User” Category

6. Once the account has been appear in “Deleted User” Office 365, you have to run a command to force deleted from the recycle bin.

7. Open Azure Module PowerShell

8. Type the following command, enter the UPN that you wish to remove from recycle bin

Connect-MsolService

Get-MsolUser -ReturnDeletedUser

Get-MsolUser -ReturnDeletedUser | Remove-MsolUser -UserPrincipalName xxxx@domain.com -RemoveFromRecycleBin -Force

9. After finish remove the account from recycle bin, move back the account from unsync Organization Unit to Sync Organization Unit

10. At Azure AD Connect, run the manual sync command

11. At Office 365, locate the account and assign license

12. You can notice there is no more random numbers found

Step by Step for Situation 2

*Make sure recycle bin is clear from duplication accounts

Open Azure Module PowerShell
Type the following command, enter the UPN that you wish to remove from recycle bin

Connect-MsolService

Get-MsolUser -ReturnDeletedUser

Get-MsolUser -ReturnDeletedUser | Remove-MsolUser -UserPrincipalName xxxx@domain.com -RemoveFromRecycleBin -Force
Open Azure Module Powershell
Type the following command

Connect-MsolService

Set-MsolDirSyncEnabled -EnableDirSync $false

3. You probably have to wait for 24hr to 48hrs for the dirsync to complete progress

4. At Office 365 > Exchange Online > Recipients > Mailbox

5. Search for the account > Double click on it

6. Go to Email Option > select the smtp address to edit

7. Remove the random numbers from the smtp address

8. Save your changes

*Make sure you put this to lab test before trying it out in actual environment, just to get clear understanding what are you doing

References:

https://support.office.com/en-us/article/Turn-off-directory-synchronization-for-Office-365-ee5f861e-bd48-4267-83d1-a4ead4b4a00d

Office 365 & Azure Powershell: Why not to use -SearchString pipe to Set function command?

Even though that you type the following command and it return you a single result, and you thought that it would work but it will not work.

Example:

First you try to get the user, and you able to retrieve a result

Get-MsolUser – SearchString “abc”

#Result
Name UserPrincipalName
——— ——————————-

abc abc@domain.com

2. After getting the user, you try to pipe it to a Set function. However, you receive an error like below; this error indicates an exception is trigger in Microsoft backend and prevent such command to proceed.

Get-MsolUser -SearchString “abc” | Set-MsolUserPrincipalName -NewUserPrincipalName “aaa@domain.com”

#Result

Set-MsolUserPrincipalName : Unable to update parameter. Parameter name: IMMUTABLEID.
At line:1 char:44
+ … abc” | Set-MsolUserPrincipalName -NewUserPrincipalName “aaa…
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (:) [Set-MsolUserPrincipalName], MicrosoftOnlineException
+ FullyQualifiedErrorId : Microsoft.Online.Administration.Automation.PropertyNotSettableException,Microsoft.Online.Admi
nistration.Automation.SetUserPrincipalName

3. So the correct way to do it is to either

Get-MsolUser -UserPrincipalName “abc@domain.com” | Set-MsolUserPrincipalName -NewPrincipalName “aaa@domain.com”
OR

Set-MsolUserPrincipalName -UserPrincipalName “abc@domain.com” -NewUserPrincipalName “aaa@domain.com”

*Note: Please test it out before you implement

	sabrinaksy on Azure Autopilot: Unable to del…
	Rob Simon on Azure Autopilot: Unable to del…
	Adam on Intune Autopilot: Troubleshoot…
	DougS on Cloud App Security: Masking wi…
	Pieter Louw on Azure AD Connect: Error 8344 P…