Re: ADAM schema design
- From: Amol <amol4321@xxxxxxxxx>
- Date: Sun, 23 Sep 2007 17:39:12 -0000
Cool!!! Thanks guyz. This really helps. Do you by any chance have any
references of such large scale ADAM implementation?
Anyways we shall be starting PoC soon... and will keep you posted on
the findings.
Thanks again.
Amol
On Sep 22, 1:32 pm, "Dmitri Gavrilov [MSFT]"
<dmit...@xxxxxxxxxxxxxxxxxxxx> wrote:
It should work just fine, as long as you avoid reading the complete group
membership.
To verify whether a user is a member of a group, you should read its
memberOf.
To add a user to a group, modify the group member attribute, adding user DN.
That should be fast.
To remove a user from a group, modify the group member attribute, removing
user DN. That should be fast too.
Do *not* attempt to load the complete group membership, remove one value,
and do a "replace" operation on the member attribute. That will not scale.
--
Dmitri Gavrilov
SDE, Active Directory team
This posting is provided "AS IS" with no warranties, and confers no rights.
Use of included script samples are subject to the terms specified athttp://www.microsoft.com/info/cpyright.htm
"Joe Kaplan" <joseph.e.kap...@xxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:exLn4SG$HHA.3548@xxxxxxxxxxxxxxxxxxxxxxx
First, let me explain range retrieval.
In AD or ADAM, the directory service will limit the number of attribute
values returned by default in a multivalued attribute. If a multivalued
attribute has more than 1500 values, the DS will only return the first
1500. Thus, if you had a group with a member attribute that contains 200K
values and did a base search on the object to read the member attribute,
you won't get a member attribute with 200K values, you'll get the first
1500 by default. If you want to get the rest, there is a special syntax
for the attribute name used to request "ranges" of the value. It looks
like "member;x-y" or "member;x-*" where X is the start range and y is the
end. You can specify * for the end range value as well and the maximum
number of values allowed by the policy will be returned.
As such, you may need to do many many searches to read the group
membership of a group that contains a lot of values.
Regarding your questions on performance, I have no idea how the directory
will perform if you are talking about putting millions of objects in a
group. My understanding is that there is no actual limit to the number of
values allowed in a linked attribute anymore (there uses to be, but now
there isn't). However, from a practical standpoint I've never heard of
anyone scaling group membership this big. I highly recommend you set up
some real world tests where you try it out and see.
Theoretically, memberOf should continue to perform just fine. If
individual objects are not members of thousands of groups, then you won't
have to worry about range retrieval for them. If you aren't worried about
nesting, then memberOf will work just fine by itself.
As to whether operations like Compare and modify operations like Add and
Delete will perform ok with millions of attribute values, I have no idea.
I have a feeling like you won't like the results (the reason I recommended
considering a query-based approach for group membership if possible), but
I've never heard of anyone actually doing this so I really don't know what
to expect either way.
Good luck!
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"
http://www.directoryprogramming.net
--
"Amol" <amol4...@xxxxxxxxx> wrote in message
news:1190351786.636228.145580@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Thanks for your response... but on your last point of using range
retrival techniques for groups with 1500+ users - I'm not sure I quite
followed you, so pls bear with me here -
As I mentioned earlier, I can understand the impact while trying to
retrieve the list members of this large group or lookup within a grp.
but -
1. Do you think having large # of users in a group may affect the real-
time appl calls for user's group membership info? based on the
memberOf attr of user obj.
2. So do you think that during the administrative fucntions like
assign grp membership (add user to group as member) would get the
performance hit?
Thanks,
Amol
On Sep 20, 11:27 pm, "Joe Kaplan"
<joseph.e.kap...@xxxxxxxxxxxxxxxxxxxxxxxx> wrote:
I've never played with groupOfNames, but I thought I'd point out that
ADAM
groups are not Windows security principals and have no effect on Windows
security at all. They are security principals in ADAM only (so they can
be
used in ADAM ACLs and it will understand them).
One possible advantage of using group instead of groupOfNames is that
you
might be able to get nested group membership via tokenGroups. I'm not
sure
if groupOfNames supports that. If group membership will be nested, that
is
a handy convenience feature as you would not have to recursively expand
through memberOf (ADAM will basically do it for you).
I'm not sure if putting millions of users in a group will work. I've
never
heard of anyone trying to do that at that scale. I think you might be
better off building some sort of query-based group management function
where
you set attributes on the user to indicate their group memberships and
determine membership dynamically (like the feature provided by the MS
AzMan
framework). However, you could certainly try it and see.
Note that if you have more than 1500 members in a group, you'll need to
use
range retrieval techniques to expand the membership (reading member on
the
group object) if you ever need to do that.
Best of luck!
Joe K.
--
Joe Kaplan-MS MVP Directory Services Programming
Co-author of "The .NET Developer's Guide to Directory Services
Programming"http://www.directoryprogramming.net
--<amol4...@xxxxxxxxx> wrote in message
news:1190301118.076596.311360@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
I'm really impressed to see the discussions on group / groupOfNames /
groupOfUniqueNames on this forum.
This is my first post in here and would really appretiate if you could
respond to it with your guidance.
We need to use ADAM as the WMM store for WebSphere Portal Server 6.0
which would essentially use ADAM for user authorization based on the
group memberships. we have decided to use "groupOfNames" as we purely
want to use these objects as application/functional groups and not
windows sec principles.
I'm looking your guidance on the following scenario:
Where we are expected to have million+ users in a single group; which
means the million DN entries in "member" attribute of group object
- Firstly how is it going to affect the user authorization calls made
from portal to ADAM? (I believe, it should not as it should ideally
lookup for user object and return the "memberOf" list back to the
portal") but I would appritiate your thought on this.
- Secondly, how does this impact the group management functions where
I need to add / delete any users from this large group?
Amol.- Hide quoted text -
- Show quoted text -- Hide quoted text -
- Show quoted text -
.
- References:
- ADAM schema design
- From: amol4321
- Re: ADAM schema design
- From: Joe Kaplan
- Re: ADAM schema design
- From: Amol
- Re: ADAM schema design
- From: Joe Kaplan
- Re: ADAM schema design
- From: Dmitri Gavrilov [MSFT]
- ADAM schema design
- Prev by Date: Re: telnet to network.. log in..change user properties
- Next by Date: Re: Integrating a newly acquired subsidiary of a big corporation.
- Previous by thread: Re: ADAM schema design
- Next by thread: Re: IAS Radius - more than 1 policy possible?
- Index(es):
Relevant Pages
|
Loading