Group Policy: multiple password policies in the same domain?

[Derick Anderson]

I'm trying to lock down some domain "service" accounts (backup,
Exchange, SQL Server, Scheduled Tasks, etc.) where I work. We're an
application service provider (web-based) and we have only one domain at
the moment (sigh), shared by our production servers (big sigh) on the
same physical network (very big sigh). Our web application must run as a
domain account (throws up hands in exasperation).

Splitting the domain into production and non-production is in the works
but will realistically be at least a couple months away. In the mean
time I'm trying to enforce stronger passwords for service accounts like
those I mentioned above but I'm having problems using Group Policy to
specify that service accounts have a certain password policy while
regular users have another. I believe the problem is that password
policies are computer based instead of user based, so I can't specify
that specific users have one set of password policies while others have
a different one.

Would applying the policy to a specific set of computers affect only the
local accounts on those computers, or the entire domain? My theory is
that only the password policy on the domain controllers would affect
domain passwords, but I'd love to hear differently.

Any help would be appreciated.

Thanks,

Derick Anderson

---------------------------------------------------------------------------
---------------------------------------------------------------------------

[Depp, Dennis M.]

There can be only one password policy for the domain.

Dennis

---------------------------------------------------------------------------
---------------------------------------------------------------------------

[Derick Anderson]

As I feared.

Thanks,

Derick

[Delgado, Jacob M.]

Derick,

Active Directory password policies are set at the domain level. At all
other levels, the policy is just ignored. All domain accounts will have
the same policy applied. If you want different policies for different
users, they have to reside in a different domain.

http://www.microsoft.com/technet/prodtechnol/windowsserver2003/technolog
ies/directory/activedirectory/stepbystep/strngpw.mspx

Jacob Delgado
Network Administrator
University of Northwestern Ohio

------------------------------------------------------------------------
---
------------------------------------------------------------------------
---


---------------------------------------------------------------------------

---------------------------------------------------------------------------

[Beauford, Jason]

Domain Wide Password policies cannot be blocked by OU Policies. With
that in mind you should look at creating an OU and setting up a GPO with
Password Policies there rather than on the top level domain. Drop your
service accounts into the OU and they will take on the the applied GPO.

Because you have no other password policy set on the top level domain
name, your "other" users will be unaffected.

I believe that should do it. But then again. I haven't tested it or
ever implemented it to confirm. Check it out.

JMB

=| -----Original Message-----
=| From: Derick Anderson [mailto:dand...@vikus.com]
=| Sent: Wednesday, August 31, 2005 7:32 AM
=| To: focu...@securityfocus.com
=| Subject: Group Policy: multiple password policies in
=| the same domain?
=|
=| I'm trying to lock down some domain "service"
=| accounts (backup, Exchange, SQL Server, Scheduled
=| Tasks, etc.) where I work. We're an application
=| service provider (web-based) and we have only one
=| domain at the moment (sigh), shared by our production
=| servers (big sigh) on the same physical network (very
=| big sigh). Our web application must run as a domain
=| account (throws up hands in exasperation).
=|
=| Splitting the domain into production and
=| non-production is in the works but will realistically
=| be at least a couple months away. In the mean time
=| I'm trying to enforce stronger passwords for service
=| accounts like those I mentioned above but I'm having
=| problems using Group Policy to specify that service
=| accounts have a certain password policy while regular
=| users have another. I believe the problem is that
=| password policies are computer based instead of user
=| based, so I can't specify that specific users have
=| one set of password policies while others have a
=| different one.
=|
=| Would applying the policy to a specific set of
=| computers affect only the local accounts on those
=| computers, or the entire domain? My theory is that
=| only the password policy on the domain controllers
=| would affect domain passwords, but I'd love to hear
=| differently.
=|
=| Any help would be appreciated.
=|
=| Thanks,
=|
=| Derick Anderson
=|
=| ------------------------------------------------------
---------------------
=| ------------------------------------------------------
---------------------
=|
=|

---------------------------------------------------------------------------
---------------------------------------------------------------------------

[Derick Anderson]

> -----Original Message-----
> From: Richard Whitworth [mailto:Richard....@hsbp.co.uk]
> Sent: Wednesday, August 31, 2005 10:19 AM
> To: Derick Anderson
> Subject: RE: Group Policy: multiple password policies in the
> same domain?
>
> You can only set password policies affecting domain accounts
> using the "default domain policy" GPO - ie. the GPO at the
> top of the AD tree for a particular domain.
>
> As you indentify, setting a GPO that affects computer
> accounts lower down in the AD tree will only affect local accounts.
>
> Richard
>

