Active Directory Domain Policy

[CAMC1]

Hi,

We have Active Directory Domain Policy which I want to enforce password
expiration and remembered passwords, and so on.
But I want certain users and or exchange mailboxes be excluded from this
policy.
Instead of forcing domain wide policy, if I create another OU, move all
users to be part of this policy to the new OU, and implement it OU level,
is there anything wrong doing it this way?

IS there a better way to appoach this issue?

Thanks
MC

 

[Fusion Consulting Services, Inc.]

MC,

Policies pertaining to account policies (lockout, expiration, etc.) can
only be applied at the domain level.


Best Regards,
____________________________________

Eric J. Ortiz
Fusion Consulting Services, Inc.
a Microsoft Small Business Specialist
http://www.fcs-ny.com



This posting is provided "AS IS" with no warranties, and confers no
rights.

-----Original Message-----
From: CAMC1 [mailto:[email protected]]
Posted At: Wednesday, November 22, 2006 10:03 AM
Posted To: microsoft.public.win2000.active_directory
Conversation: Active Directory Domain Policy
Subject: Active Directory Domain Policy


Hi,

We have Active Directory Domain Policy which I want to enforce password
expiration and remembered passwords, and so on.
But I want certain users and or exchange mailboxes be excluded from this
policy.
Instead of forcing domain wide policy, if I create another OU, move all
users to be part of this policy to the new OU, and implement it OU
level, is there anything wrong doing it this way?

IS there a better way to appoach this issue?

Thanks
MC

 

[myweb]

Hello CAMC1,

In Windows server architecture its by design, that the password policy only
can set by the default domain policy. You can configure it with OU but it
will not work.

Best regards

myweb
Disclaimer: This posting is provided "AS IS" with no warranties, and confers
no rights.

 

[CAMC1]

well I am sure we are not the only company who has a generic login accunts
that don't need to change passwords every every 40days or 90 days.

How others do it?

If I disable "password expiry" from default domain policy, copy or create a
new policy on OU level, are you saying it won't work?
We have CITRIX OU which has different policy, that restricts how users login
to citrix, seem working fine.
So, only password policy won't work on OU level?
MC

 

[Danny Sanders]

well I am sure we are not the only company who has a generic login accunts

that don't need to change passwords every every 40days or 90 days.

How others do it?

With all the regulations today, you must change those generic accounts
periodically and be able to show that it is done. You would set the
attribute "password never expires" and then you would schedule to change it
manually periodically throughout the year.

The thinking behind this is that if you have sensitive data on your domain
that would require a strong account policy, allowing the administrator to
set up accounts that don't follow that "strong" password policy would amount
to the administrator creating a security hole. Kind of like putting bars and
dead bolts on the front doors and windows but securing the back entrance
with only a screen door and a hook.

If I disable "password expiry" from default domain policy, copy or create
a
new policy on OU level, are you saying it won't work?

It will not work when logging into the domain. It will work when logging in
locally to that computer.

So, only password policy won't work on OU level?

Actually it's the account policy, and they will work when logging in locally
to a computer in that OU.

The requirement to have different password policies is one of MS's best
practices for creating another domain.

hth
DDS

 

[CAMC1]

If I can set individual account password not to expire, and domain policy
doesn't over-ride this settings, then this what I want. If this assumption
is right, this is good enough, as long as I can set those user password
manually, but yet force password change for rest of users.

So, I can change those accounts manually, periodically may be 1-2 times a
year.



Thanks
MC

 

[Danny Sanders]

If I can set individual account password not to expire, and domain policy

doesn't over-ride this settings, then this what I want.

That is exactly what happens when you enable that setting.

If this assumption

is right, this is good enough, as long as I can set those user password
manually, but yet force password change for rest of users.

So, I can change those accounts manually, periodically may be 1-2 times a
year.

Your assumption is correct and generic accounts to be compliant with the
many regulations you need to manually change those passwords on a regular
schedule.

hth
DDS

 

[RBot]

This is completely not relevant, but I need to find somebody who knows
about Active Directory Remote Management. I will post my question
here, and maybe somebody will see it and at least tell me where to go
to find my answer

Explorer to create filters to view certain logs in
saved event log files. Everything works perfectly and I get exactly
the information that I am looking for out of each log; HOWEVER, I have
come to notice that if any changes are made to user or computer
accounts using the Active Directory Remote Management tool, it is not
logged the same as when I make the changes in Active Directory while
logged into the server. (As a matter of fact, I am unable to find any
logs for the changes whatsoever).
Just so you know where I am coming from, here is an example:
Lets say that a new account is created with the name of "TestAccount"
by user "AccountCreator" at 12:30am on 12/25/1955. I can go into Event

Log Explorer, load the event log from the specified date, and apply a
filter to show me all important changes for the day (a filter that I
have setup that filters by Event ID), and get this output:
Event ID 624
User Account Created:
New Account Name: TestAccount
New Domain: TestDomain
New Account ID: TestDomain\TestAccount
Caller User Name: Account Creator
Caller Domain: TestDomain
When I create a new account using Active Directory Remote Management
tool, I don't get an Event ID 624, and all other events that show up at

the time of setup are either unreadable, or do not have anything to do
with a new user account.
My question is, is there another Event ID that replaces Event ID 624
(if so I will need one to replace many others as well that I can
elaborate on in the future), or, is there a way to DISABLE Active
Directory Remote Management on the servers so I know that all new users

or computers in the domain will show up in Event Viewer. (reports are
used to verify that we have paperwork for all new users created, and if

one shows up in Event Viewer that we don't have paperwork for, it is a
problem. This becomes useless if one can bypass Event Viewer by using
Active Directory Remote Management)
Sorry for the long message.
RBOT

 

[Joe Richards [MVP]]

Currently Windows only allows a single domain password policy.

If you set policy on OUs, the policy will apply to the member machines
local to that OU and any IDs that exist on those member machines. Domain
IDs will be unaffected.


--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

 

[Harj]

Hi,

If you have strong programming skills you can create your own password
filter.
There is no "out of the box" solution of multiple password policies
within a domain and believe me you are one of large amounts of
organizations that are realizing this limitation of one password policy
and are scratching their heads figuring out the next step.
Best practice of creating a completely new domain just for this sole
purpose does not cut it for everyone looking for a solution.
There are third party solutions out there that allow you multiple
password policies within a single domain as well as controlling
password age on a per policy bases with no additional hardware
required.

Password Filters

http://msdn.microsoft.com/library/d...y/en-us/secmgmt/security/password_filters.asp

Good luck

Harj Singh
Password Policy done right
www.specopssoft.com

 

[CAMC1]

thanks a lot.
MC

That is exactly what happens when you enable that setting.

If this assumption

Your assumption is correct and generic accounts to be compliant with the
many regulations you need to manually change those passwords on a regular
schedule.

hth
DDS

 

[Joe Richards [MVP]]

There are rumours that we will have a solution next year.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm

 

[Guest]

Why not create an OU in the domain and select to "Block Enheritance" and move
objects into that OU that you don't want effected by the domain policy?
Steve

 

[Joe Richards [MVP]]

Because it won't work.

Domain policy is applied to domain controllers which apply it to the NC
Head object and use it in the domain policy.

--
Joe Richards Microsoft MVP Windows Server Directory Services
Author of O'Reilly Active Directory Third Edition
www.joeware.net


---O'Reilly Active Directory Third Edition now available---

http://www.joeware.net/win/ad3e.htm