?
Solved

Active Directory + OU's.

Posted on 2006-06-19
19
Medium Priority
?
875 Views
Last Modified: 2012-06-21
Ok guys, this may be a simplistic one but its bugging me.

Basically, I have a domain policy and I am aware that any changes that apply to this domain policy will apply to all usernames.
So a password policy would reside here.

However, I need to apply policy rules to ALL users but NOT server logins.
Applying any settings at the domain level will affect server logins too.

So, I thought of this and just wondering if it would work.
Firstly, each department has an OU. (Marketing, Finance, Developers, etc.. etc...)
Could I put all the company users in an OU called, <COMPANY NAME USERS> for example... and keep the servers out of this OU.
If for example I want to apply a setting to ALL users but NOT servers, all I have to do is apply the setting to the <COMPANY NAME USERS> OU.

Its just I have so many OU's, Each OU has its personal settings and some personal settings need to go accross the board.
The server logins need to be supressed from any USER change. I dont want to affect these logins at all.


A fine example would be:
Finance needs to access the CD-ROM. (This would be in the Finanace OU)
Support doesnt need to access the CD-ROM. (This would recide in the Support OU)
However both groups need to have personalised menus. (This would be the newly created COMPANY NAME USERS> OU which contains them both.


Thanks guys!

0
Comment
Question by:dqnet
  • 11
  • 7
19 Comments
 
LVL 6

Expert Comment

by:Azhrei1
ID: 16933462
would work :)

domain root - server OU
                  - user OU  -usergroup1
0
 
LVL 6

Expert Comment

by:Azhrei1
ID: 16933477
and many more groups under user OU (which you're calling company name users).

0
 
LVL 6

Accepted Solution

by:
Azhrei1 earned 600 total points
ID: 16933482
in fact, you answered your own question! hehe
0
Transaction-level recovery for Oracle database

Veeam Explore for Oracle delivers low RTOs and RPOs with agentless transaction log backup and transaction-level recovery of Oracle databases. You can restore the database to a precise point in time, even to a specific transaction.

 

Author Comment

by:dqnet
ID: 16933545
Hahaha :) excellent.

