However, you must write the 0 before you write the -1, that is the little secret. Otherwise it doesn't do anything because it knows it is wrong...
joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Friday, October 03, 2003 11:12 AM To: AD mailing list (Send) As Joe pointed out, the attribute is owned by the system (the SAM I believe) and subsequently logic is in force when submitting values against it. In the case of pwdLastSet the only permissible values are "0" and "-1". "0" forces an immediate password expiry while "-1" (in my opinion should NOT be permissible but is) manages to pass through the logic and triggers a rewrite of the value to the FileTime representation of "now" effectively indicating the password has just been set. -- Dean Wells MSEtechnology * Tel: +1 (954) 501-4307 * Email: [EMAIL PROTECTED] http://msetechnology.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of [EMAIL PROTECTED] Sent: Friday, October 03, 2003 7:21 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Password Policy - Challenge.... Does the -1 setting tell the system it "never expires"? -----Original Message----- From: Joe [mailto:[EMAIL PROTECTED] Sent: Friday, October 03, 2003 4:24 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Password Policy - Challenge.... See I knew the word challenge in the subject would bring you guys out... In fact Challenge is the alternate spelling for MVP... :op Speaking of which, did you notice that the AD list has doubled? Correct, setting pwdLastSet to 0 will cause it to flag as expired (user must change password on next logon). If you clear that flag due to the implementation of NOT keeping this info in userAccountControl but instead in the attribute that specifies password age will cause that password age to have to become something valid and since it can't be set back to what it was previously (no history), the logical thing is to put it to 0 days old. Keep in mind that that attribute can be set to two things by a programmer without hacking LSASS... 0 or -1. 0 as Tony points out will force the user to be expired right now. So what do you think setting it to -1 would do? Here let me illustrate: File: Test.vbs ---------------- set o=getobject("LDAP://cn=joe,cn=users,dc=joehome,dc=com";) o.pwdlastset=0 o.setinfo o.pwdlastset=-1 o.setinfo Screen Cap of Run ------------------- G:\temp>getuserinfo joehome\joe GetUserInfo V02.07.00cpp Joe Richards ([EMAIL PROTECTED]) September 2003 User information for joehome\joe (\\W2KASDC1) User Name joe Full Name Description User's Comment User Type User Enhanced Authority AccOp Account Type Global Workstations Home Directory User Profile Logon Script Flags Account Expires Never Password age in days 40 Password last set 8/23/2003 9:37 AM Bad PWD count 0 Num logons (this machine) 24 Last logon 12/21/2002 9:42 AM Logon hours All Global group memberships *Domain Users Local group memberships *Account Operators *Users Completed. G:\temp>test Microsoft (R) Windows Script Host Version 5.6 Copyright (C) Microsoft Corporation 1996-2001. All rights reserved. G:\temp>getuserinfo joehome\joe GetUserInfo V02.07.00cpp Joe Richards ([EMAIL PROTECTED]) September 2003 User information for joehome\joe (\\W2KASDC1) User Name joe Full Name Description User's Comment User Type User Enhanced Authority AccOp Account Type Global Workstations Home Directory User Profile Logon Script Flags Account Expires Never Password age in days 0 Password last set 10/3/2003 7:03 AM Bad PWD count 0 Num logons (this machine) 24 Last logon 12/21/2002 9:42 AM Logon hours All Global group memberships *Domain Users Local group memberships *Account Operators *Users Completed. G:\temp> If you REM out the setting to -1 second piece, this is the account status: G:\temp>getuserinfo joehome\joe GetUserInfo V02.07.00cpp Joe Richards ([EMAIL PROTECTED]) September 2003 User information for joehome\joe (\\W2KASDC1) User Name joe Full Name Description User's Comment User Type User Enhanced Authority AccOp Account Type Global Workstations Home Directory User Profile Logon Script Flags EXPIRED Account Expires Never Password age in days 0 Password last set 10/3/2003 7:11 AM Bad PWD count 0 Num logons (this machine) 24 Last logon 12/21/2002 9:42 AM Logon hours All Global group memberships *Domain Users Local group memberships *Account Operators *Users Completed. G:\temp> So the answer to #3 below is to take the above small code snippet and wrap it with a loop to go through all users you need cleared. Now that I have said this, it is for edumacational purposes only. I DO NOT recommend this as it is bypassing security and logically you do not want to bypass security because there is a reason you have a password policy. That reason being if someone is trying to hack you by brute force it takes X days to get through a password of Y complexity that you have created. Your password policy is supposed to determine a safe value for X for the Y that you use. By passing the policy with either non-expiring accounts or this (dare I say chicken clever :o) hack is not only bad, it is overall stupid to do. That being said I would really hope people just keep this in their noodle for the holy shit what am I going to do occurrances they have to handle and not make this some regular thing that they do. I also think you shouldn't use non-expiring ID's ever either but until MS and other vendors step up to handling services properly, I think we will have a hard time getting away from those. So, was this an assist or was this a goal? Or possibly was this a major penalty? So I wonder if this will be plugged now? And if so how? I can't think of a logical way to do it without maintaining a change log or history so the old value can be ascertained and reverted to. Otherwise the accidental checks in the gui will screw someone. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Murray Sent: Friday, October 03, 2003 4:44 AM To: [EMAIL PROTECTED] Deano (and others) >From what I can see, setting the value of pwdLastSet to 0 has the >effect of setting the "User must change password at next logon" flag. In other words I think the user would be prompted to change their password at next logon. One thing I've noticed is that if you check the "User must change password at next logon" flag using dsa.msc and then subsequently uncheck it, it has the effect of assigning a new pwdLastSet value. This would meet Travis's requirements, but would be very slow for a large number of users. Another way of doing this would be to set the value of pwdLastSet programatically, but as this involves working with large integers (which scare me for some reason), it may not be easy. A different option which would work for a large number of users would be to toggle the flag using "dsmod user" with the "-mustchpwd {yes | no}" option. You would need to first set the flag using "yes" and then unset it using "no". If I have some time I'll test this and post the results. Tony ---------- Original Message ---------------------------------- From: "Dean Wells" <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Date: Thu, 2 Oct 2003 22:24:30 -0700 Assign the pwdLastSet attribute a value of 0 per necessary user. At next logon, user's password will remain intact and pwdLastSet will be assigned current date and time (represented in FileTime) by the authenticating DC effectively setting user's next password expiry date to (now + password expiry policy days). -- Dean Wells MSEtechnology * Tel: +1 (954) 501-4307 * Email: [EMAIL PROTECTED] http://msetechnology.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Joe Sent: Thursday, October 02, 2003 6:30 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Password Policy - Challenge.... Yep passwords would expire. The policy is on the domain and it is a delta value that is stored in the domain partition that handles this. It causes the system to go back that delta value and then any accounts that haven't been changed since that calculated time are expired. Also this has to be done on the domain policy. You have a couple of options. 1. Send a note to everyone and tell them to change their password. 2. Expire portions of the id's each day until you have gotten through all of them. Then once all done, sey up the domain policy. See my expire tool on www.joeware.net site as that tool was specifically written for this scenario. 3. Get the passwords time reset. Todd's idea below will work but could take a while if you have decent passwords and really isn't the elegant way to do this. Instead you can reset the password timestamp on the user accounts so that they are all started out as if they had just been changed but really haven't and then turn on your policy.... Now I was going to post the way to do this, but thought, you know, let's test the group and see who else knows this little trick..... I will post an answer within a day or if you need it quicker email me at [EMAIL PROTECTED] and I will send a little script to pull it off. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Myrick, Todd (NIH/CIT) Sent: Thursday, October 02, 2003 3:44 PM To: '[EMAIL PROTECTED]' You are correct, your company passwords would expire. The solution I suggest is to crack all the passwords, then reset the original password to each account to reset expiration. Then implement the Domain Account policy again. Also remember that NTLM and Kerberos authentications count double. So if you client has problems with authentication it will try Kerberos then NTLM and a single bad logon counts twice. So 10 bad password attempt really means 5 within the limited time frame you set. Todd -----Original Message----- From: Travis Riddle [mailto:[EMAIL PROTECTED] Sent: Thursday, October 02, 2003 3:09 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] Password Policy I made a slight error when creating a group policy, and now need some advice on how to fix it. Hopefully some one will be kind enough to help out. I have a single domain with 2 sites. I created a Default Policy for the entire domain with fairly minimal settings (such as password policy, proxy settings and a few IE settings). Our manufacturing facility is our largest site, and our corporate offices is significantly smaller, so instead of applying one policy several times I set block policy inheritance for the corporate OU (so they wouldn't get the Proxy and IE settings). I then set password settings on the separate corporate OU. Well, I guess I didn't realize at the time that you could only have one password policy for the domain, so basically they haven't had to change their passwords for some time now. So here is the problem, I need to enable the password policy for corporate, but if I do I think it will immediately expire their passwords (since they are well over 90 days old). Is my thinking wrong here, and is there a way around this or am I going to have to call the corporate guys and have them manually change their passwords? Any ideas? Your suggestions are much appreciated, Thanks, Travis List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
