GPO configuration

Hi,
I am confused on the issue of Domains and security boundries. Can I have
different password policies in the same domain? Couldn't I have one policy
that has a 6 character password requirement and link it to a GPO for the
general user, and then have a 12 character password requirement for admin
group linked through a GPO? Also what happens when you have a GPO like this
with password requirements linked to a site that crosses domains? Does it
just not process or execute properly?
Thanks - Wayner

Advertisements

Within the native operating system there can be only one password/account
policy for "domain" users and this is defined only at the domain level. The
domain controllers apply password policy and they read the policy from the
winning domain level policy that has password policy defined which in a
fresh install would be Domain Security Policy. However any domain linked GPO
could apply the password policy and the GPO at the top of the list has
highest priority. When configuring a password/account policy make sure that
you do not change defined settings to "undefined" to reverse or disable
them. A good example is password complexity. If you want to disable it for
some reason change the domain level policy to disabled and not undefined as
undefined will not disable it.

There are ways to use custom passfilt.dll to have different password
policies for different users/computers in a domain. Writing and installing a
passfilt.dll correctly is not a trivial matter and takes a good programmer
and there are third party applications that can do such. In my opinion it
makes sense to have a strong password/account policy for all domain users
and to train users how to conform to it. Training users to use pass phrases
instead of passwords can help immensely. Instead of remembering T65r)*xn as
a password they could use a favorite phrase such as A spoonful of sugar!
which is a long complex password. Train them to leave the spaces in the
passphrase. For sensitive accounts consider using smart cards and
configuring the user account to require a smart card for logon.

In Windows 2000/2003 domains are NOT security boundaries - forests are. You
can create external or possibly forest trusts [in Windows 2003] to allow
resources to users from a different forest. Remember that admins in the root
forest domain are all powerful in a forest. --- Steve

"Wayne" <> wrote in message
news:...
> Hi,
> I am confused on the issue of Domains and security boundries. Can I have
> different password policies in the same domain? Couldn't I have one policy
> that has a 6 character password requirement and link it to a GPO for the
> general user, and then have a 12 character password requirement for admin
> group linked through a GPO? Also what happens when you have a GPO like
> this
> with password requirements linked to a site that crosses domains? Does it
> just not process or execute properly?
> Thanks - Wayner

Advertisements

I am still confused on this issue. What if I leave the domain
account/password policy undefined and apply different OU account/password
policies? It seems like this should work. Also on the issue of overrides -
does an account/password policy applied at the domain level override OU
level? I thought the lower GPO policies would overwrite the upper levels if
the same setting is configured with different parameters. So in my question
above the undefined policy would override the defined policy? Do
account/password policies always override lower processed GPO policies even
if you do not no override in the GPO? Note - these questions apply to 2000
arena - 70-217.
Thanks

"Steven L Umbach" wrote:
> Within the native operating system there can be only one password/account
> policy for "domain" users and this is defined only at the domain level. The
> domain controllers apply password policy and they read the policy from the
> winning domain level policy that has password policy defined which in a
> fresh install would be Domain Security Policy. However any domain linked GPO
> could apply the password policy and the GPO at the top of the list has
> highest priority. When configuring a password/account policy make sure that
> you do not change defined settings to "undefined" to reverse or disable
> them. A good example is password complexity. If you want to disable it for
> some reason change the domain level policy to disabled and not undefined as
> undefined will not disable it.
>
> There are ways to use custom passfilt.dll to have different password
> policies for different users/computers in a domain. Writing and installing a
> passfilt.dll correctly is not a trivial matter and takes a good programmer
> and there are third party applications that can do such. In my opinion it
> makes sense to have a strong password/account policy for all domain users
> and to train users how to conform to it. Training users to use pass phrases
> instead of passwords can help immensely. Instead of remembering T65r)*xn as
> a password they could use a favorite phrase such as A spoonful of sugar!
> which is a long complex password. Train them to leave the spaces in the
> passphrase. For sensitive accounts consider using smart cards and
> configuring the user account to require a smart card for logon.
>
> In Windows 2000/2003 domains are NOT security boundaries - forests are. You
> can create external or possibly forest trusts [in Windows 2003] to allow
> resources to users from a different forest. Remember that admins in the root
> forest domain are all powerful in a forest. --- Steve
>
>
> "Wayne" <> wrote in message
> news:...
> > Hi,
> > I am confused on the issue of Domains and security boundries. Can I have
> > different password policies in the same domain? Couldn't I have one policy
> > that has a 6 character password requirement and link it to a GPO for the
> > general user, and then have a 12 character password requirement for admin
> > group linked through a GPO? Also what happens when you have a GPO like
> > this
> > with password requirements linked to a site that crosses domains? Does it
> > just not process or execute properly?
> > Thanks - Wayner
>
>
>