BUT... Here is the catch... :(

When I come to move these OU's into a new single OU, I get this error.
Moving objects in Active Directory can prevent your existing system from working the way it was designed. For example, moving an organizational unit (OU) can affect the way that group policies are applied to the accounts within the OU Are you sure you want to move this object?

Standard YES, NO answer.

That’s when I use drag drop.
If I right click on an OU and click: All Tasks --> MOVE it doesn’t say anything and moves it.


What you think? Safe or dodgy? One errors, one doesn’t.
0
 
LVL 6

Expert Comment

by:Azhrei1
ID: 16933566
odd it doesn't give the same error on the 2nd way, since it's exactly the same :O

it's not an error tho...just a warning, saying you're changing the way group policies apply to the containers, which is true, because you're moving them, but the change is one you want :) so, no problems
0
 

Author Comment

by:dqnet
ID: 16933599
So updating the default domain policy will still propgate through the OU'sinto the other OU's.

For example...

Default domain policy --> Users OU (ive named it that) --> Support
                                                                               --> Finanace
                                                                               --> Marketing


Like I can still make Entire company changes through the defualt domain policy to affect servers and user logins and EACH individual OU in the users login OU???
0
 
LVL 6

Expert Comment

by:Azhrei1
ID: 16933604
yes :D

unless you specifically set an OU to not inherit from it's parents (default is what you said).

0
 

Author Comment

by:dqnet
ID: 16933654
Ahh... As far as I am aware you cannot set ANY OU to not inherit from the defualt domain policy.
ALL OU's must inherit from the default domain.

I asked that in one of my previous posts... unless i've misundersood here?? :/

so...

Default domain policy --> Users OU (ive named it that) --> Support (MUST INHERITE everything from DEFUALT DOMAIN POLICY)
                                                                               --> Finanace (MUST INHERITE everything from DEFUALT DOMAIN POLICY)
                                                                               --> Marketing (MUST INHERITE everything from DEFUALT DOMAIN POLICY)

                               --> Servers OU (MUST INHERITE everything from DEFUALT DOMAIN POLICY)


Something about no way to stop inheritance at that level, but there is a way to stop it at OU level? so OU to OU is ok, but not Domain to OU ???  
0
 
LVL 6

Expert Comment

by:Azhrei1
ID: 16933688
support inherits from users ou and default domain policy, same with all the others.

far as I know, even the default domain policy can be blocked by turning off policy inheritance, but this I have never needed/tried, so not 100% sure. it's not something you seem to need though :) (far as I could read from your first post).

0
 

Author Comment

by:dqnet
ID: 16933988
True, Dont really need it.. but.. I'm gonna post another question to find out. After all, I could have kep all OU's in the root and blocked inheritance on the server OU...

What you think?
0
 
LVL 6

Expert Comment

by:Azhrei1
ID: 16933998
if you did, you couldn't do company wide policies :) You can only say inherit: yes or no, not which specific policy
0
 

Author Comment

by:dqnet
ID: 16934029
Not quite sure I understand.. could you explain?
(Excuse the ignorance).

Points rasied to 200.
0
 
LVL 6

Expert Comment

by:Azhrei1
ID: 16934098
well, what you're doing now is creating a container to hold all your other containers (subcontainers, company user groups).

On this container, you can apply a group policy. This policy would then apply to all subcontainers. Therefore, you don't need to use the default domain policy to apply a policy to all divisions in your company. On an OU you can choose if it inherits the policies above it, or doesn't. If it inherits, it merges any policies that already apply to it, with those from it's parent.

Say, your grandfather says you can eat apples, but can't eat pears.
Then your father says you can eat pears.

Result: you can eat both. You, and your brothers and sisters are the company divisions. Your father is the OU you made for them, and the grandfather is the default domain policy.

hope this clarifies :S
0
 
LVL 6

Expert Comment

by:Azhrei1
ID: 16934106
oh and for stopping inheritance, if you say block inheritance on the policy that applies to you, then what your father and grandfather say doesn't matter anymore, because you block their policies :)

0
 
LVL 9

Assisted Solution

by:dooleydog
dooleydog earned 200 total points
ID: 16934515
you can use the computers OU, or build your own, place all of hte computers there. All DCs will be in hte Domain Controllers OU so they will not be affected.

you can do the same with your users, but you cannot use the users Container, as it is not an OU and you cannot link a GPO directly to it.

More complicated, and not necessarily better, is security group filtering.

http://technet2.microsoft.com/WindowsServer/en/Library/a2ae66ed-2bd0-47e3-9a77-6677af514b171033.mspx?mfr=true

Good Luck,
0
 

Author Comment

by:dqnet
ID: 16934678
I know for sure now, you CAN block policy inheritance on OU's even when they are assigned at domain level providing they are NOT part of the default domain policy. I have yet to try and see if you can block inheritance if modifying the default domain policy.
Now I have two choices, applying company wide policies using anything but the default (creating one at domain level) and blocking them at the servers OU.
Or, like I've already done by creating a container and putting all the OU's in it, then applying policies based on a specific containers avoiding using the new domain policy. I will only use the domain policy for serious company wide changes that need to affect ALL machines including server logins.
I am certainly going to look at security group filtering to see how that may work.

Is the way I approaced it correct / best practise?
1. Container with sub containers (OU's) for users/departments.
2. Server logins in a seperate OU in the root.
and a password policy set in the root domain but NOT under the default domain policy. (keeping that untouched and unused- also u can block inheritance on these)
0
 
LVL 6

Expert Comment

by:Azhrei1
ID: 16934707
yes, perfectly done :) exactly as I made it at my company (250 workplaces)
0
 
LVL 6

Expert Comment

by:Azhrei1
ID: 16934785
and as described above, you can use security groups, put them in specific containers, and apply policies to those. This way you can do 2 policies on 1 user. I'd recommend experimenting a bit first :P
0
 

Author Comment

by:dqnet
ID: 16934931
Star Man!!! :)
Points assigned as I best I thought..!

Thanks folks!! Much appreciated.
0

Featured Post

Free Tool: Subnet Calculator

The subnet calculator helps you design networks by taking an IP address and network mask and returning information such as network, broadcast address, and host range.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

I guess it is not common knowledge to most Wintel engineers/administrators: If you have an SNMP-based monitoring system in your environment (and it's common to have SNMP or Syslog) it's reasonably easy to enable monitoring of the Windows Event logs,…
ADCs have gained traction within the last decade, largely due to increased demand for legacy load balancing appliances to handle more advanced application delivery requirements and improve application performance.
Integration Management Part 2
Loops Section Overview

850 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question