How Active Directory cleanup and Azure Files SMB hardening produced the same symptom for different reasons

Created by Shaun Hardneck | www.thatlazyadmin.com

At 05:33 on the first day, an Active Directory cleanup job disabled the identity behind an Azure Files storage account. The next day, an SMB hardening change restricted two storage accounts to AES-256-GCM. The user experience was almost identical both times: FSLogix could not attach the profile container, and new Azure Virtual Desktop logons failed or landed in the wrong profile.

The root causes were nowhere near each other. One sat in Active Directory identity lifecycle management. The other sat in SMB session negotiation. That contrast is what makes these incidents useful. The same FSLogix symptom can point to very different layers, and the fastest path is to treat every code as a clue that still needs corroboration.

This post walks through the evidence, the corrections I would make to the original diagnosis, and the rollout checks I now use before changing Azure Files SMB security settings.

Scope All host names, storage account names, domain names and identifiers are anonymised. The timings, error codes, configuration values and recovery results are retained as incident observations. Where the evidence did not prove a mechanism, I say so.

Read the error code and then confirm the layer

Start with the FSLogix operational log and the profile log. The Windows error code narrows the search, but it does not establish the root cause on its own. Microsoft documents FSLogix error values as Windows system errors returned by failed API calls, so the same code can surface through more than one underlying condition.

$filter = @{
LogName = 'Microsoft-FSLogix-Apps/Operational'
Level = 2
StartTime = (Get-Date).AddHours(-4)
}

Get-WinEvent -FilterHashtable $filter |
Select-Object -First 10 TimeCreated, Id, Message |
Format-List

Then open the matching Profile log under C:\ProgramData\FSLogix\Logs\Profile. Current Microsoft guidance treats that text log as the primary troubleshooting record because it includes the FSLogix version, user, process, status changes and the Windows error returned at the failed operation.

Code	Windows meaning	Useful first direction	Important limit
1326	ERROR_LOGON_FAILURE	Kerberos, the Azure Files AD identity, trusts and credentials	A strong authentication clue, not proof of one specific cause
5	ERROR_ACCESS_DENIED	Share access, ACLs and SMB session policy	Azure Files also returns access denied when SMB security requirements are not met
53 or 67	Network path or network name not found	DNS, private endpoints, connectivity and VHDLocations	Confirm the exact failing operation before blaming name resolution
112	ERROR_DISK_FULL	Share quota, container size and local disk capacity	Identify which disk or quota returned the error

FrxStatus 31 appeared in both incidents with different underlying Windows errors. Microsoft examples also show FrxStatus 31 paired with different error messages. In this case it was a wrapper around a failed profile load, not a reliable discriminator. The more useful evidence was the Windows error line immediately before it and the operation that failed.

Day one when Active Directory Automation jobs disabled the storage identity

Users could not load profiles on any host in the pool. The profile log showed Windows error 1326, and the Active Directory object representing the storage account had been disabled at 05:33.

CN=stfslogixprod01,OU=Servers,DC=corp,DC=example,DC=com
sAMAccountName : SVC-FSLOGIX-SA$
userAccountControl : 4098
0x1000 WORKSTATION_TRUST_ACCOUNT
+ 0x0002 ACCOUNTDISABLE
pwdLastSet : 18 months ago

What the Azure Files identity actually is

With Azure Files AD DS authentication, the storage account is represented in AD DS by either a computer account or a service logon account. Its password is set to one of the storage account Kerberos keys. This identity is not a domain-joined Windows computer that automatically changes its own machine password on the usual schedule.

That does not mean the password can never change. Microsoft provides supported procedures to rotate it with Update-AzStorageAccountADObjectPassword or with Active Directory PowerShell. Microsoft also says that the password must be rotated before the applicable maximum age if the OU policy requires expiration. The alternative is to place the object in an OU where password rotation is not required and protect it from stale-account cleanup.

In this incident, the 18-month pwdLastSet value explained why a password-age cleanup rule selected the object. The disabled account flag was the decisive evidence. An old pwdLastSet value by itself would not have proved that authentication was broken.

Recovery and the hour delay

Re-enabling the AD object restored access, but failed logons continued for roughly an hours. That delay is a real observation. The available evidence did not isolate whether the remaining failures came from AD replication, cached Kerberos state, an SMB connection, or another cache in the sign-in path.

The safe recovery sequence is to confirm that the object is enabled on the relevant domain controllers, verify that its password still matches a storage account Kerberos key, and test with a fresh user sign-in on a drained host. The AzFilesHybrid module includes a supported password-match test.

$resourceGroupName = '<resource-group-name>'
$storageAccountName = '<storage-account-name>'