Does anyone know why the password policy is a computer and not a
user-based setting?

Derick Anderson

---------------------------------------------------------------------------
---------------------------------------------------------------------------

[Derick Anderson]

> -----Original Message-----
> From: Beauford, Jason [mailto:jbea...@EightInOnePet.com]
> Sent: Wednesday, August 31, 2005 10:26 AM
> To: Derick Anderson; focu...@securityfocus.com

> Subject: RE: Group Policy: multiple password policies in the
> same domain?
>

> Domain Wide Password policies cannot be blocked by OU
> Policies. With that in mind you should look at creating an
> OU and setting up a GPO with Password Policies there rather
> than on the top level domain. Drop your service accounts
> into the OU and they will take on the the applied GPO.
>
> Because you have no other password policy set on the top
> level domain name, your "other" users will be unaffected.
>
> I believe that should do it. But then again. I haven't
> tested it or ever implemented it to confirm. Check it out.
>
> JMB

I've tried this and the end result is that the policy is undefined.
Someone else mentioned that it would only affect local accounts (local
security policy overridden by Group Policy). Since domain controllers
have no local accounts, it would make sense (unfortunately for me) that
whatever password policy the domain controllers were given would
determine the domain password policy. The service accounts I want to
harden are domain accounts, not local ones. I can't use local accounts
because some of them must transfer data from one machine to the other.

I've tried using Group Policy modeling with security filtering (i.e.,
apply only to 'service accounts' group), and that is not applied. If I
add 'Domain Computers' to that list then it applies but conflicts with
the domain password policy and nothing is set. I don't understand how
applying it to specific servers will affect domain user accounts but
that is one thing I have yet to try.

Also thanks to those people who've mailed me off-list for your replies.

Derick Anderson

---------------------------------------------------------------------------
---------------------------------------------------------------------------

[Laura A. Robinson]

Password policies for accounts stored in Active Directory can *only* be set
at the domain level. End of story. For *local* accounts, password policies
can be set at the OU level, but again, they affect only local accounts on
the computers within the OU in question.

Laura

> -----Original Message-----
> From: Derick Anderson [mailto:dand...@vikus.com]

> Sent: Wednesday, August 31, 2005 7:32 AM
> To: focu...@securityfocus.com

[Kurt Dillard]

Right now, there can only be 1 password policy for each account
database, so all accounts in the domain will be subject to the domain's
policy. If you define unique policy for OUs those settings will only
affect the local accounts on the servers in scope of that GPO.

Kurt

[Laura A. Robinson]

Inline replies to a couple of different people.

> > You can only set password policies affecting domain
> accounts using the
> > "default domain policy" GPO - ie. the GPO at the top of the AD tree
> > for a particular domain.

Actually, that's not the case. You can only affect domain accounts at the
domain level, but you do NOT have to use the "Default Domain Policy" GPO.
You can create your own and it works. If you have multiple domain-level
policies that specify password settings, the last applied policy at the
domain level will "win". My other post answering the original question got
bounced, but I clarified some of this in it.

> Does anyone know why the password policy is a computer and
> not a user-based setting?

Why would it be a computer setting? That would make no sense for all of the
users in the domain who are people rather than computers. Again, you can
only have a single password policy that affects accounts stored in AD for a
given domain. Because both users and computers are stored in AD, the
password policy applies to *any* account stored in AD.

Laura


---------------------------------------------------------------------------
---------------------------------------------------------------------------

[Laura A. Robinson]

Inline...

> -----Original Message-----
> From: Beauford, Jason [mailto:jbea...@EightInOnePet.com]
>

> Domain Wide Password policies cannot be blocked by OU
> Policies.

It's not a matter of blocking. It's a matter of where the accounts are
actually stored. AD accounts are stored in the *domain*, so that is the only
place where a password policy affects *domain* accounts. OUs are irrelevant
in that scenario.

> With that in mind you should look at creating an
> OU and setting up a GPO with Password Policies there rather
> than on the top level domain. Drop your service accounts
> into the OU and they will take on the the applied GPO.

No, they won't. Moving the service account from one OU to another has no
affect. The account is still stored in AD and is still subject to the
*domain* password policy. Creating *local* accounts on the computer(s) in
question, then setting password policies on the OUs where the *computers*
reside, would work. However, it wouldn't meet the requirements of the
original poster.

>
> Because you have no other password policy set on the top
> level domain name, your "other" users will be unaffected.

