That is a good use of the bu... Err feature. I understand on the logging off business. I always thought it would be handy for MS to pop a dialog box when the expiration was coming up versus waiting for the logon. I guess with Win9x logoff/logon was a requirement but my W2K3/W2K/XP machines go quite a while between reboots and logoffs.
joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GRILLENMEIER,GUIDO (HP-Germany,ex1) Sent: Monday, October 06, 2003 4:12 PM To: [EMAIL PROTECTED] and as mentioned in some other previous thread, this documenation, which is way overdue is coming out as a whitepaper in roughly a month... It should answer all those "which permissions to I need to set on which attribute to allow this or that" questions. BTW, we're also leveraging the pwdLastSet "backdoor" to fix some things during migrations (e.g. if you've migrated many accounts from a large domain and it takes you forever to update some users profiles => after you've finally activated those accounts in AD, you don't want to add more pain to them by forcing an immediate PW change on them. However, depending on your PW policy in the AD domain, you can't simply re-migrate the users' PW (e.g. due to PW history), but you'd still like them to keep the PW for the first period after the migration... => that's where this "fix" helps as well ;-) Furthermore, we're using the pwLastSet attribute to calculate the time when a user will need to change his PW and then send out customized eMail notifications 10 and 5 days prior to expiry. We're also using the default warning you get during interactive logon 14 days prior to expiry, but users who hardly logoff and on or those who logon via a VPN connection typically do not receive this warning... So there's lot's of benefit playing around with the pwLastSet property ;-) But I agree to Joe, that you don't want the wrong guys to use the wrong scripts against it... /Guido -----Original Message----- From: Joe [mailto:[EMAIL PROTECTED] Sent: Samstag, 4. Oktober 2003 14:39 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Password Policy - Challenge.... Ouch... The lesson... Don't play with ACL's in your production environment kids... Run with scissors first, it is less painful. Something like this is why companies that sell role based products should do well. What you described could happen a lot for many people as the number of people who know or take the time to figure out permissioning before experimentation in production is much smaller than don't. Of course this could be helped with better and better documentation of what all the perms are and what all the attributes are (and used for) and how they can interact from Microsoft. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Friday, October 03, 2003 9:20 PM To: AD mailing list (Send) LOL! Not me, at least not this time. The admins. inadvertently re-ACL'd the entire sysvol hierarchy (and much of AD) and managed to deny each and every security principal any permission to perform any action. After a series of reboots (the customer's generic means of fixing anything, one which does sadly work more often than not) the Domain Security Policy was something of a mystery in that the behavior was completely unpredictable. They finally called me in and, after many hours of searching for the cause, I discovered the misplaced ACEs and removed them. We then tested a few of their accounts and received random password change dialogs, we proceeded to change those passwords but they (seemingly) randomly popped back up. The process to force an immediate password expiry or to reset the password expiry timer for certain accounts was documented as I couldn't be sure if the modification to the entire domain would permanently resolve the issue, as it turns out ... it did! I now know why I was so utterly convinced I had set the pwdLastSet to "0", I had ... in preparation for setting the negative value. I've enclosed the remainder of the document below - [SNIP] Specific marked attributes have additional restrictions imposed by the Security Accounts Manager (SAM). A selection of well known SAM read-only entities is outlined - revision, objectSID, domainReplica, creationTime modifiedCount, modifiedCountAtLastPromotion, nextRID, serverState, samAccountType, isCriticalSystemObject, dbcsPwd, ntPwdHistory, lmPwdHistory, lastLogon, lastLogoff, badPasswordTime, badPwdCount, logonCount, supplementalCredentials. Further, there are a variety of other attributes upon which the SAM enforces specific rules - sAMAccountName: Domain-wide uniqueness, without replication latency, 20-character limit for user objects (not groups). Member: Membership rules as defined in Windows 2000 groups. userWorkstations: Must be valid computer names. primaryGroupID: For a user/computer account, must point to a group and the user /computer account must be a member of the group; the group and the user must be in the same domain. If the computer is a domain controller, the primary group must be the domain controllers group. LockoutTime: For a user or computer object. Only permissible value that can be written is 0 to clear an account. pwdLastSet: The system normally maintains it, but two special values can be written 0 and -1 to expire/unexpire a password. [/SNIP] I'm uncertain as to the exact source of that subset but, in the few cases where I've had cause to use it as a reference, it has been accurate. Dean -- 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: Friday, October 03, 2003 5:27 PM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Password Policy - Challenge.... 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/ 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/