There natively is no possible way to override/bypass domain password policy
for domain users. Again, domain controllers read ONLY the domain container
GPO's for password/account policy. If you undefine a password/account policy
setting that means "no change" from current configuration. Password/account
policy is one of the few exceptions to the normal way GP is applied and this
naturally confuses a lot of users. You can use the command " net accounts "
on a domain controller to find out most domain password policy settings
other than complexity. The link below explains also. --- Steve

"Wayne" <> wrote in message
news:...
>I am still confused on this issue. What if I leave the domain
> account/password policy undefined and apply different OU account/password
> policies? It seems like this should work. Also on the issue of
> overrides -
> does an account/password policy applied at the domain level override OU
> level? I thought the lower GPO policies would overwrite the upper levels
> if
> the same setting is configured with different parameters. So in my
> question
> above the undefined policy would override the defined policy? Do
> account/password policies always override lower processed GPO policies
> even
> if you do not no override in the GPO? Note - these questions apply to
> 2000
> arena - 70-217.
> Thanks
>
> "Steven L Umbach" wrote:
>
>> Within the native operating system there can be only one password/account
>> policy for "domain" users and this is defined only at the domain level.
>> The
>> domain controllers apply password policy and they read the policy from
>> the
>> winning domain level policy that has password policy defined which in a
>> fresh install would be Domain Security Policy. However any domain linked
>> GPO
>> could apply the password policy and the GPO at the top of the list has
>> highest priority. When configuring a password/account policy make sure
>> that
>> you do not change defined settings to "undefined" to reverse or disable
>> them. A good example is password complexity. If you want to disable it
>> for
>> some reason change the domain level policy to disabled and not undefined
>> as
>> undefined will not disable it.
>>
>> There are ways to use custom passfilt.dll to have different password
>> policies for different users/computers in a domain. Writing and
>> installing a
>> passfilt.dll correctly is not a trivial matter and takes a good
>> programmer
>> and there are third party applications that can do such. In my opinion
>> it
>> makes sense to have a strong password/account policy for all domain users
>> and to train users how to conform to it. Training users to use pass
>> phrases
>> instead of passwords can help immensely. Instead of remembering T65r)*xn
>> as
>> a password they could use a favorite phrase such as A spoonful of sugar!
>> which is a long complex password. Train them to leave the spaces in the
>> passphrase. For sensitive accounts consider using smart cards and
>> configuring the user account to require a smart card for logon.
>>
>> In Windows 2000/2003 domains are NOT security boundaries - forests are.
>> You
>> can create external or possibly forest trusts [in Windows 2003] to allow
>> resources to users from a different forest. Remember that admins in the
>> root
>> forest domain are all powerful in a forest. --- Steve
>>
>>
>> "Wayne" <> wrote in message
>> news:...
>> > Hi,
>> > I am confused on the issue of Domains and security boundries. Can I
>> > have
>> > different password policies in the same domain? Couldn't I have one
>> > policy
>> > that has a 6 character password requirement and link it to a GPO for
>> > the
>> > general user, and then have a 12 character password requirement for
>> > admin
>> > group linked through a GPO? Also what happens when you have a GPO like
>> > this
>> > with password requirements linked to a site that crosses domains? Does
>> > it
>> > just not process or execute properly?
>> > Thanks - Wayner
>>
>>
>>

"=?Utf-8?B?V2F5bmU=?=" <> prattled
ceaslessly in news::
> I am still confused on this issue. What if I leave the domain
> account/password policy undefined and apply different OU
> account/password policies? It seems like this should work. Also on
> the issue of overrides - does an account/password policy applied at
> the domain level override OU level? I thought the lower GPO policies
> would overwrite the upper levels if the same setting is configured
> with different parameters. So in my question above the undefined
> policy would override the defined policy? Do account/password
> policies always override lower processed GPO policies even if you do
> not no override in the GPO? Note - these questions apply to 2000
> arena - 70-217. Thanks
>