That is not the case. See above.

>
> I believe that should do it. But then again. I haven't
> tested it or ever implemented it to confirm. Check it out.

I have tested and implemented this stuff eight ways to Sunday, but I
encourage anybody who doesn't want to take my word for it to test for
himself/herself. :-)

Laura


---------------------------------------------------------------------------
---------------------------------------------------------------------------

[Derick Anderson]

> -----Original Message-----
> From: Laura A. Robinson [mailto:laurar...@earthlink.net]
> Sent: Wednesday, August 31, 2005 3:20 PM
> To: Derick Anderson; focu...@securityfocus.com

> Subject: RE: Group Policy: multiple password policies in the
> same domain?
>

> Inline replies to a couple of different people.
>
> > > You can only set password policies affecting domain
> > accounts using the
> > > "default domain policy" GPO - ie. the GPO at the top of
> the AD tree
> > > for a particular domain.
>
> Actually, that's not the case. You can only affect domain
> accounts at the domain level, but you do NOT have to use the
> "Default Domain Policy" GPO.
> You can create your own and it works. If you have multiple
> domain-level policies that specify password settings, the
> last applied policy at the domain level will "win". My other
> post answering the original question got bounced, but I
> clarified some of this in it.

On my DC, running GPMC, if I do a GPO model with conflicting policies,
the report shows that the policies aren't set at all. Are they actually
set? Doing a RSoP gives me the red X over all conflicting policies. I
wasn't able to hunt down the actual meaning of the red X in the couple
minutes I could spare to investigate, but I figure it's not good. I am
just wondering if the policy is actually set but the reporting/RSoP
features see it as a bad thing and that explains their output.

> > Does anyone know why the password policy is a computer and not a
> > user-based setting?
>
> Why would it be a computer setting? That would make no sense
> for all of the users in the domain who are people rather than
> computers. Again, you can only have a single password policy
> that affects accounts stored in AD for a given domain.
> Because both users and computers are stored in AD, the
> password policy applies to *any* account stored in AD.
>
> Laura

The password settings are in the computer section, not the user section.
I couldn't fathom that idea, so I set up security filtering on the
"Service Accounts" GPO to apply only to "Service Accounts" (a user
group). Group Policy modeling reported back that the GPO was denied
access due to security filtering.

Here's my theory: It's easier to have the password policy computer-based
instead of user-based. When a user authenticates/resets their
password/is created, Windows checks the local computer password policies
against the supplied password. Because it's a computer setting, there is
only one thing to check: the local computer's policy (which is set by
the domain policy on a domain). Since a domain user is like a local user
on a domain controller (sort of), the domain controller policy is the
only one that matters for that user in respect to passwords.

Now let's imagine this was a user setting: I can now apply password
policies to an individual user, group, whatever. I log on to a domain
computer and the domain controller now has to figure out what group I'm
in, what group policy applies to me, and therefore what my password
requirements are. It must do this every time I attempt to authenticate
(ignoring caching, etc.). And what if I'm a member of more than one
group with differing password policies? Which group wins?

I bet Microsoft thought about all that and said "nevermind."

Derick Anderson

---------------------------------------------------------------------------
---------------------------------------------------------------------------

[Brady McClenon]

Why would you ever want different password policies for different
accounts? I don't see the point of only having a portion of your
accounts with strong passwords. If you are going to be serious about
password security, be serious about it. What account is it not
necessary to have a strong password if the others are? I'm just
curious...

-----Original Message-----
From: Derick Anderson [mailto:dand...@vikus.com]

[Derick Anderson]

Why two policies?

I have single domain that contains both end users and mission-critical
service accounts, and our company must be SAS70 type-II certified. So
the auditors come and say, "You must have secure password policies."
This amounts to (in our case) at least 8 character passwords, a maximum
age of 90 days, complexity requirements, a lockout policy of 5 attempts
with infinite lockout, and a 1 day period between failed attempt count
resets. When I first came the minimum length was 7 characters. The day I
upped it to 8 you should have heard all the crying.

I consider 8 characters the bare minimum for a secure account password.
Unfortunately our users cannot fathom security and while I personally
use passphrases that exceed 20 characters I doubt very much that I could
ever get the whole company past 10 and then I'd spend all my mornings
unlocking accounts or resetting forgotten passwords.

