Azure files with JOIN to ON PREM AD - Kerberos Key Rotation

Question

Hello,

we are using Azure Files with integration to our ON PREM Active Directory. JOIN of the storage account into our Active Directory was done using the AzFiles Hybrid Powershell modules. Everything works without any problems and is productive.

During the join 2 Kerberos keys are generated in the storage account - kerb1/2 e.g. With the function "Update-AzStorageAccountADObjectPassword " new keys can be generated and applied to the domain object: 

Example:

Update-AzStorageAccountADObjectPassword `

        -RotateToKerbKey kerb2 `

        -ResourceGroupName "<your-resource-group-name-here>" `

        -StorageAccountName "<your-storage-account-name-here>" `

 

In the documentation I find the following about this: 

"This action will change the password for the AD object from kerb1 to kerb2. This is intended to be a two-stage process: rotate from kerb1 to kerb2 (kerb2 will be regenerated on the storage account before being set), wait several hours, and then rotate back to kerb1 (this cmdlet will likewise regenerate kerb1)."

I understand that during the update kerb1 will be replaced by a updated kerb2 and thus the password of the domain object will be changed. 

However, it is unclear to me why I should wait for a few hours and then go back to a new kerb1. What is the background?

Answer 1

@AZADMIN Welcome to Microsoft Q&A Forum, Thank you for posting your query here!

The reason for waiting for several hours before rotating back to kerb1 is to ensure that any cached credentials or authorization tokens that were issued using the old password have expired.

When a client authenticates to a domain-joined Azure Files SMB share, it obtains a token that contains an encrypted copy of the account's password. This token can be cached locally and used for subsequent authentication attempts, which can lead to issues if the password is changed during an active session.

By waiting several hours before rotating back to kerb1, you give the clients enough time to refresh their tokens and ensure that they are using the new password. This helps to prevent issues with authentication failures or unexpected behavior due to cached credentials.

It is also worth noting that the specific duration of the waiting period may vary depending on factors such as the size of the domain, the number of clients, and the length of time that tokens are cached. Therefore, it is a good idea to monitor the system and ensure that all clients are able to authenticate successfully before rotating back to kerb1.

Please let us know if you have any further queries. I’m happy to assist you further.

---

Please do not forget to "Accept the answer” and “up-vote” wherever the information provided helps you, this can be beneficial to other community members.