Re: OU group policy and how to use ldapsearch to find GPO settings



The account is a domain account.
It is subjected to the Account Policies, including lockout behaviors,
which are in effect for the domain. It does not matter where the
user account object is placed in AD's OU. There is only one set of
Account Policies effective for all domain accounts.
The different settings in the Account Policies section in the GPO
that was linked to the OU would have effect for machine local
account defined on machines placed in that OU.
Notice that Account Policies are in the Computer Policies section,
not the User Policies section. They control the systems behaviors
in how it handles its accounts.

Your ldap query is seeing the settings that are in use for the domain.
It is not reading the settings in the GPO that causes the domain to
have those settings. Similarly you are attempting to read the settings
for these policies within other GPOs. In general, there is no public
information nor API for reading the setting values of the policies in
a GPO (or for writing them for that matter).
You could look at the scripts that install with GPMC for examples,
and see about using the reports capability to generate XML that
you could then parse for those values for arbitrary GPOs. When
you install GPMC you will find a .\scripts subdirectory at the install
point.


"emily1997" <emily1997@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:7E47FBD6-2CF8-46FB-9B7E-F06AAA2B01C3@xxxxxxxxxxxxxxxx
Roger, thanks for helping me.

For the first question, I am not sure you answered my question. Or mabye I
misunderstood. The user I tested with to logon to my unix box is under
ou=test_ou, but I didn't see that the GPO at this OU level been effective
for
this user.

For my second question, what I am really interested in are the values for
the three attributes/settings for a particular group policy:
lockoutDuration
lockOutObservationWindow
lockoutThreshold

I need to find a way to use ldapsearch to find these settins for a
particular GPO. To find the default domain policy settings, I can just
search for the root DN. But for the GPO at ou=test_ou level, I cannot
find
where these three attributes are, or in what object.

Thanks again for your help.

"Roger Abell [MVP]" wrote:

First question:
There is only one set of Account policies that are applied to all
accounts
of the domain. Setting Account policies at an OU level effects those
policy settings for the machine local account of computers in those OUs.

Second question:
Not sure I understand what you are after, or what you mean by
the new group policy. Your ldap search (a little reckless with the
wildcard) is showing your attributes of the domain object you named.
GPOs are stored partly in AD and partly in the filesystem (SYSVOL).

--
Roger Abell
Microsoft MVP (Windows Server : Security)

"emily1997" <emily1997@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:E9C5349C-8DC5-4CA9-92CD-0E3E4C812869@xxxxxxxxxxxxxxxx
Hi, I am from the UNIX world. I have an environment that my HP-UX unix
machine is configured with a Windows 2003 server(single domain). Users
in
ADS can logon to my unix box via pam_kerberos.

If I configure the account lockout policy in the default domain policy,
say:
Account lockout duration: 30 min
Account lockout threshold: 5 invalid logon attempts
Reset accout lockout counter after: 30 min

Then an ADS user try to logon to the unix box with an invalid password
for
5
times, this user's account will be locked out for 30 minutes. I
verified
that this works as expected.

Now, I crated an ou=test_ou, and added a new group policy linked to
this
OU,
and I set the accout lockout policy in this new GPO as following:
Account lockout duration: 3 min
Account lockout threshold: 2 invalid logon attempts
Reset accout lockout counter after: 3 min

then I sould expect that a user under ou=test_ou should be locked out
if
this user entered bad passwd twice in a row at logon time. But it
didn't
work this way. This new group policy some how didn't get applied to
this
user. So does anyone know why it didn't work?

The second question I have is: I can use ldapsearch command to find out
the
settings for the default domain policy. For example, I can do the
following:

./ldapsearch -s base -h HOST -p PORT -D administrator@xxxxxxxx -w
PASSWD -b
"DC=test, DC=com" "objectclass=*"|grep -i lockout
lockoutDuration: -18000000000
lockOutObservationWindow: -18000000000
lockoutThreshold: 5

How can I use ldapsearch command to find out the settings for the new
group
policy?

Thanks in advance for your help.







.



Relevant Pages

  • Re: GPO Settings not applying
    ... Of course is it okay to "Move" the computer's Active Directory account into that newly created OU to which you linked your policy - otherwise the computer wouldn't pick up the policy settings again. ... account lockout policy to lockout 3 failed login attempts. ...
    (microsoft.public.windows.group_policy)
  • Re: GPO Settings not applying
    ... computer settings or in the user settings is being applied. ... account lockout policy to lockout 3 failed login attempts. ... I assume that you want to configure the lockout policy for domain ...
    (microsoft.public.windows.group_policy)
  • Re: Username Vulnerability???
    ... Open Server Manager> highlight the PDC ... Password Policy and Account Lockout Policy are both ...
    (microsoft.public.windows.server.general)
  • Re: OU group policy and how to use ldapsearch to find GPO settings
    ... There is only one set of Account policies that are applied to all accounts ... policy settings for the machine local account of computers in those OUs. ... If I configure the account lockout policy in the default domain policy, ...
    (microsoft.public.windows.group_policy)
  • Re: Replication of password resets/unlocks
    ... Assuming that the reg key AvoidPDCOnWan isn't set passwords will be sent immediately out of band to the PDC when changed on a local machine. ... I haven't dug into the specifics but I believe that occasionally it will check with the PDC to see if the account has been unlocked but not for every auth attempt, this is so a PDC will not be overwhelmed by attempts to auth a locked account. ... The idea behind auto lockout is to prevent brute force systems from sending thousands of passwords an hour to crack a password, if that is the case, then setting the lockout policy to 25 bad attempts and locking the account out for say 5 minutes is just as good from a security perspective; it will seriously impact the ability for a brute force attack. ... From the usability standpoint, it will only lockout users who have really screwed up with their password and give them just enough time to realize they really screwed up but take less time than a call to the helpdesk for an unlock and replication of the unlock meaning that if they call the helpdesk for a rest, the only mechanism that comes into play is the one in the first paragraph above which works fine. ...
    (microsoft.public.windows.server.active_directory)