The second issue is the lockout policy and password age - if you are
only going to require 8 characters you'd better have some sort of
lockout policy, in my opinion. However, when a mission-critical system
runs as a domain service account, and a developer tries to use that same
account for "debugging" (.NET machine config for the uninitiated) and
uses the wrong password, it locks out the service account and DoSes the
system. Clearly a security risk from an availability standpoint.

So the dilemma is that I need shorter passwords with tighter lockout
policies for users, and longer passwords with no lockout policies for
service accounts, and I have to be able to demonstrate that the password
policy is in effect to the auditors. I can make the service account
passwords as long as I want, but unless it can be proven that this is
the case, we don't pass the audit next time around.

Derick Anderson

[Derick Anderson]

Responses inline.

> -----Original Message-----
> From: Richard Whitworth [mailto:Richard....@hsbp.co.uk]

> Sent: Thursday, September 01, 2005 10:54 AM
> To: Derick Anderson; focu...@securityfocus.com
> Subject: RE: Group Policy: multiple password policies in the
> same domain?
>

> Good point Laura, I'd suspected that you might be able to use
> a different GPO at the same level but having never tested it
> I didn't want to committ it to writing! At least I know now :)
>
> Derick if you've filtered the security of the GPO's to just
> the service accounts then under what user account are you
> running RSoP? it will run under the context you are logged in
> as unless you are running it in planning mode to apply it to
> the account in question. Even then I am not sure that it will
> work properly if you've denied the user account you running
> it under access to the GPO.

I'm running it as Domain Admin. I've run modeling and planning modes
with similar results. The consistent thing is that whenever there's a
conflict with password policy that nothing gets set (red x or blank
settings in the report). The conflict only happens when both policies
can apply to the same computer. Doing a security filter with only users
results in having the policy denied.

> Taking Laura's point into account, whilst the password policy
> is applied at the computer level, it still requires that the
> user accounts it affects be able to read it and have "apply
> group policy" permissions. Presumably then, if you were to
> set up an additional GPO at the top of the AD tree and deny
> all user accounts but the service accounts "apply group
> policy" permissions then the policy would only be applied to
> the service accounts. Similarly you would need to ensure that
> the rest of the user accounts in the domain have "apply group
> policy" permissions denied on the GPO for the service
> accounts, or that it is lower in the list.

And that is what I tried first, to no avail. =) I believe because the
password policy is a computer-based setting it ignores filtering of
users. Again, trying to apply two policies to one computer results in a
clash that according to GPO modeling/planning/RSoP is resolved by not
trying to do anything. I suppose this could be tested by applying one
policy to the DCs only (using security filtering) and the other for
Domain Computers (which is every computer but the DCs). I bet that local
accounts on non-DCs would get the second policy while domain accounts
would get the first, irrespective of where the user logged in.

> As to why the password policy is computer based or user based
> - I think it makes no difference in the context of your
> question - you can only apply a password policy at the top of
> the AD tree and not in a GPO or object beneath it, so if it
> was user based it would make no difference to what you are
> trying to achieve.
>
> My thoughts as to why its computer based - well perhaps its
> related to the fact that it is "the computer" that
> authenticates the login? The account policies on a local
> machine are found in the local security policy msc. on a
> computer - which has no user related settings. A Group Policy
> combines these settings with various other related policies,
> it would make little sense then for password policy to be
> found under the user node of a GPO since user objects have
> nothing to do with authenticating logins.
>
> Richard

I believe that you can apply password policies in other OUs but it will
affect only the local computers in the OU for the very reason you state:
the computer authenticates the login. For a domain account, the "local"
computer is the domain controller, not the machine being logged into. I
think that allowing multiple password policies tied to user groups is
far more complicated than having it tied to a computer, and so that's
why it's a computer setting.

> Disclaimer: This email and any files transmitted with it are
> confidential and intended solely for the use of the
> individual or entity to whom they are addressed.
>
> If you have received this email in error please notify the
> originator of the message. This footer also confirms that
> this email message has been scanned for the presence of
> computer viruses and Henshaws Society for Blind People will
> not accept any responsibility for any loss of data or
> financial loss caused directly or indirectly by opening or
> processing this email and any accompanying attachments.
>
> Any views expressed in this message are those of the
> individual sender, except where the sender specifies and with
> authority, states them to be the views of Henshaws Society
> for Blind People.
>
> Please Note: Recipients of this message should be aware that
> Henshaws Society for Blind People reserves the right to
> monitor all email sent to and from the hsbp.co.uk domain or
> any other domain that may be administered by the said organisation.
>
> Head office telephone number: 0161 872 1234 Head office fax
> number: 0161 848 9889
> website: http://www.hsbp.co.uk
>
>

