Brad
Wed Jul 14 15:50:55 CDT 2004
Thanks for the links Dave. I appreciate your help.
"Dave Nickason [SBS MVP]" <gwdibble@NOSPAM.frontiernet.net> wrote in message
news:ebmdviSaEHA.4048@TK2MSFTNGP10.phx.gbl...
> I'm pretty much out of ideas at this point - unless you're seeing logged
> errors that point you in a specific direction for troubleshooting, you
> probably need to go through every setting to see if you can figure out
> what's happening (or not happening). Make sure your workstations are in
an
> OU covered by the GP (not sure how they could avoid the domain security
> policy, though), check the permissions, etc.
>
> Using Secedit.exe to Force Group Policy to Be Applied Again
>
http://support.microsoft.com/default.aspx?scid=kb;en-us;227448
>
> Step-by-Step Guide to Understanding the Group Policy Feature Set
>
http://www.microsoft.com/windows2000/techinfo/planning/management/groupsteps.asp
>
>
> "Brad Pears" <donotreply@notreal.com> wrote in message
> news:uZkNeESaEHA.1652@TK2MSFTNGP09.phx.gbl...
> > Somethings wrong in our setup for sure then... I applied a domain
> > policy...
> > After 20 minutes, still was able to modify the local policy on our win2K
> > terminal server. The settings hadn't changed.
> >
> > There must be a configuration issue. It appears as if the domain policy
is
> > not functioning at all...
> >
> > ANy ideas?
> >
> > Thanks,
> >
> > Brad
> >
> > "Dave Nickason [SBS MVP]" <gwdibble@NOSPAM.frontiernet.net> wrote in
> > message
> > news:O$S9PaQaEHA.2812@TK2MSFTNGP11.phx.gbl...
> >> Set it in the domain policy. I set it in the domain controller policy
> > too,
> >> so it'll hopefully lock out anyone experimenting from the Internet
side,
> > or
> >> in the unlikely event that anyone got inappropriate access to the
server
> >> room. But domain policy is where you want it for users connecting over
> > the
> >> network.
> >>
> >> Hopefully if you raise the lockout threshhold to 10 in the domain
> >> security
> >> policy, within a fairly short time you should see that the local
> > workstation
> >> policies are set to 10, greyed out so there's no option to change the
> >> setting.
> >>
> >> I've tried to figure out what can be causing your lockouts, including
> >> reading up on lockout in technet, but haven't been able to find
anything
> >> like what you describe. Lockout can be strange. I have one
workstation
> >> where if I log in with my own userid/password, my account locks out
> >> within
> > a
> >> few minutes - even if I just walk away and leave it sitting idle. I
> > haven't
> >> had time to try figuring it out, so I just log in as Admin when I'm at
> > that
> >> machine (I'm only there for admin tasks anyway).
> >>
> >>
> >> "Brad Pears" <donotreply@notreal.com> wrote in message
> >> news:%23zjROLQaEHA.2056@TK2MSFTNGP12.phx.gbl...
> >> > Ya, I forgot to mention, none of the workstations I checked had a
local
> >> > policy set. Most people connect to the terminal server using older
> >> > win98
> >> > machines anyway ...
> >> >
> >> > Also, I like the idea of just setting a new polciy of 10 or higher
but
> >> > where
> >> > should the policy be set for an SBS machine... "domain policy" or
> > "domain
> >> > controller policy"??? I'm confused on that one...
> >> >
> >> >
> >> > "Dave Nickason [SBS MVP]" <gwdibble@NOSPAM.frontiernet.net> wrote in
> >> > message
> >> > news:%23E34lVPaEHA.3988@tk2msftngp13.phx.gbl...
> >> >> The only place you don't mention checking is the local security
policy
> > on
> >> >> the workstations. When you set a domain policy, it gets applied to
> >> >> the
> >> >> workstations. Then when you remove the domain policy, I'm not sure
> >> >> what's
> >> >> supposed to happen, but it's possible the workstations are still
> > applying
> >> >> the old policy even though you've removed it from the domain
security
> >> >> policy. If that's the case, you should be able to just remove or
> >> >> alter
> >> > the
> >> >> policy in the local security policies on each workstation.
> >> >>
> >> >> Another option might be to set a domain policy with a threshhold of
> > 10 -
> >> > if
> >> >> that gets applied correctly, it should solve your problem. Or, post
a
> >> >> question in the win2k server group (since unfortunately none of us
> >> >> SBS'ers
> >> >> seems to have a workable solution).
> >> >>
> >> >> You don't happen to have a free PSS call available by any chance?
If
> >> >> I
> >> > had
> >> >> users getting locked out frequently over a period of days, I'd have
to
> >> > make
> >> >> the phone call even if I had to pay for it, to keep the users from
> >> >> stoning
> >> >> me.
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> "Brad Pears" <donotreply@notreal.com> wrote in message
> >> >> news:e61YpCDaEHA.2408@tk2msftngp13.phx.gbl...
> >> >> > We have a Windows 2000 Small Business Server and a member Windows
> > 2000
> >> >> > server we are running terminal services in admin mode on.
> >> >> >
> >> >> > For some reason, we are getting account lockout issues. There is
no
> >> >> > account
> >> >> > lockout "domain security policy" configured on the SBS server nor
is
> >> > there
> >> >> > an account lockout configured under "domain controller security
> >> >> > policy".
> >> >> > Also there also isn't an account lockout "local" policy configured
> >> >> > on
> >> > the
> >> >> > Win2K Terminal Server. So, to the best of my knowledge, there
isn't
> > ANY
> >> >> > account lockout policy configured anywhere, yet we are getting a
> >> >> > lockout
> >> >> > after 3 invalid atempts which is way too low of a value and is
> > causing
> >> >> > issues.
> >> >> >
> >> >> > We do have a Group Policy(GP) configured on the terminal server
OU
> >> >> > (organization unit) listed under "active directory users and
groups"
> >> >> > and
> >> > a
> >> >> > GP defined on the lighlevel domain (ourdomain.local) but NEITHER
of
> >> > these
> >> >> > have account lockout configured!
> >> >> >
> >> >> > So, my question is, where the heck is the account lockout coming
> > from?
> >> >> > Could
> >> >> > there be a registry setting that did not get changed?
> >> >> >
> >> >> > Thanks,
> >> >> >
> >> >> > Brad
> >> >> >
> >> >> >
> >> >>
> >> >>
> >> >
> >> >
> >>
> >>
> >
> >
>
>