OU Account Policies only affect local SAM accounts for the computer
accounts in that OU. All domain controllers will get their Account
Policies (Password Policies, Account Lockout Policies, and Kerberos
Policies) from the winning domain level policy and nowhere else. Also,
Account Policies are in the computer configuration of group policy and
therefore would affect computers and not users. Active Directory user
accounts will be affected by the policy the domain controllers use which
is always only from the winning domain account policies. Normally, you
would be correct that the policy closer to the object would win, but this
is the exception that proves the rule.

--
Catwalker
aka Pu$$y Feet
BS, MCP, MCSA
MCNGP #43www.mcngp.com
faq.mcngp.com
"If man could be crossed with the cat, it would improve man, but it would
deteriorate the cat." Mark Twain

"Steven L Umbach" wrote:
> There natively is no possible way to override/bypass domain password policy
> for domain users. Again, domain controllers read ONLY the domain container
> GPO's for password/account policy. If you undefine a password/account policy
> setting that means "no change" from current configuration. Password/account
> policy is one of the few exceptions to the normal way GP is applied and this
> naturally confuses a lot of users. You can use the command " net accounts "
> on a domain controller to find out most domain password policy settings
> other than complexity. The link below explains also. --- Steve
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;255550
>
> "Wayne" <> wrote in message
> news:...
> >I am still confused on this issue. What if I leave the domain
> > account/password policy undefined and apply different OU account/password
> > policies? It seems like this should work. Also on the issue of
> > overrides -
> > does an account/password policy applied at the domain level override OU
> > level? I thought the lower GPO policies would overwrite the upper levels
> > if
> > the same setting is configured with different parameters. So in my
> > question
> > above the undefined policy would override the defined policy? Do
> > account/password policies always override lower processed GPO policies
> > even
> > if you do not no override in the GPO? Note - these questions apply to
> > 2000
> > arena - 70-217.
> > Thanks
> >
> > "Steven L Umbach" wrote:
> >
> >> Within the native operating system there can be only one password/account
> >> policy for "domain" users and this is defined only at the domain level.
> >> The
> >> domain controllers apply password policy and they read the policy from
> >> the
> >> winning domain level policy that has password policy defined which in a
> >> fresh install would be Domain Security Policy. However any domain linked
> >> GPO
> >> could apply the password policy and the GPO at the top of the list has
> >> highest priority. When configuring a password/account policy make sure
> >> that
> >> you do not change defined settings to "undefined" to reverse or disable
> >> them. A good example is password complexity. If you want to disable it
> >> for
> >> some reason change the domain level policy to disabled and not undefined
> >> as
> >> undefined will not disable it.
> >>
> >> There are ways to use custom passfilt.dll to have different password
> >> policies for different users/computers in a domain. Writing and
> >> installing a
> >> passfilt.dll correctly is not a trivial matter and takes a good
> >> programmer
> >> and there are third party applications that can do such. In my opinion
> >> it
> >> makes sense to have a strong password/account policy for all domain users
> >> and to train users how to conform to it. Training users to use pass
> >> phrases
> >> instead of passwords can help immensely. Instead of remembering T65r)*xn
> >> as
> >> a password they could use a favorite phrase such as A spoonful of sugar!
> >> which is a long complex password. Train them to leave the spaces in the
> >> passphrase. For sensitive accounts consider using smart cards and
> >> configuring the user account to require a smart card for logon.
> >>
> >> In Windows 2000/2003 domains are NOT security boundaries - forests are.
> >> You
> >> can create external or possibly forest trusts [in Windows 2003] to allow
> >> resources to users from a different forest. Remember that admins in the
> >> root
> >> forest domain are all powerful in a forest. --- Steve
> >>
> >>
> >> "Wayne" <> wrote in message
> >> news:...
> >> > Hi,
> >> > I am confused on the issue of Domains and security boundries. Can I
> >> > have
> >> > different password policies in the same domain? Couldn't I have one
> >> > policy
> >> > that has a 6 character password requirement and link it to a GPO for
> >> > the
> >> > general user, and then have a 12 character password requirement for
> >> > admin
> >> > group linked through a GPO? Also what happens when you have a GPO like
> >> > this
> >> > with password requirements linked to a site that crosses domains? Does
> >> > it
> >> > just not process or execute properly?
> >> > Thanks - Wayner
> >>
> >>
> >>
>
>
>

