DSInternals
DSInternals copied to clipboard
Retrieve the "lastPwdSet" and "mail" attributes from Get-ADDBAccount and Get-ADReplAccount
Hello,
I open an issue for enhancement. I have check issues (open/closed) and made some tests with Get-ADDBAccount and Get-ADReplAccount but I can't retrieve the following user account's attributes that I need :
mail: the corporate email of the identity specified stored in the Active DirectorylastPwdSet: the timestamp of the last update of the password
As example, from an ntds.dit file, I have tried:
PS C:\Users\X\Desktop\Active Directory> Get-ADDBAccount -samaccountname krbtgt -BootKey $key -DatabasePath ".\ntds.dit"
DistinguishedName: CN=krbtgt,CN=Users,DC=opmanagement,DC=local
Sid: S-1-5-21-2576180771-3553906584-3249235270-502
Guid: 889fc01f-ef4a-4f0a-97aa-7b628463346d
SamAccountName: krbtgt
SamAccountType: User
UserPrincipalName:
PrimaryGroupId: 513
SidHistory:
Enabled: False
UserAccountControl: Disabled, NormalAccount
SupportedEncryptionTypes: Default
AdminCount: True
Deleted: False
LastLogonDate:
DisplayName:
GivenName:
Surname:
Description: Key Distribution Center Service Account
ServicePrincipalName: {kadmin/changepw}
SecurityDescriptor: DiscretionaryAclPresent, SystemAclPresent, DiscretionaryAclAutoInherited, SystemAclAutoInherited,
DiscretionaryAclProtected, SelfRelative
Owner: S-1-5-21-2576180771-3553906584-3249235270-512
Secrets
[... REDACTED ...]
Key Credentials:
Credential Roaming
Created:
Modified:
Credentials:
In this example, there is the LastLogonDate attribute (obviously empty for krbtgt, but not for other users).
But no "LastPwdSet" nor "mail".
When I pipe the previous command and select *, some others attributes are available:
PS C:\Users\X\Desktop\Active Directory> Get-ADDBAccount -samaccountname krbtgt -BootKey $key -DatabasePath ".\ntds.dit" | select *
DistinguishedName : CN=krbtgt,CN=Users,DC=opmanagement,DC=local
Sid : S-1-5-21-2576180771-3553906584-3249235270-502
SidHistory :
SecurityDescriptor : System.Security.AccessControl.RawSecurityDescriptor
Guid : 889fc01f-ef4a-4f0a-97aa-7b628463346d
DisplayName :
Description : Key Distribution Center Service Account
GivenName :
Surname :
Enabled : False
UserAccountControl : Disabled, NormalAccount
SupportedEncryptionTypes : Default
SupportsKerberosAESEncryption : False
Deleted : False
LastLogon :
LastLogonTimestamp :
LastLogonDate :
UserPrincipalName :
SamAccountName : krbtgt
LogonName : OPMANAGEMENT\krbtgt
PrimaryGroupId : 513
SamAccountType : User
AdminCount : True
ServicePrincipalName : {kadmin/changepw}
NTHash : [... REDACTED ...]
LMHash :
NTHashHistory : [... REDACTED ...]
LMHashHistory : [... REDACTED ...]
SupplementalCredentials : DSInternals.Common.Data.SupplementalCredentials
RoamedCredentialsCreated :
RoamedCredentialsModified :
RoamedCredentials :
KeyCredentials : {}
In the previous output, we can see the new LastLogonTimestamp or LastLogon attributes available.
But no LastPwdSet nor mail.
Same with the pipe | Format-List -Property *.
- Can you confirm to me that these attributes are not returned throught
Get-ADDBAccountandGet-ADReplAccount(or I'm totaly blind 😎) ? - Do you think it is possible to retrieve
LastPwdSetandmailattributes viaGet-ADDBAccountandGet-ADReplAccount?
Thank you again for your great work,
Sincerely,
Hello @yanncam , the mail and pwdLastSet attributes are indeed not retrieved by DSInternals cmdlets. The original purpose of DSInternals was the decryption of secret attributes, which are never exposed through LDAP.
Other methods can be used to read these standard attributes:
- LDAP for live AD
- Database Mounting Tool (dsamain.exe) + LDAP for offline ntds.dit files
That being said, I might add support for these attributes in a future version of DSInternals.
Hello @MichaelGrafnetter, than you for the quick answer.
I understand that the objective of DSInternals is towards the secrets sequestered in the AD, it is not a classic LDAP / AD browser of course.
A definite advantage of DSInternals is that it is notably able to extract information from an AD in offline mode (via the ntds.dit) or in online mode.
When we talk about secrets, and in particular LM / NTLM hashes, DSInternals is already very well equipped to extract them, their history, compare them to the HaveIBeenPwned database with the "Test Password Quality", etc.
However, from all these functions, it is not possible to extract the lastPwdSet or the mail.
Why do I think these two attributes are of interest regarding secrets?
- If one tries to test the robustness of the passwords extracted via DSInternals, one can discover weak passwords which do not respect the password policy defined in the AD. Knowing the
lastPwdSetis interesting to identify the accounts which derogate from this renewal policy precisely. - The
lastPwdSetis also useful for gauging accounts whose password never expires. Of course, they are set to never expire, but a password that has not been changed for +10 years or even + 20 years would still have to be checked to avoid a compromise. - In the event that weak or leaking passwords are identified via DSInternals via the Test password Quality and HaveIBeenPwned, the email is in my opinion useful for precisely automating a routine that would alert these users.
- We can extract the
lastLogon,lastLogonTimestampandlastLogonDate, so in my opinion thelastPwdSetis in the same logic. - In another issue, mention is made of quickly identifying through DSInternals which accounts are kerberoastable. By identifying these accounts and analyzing the date of the last password modification, it would be possible to prioritize those to be renewed first, for example.
For me these attributes have a real interest during the analysis of secrets, precisely to take concrete actions against these accounts subsequently.
Yes, I agree, other standard AD query tools (online) would make it possible to retrieve these elements but would require cross-checking the results, making data crossovers between DSInternals and the tools, with risks correlation errors.
If DSInternals integrated these two attributes directly, that would greatly facilitate the task, especially in the event of forensic analysis on an offline ntds.dit following a compromise of an Active Directory ecosystem for example.
Thank you for your interest and have a nice day,
yanncam Good reasoning, added to my backlog.
👍 ! Thank you for consider it :) !