Test-AzStorageAccountADObjectPasswordIsKerbKey `
-ResourceGroupName $resourceGroupName `
-Name $storageAccountName `
-Verbose

Do not assume that purging the SYSTEM Kerberos cache is the right fix. FSLogix profile containers attach as the user by default because AccessNetworkAsComputerObject defaults to 0. The SYSTEM or computer context matters only when the solution was deliberately configured to attach as the computer. Purging tickets or tearing down SMB state on an active multi-user host can affect live sessions, so use a drained test host and target the security context your design actually uses.

The durable identity fix

1. Identify the process that disabled the object. If account-management auditing is enabled, domain controller Security event 4725 records the subject that disabled the account.

2. Choose one supported password lifecycle. Rotate the Azure Files AD identity password before the applicable maximum age, or place the identity in a protected OU that does not require rotation.

3. Exclude the identity from stale-account cleanup in a way that survives an OU move. A direct object exception is more robust when the cleanup tool supports it.

4. Document the storage account, SPN, object type, OU, owner and rotation or exception decision. Test the password-to-Kerberos-key match after any identity change.

# Run from a domain-joined PowerShell 5.1 host with the required
# Azure and AD DS permissions. Follow the Microsoft rotation procedure.
Update-AzStorageAccountADObjectPassword `
-RotateToKerbKey kerb2 `
-ResourceGroupName $resourceGroupName `
-StorageAccountName $storageAccountName

Day two when one SMB setting blocked new logons

The next incident returned Windows error 5. A hardening change had restricted SMB channel encryption on both FSLogix storage accounts to AES-256-GCM only.

Versions : SMB3.1.1
ChannelEncryption : AES-256-GCM

The session hosts were Windows 11 and their SMB client configuration listed AES_256_GCM, so I initially ruled out cipher compatibility.

PS> (Get-SmbClientConfiguration).EncryptionCiphers

AES_128_GCM, AES_128_CCM, AES_256_GCM, AES_256_CCM

That was the wrong inference. A capability list does not prove which cipher the client will offer first or which policy applies to a new connection. Current Azure Files guidance says that when the service allows only AES-256-GCM, Windows 11 and Windows Server 2022 clients must be configured to use only AES-256-GCM with Set-SmbClientConfiguration. Azure Files checks the server-side SMB security settings when the session is established and returns STATUS_ACCESS_DENIED if they are not met.

I would not generalise this into a claim that every Windows 11 client always negotiates AES-128-GCM first. Microsoft explicitly documents AES-128-GCM as the default on Windows 10 version 21H1 for performance reasons, while its Azure Files guidance separately requires an explicit AES-256-GCM client configuration for the supported Windows 11 and Windows Server 2022 clients when the server is restricted to that one cipher. The practical conclusion is narrower: advertised support was not enough for this policy.

The server-side change, the failure window, the documented STATUS_ACCESS_DENIED behaviour, and the successful rollback together made cipher policy the supported explanation for this incident. Error 5 alone did not.

Why the outage appeared intermittent

Azure Files checks these SMB security settings when a session is established. In the incident, sessions created before the change continued to work while new session attempts failed. Existing sessions can still end because of normal disconnects, host changes, idle handling or service events, so they should not be described as surviving indefinitely.

Time	Observed event
11:14	Last successful profile load
11:29	Channel encryption restricted to AES-256-GCM
12:10	Next logon attempt failed
12:10 onward	Subsequent attempts in the observed window failed
16:41	Setting reverted
16:44	First successful profile load after the revert

The timeline mattered more than any single message. Once the last success, first failure and 11:29 configuration change were aligned, the testable hypothesis was obvious.

Use FSLogix event IDs as local evidence

On the installed FSLogix build, event 25 in Microsoft-FSLogix-Apps Operational included a Status field that helped reconstruct profile outcomes. I have kept that as an incident observation, not a universal contract. Current Microsoft Learn guidance documents the Apps logs and recommends the Profile log, but it does not define event 25 or event 26 as stable profile-result events across versions.

Event 26 is especially unsuitable as a blanket alert. Microsoft documents event 26 for group SID and domain lookup errors on Microsoft Entra joined devices that can be safely ignored, which means the ID is not unique to a profile-container failure. Build monitoring from the provider, level, message or extracted status fields that you have validated against your deployed FSLogix version. Always retain the FSLogix version and profile log with the alert.

A safer SMB hardening rollout

AES-256-GCM only can be a valid target for Azure Files, but it is a compatibility change as well as a security change. The rollout must account for every SMB client and every share on the storage account, not only the AVD host pool that prompted the work.