Another question - Does the default domain controller policy effect all
domain controllers or the one on which modifications are made?

"Steven L Umbach" wrote:
> There natively is no possible way to override/bypass domain password policy
> for domain users. Again, domain controllers read ONLY the domain container
> GPO's for password/account policy. If you undefine a password/account policy
> setting that means "no change" from current configuration. Password/account
> policy is one of the few exceptions to the normal way GP is applied and this
> naturally confuses a lot of users. You can use the command " net accounts "
> on a domain controller to find out most domain password policy settings
> other than complexity. The link below explains also. --- Steve
>
> http://support.microsoft.com/default.aspx?scid=kb;en-us;255550
>
> "Wayne" <> wrote in message
> news:...
> >I am still confused on this issue. What if I leave the domain
> > account/password policy undefined and apply different OU account/password
> > policies? It seems like this should work. Also on the issue of
> > overrides -
> > does an account/password policy applied at the domain level override OU
> > level? I thought the lower GPO policies would overwrite the upper levels
> > if
> > the same setting is configured with different parameters. So in my
> > question
> > above the undefined policy would override the defined policy? Do
> > account/password policies always override lower processed GPO policies
> > even
> > if you do not no override in the GPO? Note - these questions apply to
> > 2000
> > arena - 70-217.
> > Thanks
> >
> > "Steven L Umbach" wrote:
> >
> >> Within the native operating system there can be only one password/account
> >> policy for "domain" users and this is defined only at the domain level.
> >> The
> >> domain controllers apply password policy and they read the policy from
> >> the
> >> winning domain level policy that has password policy defined which in a
> >> fresh install would be Domain Security Policy. However any domain linked
> >> GPO
> >> could apply the password policy and the GPO at the top of the list has
> >> highest priority. When configuring a password/account policy make sure
> >> that
> >> you do not change defined settings to "undefined" to reverse or disable
> >> them. A good example is password complexity. If you want to disable it
> >> for
> >> some reason change the domain level policy to disabled and not undefined
> >> as
> >> undefined will not disable it.
> >>
> >> There are ways to use custom passfilt.dll to have different password
> >> policies for different users/computers in a domain. Writing and
> >> installing a
> >> passfilt.dll correctly is not a trivial matter and takes a good
> >> programmer
> >> and there are third party applications that can do such. In my opinion
> >> it
> >> makes sense to have a strong password/account policy for all domain users
> >> and to train users how to conform to it. Training users to use pass
> >> phrases
> >> instead of passwords can help immensely. Instead of remembering T65r)*xn
> >> as
> >> a password they could use a favorite phrase such as A spoonful of sugar!
> >> which is a long complex password. Train them to leave the spaces in the
> >> passphrase. For sensitive accounts consider using smart cards and
> >> configuring the user account to require a smart card for logon.
> >>
> >> In Windows 2000/2003 domains are NOT security boundaries - forests are.
> >> You
> >> can create external or possibly forest trusts [in Windows 2003] to allow
> >> resources to users from a different forest. Remember that admins in the
> >> root
> >> forest domain are all powerful in a forest. --- Steve
> >>
> >>
> >> "Wayne" <> wrote in message
> >> news:...
> >> > Hi,
> >> > I am confused on the issue of Domains and security boundries. Can I
> >> > have
> >> > different password policies in the same domain? Couldn't I have one
> >> > policy
> >> > that has a 6 character password requirement and link it to a GPO for
> >> > the
> >> > general user, and then have a 12 character password requirement for
> >> > admin
> >> > group linked through a GPO? Also what happens when you have a GPO like
> >> > this
> >> > with password requirements linked to a site that crosses domains? Does
> >> > it
> >> > just not process or execute properly?
> >> > Thanks - Wayner
> >>
> >>
> >>
>
>
>

It configures any computer in the domain controllers container which by
default would only be domain controllers. Because of such it is also a good
idea to never move a domain controller out of the domain controller
container which actually is an OU. You can however configure child OU's in
the domain controller container if you have special needs to apply different
policy [other than password/account policy] to groups of domain
controllers. Say you have one domain controller that you want regular users
to logon to which normally is not good practice but I have heard of some
configuring a domain controller to be a Terminal Server. Often peoples
budgets outweigh certain security concerns but that is the real world.. ---
Steve

