1. For the specific case of using CTRL+ALT+DEL because your password has expired or you just felt like changing your password:
If you are using a modern OS like Windows 7 with AD, the computer uses the Kerberos protocol end to end. This starts with a normal AS_REQ logon, but to a special service principal name of kadmin/changepw , as described in http://www.ietf.org/rfc/rfc3244.txt .
The computer first contacts a KDC over port 88, then communicates over port 464 to send along the special AP_REQ and AP_REP. You are still using Kerberos cryptography and sending an encrypted payload containing a KRB_PRIV message with the password. Therefore, to get to the password, you have to defeat Kerberos cryptography itself, which means defeating the crypto and defeating the key derived from the cryptographic hash of the user's original password. Which has never happened in the history of Kerberos.
The parsing of this kpasswd traffic is currently broken in NetMon's latest public parsers, but even when you parse it in WireShark, all you can see is the encryption type and a payload of encrypted goo. For example, here is that Windows 7 client talking to a Windows Server 2008 R2 DC, which means AES-256:
Aka: Insane-O-Cryption ™
On the other hand, if using a crusty OS like Windows XP, you end up using a legacy password mechanism that worked with NT 4.0 – in this case SamrUnicodeChangePasswordUser2 ( http://msdn.microsoft.com/en-us/library/cc245708(v=PROT.10).aspx) .
XP also supports the Kerberos change mechanism, but by default uses NTLM with CTRL+ALT+DEL password changes. Witness:
This uses “RPC over SMB with Named Pipes” with RPC packet privacy. You are using NTLM v2 by default (unless you set LMCompatibility unwisely) and you are still double-protected (the payload and packets), which makes it relatively safe. Definitely not as safe as Win7 though – just another reason to move forward.
You can disable NTLM in the domain if you have Win2008 R2 DCs and XP is smart enough to switch to using Kerberos here:
... but you are likely to break many other apps . Better to get rid of Windows XP.
2. A lot of administrative code use SamrSetInformationUser2, which does not require knowing the user’s current password ( http://msdn.microsoft.com/en-us/library/cc245793(v=PROT.10).aspx ). For example, when you use NET USER to change a domain user’s password:
This invokes SamrSetInformationUser2 to set Internal4InformationNew data:
So, doubly-protected (a cryptographically generated, key signed hash covered by an encrypted payload). This is also “RPC over SMB using Named Pipes”
The crypto for the encrypted payload is derived from a key signed using the underlying authentication protocol, seen from a previous session setup frame (negotiated as Kerberos in this case):
3. The legacy mechanisms to change a user password are NetUserChangePassword ( http://msdn.microsoft.com/en-us/library/windows/desktop/aa370650(v=vs.85).aspx ) and IADsUser::ChangePassword ( http://msdn.microsoft.com/en-us/library/windows/desktop/aa746341(v=vs.85).aspx )
4. A local user password change usually involves SamrUnicodeChangePasswordUser2, SamrChangePasswordUser, or SamrOemChangePasswordUser2 ( http://msdn.microsoft.com/en-us/library/cc245705(v=PROT.10).aspx ).
a. In IIS manager, expand the server name node.
b. Click on Application Pools .
c. On the right, locate and highlight the SCEP application pool.
d. In the Action pane on the right, click on Advanced Settings....
e. Under Process Model click on Identity, then click on the … button.
f. In the Application Pool Identity dialog box, select Custom account and then click on Set….
g. Enter the custom application pool account name, and then set and confirm the password. Click Ok, when finished.
h. Click Ok, and then click Ok again.
i. Back on the Application Pools page, verify that SCEP is still highlighted. In the Action pane on the right, click on Recycle….
j. You are done.
Once for the chat log alone
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.