1 Inventory every client and dependency

• 
  List every file share on each affected storage account.
  
• 
  Map every AVD host pool, server, backup job, monitoring agent, app attach or MSIX dependency, and scripted file copy that uses those shares.
  
• 
  Confirm the operating system and patch level. Azure Files supports AES-256-GCM with Windows 11 and Windows Server 2022 or later. Older Windows clients do not support that Azure Files channel cipher.
  
• 
  Confirm that the EncryptionCiphers parameter is available on the deployed Windows build before scheduling the server change.
  

2 Capture the client and server baselines

$resourceGroupName = '<resource-group-name>'
$storageAccountName = '<storage-account-name>'

$clientBefore = (Get-SmbClientConfiguration).EncryptionCiphers
$serverBefore = Get-AzStorageFileServiceProperty `
-ResourceGroupName $resourceGroupName `
-StorageAccountName $storageAccountName

$serverBefore.ProtocolSettings.Smb |
Select-Object Versions, AuthenticationMethods, `
KerberosTicketEncryption, ChannelEncryption |
Format-List

A null Azure Files SMB value means the platform default is in effect. Preserve that distinction. It is not the same thing as an explicitly configured list, even when the effective algorithms happen to match.

3 Configure and verify the clients first

Set-SmbClientConfiguration `
-EncryptionCiphers 'AES_256_GCM' `
-Confirm:$false

(Get-SmbClientConfiguration).EncryptionCiphers

This is a computer-wide SMB client setting, not an Azure Files setting scoped to one share. Test other SMB dependencies on the same host before broad deployment. Push the configuration through the image or device management layer so that replacement and autoscaled hosts receive it before they accept users.

4 Treat authentication and ticket encryption as separate changes

Restricting SmbAuthenticationMethod to Kerberos disables SMB mounts that use the storage account key through NTLMv2. That may be the desired result, but only after every key-based consumer has been found and migrated. Do not label the change risk-free merely because AllowSharedKeyAccess is false.

Restricting SmbKerberosTicketEncryption to AES-256 is also separate from channel encryption. Validate the Azure Files AD identity, its msDS-SupportedEncryptionTypes value, domain controller support, client support and current Microsoft Kerberos hardening guidance. Apply and test these controls independently so that a failure has one plausible change behind it.

5 Restrict the server and verify the result

$result = Update-AzStorageFileServiceProperty `
-ResourceGroupName $resourceGroupName `
-StorageAccountName $storageAccountName `
-SmbChannelEncryption 'AES-256-GCM'

$result.ProtocolSettings.Smb.ChannelEncryption

Run a real test logon from a drained host that has no existing SMB session to the storage account. Confirm the profile container attached, review the matching Profile log, and test each non-FSLogix workload found during inventory. A test over an existing SMB session does not exercise new-session policy evaluation.

6 Prepare an exact rollback

$previousChannelEncryption = @(
$serverBefore.ProtocolSettings.Smb.ChannelEncryption
)

if ($previousChannelEncryption.Count -eq 0) {
# Clear the custom restriction and return to the platform default.
Update-AzStorageFileServiceProperty `
-ResourceGroupName $resourceGroupName `
-StorageAccountName $storageAccountName `
-SmbChannelEncryption @()
}
else {
# Restore the exact explicit value captured before the change.
Update-AzStorageFileServiceProperty `
-ResourceGroupName $resourceGroupName `
-StorageAccountName $storageAccountName `
-SmbChannelEncryption $previousChannelEncryption
}

The original rollback restored only AES-128-GCM and AES-256-GCM. That can restore compatibility for modern clients, but it is not the same as returning to Azure Files defaults. The current Az.Storage cmdlet documentation uses an empty array to clear a custom SMB security setting.

Portal caution Maximum security applies several SMB restrictions together. Use Custom when you need controlled sequencing, and record the current values before saving. One preset can change protocol versions, authentication methods, Kerberos ticket encryption and channel encryption in the same action.

Signals that looked useful but were not decisive

A SYSTEM share test checks the computer identity

Azure Run Command executes as LocalSystem. On a domain-joined machine, LocalSystem presents the computer account to network services. Azure Files share-level Azure RBAC roles cannot be assigned directly to computer accounts because those accounts do not sync to Microsoft Entra ID, although a default share-level permission and Windows ACLs can allow access. A failed Get-ChildItem from Run Command therefore tests the computer identity, not the default FSLogix user identity.

The failure is expected only when that computer identity has not been granted access through the chosen share-level and ACL model. It does not prove that the share is missing, and it does not validate a user’s FSLogix path.

A third party klist can shadow the Windows tool

