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/
