The msDS-KeyVersionNumber attribute stores the Kerberos Key Version Number (KVNO) for a user, computer, or built-in account in Active Directory (AD). It is a constructed attribute: AD computes its value automatically from the version counter on the account's unicodePwd attribute. The value increments by one each time the account's password changes, giving Kerberos clients and Key Distribution Centers (KDCs) a reliable way to detect stale session keys.
Because msDS-KeyVersionNumber is read-only, this article focuses on how to read and monitor it: using Active Directory Users and Computers (ADUC), PowerShell, and ManageEngine ADManager Plus.
| LDAP display name | msDS-KeyVersionNumber |
| CN | ms-DS-KeyVersionNumber |
| Syntax | Enumeration (Integer—attributeSyntax: 2.5.5.9, omSyntax: 2) |
| OM-Syntax | 2 |
| Attribute ID (OID) | 1.2.840.113556.1.4.1782 |
| System ID GUID | c523e9c0-33b5-4ac8-8923-b57b927f42f6 |
| Single- or multi-valued | Single-valued |
| Indexed | No |
| In Global Catalog | No |
| Replicated | No. Constructed locally on each DC; not replicated. |
| System-Only ( writable ) | True—read-only. Cannot be set directly. |
| Constructed | Yes. Computed from the dwVersion field of the unicodePwd AttributeStamp. |
| Visible in ADUC UI | No. Requires the Attribute Editor tab. |
| Applies to | Security-Principal class (users, computers, built-in accounts) |
| First implemented | Windows Server 2003 |
| Source schema | Microsoft core AD schema |
| Microsoft reference | Win32 ADSchema · MS-ADA2 · MS-ADTS computation spec |
Note: msDS-KeyVersionNumber is a System-Only constructed attribute. Any attempt to write to it directly via ADSI Edit, Set-ADUser, or LDAP will fail with an error. The value is managed entirely by AD and increments automatically on each password change. The only supported way to indirectly influence the KVNO is to change the account's password.
msDS-KeyVersionNumber was introduced in Windows Server 2003 to give AD a monotonically increasing counter that tracks how many times a security principal's Kerberos keys have been rotated. Before Windows Server 2003, the key version number was derived from a timestamp rather than a counter, which made KVNO collisions possible in certain scenarios. The counter-based approach introduced in 2003 eliminated that ambiguity.
Every time an account's password changes in AD, the domain controller increments the version counter on the unicodePwd attribute. AD then exposes the current counter value as msDS-KeyVersionNumber. The Kerberos protocol uses this value so that a KDC can detect when a client is presenting a ticket encrypted with a key that has since been rotated, and reject it with a KRB_AP_ERR_MODIFIED or KRB_AP_ERR_BADKEYVER error.
Common scenarios where admins need to read msDS-KeyVersionNumber include:
Because msDS-KeyVersionNumber is constructed and not replicated, the value you read depends on which domain controller you query. Each DC computes the value locally. For the most current value, always query the PDC Emulator or the DC that processed the most recent password change.
View only: msDS-KeyVersionNumber is a constructed, System-Only attribute. The Attribute Editor displays the current computed value, but the field is not editable. Attempting to edit it will result in an "Access is denied" or "The attribute syntax specified to the directory service is invalid" error.
Note: If msDS-KeyVersionNumber does not appear in the Attribute Editor or shows as <not set>, Advanced Features may not be enabled, or you may be viewing the object on a read-only domain controller (RODC). Because the attribute is constructed and not replicated, it may not be visible on all DCs. Query the PDC Emulator or a full writable DC for a reliable reading.
Because msDS-KeyVersionNumber is a constructed attribute, it is not returned by default with Get-ADUser or Get-ADComputer. You must request it explicitly using the -Properties parameter. All read operations should be directed at the PDC Emulator or a specific writable DC to ensure the most current value.
Get-ADUser -Identity jsmith -Properties 'msDS-KeyVersionNumber' |
Select-Object Name, SamAccountName, 'msDS-KeyVersionNumber'
Returns the current KVNO for the specified user account. Use single quotes around the attribute name to handle the hyphen.
Get-ADUser -Identity jsmith -Properties 'msDS-KeyVersionNumber', PasswordLastSet |
Select-Object Name, SamAccountName, PasswordLastSet, 'msDS-KeyVersionNumber'
Returns KVNO alongside the last password change date, useful for correlating key rotation with password history.
Get-ADComputer -Identity WEB01 -Properties 'msDS-KeyVersionNumber' |
Select-Object Name, 'msDS-KeyVersionNumber'
Returns the KVNO for the specified computer account. Computer account passwords rotate automatically every 30 days by default, so the KVNO increments regularly.
$PDC = (Get-ADDomain).PDCEmulator
Get-ADUser -Identity jsmith -Properties 'msDS-KeyVersionNumber' `
-Server $PDC |
Select-Object Name, 'msDS-KeyVersionNumber'
Directs the query to the PDC Emulator to ensure the most current KVNO is returned, regardless of which DC your session defaults to.
$PDC = (Get-ADDomainController -Discover -Service PrimaryDC).HostName
Get-ADUser -Identity krbtgt `
-Properties 'msDS-KeyVersionNumber', PasswordLastSet `
-Server $PDC |
Select-Object DistinguishedName, PasswordLastSet, 'msDS-KeyVersionNumber'
Returns the KRBTGT account's current KVNO and last password set date. The KVNO should be two or higher after a two-reset Golden Ticket remediation cycle.
$PDC = (Get-ADDomain).PDCEmulator
Get-ADUser -Filter {ServicePrincipalName -like '*'} `
-Properties SamAccountName, 'msDS-KeyVersionNumber', PasswordLastSet, ServicePrincipalName `
-Server $PDC |
Select-Object Name, SamAccountName, PasswordLastSet, 'msDS-KeyVersionNumber',
@{N='SPNs'; E={ ($_.ServicePrincipalName) -join '; ' }} |
Export-Csv .\service-account-kvno-report.csv -NoTypeInformation
Finds all accounts with at least one SPN, retrieves the current KVNO for each, and exports a CSV for tracking which accounts need keytab regeneration after a password change.
ADManager Plus can surface msDS-KeyVersionNumber through custom attribute reports, giving you a centralized view of KVNO values across users and service accounts without running individual PowerShell queries. Because the attribute is read-only, all ADManager Plus workflows for it are reporting and monitoring, not modification.
ADManager Plus prebuilt user reports include User Attribute Reports that can be customized to show msDS-KeyVersionNumber alongside pwdLastSet and SPN data. This is particularly useful for tracking which service account keytabs are at risk of becoming stale after a password rotation cycle.
To allow a help desk operator or security analyst to view KVNO data for service accounts without granting broader AD read rights, use help desk delegation:
By default, msDS-KeyVersionNumber is readable by all authenticated users in the domain, consistent with the general AD principle that non-sensitive attributes on user and computer objects are world-readable to domain members. The KVNO itself is not a secret: it is embedded in Kerberos tickets and transmitted in the clear as part of the AP-REQ structure. Knowing a principal's KVNO gives an attacker no cryptographic advantage.
Confirm that Advanced Features is enabled in ADUC (View > Advanced Features). If Advanced Features is already on and the attribute still does not appear, you may be connected to a read-only domain controller (RODC) or a pre-2003 DC. The attribute was introduced in Windows Server 2003 and is not present on older DCs. Reconnect to a full writable DC or the PDC Emulator.
The attribute must be requested explicitly. Confirm your command includes -Properties 'msDS-KeyVersionNumber' with single quotes around the attribute name. If the value is still empty, confirm you are querying a writable DC with -Server $PDC. If the account was created without an initial password, for example, if some scripted or provisioning flows leave unicodePwd unset until the first password change, the attribute may return empty until a password is set.
The keytab was generated before the most recent password change and now contains a stale KVNO. Read the current msDS-KeyVersionNumber value from the PDC Emulator and regenerate the keytab using ktpass with the updated account credentials. The KVNO parameter passed to ktpass must match the value you read from AD.
msDS-KeyVersionNumber is a constructed attribute and is not replicated between DCs. Each DC computes the value independently from the local copy of the unicodePwd AttributeStamp. If AD replication is healthy, all DCs will converge to the same value after the password change replicates. If the values diverge and replication is healthy, check for USN rollback or lingering objects on the DC showing the lower value.
This is expected behavior when a domain is upgraded from a 2003 functional level to 2008 or later. In domains that were originally created at the Windows 2000 functional level, the KVNO was derived from a timestamp rather than a simple counter, resulting in values in the tens of thousands or higher. After upgrading to Windows Server 2003 or later, subsequent password changes increment the counter normally from that large baseline. The large value is not harmful.
msDS-KeyVersionNumber is System-Only and cannot be written directly. The error is expected. To increment the KVNO, change the account's password using Set-ADAccountPassword or through ADUC. There is no supported way to set the KVNO to an arbitrary value.
ADManager Plus gives you centralized visibility into Kerberos key versions, service account password rotation, and KRBTGT health, without requiring Domain Admin rights for every audit task. You can view msDS-KeyVersionNumber values, build custom KVNO reports, and delegate read access to security analysts, all from a single console.
The integer value is a monotonically increasing counter representing how many times the account's Kerberos keys have been updated. A value of one typically means the password has been set once since the account was created or since the domain was upgraded to Windows Server 2003. Higher values reflect additional password changes over the account's lifetime.
No. There is no supported mechanism to reset the KVNO counter. The value increments monotonically and cannot be decremented or reset via any AD management tool. In practice, there is no operational reason to reset it: the Kerberos protocol only requires that the KVNO in a client's keytab or ticket matches the current value in AD.
Yes. Computer accounts reset their passwords automatically every 30 days by default (configurable via Group Policy). Each automatic machine password change increments the computer's msDS-KeyVersionNumber. This is normal behavior and does not require any administrator action.
No. The attribute is not replicated to the Global Catalog, and it is not replicated between domain controllers at all. It is constructed locally in each DC. For this reason, always target the PDC Emulator or the specific DC that processed the most recent password change when reading the value.
msDS-KeyVersionNumber is an on-premises AD DS constructed attribute and is not part of the Microsoft Entra Connect synchronization attribute set. Kerberos key versioning in Entra ID is managed separately through the Entra Kerberos infrastructure (used for Windows Hello for Business and Entra Kerberos Cloud Trust).
Yes, when the values match they refer to the same integer. The kvno field embedded in a keytab file generated by ktpass is taken directly from msDS-KeyVersionNumber at the time the keytab was created. Subsequent password changes increment the AD attribute, leaving the keytab's embedded kvno stale. Authentication fails until a new keytab is generated with the updated KVNO.