---------------------------------------------------------------------------
---------------------------------------------------------------------------

[Richard Whitworth]

Good point Laura, I'd suspected that you might be able to use a different GPO at the same level but having never tested it I didn't want to committ it to writing! At least I know now :)

Derick if you've filtered the security of the GPO's to just the service accounts then under what user account are you running RSoP? it will run under the context you are logged in as unless you are running it in planning mode to apply it to the account in question. Even then I am not sure that it will work properly if you've denied the user account you running it under access to the GPO.

Taking Laura's point into account, whilst the password policy is applied at the computer level, it still requires that the user accounts it affects be able to read it and have "apply group policy" permissions. Presumably then, if you were to set up an additional GPO at the top of the AD tree and deny all user accounts but the service accounts "apply group policy" permissions then the policy would only be applied to the service accounts. Similarly you would need to ensure that the rest of the user accounts in the domain have "apply group policy" permissions denied on the GPO for the service accounts, or that it is lower in the list.

As to why the password policy is computer based or user based - I think it makes no difference in the context of your question - you can only apply a password policy at the top of the AD tree and not in a GPO or object beneath it, so if it was user based it would make no difference to what you are trying to achieve.

My thoughts as to why its computer based - well perhaps its related to the fact that it is "the computer" that authenticates the login? The account policies on a local machine are found in the local security policy msc. on a computer - which has no user related settings. A Group Policy combines these settings with various other related policies, it would make little sense then for password policy to be found under the user node of a GPO since user objects have nothing to do with authenticating logins.

Richard

[Derick Anderson]

Inline..

> -----Original Message-----
> From: Derick Anderson [mailto:dand...@vikus.com]
> Sent: Thursday, September 01, 2005 2:32 PM
> To: focu...@securityfocus.com
> Subject: RE: Group Policy: multiple password policies in the
> same domain?
>

> Why two policies?
>
> I have single domain that contains both end users and
> mission-critical service accounts, and our company must be
> SAS70 type-II certified. So the auditors come and say, "You
> must have secure password policies."
> This amounts to (in our case) at least 8 character passwords,
> a maximum age of 90 days, complexity requirements, a lockout
> policy of 5 attempts with infinite lockout, and a 1 day
> period between failed attempt count resets. When I first came
> the minimum length was 7 characters. The day I upped it to 8
> you should have heard all the crying.
>

> [Brady]
> Let them cry. They'll get used to it. We had the same
> issue, but stick to your guns and they'll stop complaining.
> People only complain when they learn it will get them what
> they want. Plus if you are required to have 8 character
> passwords, what can you do about it? It must be that way.
> [End Brady]

The best thing about the SAS70 audit is getting to blame someone else
for doing things right. =) I've had similar issues with developers who
thought they needed full control in the production database. It's always
handy to say, "If we don't we won't pass our audit" when the idea of
role separation doesn't quite get through to them. Also the CIO backs me
up 95% of the time...

My concern is that they'll start writing the passwords down. I've tried
educating them about passphrases (which I use to create 20+ character
passwords for critical accounts) but only a few of them have been able
to make the switch. There seems to be some mental block about how long
the password is, even though passphrases are easier to remember because
of memory chunking.

> I consider 8 characters the bare minimum for a secure account
> password.
> Unfortunately our users cannot fathom security and while I
> personally use passphrases that exceed 20 characters I doubt
> very much that I could ever get the whole company past 10 and
> then I'd spend all my mornings unlocking accounts or
> resetting forgotten passwords.
>
> The second issue is the lockout policy and password age - if
> you are only going to require 8 characters you'd better have
> some sort of lockout policy, in my opinion. However, when a
> mission-critical system runs as a domain service account, and
> a developer tries to use that same account for "debugging"
> (.NET machine config for the uninitiated) and uses the wrong
> password, it locks out the service account and DoSes the
> system. Clearly a security risk from an availability standpoint.
>

> [Brady]
> Why would a developer have access to mission-critical domain
> service account? If he needs access, give him a separate
> account with the same permissions if necessary.
> [End Brady]