"Wayne" <> wrote in message
news:...
> Another question - Does the default domain controller policy effect all
> domain controllers or the one on which modifications are made?
>
> "Steven L Umbach" wrote:
>
>> There natively is no possible way to override/bypass domain password
>> policy
>> for domain users. Again, domain controllers read ONLY the domain
>> container
>> GPO's for password/account policy. If you undefine a password/account
>> policy
>> setting that means "no change" from current configuration.
>> Password/account
>> policy is one of the few exceptions to the normal way GP is applied and
>> this
>> naturally confuses a lot of users. You can use the command " net
>> accounts "
>> on a domain controller to find out most domain password policy settings
>> other than complexity. The link below explains also. --- Steve
>>
>> http://support.microsoft.com/default.aspx?scid=kb;en-us;255550
>>
>> "Wayne" <> wrote in message
>> news:...
>> >I am still confused on this issue. What if I leave the domain
>> > account/password policy undefined and apply different OU
>> > account/password
>> > policies? It seems like this should work. Also on the issue of
>> > overrides -
>> > does an account/password policy applied at the domain level override OU
>> > level? I thought the lower GPO policies would overwrite the upper
>> > levels
>> > if
>> > the same setting is configured with different parameters. So in my
>> > question
>> > above the undefined policy would override the defined policy? Do
>> > account/password policies always override lower processed GPO policies
>> > even
>> > if you do not no override in the GPO? Note - these questions apply to
>> > 2000
>> > arena - 70-217.
>> > Thanks
>> >
>> > "Steven L Umbach" wrote:
>> >
>> >> Within the native operating system there can be only one
>> >> password/account
>> >> policy for "domain" users and this is defined only at the domain
>> >> level.
>> >> The
>> >> domain controllers apply password policy and they read the policy from
>> >> the
>> >> winning domain level policy that has password policy defined which in
>> >> a
>> >> fresh install would be Domain Security Policy. However any domain
>> >> linked
>> >> GPO
>> >> could apply the password policy and the GPO at the top of the list has
>> >> highest priority. When configuring a password/account policy make sure
>> >> that
>> >> you do not change defined settings to "undefined" to reverse or
>> >> disable
>> >> them. A good example is password complexity. If you want to disable it
>> >> for
>> >> some reason change the domain level policy to disabled and not
>> >> undefined
>> >> as
>> >> undefined will not disable it.
>> >>
>> >> There are ways to use custom passfilt.dll to have different password
>> >> policies for different users/computers in a domain. Writing and
>> >> installing a
>> >> passfilt.dll correctly is not a trivial matter and takes a good
>> >> programmer
>> >> and there are third party applications that can do such. In my
>> >> opinion
>> >> it
>> >> makes sense to have a strong password/account policy for all domain
>> >> users
>> >> and to train users how to conform to it. Training users to use pass
>> >> phrases
>> >> instead of passwords can help immensely. Instead of remembering
>> >> T65r)*xn
>> >> as
>> >> a password they could use a favorite phrase such as A spoonful of
>> >> sugar!
>> >> which is a long complex password. Train them to leave the spaces in
>> >> the
>> >> passphrase. For sensitive accounts consider using smart cards and
>> >> configuring the user account to require a smart card for logon.
>> >>
>> >> In Windows 2000/2003 domains are NOT security boundaries - forests
>> >> are.
>> >> You
>> >> can create external or possibly forest trusts [in Windows 2003] to
>> >> allow
>> >> resources to users from a different forest. Remember that admins in
>> >> the
>> >> root
>> >> forest domain are all powerful in a forest. --- Steve
>> >>
>> >>
>> >> "Wayne" <> wrote in message
>> >> news:...
>> >> > Hi,
>> >> > I am confused on the issue of Domains and security boundries. Can I
>> >> > have
>> >> > different password policies in the same domain? Couldn't I have one
>> >> > policy
>> >> > that has a 6 character password requirement and link it to a GPO for
>> >> > the
>> >> > general user, and then have a 12 character password requirement for
>> >> > admin
>> >> > group linked through a GPO? Also what happens when you have a GPO
>> >> > like
>> >> > this
>> >> > with password requirements linked to a site that crosses domains?
>> >> > Does
>> >> > it
>> >> > just not process or execute properly?
>> >> > Thanks - Wayner
>> >>
>> >>
>> >>
>>
>>
>>

