This has been a fun topic of discussion on Server Fault. There appear to be varying "religious views" on the topic.
I agree with Microsoft's recommendation: Use a sub-domain of the company's already-registered Internet domain name.
So, if you own foo.com, use ad.foo.com or some such.
The most vile thing, as I see it, is using the registered Internet domain name, verbatim, for the Active Directory domain name. This causes you to be forced to manually copy records from the Internet DNS (like www) into the Active Directory DNS zone to allow "external" names to resolve. I've seen utterly silly things like IIS installed on every DC in an organization running a web site that does a redirect such that someone entering foo.com into their browser would be redirected to www.foo.com by these IIS installations. Utter silliness!
Using the Internet domain name gains you no advantages, but creates "make work" every time you change the IP addresses that external host names refer to. (Try using geographically load-balanced DNS for the external hosts and integrating that with such a "split DNS" situation, too! Gee-- that would be fun...)
Using such a subdomain has no effect on things like Exchange email delivery or User Principal Name (UPN) suffixes, BTW. (I often see those both cited as excuses for using the Internet domain name as the AD domain name.)
I also see the excuse "lots of big companies do it". Large companies can make boneheaded decisions as easily (if not moreso) than small companies. I don't buy that just because a large company makes a bad decision that somehow causes it to be a good decision.
The 'typical' answer is to log on with another admin user and reset the password via active directory users and computers. Is there a reason you can't do this?
I haven't tested it but if you've locked out all your domain administrator accounts then you might give this a look.
Best Answer
Enable Advanced auditing on the domain controllers for Account Management: Audit User Account Management
Note that if you enable Advanced auditing, you must not use legacy auditing.
Here are some of the events of interest:
4723: An attempt was made to change an account's password
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4723
The user attempted to change his/her own password. Subject and Target should always match. Don't confuse this event with 4724.
This event is logged as a failure if his new password fails to meet the password policy.
If the user fails to correctly enter his old password this event is not logged. Instead, for domain accounts, a 4771 is logged with kadmin/changepw as the service name.
This event is logged both for local SAM accounts and domain accounts.
You will also see event ID 4738 informing you of the same information.
4738: A user account was changed
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4738
The user identified by Subject: changed the user identified by Target Account:.
Attributes show some of the properties that were set at the time the account was changed.
This event is logged both for local SAM accounts and domain accounts.
Depending on what was changed you may see other User Account Management events specific to certain operations like password resets.
4724: An attempt was made to reset an accounts password
https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4724
The Subject attempted to reset the password of the Target:
Don't confuse this event with 4723.
This event is logged as a failure if the new password fails to meet the password policy.
This event is logged both for local SAM accounts and domain accounts.
You will also see one or more event ID 4738s informing you of the same information.