RE: [ActiveDir] Few quick ones on password polices
Title: Few quick ones on password polices cheers for the answers, boys and girls. strictly speaking, I didn't need to deny the users the ability to change their password but did it anyway. mostly so they wouldn't complain that'd they'd just changed their password during the implementation period. I did miss blocking the inheritance for the OUs I wasn't rolling out to immediately though. bit of a boo-boo on my behalf, but nothing major kicked off. well, other than their machines locking after 20 mins of inactivity. For Troup Bywaters + Anders Tim Sutton T: +44 (0) 113 243 2241 F: +44 (0) 113 242 4024 E: [EMAIL PROTECTED] W: www.TBandA.com Eastgate House 10 Eastgate Leeds LS2 7JL Office Location Map From: joe [mailto:[EMAIL PROTECTED] Sent: 17 February 2005 03:47To: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Few quick ones on password polices This would put the domain into an entirely inconsistent state. I have helped companies get out of similar predicaments that they got into accidently like this that was due to poor FRS replication. Basically what happens is that the changes get applied locally, replicate out through the domain partition, get stomped on by some other DC somewhere else which replicates back out. If you different policies on several DCs you would be entirely in flux and could never guarantee where you would be in terms of settings as it would depend on which DC you last replicated in changes from and whether or not the local policy had recently reapplied. I have seen this for password policies, lockout policies, and restricted groups (this is a hoot if the group is admins or domain admins because you have to time your logon at a point when you have rights). Basically anything that replicates in the directory as well as through FRS. This is fairly easy to catch by looking at version numbers on the domain nc attributes, when you see something that is the hundreds, you may have an issue. Alternatively have a script that watches for changes and you will keep seeing the domain NC popping up as changing. joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-EliaSent: Wednesday, February 16, 2005 7:43 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Few quick ones on password polices Actually, this isn't entirely true. A little testing on Win2K3 shows the following: If I have domain account policy defined, say, on the Default Domain Policy, and I set block inheritance on the Domain Controllers OU, then any changes to the domain account policy on that domain-linked GPO will be ignored by DCs located in the DC OU. You can see this by looking at the effective account policy on a given DC by firing up the local GPO editor (gpedit.msc). If you look at account policy on the local GPO of a DC, it shows the current effective policy as delivered by any domain linked GPOs. If you try to change it from the local GPO, you'll noticed its grayed out--and can't be changed. Interestingly, if you set Block Inheritance on the DC OU, not only are changes to domain account policy from that domain-linked GPO ignored, but you can now change the local account policy on a given DC from the local GPO editor. Obviously that isn't too desirable since this would imply to me that you could have a different account policy on each DC. Yuck. Its unclear to me whether AD has any kind of mechanism to prevent this, but I am currently doubting it until I test some more. So bottom line is don't put Block Inheritance on the DC OU or, better yet, always set the GPO where you define domain account policy to Enforced. Darren From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Wednesday, February 16, 2005 12:38 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Few quick ones on password polices 1. Correct 2. Yes and no. Account policies as applied onto domain users can't be blocked. However you can block those policies from being applied to the local policies of member machines. I don't think you need to set "user can not change password", if the person doesn't want their password changed, setting that only prevents them from doing it. joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim SuttonSent: Wednesday, February 16, 2005 1:05 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Few quick ones on password polices Hey all! Can you do me a quick favour and just confirm that I'm not going mad by agreeing (or not, if I'm wrong) with these: 1) you can only apply password policies (account policies to be exact, but this is a bone of contention here at the moment) at the domain level. i.e.: if the domain is abc.com you have to apply it at that level, not below. 2) account policies cannot be blocked by using the "block inheritance" option? Not too sure on this one, so could do with it clearin
RE: [ActiveDir] Few quick ones on password polices
Title: Few quick ones on password polices 1. Correct 2. Yes and no. Account policies as applied onto domain users can't be blocked. However you can block those policies from being applied to the local policies of member machines. I don't think you need to set "user can not change password", if the person doesn't want their password changed, setting that only prevents them from doing it. joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim SuttonSent: Wednesday, February 16, 2005 1:05 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Few quick ones on password polices Hey all! Can you do me a quick favour and just confirm that I'm not going mad by agreeing (or not, if I'm wrong) with these: 1) you can only apply password policies (account policies to be exact, but this is a bone of contention here at the moment) at the domain level. i.e.: if the domain is abc.com you have to apply it at that level, not below. 2) account policies cannot be blocked by using the "block inheritance" option? Not too sure on this one, so could do with it clearing up. As a fail safe I'm going to make sure I've got "password never expires" and "user can not change password" options selected for those people who I don't want their password changing just yet. Any answers greatly received and advice always welcome. Cheers, folks. For Troup Bywaters + Anders Tim Sutton T: +44 (0) 113 243 2241 F: +44 (0) 113 242 4024 E: [EMAIL PROTECTED] W: www.TBandA.com Eastgate House 10 Eastgate Leeds LS2 7JL Office Location Map Groupshield 6.0 - Troup Bywaters AndersPrivilege and Confidentiality NoticeThis email and any attachments to it are intended only for the party to whom they are addressed. They may contain privileged and / or confidential information. If you have received this transmission in error please notify the sender immediately and delete any digital copies and destroy any paper copies. Thank you.
RE: [ActiveDir] Few quick ones on password polices
Title: Few quick ones on password polices I used to agree with Joe on topic 2 until I actually ran into a problem in my forest. I needed to make a change to the password complexity setting on one domain and the change wasnt happening. The problem was that the block inheritance setting was checked on the domain controllers OU. Once the checkbox was cleared, the new account policy took affect. This was a Windows 2000 domain. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Wednesday, February 16, 2005 10:38 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Few quick ones on password polices 1. Correct 2. Yes and no. Account policies as applied onto domain users can't be blocked. However you can block those policies from being applied to the local policies of member machines. I don't think you need to set user can not change password, if the person doesn't want their password changed, setting that only prevents them from doing it. joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Sutton Sent: Wednesday, February 16, 2005 1:05 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Few quick ones on password polices Hey all! Can you do me a quick favour and just confirm that I'm not going mad by agreeing (or not, if I'm wrong) with these: 1) you can only apply password policies (account policies to be exact, but this is a bone of contention here at the moment) at the domain level. i.e.: if the domain is abc.com you have to apply it at that level, not below. 2) account policies cannot be blocked by using the block inheritance option? Not too sure on this one, so could do with it clearing up. As a fail safe I'm going to make sure I've got password never expires and user can not change password options selected for those people who I don't want their password changing just yet. Any answers greatly received and advice always welcome. Cheers, folks. For Troup Bywaters + Anders Tim Sutton T: +44 (0) 113 243 2241 F: +44 (0) 113 242 4024 E: [EMAIL PROTECTED] W: www.TBandA.com Eastgate House 10 Eastgate Leeds LS2 7JL Office Location Map Groupshield 6.0 - Troup Bywaters Anders Privilege and Confidentiality Notice This email and any attachments to it are intended only for the party to whom they are addressed. They may contain privileged and / or confidential information. If you have received this transmission in error please notify the sender immediately and delete any digital copies and destroy any paper copies. Thank you.
RE: [ActiveDir] Few quick ones on password polices
Title: Few quick ones on password polices Actually you still agree with me, you just state it differently. :o) In that case, the domainpolicy for the user accounts isn't being applied at all. I believe theidea of the OP sprang form the idea toblock a certain OU from having the policy impact the users in that OU. This isn't possible because the policies are actually initiating changes on the default NC of the domain controllers which are applied to all users within the domain. I.E. When you set the lockout policy for instance you impact a couple of attributes on the default NC, specifically F:\DEV\cpp\dosdadfind -schema -f ldapdisplayname=*lockout* -nodn -nolabel ldapdisplayname AdFind V01.26.00cpp Joe Richards ([EMAIL PROTECTED]) February 2005 Using server: 2k3dc01.joe.comDirectory: Windows Server 2003Base DN: CN=Schema,CN=Configuration,DC=joe,DC=com lockOutObservationWindowlockoutDurationlockoutThresholdlockoutTime 4 Objects returned From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Passo, LarrySent: Wednesday, February 16, 2005 3:21 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Few quick ones on password polices I used to agree with Joe on topic 2 until I actually ran into a problem in my forest. I needed to make a change to the password complexity setting on one domain and the change wasnt happening. The problem was that the block inheritance setting was checked on the domain controllers OU. Once the checkbox was cleared, the new account policy took affect. This was a Windows 2000 domain. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Wednesday, February 16, 2005 10:38 AMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Few quick ones on password polices 1. Correct 2. Yes and no. Account policies as applied onto domain users can't be blocked. However you can block those policies from being applied to the local policies of member machines. I don't think you need to set "user can not change password", if the person doesn't want their password changed, setting that only prevents them from doing it. joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim SuttonSent: Wednesday, February 16, 2005 1:05 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Few quick ones on password polices Hey all! Can you do me a quick favour and just confirm that I'm not going mad by agreeing (or not, if I'm wrong) with these: 1) you can only apply password policies (account policies to be exact, but this is a bone of contention here at the moment) at the domain level. i.e.: if the domain is abc.com you have to apply it at that level, not below. 2) account policies cannot be blocked by using the "block inheritance" option? Not too sure on this one, so could do with it clearing up. As a fail safe I'm going to make sure I've got "password never expires" and "user can not change password" options selected for those people who I don't want their password changing just yet. Any answers greatly received and advice always welcome. Cheers, folks. For Troup Bywaters + Anders Tim Sutton T: +44 (0) 113 243 2241 F: +44 (0) 113 242 4024 E: [EMAIL PROTECTED] W: www.TBandA.com Eastgate House 10 Eastgate Leeds LS2 7JL Office Location Map Groupshield 6.0 - Troup Bywaters AndersPrivilege and Confidentiality NoticeThis email and any attachments to it are intended only for the party to whom they are addressed. They may contain privileged and / or confidential information. If you have received this transmission in error please notify the sender immediately and delete any digital copies and destroy any paper copies. Thank you.
RE: [ActiveDir] Few quick ones on password polices
Title: Few quick ones on password polices That makes me feel better. Its too disruptive to my worldview when I think that Joe could be wrong grin From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Wednesday, February 16, 2005 12:55 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Few quick ones on password polices Actually you still agree with me, you just state it differently. :o) In that case, the domainpolicy for the user accounts isn't being applied at all. I believe theidea of the OP sprang form the idea toblock a certain OU from having the policy impact the users in that OU. This isn't possible because the policies are actually initiating changes on the default NC of the domain controllers which are applied to all users within the domain. I.E. When you set the lockout policy for instance you impact a couple of attributes on the default NC, specifically F:\DEV\cpp\dosdadfind -schema -f ldapdisplayname=*lockout* -nodn -nolabel ldapdisplayname AdFind V01.26.00cpp Joe Richards ([EMAIL PROTECTED]) February 2005 Using server: 2k3dc01.joe.com Directory: Windows Server 2003 Base DN: CN=Schema,CN=Configuration,DC=joe,DC=com lockOutObservationWindow lockoutDuration lockoutThreshold lockoutTime 4 Objects returned From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Passo, Larry Sent: Wednesday, February 16, 2005 3:21 PM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Few quick ones on password polices I used to agree with Joe on topic 2 until I actually ran into a problem in my forest. I needed to make a change to the password complexity setting on one domain and the change wasnt happening. The problem was that the block inheritance setting was checked on the domain controllers OU. Once the checkbox was cleared, the new account policy took affect. This was a Windows 2000 domain. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Wednesday, February 16, 2005 10:38 AM To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] Few quick ones on password polices 1. Correct 2. Yes and no. Account policies as applied onto domain users can't be blocked. However you can block those policies from being applied to the local policies of member machines. I don't think you need to set user can not change password, if the person doesn't want their password changed, setting that only prevents them from doing it. joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim Sutton Sent: Wednesday, February 16, 2005 1:05 PM To: ActiveDir@mail.activedir.org Subject: [ActiveDir] Few quick ones on password polices Hey all! Can you do me a quick favour and just confirm that I'm not going mad by agreeing (or not, if I'm wrong) with these: 1) you can only apply password policies (account policies to be exact, but this is a bone of contention here at the moment) at the domain level. i.e.: if the domain is abc.com you have to apply it at that level, not below. 2) account policies cannot be blocked by using the block inheritance option? Not too sure on this one, so could do with it clearing up. As a fail safe I'm going to make sure I've got password never expires and user can not change password options selected for those people who I don't want their password changing just yet. Any answers greatly received and advice always welcome. Cheers, folks. For Troup Bywaters + Anders Tim Sutton T: +44 (0) 113 243 2241 F: +44 (0) 113 242 4024 E: [EMAIL PROTECTED] W: www.TBandA.com Eastgate House 10 Eastgate Leeds LS2 7JL Office Location Map Groupshield 6.0 - Troup Bywaters Anders Privilege and Confidentiality Notice This email and any attachments to it are intended only for the party to whom they are addressed. They may contain privileged and / or confidential information. If you have received this transmission in error please notify the sender immediately and delete any digital copies and destroy any paper copies. Thank you.
RE: [ActiveDir] Few quick ones on password polices
Title: Few quick ones on password polices Actually, this isn't entirely true. A little testing on Win2K3 shows the following: If I have domain account policy defined, say, on the Default Domain Policy, and I set block inheritance on the Domain Controllers OU, then any changes to the domain account policy on that domain-linked GPO will be ignored by DCs located in the DC OU. You can see this by looking at the effective account policy on a given DC by firing up the local GPO editor (gpedit.msc). If you look at account policy on the local GPO of a DC, it shows the current effective policy as delivered by any domain linked GPOs. If you try to change it from the local GPO, you'll noticed its grayed out--and can't be changed. Interestingly, if you set Block Inheritance on the DC OU, not only are changes to domain account policy from that domain-linked GPO ignored, but you can now change the local account policy on a given DC from the local GPO editor. Obviously that isn't too desirable since this would imply to me that you could have a different account policy on each DC. Yuck. Its unclear to me whether AD has any kind of mechanism to prevent this, but I am currently doubting it until I test some more. So bottom line is don't put Block Inheritance on the DC OU or, better yet, always set the GPO where you define domain account policy to Enforced. Darren From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Wednesday, February 16, 2005 12:38 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Few quick ones on password polices 1. Correct 2. Yes and no. Account policies as applied onto domain users can't be blocked. However you can block those policies from being applied to the local policies of member machines. I don't think you need to set "user can not change password", if the person doesn't want their password changed, setting that only prevents them from doing it. joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim SuttonSent: Wednesday, February 16, 2005 1:05 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Few quick ones on password polices Hey all! Can you do me a quick favour and just confirm that I'm not going mad by agreeing (or not, if I'm wrong) with these: 1) you can only apply password policies (account policies to be exact, but this is a bone of contention here at the moment) at the domain level. i.e.: if the domain is abc.com you have to apply it at that level, not below. 2) account policies cannot be blocked by using the "block inheritance" option? Not too sure on this one, so could do with it clearing up. As a fail safe I'm going to make sure I've got "password never expires" and "user can not change password" options selected for those people who I don't want their password changing just yet. Any answers greatly received and advice always welcome. Cheers, folks. For Troup Bywaters + Anders Tim Sutton T: +44 (0) 113 243 2241 F: +44 (0) 113 242 4024 E: [EMAIL PROTECTED] W: www.TBandA.com Eastgate House 10 Eastgate Leeds LS2 7JL Office Location Map Groupshield 6.0 - Troup Bywaters AndersPrivilege and Confidentiality NoticeThis email and any attachments to it are intended only for the party to whom they are addressed. They may contain privileged and / or confidential information. If you have received this transmission in error please notify the sender immediately and delete any digital copies and destroy any paper copies. Thank you.
RE: [ActiveDir] Few quick ones on password polices
Title: Few quick ones on password polices This would put the domain into an entirely inconsistent state. I have helped companies get out of similar predicaments that they got into accidently like this that was due to poor FRS replication. Basically what happens is that the changes get applied locally, replicate out through the domain partition, get stomped on by some other DC somewhere else which replicates back out. If you different policies on several DCs you would be entirely in flux and could never guarantee where you would be in terms of settings as it would depend on which DC you last replicated in changes from and whether or not the local policy had recently reapplied. I have seen this for password policies, lockout policies, and restricted groups (this is a hoot if the group is admins or domain admins because you have to time your logon at a point when you have rights). Basically anything that replicates in the directory as well as through FRS. This is fairly easy to catch by looking at version numbers on the domain nc attributes, when you see something that is the hundreds, you may have an issue. Alternatively have a script that watches for changes and you will keep seeing the domain NC popping up as changing. joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darren Mar-EliaSent: Wednesday, February 16, 2005 7:43 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Few quick ones on password polices Actually, this isn't entirely true. A little testing on Win2K3 shows the following: If I have domain account policy defined, say, on the Default Domain Policy, and I set block inheritance on the Domain Controllers OU, then any changes to the domain account policy on that domain-linked GPO will be ignored by DCs located in the DC OU. You can see this by looking at the effective account policy on a given DC by firing up the local GPO editor (gpedit.msc). If you look at account policy on the local GPO of a DC, it shows the current effective policy as delivered by any domain linked GPOs. If you try to change it from the local GPO, you'll noticed its grayed out--and can't be changed. Interestingly, if you set Block Inheritance on the DC OU, not only are changes to domain account policy from that domain-linked GPO ignored, but you can now change the local account policy on a given DC from the local GPO editor. Obviously that isn't too desirable since this would imply to me that you could have a different account policy on each DC. Yuck. Its unclear to me whether AD has any kind of mechanism to prevent this, but I am currently doubting it until I test some more. So bottom line is don't put Block Inheritance on the DC OU or, better yet, always set the GPO where you define domain account policy to Enforced. Darren From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joeSent: Wednesday, February 16, 2005 12:38 PMTo: ActiveDir@mail.activedir.orgSubject: RE: [ActiveDir] Few quick ones on password polices 1. Correct 2. Yes and no. Account policies as applied onto domain users can't be blocked. However you can block those policies from being applied to the local policies of member machines. I don't think you need to set "user can not change password", if the person doesn't want their password changed, setting that only prevents them from doing it. joe From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tim SuttonSent: Wednesday, February 16, 2005 1:05 PMTo: ActiveDir@mail.activedir.orgSubject: [ActiveDir] Few quick ones on password polices Hey all! Can you do me a quick favour and just confirm that I'm not going mad by agreeing (or not, if I'm wrong) with these: 1) you can only apply password policies (account policies to be exact, but this is a bone of contention here at the moment) at the domain level. i.e.: if the domain is abc.com you have to apply it at that level, not below. 2) account policies cannot be blocked by using the "block inheritance" option? Not too sure on this one, so could do with it clearing up. As a fail safe I'm going to make sure I've got "password never expires" and "user can not change password" options selected for those people who I don't want their password changing just yet. Any answers greatly received and advice always welcome. Cheers, folks. For Troup Bywaters + Anders Tim Sutton T: +44 (0) 113 243 2241 F: +44 (0) 113 242 4024 E: [EMAIL PROTECTED] W: www.TBandA.com Eastgate House 10 Eastgate Leeds LS2 7JL Office Location Map Groupshield 6.0 - Troup Bywaters AndersPrivilege and Confidentiality NoticeThis email and any attachments to it are intended only for the party to whom they are addressed. They may contain privileged and / or confidential information. If you have received this transmission in error please notify the sender immediately and delete any digital copies and destroy any paper copies. Thank you.
