Does anyone know if WinInternals ERD Commander Locksmith can reset domain admin passwords on Windows 2003?
Hi,
All the passwords in one of our test environments have been changed when the environment was handed over to our team. Unfortunately, the domain admin password (windows 2003 AD) is not what it is supposed to be.
Does anyone have a definitive answer on whether ERD Commander Locksmith can reset the domain admin password. No guesses please.
Thanks
Mick
All the passwords in one of our test environments have been changed when the environment was handed over to our team. Unfortunately, the domain admin password (windows 2003 AD) is not what it is supposed to be.
Does anyone have a definitive answer on whether ERD Commander Locksmith can reset the domain admin password. No guesses please.
Thanks
Mick
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Rich, _domain_ admin password. :)
LM 71CDBB161563F261
NTLM 323D4166E252687B4350E59183
:p
-rich
NTLM 323D4166E252687B4350E59183
:p
-rich
Domain accounts are not in the SAM, they're in AD. What you're cracking (if you're on a DC) is the DSRM password.
AD stores in the sam too. Download PwdumpX (i think they are upto version 4 now) and runn it on your GC, you'll get the hashes.
I do it every month... for several coporations.
-rich
I do it every month... for several coporations.
-rich
That's very strange, I've never heard anything suggesting that, quite the opposite. The pwdump4.02 readme and faq don't mention domain accounts at all. Ntpasswd faq itself says this:
I tried it on Win2k PDC (Active Directory), and it didn't change the password.
* ActiveDirectory (AD) is a completely different database.
* There is no support for directly changing passwords in AD.
I don't have a test DC to try this right now, could someone else verify this?
I tried it on Win2k PDC (Active Directory), and it didn't change the password.
* ActiveDirectory (AD) is a completely different database.
* There is no support for directly changing passwords in AD.
I don't have a test DC to try this right now, could someone else verify this?
Windows 2000 SAM Storage
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/distrib/dsbg_dat_udnu.asp
"The disposition of the security principals in the SAM database on the server is different in each case, as follows:
* If you create an additional domain controller in an existing domain, the security accounts in the existing SAM database on the server are deleted. The accounts from the existing domain are replicated to Active Directory on the new domain controller.
* If you create a new domain, the security accounts in the existing SAM database are preserved as follows:
o User accounts become user objects in Active Directory.
o Local groups in the account domain become group objects in Active Directory. The group type indicates a local group.
o Built-in local groups become group objects in Active Directory. The group type indicates a built-in local group. These groups retain their constant SIDs and are stored in the Builtin container."
This further suggests that only local accounts are retained in the SAM. So, are you sure the admin account you are reseting/cracking is the domain admin and not the DSRM admin?
http://www.microsoft.com/resources/documentation/Windows/2000/server/reskit/en-us/Default.asp?url=/resources/documentation/Windows/2000/server/reskit/en-us/distrib/dsbg_dat_udnu.asp
"The disposition of the security principals in the SAM database on the server is different in each case, as follows:
* If you create an additional domain controller in an existing domain, the security accounts in the existing SAM database on the server are deleted. The accounts from the existing domain are replicated to Active Directory on the new domain controller.
* If you create a new domain, the security accounts in the existing SAM database are preserved as follows:
o User accounts become user objects in Active Directory.
o Local groups in the account domain become group objects in Active Directory. The group type indicates a local group.
o Built-in local groups become group objects in Active Directory. The group type indicates a built-in local group. These groups retain their constant SIDs and are stored in the Builtin container."
This further suggests that only local accounts are retained in the SAM. So, are you sure the admin account you are reseting/cracking is the domain admin and not the DSRM admin?
I was not reffering to using the nt reset disk to minipulate the password in the SAM. I was referring to AD storing the hases of the users in the SAM, and using Pwdump to dump the hases for cracking, pwdump doesn't reset them. AD apparently has 2 copies of the passwords, on in AD (UPN) and one in the SAM. I dump the SAM off of a dozen DC's every month to do password audit's.
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/deploy/projplan/adarch.mspx
SAM Account Name
A Security Account Manager (SAM) account name is required for compatibility with Windows NT 3.x and Windows NT 4.0 domains. The Windows 2000 user interface refers to the SAM account name as the "User logon name (pre-Windows 2000)."
SAM account names are sometimes referred to as flat names because—unlike DNS names—SAM account names do not use hierarchical naming. Because SAM names are flat, each one must be unique in the domain.
If this isn't an option for the asker, your first link: http://www.petri.co.il/reset_domain_admin_password_in_windows_server_2003_ad.htm
Will probably be the way to go.
-rich
PS use the AT command ( at 10:54 /interactive regedit ) set the time to 1 minute in the future, then open the SAM hive using regedit (when it opens) HKEY_LOCAL_MACHINE\SECURIT
And you'll see the username in your macine, or do this on a GC/DC and see the users listed in the SAM db
http://www.microsoft.com/technet/prodtechnol/windows2000serv/technologies/activedirectory/deploy/projplan/adarch.mspx
SAM Account Name
A Security Account Manager (SAM) account name is required for compatibility with Windows NT 3.x and Windows NT 4.0 domains. The Windows 2000 user interface refers to the SAM account name as the "User logon name (pre-Windows 2000)."
SAM account names are sometimes referred to as flat names because—unlike DNS names—SAM account names do not use hierarchical naming. Because SAM names are flat, each one must be unique in the domain.
If this isn't an option for the asker, your first link: http://www.petri.co.il/reset_domain_admin_password_in_windows_server_2003_ad.htm
Will probably be the way to go.
-rich
PS use the AT command ( at 10:54 /interactive regedit ) set the time to 1 minute in the future, then open the SAM hive using regedit (when it opens) HKEY_LOCAL_MACHINE\SECURIT
And you'll see the username in your macine, or do this on a GC/DC and see the users listed in the SAM db
Yeah I now the usernames are there, but the password hashes?? If you can find any domain account's LM and NTLM hashes in the local SAM, whats the point of encrypting them in the AD? Or bothering with dumping LSA secrets? Why isn't this headline news?
Oh nevermind, you're right, sort of. The hashes are stored locally IF you change the default setting of the NoLMHash setting, controlled by the Network security: Do not store LAN Manager hash value on next password change policy which is disabled by default on W2000/2003.
Hahaha headline news... The SAM is there for backward compatibilty, even if your in an ALL AD envronment, by default/design the SAM is still there. There was a big stink about this when AD came out... If you've noticed, when you authenticate to a share, your LM/NTLM hashes are used, not AD kerberos credentials. When you use a program like outlook, depending on your settings, you also auth with LM/NTLM and possibly kerberos. Fire up cain&able (www.oxid.it) , sniff your connections, you'll see your lm/ntlm passes still being used. This is most likely why AD still uses a SAM, so that it does have to convert AD (UPN) passes back into a hash for comparison, it just keeps them for less overhead.
AD really offers no better authentication, and for that mater password storage, since it still contains the lm/ntlm hashs (were getting off topic)
-rich
AD really offers no better authentication, and for that mater password storage, since it still contains the lm/ntlm hashs (were getting off topic)
-rich
The setting only affects the case insensitve LM hashes, which are all upper case. The NTLM's are still stored, and they are case sensitive, which add's some more time to cracking, but they still fall easily. Ok, I'm done, I swear :)
If lambch0p has any more questions about the topic, we'll do our best to assist.
-rich
If lambch0p has any more questions about the topic, we'll do our best to assist.
-rich
Kerberos is always used as the first option, NTLM only if it fails.
Hrm noticed I made an error again, 'Do not store' is disabled...so yes it's enabled by default. :/
Hrm noticed I made an error again, 'Do not store' is disabled...so yes it's enabled by default. :/
Rich, can Nordahl's utility really do it?
Nordahl himself links http://www.jms1.net/nt-unlock.html which as quite equal to petri's / CoccoBill's method.
Nordahl himself links http://www.jms1.net/nt-unlock.html which as quite equal to petri's / CoccoBill's method.
It did for me on an 2003/NT domain contoller for me... not tested it with an AD GC/DC server. I've not tested it, and don't have the time currently.
-rich
-rich
ASKER
Wow.
Thanks for all the info guys. I've got a bit of reading to do.
M
Thanks for all the info guys. I've got a bit of reading to do.
M
ASKER
I'm going to keep the question open to see if I get a definite answer, but as your tip should get me out of trouble, I have increased the points, and will give you 250 of them when I close the question.
Mick