On these hosts, an MIT Kerberos installation placed another klist earlier in the path. It rejected Windows syntax with MIT-style usage text. Calling the Windows binary by its full path removed that ambiguity.

& "$env:SystemRoot\System32\klist.exe" `
get cifs/stfslogixprod01.file.core.windows.net

SMB event 31018 is a configuration warning

During day two, 0x8009030C SEC_E_LOGON_DENIED appeared near SMB client event 31018. Event 31018 does not prove that a guest fallback occurred. Microsoft defines it as a warning that an administrator enabled AllowInsecureGuestAuth. Events 31017 and 31022 describe rejected and allowed insecure guest logons. In this incident, event 31018 was background configuration evidence, not the root cause.

A strict Kerberos attribute is not automatically wrong

The storage account AD object had msDS-SupportedEncryptionTypes set to 16, which represents AES-256, while the domain controllers allowed 24, which represents AES-128 plus AES-256. The value was long-standing and had not changed in either outage window. It was worth checking, but it was not evidence that it caused these failures.

Recovery includes users who landed in local profiles

Reverting the SMB cipher restriction produced the first successful profile load three minutes later. The service was available again, but some users had already signed in without a profile container. On one host, eight users were active and no FSLogix containers were mounted. Their work existed on the session host’s local disk.

Protect that data before the next sign-in. DeleteLocalProfileWhenVHDShouldApply does not simply discard a profile at sign-out. When enabled, FSLogix permanently deletes an existing local profile at sign-in if the user should receive a profile container. When disabled, the default behaviour can honour an existing local profile instead of attaching the container. Either path can surprise an administrator who tells users to sign out before copying their work.

1. Identify users who signed in during the failure window and stop new logons to the affected host.

2. Tell those users where to save any work that exists only in the local profile. Verify the copy before sign-out.

3. Review the FSLogix profile session state and matching Profile log for each user. Do not infer attachment from a volume label alone.

4. After the storage path is healthy, test one affected user on a drained host before releasing the pool.

5. Decide whether PreventLoginWithFailure and PreventLoginWithTempProfile should block future full-desktop sign-ins when a container cannot attach. Microsoft notes that these controls do not block RemoteApp in the same way.

$sessionRoot = 'HKLM:\SOFTWARE\FSLogix\Profiles\Sessions'

if (Test-Path $sessionRoot) {
Get-ChildItem $sessionRoot | ForEach-Object {
Get-ItemProperty $_.PSPath |
Select-Object @{n='SID';e={$_.PSChildName}}, `
Status, Reason, ErrorCode
}
}

Microsoft documents Status 0 as success, Reason 0 as an attached profile, Reason 3 as a local profile, Reason 7 as a Windows temporary profile, and Reason 9 as a failed profile load. Correlate those values with the user’s logon time and profile log because the registry shows session state, not a complete cause analysis.

What I would keep from both incidents

• 
  Use the Windows error as a starting point and confirm the failing operation in the FSLogix Profile log.
  
• 
  Treat 1326 as an authentication signal and 5 as an access or SMB policy signal. Neither identifies a unique root cause by itself.
  
• 
  Give the Azure Files AD identity an explicit password lifecycle and cleanup exception. It is infrastructure, even when it looks stale.
  
• 
  For AES-256-GCM only, configure and validate supported clients before restricting the Azure Files service.
  
• 
  Capture null versus explicit Azure Files SMB settings and prepare a rollback that restores the exact previous state.
  
• 
  Change channel encryption, authentication method and Kerberos ticket encryption separately. Each control has different dependencies.
  
• 
  Monitor validated message content and status fields for your deployed FSLogix version. Do not alert on event 26 alone.
  
• 
  Include local and temporary profile recovery in the outage plan so the storage fix does not become a user-data incident.
  

Neither original change was reckless. The cleanup job acted on an object that looked stale, and the SMB change selected the strongest channel cipher Azure Files offers. The outages came from missing dependency checks and assumptions that were too broad. A current inventory, a fresh-session test and a verified rollback would have prevented the second outage. A documented identity lifecycle would have prevented the first.

Microsoft references

• Enable AD DS authentication for Azure Files
  
• Update the password for an Azure Files AD DS identity
  
• SMB file shares and SMB security settings in Azure Files
  
• Update AzStorageFileServiceProperty
  
• Set SmbClientConfiguration
  
• FSLogix codes and their meaning
  
• FSLogix logging and diagnostics
  
• FSLogix configuration settings
  
• FSLogix old temporary and local profile troubleshooting
  
• Azure Files authorization and access control
  
• Windows system error codes 1300 to 1699
  
• Windows SMB insecure guest logon events