Thanks Dean! Now why exactly did you document this process for a customer? What bad things are you having them do?
joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Friday, October 03, 2003 10:12 AM To: AD mailing list (Send) It appears my memory isn't what it used to be. I'd have laid money that I used a zero value to achieve this, then I saw Joe's reply and was still convinced so (short of testing it myself in a VM) I called the customer where we used this very technique and asked him to open up the doc. outlining the procedure and its effect. He tells me it says "assign a value of -1" ... to which I vigorously respond "who wrote that document?", "you did", he says, ... I imagine the only thing he heard after that was "SHIT, I hate being proved ........ <DIAL TONE>". Nice job Joe :) -- Dean Wells MSEtechnology * Tel: +1 (954) 501-4307 * Email: [EMAIL PROTECTED] http://msetechnology.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Tony Murray Sent: Friday, October 03, 2003 1:44 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Password Policy - Challenge.... 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/
