tying users to OUs with an attribute

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

We initially planned to have OUs setup for member stores of our company with
store employees setup as users under their corresponding OU. We were
planning naming the OUs by the store number assigned from corporate. However
due to the fact that the stores change store numbers frequently and for other
reasons we have considered putting all users under a separate OU which would
contain users from all stores. We would then have a custom attribute that
would tie a user to a store which would still be an OU. There would be no
users under the store OUs, but the OUs would have attributes custom to the
representative store. We planned to have another attribute to specify which
users is the administrator for that OU, so we would have attributes tying the
users to their OUs.
What disadvantages would we have by not having the users under their
representative store? What issues of delegated administration would we
encounter by using an attribute to tie a user to an OU instead of having the
user under its corrsesponding OU?

Another option we considered was similar but have the individual stores
setup as groups with the needed attributes with the users still under a
single OU using the same idea of tying the users to their OUs with an
attribute.
What disadvantages would we have with this setup?

Any other ideas or suggestions to deal with contantly changing OUs?

Any help would be greatly appreciated.
Thank you in advance,
Leroy
 
What disadvantages would we have by not having the users under their
representative store? What issues of delegated administration would we
encounter by using an attribute to tie a user to an OU instead of having
the user under its corrsesponding OU?
Click to expand...

The best way of delegating is via OU. Without some cool code, I can't see
you being able to delagate by a hidden attribute --unless you do it manually
of course.

Another option we considered was similar but have the individual stores
setup as groups with the needed attributes with the users still under a
single OU using the same idea of tying the users to their OUs with an
attribute. What disadvantages would we have with this setup?
Click to expand...

Again, having all the users in one container and then trying to delegate by
group membership is tough (without lots of labour or code).

Any other ideas or suggestions to deal with contantly changing OUs?
Click to expand...

Yes, use the OU design and simply rename them when the time comes. Or, name
the OU with the name of a location, for example, and set a hidden attribute
as the OU number. businessCategory springs straight to mind.
 
Back
Top