Correct never expires is part of the userAccountControl bitflags attribute.
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Roger Seielstad Sent: Friday, October 03, 2003 10:41 AM To: '[EMAIL PROTECTED]' Not really. If I remember the schema correctly, it is simply a flag as to whether or not the password has expired. The "never expires" attribute is part of a separate bit flag field, I believe. -------------------------------------------------------------- Roger D. Seielstad - MTS MCSE MS-MVP Sr. Systems Administrator Inovis Inc. > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] > Sent: Friday, October 03, 2003 10: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/