The developer didn't have access to the account, but did have access to
try and use it (because we've got one domain). 5 tries later our
production system went down. In fact, the developer didn't even need to
use that account, just thought that he did.

> So the dilemma is that I need shorter passwords with tighter lockout
> policies for users, and longer passwords with no lockout policies for
> service accounts, and I have to be able to demonstrate that
> the password
> policy is in effect to the auditors. I can make the service account
> passwords as long as I want, but unless it can be proven that this is
> the case, we don't pass the audit next time around.
>

> [Brady]
> You don't need shorter passwords. You need to tell your users the
> company is required to have at least 8 character passwords,
> and if they
> don't like, tough, there is nothing you can do about it. And you need
> to not let anyone use your service accounts.
> [End Brady]


When I said "shorter" I meant 8 characters plus. For me, a normal-sized
password is at least 12 completely random characters or 20+ for a
passphrase. Again, with the service accounts, no one can use them but
the password policy allows them to be locked out if people try. I want
the lockout policy for our users, just not the service accounts.

Derick



---------------------------------------------------------------------------
---------------------------------------------------------------------------

[Brady McClenon]

See inline...

-----Original Message-----
From: Derick Anderson [mailto:dand...@vikus.com]
Sent: Thursday, September 01, 2005 2:32 PM
To: focu...@securityfocus.com
Subject: RE: Group Policy: multiple password policies in the same
domain?

Why two policies?

I have single domain that contains both end users and mission-critical
service accounts, and our company must be SAS70 type-II certified. So
the auditors come and say, "You must have secure password policies."
This amounts to (in our case) at least 8 character passwords, a maximum
age of 90 days, complexity requirements, a lockout policy of 5 attempts
with infinite lockout, and a 1 day period between failed attempt count
resets. When I first came the minimum length was 7 characters. The day I
upped it to 8 you should have heard all the crying.

[Brady]
Let them cry. They'll get used to it. We had the same issue, but stick
to your guns and they'll stop complaining. People only complain when
they learn it will get them what they want. Plus if you are required to
have 8 character passwords, what can you do about it? It must be that
way.
[End Brady]

I consider 8 characters the bare minimum for a secure account password.
Unfortunately our users cannot fathom security and while I personally
use passphrases that exceed 20 characters I doubt very much that I could
ever get the whole company past 10 and then I'd spend all my mornings
unlocking accounts or resetting forgotten passwords.

The second issue is the lockout policy and password age - if you are
only going to require 8 characters you'd better have some sort of
lockout policy, in my opinion. However, when a mission-critical system
runs as a domain service account, and a developer tries to use that same
account for "debugging" (.NET machine config for the uninitiated) and
uses the wrong password, it locks out the service account and DoSes the
system. Clearly a security risk from an availability standpoint.

[Brady]
Why would a developer have access to mission-critical domain service
account? If he needs access, give him a separate account with the same
permissions if necessary.
[End Brady]

So the dilemma is that I need shorter passwords with tighter lockout
policies for users, and longer passwords with no lockout policies for
service accounts, and I have to be able to demonstrate that the password
policy is in effect to the auditors. I can make the service account
passwords as long as I want, but unless it can be proven that this is
the case, we don't pass the audit next time around.

[Brady]
You don't need shorter passwords. You need to tell your users the
company is required to have at least 8 character passwords, and if they
don't like, tough, there is nothing you can do about it. And you need
to not let anyone use your service accounts.
[End Brady]

Derick Anderson

> -----Original Message-----
> From: Brady McClenon [mailto:BMcC...@uamail.albany.edu]
> Sent: Thursday, September 01, 2005 10:53 AM

> To: Derick Anderson; focu...@securityfocus.com
> Subject: RE: Group Policy: multiple password policies in the same
> domain?
>

> Why would you ever want different password policies for different
> accounts? I don't see the point of only having a portion of your
> accounts with strong passwords. If you are going to be serious about
> password security, be serious about it. What account is it not
> necessary to have a strong password if the others are? I'm just
> curious...
>
>
>

> -----Original Message-----
> From: Derick Anderson [mailto:dand...@vikus.com]
> Sent: Wednesday, August 31, 2005 3:44 PM
> To: focu...@securityfocus.com
> Subject: RE: Group Policy: multiple password policies in the same
> domain?
>
>
>

> > -----Original Message-----
> > From: Laura A. Robinson [mailto:laurar...@earthlink.net]
> > Sent: Wednesday, August 31, 2005 3:20 PM

> > To: Derick Anderson; focu...@securityfocus.com
> > Subject: RE: Group Policy: multiple password policies in the same
> > domain?
> >

> --------------------------------------------------------------
> ----------
> ---
> --------------------------------------------------------------
> ----------
> ---
>
>

------------------------------------------------------------------------
---
------------------------------------------------------------------------
---


---------------------------------------------------------------------------

---------------------------------------------------------------------------