In article <Xns968A8033A4C81catwalker63athotmail@216.196.97.136>, says...
> "=?Utf-8?B?V2F5bmU=?=" <> prattled
> ceaslessly in news::
>
> > I am still confused on this issue. What if I leave the domain
> > account/password policy undefined and apply different OU
> > account/password policies? It seems like this should work. Also on
> > the issue of overrides - does an account/password policy applied at
> > the domain level override OU level? I thought the lower GPO policies
> > would overwrite the upper levels if the same setting is configured
> > with different parameters. So in my question above the undefined
> > policy would override the defined policy? Do account/password
> > policies always override lower processed GPO policies even if you do
> > not no override in the GPO? Note - these questions apply to 2000
> > arena - 70-217. Thanks
> >
>
> OU Account Policies only affect local SAM accounts for the computer
> accounts in that OU. All domain controllers will get their Account
> Policies (Password Policies, Account Lockout Policies, and Kerberos
> Policies) from the winning domain level policy and nowhere else.

Not quite - the effective settings applied for Account policies are
resolved like they are for any other GPO setting - not at the policy
level, hence there is no "winning policy" per se.
> Also,
> Account Policies are in the computer configuration of group policy and
> therefore would affect computers and not users. Active Directory user
> accounts will be affected by the policy the domain controllers use which
> is always only from the winning domain account policies. Normally, you
> would be correct that the policy closer to the object would win, but this
> is the exception that proves the rule.
>
>

Password policies apply only at the domain level. So, if you link GPO
containing password policies in any other place than at Domain (site or
OU).... It will not apply !!!

If you have to configure 2 or more Password policies, ou have to setup 2 or
more domain !

Hugo

"Wayne" <> a écrit dans le message de news:...
> Hi,
> I am confused on the issue of Domains and security boundries. Can I have
> different password policies in the same domain? Couldn't I have one policy
> that has a 6 character password requirement and link it to a GPO for the
> general user, and then have a 12 character password requirement for admin
> group linked through a GPO? Also what happens when you have a GPO like
> this
> with password requirements linked to a site that crosses domains? Does it
> just not process or execute properly?
> Thanks - Wayner

You cannot set password policies at any other level in Active Directory.
Not at the OU Level, not at the site level. No exceptions.

All domain controllers in the domain replicate the same group policy, so the
password policy set on any domain controller replicates to all the others,
so again: Only one password policy per domain.

Jesse Wimberley
A+, Net+, iNet+, Security+, MCP+I, MCDST, MCSA:Security, MCSE:Security, MCT
"Wayne" <> wrote in message
news:...
> Hi,
> I am confused on the issue of Domains and security boundries. Can I have
> different password policies in the same domain? Couldn't I have one policy
> that has a 6 character password requirement and link it to a GPO for the
> general user, and then have a 12 character password requirement for admin
> group linked through a GPO? Also what happens when you have a GPO like
> this
> with password requirements linked to a site that crosses domains? Does it
> just not process or execute properly?
> Thanks - Wayner

In article <#>, says...
> The anser is no.
>
> There is only one password policy per domain, mixed or native.
>
> You cannot set password policies at any other level in Active Directory.
> Not at the OU Level, not at the site level. No exceptions.

You can create one - it will apply to local accounts on the computers
within the site or OU not the domain account.
> All domain controllers in the domain replicate the same group policy, so the
> password policy set on any domain controller replicates to all the others,
> so again: Only one password policy per domain.

This is not the technical reason why there is only one password policy
per domain.
> Jesse Wimberley
> A+, Net+, iNet+, Security+, MCP+I, MCDST, MCSA:Security, MCSE:Security, MCT
> "Wayne" <> wrote in message
> news:...
> > Hi,
> > I am confused on the issue of Domains and security boundries. Can I have
> > different password policies in the same domain? Couldn't I have one policy
> > that has a 6 character password requirement and link it to a GPO for the
> > general user, and then have a 12 character password requirement for admin
> > group linked through a GPO? Also what happens when you have a GPO like
> > this
> > with password requirements linked to a site that crosses domains? Does it
> > just not process or execute properly?
> > Thanks - Wayner
>
>
>

Share This Page

Welcome to Velocity Reviews!

Welcome to the Velocity Reviews, the place to come for the latest tech news and reviews.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to chat with other enthusiasts and get tech help from other members.
Sign up now!